Op een of ander manier het 'n toepassing vir wolkdienste na ons toe gekom. Ons het in algemene terme uitgepluis wat van ons vereis sou word, en 'n lys vrae teruggestuur om die besonderhede te verduidelik. Toe het ons die antwoorde ontleed en besef: die kliënt wil persoonlike data van die tweede vlak van sekuriteit in die wolk plaas. Ons antwoord hom: "Jy het 'n tweede vlak van persoonlike data, jammer, ons kan net 'n private wolk maak." En hy: "Jy weet, maar in maatskappy X kan hulle alles vir my in die openbaar plaas."
Foto Steve Crisp, Reuters
Vreemde dinge! Ons het na die webwerf van maatskappy X gegaan, hul attestaatdokumente bestudeer, ons koppe geskud en besef dat daar baie oop vrae in die plasing van persoonlike data is en hulle moet goed geventileer word. Wat ons in hierdie pos sal doen.
Hoe dinge moet werk
Om mee te begin, laat ons uitvind op watter gronde persoonlike data oor die algemeen aan een of ander vlak van sekuriteit toegeskryf word. Dit hang af van die kategorie data, van die aantal onderwerpe van hierdie data wat die operateur stoor en verwerk, sowel as die tipe huidige bedreigings.
Vir 'n definisie van die tipes huidige bedreigings, sien gedateer 1 November 2012 "By goedkeuring van vereistes vir die beskerming van persoonlike data tydens die verwerking daarvan in inligtingstelsels van persoonlike data":
“Bedreigings van die 1ste tipe is relevant vir 'n inligtingstelsel, indien daarvoor o.a. huidige bedreigings wat verband hou met die teenwoordigheid van ongedokumenteerde (onverklaarde) kenmerke in stelselsagtewarein die inligtingstelsel gebruik word.
Bedreigings van die 2de tipe is relevant vir 'n inligtingstelsel, indien daarvoor o.a. huidige bedreigings wat verband hou met die teenwoordigheid van ongedokumenteerde (onverklaarde) kenmerke in toepassingsagtewarein die inligtingstelsel gebruik word.
Bedreigings van die 3de tipe is relevant vir 'n inligtingstelsel indien daarvoor relevante bedreigings wat nie verband hou nie met die teenwoordigheid van ongedokumenteerde (onverklaarde) kenmerke in stelsel- en toepassingsagtewarein die inligtingstelsel gebruik word."
Die belangrikste ding in hierdie definisies is die teenwoordigheid van ongedokumenteerde (onverklaarde) kenmerke. Om die afwesigheid van ongedokumenteerde sagteware-kenmerke te bevestig (in die geval van die wolk is dit 'n hiperviser), is FSTEC van Rusland gesertifiseer. As die PD-operateur aanvaar dat daar nie sulke geleenthede in die sagteware is nie, is die ooreenstemmende bedreigings irrelevant. Bedreigings van die 1ste en 2de tipes word selde deur PD-operateurs as relevant aanvaar.
Benewens die bepaling van die vlak van PD-sekuriteit, moet die operateur ook spesifieke huidige bedreigings vir die publieke wolk bepaal en, gebaseer op die geïdentifiseerde vlak van PD-sekuriteit en huidige bedreigings, die nodige maatreëls en middele van beskerming daarteen bepaal.
Die FSTEC het al die belangrikste bedreigings duidelik gelys (bedreigingsdatabasis). Verskaffers en sertifiseerders van wolkinfrastruktuur gebruik hierdie basis in hul werk. Hier is voorbeelde van dreigemente:
: "Die bedreiging lê in die moontlikheid om die sekuriteit van gebruikersdata van programme wat binne die virtuele masjien werk, te kompromitteer deur kwaadwillige sagteware wat buite die virtuele masjien werk." Hierdie bedreiging is te wyte aan die teenwoordigheid van kwesbaarhede in die hipervisor-sagteware, wat die isolasie verseker van die adresruimte wat gebruik word om gebruikersdata van programme wat binne die virtuele masjien werk, te stoor van ongemagtigde toegang deur kwaadwillige sagteware wat buite die virtuele masjien werk.
Die implementering van hierdie bedreiging is moontlik as die kwaadwillige programkode die grense van die virtuele masjien suksesvol oorkom, nie net deur die kwesbaarhede van die hiperviser te ontgin nie, maar ook deur so 'n impak vanaf laer (in verhouding tot die hipervisor) vlakke van die stelsel funksionering.
: “Die bedreiging lê in die moontlikheid van ongemagtigde toegang tot die beskermde inligting van een wolkdiensverbruiker deur ’n ander. Hierdie bedreiging is te wyte aan die feit dat, as gevolg van die aard van wolktegnologie, wolkdiensverbruikers dieselfde wolkinfrastruktuur moet deel. Die implementering van hierdie bedreiging is moontlik as foute gemaak word wanneer elemente van die wolkinfrastruktuur tussen verbruikers van wolkdienste geskei word, sowel as wanneer hul hulpbronne isoleer en data van mekaar isoleer.
U kan slegs teen hierdie bedreigings beskerm met die hulp van 'n hiperviser, aangesien dit hy is wat virtuele hulpbronne bestuur. Die hiperviseerder moet dus as 'n beskermingsmiddel beskou word.
En in ooreenstemming met gedateer 18 Februarie 2013, moet die hiperviser gesertifiseer wees vir die afwesigheid van NDV op vlak 4, anders sal die gebruik van persoonlike data van vlakke 1 en 2 daarmee onwettig wees ("Item 12. … Om die 1ste en 2de vlakke van persoonlike datasekuriteit te verseker, asook om die 3de vlak van persoonlike datasekuriteit te verseker in inligtingstelsels waarvoor tipe 2-bedreigings as relevant geklassifiseer word, word inligtingsekuriteitsinstrumente gebruik, waarvan die sagteware het ten minste 4 die vlak van beheer van die afwesigheid van onverklaarde vermoëns getoets").
Die vereiste vlak van sertifisering, NDV-4, het slegs een hipervisor, Russiese ontwikkeling - . Om dit sagkens te stel, nie die gewildste oplossing nie. Kommersiële wolke word gewoonlik gebou op die basis van VMware vSphere, KVM, Microsoft Hyper-V. Nie een van hierdie produkte is NDV-4-gesertifiseer nie. Hoekom? Waarskynlik is die verkryging van sulke sertifisering vir vervaardigers nog nie ekonomies geregverdig nie.
En dit bly vir ons vir die persoonlike data van die 1ste en 2de vlakke in die openbare wolk net Horizon VS. Hartseer maar waar.
Hoe alles (na ons mening) eintlik werk
Met die eerste oogopslag is alles redelik streng: hierdie bedreigings moet uitgeskakel word deur die standaardbeskermingsmeganismes van 'n hipervisor wat volgens NDV-4 gesertifiseer is, behoorlik op te stel. Maar daar is een skuiwergat. In ooreenstemming met FSTEC Bevel No. 21 (“klousule 2 Die sekuriteit van persoonlike data tydens die verwerking daarvan in die persoonlike data inligtingstelsel (hierna verwys as die inligtingstelsel) word verseker deur die operateur of die persoon wat persoonlike data namens die operateur verwerk ooreenkomstig Russiese Federasie"), verskaffers evalueer onafhanklik die relevansie van moontlike bedreigings en kies in ooreenstemming hiermee beskermingsmaatreëls. As die UBI.44- en UBI.101-bedreigings dus nie as relevant aanvaar word nie, sal dit nie nodig wees om 'n hiperviseerder te gebruik wat volgens NDV-4 gesertifiseer is nie, wat beskerming daarteen behoort te bied. En dit sal genoeg wees om 'n sertifikaat van voldoening van die openbare wolk met 1- en 2-vlakke van PD-sekuriteit te verkry, waarmee Roskomnadzor heeltemal tevrede sal wees.
Natuurlik, benewens Roskomnadzor, kan die FSTEC met 'n oudit kom - en hierdie organisasie is baie noukeuriger in tegniese sake. Sy sal beslis belangstel in hoekom presies die dreigemente UBI.44 en UBI.101 as irrelevant beskou is? Maar gewoonlik onderneem die FSTEC slegs 'n inspeksie wanneer dit inligting oor een of ander helder voorval ontvang. In hierdie geval kom die federale diens eers na die operateur van persoonlike data - dit wil sê die kliënt van wolkdienste. In die ergste geval kry die operateur ’n klein boete – byvoorbeeld vir Twitter aan die begin van die jaar in 'n soortgelyke geval beloop 5000 roebels. Dan gaan FSTEC verder na 'n wolkdiensverskaffer. Wat heel moontlik van lisensies ontneem kan word weens nie-nakoming van regulatoriese vereistes – en dit is heeltemal verskillende risiko's, beide vir die wolkverskaffer en vir sy kliënte. Maar, ek herhaal, 'n duidelike rede is gewoonlik nodig om die FSTEC na te gaan. Wolkverskaffers is dus bereid om die risiko te neem. Tot die eerste groot voorval.
Daar is ook 'n groep "meer verantwoordelike" verskaffers wat glo dat dit moontlik is om alle bedreigings te sluit deur 'n byvoeging soos vGate by die hiperviser te voeg. Maar in 'n virtuele omgewing wat onder kliënte versprei is vir sommige bedreigings (byvoorbeeld, die bogenoemde UBI.101), kan 'n effektiewe beskermingsmeganisme slegs geïmplementeer word op die vlak van 'n hiperviseerder wat volgens NDV-4 gesertifiseer is, aangesien enige byvoegingstelsels tot die standaardfunksies van die hulpbronbestuur-hipervisor (veral RAM) beïnvloed nie.
Hoe ons werk
Ons het 'n wolksegment wat op 'n FSTEC-gesertifiseerde hipervisor geïmplementeer is (maar sonder NDV-4-sertifisering). Hierdie segment is gesertifiseer, sodat persoonlike data op grond daarvan in die wolk geplaas kan word 3 en 4 sekuriteitsvlakke - die vereistes vir beskerming teen onverklaarde vermoëns hoef nie hier nagekom te word nie. Terloops, hier is die argitektuur van ons veilige wolksegment:
Stelsels vir persoonlike data 1 en 2 sekuriteitsvlakke Ons implementeer slegs op toegewyde toerusting. Slegs in hierdie geval, byvoorbeeld, is die UBI.101-bedreiging regtig nie relevant nie, aangesien bedienerrekke wat nie deur een virtuele omgewing verenig is nie, mekaar nie kan beïnvloed nie, selfs wanneer dit in dieselfde datasentrum geplaas word. Vir sulke gevalle bied ons 'n diens vir die huur van toegewyde toerusting (dit word ook Hardeware as 'n diens, toerusting as 'n diens genoem).
As jy nie seker is watter vlak van sekuriteit vir jou persoonlike datastelsel vereis word nie, help ons ook om dit te klassifiseer.
Output
Ons klein marknavorsing het getoon dat sommige wolkoperateurs baie bereid is om beide die sekuriteit van klantdata en hul eie toekoms te waag om 'n bestelling te ontvang. Maar ons hou by 'n ander beleid in hierdie sake, wat ons kortliks 'n bietjie hoër beskryf het. Ons sal graag jou vrae in die kommentaar beantwoord.
Bron: will.com