Šifriranje in upravljanje ključev: preverite verigo zaščite

Šifriranje ščiti informacije ob določenih predpostavkah. Uporabna izvedba pojasni, kateri podatki so zaščiteni, pred kakšnim dostopom in kako ključi ostanejo pod nadzorom skozi ves svoj življenjski cikel. Nastavitev „šifriranje omogočeno“ odgovori le na majhen del tega vprašanja.

Za tehničnega direktorja (CTO) je inženirska naloga preveriti verigo zaščite: kje nastane golo besedilo, kam potuje, kje je shranjeno šifrirano besedilo, kdo lahko zahteva dešifriranje in kaj se zgodi ob napaki ali obnovi. Ta veriga vključuje aplikacije, identitete, oblačne storitve, skrbnike, varnostne kopije in operativne postopke.

Naslednja praktična priporočila ponujajo način za načrtovanje in pregled te verige. Začnite z eno shrambo občutljivih podatkov, nato isto metodo razširite na odvisne sisteme in sekundarne kopije.

Pred izbiro tehnologije opredelite cilj zaščite

Začnite z opisom grožnje, ne z algoritmom. „Zaščititi zapise strank“ je preširoko, da bi usmerjalo izvedbo. „Preprečiti, da bi oseba z ukradeno varnostno kopijo brez ločeno nadzorovanih ključev brala zapise strank“ opredeli sredstvo, zmožnost napadalca in mejo zaščite.

Različne grožnje zahtevajo različne kontrole. Šifriranje diska lahko zaščiti ukraden izklopljen prenosnik, vendar lahko overjen uporabnik ali zlonameren proces še vedno bere datoteke, medtem ko je disk odklenjen. Šifriranje zbirke podatkov lahko zaščiti pomnilniške medije, poizvedbe v zbirki podatkov pa še vedno vračajo golo besedilo. Šifriranje na aplikacijski ravni lahko omeji, kaj vidijo skrbniki zbirke podatkov, morda pa ne ščiti pred ogroženo aplikacijo z dovoljenjem za dešifriranje.

Te razlike naredite izrecne s kratkim popisom podatkovnih tokov. Vključite produkcijske zapise, naložene dokumente, predpomnilnike, čakalne vrste, analitične izvlečke, dnevnike, začasne datoteke, posnetke stanja in varnostne kopije. Odkrivanje podatkov mora prepoznati kopije, ki uidejo glavni arhitekturi shranjevanja, ne le sistemov na arhitekturnem diagramu.

Za vsak pomemben tok zabeležite:

• Kategorijo podatkov in njene potrebe po zaupnosti.
• Vir, cilj, vmesne storitve in meje golega besedila.
• Napadalca ali nepooblaščeno vlogo, ki naj bi jo šifriranje omejilo.
• Identiteto, ki sme dešifrirati, in razlog, zakaj potrebuje to dovoljenje.
• Zahteve glede razpoložljivosti, hrambe in obnove.
• Lastnika, odgovornega za izvedbo, in pregledovalca, odgovornega za dokazila.

Pristop modeliranja groženj pomaga preizkusiti, ali izbrana meja ustreza grožnji. Če lahko napadalec prevzame identiteto aplikacije, samo transparentno šifriranje shrambe ne bo preprečilo dostopa prek te aplikacije.

Rezultat je zemljevid zaščite: diagram podatkovnih tokov z izrecnimi predpostavkami in izjemami. Ta postane referenca za preverjanja konfiguracije, teste avtorizacije in vaje obnove.

Razumite, kaj kriptografski gradniki dejansko zagotavljajo

Šifriranje z uporabo kriptografskega algoritma in ključa pretvori golo besedilo v šifrirano besedilo. Njegova zaupnost je odvisna od konstrukcije, izvedbe, tajnosti ključa in okolja delovanja. Močan algoritem ne more nadomestiti ključa, shranjenega v repozitoriju izvorne kode, ali končne točke aplikacije, ki vrača zapise druge stranke.

Simetrična in asimetrična kriptografija imata različne naloge

Simetrično šifriranje za šifriranje in dešifriranje uporablja skupni tajni ključ. Pogosto se uporablja za velike količine podatkov, ker je učinkovito. AES podpira 128-, 192- in 256-bitne ključe, vendar oznaka velikosti ključa sama po sebi ne opisuje varne izvedbe: pomembni so tudi način delovanja, ravnanje z enkratnimi vrednostmi (nonce), overjanje in obnašanje knjižnice.

Asimetrična kriptografija uporablja povezana javni in zasebni ključ. Glede na algoritem in protokol podpira šifriranje, podpise ali dogovor o ključu. Konstrukcije RSA in eliptičnih krivulj imajo različne zmožnosti in parametre; niso zamenljive oznake. Asimetrična kriptografija sama po sebi ni „varnejša“ od simetričnega šifriranja.

Sodobni sistemi ju pogosto kombinirajo. Varen transportni protokol lahko overi nasprotno stran in vzpostavi skupne skrivnosti, nato pa za zaščito prometa uporabi simetrično šifriranje. Velike datoteke se običajno šifrirajo s simetričnimi podatkovnimi ključi, namesto da bi celotno datoteko neposredno obdelali z asimetričnim algoritmom.

Zaupnost ni isto kot celovitost ali pristnost

Overjeno šifriranje, na primer pravilno uporabljen AES-GCM, ščiti zaupnost in zazna nepooblaščene spremembe zaščitenega šifriranega besedila in povezanih podatkov. Ponovna uporaba enkratne vrednosti z istim ključem lahko to zaščito spodkoplje. Prednost dajte vzdrževanim knjižnicam in dobro podprtim formatom, ki te zahteve varno obravnavajo; ne izumljajte lastne šifre, načina delovanja ali protokola za izmenjavo ključev.

Zgoščevanje ustvari povzetek, ne šifriranega besedila, ki bi ga bilo mogoče obnoviti. Običajna zgoščena vrednost ne dokazuje, kdo je ustvaril sporočilo. Shranjevanje gesel zahteva namensko zgoščevanje gesel, ne reverzibilnega šifriranja ali zgolj hitrega splošnonamenskega povzetka.

Koda za overjanje sporočil (MAC) uporablja skrivnost za preverjanje celovitosti in pristnosti med stranmi, ki si to skrivnost delijo. Digitalni podpisi uporabljajo zasebni ključ za podpisovanje in javni ključ za preverjanje; podpisane vsebine ne naredijo zaupne.

Te razlike so pomembne pri pregledu. Vprašajte, katera lastnost je zahtevana in kateri mehanizem jo zagotavlja, namesto da „kriptografijo“ sprejmete kot enotno, nerazčlenjeno kontrolo.

Preverite vsako raven shranjevanja in vsako sekundarno kopijo

Šifriranje v mirovanju zajema shranjene informacije, vključno s podatki, ki jih aktivno uporablja delujoča storitev. Izraz ne pomeni le arhiviranih ali neaktivnih podatkov.

Različne ravni ščitijo pred različnimi potmi dostopa:

Preverite dejansko konfiguracijo virov, ne le privzete nastavitve računa. Privzeta nastavitev morda velja samo za na novo ustvarjeno shrambo. Obstoječi objekti, uvoženi nosilci, replike ali zgodovinski posnetki stanja lahko sledijo drugačnim nastavitvam.

Pri zbirkah podatkov preglejte transakcijske dnevnike, začasno shrambo, replike, izvoze in administrativne postopke izpisa. Pri objektni shrambi preverite nalaganja, kopije, cilje replikacije, objekte z različicami in poti za prenos. Pri končnih točkah preverite ravnanje s ključi za obnovo in ali so zajeti izmenljivi mediji.

Šifriranje na aplikacijski ravni si zasluži ločeno odločitev o zasnovi. Lahko zmanjša izpostavljenost upravljavcem zbirke podatkov ali zoži nabor delovnih obremenitev, ki lahko dešifrirajo izbrana polja. Lahko pa tudi oteži indeksiranje, iskanje, analitiko in delovne tokove podpore. Dokumentirajte, kje dešifrirane vrednosti vstopijo v pomnilnik, dnevnike, poročila o napakah ali izvoze.

Šifriranja ne obravnavajte kot nadomestka za avtorizacijo. Aplikacija lahko zapis pravilno dešifrira in ga kljub temu razkrije napačnemu najemniku. Izolacijo najemnikov, preverjanja dostopa in kontrole privilegiranega dostopa vključite v isti pregled.

Preverite prenos od prvega pošiljatelja do končnega prejemnika

Šifriranje pri prenosu ščiti podatke, ki se premikajo med končnimi točkami. Uporabno vprašanje ni „Ali uporabljamo HTTPS?“, temveč „Katere povezave so zaščitene in katere identitete so overjene?“

Preslikajte povezave od brskalnika do roba omrežja, od roba do aplikacije, med storitvami, od aplikacije do zbirke podatkov, replikacijo, prenos varnostnih kopij, administrativni dostop in izvozne povezave k tretjim osebam. Zaključevanje TLS na izravnalniku obremenitve ustvari mejo: naslednji skok zahteva lastno odločitev o zaščiti. Zasebno omrežje samodejno ne odpravi tveganj prestrezanja ali lateralnega premikanja.

Kot praktično izhodišče dajte prednost podprtim sodobnim konfiguracijam TLS in vzdrževanim odjemalskim knjižnicam. TLS 1.3 je, kjer je podprt, močna privzeta izbira; ustrezno konfiguriran TLS 1.2 bo morda zaradi združljivosti še vedno potreben. Zastareli SSL ni primerna sodobna varnostna izbira.

Preverjanje certifikatov je del zaščite. Preverite preverjanje imena gostitelja, shrambe zaupanja, spremljanje poteka veljavnosti, obnavljanje certifikatov in odsotnost produkcijskih nastavitev, ki onemogočajo preverjanje. Šifriranje proti neoverjeni končni točki lahko promet zaščiti pred pasivnim opazovanjem, a ga kljub temu pošlje napačni strani.

Vzajemni TLS (mTLS) lahko overi oba konca povezave, vendar ne nadomesti avtorizacije v aplikaciji. Izdajanje certifikatov, identiteta delovnih obremenitev, obnavljanje in preklic postanejo operativne odvisnosti, ki potrebujejo lastnike in teste.

Ločite šifriranje pri prenosu od šifriranja od konca do konca. Storitev, ki zaključi TLS in obdeluje golo besedilo, ne zagotavlja zaupnosti od konca do konca pred samo seboj. Zasnove od konca do konca dešifriranje pridržijo za določene končne točke; prinašajo ločena vprašanja o vpisu naprav, preverjanju prejemnikov, dostopu z več naprav in obnovi.

Dokazila morajo vključevati teste konfiguracije in povezav. Preizkusite zavrnitev neveljavnih certifikatov in prepovedanih različic protokolov, ne le ene uspešne šifrirane povezave.

Ključe upravljajte kot sredstva z življenjskim ciklom

Ključi zahtevajo generiranje, shranjevanje, pooblaščeno uporabo, zamenjavo, preklic, hrambo in uničenje. Vsaka faza mora imeti lastnika in opredeljen postopek.

Ključe generirajte in registrirajte premišljeno

Ključe generirajte z vzdrževanimi kriptografskimi orodji z ustrezno naključnostjo. Produkcijskih šifrirnih ključev ne izpeljujte iz zapomnljivih gesel, identifikatorjev, časovnih žigov ali običajnih aplikacijskih funkcij za naključna števila.

Vzdržujte popis ključev, ki vsebuje namen, lastnika, okolje, zaščitene sisteme, algoritem, identifikator ključa, datum nastanka, status in odvisnosti za obnovo. Beležite metapodatke, ne tajnega ključnega materiala. Ločite šifrirne ključe, ključe za podpisovanje, zasebne ključe TLS in poverilnice API, ker se njihova izpostavljenost in postopki zamenjave razlikujejo.

Produkcijo ločite od razvoja in testiranja. Deljenje ključa med okolji razširi vpliv okolja z nižjo stopnjo zaupanja in oteži razlago dnevnikov uporabe.

Nadzor nad ključi ločite od dostopa do podatkov

Storitev za upravljanje ključev (KMS) običajno zagotavlja nadzorovane operacije s ključi, politike dostopa, različice in zapise o uporabi. Strojni varnostni modul (HSM) zagotavlja strojno podprto mejo za kriptografske operacije in zaščito ključev. Storitve lahko te funkcije združujejo, vendar imena izdelkov ne določajo natančne varnostne meje.

Ugotovite, ali je ključe mogoče izvoziti, katere operacije potekajo znotraj meje, kdo upravlja politike in kako deluje obnova. Upravljane storitve ključev ali strojno zaščito izberite glede na tveganja in operativne zahteve, namesto da bi namensko strojno opremo obravnavali kot splošno nujno. HSM-ji ščitijo predvsem ključe in kriptografske operacije; niso splošnonamenski repozitoriji za vse šifrirane poslovne podatke.

Ovojnično šifriranje (envelope encryption) je pogost vzorec. Podatkovni šifrirni ključ šifrira vsebino, ključ za šifriranje ključev pa ščiti ta podatkovni ključ. Šifriran podatkovni ključ lahko spremlja šifrirano besedilo. Njegova varnost je odvisna od tega, da zmožnost njegovega odvijanja ostane ločeno nadzorovana, ne od skrivanja vsakega šifriranega ključa na drugem mestu.

Dešifriranje omejite na delovne obremenitve, ki ga potrebujejo. Kjer je izvedljivo, ločite upravljanje ključev od uporabe ključev in upravljanja shrambe. Preverite, ali si lahko skrbnik, ki trenutno ne more dešifrirati, to dovoljenje dodeli sam. Dostop v sili mora imeti izrecno odobritev, omejeno trajanje in revizijsko sled.

Rotacijo obravnavajte kot proces spremembe, ne kot kljukico

Kriptografska obdobja določite glede na občutljivost podatkov, izpostavljenost, omejitve algoritma, obseg uporabe in veljavne zahteve. Rotacija je primerna tudi po sumu ogroženosti ali bistveni spremembi zaupanja.

Razjasnite, kaj „rotacija“ pomeni v izbrani storitvi. Ustvarjanje nove različice ključa za prihodnje šifriranje lahko zgodovinske podatke pusti odvisne od starejših različic. Ponovno ovijanje podatkovnih ključev z novim ključem za šifriranje ključev se razlikuje od dešifriranja in ponovnega šifriranja osnovnih podatkov. Nobene od teh operacij ne smete domnevati na podlagi nastavitve samodejne rotacije.

Načrt rotacije mora opredeliti prizadete aplikacije, shranjene identifikatorje ključev, zgodovinske različice, postopno uvajanje, spremljanje napak, pogoje za povrnitev in končno upokojitev. Pred odstranitvijo starega dostopa preizkusite branje mešanih različic in dolgotrajna opravila.

Ločite preklic od uničenja

Preklic odstrani dovoljenje ali onemogoči prihodnjo uporabo ključa. Ne izbriše že pridobljenega golega besedila, ne razveljavi vsakega predpomnjenega podatkovnega ključa in ne odstrani izvožene skrivnosti.

Uničenje lahko hranjeno šifrirano besedilo naredi neobnovljivo, vendar le, če so obravnavane vse uporabne kopije in poti obnove. Upoštevajte replike, deponiranje (escrow), izvožen material, varnostne kopije in odvisnosti od deljenih ključev. Če si nepovezani zapisi delijo ključ, lahko njegovo uničenje uniči tudi dostop do podatkov, ki morajo ostati na voljo.

Zasnovo hrambe in izbrisa ohranite povezano. Hramba ključev za nedoločen čas lahko spodkoplje cilj izbrisa; prezgodnje uničenje lahko povzroči incident razpoložljivosti.

Oblačne modele ključev ocenite po njihovi dejanski meji nadzora

Šifriranje v oblaku lahko zmanjša delo pri izvedbi, vendar privzete nastavitve ponudnika ne določajo vašega modela groženj. Storitev, politiko ključev, administrativni dostop, regijo, model obnove in podporna dokazila ocenite skupaj.

Ključi, ki jih upravlja ponudnik, lahko ustrezajo nekaterim tveganjem z razmeroma majhnim operativnim bremenom. Ključi, ki jih upravlja stranka, lahko zagotovijo bolj izrecen nadzor nad politikami, lastništvo in odločitve o življenjskem ciklu. Zunanje hranjeni ključi lahko ustvarijo drugačno mejo zaupanja, hkrati pa uvedejo odvisnost od zunanje razpoložljivosti in povezljivosti.

Izrazi, kot so bring your own key, bring your own encryption in šifriranje kot storitev, niso enakovredna arhitekturna jamstva. Uvoz ključa v storitev ponudnika ne pomeni nujno, da ponudnik nikoli ne more izvesti dešifriranja. Uvedba šifriranja na strani odjemalca spremeni mejo golega besedila, lahko pa oteži funkcije aplikacije in obnovo.

Morebitnega ponudnika vprašajte:

• Ali lahko za vsak relevanten vir shranjevanja in varnostno kopijo ugotovimo, kateri ključ je uporabljen?
• Kdo lahko spreminja politike ključev in kako se te spremembe beležijo?
• Kaj se zgodi, ko je ključ onemogočen ali storitev ključev ni na voljo?
• Kako izvoz, replikacija, selitev in zaprtje računa vplivajo na zaščito?
• Kateri dogodki uporabe so na voljo in katera dejavnost je zunaj njihove vidnosti?

Zmogljivost ocenite z reprezentativnimi delovnimi obremenitvami: prepustnost, zakasnitev, kvote storitve ključev, obnašanje predpomnjenja in načini odpovedi. Storitev, ki deluje v majhni predstavitvi, lahko odpove med obsežno obnovo. Lokacija podatkov in lastništvo ključev pri stranki sta uporabna vhoda za zasnovo, ne dokaz suverenosti ali regulativne skladnosti.

Rešitev izberite z operativnim preizkusom

Kandidate primerjajte z zemljevidom zaščite, ne s seznamom imen algoritmov. Vključite vzdrževanje knjižnic, podprte platforme, administrativno ločevanje, razpoložljivost dokazil, možnosti selitve in zmožnost ekipe, da storitev upravlja. Če pogodba zahteva validiran kriptografski modul, ugotovite relevantni modul, različico, okolje delovanja in obseg validacije; sama oznaka AES te zahteve ne izpolni.

Praktičen preizkus naj šifrira reprezentativne podatke, izvede običajna branja, rotira ključ, obnovi starejšo kopijo in simulira nedosegljivo storitev ključev. Vključite obsežne uvoze in izvoze, ker se njihovo obnašanje lahko razlikuje od rutinskih zahtev aplikacije. Izmerite učinek na lastno zakasnitev aplikacije in cilje obnove, namesto da sprejmete splošno trditev o zmogljivosti.

Zabeležite izrecno odločitev o sprejemu: katere grožnje so obravnavane, katere odvisnosti so uvedene, kaj ostaja zunaj obsega in kdo je lastnik teh preostalih tveganj. Preizkusite tudi prenosljivost. Izvoženo šifrirano besedilo ima malo operativne vrednosti, če njegovega formata, ovitih ključev ali zahtevanih metapodatkov po koncu poslovnega razmerja ni mogoče razložiti.

Obnovo načrtujte skupaj z zaupnostjo

Za varnostno kopijo ugotovite tri stvari: podatki so šifrirani, pooblaščeno osebje za obnovo lahko pridobi zahtevane operacije s ključi in obnova uspe.

Edine poti obnove ne postavljajte znotraj iste meje odpovedi kot produkcijo. Zaklenjen račun, regionalna motnja ali administrativna napaka lahko prizadene tako varnostno kopijo kot njene ključe. Ločene ureditve za obnovo morajo ostati strogo nadzorovane; njihova neodvisnost jih ne sme narediti široko dostopnih.

Dokumentirajte različice ključev, ki jih potrebuje vsaka generacija varnostnih kopij, zahtevane identitete, korake odobritve, odvisnosti od ponudnika in omejitve za obnovljene podatke. Obnova v testno okolje ne sme razvijalcem tiho razkriti produkcijskih informacij.

Obnovo vadite v izoliranem okolju. Zabeležite, ali je bilo varnostno kopijo mogoče najti, ali so preverjanja celovitosti uspela, ali so zahtevani ključi ostali uporabni, ali so bili podatki aplikacije berljivi in ali je doseženi čas obnove izpolnil cilj organizacije. Vsi časovni podatki pripadajo dejanski vaji, ne domnevni koristi šifriranja.

Odpoved storitve ključev vključite v testiranje odpornosti. Odločite, ali naj delovna obremenitev ob napaki zapre dostop, poskusi znova ali uporabi odobren predpomnjen ključ. Predpomnjenje lahko izboljša razpoložljivost, vendar podaljša obdobje, v katerem lahko proces dešifrira, potem ko je osrednji dostop odstranjen. To kompromisno odločitev izrecno dokumentirajte.

Pripravite se na sum ogroženosti ključa

Odziv je odvisen od tega, kaj je bilo izpostavljeno. Uhajanje aplikacijske poverilnice z dovoljenjem za klicanje KMS se razlikuje od izvoženega šifrirnega ključa: odstranitev poverilnice lahko ustavi prihodnji dostop do storitve, medtem ko lahko napadalec, ki ima ključ in šifrirano besedilo, dešifrira neodvisno. Ogrožen ključ za podpisovanje povzroči drugačno težavo, ki zadeva zaupanje v podpise, ne zgolj zaupnost.

Pripravite operativni priročnik, ki opredeli odločevalca, prizadete identifikatorje ključev, odvisne sisteme, možnosti zajezitve in dokazila, ki jih je treba ohraniti. Raziščite spremembe politik, nenavadne operacije s ključi, prenose podatkov, dostop aplikacij in možno obdobje izpostavljenosti. Manjkajoči dogodki v dnevnikih niso dokaz, da do dešifriranja ni prišlo, zlasti kadar je ključe mogoče izvoziti ali predpomniti.

Zajezitev lahko vključuje onemogočanje identitete, zožitev politike, izolacijo delovne obremenitve ali onemogočanje ključa. Pred nepovratnim dejanjem ocenite posledice za razpoložljivost. Edinega ključa za obnovo ne uničite kot improviziran korak zajezitve.

Po zajezitvi ugotovite, katere podatke je treba preseliti na neogrožene ključe. Rotacija ovojnega ključa ne zadošča, če je napadalec pridobil osnovne podatkovne ključe. Ponovno šifriranje hranjenih podatkov lahko zaščiti prihodnje kopije, ne more pa preklicati šifriranega besedila in ključev, ki so bili ukradeni skupaj. Podobno zamenjava ogrožene identitete aplikacije brez odprave njene napake v avtorizaciji pusti prvotno pot razkritja odprto.

Ohranite časovnico incidenta, oceno prizadetih podatkov, zapise o zamenjavi in potrditvi ter preostale negotovosti. Kadar gre za osebne podatke, obveznosti obveščanja ocenite ločeno; „zbirka podatkov je bila šifrirana“ ne odgovori na vprašanje, ali je napadalec lahko pridobil golo besedilo ali uporabne ključe.

Zgradite dokazila, ki preizkušajo verigo

Politika opisuje nameravano obnašanje. Dokazila morajo pokazati, da ji izvedba sledi in da se pomembne poti odpovedi obnašajo, kot je pričakovano.

Izvoze konfiguracije, preglede politik, teste dostopa, dnevnike uporabe ključev, preverjanja uvajanja in zapise o obnovi uporabljajte skupaj. Posnetki zaslona lahko podprejo pregled, vendar sami redko pojasnijo obseg, zgodovinsko obnašanje ali odstopanja.

Pokritost beleženja razlagajte previdno. Pri ovojničnem šifriranju in predpomnjenih podatkovnih ključih lahko ena operacija storitve ključev omogoči več poznejših lokalnih dešifriranj. Dnevnik KMS zato ni nujno popoln zapis vsakega dostopa do golega besedila. Kjer je primerno, ga povežite z zapisi o avtorizaciji v aplikaciji in dostopu do podatkov.

Iz paketov dokazil odstranite skrivnosti. Nikoli ne nalagajte surovih ključev, fraz za obnovo, aktivnih poverilnic ali nepotrebnih zapisov z golim besedilom. Ohranite identifikator vira, časovni žig, obseg, pregledovalca, rezultat testa in relevantno konfiguracijo, ne da bi ustvarili novo izpostavljenost.

Izjeme morajo navajati prizadeti sistem, razlog, nadomestne kontrole, lastnika, iztek in nalogo odprave. Začasna izjema za zastarel prenos potrebuje odločitev in načrt izstopa, ne trajne opombe v preglednici.

Kot praktično priporočilo ponovite ciljna preverjanja po spremembah shrambe, identitet delovnih obremenitev, politik ključev, certifikatov ali ciljev varnostnih kopij. Načrtovani pregledi ostajajo koristni, vendar lahko uvajanje spremeni mejo zaščite pred naslednjim koledarskim pregledom. Samodejna preverjanja morajo sprožiti ugotovitve, na podlagi katerih je mogoče ukrepati, s kontekstom vira in lastnikom, medtem ko človeški pregledovalci ocenjujejo izjeme in spremembe modela groženj.

Praktični primer: izsledite storitev za dokumente strank

Predpostavimo ponazoritveno storitev SaaS, ki zaupne dokumente strank hrani v objektni shrambi. Njena aplikacija pridobiva dokumente za overjene uporabnike, dnevne varnostne kopije pa podpirajo poslovno določen cilj obnove. Pregledane grožnje so ukradene kopije shrambe, nepooblaščen administrativni dostop in razkritje med najemniki.

Ekipa preslika TLS od brskalnika do roba, TLS od roba do aplikacije, povezave od aplikacije do shrambe, produkcijsko vedro in ločen cilj varnostnih kopij. Odkrije, da opravilo izvoza za odpravljanje težav zapisuje dešifrirane datoteke v mapo podpore. Ta mapa takoj postane del obsega; nastavitev šifriranja produkcijskega vedra je ne zajema.

V začetni zasnovi šifriranje shrambe s ključem, ki ga upravlja stranka, ščiti produkcijske objekte. Identiteta aplikacije lahko pridobiva pooblaščene objekte in kliče potrebne operacije s ključi. Vloga za uvajanje lahko ustvarja vire, nima pa rutinskega dovoljenja za dešifriranje. Upravljanje politik ključev sledi ločeni poti odobritve.

Ekipa prepozna preostalo mejo: ogroženost aplikacije bi še vedno lahko omogočila pridobitev golega besedila. Za posebej občutljivo kategorijo dokumentov razmisli o šifriranju na aplikacijski ravni, nato oceni zahteve iskanja, dostop podpore in zapletenost obnove, preden odloči, ali je dodatna meja upravičena.

Preverjanje da konkretne rezultate:

• Nepooblaščena identiteta storitve ne more pridobiti ali dešifrirati dokumenta.
• Aplikacija zavrne overjenega uporabnika drugega najemnika.
• Neveljavni certifikati na predhodnih povezavah so zavrnjeni, ne zaobideni.
• Starejša varnostna kopija se uspešno obnovi z zahtevano zgodovinsko različico ključa.
• Postopna sprememba ključa omogoča branje obstoječih dokumentov in novih nalaganj.
• Opravilo izvoza za podporo je spremenjeno tako, da uporablja odobren, z dostopom nadzorovan šifriran cilj z opredeljeno hrambo.

Pregledovalec ohrani zemljevid podatkovnih tokov, izvoze konfiguracije, politike identitet, anonimizirane rezultate negativnih testov, zapis o rotaciji in poročilo o obnovi. Vaja onemogočanja ključa v neprodukcijskem okolju potrdi, da storitev vrne nadzorovano napako, namesto da bi razkrila podatke ali tiho zavrgla zapise.

Ta primer ne dokazuje zaščite pred vsakim napadom. Dokazuje, katere grožnje zasnova obravnava, katera identiteta ostaja zaupanja vredna in katera dokazila podpirajo te sklepe.

Pravne zahteve in prihodnje spremembe povežite z zasnovo

Odločitve o šifriranju morajo odražati pravne, pogodbene zahteve in zahteve okvirov, ne da bi jih spremenile v splošne trditve. Člen 32 Splošne uredbe o varstvu podatkov (GDPR) uporablja pristop na podlagi tveganj in šifriranje navaja med ustreznimi ukrepi; ne nalaga univerzalne obveznosti šifriranja za vsako dejavnost obdelave. Šifriranje tudi ne odpravi dolžnosti glede zakonite obdelave, dostopa, hrambe ali ocene incidentov.

V okviru ISMS po ISO 27001 z opredeljenim obsegom dokumentirajte obravnavo tveganj, veljavne kontrole, lastništvo in dokazila, namesto da domnevate, da ena šifrirana zbirka podatkov izpolnjuje širši sistem upravljanja. Kadar se NIS2 uporablja prek nacionalne zakonodaje, njeni ukrepi iz člena 21 vključujejo politike in postopke v zvezi s kriptografijo in, kjer je ustrezno, šifriranjem. Uporabnost in nacionalne zahteve potrdite ločeno.

Kriptografske spremembe načrtujte kot inženirsko odvisnost. Popišite algoritme, certifikate, knjižnice, protokole in vgrajene formate, da je zastarele mehanizme mogoče zamenjati. Pri dolgo hranjenih zaupnih podatkih ocenite pomen prihodnjih kriptoanalitičnih in kvantnih groženj. Vprašanja postkvantne selitve se razlikujejo pri vzpostavljanju ključev, podpisih in simetričnem šifriranju; izogibajte se nepreizkušeni celoviti zamenjavi, predstavljeni kot univerzalna rešitev.

Naslednji pregled naj bo konkreten

Secani lahko pri tem delu poveže ciljne sisteme, zahteve kontrol, opise izvedbe, dokazila, lastnike in odločitve pregledov. Zemljevid zaščite in anonimizirane zapise testov priložite relevantnim sistemom in kontrolam, odprta vprašanja o dostopu do ključev ali obnovi spremenite v naloge in ohranite utemeljitev, zakaj je bila posamezna kriptografska izbira odobrena. Predloge, pripravljene s pomočjo UI, preverite glede na njihove vire in človeško odobritev ohranite izrecno.

Začnite z eno shrambo občutljivih podatkov in skupaj izsledite dostop do podatkov, dostop do ključev in obnovo. Izberite en negativni test avtorizacije in eno vajo obnove, določite lastnike in zabeležite rezultate, preden razširite obseg. Naš vodnik po varnosti v oblaku ponuja širši konfiguracijski kontekst.