Nuk e dimë si ka ndodhur, por na erdhi një kërkesë për shërbimet e reja të cloud-it. Ne përllogaritëm në përgjithësi se çfarë na nevojitet dhe dërguam një listë pyetjesh për sqarimin e detajeve. Më pas analizuam përgjigjet dhe kuptuam: klienti dëshiron të vendosë në cloud të dhëna personale të nivelit të dytë të sigurisë. I përgjigjemi: "Ju keni të dhëna personale të nivelit të dytë, na vjen keq, mund të ofrojmë vetëm një cloud privat." Ai tha: "E dini, në kompaninë X mund të vendos çdo gjë në publik."
Foto Steve Crisp, Reuters
ĂĂ«shtje tĂ« çuditshme! Shkuam nĂ« faqen e kompanisĂ« X, studiuam dokumentet e tyre tĂ« akreditimit, tundĂ«m kokĂ«n dhe kuptuam: ka shumĂ« pyetje tĂ« hapura pĂ«r vendosjen e tĂ« dhĂ«nave personale qĂ« duhen analizuar mirĂ«. KĂ«shtu do tĂ« veprojmĂ« nĂ« kĂ«tĂ« postim.
Si duhet të funksionojë gjithçka
Për të filluar, le të analizojmë se me cilat kritere klasifikohen të dhënat personale në nivele të ndryshme të sigurisë. Kjo varet nga kategoria e të dhënave, numri i subjekteve të këtyre të dhënave që ruan dhe përpunon operatori, si dhe nga lloji i kërcënimeve aktuale.
Përcaktimi i llojeve të kërcënimeve aktuale jepet në të datës 1 Nëntor 2012 "Për miratimin e kërkesave për mbrojtjen e të dhënave personale gjatë përpunimit në sistemet informacioni për të dhënat personale":
"Kërcënimet e tipit të parë janë të rëndësishme për një sistem informacioni, nëse për të janë të rëndësishme gjithashtu kërcënimet që lidhen me praninë e mundësive të pabëra (të padeklaruara) në programin sistemor, që përdoret në sistemin informacioni.
Kërcënimet e tipit të dytë janë të rëndësishme për një sistem informacioni, nëse për të janë të rëndësishme gjithashtu kërcënimet që lidhen me praninë e mundësive të pabëra (të padeklaruara) në programin aplikues, që përdoret në sistemin informacioni.
Kërcënimet e tipit të tretë janë të rëndësishme për një sistem informacioni, nëse për të janë të rëndësishme kërcënimet që nuk lidhen me praninë e mundësive të pabëra (të padeklaruara) në programin sistemor dhe aplikues, që përdoret në sistemin informacioni."
E rëndësishme në këto përkufizime është pranija e mundësive të pabëra (të padeklaruara). Për të konfirmuar mungesën e mundësive të pabëra në programin (në rastin e cloud-it, kjo është hipervizori), bëhet një certifikim nga FSTEK e Rusisë. Nëse operatori i të dhënave personale pranon se nuk ka mundësi të tilla në program, atëherë kërcënimet përkatëse nuk janë të rëndësishme. Operatorët e të dhënave personale shumë rrallë i pranojnë kërcënimet e tipit të parë dhe të dytë si të rëndësishme.
Përveç përcaktimit të nivelit të mbrojtjes së të dhënave personale, operatori duhet gjithashtu të identifikojë kërcënimet aktuale për cloud-in publik dhe, duke u bazuar në nivelin e zbuluar të mbrojtjes të të dhënave personale dhe kërcënimet aktuale, të përcaktojë masat dhe mjetet e nevojshme për mbrojtjen nga to.
Në FSTEK të gjitha kërcënimet kryesore janë të listuara qartë në (banka e të dhënave për kërcënimet). Ofruesit dhe vlerësuesit e infrastrukturave cloud përdorin këtë bazë në punën e tyre. Ja disa shembuj kërcënimesh:
: «Kërcënimi qëndron në mundësinë e shkeljes së sigurisë së të dhënave të përdoruesit nga programe që funksionojnë brenda një makine virtuale, nga një software keqdashës që funksionon jashtë makinës virtuale». Ky kërcënim është i përshkaktuar nga prania e vulnerabiliteteve në softuerin e hypervisor-it që siguron izolimin e hapësirës adresore përdorur për ruajtjen e të dhënave të përdoruesve që funksionojnë brenda makinës virtuale nga qasja e paautorizuar nga softueri keqdashës që funksionon jashtë makinës virtuale.
Zbatimi i këtij kërcënimi është i mundur nëse kodin keqdashës arrin të kalojë kufijtë e makinës virtuale, jo vetëm përmes shfrytëzimit të vulnerabiliteteve të hypervisor-it, por edhe përmes një ndikimi nga nivele më të ulta (në lidhje me hypervisor-in) të funksionimit të sistemit.
: «Kërcënimi qëndron në mundësinë e qasjes së paautorizuar në informacionin e mbrojtur të një përdoruesi të shërbimeve cloud nga një tjetër. Ky kërcënim ndodh për shkak të veçorive të teknologjive cloud, ku përdoruesit e shërbimeve cloud duhet të ndajnë të njëjtën infrastrukturë cloud. Zbatimi i këtij kërcënimi është i mundur në rast se bëhen gabime në ndarjen e elementeve të infrastrukturës cloud mes përdoruesve, si dhe në izolimin e burimeve të tyre dhe ndarjen e të dhënave nga njëra-tjetra.
Mbrojtja nga këto kërcënime mund të arrihet vetëm nëpërmjet hypervisor-it, pasi ai menaxhon burimet virtuale. Prandaj, hypervisor-i duhet të gjykohet si një mjet mbrojtës.
Dhe në përputhje me nga 18 shkurt 2013, hipervizori duhet të kalojë certifikimin për mungesën e mundësive të pa deklaruara në nivelin 4, përnd otherwise, përdorimi i të dhënave personale të nivelit 1 dhe 2 me të do të ishte i paligjshëm («p.12. ⊠Për të siguruar nivelet 1 dhe 2 të mbrojtjes së të dhënave personale, si dhe për të siguruar nivelin 3 të mbrojtjes së të dhënave personale në sistemet informatik, për të cilat kërcënimet e aktuale janë klasifikuar si rreziku i tipit 2, përdoren mjetet e mbrojtjes së informacionit, programet e të cilave kanë kaluar verifikimin jo më të ulët se niveli 4 i kontrollit të mungesës së mundësive të pa deklaruara»).
Niveli i nevojshĂ«m i certifikimit, NĂD-4, e ka vetĂ«m njĂ« hipervizor, tĂ« zhvilluar nĂ« Rusi â . Thjesht nuk Ă«shtĂ« njĂ« zgjidhje shumĂ« e njohur. Ajo qĂ« quhet cloud komercial zakonisht ndĂ«rtohet mbi bazĂ«n e VMware vSphere, KVM, Microsoft Hyper-V. AsnjĂ« nga kĂ«to produkte nuk ka certifikatĂ« pĂ«r NĂD-4. Pse? Ndoshta, marrja e njĂ« certifikate tĂ« tillĂ« pĂ«r prodhuesit aktualisht nuk justifikohet ekonomikisht.
Dhe na mbetet vetëm Horizont VC për të dhënat personale të niveleve 1 dhe 2 në cloud publik. E trishtë por e vërtetë.
Siç funksionon (në mendimin tonë) në të vërtetë
NĂ« shikim tĂ« parĂ«, duket mjaft e rreptĂ«: kĂ«rcĂ«nimet e specifikuara duhet tĂ« eliminohen me konfigurimin e duhur tĂ« mekanizmave tĂ« mbrojtjes sĂ« hipervizorit, tĂ« certifikuar sipas NĂD-4. Por ka njĂ« anĂ«. NĂ« pĂ«rputhje me UrdhĂ«rin e FSTEK â21 («p.2 Siguria e tĂ« dhĂ«nave personale gjatĂ« pĂ«rpunimit tĂ« tyre nĂ« njĂ« sistem informatik tĂ« tĂ« dhĂ«nave personale (mĂ« pas â sistemi informatik) siguron operatori ose personi qĂ« kryen pĂ«rpunimin e tĂ« dhĂ«nave personale sipas kĂ«rkesĂ«s sĂ« operatorit nĂ« pĂ«rputhje me e FederatĂ«s Ruse»), ofruesit vlerĂ«sojnĂ« vetĂ« aktualitetin e kĂ«rcĂ«nimeve tĂ« mundshme dhe sipas kĂ«saj zgjedhin masat e mbrojtjes. Prandaj, nĂ«se nuk i konsiderojmĂ« kĂ«rcĂ«nimet UBI.44 dhe UBI.101 si aktuale, atĂ«herĂ« nuk do tĂ« ketĂ« nevojĂ« pĂ«r pĂ«rdorimin e hipervizorit tĂ« certifikuar sipas NĂD-4, i cili duhet pikĂ«risht tĂ« sigurojĂ« mbrojtjen nga ato. Dhe kjo do tĂ« jetĂ« e mjaftueshme pĂ«r tĂ« marrĂ« njĂ« certifikatĂ« pĂ«r pĂ«rputhjen e cloud-it publik me nivelet 1 dhe 2 tĂ« mbrojtjes sĂ« tĂ« dhĂ«nave personale, tĂ« cilit Roskomnadzor do tâi jetĂ« plotĂ«sisht i kĂ«naqur.
Sigurisht, përveç Roskomnadzor, FSTEK mund të kryejë verifikime - dhe kjo organizatë është shumë më e kujdesshme në çështje teknike. Ajo sigurisht që do të jetë e interesuar përse këto kërcënime UBI.44 dhe UBI.101 u konsideruan të pavlefshme? Por zakonisht FSTEK ndërmerr kontroll vetëm kur merr informacion mbi ndonjë incident të rëndësishëm. Në këtë rast, shërbimi federal fillimisht shkon tek operatori i të dhënave personale - pra, te klienti i shërbimeve në cloud. Në rastin më të keq, operatori merr një gjobë të vogël - për shembull, për Twitter në fillim të vitit. në një rast të ngjashëm ishte 5000 rubla. Pastaj FSTEK vazhdon më tutje, tek ofruesi i shërbimeve në cloud. Ky i fundit mund të humbasë licencën për shkak të mosrespektimit të kërkesave rregullatore - dhe këtu janë rreziqe krejtësisht të tjera, si për ofruesin e shërbimeve në cloud, ashtu edhe për klientët e tij. Por, e përsëris, për verifikimin FSTEK zakonisht ka nevojë për një arsye të qartë. Pra, ofruesit e shërbimeve në cloud janë të gatshëm të pranojnë rrezik. Deri në incidentin e parë të rëndë.
Ka gjithashtu një grup ofruesish "më të përgjegjshëm" që mendojnë se mund të mbyllen të gjitha kërcënimet, duke shtuar mbi hipervizorin një shtesë të tipit vGate. Por në një ambient virtual të shpërndarë midis klientëve, për disa kërcënime (për shembull, UBI.101 e përmendur më sipër), një mekanizëm efektiv mbrojtjeje mund të realizohet vetëm në nivelin e hipervizorit të certifikuar sipas NDV-4, sepse të gjitha sistemet-shtesë nuk ndikojnë në funksionet standarde të punës së hipervizorit për menaxhimin e burimeve (veçanërisht, memorie operativë).
Si punojmë ne
Ne kemi një segment cloud, i implementuar në një hipervizor të certifikuar nga FSTEK (por pa çertifikim për NDV-4). Ky segment është i vlerësuar, kështu që në bazë të tij në cloud mund të ruhet të dhëna personale. nivelet 3 dhe 4 të sigurisë - kërkesat për mbrojtje nga mundësitë e papara këtu nuk janë të nevojshme. Ja, për më tepër, arkitektura e segmentit tonë të sigurt të cloud-it:
Sistemet pĂ«r tĂ« dhĂ«nat personale nivelet 1 dhe 2 tĂ« sigurisĂ« Ne ofrojmĂ« vetĂ«m nĂ« pajisje tĂ« dedikuara. VetĂ«m nĂ« kĂ«tĂ« rast, pĂ«r shembull, kĂ«rcĂ«nimi UBI.101 nĂ« tĂ« vĂ«rtetĂ« nuk Ă«shtĂ« aktual, pasi raftet e serverĂ«ve, tĂ« cilat nuk janĂ« tĂ« lidhura nĂ« njĂ« mjedis virtual, nuk mund tĂ« ndikojnĂ« njĂ«ra-tjetrĂ«n edhe kur ndodhen nĂ« tĂ« njĂ«jtin QENDĂR TĂ TĂ DHENAVE. PĂ«r kĂ«to raste ofrojmĂ« shĂ«rbimin e qirasĂ« sĂ« pajisjeve tĂ« dedikuara (i njohur gjithashtu si Hardware as a Service, pajisja si njĂ« shĂ«rbim).
Nëse nuk jeni të sigurt se cilin nivel mbrojtjeje kërkon sistemi juaj i të dhënave personale, ne gjithashtu ndihmojmë në klasifikimin e tyre.
PĂ«rfundimi
Një studim i vogël i tregut tregoi: disa operatorë të cloud-it janë gati të rrezikojnë si sigurinë e të dhënave të klientëve, ashtu edhe të ardhmen e tyre për të marrë një porosi. Por ne në këto çështje ndjekim një politikë tjetër, të cilën e përshkruam shkurtimisht më sipër. Do të jemi të lumtur të përgjigjemi në komentet tuaja për pyetjet tuaja.
Burimi: habr.com
