Titkosítás és kulcskezelés: ellenőrizze a védelmi láncot

A titkosítás meghatározott feltevések mellett védi az információkat. Egy hasznos megvalósítás megmagyarázza, mely adatok védettek, milyen hozzáférés ellen, és hogyan maradnak a kulcsok kontroll alatt a teljes életciklusuk során. Egy „titkosítás bekapcsolva” beállítás ennek a kérdésnek csak kis részére ad választ.

Egy CTO számára a mérnöki feladat a védelmi lánc ellenőrzése: hol keletkezik a nyílt szöveg, merre halad, hol tárolják a titkosított szöveget, ki kérhet visszafejtést, és mi történik hiba vagy helyreállítás esetén. Ebbe a láncba beletartoznak az alkalmazások, az identitások, a felhőszolgáltatások, az adminisztrátorok, a mentések és a működési eljárások.

Az alábbi gyakorlati ajánlások módszert adnak ennek a láncnak a megtervezéséhez és felülvizsgálatához. Kezdjen egyetlen érzékeny adattárral, majd terjessze ki ugyanezt a módszert a tőle függő rendszerekre és a másodlagos másolatokra.

A technológia kiválasztása előtt határozza meg a védelmi célt

Fenyegetési állítással kezdjen, ne algoritmussal. Az „ügyfélrekordok védelme” túl tág ahhoz, hogy irányt adjon a megvalósításnak. Az „annak megakadályozása, hogy valaki, aki egy ellopott mentés birtokában van, külön kezelt kulcsok nélkül elolvashassa az ügyfélrekordokat” megfogalmazás azonosít egy eszközt, egy támadói képességet és egy védelmi határt.

A különböző fenyegetések különböző kontrollokat igényelnek. A lemeztitkosítás védhet egy kikapcsolt, ellopott laptopot, de egy hitelesített felhasználó vagy egy rosszindulatú folyamat a lemez feloldott állapotában továbbra is olvashatja a fájlokat. Az adatbázis-titkosítás védheti az adathordozókat, miközben az adatbázis-lekérdezések nyílt szöveget adnak vissza. Az alkalmazásszintű titkosítás korlátozhatja, mit látnak az adatbázis-adminisztrátorok, de nem feltétlenül véd egy visszafejtési jogosultsággal rendelkező, kompromittált alkalmazás ellen.

Ezeket a különbségeket egy rövid adatfolyam-leltárral tegye kifejezetté. Vegye fel az éles rekordokat, a feltöltött dokumentumokat, a gyorsítótárakat, a sorokat, az analitikai kivonatokat, a naplókat, az ideiglenes fájlokat, a pillanatképeket és a mentéseket. Az adatfelderítésnek azokat a másolatokat is azonosítania kell, amelyek kikerülnek a fő tárolási architektúrából, nem csak az architektúraábrán szereplő rendszereket.

Minden fontos adatfolyamhoz rögzítse:

• Az adatkategóriát és annak bizalmassági igényeit.
• A forrást, a célt, a köztes szolgáltatásokat és a nyílt szöveg határait.
• Azt a támadót vagy jogosulatlan szerepet, amelyet a titkosításnak korlátoznia kell.
• A visszafejtésre jogosult identitást és azt az okot, amiért erre a jogosultságra szüksége van.
• A rendelkezésre állási, megőrzési és helyreállítási követelményeket.
• A megvalósításért felelős személyt és a bizonyítékokért felelős felülvizsgálót.

Egy fenyegetésmodellezési megközelítés segít tesztelni, hogy a kiválasztott határ megfelel-e a fenyegetésnek. Ha egy támadó felveheti az alkalmazás identitását, az átlátszó tárolási titkosítás önmagában nem akadályozza meg az alkalmazáson keresztüli hozzáférést.

Az eredmény egy védelmi térkép: egy adatfolyam-ábra, kifejezett feltevésekkel és kivételekkel kiegészítve. Ez lesz a viszonyítási alap a konfigurációs ellenőrzésekhez, a jogosultsági tesztekhez és a helyreállítási gyakorlatokhoz.

Értse meg, mit nyújtanak valójában a kriptográfiai építőelemek

A titkosítás egy kriptográfiai algoritmus és egy kulcs segítségével alakítja a nyílt szöveget titkosított szöveggé. A bizalmasság a konstrukciótól, a megvalósítástól, a kulcs titkosságától és a működési környezettől függ. Egy erős algoritmus nem tudja ellensúlyozni azt, ha a kulcsot egy forráskódtárba commitolták, vagy ha egy alkalmazásvégpont egy másik ügyfél rekordjait adja vissza.

A szimmetrikus és az aszimmetrikus kriptográfia más-más feladatot lát el

A szimmetrikus titkosítás közös titkos kulcsot használ a titkosításhoz és a visszafejtéshez. Hatékonysága miatt gyakran használják nagy adatmennyiségekhez. Az AES 128, 192 és 256 bites kulcsokat támogat, de a kulcsméret önmagában nem ír le biztonságos megvalósítást: a mód, a nonce-kezelés, a hitelesítés és a könyvtár viselkedése is számít.

Az aszimmetrikus kriptográfia egymáshoz kapcsolódó nyilvános és titkos kulcsokat használ. Az algoritmustól és a protokolltól függően titkosítást, aláírást vagy kulcsmegállapodást támogat. Az RSA és az elliptikus görbéken alapuló konstrukciók eltérő képességekkel és paraméterekkel rendelkeznek; nem felcserélhető címkék. Az aszimmetrikus kriptográfia nem eredendően „biztonságosabb”, mint a szimmetrikus titkosítás.

A modern rendszerek gyakran kombinálják őket. Egy biztonságos átviteli protokoll hitelesítheti a másik felet és közös titkokat hozhat létre, majd szimmetrikus titkosítással védi a forgalmat. A nagy fájlokat jellemzően szimmetrikus adatkulcsokkal titkosítják, ahelyett hogy a teljes fájlt közvetlenül egy aszimmetrikus algoritmussal dolgoznák fel.

A bizalmasság nem azonos a sértetlenséggel vagy a hitelességgel

A hitelesített titkosítás, például a helyesen használt AES-GCM, védi a bizalmasságot, és észleli a védett titkosított szöveg és a kapcsolódó adatok jogosulatlan módosítását. Ha ugyanazzal a kulccsal újra felhasználják a nonce-ot, az alááshatja ezt a védelmet. Részesítse előnyben a karbantartott könyvtárakat és a jól támogatott formátumokat, amelyek biztonságosan kezelik ezeket a követelményeket; ne találjon ki saját rejtjelezőt, módot vagy kulcscsere-protokollt.

A hash-függvény lenyomatot állít elő, nem visszaállítható titkosított szöveget. Egy közönséges hash nem bizonyítja, ki hozta létre az üzenetet. A jelszavak tárolásához erre a célra tervezett jelszó-hash-elés szükséges, nem visszafordítható titkosítás vagy önmagában egy gyors, általános célú lenyomatképzés.

Az üzenethitelesítő kód (MAC) egy titok segítségével ellenőrzi a sértetlenséget és a hitelességet az ezt a titkot megosztó felek között. A digitális aláírások titkos aláírókulcsot és nyilvános ellenőrzőkulcsot használnak; nem teszik bizalmassá az aláírt tartalmat.

Ezek a különbségek a felülvizsgálat során számítanak. Kérdezze meg, melyik tulajdonságra van szükség, és melyik mechanizmus biztosítja, ahelyett hogy a „kriptográfiát” egyetlen, differenciálatlan kontrollként fogadná el.

Ellenőrizzen minden tárolási réteget és minden másodlagos másolatot

A tárolt adatok titkosítása (encryption at rest) a tárolt információkra vonatkozik, beleértve a futó szolgáltatás által aktívan használt adatokat is. A kifejezés nem csak az archivált vagy inaktív adatokat jelenti.

A különböző rétegek különböző hozzáférési útvonalak ellen védenek:

A tényleges erőforrás-konfigurációt ellenőrizze, ne csupán egy fiókszintű alapbeállítást. Egy alapbeállítás csak az újonnan létrehozott tárolókra vonatkozhat. A meglévő objektumok, az importált kötetek, a replikák vagy a korábbi pillanatképek eltérő beállításokat követhetnek.

Adatbázisoknál vizsgálja meg a tranzakciós naplókat, az ideiglenes tárolókat, a replikákat, az exportokat és az adminisztratív dump-eljárásokat. Objektumtárolóknál ellenőrizze a feltöltéseket, a másolatokat, a replikációs célhelyeket, a verziózott objektumokat és a letöltési útvonalakat. Végpontoknál ellenőrizze a helyreállítási kulcsok kezelését, és hogy kiterjed-e a védelem a cserélhető adathordozókra.

Az alkalmazásszintű titkosítás külön tervezési döntést érdemel. Csökkentheti az adatbázis-üzemeltetők felé fennálló kitettséget, vagy szűkítheti azoknak a munkaterheléseknek a körét, amelyek a kiválasztott mezőket visszafejthetik. Ugyanakkor megnehezítheti az indexelést, a keresést, az analitikát és a támogatási munkafolyamatokat. Dokumentálja, hol kerülnek a visszafejtett értékek a memóriába, a naplókba, a hibajelentésekbe vagy az exportokba.

Ne tekintse a titkosítást a jogosultságkezelés helyettesítőjének. Egy alkalmazás helyesen visszafejthet egy rekordot, és mégis rossz bérlőnek adhatja ki. A bérlők elkülönítését, a hozzáférés-ellenőrzéseket és a privilegizált hozzáférés kontrolljait ugyanabban a felülvizsgálatban kezelje.

Ellenőrizze az átvitelt az első küldőtől a végső címzettig

Az átviteli titkosítás a végpontok között mozgó adatokat védi. A hasznos kérdés nem az, hogy „Használunk-e HTTPS-t?”, hanem az, hogy „Mely kapcsolatok védettek, és mely identitások hitelesítettek?”

Térképezze fel a böngésző–edge, edge–alkalmazás, szolgáltatás–szolgáltatás, alkalmazás–adatbázis kapcsolatokat, a replikációt, a mentések átvitelét, az adminisztratív hozzáférést és a harmadik feleknek szóló exportkapcsolatokat. Ha a TLS egy terheléselosztónál végződik, az határt hoz létre: a következő ugráshoz saját védelmi döntés szükséges. Egy magánhálózat nem szünteti meg automatikusan a lehallgatás vagy az oldalirányú mozgás kockázatát.

Gyakorlati alapszintként részesítse előnyben a támogatott, modern TLS-konfigurációkat és a karbantartott kliensoldali könyvtárakat. Ahol támogatott, a TLS 1.3 erős alapértelmezés; a kompatibilitás miatt a megfelelően konfigurált TLS 1.2 továbbra is szükséges lehet. A régi SSL nem megfelelő modern biztonsági választás.

A tanúsítványok ellenőrzése a védelem része. Ellenőrizze a hosztnév-ellenőrzést, a megbízható tanúsítványtárakat, a lejárat monitorozását, a tanúsítványok megújítását, és azt, hogy nincsenek-e olyan éles beállítások, amelyek kikapcsolják az ellenőrzést. Egy nem hitelesített végpont felé irányuló titkosítás megvédheti a forgalmat a passzív megfigyeléstől, miközben azt mégis rossz félnek küldi.

A kölcsönös TLS (mTLS) a kapcsolat mindkét végét hitelesítheti, de nem helyettesíti az alkalmazás jogosultságkezelését. A tanúsítványok kiadása, a munkaterhelés-identitás, a megújítás és a visszavonás olyan működési függőségekké válnak, amelyekhez felelősök és tesztek kellenek.

Különböztesse meg az átviteli titkosítást a végpontok közötti titkosítástól. Egy szolgáltatás, amely lezárja a TLS-t és nyílt szöveget dolgoz fel, nem nyújt önmagával szemben végpontok közötti bizalmasságot. A végpontok közötti megoldások a visszafejtést kijelölt végpontokra korlátozzák; külön kérdéseket vetnek fel az eszközök regisztrációjával, a címzettek ellenőrzésével, a több eszközről történő hozzáféréssel és a helyreállítással kapcsolatban.

A bizonyítékoknak konfigurációs és kapcsolódási teszteket is tartalmazniuk kell. Ne csak egy sikeres titkosított kapcsolatot teszteljen, hanem az érvénytelen tanúsítványok és a tiltott protokollverziók elutasítását is.

A kulcsokat életciklussal rendelkező eszközként irányítsa

A kulcsok előállítást, tárolást, engedélyezett használatot, cserét, visszavonást, megőrzést és megsemmisítést igényelnek. Minden szakaszhoz felelős és meghatározott eljárás tartozzon.

A kulcsokat tudatosan állítsa elő és regisztrálja

A kulcsokat megfelelő véletlenszerűséget biztosító, karbantartott kriptográfiai eszközökkel állítsa elő. Ne származtasson éles titkosítási kulcsokat megjegyezhető jelszavakból, azonosítókból, időbélyegekből vagy hagyományos alkalmazásszintű véletlenszám-függvényekből.

Vezessen kulcsleltárt, amely tartalmazza a célt, a felelőst, a környezetet, a védett rendszereket, az algoritmust, a kulcsazonosítót, a létrehozás dátumát, az állapotot és a helyreállítási függőségeket. Metaadatokat rögzítsen, ne titkos kulcsanyagot. Különböztesse meg a titkosítási kulcsokat, az aláírókulcsokat, a TLS titkos kulcsokat és az API-hitelesítő adatokat, mert kitettségük és cseréjük eljárása eltér.

Válassza külön az éles környezetet a fejlesztési és tesztkörnyezetektől. Ha egy kulcsot több környezetben is használnak, az kiterjeszti egy alacsonyabb bizalmi szintű környezet hatását, és nehezebben értelmezhetővé teszi a használati naplókat.

Válassza külön a kulcsok kezelését az adatokhoz való hozzáféréstől

Egy kulcskezelő szolgáltatás (KMS) jellemzően szabályozott kulcsműveleteket, hozzáférési szabályzatokat, verziókezelést és használati nyilvántartásokat biztosít. Egy hardveres biztonsági modul (HSM) hardveres határt biztosít a kriptográfiai műveletekhez és a kulcsok védelméhez. A szolgáltatások kombinálhatják ezeket a funkciókat, de a terméknevek nem határozzák meg a pontos biztonsági határt.

Állapítsa meg, hogy a kulcsok exportálhatók-e, mely műveletek zajlanak a határon belül, ki kezeli a szabályzatokat, és hogyan működik a helyreállítás. A felügyelt kulcsszolgáltatásokat vagy a hardveres védelmet a kockázat és a működési követelmények alapján válassza meg, ahelyett hogy a dedikált hardvert általánosan szükségesnek tekintené. A HSM-ek elsősorban a kulcsokat és a kriptográfiai műveleteket védik; nem általános célú tárolók az összes titkosított üzleti adat számára.

A borítéktitkosítás (envelope encryption) gyakori minta. Egy adattitkosító kulcs titkosítja a tartalmat, egy kulcstitkosító kulcs pedig ezt az adatkulcsot védi. A titkosított adatkulcs a titkosított szöveggel együtt tárolható. A biztonsága azon múlik, hogy a kicsomagolás képességét külön kezelik-e, nem azon, hogy minden titkosított kulcsot egy másik helyen rejtenek el.

A visszafejtést korlátozza azokra a munkaterhelésekre, amelyeknek szükségük van rá. Ahol megvalósítható, válassza külön a kulcsok adminisztrációját a kulcsok használatától és a tárolók adminisztrációjától. Vizsgálja meg, hogy egy adminisztrátor, aki jelenleg nem tud visszafejteni, megadhatja-e magának ezt a jogosultságot. A vészhelyzeti hozzáféréshez kifejezett jóváhagyás, korlátozott időtartam és felülvizsgálati nyomvonal tartozzon.

A kulcsrotációt változási folyamatként kezelje, ne kipipálandó tételként

A kriptoperiódusokat az adatok érzékenysége, a kitettség, az algoritmus korlátai, a használat mennyisége és az alkalmazandó követelmények alapján határozza meg. A rotáció egy feltételezett kompromittálódás vagy a bizalmi viszonyok lényeges változása után is indokolt.

Tisztázza, mit csinál a „rotáció” a választott szolgáltatásban. Ha a jövőbeli titkosításhoz új kulcsverziót hoznak létre, a korábbi adatok továbbra is a régebbi verzióktól függhetnek. Az adatkulcsok újracsomagolása egy új kulcstitkosító kulccsal más, mint a mögöttes adatok visszafejtése és újratitkosítása. Egyik műveletet sem szabad egy automatikus rotációs beállításból feltételezni.

Egy rotációs tervnek azonosítania kell az érintett alkalmazásokat, a tárolt kulcsazonosítókat, a korábbi verziókat, a fokozatos bevezetést, a hibák monitorozását, a visszaállítási feltételeket és a végső kivezetést. A régi hozzáférés megszüntetése előtt tesztelje a vegyes verziójú olvasásokat és a hosszan futó feladatokat.

Különböztesse meg a visszavonást a megsemmisítéstől

A visszavonás eltávolítja a jogosultságot, vagy letiltja a kulcs jövőbeli használatát. Nem törli a már lekért nyílt szöveget, nem érvényteleníti az összes gyorsítótárazott adatkulcsot, és nem tünteti el az exportált titkot.

A megsemmisítés helyreállíthatatlanná teheti a megőrzött titkosított szöveget, de csak akkor, ha minden használható másolatot és helyreállítási útvonalat kezelnek. Vegye figyelembe a replikákat, a kulcsletétet, az exportált anyagot, a mentéseket és a közös kulcsokból eredő függőségeket. Ha egymással nem összefüggő rekordok közös kulcsot használnak, annak megsemmisítése olyan adatokhoz való hozzáférést is megszüntethet, amelyeknek elérhetőnek kell maradniuk.

A megőrzés és a törlés tervezését tartsa összekapcsolva. A kulcsok határozatlan ideig tartó megőrzése alááshatja a törlési célt; az idő előtti megsemmisítés rendelkezésre állási incidenst okozhat.

A felhőalapú kulcsmodelleket a tényleges kontrollhatáruk alapján értékelje

A felhőalapú titkosítás csökkentheti a megvalósítási munkát, de a szolgáltató alapbeállításai nem határozzák meg az Ön fenyegetési modelljét. A szolgáltatást, a kulcsszabályzatot, az adminisztratív hozzáférést, a régiót, a helyreállítási modellt és az alátámasztó bizonyítékokat együtt értékelje.

A szolgáltató által kezelt kulcsok bizonyos kockázatokhoz viszonylag kis működési teherrel megfelelőek lehetnek. Az ügyfél által kezelt kulcsok kifejezettebb szabályzati kontrollt, felelősséget és életciklus-döntéseket biztosíthatnak. A külsőleg tárolt kulcsok más bizalmi határt hozhatnak létre, ugyanakkor függőséget is teremtenek a külső rendelkezésre állástól és kapcsolódástól.

Az olyan kifejezések, mint a bring your own key, a bring your own encryption és az encryption as a service, nem egyenértékű architekturális garanciák. Ha egy kulcsot importálnak egy szolgáltatói szolgáltatásba, az nem feltétlenül jelenti, hogy a szolgáltató soha nem végezhet visszafejtést. A kliensoldali titkosítás bevezetése megváltoztatja a nyílt szöveg határát, de megnehezítheti az alkalmazás funkcióit és a helyreállítást.

Kérdezze meg a potenciális szolgáltatót:

• Azonosítani tudjuk-e az egyes releváns tárolóerőforrásokhoz és mentésekhez használt kulcsot?
• Ki módosíthatja a kulcsszabályzatokat, és hogyan rögzítik ezeket a változtatásokat?
• Mi történik, ha egy kulcsot letiltanak, vagy a kulcsszolgáltatás nem érhető el?
• Hogyan befolyásolja a védelmet az export, a replikáció, a migráció és a fiók megszüntetése?
• Mely használati események érhetők el, és milyen tevékenység esik kívül a láthatóságukon?

A teljesítményt reprezentatív munkaterhelésekkel értékelje: átviteli sebesség, késleltetés, a kulcsszolgáltatás kvótái, a gyorsítótárazás viselkedése és a hibamódok. Egy szolgáltatás, amely egy kis bemutatón működik, egy tömeges visszaállítás során meghibásodhat. Az adatok helye és az ügyfél kulcstulajdonlása hasznos tervezési bemenet, de nem bizonyítja a szuverenitást vagy a jogszabályi megfelelést.

Válasszon megoldást működési próbán keresztül

A jelölteket a védelmi térképhez mérje, ne algoritmusnevek listájához. Vegye figyelembe a könyvtárak karbantartását, a támogatott platformokat, az adminisztratív szétválasztást, a bizonyítékok elérhetőségét, a migrációs lehetőségeket és a csapat képességét a szolgáltatás üzemeltetésére. Ha egy szerződés validált kriptográfiai modult ír elő, állapítsa meg az érintett modult, a verziót, a működési környezetet és a validálás hatókörét; az AES címke önmagában nem igazolja ezt a követelményt.

Egy gyakorlati próbának reprezentatív adatokat kell titkosítania, normál olvasásokat kell végeznie, rotálnia kell egy kulcsot, vissza kell állítania egy régebbi másolatot, és szimulálnia kell egy elérhetetlen kulcsszolgáltatást. Vegye bele a tömeges importokat és exportokat is, mert ezek viselkedése eltérhet a rutinszerű alkalmazáskérésekétől. Az alkalmazás saját késleltetésére és helyreállítási céljaira gyakorolt hatást mérje, ahelyett hogy egy általános teljesítményállítást fogadna el.

Rögzítsen kifejezett elfogadási döntést: mely fenyegetéseket kezeli a megoldás, milyen függőségeket vezet be, mi marad a hatókörön kívül, és ki a felelőse ezeknek a maradványkockázatoknak. Tesztelje a hordozhatóságot is. Az exportált titkosított szövegnek kevés működési értéke van, ha a formátuma, a becsomagolt kulcsai vagy a szükséges metaadatai a szolgáltatási kapcsolat megszűnése után nem értelmezhetők.

A helyreállítást a bizalmassággal együtt tervezze meg

Egy mentésnél három dolgot kell megállapítani: az adatok titkosítottak, a jogosult helyreállítási munkatársak hozzáférnek a szükséges kulcsműveletekhez, és a visszaállítás sikeres.

Ne helyezze az egyetlen helyreállítási útvonalat ugyanabba a hibahatárba, mint az éles környezetet. Egy fiókzárolás, egy regionális zavar vagy egy adminisztratív hiba a mentést és annak kulcsait is érintheti. A különálló helyreállítási megoldásokat szigorúan kontrollálni kell; függetlenségük nem teheti őket széles körben hozzáférhetővé.

Dokumentálja az egyes mentésgenerációkhoz szükséges kulcsverziókat, a szükséges identitásokat, a jóváhagyási lépéseket, a szolgáltatói függőségeket és a visszaállított adatokra vonatkozó korlátozásokat. A tesztkörnyezetbe történő visszaállítás nem teheti csendben elérhetővé az éles információkat a fejlesztők számára.

A helyreállítást elszigetelt környezetben gyakorolja. Rögzítse, hogy megtalálták-e a mentést, sikeresek voltak-e a sértetlenségi ellenőrzések, használhatók maradtak-e a szükséges kulcsok, olvashatók voltak-e az alkalmazásadatok, és megfelelt-e az elért helyreállítási idő a szervezet céljának. Az időadatok a tényleges gyakorlathoz tartoznak, nem a titkosítás feltételezett előnyéhez.

A kulcsszolgáltatás kiesését is vegye fel az ellenálló képesség tesztelésébe. Döntse el, hogy egy munkaterhelésnek zártan kell-e hibáznia (fail closed), újra kell-e próbálkoznia, vagy jóváhagyott gyorsítótárazott kulcsot kell-e használnia. A gyorsítótárazás javíthatja a rendelkezésre állást, de meghosszabbítja azt az időszakot, amely alatt egy folyamat a központi hozzáférés megszüntetése után is visszafejthet. Ezt a kompromisszumot kifejezetten dokumentálja.

Készüljön fel egy kulcs feltételezett kompromittálódására

A reagálás attól függ, mi került nyilvánosságra. Egy kiszivárgott alkalmazás-hitelesítő adat, amely jogosult a KMS meghívására, más, mint egy exportált titkosítási kulcs: a hitelesítő adat eltávolítása megállíthatja a szolgáltatáshoz való jövőbeli hozzáférést, míg egy támadó, aki birtokában van a kulcsnak és a titkosított szövegnek, önállóan is visszafejthet. Egy kompromittált aláírókulcs más problémát teremt, amely az aláírásokba vetett bizalmat érinti, nem egyszerűen a bizalmasságot.

Készítsen olyan forgatókönyvet, amely azonosítja a döntéshozót, az érintett kulcsazonosítókat, a függő rendszereket, a kárelhárítási lehetőségeket és a megőrzendő bizonyítékokat. Vizsgálja ki a szabályzatváltozásokat, a szokatlan kulcsműveleteket, az adatletöltéseket, az alkalmazáshozzáféréseket és a lehetséges kitettségi időszakot. A hiányzó naplóesemények nem bizonyítják, hogy nem történt visszafejtés, különösen ott, ahol a kulcsok exportálhatók vagy gyorsítótárazhatók.

A kárelhárítás magában foglalhatja egy identitás letiltását, egy szabályzat szűkítését, egy munkaterhelés elszigetelését vagy egy kulcs letiltását. Egy visszafordíthatatlan lépés előtt értékelje a rendelkezésre állásra gyakorolt következményeket. Ne semmisítse meg az egyetlen helyreállítási kulcsot rögtönzött kárelhárítási lépésként.

A kárelhárítás után határozza meg, mely adatokat kell nem kompromittált kulcsokra migrálni. Egy csomagolókulcs rotálása nem elegendő, ha a támadó megszerezte a mögöttes adatkulcsokat. A megőrzött adatok újratitkosítása megvédheti a jövőbeli másolatokat, de nem vonhatja vissza a már együtt ellopott titkosított szöveget és kulcsokat. Hasonlóképpen, ha egy kompromittált alkalmazásidentitást lecserélnek anélkül, hogy kijavítanák a jogosultsági hibáját, az eredeti kiszivárgási útvonal nyitva marad.

Őrizze meg az incidens idővonalát, az érintett adatok értékelését, a csere- és validálási nyilvántartásokat és a fennmaradó bizonytalanságokat. Ha személyes adatok érintettek, a bejelentési kötelezettségeket külön értékelje; az „adatbázis titkosítva volt” nem válaszolja meg, hogy a támadó hozzájuthatott-e nyílt szöveghez vagy használható kulcsokhoz.

Olyan bizonyítékokat építsen, amelyek a láncot tesztelik

Egy szabályzat a szándékolt viselkedést írja le. A bizonyítékoknak azt kell igazolniuk, hogy a megvalósítás ezt követi, és hogy a fontos hibaútvonalak az elvárt módon viselkednek.

Használja együtt a konfigurációs exportokat, a szabályzat-felülvizsgálatokat, a hozzáférési teszteket, a kulcshasználati naplókat, a telepítési ellenőrzéseket és a helyreállítási nyilvántartásokat. A képernyőképek támogathatnak egy felülvizsgálatot, de önmagukban ritkán magyarázzák meg a hatókört, a korábbi viselkedést vagy az elsodródást.

A naplózás lefedettségét óvatosan értelmezze. Borítéktitkosítás és gyorsítótárazott adatkulcsok esetén egyetlen kulcsszolgáltatási művelet több későbbi helyi visszafejtést is lehetővé tehet. Egy KMS-napló ezért nem feltétlenül teljes nyilvántartása minden nyílt szöveghez való hozzáférésnek. Adott esetben párosítsa az alkalmazás jogosultságkezelési és adathozzáférési nyilvántartásaival.

A bizonyítékcsomagokból takarja ki a titkos adatokat. Soha ne töltsön fel nyers kulcsokat, helyreállítási kifejezéseket, élő hitelesítő adatokat vagy szükségtelen nyílt szöveges rekordokat. Őrizze meg az erőforrás-azonosítót, az időbélyeget, a hatókört, a felülvizsgálót, a teszteredményt és a releváns konfigurációt, anélkül hogy új kitettséget teremtene.

A kivételeknek meg kell nevezniük az érintett rendszert, az okot, a kompenzáló kontrollokat, a felelőst, a lejáratot és a hibaelhárítási feladatot. Egy ideiglenes, régi átviteli protokollra vonatkozó kivételhez döntés és kivezetési terv kell, nem egy állandó megjegyzés egy táblázatban.

Gyakorlati ajánlásként ismételje meg a célzott ellenőrzéseket a tárolók, a munkaterhelés-identitások, a kulcsszabályzatok, a tanúsítványok vagy a mentési célhelyek változásai után. Az ütemezett felülvizsgálatok továbbra is hasznosak, de egy telepítés a következő naptári felülvizsgálat előtt is megváltoztathatja a védelmi határt. Az automatizált ellenőrzéseknek erőforrás-kontextussal és felelőssel ellátott, cselekvésre alkalmas megállapításokat kell generálniuk, miközben az emberi felülvizsgálók értékelik a kivételeket és a fenyegetési modell változásait.

Gyakorlati példa: egy ügyféldokumentum-szolgáltatás végigkövetése

Tegyük fel, hogy egy szemléltető SaaS-szolgáltatás bizalmas ügyféldokumentumokat tárol objektumtárolóban. Az alkalmazás a hitelesített felhasználók számára kéri le a dokumentumokat, a napi mentések pedig egy üzletileg meghatározott helyreállítási célt támogatnak. A felülvizsgált fenyegetések: ellopott tárolómásolatok, jogosulatlan adminisztratív hozzáférés és bérlők közötti adatkiszivárgás.

A csapat feltérképezi a böngésző–edge TLS-t, az edge–alkalmazás TLS-t, az alkalmazás és a tároló közötti kapcsolatokat, az éles bucketet és egy különálló mentési célhelyet. Felfedezi, hogy egy hibaelhárítási exportfeladat visszafejtett fájlokat ír egy támogatási mappába. Ez a mappa azonnal a hatókör részévé válik; az éles bucket titkosítási beállítása nem terjed ki rá.

A kezdeti tervben az ügyfél által kezelt kulccsal végzett tárolási titkosítás védi az éles objektumokat. Az alkalmazásidentitás lekérheti a jogosult objektumokat, és meghívhatja a szükséges kulcsműveleteket. A telepítési szerepkör erőforrásokat hozhat létre, de rutinszerű visszafejtési jogosultsága nincs. A kulcsszabályzatok adminisztrációja külön jóváhagyási útvonalat követ.

A csapat felismeri a fennmaradó határt: egy alkalmazáskompromittálódás esetén továbbra is lekérhető nyílt szöveg. Egy különösen érzékeny dokumentumkategóriához mérlegeli az alkalmazásszintű titkosítást, majd értékeli a keresési igényeket, a támogatási hozzáférést és a helyreállítás összetettségét, mielőtt eldöntené, indokolt-e a további határ.

Az ellenőrzés konkrét eredményeket hoz:

• Egy jogosulatlan szolgáltatásidentitás nem tud dokumentumot lekérni vagy visszafejteni.
• Egy másik bérlő hitelesített felhasználóját az alkalmazás elutasítja.
• Az érvénytelen upstream tanúsítványokat elutasítják, nem pedig megkerülik.
• Egy régebbi mentés a szükséges korábbi kulcsverzióval sikeresen visszaáll.
• Egy fokozatos kulcsváltás után a meglévő dokumentumok és az új feltöltések is olvashatók.
• A támogatási exportfeladatot úgy módosítják, hogy jóváhagyott, hozzáférés-szabályozott, titkosított célhelyet használjon meghatározott megőrzési idővel.

A felülvizsgáló megőrzi az adatfolyam-térképet, a konfigurációs exportokat, az identitásszabályzatokat, az anonimizált negatív tesztek eredményeit, a rotációs nyilvántartást és a visszaállítási jelentést. Egy nem éles környezetben végzett kulcsletiltási gyakorlat megerősíti, hogy a szolgáltatás kontrollált hibát ad vissza, ahelyett hogy adatokat fedne fel, vagy csendben eldobná az írásokat.

Ez a példa nem igazol védelmet minden támadás ellen. Azt igazolja, mely fenyegetéseket kezeli a terv, melyik identitás marad megbízható, és milyen bizonyítékok támasztják alá ezeket a következtetéseket.

Kapcsolja a jogi követelményeket és a jövőbeli változásokat a tervhez

A titkosítási döntéseknek tükrözniük kell a jogi, szerződéses és keretrendszer-követelményeket, anélkül hogy általános állításokká válnának. A GDPR 32. cikke kockázatalapú megközelítést alkalmaz, és a megfelelő intézkedések között említi a titkosítást; nem ír elő minden adatkezelési tevékenységre általános titkosítási kötelezettséget. A titkosítás nem szünteti meg a jogszerű adatkezelésre, a hozzáférésre, a megőrzésre vagy az incidensek értékelésére vonatkozó kötelezettségeket sem.

Egy meghatározott hatókörű ISO 27001 szerinti IBIR-ben dokumentálja a kockázatkezelést, az alkalmazandó kontrollokat, a felelősséget és a bizonyítékokat, ahelyett hogy feltételezné, hogy egyetlen titkosított adatbázis kielégíti a tágabb irányítási rendszert. Ahol a NIS2 a nemzeti jogon keresztül alkalmazandó, a 21. cikk szerinti intézkedései között szerepelnek a kriptográfiára és adott esetben a titkosításra vonatkozó szabályzatok és eljárások. Az alkalmazhatóságot és a nemzeti követelményeket külön erősítse meg.

A kriptográfiai változásokat mérnöki függőségként tervezze meg. Vegye leltárba az algoritmusokat, a tanúsítványokat, a könyvtárakat, a protokollokat és a beágyazott formátumokat, hogy az elavult mechanizmusok lecserélhetők legyenek. A hosszú élettartamú bizalmas adatoknál értékelje a jövőbeli kriptoanalitikai és kvantumfenyegetések relevanciáját. A posztkvantum-migráció szempontjai eltérnek a kulcsmegállapodás, az aláírások és a szimmetrikus titkosítás esetében; kerülje a teszteletlen, mindenre kiterjedő cserét, amelyet univerzális megoldásként mutatnak be.

Tegye konkréttá a következő felülvizsgálatot

A Secani ehhez a munkához összekapcsolhatja a célrendszereket, a kontrollkövetelményeket, a megvalósítási leírásokat, a bizonyítékokat, a felelősöket és a felülvizsgálati döntéseket. Csatolja a védelmi térképet és az anonimizált tesztnyilvántartásokat a releváns rendszerekhez és kontrollokhoz, alakítsa a kulcshozzáféréssel vagy helyreállítással kapcsolatos nyitott kérdéseket feladatokká, és őrizze meg, miért hagyták jóvá az egyes kriptográfiai döntéseket. Az MI-támogatott javaslatokat vesse össze a forrásaikkal, és tartsa kifejezetté az emberi jóváhagyást.

Kezdjen egyetlen érzékeny adattárral, és kövesse végig együtt az adathozzáférést, a kulcshozzáférést és a helyreállítást. Válasszon ki egy negatív jogosultsági tesztet és egy visszaállítási gyakorlatot, jelöljön ki felelősöket, és rögzítse az eredményeket, mielőtt kiterjesztené a hatókört. A felhőbiztonsági útmutatónk adja meg a környező konfigurációs kontextust.