"Och sÄ kommer det att göra": att molnleverantörer inte förhandlar om personuppgifter

En dag fick vi en förfrÄgan om molntjÀnster. Vi beskrev i allmÀnna termer vad som skulle krÀvas av oss och skickade tillbaka en lista med frÄgor för att förtydliga detaljerna. Sedan analyserade vi svaren och insÄg: kunden vill placera personuppgifter av den andra sÀkerhetsnivÄn i molnet. Vi svarar honom: "Du har en andra nivÄ av personlig data, förlÄt, vi kan bara skapa ett privat moln." Och han: "Du vet, men i företag X kan de publicera allt till mig offentligt."

"Och sÄ kommer det att göra": att molnleverantörer inte förhandlar om personuppgifter
Foto av Steve Crisp, Reuters

Konstiga saker! Vi gick till webbplatsen för företag X, studerade deras certifieringsdokument, skakade pÄ vÄra huvuden och insÄg: det finns mÄnga öppna frÄgor i placeringen av personuppgifter och de bör behandlas noggrant. Det Àr vad vi kommer att göra i det hÀr inlÀgget.

Hur allt ska fungera

LÄt oss först ta reda pÄ vilka kriterier som anvÀnds för att klassificera personuppgifter som en eller annan sÀkerhetsnivÄ. Detta beror pÄ kategorin av data, antalet individer av denna data som operatören lagrar och bearbetar, samt typen av aktuella hot.

"Och sÄ kommer det att göra": att molnleverantörer inte förhandlar om personuppgifter

Typerna av aktuella hot definieras i Dekret frĂ„n Ryska federationens regering nr 1119 daterad 1 november 2012 ”Om godkĂ€nnande av krav pĂ„ skydd av personuppgifter vid deras behandling i personuppgiftsinformationssystem”:

"Typ 1-hot Àr relevanta för ett informationssystem om det inkluderar aktuella hot relaterade till med förekomsten av odokumenterade (odeklarerade) förmÄgor i systemprogramvarananvÀnds i informationssystemet.

Hot av den 2:a typen Àr relevanta för ett informationssystem om för det, inklusive aktuella hot relaterade till med förekomsten av odokumenterade (odeklarerade) förmÄgor i applikationsprogramvaraanvÀnds i informationssystemet.

Hot av den tredje typen Àr relevanta för ett informationssystem om för det hot som inte Àr relaterade med förekomsten av odokumenterade (odeklarerade) förmÄgor i system och tillÀmpningsprogramanvÀnds i informationssystemet."

Huvudsaken i dessa definitioner Àr förekomsten av odokumenterade (odeklarerade) förmÄgor. För att bekrÀfta frÄnvaron av odokumenterade mjukvarufunktioner (i fallet med molnet Àr detta en hypervisor) utförs certifiering av FSTEC i Ryssland. Om PD-operatören accepterar att det inte finns nÄgra sÄdana funktioner i programvaran, Àr motsvarande hot irrelevanta. Hot av typ 1 och 2 anses extremt sÀllan vara relevanta av PD-operatörer.

Förutom att bestÀmma PD-sÀkerhetsnivÄn mÄste operatören Àven faststÀlla specifika aktuella hot mot det offentliga molnet och, baserat pÄ den identifierade nivÄn av PD-sÀkerhet och aktuella hot, bestÀmma nödvÀndiga ÄtgÀrder och skyddsmedel mot dem.

FSTEC listar tydligt alla huvudhoten i NOS (hotdatabas). Molninfrastrukturleverantörer och bedömare anvÀnder denna databas i sitt arbete. HÀr Àr exempel pÄ hot:

UBI.44: "Hotet Àr möjligheten att bryta mot sÀkerheten för anvÀndardata för program som verkar inuti en virtuell maskin av skadlig programvara som verkar utanför den virtuella maskinen." Detta hot beror pÄ nÀrvaron av sÄrbarheter i hypervisormjukvaran, som sÀkerstÀller att adressutrymmet som anvÀnds för att lagra anvÀndardata för program som arbetar inuti den virtuella maskinen Àr isolerat frÄn obehörig Ätkomst av skadlig programvara som fungerar utanför den virtuella maskinen.

Implementeringen av detta hot Àr möjlig förutsatt att den skadliga programkoden framgÄngsrikt övervinner grÀnserna för den virtuella maskinen, inte bara genom att utnyttja hypervisorns sÄrbarheter, utan ocksÄ genom att utföra en sÄdan pÄverkan frÄn lÀgre (i förhÄllande till hypervisorn) nivÄer av systemet fungerar."

UBI.101: ”Hotet ligger i möjligheten för obehörig Ă„tkomst till den skyddade informationen frĂ„n en molntjĂ€nstkonsument frĂ„n en annan. Detta hot beror pĂ„ det faktum att, pĂ„ grund av molnteknikens natur, molntjĂ€nstkonsumenter mĂ„ste dela samma molninfrastruktur. Detta hot kan realiseras om det görs fel nĂ€r man separerar molninfrastrukturelement mellan molntjĂ€nstkonsumenter, sĂ„vĂ€l som nĂ€r man isolerar deras resurser och separerar data frĂ„n varandra.”

Du kan bara skydda dig mot dessa hot med hjÀlp av en hypervisor, eftersom det Àr den som hanterar virtuella resurser. Hypervisorn mÄste alltsÄ betraktas som ett skyddsmedel.

Och i enlighet med pÄ order av FSTEC nr 21 daterad 18 februari 2013 mÄste hypervisorn vara certifierad som icke-NDV pÄ nivÄ 4, annars kommer anvÀndningen av nivÄ 1 och 2 personuppgifter med den att vara olaglig ("Klausul 12. ... För att sÀkerstÀlla nivÄ 1 och 2 av personuppgiftssÀkerhet, samt sÀkerstÀlla nivÄ 3 av personuppgiftssÀkerhet i informationssystem för vilka typ 2-hot klassas som aktuella, anvÀnds informationssÀkerhetsverktyg, vars mjukvara har varit testad Ätminstone enligt 4 nivÄer av kontroll över frÄnvaron av odeklarerade förmÄgor").

Endast en hypervisor, utvecklad i Ryssland, har den erforderliga certifieringsnivÄn, NDV-4. Solens horisont. Milt sagt inte den mest populÀra lösningen. Kommersiella moln Àr vanligtvis byggda pÄ basis av VMware vSphere, KVM, Microsoft Hyper-V. Ingen av dessa produkter Àr NDV-4-certifierade. Varför? Det Àr troligt att det Ànnu inte Àr ekonomiskt motiverat att erhÄlla sÄdan certifiering för tillverkare.

Och allt som ÄterstÄr för oss för personuppgifter pÄ nivÄ 1 och 2 i det offentliga molnet Àr Horizon BC. TrÄkigt men sant.

Hur allting (enligt vÄr mening) verkligen fungerar

Vid första anblicken Ă€r allt ganska strikt: dessa hot mĂ„ste elimineras genom att korrekt konfigurera standardskyddsmekanismerna för en hypervisor certifierad enligt NDV-4. Men det finns ett kryphĂ„l. I enlighet med FSTEC Order No. 21 (”punkt 2 SĂ€kerheten för personuppgifter vid behandling i personuppgiftsinformationssystemet (nedan kallat informationssystemet) sĂ€kerstĂ€lls av verksamhetsutövaren eller den som behandlar personuppgifter för verksamhetsutövarens rĂ€kning i enlighet med lagstiftning Ryska Federationen"), bedömer leverantörer sjĂ€lvstĂ€ndigt relevansen av möjliga hot och vĂ€ljer skyddsĂ„tgĂ€rder i enlighet med detta. DĂ€rför, om du inte accepterar hoten UBI.44 och UBI.101 som aktuella, sĂ„ kommer det inte att finnas nĂ„got behov av att anvĂ€nda en hypervisor certifierad enligt NDV-4, vilket Ă€r just det som ska ge skydd mot dem. Och detta kommer att rĂ€cka för att erhĂ„lla ett certifikat om överensstĂ€mmelse för det offentliga molnet med nivĂ„erna 1 och 2 av personlig datasĂ€kerhet, vilket Roskomnadzor kommer att vara helt nöjd med.

Givetvis kan FSTEC, förutom Roskomnadzor, komma med en inspektion – och denna organisation Ă€r mycket mer noggrann i tekniska frĂ„gor. Hon kommer förmodligen att vara intresserad av varför just hoten UBI.44 och UBI.101 ansĂ„gs irrelevanta? Men vanligtvis gör FSTEC en inspektion först nĂ€r det fĂ„r information om nĂ„gon betydande incident. I det hĂ€r fallet kommer den federala tjĂ€nsten först till personuppgiftsoperatören - det vill sĂ€ga kunden av molntjĂ€nster. I vĂ€rsta fall fĂ„r operatören ett mindre vite – till exempel för Twitter i början av Ă„ret böter i ett liknande fall uppgick till 5000 XNUMX rubel. Sedan gĂ„r FSTEC vidare till molntjĂ€nstleverantören. Som mycket vĂ€l kan bli frĂ„ntagna en licens pĂ„ grund av bristande efterlevnad av myndighetskrav – och det Ă€r helt andra risker, bĂ„de för molnleverantören och för dess kunder. Men jag upprepar, För att kontrollera FSTEC behöver du vanligtvis ett tydligt skĂ€l. SĂ„ molnleverantörer Ă€r villiga att ta risker. Fram till den första allvarliga hĂ€ndelsen.

Det finns ocksÄ en grupp "mer ansvarsfulla" leverantörer som tror att det Àr möjligt att stÀnga alla hot genom att lÀgga till ett tillÀgg som vGate till hypervisorn. Men i en virtuell miljö distribuerad bland kunder för vissa hot (till exempel ovanstÄende UBI.101), kan en effektiv skyddsmekanism endast implementeras pÄ nivÄn för en hypervisor certifierad enligt NDV-4, eftersom alla tillÀggssystem till hypervisorns standardfunktioner för hantering av resurser (i synnerhet RAM) pÄverkar inte.

Hur vi arbetar

Vi har ett molnsegment implementerat pĂ„ en hypervisor certifierad av FSTEC (men utan certifiering för NDV-4). Detta segment har certifierats, sĂ„ personuppgifter kan lagras i molnet baserat pĂ„ det 3 och 4 sĂ€kerhetsnivĂ„er — krav pĂ„ skydd mot odeklarerade förmĂ„gor behöver inte iakttas hĂ€r. HĂ€r Ă€r förresten arkitekturen för vĂ„rt sĂ€kra molnsegment:

"Och sÄ kommer det att göra": att molnleverantörer inte förhandlar om personuppgifter
System för personuppgifter 1 och 2 sÀkerhetsnivÄer Vi implementerar endast pÄ dedikerad utrustning. Bara i det hÀr fallet, till exempel, Àr hotet frÄn UBI.101 verkligen inte relevant, eftersom serverrack som inte Àr förenade av en virtuell miljö inte kan pÄverka varandra Àven nÀr de Àr placerade i samma datacenter. För sÄdana fall erbjuder vi en dedikerad uthyrningstjÀnst för utrustning (det kallas Àven Hardware as a Service).

Om du inte Àr sÀker pÄ vilken sÀkerhetsnivÄ som krÀvs för ditt persondatasystem hjÀlper vi Àven till med att klassificera det.

UtgÄng

VÄr lilla marknadsundersökning visade att vissa molnoperatörer Àr ganska villiga att riskera bÄde sÀkerheten för kunddata och sin egen framtid för att fÄ en order. Men i dessa frÄgor följer vi en annan policy, som vi kort beskrev precis ovan. Vi svarar gÀrna pÄ dina frÄgor i kommentarerna.

KĂ€lla: will.com

Köp pĂ„litlig hosting för webbplatser med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster