Tartson nyilván minden titkot és annak felelősét, hozzon létre minden környezethez külön, minimális jogosultságú identitásokat, az értékeket a kijelölt biztonságos tárolóban tárolja, soha ne naplózza őket, és rendszeresen tesztelje a rotációt, a visszavonást, a hozzáférés helyreállítását és a felelősség átadását is.
Az API-kulcs, a kliensjelszó, az aláírókulcs vagy az adatbázis-hitelesítő adat lehetővé teszi, hogy a rendszer a kiosztott jogosultságokkal cselekedjen. Ha ezeket forráskódba, e-mailbe vagy közös dokumentumba másolják, elvész az ellenőrzés afölött, hogy kinél vannak, és hogyan lehet őket visszavonni. A titkok biztonságos kezelése ezért üzemeltetési folyamat, nem az érték egyszeri elrejtése.
A cél a hozzáférés korlátozása, az érvényesség lerövidítése, ahol lehetséges, a környezetek szétválasztása, valamint a kaotikus leállás nélküli rotáció lehetővé tétele. A konkrét eszköz a tárhelytől és a kockázattól függ, de az alapelvek változatlanok. A titkos adat nem szivároghat ki sem naplón, sem biztonsági mentésen, sem hibaoldalon, sem a projekt átadása során.
Készítsen leltárt az identitásokról és a függőségekről
Minden titkos adatnál jegyezze fel a rendszert, a célt, a felelőst, a környezetet, a kiosztott jogosultságokat, a felhasználás helyét és a visszavonás módját. Magát az érzékeny értéket ne vegye fel a nyilvántartásba. Vegye fel a régi integrációs fiókokat, a helyi szkriptek kulcsait és a külső beszállító által létrehozott adatokat is. Az ismeretlen felelős üzemeltetési kockázatot jelent.
Térképezze fel, mely szolgáltatásokat kell frissíteni a kulcsrotáció során, és milyen sorrendben. Egyetlen, a weboldal, egy ütemezett feladat és egy riport által egyaránt használt kulcs láthatatlan függőséget hoz létre. A különálló identitások megkönnyítik a jogosultságok korlátozását, a diagnosztikát és egy konkrét integráció megszüntetését anélkül, hogy az a többi folyamatot érintené.
Különítse el a környezeteket, és ossza ki a legszűkebb jogosultságokat
A fejlesztési, a teszt- és az éles környezetnek eltérő fiókokat és értékeket kell használnia. A tesztkulcs nem férhet hozzá éles ügyféladatokhoz, és nem hajthat végre éles fizetéseket. Ha a szolgáltató nem kínál külön környezetet, hozzon létre korlátozott fiókot és biztonságos tesztadatokat. A különbségeket jelölje egyértelműen, hogy ne lehessen őket tévedésből kiválasztani.
Minden identitáshoz csak a feladatához szükséges műveleteket és erőforrásokat rendelje hozzá. A készletet olvasó integrációnak nem kell árakat vagy felhasználókat módosítania. A jogosultságokat rendszeresen vesse össze a tényleges használattal. A hatókör bővítése menjen át külön értékelésen, és maradjon nyoma, ki hagyta jóvá és miért.
- egy identitás egy adott integrációhoz
- külön értékek minden környezethez
- a legszűkebb szükséges jogosultsági kör
- egyértelmű felelős és fellebbezési út
Biztonságosan juttassa be a titkokat az alkalmazásba
Az éles környezeti érték nem kerülhet a repozitóriumba, a konténerképbe vagy a fejlesztő által terjesztett fájlba. Az alkalmazásnak indításkor vagy használatkor kell megkapnia egy védett konfigurációból, auditált hozzáféréssel. A titok olvasására vonatkozó jogosultságot csak a futó szolgáltatásnak és azoknak az embereknek adja meg, akik azt feltétlenül kezelik.
Ellenőrizze a hibaüzeneteket, a diagnosztikai kimeneteket, az analitikát és az ügyfélszolgálatot. A konfiguráció automatikus szerializálása szándékolatlanul is felfedheti az értéket. A naplókban a kulcs biztonságos azonosítóját vagy az utolsó ártalmatlan karaktereit használja, ha ez segíti a diagnosztikát. A szerkesztői felület mentés után ne jelenítse meg az éles környezet titkát.
Tervezze meg a rotációt nem tervezett leállás nélkül
A rotációhoz eljárás kell az új érték létrehozására, telepítésére, ellenőrzésére és a régi visszavonására. Ha a rendszer lehetővé teszi az egyidejű érvényességet, használjon rövid átmeneti időszakot, és figyelje, használja-e még valami a régi kulcsot. Ha nem teszi lehetővé, készítsen elő karbantartási ablakot vagy koordinált átkapcsolást visszaállítási lehetőséggel.
Az intervallumot ne határozza meg mechanikusan, a kockázat és a platform lehetőségeinek mérlegelése nélkül. Azonnal végezzen rotációt szivárgás gyanúja, jogosult személy távozása vagy beszállítóváltás esetén. Az automatizálás segít, de hiba esetén riasztást kell adnia. Az első rotációs tesztet még az incidens előtt végezze el, amikor van idő a javításra.
Készüljön fel az incidensekre és a biztonságos átadásra
Szivárgás esetén először azonosítsa az érintett identitást és jogosultságokat, vonja vissza vagy korlátozza azt, és ellenőrizze az auditnaplókat. Az érték puszta módosítása nem elég, ha a támadó újabb fiókot hozott létre vagy módosította a konfigurációt. Az incidenst az adatokra gyakorolt hatás és a szervezet kötelezettségei szerint, megfelelő szakemberek bevonásával kezelje.
A projekt átadásakor ne továbbítson titkokat hagyományos dokumentumban. Az új tulajdonos kapja meg a fiókok kezelését, a cserefolyamatot és a függőségek leltárát; az értékeket célszerű az átvétel után megújítani. Vonja vissza a korábbi csapat hozzáféréseit, és szüntesse meg az ideiglenes tokeneket. Ellenőrizze, hogy az üzemeltetés a beszállító rejtett személyes fiókja nélkül is folytatódik.
- a gyanús identitás azonnali visszavonása
- a kiszivárgott kulccsal végrehajtott műveletek ellenőrzése
- az összes kapcsolódó környezet rotációja
- személyes és ideiglenes fiókok eltávolítása
- a működés ellenőrzése a biztonságos átvétel után
- minden éles identitás dokumentált tulajdonosa
- begyakorolt helyreállítás sikertelen rotáció után
- titkokat tartalmazó mentések és exportok ellenőrzése
- a fel nem használt hitelesítő adatok rendszeres auditja
Gyakori kérdések
Biztonságos tárolóhely-e a környezeti változó?
Jobb, mint a kódba írt érték, de a biztonság a platformtól, a hozzáférésektől, a diagnosztikától és a telepítéstől függ. Az érzékenyebb rendszerek dedikált titokkezelést és korlátozott szolgáltatásidentitásokat használnak.
Milyen gyakran kell rotálni az API-kulcsokat?
Az intervallum a kockázatból, a követelményekből és a szolgáltató lehetőségeiből adódik. Fontosabb, hogy legyen ellenőrzött eljárás, és szivárgás, személyi változás vagy az ellenőrzés elvesztése esetén azonnal lehessen rotálni.
Használhat több integráció egyetlen kulcsot?
Technikailag néha igen, de ez megnehezíti a minimális jogosultságok elvének betartását, az auditot és a biztonságos visszavonást. Az integrációnként külön identitás általában csökkenti a hibák hatását, és megkönnyíti az üzemeltetést.