Varnost podatkov v oblaku: deljeno odgovornost naredite konkretno

Ponudnik storitev v oblaku upravlja del varnostnega okolja. Vaša ekipa mora še vedno ugotoviti, katere zaščite konfigurira sama, ali zajemajo podatke in storitve v uporabi ter kako ve, da ostajajo učinkovite.

Varnost podatkov v oblaku ščiti zaupnost, celovitost in razpoložljivost pri shranjevanju, obdelavi, deljenju in obnovitvi. Vključuje baze podatkov in objektne shrambe, pa tudi dovoljenja aplikacij, izvoze iz storitev SaaS, identitete storitev, varnostne kopije ter prenosnike ali sisteme za avtomatizacijo, ki lahko pridobijo podatke.

Z vidika tehničnega direktorja (CTO) postane deljena odgovornost koristna šele, ko privede do konkretnih inženirskih odločitev: kdo konfigurira kontrolo, kdo jo spremlja, kateri dokazi izkazujejo njeno delovanje in kdo ukrepa, ko odpove. Varnostna izjava ponudnika na ta vprašanja za vašo namestitev ne more odgovoriti.

Mejo določite, preden izberete kontrole

Okolja v oblaku združujejo infrastrukturo, platforme in aplikacije, ki se zagotavljajo na daljavo. Javni oblak praviloma uporablja infrastrukturo, ki jo upravlja ponudnik in ki služi več strankam; zasebni oblak je namenjen eni organizaciji. Nobena oznaka ne določa, ali so vaši podatki ustrezno zaščiteni. Izolacija, poti dostopa, operativno lastništvo in ureditve za obnovitev so pomembnejši od oznake.

Začnite z eno poslovno storitvijo in sledite njenim odvisnostim. Ugotovite račune ali naročnine v oblaku, regije, storitve, podatkovne shrambe, skrbnike in sisteme za namestitev. Vključite izdelke SaaS, ki jih uporabljajo podpora, finance in razvoj: produkcijska baza podatkov je lahko strogo nadzorovana, medtem ko njen izvoz podatkov o strankah leži v široko deljenem delovnem prostoru.

Popis naj odgovori na ta vprašanja:

• Katere informacije se shranjujejo ali obdelujejo in kdo je lastnik poslovnega namena?
• Kje so primarni zapisi, replike, dnevniki, izvozi, predpomnilniki in varnostne kopije?
• Kateri ljudje, delovne obremenitve, dobavitelji in zunanji prejemniki lahko dostopajo do njih?
• Kateri računi, regije in storitve so odobreni in kako se odkrivajo novi?
• Katere zahteve glede hrambe, izbrisa, razpoložljivosti in pogodb veljajo?

Prilagodljivost oblaka in dostopnost na daljavo lahko izboljšata delovanje, upravljane storitve pa lahko zmanjšajo vzdrževanje infrastrukture. Hkrati olajšajo ustvarjanje virov in kopij hitreje, kot jim lahko sledijo pregledovalci. Stroški varnosti zato vključujejo upravljanje identitet, spremljanje, zbiranje dokazov, preizkušanje obnovitve in nadzor nad dobavitelji – ne le računa za shranjevanje.

Informacije razvrstite tam, kjer dejansko so

Uporabite obvladljivo shemo razvrščanja, povezano z ukrepi. Kategorije javno, interno, zaupno in omejeno lahko na primer določajo pravila deljenja, preglede dostopov, beleženje in hrambo. Opredelite, katera kategorija zajema identifikatorje strank, avtentikacijske skrivnosti, finančne zapise, izvorno kodo in občutljive osebne podatke.

Samodejno odkrivanje lahko pomaga najti spregledane nabore podatkov, vendar rezultate preverite z lastniki podatkov. Skener lahko spregleda stisnjene arhive ali polja, specifična za aplikacijo, neškodljiv testni niz pa lahko sproži lažno pozitiven rezultat. Zabeležite nepregledane lokacije in omejitve vzorčenja. Za celovitejši delovni tok odkrivanja glejte odkrivanje podatkov in zasebnost.

Odgovornost popišite za vsako storitev posebej

Meja odgovornosti se spreminja z modelom storitve in izvedbo ponudnika. Spodnje obravnavajte kot izhodišče, ki ga je treba potrditi z dokumentacijo storitve in pogodbami, ne kot splošno razdelitev.

Za vsako pomembno zaščito zabeležite prispevek ponudnika, konfiguracijo stranke, operativnega lastnika, pregledovalca in vir dokazov. Izogibajte se vnosom, kot je »šifriranje: ponudnik«. Namesto tega zapišite: »Ponudnik zagotavlja upravljano šifriranje; ekipa platforme izbere konfiguracijo ključev; varnost pregleda dovoljenja za dešifriranje; lastnik storitve preizkusi obnovitev.«

Poleg človeških uporabnikov vključite tudi identitete storitev in avtomatizacijo namestitev. Cevovod, ki ustvarja vire, spreminja politike dostopa ali pridobiva skrivnosti, je del varnostne meje. Tudi upravljavci upravljanih storitev in zunanji ponudniki podpore potrebujejo izrecne odgovornosti, tudi kadar infrastrukturo upravljajo v vašem imenu.

Opredelite napake pri predajah. Če ponudnik sporoči kompromitirano poverilnico, kdo prejme obvestilo zunaj delovnega časa? Če baza podatkov ni na voljo, kdo odloči, ali obnoviti, preklopiti na rezervni sistem ali počakati? Vsakemu izidu na strani stranke dodelite enega odgovornega notranjega lastnika, tudi kadar delo izvaja več ekip.

Zagotovila ponudnika ocenite, ne da bi jih preširoko razlagali

Preglejte varnostno dokumentacijo storitve, komunikacijo ob incidentih, ureditve podpornega dostopa, podobdelovalce, ravnanje ob izbrisu, možnosti obnovitve in razpoložljive revizijske dnevnike. Preverite, ali ustrezna raven računa dejansko vključuje funkcije, ki jih potrebuje vaša zasnova.

Dokumenti o zagotovilih zahtevajo pregled obsega. Poročilo SOC 2 je poročilo o atestaciji, ne certifikat. Certifikat ISO 27001 se nanaša na sistem upravljanja informacijske varnosti z opredeljenim obsegom in ne dokazuje, da je vaš najemnik varno konfiguriran. Preverite zajete storitve, obdobje poročanja, izjeme in kontrole stranke, navedene v poročilu.

Kadar je ustrezno, katalog BSI C5 zagotavlja merila za zagotovila v oblaku. Razlikujte oceno tipa 1, ki zajema zasnovo in izvedbo v določenem trenutku, od tipa 2, ki zajema delovanje v določenem obdobju. Nobena ne nadomesti preizkušanja vaših lastnih dostopov in podatkovnih tokov.

Obveznosti prevedite v tehnične zahteve

Preden izberete regijo ali sprejmete pogoje ponudnika, ugotovite veljavno zakonodajo in zaveze do strank. Uporaba je odvisna od informacij, vlog pri obdelavi, sektorja, jurisdikcij in razmerij pri storitvah. Poročilo ali certifikat ponudnika ne dokazuje skladnosti vaše organizacije s predpisi.

Za osebne podatke, za katere velja Splošna uredba o varstvu podatkov (GDPR), 32. člen zahteva varnost, ustrezno tveganju; ni splošna obveznost šifriranja vsakega nabora podatkov v vseh okoliščinah. Kadar ponudnik deluje kot obdelovalec, ocenite pogodbene zahteve iz 28. člena. Ureditve mednarodnih prenosov zahtevajo ločeno oceno. Sama lokacija podatkov ne dokazuje suverenosti ali skladnosti z GDPR, zlasti kadar podporni dostop ali podobdelovalci ustvarjajo dodatne poti dostopa.

Praktično priporočilo: vsako veljavno zahtevo prevedite v preverljivo izjavo: dovoljene regije obdelave, odobreni prejemniki, obdobja hrambe, omejitve dostopa, cilji obnovitve ali predaje pri obveščanju o incidentih. Pravni strokovnjaki in strokovnjaki za zasebnost naj potrdijo razlago, razvoj pa ugotovi, kako bo zahteva izvedena in dokazana.

Preverite dejanski dostop, ne le nameravanih dovoljenj

Ukradene poverilnice, prekomerna pooblastila, javno deljenje in zloraba s strani notranjih oseb so pogoste poti do izpostavljenosti podatkov v oblaku. Šifrirana shramba lahko še vedno razkrije zapise prek pooblaščenega računa ali aplikacije, ki vrne podatke napačne stranke.

Človeške identitete po možnosti povežite prek federacije, tako da procesi ob prihodu, premestitvi in odhodu zaposlenih dosežejo tudi storitve v oblaku. Za privilegirani dostop zahtevajte močno avtentikacijo, kjer je podprto, dajte prednost MFA, odporni proti lažnemu predstavljanju, in rutinsko delo ločite od administracije. Dostop v sili potrebuje nadzorovane poverilnice, spremljano uporabo in preizkušen postopek obnovitve; ne sme postati trajni obvod.

Pri identitetah delovnih obremenitev, kjer je podprto, dajte prednost ozko omejenim poverilnicam s kratko veljavnostjo. Preglejte razmerja zaupanja: katera delovna obremenitev lahko prevzame vlogo, pod katerimi pogoji in v katerem okolju? Odstranite vgrajene skrivnosti iz repozitorijev in artefaktov namestitve ter omejite dostop do same storitve za skrivnosti.

Dejanska dovoljenja ocenite prek politik identitet, politik virov, prevzemanja vlog, članstva v skupinah, povezav za deljenje in omejitev na ravni organizacije. »Samo za branje« lahko še vedno omogoča obsežno izvlečenje občutljivih informacij. Vloga, ki zapisov ne more brati, lahko pa spremeni aplikacijo ali politiko ključev, lahko dostop pridobi posredno.

Dokazi o pregledu dostopov naj navajajo subjekt, vir, dovoljena dejanja, poslovno utemeljitev, odobritelja in po potrebi datum odstranitve. Preizkusite odjavo odhajajočih zaposlenih in potečeni začasni dostop, namesto da se zanašate izključno na pisni postopek.

Izpostavljenost in delovanje aplikacij preverjajte skupaj

Napačna konfiguracija pogosto združuje več nastavitev, ki so vsaka zase videti verjetne. Pri objektni shrambi privzeto šifriranje ne odgovori na vprašanje, kdo lahko bere objekte ali ali jih politika deljenja naredi javne. Identiteto, politike virov, delovanje aplikacije in spremljanje preučite skupaj.

Preverite omejitve javnega dostopa, vhodni omrežni promet, poslušalce baz podatkov, zaupanje med računi, delovanje podpisanih povezav in zunanje deljenje. Zasebne končne točke lahko zmanjšajo izpostavljenost, vendar ne popravijo prekomernih pooblastil ali ranljive aplikacije. Ločite okolja in omejite dostop do produkcije iz razvojnih sistemov.

API-ji v oblaku potrebujejo avtentikacijo in avtorizacijo na ravni objekta in dejanja. Veljaven uporabniški žeton ne sme nikomur omogočiti, da s spremembo identifikatorja pridobi zapise drugega najemnika. Preizkusite končne točke za izvoz, administrativne operacije, množične poizvedbe in obdelovalnike nalaganja. Omejitve hitrosti lahko zmanjšajo zlorabo, ne nadomestijo pa avtorizacije.

S pregledom infrastrukture kot kode in preverjanjem politik preprečite znane nevarne nastavitve, nato odobrena pravila primerjajte z nameščeno konfiguracijo. Spremembe prek konzole, migracije in nujni popravki lahko povzročijo odstopanja. Zabeležite, zakaj izjeme obstajajo, katere so njihove nadomestne kontrole in kdaj potečejo. Modeliranje groženj lahko pred izvedbo pomaga prepoznati poti od izpostavljenega vmesnika do občutljivih podatkov.

Šifriranje in dostop do ključev naj bosta ločeni kontroli

Podatke med prenosom zaščitite s sodobnimi avtenticiranimi protokoli in ustreznim preverjanjem certifikatov. Poleg javnih končnih točk preglejte tudi notranje povezave aplikacij. Za shranjene podatke ugotovite, katere storitve, replike, izvozi, posnetki stanja in varnostne kopije so šifrirani in s kakšnimi ureditvami ključev.

Ključi, ki jih upravlja ponudnik, in ključi, ki jih upravlja stranka, podpirajo različne operativne izbire. Izbirajte na podlagi modela groženj, pogodbenih zahtev, administrativne ločenosti in potreb po obnovitvi. Ključ, ki ga upravlja stranka, ni samodejno varnejši, če isti neomejeni skrbnik nadzoruje tako dostop do podatkov kot dovoljenja za ključe.

Dokumentirajte, kdo lahko ključe uporablja za šifriranje in dešifriranje, jih upravlja, onemogoči in izbriše. Preglejte spremembe politik ključev in nenavadno dešifriranje. Vzpostavite postopke menjave, preklica, hrambe in obnovitve; menjava ključa, odvisno od storitve, ne pomeni nujno ponovnega šifriranja vseh obstoječih kopij.

Storitve KMS in HSM lahko podpirajo zaščito ključev in kriptografske operacije, vendar ne odpravijo odgovornosti v življenjskem ciklu. Preden uveljavite postopek izbrisa ali preklica, preizkusite posledice nedosegljivosti ključa. Zaščitena varnostna kopija je neuporabna, če zahtevanega ključa ni mogoče obnoviti. Za podporne kriptografske odločitve glejte šifriranje in upravljanje ključev.

Spremljajte dejavnosti s podatki in ohranite zmožnost odziva

Beleženje mora zajeti vprašanja, na katera morajo odgovoriti odzivniki. Administrativni revizijski dogodki lahko pokažejo, kdo je spremenil politiko, ne pa, kdo je prenesel nabor podatkov. Ugotovite, kje je beleženje dostopa do podatkov na voljo, ali je omogočeno in kateri dogodki ali storitve ostajajo zunaj pokritosti.

Zbirajte ustrezne dogodke identitet, nadzorne ravnine, dostopa do podatkov, aplikacij, upravljanja ključev in deljenja. Ohranite identifikatorje računov in virov, identiteto akterja, časovne žige, dejanja in izide. Dnevnike zaščitite pred spreminjanjem in nepooblaščenim izbrisom. V dnevnike ne zapisujte občutljive vsebine ali ponovno uporabnih poverilnic; diagnostični podatki lahko postanejo nov vir izpostavljenosti.

Prednost dajte scenarijem zaznavanja, kot so:

• Omejena shramba postane javno dostopna.
• Novo zunanje zaupanje ali dodelitev privilegirane vloge.
• Nenavadni množični izvozi ali dostop prek neaktivne identitete.
• Beleženje je onemogočeno ali je spremenjen njegov cilj.
• Izbris varnostnih kopij ali spremembe pri upravljanju ključev.

Določite odzivnike in opozorila preizkusite z nadzorovano vajo. Pravilo, ki se sproži v nenadzorovan nabiralnik, ni učinkovit proces zaznavanja. Zabeležite napake pri zbiranju, zakasnjen zajem, na novo ustvarjene vire in omejitve ponudnika, namesto da nadzorno ploščo predstavite kot popolno pokritost.

Med incidentom ohranite ustrezne dokaze in uskladite zajezitev prek identitet, aplikacij in shrambe. Preklic enega žetona morda ne bo prekinil drugih sej ali ustavil izvoza, ki že poteka. Pri kršitvah varstva osebnih podatkov po GDPR obdelovalci upravljavce obvestijo brez nepotrebnega odlašanja. Upravljavci uradno obvestijo nadzorni organ brez nepotrebnega odlašanja in, kadar je izvedljivo, v 72 urah po seznanitvi, razen če ni verjetno, da bi kršitev ogrozila pravice in svoboščine posameznikov. Kršitve z velikim tveganjem zahtevajo tudi sporočilo prizadetim posameznikom brez nepotrebnega odlašanja, ob upoštevanju izjem iz 34. člena. Ohranite utemeljitev obveščanja ali neobveščanja.

Varnostna orodja uporabljajte za opredeljena vprašanja

Varnostna orodja za oblak so najuporabnejša, kadar sta njihov obseg in namen odločanja jasna:

Uveljavljanje DLP začnite z reprezentativnim testiranjem in pregledom s strani lastnikov podatkov. Pravilo, ki blokira zakonito delo podpore, lahko uporabnike potisne k nenadzorovanim obvodom. Skenerje in agente za spremljanje omejite na dostop, ki ga potrebujejo; orodje za odkrivanje s širokim bralnim dostopom samo postane občutljiva komponenta.

Avtomatizacija lahko zmanjša ponavljajoča se preverjanja in zbiranje dokazov. Ne more pa dokazati, da je nepodprta storitev varna ali da je pravna razlaga pravilna. Pri bistvenih ugotovitvah in izjemah naj človeški pregled ostane izrecen.

Obnovitev dokažite neodvisno od stanja varnostnih kopij

Varnostne kopije obravnavajo izgubo in poškodbe le, če jih je mogoče obnoviti v okviru potreb storitve. Z lastnikom poslovne storitve določite cilje točke obnovitve (RPO) za sprejemljivo izgubo podatkov in cilje časa obnovitve (RTO) za sprejemljivo prekinitev.

Razlikujte replikacijo, različice, posnetke stanja in varnostne kopije. Replikacija lahko prekopira poškodbe ali izbris. Posnetki stanja so lahko še vedno ranljivi za istega skrbnika, ki nadzoruje produkcijo. Izberite zaščitene kopije in administrativno ločenost, ki ustrezajo modelu groženj, vključno z odpornostjo proti izbrisu, kjer je podprta.

Reprezentativno delovno obremenitev obnovite v izolirano okolje. Preverite skladnost podatkov, odvisnosti aplikacije, konfiguracijo identitet, razpoložljivost ključev in pretečeni čas obnovitve. Sama obnovitev baze podatkov ne dokazuje, da poslovna storitev deluje. Zabeležite napake in po odpravi ponovno preizkusite.

Obnovitev storitev SaaS ocenite ločeno. Obnovitev ponudnika po katastrofi lahko obnovi platformo, ne da bi razveljavila nenamerni izbris v vašem najemniku. Ugotovite razpoložljivo zrnatost obnovitve, obdobja hrambe, možnosti izvoza in odgovornost za začetek obnovitve. Pravila razvrščanja in hrambe uporabite tudi za varnostne kopije.

Praktični primer: storitev za izvoz podatkov strank

Vzemimo ponazoritveno ekipo SaaS, ki uporablja upravljano bazo podatkov, objektno shrambo za izvoze in delovni proces v ozadju. Predpostavimo, da izvozi vsebujejo zaupne kontaktne podatke strank, da stranke dostopajo le do lastnih izvozov in da sta dogovorjena cilja obnovitve štiri ure izgube podatkov in osem ur prekinitve. To so predpostavke za primer, ne priporočeni splošni cilji.

Ponudnik upravlja upravljano infrastrukturo. Ekipa platforme konfigurira omrežne omejitve, identitete, šifriranje in beleženje. Razvijalci aplikacije so lastniki avtorizacije najemnikov in delovanja povezav za izvoz. Lastnik storitve odobri cilje hrambe in obnovitve; varnost pregleda dostop in dokaze.

Delovni proces prejme dovoljenje za branje potrebnih zapisov v bazi podatkov in zapisovanje izvozov v določeno shrambo. Ne potrebuje dovoljenja za spreminjanje politike shrambe ali brisanje varnostnih kopij. Prenosi gredo prek avtorizacije najemnika; morebitne začasne povezave imajo omejeno veljavnost in se obravnavajo kot nosilne poverilnice. Izvozne datoteke potečejo v skladu z odobrenim pravilom hrambe.

Testiranje vključuje neavtenticirano zahtevo za objekt, stranko, ki poskuša pridobiti izvoz druge stranke, in delovni proces, ki poskuša izvesti prepovedano administrativno dejanje. Pregledovalci preverijo tudi, ali je javni dostop blokiran in ali testni prenosi ustvarijo pričakovane revizijske dogodke.

Vaja obnovitve preveri bazo podatkov in odvisnosti aplikacije glede na predpostavljene cilje obnovitve. Dokazi vključujejo izvoze konfiguracije, rezultate testov avtorizacije, vzorčene dogodke dostopa in zapis o obnovitvi. Če v eni regiji manjka beleženje dostopa do podatkov, pregled to vrzel zabeleži in dodeli odpravo; uspešno testiranje drugod je ne zapre.

Ohranite obseg, izjeme in odločitve o pregledih

Dokazi naj navajajo račun, vir, čas, način zbiranja in pregledovalca. Izvoz konfiguracije iz enega računa ne more dokazati drže vseh računov. Zbrane vire primerjajte s popisom in zabeležite neuspešna zbiranja ali nedostopne lokacije.

Za vsako storitev vzdržujte jedrnat nabor dokazov: zemljevid odgovornosti, odobreno izhodišče, trenutna preverjanja konfiguracije, pregled dejanskega dostopa, pokritost beleženja, rezultate obnovitve in odprte izjeme. Vsaka izjema potrebuje lastnika, utemeljitev tveganja, nadomestne kontrole, odobritev, datum poteka in pogoj za ponovni preizkus.

Poleg rednih pregledov uporabljajte sprožilce na podlagi dogodkov. Bistvene spremembe namestitev, nove regije, menjave dobaviteljev, incidenti, spremenjene razvrstitve podatkov in nove poti deljenja naj sprožijo ponovno oceno. NIST Cybersecurity Framework je uporabna organizacijska referenca za funkcije Govern, Identify, Protect, Detect, Respond in Recover; gre za smernice, ne za dokaz, da namestitev izpolnjuje svoje obveznosti.

Secani lahko to delo poveže z zahtevami, ciljnimi objekti, dokazi, lastniki, nalogami in odločitvami o pregledih. Modelirajte storitev v oblaku in njene odvisnosti, izvoze konfiguracije in zapise o testih pripnite h kontrolam, ki jih podpirajo, manjkajočo pokritost pa spremenite v dodeljeno delo. Človeška odobritev in sledljivost do virov naj ostaneta izrecni. Varnostna orodja za oblak ostajajo vir tehnične konfiguracije in opozoril; delovni prostor za skladnost ohranja njihov obseg in ukrepe, ki jih podpirajo.

Za naslednji inženirski pregled izberite en občutljiv podatkovni tok. Sledite vsaki kopiji in poti dostopa, dodelite odgovornosti na strani stranke, preizkusite dejanska dovoljenja in obnovite reprezentativno delovno obremenitev. Obseg razširite, ko ta pregled ustvari zanesljive dokaze in ponovljiv proces.