Hozzáférés-vezérlés titkosítási kulcsokhoz: Ajánlott gyakorlatok
A titkosítási kulcsok védelme ugyanolyan fontos, mint az adatok titkosítása. A nem megfelelő kulcshozzáférés-vezérlés adatvédelmi incidensekhez, szolgáltatás-megszemélyesítéshez és végleges adatvesztéshez vezethet. Íme, amit tudnia kell a kulcsai biztonságának megőrzése érdekében:
- A legkisebb privilégium elve: Csak az adott feladatokhoz szükséges minimális jogosultságokat adja meg. Kerülje a túl tág jogosultságokat, mint például a
km:*és szigorú hozzáférési szabályokat kell érvényesíteni. - Szerepköralapú hozzáférés-vezérlés (RBAC): Különítse el a kulcskezelési (pl. adminisztrátorok) és a kriptográfiai műveletek (pl. felhasználók) szerepköreit. Kerülje az átfedéseket a felelősségi körökben.
- Központosított kulcskezelés: Használjon olyan eszközöket, mint az AWS KMS, a Google Cloud KMS vagy az Azure Key Vault az egységes és biztonságos kulcskezelés érdekében.
- Hardveres biztonsági modulok (HSM-ek): A erősebb védelem érdekében tárolja a kulcsokat biztonsági hardverben. A felügyelt HSM-ek leegyszerűsítik az integrációt és biztosítják a FIPS-megfelelőséget.
- Monitoring és naplózás: Részletes naplózás engedélyezése mind az adminisztrátori tevékenységekről, mind a kulcshasználatról. Riasztások beállítása szokatlan viselkedések vagy magas kockázatú műveletek esetén.
- Kulcscsere és -visszavonás: Rendszeresen cserélje a kulcsokat a kockázat csökkentése érdekében. Azonnal vonja vissza a veszélyeztetett kulcsokat, és késedelem nélkül cserélje ki azokat.
A következő lépések követésével biztosíthatja a titkosítási kulcsok biztonságát, csökkentve a kockázatokat és megőrizve az adatok integritását.
PKI 101: privát titkosítási kulcs tárolása és használata
sbb-itb-59e1987
Legalacsonyabb jogosultság alkalmazása a kulcskezelésre
Kulcsfontosságú adminisztrátori és kulcsfelhasználói szerepkörök és engedélyek
Mit jelent a legkisebb privilégium?
A legkisebb jogosultságok elve (PoLP) arra összpontosít, hogy a felhasználók és szolgáltatások csak azokat az engedélyeket kapják, amelyekre feltétlenül szükségük van a feladataik elvégzéséhez – semmi többet. A kulcskezelésre alkalmazva ez azt jelenti, hogy gondosan ellenőrizni kell, hogy kik titkosíthatják, dekódolhatják, módosíthatják a szabályzatokat vagy törölhetik a kulcsokat.
"Egyetlen AWS-azonosító sem rendelkezik semmilyen jogosultsággal egy KMS-kulcshoz, kivéve, ha ezt az engedélyt explicit módon megadják, és soha nem tagadják meg. Nincsenek implicit vagy automatikus jogosultságok a KMS-kulcs használatára vagy kezelésére." – AWS Key Management Service
Ez az "alapértelmezett tiltás" megközelítés a biztonság egyik sarokköve. Még a fióktulajdonos vagy a kulcsot létrehozó személy sem rendelkezik automatikusan jogosultságokkal – azokat explicit módon meg kell adni neki. Ez a szigorú ellenőrzés jelentősen csökkenti a potenciális sebezhetőségeket. Ha egy hitelesítő adat veszélybe kerül, a kár az adott identitáshoz rendelt konkrét engedélyekre korlátozódik. Például egy feltört "Kulcsfelhasználó" hitelesítő adat nem teszi lehetővé a kulcs törlését, ha nem biztosítottak rendszergazdai jogokat.
A minimális jogosultságok érvényesítésének elmulasztása súlyos következményekkel járhat. Megfelelő korlátozások nélkül a támadók a kulcsszabályzatok módosításával növelhetik jogosultságaikat, hogy teljes kontrollt szerezzenek maguknak. Ami még rosszabb, a kulcsok törlését is ütemezhetik, ami véglegesen megsemmisíti a titkosított adatokat. Az AWS legalább 7 napos (és legfeljebb 30 napos) várakozási időt ír elő a kulcsok törlésére, mert Ha egy kulcsot törölnek, a vele titkosított adatok örökre elvesznek.
Ezen vezérlők hatékony megvalósításához a szerepköralapú hozzáférés-vezérlés (RBAC) kritikus eszközzé válik.
Szerepköralapú hozzáférés-vezérlés (RBAC) beállítása
Az RBAC leegyszerűsíti a minimális jogosultságok elosztását azáltal, hogy a jogosultságokat a következők alapján rendeli hozzá: munkaköröket egyének helyett. Ahelyett, hogy felhasználónként kezelné az engedélyeket, olyan szerepköröket definiál, mint a "Kulcsgazda" és a "Kulcsfelhasználó", és a felelősségi körük alapján rendeli hozzájuk az embereket.
Az RBAC egyik kulcsfontosságú elve az elválasztás adminisztratív feladatok -tól kriptográfiai műveletek. A kulcsadminisztrátorok kezelik a kulcsok életciklusát – létrehozását, engedélyezését vagy letiltását, a szabályzatok frissítését és a törlés ütemezését. A kulcsfelhasználók ezzel szemben titkosítást és visszafejtést végeznek. Ezeknek a szerepköröknek soha nem szabad átfedésben lenniük ugyanazon kulcsok esetében.
| Szerepkör típusa | Tipikus engedélyek | Célja |
|---|---|---|
| Kulcsadminisztrátor | Létrehozás, Engedélyezés/Letiltás, PutKeyPolicy, ScheduleKeyDeletion, Címkézés | Kezeli a kulcsfontosságú életciklusokat, a metaadatokat és a hozzáférési szabályzatokat |
| Kulcsfontosságú felhasználó | Titkosítás, Visszafejtés, Újratitkosítás, Adatkulcs generálása, Kulcs leírása | A kulcsot használja az adatokon végzett titkosítási műveletekhez |
Az RBAC konfigurálásakor kerülje a helyettesítő karakteres engedélyek használatát, mint például a km:* a szabályzatokban. Mindig adja meg a kulcs ARN-jét vagy erőforrás-azonosítóját. A helyettesítő karakterek akaratlanul is hozzáférést biztosíthatnak más fiókokban vagy régiókban található kulcsokhoz. Ezenkívül használjon külön kulcsokat a különböző adattípusokhoz – az ügyféladatokhoz, a pénzügyi nyilvántartásokhoz és a belső kommunikációhoz mindegyiknek saját kulcsot kell használnia. Ez biztosítja, hogy ha egy hitelesítő adat veszélybe kerül, csak az adatok egy meghatározott részhalmaza legyen veszélyben.
A fokozott védelem érdekében szükséges Többtényezős hitelesítés (MFA) olyan érzékeny műveletekhez, mint a kulcs törlésének ütemezése vagy a kulcsszabályzatok módosítása. Egy másik hasznos réteg a titkosítási kontextus, amely az engedélyeket adott metaadatokhoz köti. Ezek a nem titkos kulcs-érték párok biztosítják, hogy egy kulcs csak akkor tudja visszafejteni az adatokat, ha a titkosítás során használt kontextust használják, ami további védelmet nyújt a jogosulatlan felhasználás ellen – még akkor is, ha maga a kulcs veszélybe kerül.
Központosított kulcshozzáférés-kezelés
A központosított menedzsment előnyei
A központosított kulcskezelés a minimális jogosultságok és a meghatározott szerepkörök elvén alapul, segítve a szervezeteket az egységes biztonsági gyakorlatok érvényesítésében. Azáltal, hogy a titkosítási kulcsokat egyetlen fiókból vagy projektből kezelik, a vállalkozások elkerülhetik a kulcsok több környezetben való zsonglőrködésének kellemetlenségeit. Ahelyett, hogy külön fiókokkal kellene foglalkozniuk a kulcsok életciklusaihoz, az adminisztrátorok egy egységes konzolra támaszkodhatnak. Ez különösen fontossá válik a szervezetek növekedésével, ahol a nagyszámú kulcs kezelése egyszerűsített megközelítést igényel.
"A kulcsok és végpontok csoportosításának, valamint a szerepkörök és szabályzatok ezen csoportokhoz való hozzárendelésének lehetősége egyetlen módja annak, hogy kezeljük azt, ami akár több millió kulcsot és műveletet is jelenthet." – Nisha Amthul, a Thales vezető termékmarketing-menedzsere
A központosított rendszerek a következetes biztonsági intézkedések érvényesítésével csökkentik a hibás konfigurációk esélyét is. Csökkentik az olyan kockázatokat, mint a kulcsok véletlen törlése vagy a jogosultságok eszkalációja, mivel a helyi rendszergazdák nem kapnak ellenőrizetlen jogosultságot a kritikus kulcsok felett.
"Ez a központosított modell segíthet minimalizálni a kulcsok nem szándékos törlésének vagy a jogosultságok eszkalációjának kockázatát a delegált adminisztrátorok vagy felhasználók által." – AWS előírásos útmutató
Egy másik jelentős előny az adminisztratív feladatok és az adathozzáférés szétválasztása. Ez nemcsak a megfelelőséget erősíti, hanem a felelősségek egyértelmű megosztásával leegyszerűsíti az auditokat is. A központosított naplózás ezt tovább fokozza azáltal, hogy az összes kulcsfontosságú hozzáférési eseményt egyetlen auditnaplóba konszolidálja, így könnyebbé válik a tevékenységek nyomon követése és áttekintése.
Ezeket az előnyöket szem előtt tartva a megfelelő központosított kulcskezelő eszköz kiválasztása létfontosságú lépés a hatékony és biztonságos kulcséletciklus-kezelés biztosításában.
Központosított kulcskezelési eszközök
Számos eszköz áll rendelkezésre a központosított kulcskezelés egyszerűsítésére:
- AWS kulcskezelő szolgáltatás (KMS): A root kulcsokat FIPS 140-2 vagy 140-3 3-as szintű, validált hardveres biztonsági modulokkal (HSM) védi, és zökkenőmentesen integrálódik más AWS szolgáltatásokkal az egységes auditálás érdekében.
- Google Cloud KMS: Ügyfél által kezelt titkosítási kulcsokat kínál szoftveres, HSM és külső kulcskezelő védelmi szintekkel.
- Azure Key Vault: Központosítja a kulcsok, titkos kódok és tanúsítványok tárolását, miközben beépített szerepköralapú hozzáférés-vezérlést is tartalmaz.
A többfelhős környezetben működő szervezetek számára további eszközök biztosíthatnak egységes felületet:
- A HashiCorp Vault kulcskezelő titkait kezelő motorja: Egységes munkafolyamatot biztosít a kulcsok AWS KMS, Azure Key Vault és Google Cloud KMS rendszereken történő kezeléséhez egyetlen felületről.
- Thales Cipher Trust Manager: Egyetlen konzolon keresztül felügyeli a szerverek, tárolórendszerek és felhőplatformok kulcsfontosságú életciklusait.
Eszköz kiválasztásakor azokat részesítse előnyben, amelyek részletes hozzáférés-vezérlést támogatnak a minimális jogosultságok elvének megerősítése érdekében. Az automatizálási képességek egy másik kulcsfontosságú szempont. Míg az erős automatizálási rendszerekkel rendelkező szervezetek decentralizált beállításokat is kezelhetnek, a központosított felügyelet gyakran jobban megfelel a manuális folyamatoknak. Értékelje az Ön konkrét igényeit, például a megfelelőségi követelményeket (pl. FIPS 140-3 3. szintű validáció), az életciklus-vezérlést és a fiókonkénti szolgáltatási kvótákat, hogy a szervezete számára legjobb választást hozhassa meg.
Főbb irányelvek és a feladatok szétválasztása
Kulcsfontosságú irányelvek létrehozása és betartatása
A kulcsokra vonatkozó irányelveknek a kulcs életciklusának minden szakaszát le kell fedniük – a létrehozásától a végső megsemmisítéséig. Világos dokumentáció nélkül nagyobb a kockázata a kulcsok visszaélésszerű használatának.
A szabályzatnak pontosan meghatározott felelősségi körökkel kell rendelkeznie a megfelelő szerepkörökhöz. Például:, Kriptográfiai tisztek kezelhet olyan feladatokat, mint a kulcsgenerálás és a biztonsági mentések, miközben Biztonsági auditorok A megfelelőség biztosítására kell összpontosítani. Ez az egyértelmű felosztás kiküszöböli a kétértelműségeket és biztosítja az elszámoltathatóságot. Minden egyes kulcsról naprakész leltárt kell vezetni, amely részletezi a létrehozási dátumát, a titkosítási algoritmust (például 3072 bites RSA), a jóváhagyott felhasználási módokat és a tulajdonjogot.
Használjon erőforrás-alapú és identitás-alapú szabályzatok kombinációját a hozzáférés szabályozásához. Az erőforrás-alapú szabályzatok az engedélyeket adott kulcsokhoz kötik, míg az identitás-alapú szabályzatok a felhasználói és szerepköri műveleteket szabályozzák. Az "alapértelmezett megtagadás" megközelítés megerősítéséhez adjon meg pontos ARN-eket és korlátozza a bizalmas engedélyeket. Például korlátozza a kms:ÜtemezésiKulcsTörlés engedélyt ad a megbízható azonosítóknak, biztosítva a minimális várakozási időt a törléshez. Az AWS KMS alapértelmezett 7 napos várakozási időt érvényesít (amely akár 30 napra is meghosszabbítható), mielőtt véglegesen törölne egy kulcsot, csökkentve ezzel a véletlen adatvesztés kockázatát.
"Egyetlen AWS-tag sem, beleértve a fiók root felhasználóját vagy a kulcs létrehozóját sem, rendelkezik semmilyen jogosultsággal egy KMS-kulcshoz, kivéve, ha az kifejezetten engedélyezett, és nincs kifejezetten megtagadva egy kulcsirányelvben, IAM-irányelvben vagy engedélyezésben." – AWS előírásos útmutató
A kulcsfontosságú vezetői felelősségek szétválasztása
Miután robusztus kulcspolitikákat hozott létre, a következő lépés a feladatok megosztása a kockázatok minimalizálása érdekében. A kulcsadminisztráció és a kriptográfiai műveletek elkülönítésével csökkentheti annak valószínűségét, hogy egyetlen személy veszélyeztesse a kulcs biztonságát. Például a kulcsot kezelő személy soha nem férhet hozzá a védett adatokhoz. Ez a megosztás nemcsak a csalás vagy hibák kockázatát csökkenti, hanem megakadályozza a jogosultságok eszkalációját is.
Világosan meghatározni a szerepeket, mint például Kulcsfontosságú adminisztrátorok, akik felügyelik a kulcsfontosságú életciklusokat, a létrehozást és a rotációt, valamint Kulcsfontosságú felhasználók, akik a titkosítási, visszafejtési és aláírási műveleteket kezelik. Kerülje az olyan tág szerepkörök kiosztását, mint a "Tulajdonos" vagy a "Szerkesztő", amelyek az adminisztratív és az operatív feladatokat ötvözik. Ehelyett ragaszkodjon a szűken meghatározott szerepkörökhöz, amelyek a minimális jogosultságok elvét követik.
Nagy téttel járó műveletek esetén alkalmazzon többpárti hitelesítési technikákat, például Shamir titkos megosztását, hogy biztosítsa, hogy egyetlen személy se férhessen hozzá a kulcshoz. A bizalmas műveletekhez többtényezős hitelesítést (MFA) kell alkalmazni, és a biztonság további fokozása érdekében ossza meg a jelszavakat és az MFA-eszközöket több személy között.
A jelszavakat igyekszem a titkosítási kulcsokhoz vezető “első ajtóként” kezelni: ha ez az ajtó gyenge, minden más biztonsági réteg inkább díszítőelemmé válik. Ezért egyszerűen és szigorúan tartom a dolgokat: egy fiók = egy egyedi, hosszú jelszó, újrafelhasználás és “apróbb variációk” nélkül, mint például a Jelszó123! → Jelszó124!. Ezeket a jelszavakat nem tárolom jegyzetekben, és nem küldöm el chaten; ehelyett egy… jelszókezelő és mindenhol engedélyezem az MFA-t, ahol elérhető. Amikor pedig a kritikus rendszerekhez való hozzáférést meg kell osztani, kerülöm az “egy közös jelszót mindenkinek”, és külön fiókokat és szerepköralapú engedélyeket szorgalmazok, mert így világosabb, hogy ki mit csinált, és sokkal könnyebb gyorsan visszavonni a hozzáférést, ha valami hiba történik.
A 2011-es RSA-támadás intő példa. Ebben az esetben a kulcskezelési feladatok nem megfelelő szétválasztása lehetővé tette a támadók számára, hogy kétfaktoros hitelesítési tokeneket klónozzanak, ami jól mutatja a laza szerepmegosztás veszélyeit.
A monitorozás automatizálása egy másik kritikus lépés. Használjon eszközöket az engedélyek átfedésének észlelésére és megjelölésére, amely a feladatköri szétválasztás megsértésére utalhat. A szolgáltatásfiók-elemzések azonosíthatják a 90 napnál régebb óta nem használt fiókokat is, jelezve, hogy azokat le kell tiltani vagy el kell távolítani a szükségtelen hozzáférések csökkentése és az aktív kulcsok számának korlátozása érdekében.
Hardveres biztonsági modulok (HSM) használata kulcsvédelemhez
Hardveres biztonsági modulok megértése
A hardveres biztonsági modul (HSM) egy speciális eszköz, amelyet a titkosítási kulcsok biztonságos, manipulációbiztos környezetben történő védelmére terveztek. A szoftveralapú megoldásokkal ellentétben a HSM-ek dedikált kriptoprocesszor-chipekre támaszkodnak, amelyek manipulációbiztos csomagolásban vannak. Ez a beállítás biztosítja, hogy A titkosítási kulcsok generálása és tárolása teljes egészében a hardver határain belül történik, soha nem maradnak nyílt szöveg formájában.
A fejlett HSM-ek olyan manipulációra reagáló mechanizmusokat tartalmaznak, amelyek azonnal lenullázzák (véglegesen törlik) az érzékeny kulcsanyagokat fizikai behatolás észlelése esetén. A legtöbb HSM megfelel a következő követelményeknek: FIPS 140-2 vagy 140-3 3. szint tanúsítási szabványokat, amelyek hardveres elkülönítést kínálnak, messze felülmúlva a kizárólag szoftveres módszereket.
Manapság a felhőszolgáltatók felügyelt HSM-ek (HSM-ek) révén egyszerűsítik a technológiához való hozzáférést. Ezek a szolgáltatások FIPS-kompatibilis hardverbiztonságot nyújtanak fizikai eszközök igénylése nélkül. A felügyelt HSM-ek jellemzően biztosítják a következőket: 99.99% elérhetőség az adatok több régió közötti replikálásával. A hozzáférés két síkra oszlik: a Irányítósík, amely az erőforrás-kezelést kezeli (pl. létrehozás, törlés, konfigurálás), és a Adatsík, amely olyan kriptográfiai műveleteket kezel, mint a titkosítás, a visszafejtés és az aláírás. Ez az elkülönítés biztosítja, hogy az adminisztratív feladatok elkülönüljenek az érzékeny kulcsokhoz való közvetlen hozzáféréstől.
A HSM-ek rendszerbe integrálásával erősebb hozzáférés-vezérlést hozhat létre, és hatékonyan biztosíthatja a kulcsfontosságú műveleteket.
HSM-ek integrálása a rendszereivel
A HSM-ek integrálása az infrastruktúrába fokozza a kulcsbiztonságot azáltal, hogy az érzékeny anyagokat védett hardveres határokon belül tartja. Az első lépés a robusztus hozzáférés-vezérlés beállítása mind a vezérlő-, mind az adatsíkokhoz. Használjon felügyelt identitásokat az alkalmazásokhoz a HSM-mel történő hitelesítéshez, így nem kell a hitelesítő adatokat a kódban vagy a konfigurációs fájlokban tárolni. A szerepköröket körültekintően ossza ki – a felhőszintű szerepkörök, mint például a "Key Vault Contributor" (kulcstároló-közreműködő), magát a HSM-et kezelik, míg a HSM-helyi szerepkörök, mint például a "Crypto Officer" (kriptográfiai tisztviselő) vagy a "Crypto User" (kriptográfiai felhasználó), kriptográfiai feladatokat kezelnek. Korlátozza az engedélyeket adott kulcsokra (pl., /kulcsok/) a teljes HSM-hez való hozzáférés biztosítása helyett.
A fokozott biztonság érdekében hozzon létre egy biztonsági tartományi kvórumot legalább három RSA kulcspár használatával, amelyek mindegyikét más-más rendszergazda kezeli. Ez a beállítás biztosítja, hogy egyetlen személy se tudja teljes mértékben helyreállítani vagy feltörni a HSM-et. Tartsa ezeket a helyreállítási kulcsokat titkosított, offline USB-meghajtókon, külön széfekben. Engedélyezze az olyan funkciókat, mint a soft törlés (7-90 napos megőrzési időszakkal) és a törlés elleni védelem a kulcsok véletlen vagy rosszindulatú törlése ellen.
A hálózati kommunikáció biztonságossá tételéhez tiltsa le a nyilvános internet-hozzáférést, és az összes HSM-forgalmat privát végpontokon keresztül irányítsa át. Szigorúan szabályozott környezetek esetén érdemes megfontolni a "Hold Your Own Key" (HYOK) megközelítést. Ez a modell a kulcsokat egy külső HSM-ben tárolja, soha nem teszi elérhetővé azokat a felhőszolgáltató infrastruktúrája számára. Emellett dupla titkosítást is használ: az adatokat először a felhőszolgáltató, majd a külső HSM titkosítja, így biztosítva, hogy egyik fél sem férhessen hozzá függetlenül a nyílt szöveghez.
A biztonságot tovább növelheti a Privileged Identity Management Just-in-Time hozzáférésével, amely csak szükség esetén biztosít ideiglenes rendszergazdai jogosultságokat. A kulcsokat "nem exportálhatóként" jelölheti meg, hogy azok a hardveres határokon belül maradjanak, és automatizált kulcsrotációs ütemterveket alkalmazhat az időbeli támadások kockázatának minimalizálása érdekében.
Kulcshozzáférés monitorozása, auditálása és naplózása
A szigorú kulcskezelési és hardverbiztonsági gyakorlatok bevezetése után elengedhetetlen a hozzáférések szoros figyelemmel kísérése monitorozás és naplózás révén, hogy a potenciális incidenseket időben észlelni lehessen.
Hozzáférés-felügyelet beállítása
A kulcshozzáférések nyomon követése kritikus fontosságú a jogosulatlan használat észleléséhez, mielőtt az problémát okozna. Kezdje azzal, hogy különbséget tesz a következők között: Adminisztrátori tevékenységnaplók (amelyek olyan műveleteket rögzítenek, mint a kulcsok létrehozása vagy a szabályzatok frissítése) és Adathozzáférési naplók (amelyek olyan kriptográfiai műveleteket követnek nyomon, mint a titkosítás és a visszafejtés). Bár az adathozzáférési naplók gyakran alapértelmezés szerint ki vannak kapcsolva a keletkező hatalmas mennyiség miatt, a legérzékenyebb kulcsok esetében az engedélyezésük okos lépés.
Határozzon meg egy tipikus használati alapértéket mind az adat-, mind a vezérlési síkbeli tevékenységekhez. Ez megkönnyíti a szokatlan viselkedés észlelését, például a visszafejtési kérelmek számának növekedését egy szokatlan órában, vagy azt, hogy egy rendszergazda olyan kulcsokhoz fér hozzá, amelyeket korábban soha nem használt. Küldje el az auditnaplókat automatizált felügyeleti eszközöknek, mint például CloudWatch riasztások riasztások kiváltására magas kockázatú események esetén, például Ütemezett kulcs törlése, DisableKey, vagy jogosulatlan szabályzatmódosítások.
Használja ki a naplókban egyszerű szövegként látható titkosítási kontextus kulcs-érték párokat a tevékenységek kategorizálásához anélkül, hogy bizalmas adatokat kellene felfednie. Fordítson különös figyelmet a címkemódosításokra, mivel azok jogosulatlanul történtek. Címkeforrás vagy UntagResource A műveletek kiterjeszthetik a jogosultságokat. Ne feledje, hogy a címkék vagy aliasok módosításainak hatása a KMS-kulcsok jogosultságaira akár 5 percig is eltarthat, ezért a figyelési beállításoknak figyelembe kell venniük ezt a késleltetést.
A hatékony hozzáférés-felügyelet természetesen hozzájárul a részletes auditnaplók létrehozásához a teljes átláthatóság érdekében.
Auditnaplók és naplók létrehozása
A monitorozás kiegészítéseként gondoskodjon alapos naplózási rendszerről a biztonságos auditnapló létrehozása érdekében. Ez a megközelítés segít fenntartani az elszámoltathatóságot, és felkészíti Önt a kriminalisztikai vizsgálatokra. Használjon legalább kétféle auditeszközt a redundancia érdekében. Eszközök, mint például HashiCorp Vault úgy vannak kialakítva, hogy blokkolják az API-kéréseket, ha nem tudnak legalább egy eszközre naplózni, megakadályozva a nyomon nem követett hozzáférést.
Továbbítsa a naplókat egy távoli rendszerre, hogy megvédje őket a manipulációtól, és biztosítsa a megfelelőségi auditokhoz való elérhetőségüket. A fokozott biztonság érdekében használjon kulcsolt hasheket (pl. HMAC-SHA256) az érzékeny naplóadatok védelméhez, miközben azok auditálhatók maradnak. Állítson be riasztásokat kritikus eseményekhez, például a root token használatához, az auditkonfigurációk változásaihoz vagy az "engedély megtagadva" hibák számának növekedéséhez. Ne felejtse el megvalósítani a naplórotációt (pl. a következő használatával: logrotáció) és konfigurálja a HUP jeleket a megszakítás nélküli naplózás biztosítása érdekében.
Központosítsa és összesítse az összes projekt vagy fiók naplóit egyetlen adattárba a szervezet egészére kiterjedő láthatóság érdekében. Ez nemcsak leegyszerűsíti a felügyeletet, hanem támogatja a szabványoknak, például a PCI DSS-nek, a FedRAMP-nak és a HIPAA-nak való megfelelést is. Legyen azonban tudatában annak, hogy az adathozzáférési naplók engedélyezése növelheti a költségeket a nagyobb adatmennyiség miatt.
Kulcsrotációs és visszavonási gyakorlatok
A titkosítási kulcsok nem örökkévalóságra lettek tervezve. A rendszeres cserélés és az időben történő visszavonás elengedhetetlen ahhoz, hogy megakadályozzuk az elavult vagy veszélyeztetett kulcsok általi bizalmas adatok veszélyeztetését.
Mikor és miért kell forgatni a billentyűket
A titkosítókulcsok rotációja segít korlátozni az egyetlen kiszivárgott kulcs által okozott károkat. Ahelyett, hogy egyetlen kulcs évekig védené az adatokat, a rotáció biztosítja, hogy minden kulcs csak egy adott időtartamig érvényes legyen. Például a PCI DSS előírja az éves kulcsrotációt, de a nagyon érzékeny adatok, például a kártyabirtokosi adatok esetében a negyedéves rotáció biztonságosabb megoldás. A szolgáltatásfiók-kulcsok esetében a szakértők azt javasolják, hogy legalább 90 naponta cseréljék azokat, hogy minimalizálják a kiszivárgott hitelesítő adatok kockázatát.
A rotációs gyakoriságnak az adatok érzékenységétől és a kulcs használatának gyakoriságától kell függenie. Például a NIST azt javasolja, hogy az AES-256-GCM kulcsokat a körülbelül 4,3 milliárd titkosítás elérése előtt cseréljék le. Hasonlóképpen, az Azure Key Vault azt javasolja, hogy a titkosító kulcsokat legalább kétévente cseréljék le. A nagy igénybevételű kulcsok nagyobb kriptoanalitikai kockázatokkal néznek szembe, így a titkosítások számának telemetrián keresztüli nyomon követése segíthet meghatározni a rotáció esedékességét, ahelyett, hogy kizárólag egy naptári ütemtervre hagyatkoznánk.
A folyamat zökkenőmentesebbé és hibamentesebbé tétele érdekében az olyan automatizáló eszközök, mint a HashiCorp Vault vagy a Cloud KMS, képesek kezelni a kulcsrotációt. Ezek az eszközök kulcsverziókezelést használnak, ahol az új adatokat a legújabb kulccsal titkosítják, míg a régebbi kulcsok visszafejtik a korábbi adatokat. Ez lehetővé teszi a fokozatos, "lusta" újratitkosítási folyamatot, amely az adatokat a hozzáférés során frissíti.
De a rotáció önmagában nem mindig elég. Amikor behatolás történik, a kulcs visszavonása a következő kritikus lépés.
Kulcsok visszavonása a kockázatok csökkentése érdekében
A kulcs visszavonása egy gyors reagálású intézkedés arra az esetre, ha egy kulcs veszélybe kerül, egy hozzáféréssel rendelkező alkalmazott távozik, vagy más biztonsági esemény történik. Az időzítés mindennél fontosabb – a visszavonásnak ideális esetben a probléma azonosításától számított 24 órán belül meg kell történnie.
Így működik: Először azonosítsa a veszélyeztetett kulcsot, és generáljon egy biztonságos cserét. Telepítse az új kulcsot az összes rendszerre, majd tiltsa le a régit. Azonban ne törölje azonnal – ez a türelmi időszak lehetővé teszi, hogy figyelje a letiltott kulcshoz továbbra is kapcsolódó hibákat vagy függőségeket. Miután megerősítette, hogy a kritikus rendszerek nincsenek érintve, frissítse a konfigurációkat, titkosítsa újra a szükséges adatokat, és véglegesen törölje a régi kulcsot.
"A veszélyeztetett kulcsok azonnali visszavonásának elmulasztása lehetővé teszi a további jogosulatlan visszafejtést. A nem megfelelő kulcskezelési gyakorlatok használhatatlanná teszik a titkosítást, és az adatok ki vannak téve." – SSL támogatási csapat, SSL.com
A rossz kulcskezelés következményeinek ékes példája a 2011-es RSA biztonsági incidens. A támadók több millió SecurID tokenek kriptográfiai "vetőértékét" lopták el, mivel az RSA nem tudta biztosítani a vetőadatbázist és megfelelő hozzáférés-vezérlést érvényesíteni. Ez a incidens rávilágít a gyors és hatékony kulcskezelési gyakorlatok fontosságára az érzékeny adatok védelme érdekében.
Következtetés
Az erős kulcshozzáférés-vezérlés elengedhetetlen az érzékeny adatok védelméhez. A minimális jogosultságok elvének alkalmazásával, a feladatok szétválasztásával és hardveralapú védelemmel, például FIPS 140-2 3. szintű validált HSM-ekkel szilárd alapot teremthet a biztonságos kulcskezeléshez. Ezek a stratégiák kritikus fontosságúak mind a véletlen adatszivárgás, mind a szándékos adatvédelmi incidensek megelőzésében.
"Egyetlen AWS-tag sem, beleértve a fiók root felhasználóját vagy a kulcs létrehozóját sem, rendelkezik semmilyen jogosultsággal egy KMS-kulcshoz, kivéve, ha az kifejezetten engedélyezett, és nincs kifejezetten megtagadva egy kulcsirányelvben, IAM-irányelvben vagy engedélyezésben." – AWS előírásos útmutató
További védelmet nyújtanak a további intézkedések, mint például a kényszerített várakozási idők és a többtényezős hitelesítés. A többtényezős hitelesítés különösen extra biztonsági réteget biztosít azáltal, hogy korlátozza a jogosulatlan kulcsmódosításokat. Az automatikus kulcsrotáció, amely jellemzően 90 naponta történik, szintén minimalizálja a kockázatot azáltal, hogy csökkenti a feltört kulcs által okozott lehetséges károkat.
A hatékony kulcskezelés állandó figyelmet igényel. Ahogy a szervezetek növekednek, a személyzeti áthelyezések és az új kockázatok felmerülnek, a hozzáférés-vezérlésnek is fejlődnie kell. A rendszeres auditok kulcsfontosságúak a túlzottan privilegizált szerepkörök azonosításához, míg a valós idejű monitorozás kulcsfontosságú a szokatlan hozzáférési tevékenységek észleléséhez, mielőtt azok fenyegetést jelentenének. Az olyan funkciók, mint az automatikus kiépítés, a valós idejű riasztások és a titkosítási kontextus együttesen biztosítják a kulcsok biztonságát teljes életciklusuk alatt.
GYIK
Mi a legbiztonságosabb módja a kulcsadminisztrátori és kulcsfelhasználói hozzáférések szétválasztásának?
A biztonság érdekében érdemes betartani a a feladatok szétválasztásának elve. Ez azt jelenti, hogy a felelősségeket úgy kell megosztani, hogy egyetlen személy se tudjon egyszerre adminisztratív és operatív feladatokat ellátni. Például jelöljön ki Kulcsfontosságú adminisztrátorok a kulcslétrehozás és a szabályzatkezelés felügyelete, miközben Kulcsfontosságú felhasználók olyan kriptográfiai feladatokra összpontosítson, mint a titkosítás és a visszafejtés. szerep alapú hozzáférés-vezérlés (RBAC) valamint részletes IAM-szabályzatokat kell kidolgozni ezen határok betartatására. Ezenkívül átfogó auditnaplókat kell vezetni a tevékenységek nyomon követésére és a jogosulatlan műveletek gyors azonosítására.
Mikor érdemes HSM-et használni szoftveres kulcstároló helyett?
A hardveres biztonsági modul (HSM) a legjobb megoldás, ha hardveralapú izoláció és szabotázsvédelem nem képezik alku tárgyát a rendkívül érzékeny kriptográfiai kulcsok védelme érdekében. A HSM-ek olyan forgatókönyvekben kiválóak, ahol a szigorú megfelelőségi szabványok betartása kritikus fontosságú, vagy ahol minimalizálni kell a biztonsági résekből és szoftveres sebezhetőségekből eredő kockázatokat.
A szoftveralapú kulcstárolással ellentétben a HSM-ek további biztonsági réteget biztosítanak, így a legmagasabb szintű védelmet igénylő környezetekben az előnyben részesített választást jelentik.
Hogyan tudom lecserélni a billentyűket anélkül, hogy leállnának az alkalmazások, vagy elveszíteném az adatokhoz való hozzáférést?
A titkosítási kulcsok közötti váltáshoz az alkalmazások megszakítása vagy az adatokhoz való hozzáférés elvesztése nélkül, tegye a következőket:
- Rotációk tervezése és ütemezése: Állítson be automatizált rendszereket, vagy ütemezze be a kulcsgenerálást szükség szerint új titkosítási kulcsok létrehozásához.
- Alkalmazások és adatok frissítése: Lépésről lépésre térjen át az új kulcsokra, a régi kulcsokat ideiglenesen aktívan tartva a kompatibilitás megőrzése érdekében.
- Figyelemmel kísérés és ellenőrzés: Alapos teszteléssel győződjön meg arról, hogy az alkalmazások zökkenőmentesen működnek a frissített kulcsokkal.
Ez a módszer segít fenntartani a biztonságot, miközben elkerüli a fennakadásokat.
