
Krüpteerimine kaitseb teavet kindlate eelduste korral. Kasulik rakendus selgitab, milliseid andmeid kaitstakse, millise juurdepääsu eest ja kuidas võtmed jäävad kogu elutsükli vältel kontrolli alla. Seadistus „krüpteerimine sisse lülitatud“ vastab sellele küsimusele vaid väikeses osas.
CTO jaoks on insenertehniline ülesanne kontrollida kaitseahelat: kus avatekst tekib, kuhu see liigub, kus salvestatakse šifritekst, kes saab taotleda dekrüpteerimist ja mis juhtub tõrke või taastamise korral. See ahel hõlmab rakendusi, identiteete, pilveteenuseid, administraatoreid, varukoopiaid ja tööprotseduure.
Järgmised praktilised soovitused annavad viisi selle ahela kavandamiseks ja ülevaatamiseks. Alustage ühest tundlikust andmehoidlast ja laiendage sama meetodit seejärel sellest sõltuvatele süsteemidele ja teisestele koopiatele.
Alustage ohukirjeldusest, mitte algoritmist. „Kaitsta kliendikirjeid“ on rakendamise suunamiseks liiga lai. „Takistada varastatud varukoopia valdajal kliendikirjeid lugemast ilma eraldi kontrollitavate võtmeteta“ määrab vara, ründaja võimekuse ja kaitsepiiri.
Eri ohud nõuavad eri kontrollimeetmeid. Ketta krüpteerimine võib kaitsta varastatud väljalülitatud sülearvutit, kuid autenditud kasutaja või pahatahtlik protsess võib faile siiski lugeda, kui ketas on lukust lahti. Andmebaasi krüpteerimine võib kaitsta andmekandjaid, võimaldades samal ajal andmebaasipäringutel avateksti tagastada. Rakenduskihi krüpteerimine võib piirata seda, mida andmebaasiadministraatorid näevad, kuid see ei pruugi kaitsta kompromiteeritud rakenduse eest, millel on õigus dekrüpteerida.
Kasutage lühikest andmevoogude inventari, et need erinevused selgeks teha. Kaasake tootmiskirjed, üleslaaditud dokumendid, vahemälud, järjekorrad, analüütikaväljavõtted, logid, ajutised failid, hetktõmmised ja varukoopiad. Andmete tuvastamine peaks leidma koopiad, mis väljuvad peamisest salvestusarhitektuurist, mitte ainult arhitektuuriskeemil olevad süsteemid.
Pange iga olulise voo kohta kirja:
Ohumodelleerimise lähenemisviis aitab kontrollida, kas valitud piir vastab ohule. Kui ründaja saab üle võtta rakenduse identiteedi, ei takista läbipaistev salvestuskrüpteerimine üksi juurdepääsu selle rakenduse kaudu.
Tulemus on kaitsekaart: andmevoo skeem koos selgesõnaliste eelduste ja eranditega. Sellest saab konfiguratsioonikontrollide, autoriseerimistestide ja taastamisharjutuste lähtealus.
Krüpteerimine muudab avateksti krüptoalgoritmi ja võtme abil šifritekstiks. Selle konfidentsiaalsus sõltub konstruktsioonist, rakendusest, võtme salajasusest ja töökeskkonnast. Tugev algoritm ei suuda kompenseerida lähtekoodi hoidlasse lisatud võtit ega rakenduse otspunkti, mis tagastab teise kliendi kirjeid.
Sümmeetriline krüpteerimine kasutab krüpteerimiseks ja dekrüpteerimiseks jagatud salajast võtit. Seda kasutatakse tavaliselt suurte andmemahtude puhul, sest see on tõhus. AES toetab 128-, 192- ja 256-bitiseid võtmeid, kuid võtme pikkuse silt üksi ei kirjelda turvalist rakendust: olulised on ka režiim, nonsside käsitlemine, autentimine ja teegi käitumine.
Asümmeetriline krüptograafia kasutab omavahel seotud avalikke ja privaatvõtmeid. Olenevalt algoritmist ja protokollist toetab see krüpteerimist, allkirju või võtmekokkulepet. RSA ja elliptkõverate konstruktsioonidel on erinevad võimalused ja parameetrid; need ei ole omavahel vahetatavad sildid. Asümmeetriline krüptograafia ei ole olemuslikult „turvalisem“ kui sümmeetriline krüpteerimine.
Kaasaegsed süsteemid kombineerivad neid sageli. Turvaline transpordiprotokoll võib autentida osapoole ja luua jagatud saladused ning seejärel kasutada liikluse kaitsmiseks sümmeetrilist krüpteerimist. Suured failid krüpteeritakse tavaliselt sümmeetriliste andmevõtmetega, mitte nii, et kogu faili töödeldaks otse asümmeetrilise algoritmiga.
Autenditud krüpteerimine, näiteks õigesti kasutatud AES-GCM, kaitseb konfidentsiaalsust ja tuvastab kaitstud šifriteksti ning seotud andmete volitamata muudatused. Nonsi korduskasutamine sama võtmega võib selle kaitse õõnestada. Eelistage hooldatud teeke ja hästi toetatud vorminguid, mis neid nõudeid turvaliselt käsitlevad; ärge leiutage ise šifrit, režiimi ega võtmevahetusprotokolli.
Räsimine annab tulemuseks räsi, mitte taastatava šifriteksti. Tavaline räsi ei tõenda, kes sõnumi lõi. Paroolide salvestamine vajab selleks loodud paroolide räsimist, mitte pööratavat krüpteerimist ega üksnes kiiret üldotstarbelist räsifunktsiooni.
Sõnumi autentimiskood kasutab saladust, et kontrollida tervikust ja autentsust seda saladust jagavate osapoolte vahel. Digiallkirjad kasutavad privaatset allkirjavõtit ja avalikku kontrollvõtit; need ei muuda allkirjastatud sisu konfidentsiaalseks.
Need erinevused on ülevaatuse ajal olulised. Küsige, milline omadus on nõutav ja milline mehhanism seda pakub, selle asemel et aktsepteerida „krüptograafiat“ ühe eristamata kontrollimeetmena.
Salvestatud andmete krüpteerimine hõlmab salvestatud teavet, sealhulgas töötava teenuse poolt aktiivselt kasutatavaid andmeid. See väljend ei tähenda ainult arhiveeritud või passiivseid andmeid.
Eri kihid kaitsevad eri juurdepääsuteede eest:
| Kiht | Tüüpiline kaitsepiir | Oluline piirang, mida kontrollida |
|---|---|---|
| Kogu ketta või köite krüpteerimine | Kadunud seadmed või paljastatud andmekandjad | Lukust lahti olev operatsioonisüsteem saab andmeid tavaliselt lugeda |
| Andmebaasi või salvestusteenuse krüpteerimine | Aluseks olevad failid, kettad või salvestustaristu | Volitatud päringud või objektide lugemised võivad tagastada avateksti |
| Rakenduse või välja tasandi krüpteerimine | Valitud sisu enne andmebaasi salvestamist | Rakenduse dekrüpteerimisõigused jäävad kriitiliseks piiriks |
| Kliendipoolne või otspunktkrüpteerimine | Sisu, mis krüpteeritakse enne vahendajani jõudmist | Otspunkti kompromiteerimine ja võtmete taastamine vajavad endiselt kavandamist |
Kontrollige ressursi tegelikku konfiguratsiooni, mitte ainult konto vaikeseadet. Vaikeseade võib kehtida ainult uutele salvestusressurssidele. Olemasolevad objektid, imporditud köited, koopiad või ajaloolised hetktõmmised võivad järgida teistsuguseid seadistusi.
Andmebaaside puhul uurige tehingulogisid, ajutist salvestust, koopiaid, eksporte ja haldusliku tõmmise protseduure. Objektisalvestuse puhul kontrollige üleslaadimisi, koopiaid, replikatsiooni sihtkohti, versioonitud objekte ja allalaadimisteid. Lõppseadmete puhul kontrollige taastevõtmete käsitlemist ja seda, kas teisaldatavad andmekandjad on kaetud.
Rakenduskihi krüpteerimine väärib eraldi kavandamisotsust. See võib vähendada kokkupuudet andmebaasi käitajatega või kitsendada seda, millised töökoormused saavad valitud välju dekrüpteerida. See võib ka keerulisemaks muuta indekseerimist, otsingut, analüütikat ja tugiteenuste töövooge. Dokumenteerige, kus dekrüpteeritud väärtused jõuavad mällu, logidesse, veaaruannetesse või eksportidesse.
Ärge käsitlege krüpteerimist autoriseerimise asendajana. Rakendus võib kirje õigesti dekrüpteerida ja selle siiski valele rentnikule avaldada. Hoidke rentnike isoleerimine, juurdepääsukontrollid ja privilegeeritud juurdepääsu kontrollimeetmed samas ülevaatuses.
Edastuskrüpteerimine kaitseb otspunktide vahel liikuvaid andmeid. Kasulik küsimus ei ole „Kas me kasutame HTTPS-i?“, vaid „Millised ühendused on kaitstud ja millised identiteedid on autenditud?“
Kaardistage ühendused brauserist servani, servast rakenduseni, teenuselt teenusele, rakendusest andmebaasini, replikatsioon, varukoopiate edastamine, haldusjuurdepääs ja eksportühendused kolmandatele osapooltele. TLS-i lõpetamine koormusejaoturil loob piiri: järgmine samm vajab oma kaitseotsust. Privaatvõrk ei kõrvalda automaatselt pealtkuulamise ega külgsuunalise liikumise riske.
Praktilise lähtealusena eelistage toetatud kaasaegseid TLS-i konfiguratsioone ja hooldatud klienditeeke. TLS 1.3 on tugev vaikevalik, kus seda toetatakse; asjakohaselt konfigureeritud TLS 1.2 võib ühilduvuse tõttu jääda vajalikuks. Pärandprotokoll SSL ei ole sobiv kaasaegne turvavalik.
Sertifikaatide valideerimine on kaitse osa. Kontrollige hostinime kontrollimist, usaldushoidlaid, aegumise seiret, sertifikaatide uuendamist ja seda, et tootmises puuduksid valideerimise väljalülitavad seadistused. Krüpteerimine autentimata otspunktini võib kaitsta liiklust passiivse jälgimise eest, saates selle samal ajal valele osapoolele.
Vastastikune TLS võib autentida ühenduse mõlemad otsad, kuid see ei asenda rakenduse autoriseerimist. Sertifikaatide väljastamine, töökoormuse identiteet, uuendamine ja tühistamine muutuvad operatiivseteks sõltuvusteks, mis vajavad omanikke ja teste.
Eristage edastuskrüpteerimist otspunktkrüpteerimisest. Teenus, mis lõpetab TLS-i ja töötleb avateksti, ei paku otspunktidevahelist konfidentsiaalsust iseenda eest. Otspunktkrüpteerimisega lahendustes on dekrüpteerimine reserveeritud määratud otspunktidele; need toovad kaasa eraldi küsimused seadmete registreerimise, saaja kontrollimise, mitme seadme juurdepääsu ja taastamise kohta.
Tõendid peaksid sisaldama konfiguratsiooni- ja ühendusteste. Katsetage kehtetute sertifikaatide ja keelatud protokolliversioonide tagasilükkamist, mitte ainult ühte õnnestunud krüpteeritud ühendust.
Võtmeid tuleb genereerida, salvestada, volitatult kasutada, asendada, tühistada, säilitada ja hävitada. Igal etapil peaks olema omanik ja määratletud protseduur.
Genereerige võtmed hooldatud krüptograafiliste vahenditega, millel on sobiv juhuslikkus. Ärge tuletage tootmise krüpteerimisvõtmeid meeldejäävatest paroolidest, identifikaatoritest, ajatemplitest ega rakenduste tavalistest juhuarvufunktsioonidest.
Pidage võtmete inventari, mis sisaldab eesmärki, omanikku, keskkonda, kaitstud süsteeme, algoritmi, võtme identifikaatorit, loomise kuupäeva, olekut ja taastamissõltuvusi. Salvestage metaandmed, mitte salajane võtmematerjal. Eristage krüpteerimisvõtmeid, allkirjavõtmeid, TLS-i privaatvõtmeid ja API volitusi, sest nende paljastumise ja asendamise protseduurid erinevad.
Eraldage tootmine arendusest ja testimisest. Võtme jagamine keskkondade vahel laiendab madalama usaldusega keskkonna mõju ja muudab kasutuslogide tõlgendamise keerulisemaks.
Võtmehaldusteenus ehk KMS pakub tavaliselt juhitud võtmetoiminguid, juurdepääsupoliitikaid, versioonimist ja kasutuskirjeid. Riistvaraline turvamoodul ehk HSM pakub riistvarapõhist piiri krüptograafilistele toimingutele ja võtmete kaitsele. Teenused võivad neid funktsioone kombineerida, kuid tootenimed ei määra täpset turvapiiri.
Tehke kindlaks, kas võtmed on eksporditavad, millised toimingud toimuvad piiri sees, kes haldab poliitikaid ja kuidas taastamine toimib. Valige hallatud võtmeteenused või riistvaraline kaitse vastavalt riskile ja tegevusnõuetele, mitte käsitledes spetsiaalset riistvara üldiselt vajalikuna. HSM-id kaitsevad peamiselt võtmeid ja krüptograafilisi toiminguid; need ei ole üldotstarbelised hoidlad kõigi krüpteeritud äriandmete jaoks.
Ümbrikkrüpteerimine on levinud muster. Andmete krüpteerimisvõti krüpteerib sisu ja võtme krüpteerimisvõti kaitseb seda andmevõtit. Krüpteeritud andmevõti võib olla šifriteksti juures. Selle turvalisus sõltub sellest, et selle lahtipakkimise võimekus on eraldi kontrolli all, mitte sellest, et iga krüpteeritud võtmeplokk oleks peidetud teise kohta.
Piirake dekrüpteerimist töökoormustega, mis seda vajavad. Kus võimalik, eraldage võtmete haldamine võtmete kasutamisest ja salvestuse haldamisest. Vaadake üle, kas administraator, kes praegu dekrüpteerida ei saa, saab endale selle õiguse anda. Hädaolukorra juurdepääsul peaks olema selgesõnaline heakskiit, piiratud kestus ja ülevaatusjälg.
Määrake krüptoperioodid vastavalt andmete tundlikkusele, kokkupuutele, algoritmi piirangutele, kasutusmahule ja kohaldatavatele nõuetele. Võtmevahetus on asjakohane ka pärast kahtlustatavat kompromiteerimist või usalduse olulist muutust.
Selgitage, mida „võtmevahetus“ valitud teenuses teeb. Uue võtmeversiooni loomine tulevaseks krüpteerimiseks võib jätta ajaloolised andmed vanematest versioonidest sõltuvaks. Andmevõtmete ümberpakkimine uue võtme krüpteerimisvõtmega erineb aluseks olevate andmete dekrüpteerimisest ja uuesti krüpteerimisest. Kumbagi toimingut ei tohiks automaatse võtmevahetuse seadistusest eeldada.
Võtmevahetuse plaan peaks tuvastama mõjutatud rakendused, salvestatud võtmeidentifikaatorid, ajaloolised versioonid, järkjärgulise kasutuselevõtu, tõrgete seire, tagasipööramise tingimused ja lõpliku kasutusest kõrvaldamise. Katsetage segaversioonidega lugemisi ja pikaajalisi töid enne vana juurdepääsu eemaldamist.
Tühistamine eemaldab õiguse või keelab võtme edasise kasutamise. See ei kustuta juba hangitud avateksti, ei muuda kehtetuks iga vahemällu salvestatud andmevõtit ega pane eksporditud saladust kaduma.
Hävitamine võib muuta säilitatud šifriteksti taastamatuks, kuid ainult siis, kui kõik kasutatavad koopiad ja taastamisteed on käsitletud. Arvestage koopiaid, deponeerimist, eksporditud materjali, varukoopiaid ja jagatud võtmetest tulenevaid sõltuvusi. Kui omavahel mitteseotud kirjed jagavad võtit, võib selle hävitamine hävitada ka juurdepääsu andmetele, mis peavad jääma kättesaadavaks.
Hoidke säilitamise ja kustutamise kavandamine omavahel seotuna. Võtmete tähtajatu säilitamine võib kustutamise eesmärki õõnestada; enneaegne hävitamine võib põhjustada käideldavusintsidendi.
Pilvekrüpteerimine võib vähendada rakendamise töömahtu, kuid teenusepakkuja vaikeseaded ei otsusta teie ohumudeli üle. Hinnake teenust, võtmepoliitikat, haldusjuurdepääsu, piirkonda, taastamismudelit ja toetavaid tõendeid koos.
Teenusepakkuja hallatavad võtmed võivad mõne riski puhul sobida suhteliselt väikese operatiivse koormusega. Kliendi hallatavad võtmed võivad pakkuda selgesõnalisemat poliitikakontrolli, omandit ja elutsükli otsuseid. Väliselt hoitavad võtmed võivad luua teistsuguse usalduspiiri, tuues samal ajal kaasa sõltuvuse välisest käideldavusest ja ühenduvusest.
Mõisted nagu „too oma võti“ (bring your own key), „too oma krüpteerimine“ (bring your own encryption) ja „krüpteerimine teenusena“ (encryption as a service) ei ole samaväärsed arhitektuursed garantiid. Võtme importimine teenusepakkuja teenusesse ei tähenda tingimata, et teenusepakkuja ei saa kunagi dekrüpteerida. Kliendipoolse krüpteerimise kasutuselevõtt muudab avateksti piiri, kuid võib keerulisemaks muuta rakenduse funktsioone ja taastamist.
Küsige kaalutavalt teenusepakkujalt:
Hinnake jõudlust esinduslike töökoormustega: läbilaskevõime, latentsus, võtmeteenuse kvoodid, vahemälu käitumine ja tõrkerežiimid. Teenus, mis töötab väikeses demos, võib ebaõnnestuda suures mahus taastamisel. Andmete asukoht ja kliendi võtmeomand on kasulikud kavandamise sisendid, mitte suveräänsuse ega regulatiivse vastavuse tõend.
Võrrelge kandidaate kaitsekaardi, mitte algoritmide nimede loendi alusel. Kaasake teekide hooldus, toetatud platvormid, halduslik eraldatus, tõendite kättesaadavus, migratsioonivõimalused ja meeskonna võime teenust käitada. Kui leping nõuab valideeritud krüptomoodulit, tehke kindlaks asjakohane moodul, versioon, töökeskkond ja valideerimise ulatus; AES-i silt üksi ei tõenda selle nõude täitmist.
Praktiline katsetus peaks krüpteerima esinduslikke andmeid, läbima tavapärased lugemised, vahetama võtme, taastama vanema koopia ja simuleerima võtmeteenuse kättesaamatust. Kaasake suured impordid ja ekspordid, sest nende käitumine võib erineda rakenduse tavapärastest päringutest. Mõõtke mõju rakenduse enda latentsusele ja taastamiseesmärkidele, selle asemel et aktsepteerida üldist jõudlusväidet.
Salvestage selgesõnaline vastuvõtuotsus: milliseid ohte käsitletakse, millised sõltuvused lisanduvad, mis jääb ulatusest välja ja kes neid jääkriske omab. Katsetage ka ülekantavust. Eksporditud šifritekstil on vähe operatiivset väärtust, kui selle vormingut, pakitud võtmeid või nõutavaid metaandmeid ei saa pärast teenussuhte lõppu tõlgendada.
Varukoopia puhul tehke kindlaks kolm asja: andmed on krüpteeritud, volitatud taastamistöötajad saavad nõutavad võtmetoimingud kätte ja taastamine õnnestub.
Ärge paigutage ainsat taastamisteed tootmisega samasse tõrkepiiri. Konto lukustumine, piirkondlik häire või halduslik viga võib mõjutada nii varukoopiat kui ka selle võtmeid. Eraldi taastamiskorraldused peaksid jääma rangelt kontrollituks; nende sõltumatuks muutmine ei tohi muuta neid laialdaselt kättesaadavaks.
Dokumenteerige iga varukoopiapõlvkonna jaoks vajalikud võtmeversioonid, nõutavad identiteedid, heakskiidusammud, teenusepakkuja sõltuvused ja taastatud andmetele kehtivad piirangud. Taastamine testkeskkonda ei tohiks vaikselt paljastada tootmisteavet arendajatele.
Harjutage taastamist isoleeritud keskkonnas. Pange kirja, kas varukoopia leiti, kas tervikluskontrollid läbiti, kas nõutavad võtmed jäid kasutatavaks, kas rakenduse andmed olid loetavad ja kas saavutatud taasteaeg vastas organisatsiooni eesmärgile. Kõik ajanäitajad kuuluvad tegelikule harjutusele, mitte krüpteerimise eeldatavale kasule.
Kaasake võtmeteenuse tõrge vastupidavuse testimisse. Otsustage, kas töökoormus peaks ebaõnnestuma suletult, proovima uuesti või kasutama heakskiidetud vahemällu salvestatud võtit. Vahemälu võib parandada käideldavust, kuid pikendab perioodi, mille jooksul protsess saab pärast keskse juurdepääsu eemaldamist dekrüpteerida. Dokumenteerige see kompromiss selgesõnaliselt.
Reageerimine sõltub sellest, mis paljastus. Lekkinud rakenduse volitus, millel on õigus KMS-i kutsuda, erineb eksporditud krüpteerimisvõtmest: volituse eemaldamine võib peatada edasise juurdepääsu teenusele, samas kui võtit ja šifriteksti valdav ründaja võib dekrüpteerida iseseisvalt. Kompromiteeritud allkirjavõti tekitab teistsuguse probleemi, mis puudutab usaldust allkirjade vastu, mitte lihtsalt konfidentsiaalsust.
Valmistage ette tegevusjuhend, mis määrab otsustaja, mõjutatud võtmeidentifikaatorid, sõltuvad süsteemid, ohjeldamisvõimalused ja säilitatavad tõendid. Uurige poliitikamuudatusi, ebatavalisi võtmetoiminguid, andmete allalaadimisi, rakenduse juurdepääsu ja võimalikku kokkupuuteakent. Puuduvad logisündmused ei tõenda, et dekrüpteerimist ei toimunud, eriti kui võtmeid saab eksportida või vahemällu salvestada.
Ohjeldamine võib hõlmata identiteedi keelamist, poliitika kitsendamist, töökoormuse isoleerimist või võtme keelamist. Hinnake käideldavuse tagajärgi enne pöördumatut toimingut. Ärge hävitage ainsat taastevõtit improviseeritud ohjeldamissammuna.
Pärast ohjeldamist tehke kindlaks, milliseid andmeid on vaja migreerida kompromiteerimata võtmetele. Pakkimisvõtme vahetamisest ei piisa, kui ründaja sai aluseks olevad andmevõtmed. Säilitatud andmete uuesti krüpteerimine võib kaitsta tulevasi koopiaid, kuid see ei saa tagasi võtta šifriteksti ja võtmeid, mis on juba koos varastatud. Samamoodi jätab kompromiteeritud rakenduse identiteedi asendamine ilma selle autoriseerimisvea parandamiseta algse avalikustamistee avatuks.
Säilitage intsidendi ajajoon, mõjutatud andmete hinnang, asendamise ja valideerimise kirjed ning allesjäävad ebakindlused. Kui tegemist on isikuandmetega, hinnake teavitamiskohustusi eraldi; „andmebaas oli krüpteeritud“ ei vasta küsimusele, kas ründaja võis saada avateksti või kasutatavad võtmed.
Poliitika kirjeldab kavandatud käitumist. Tõendid peaksid näitama, et rakendus järgib seda ja et olulised tõrketeed käituvad ootuspäraselt.
Kasutage koos konfiguratsiooni eksporte, poliitikate ülevaatusi, juurdepääsuteste, võtmekasutuse logisid, juurutuskontrolle ja taastamiskirjeid. Ekraanipildid võivad ülevaatust toetada, kuid harva selgitavad nad üksi ulatust, ajaloolist käitumist või triivi.
| Ülevaatuse küsimus | Kasulikud tõendid | Test, mida tasub teha |
|---|---|---|
| Kas tundlikud hoidlad on kaetud? | Ressursside inventar ja krüpteerimise konfiguratsioon | Kontrollige pärandressursse ja uute ressursside juurutamist |
| Kas dekrüpteerimine on piiratud? | Töökoormuste identiteedid ja võtmepoliitikad | Keelake juurdepääs volitamata identiteedile ja uurige tulemust |
| Kas ühendused on autenditud? | TLS-i seadistused ja sertifikaatide konfiguratsioon | Lükake tagasi kehtetu sertifikaat ja keelatud protokoll |
| Kas võtmevahetus säilitab juurdepääsu? | Võtmevahetuse kirje ja versioonide vastavustabel | Lugege vanu ja uusi andmeid pärast järkjärgulist muudatust |
| Kas taastamine õnnestub? | Varukoopiate kataloog ja taastamisprotseduur | Taastage vanem varukoopia nõutavate võtmeversioonidega |
| Kas muudatused on tuvastatavad? | Võtmekasutuse ja poliitikamuudatuste kirjed | Kinnitage, et ootamatu sündmus jõuab hindajani |
Tõlgendage logimise kaetust ettevaatlikult. Ümbrikkrüpteerimise ja vahemällu salvestatud andmevõtmete korral võib üks võtmeteenuse toiming võimaldada mitut hilisemat kohalikku dekrüpteerimist. KMS-i logi ei ole seega tingimata täielik kirje igast juurdepääsust avatekstile. Siduge see vajaduse korral rakenduse autoriseerimise ja andmetele juurdepääsu kirjetega.
Eemaldage tõendipakettidest saladused. Ärge kunagi laadige üles tooreid võtmeid, taastefraase, kehtivaid volitusi ega mittevajalikke avatekstikirjeid. Säilitage ressursi identifikaator, ajatempel, ulatus, hindaja, testi tulemus ja asjakohane konfiguratsioon ilma uut kokkupuudet tekitamata.
Erandites tuleks märkida mõjutatud süsteem, põhjus, kompenseerivad kontrollimeetmed, omanik, aegumine ja parandusülesanne. Ajutine pärandedastuse erand vajab otsust ja väljumisplaani, mitte püsivat märget arvutustabelis.
Praktilise soovitusena korrake sihtotstarbelisi kontrolle pärast muudatusi salvestuses, töökoormuste identiteetides, võtmepoliitikates, sertifikaatides või varukoopiate sihtkohtades. Plaanilised ülevaatused jäävad kasulikuks, kuid juurutus võib kaitsepiiri muuta enne järgmist kalendrijärgset ülevaatust. Automaatsed kontrollid peaksid tõstatama tegutsemist võimaldavaid leide koos ressursi konteksti ja omanikuga, samas kui inimestest hindajad hindavad erandeid ja muutusi ohumudelis.
Oletame illustreeriva SaaS-teenuse, mis salvestab konfidentsiaalseid kliendidokumente objektisalvestusse. Selle rakendus hangib dokumente autenditud kasutajatele ja igapäevased varukoopiad toetavad ettevõtte määratud taastamiseesmärki. Ülevaatuse all olevad ohud on varastatud salvestuskoopiad, volitamata haldusjuurdepääs ja rentnikevaheline avalikustamine.
Meeskond kaardistab TLS-i brauserist servani, TLS-i servast rakenduseni, rakenduse ja salvestuse vahelised ühendused, tootmise salvestuskorvi ja eraldi varukoopiate sihtkoha. Ta avastab, et tõrkeotsingu ekspordi töö kirjutab dekrüpteeritud faile tugiteenuse kausta. Sellest kaustast saab kohene ulatuse punkt; tootmise salvestuskorvi krüpteerimisseadistus seda ei kata.
Esialgse lahenduse puhul kaitseb kliendi hallatava võtmega salvestuskrüpteerimine tootmisobjekte. Rakenduse identiteet saab hankida volitatud objekte ja kutsuda vajalikke võtmetoiminguid. Juurutusroll saab ressursse luua, kuid tal ei ole tavapärast dekrüpteerimisõigust. Võtmepoliitikate haldamine järgib eraldi heakskiiduteed.
Meeskond tunnistab allesjäävat piiri: rakenduse kompromiteerimine võimaldaks endiselt avateksti hankida. Ta kaalub eriti tundliku dokumendikategooria jaoks rakenduskihi krüpteerimist ja hindab seejärel otsingunõudeid, tugiteenuste juurdepääsu ja taastamise keerukust, enne kui otsustab, kas täiendav piir on põhjendatud.
Kontrollimine annab konkreetsed tulemused:
Hindaja säilitab andmevoo kaardi, konfiguratsiooniekspordid, identiteedipoliitikad, anonüümitud negatiivsete testide tulemused, võtmevahetuse kirje ja taastamisaruande. Võtme keelamise harjutus mittetootmiskeskkonnas kinnitab, et teenus tagastab kontrollitud vea, mitte ei paljasta andmeid ega viska kirjutusi vaikselt minema.
See näide ei tõenda kaitset iga ründe vastu. See näitab, milliseid ohte lahendus käsitleb, milline identiteet jääb usaldatuks ja millised tõendid neid järeldusi toetavad.
Krüpteerimisotsused peaksid kajastama õiguslikke, lepingulisi ja raamistikest tulenevaid nõudeid, muutmata neid üldisteks väideteks. GDPR-i artikkel 32 kasutab riskipõhist lähenemisviisi ja loeb krüpteerimise asjakohaste meetmete hulka; see ei kehtesta universaalset krüpteerimiskohustust iga töötlemistoimingu jaoks. Krüpteerimine ei kõrvalda ka kohustusi, mis puudutavad seaduslikku töötlemist, juurdepääsu, säilitamist või intsidentide hindamist.
Kindla ulatusega ISO 27001 ISMS-is dokumenteerige riskikäsitlus, kohaldatavad kontrollimeetmed, omand ja tõendid, selle asemel et eeldada, et üks krüpteeritud andmebaas rahuldab laiemat juhtimissüsteemi. Kui NIS2 kohaldub riikliku õiguse kaudu, hõlmavad selle artikli 21 meetmed krüptograafiat ja vajaduse korral krüpteerimist käsitlevaid poliitikaid ja protseduure. Kinnitage kohaldatavus ja riiklikud nõuded eraldi.
Planeerige krüptograafilisi muudatusi kui insenertehnilist sõltuvust. Inventeerige algoritmid, sertifikaadid, teegid, protokollid ja põimitud vormingud, et aegunud mehhanisme saaks asendada. Pikaajaliste konfidentsiaalsete andmete puhul hinnake tulevaste krüptoanalüütiliste ja kvantohtude asjakohasust. Kvantjärgse migratsiooni küsimused erinevad võtmete kokkuleppimise, allkirjade ja sümmeetrilise krüpteerimise puhul; vältige testimata täielikku asendamist, mida esitletakse universaalse lahendusena.
Secani suudab selle töö jaoks siduda sihtsüsteemid, kontrollinõuded, rakenduskirjeldused, tõendid, omanikud ja ülevaatusotsused. Lisage kaitsekaart ja anonüümitud testikirjed asjakohastele süsteemidele ja kontrollimeetmetele, muutke lahendamata võtmejuurdepääsu või taastamise küsimused ülesanneteks ja säilitage põhjus, miks iga krüptograafiline valik heaks kiideti. Vaadake tehisintellekti abil tehtud soovitused üle nende allikate põhjal ja hoidke inimese heakskiit selgesõnalisena.
Alustage ühest tundlikust andmehoidlast ning jälitage andmetele juurdepääsu, võtmetele juurdepääsu ja taastamist koos. Valige üks negatiivne autoriseerimistest ja üks taastamisharjutus, määrake omanikud ja salvestage tulemused enne ulatuse laiendamist. Meie pilveturbe juhend annab ümbritseva konfiguratsiooni konteksti.
Secani ühendab ulatused, tõendid, ülesanded ja tehisintellekti agendid ühte jagatud tööruumi.
Siduge kriitilised teenused taasteeesmärkide, sõltuvuste, õppuste ja parandusmeetmetega, et talitluspidevuse plaanid kajastaksid tegelikku võimekust.
Vaadake üle pilve identiteedid, avatus, krüpteerimine, taastamine ja logimine tõenditega, mis on seotud tegelike kontode, teenuste ja andmetega.
Ühendage korduvad tehnilised kontrollid ja perioodiline otsustus selge kaetuse, kogumise seisundi, künniste ja järeltegevuste omandiga.