"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

Lägg en kommentar