Správa tajných klíčů a konfigurace v cloudu
Aplikace běží v cloudu, ale heslo k databázi má celý tým v jednom souboru. Nikdo neví, které služby ho používají a co se stane při výměně. Správa tajemství má tento přehled vytvořit a umožnit změnu přístupu bez improvizace v produkci.
Začněte inventářem, vlastníky a odstraněním zbytečných trvalých klíčů. Správce tajemství pomůže s uložením a vydáním hodnot, ale odpovědnost za oprávnění, rotaci a reakci na únik zůstává součástí vašeho provozu. Běžnou konfiguraci spravujte podle jejího skutečného významu.
01Oddělte tajemství od ostatní konfigurace
Tajemstvím je například přístupové heslo, token služby nebo soukromý klíč. Jeho vyzrazení může umožnit nežádoucí přístup nebo jinou operaci. Běžná konfigurace popisuje chování systému, například název prostředí nebo povolenou funkci. Také ona může být citlivá, ale nepotřebuje automaticky stejný životní cyklus jako přihlašovací údaj.
Microsoft doporučuje používat Key Vault pro klíče, certifikáty a tajemství, nikoli jako obecné úložiště provozní konfigurace nebo zákaznického obsahu. Konkrétní služby mají různé účely. Nevybírejte jeden nástroj jen proto, že umí přijmout textovou hodnotu.
| Druh údaje | Příklad | Co řídit |
|---|---|---|
| Běžná konfigurace | Zapnutá funkce nebo adresa služby | Verzi, schválení a obnovu |
| Přístupové tajemství | Heslo nebo token integrace | Vydání, oprávnění a odvolání |
| Šifrovací klíč | Klíč pro chráněná uložená data | Použití a možnost dešifrování |
| Certifikát | Certifikát a případný soukromý klíč | Obnovu, řetězec a distribuci |
U každé hodnoty zapište, které služby ji potřebují, v jakém prostředí a kdo ji vlastní. Rozlišujte testovací a produkční přístup. Označení „API klíč“ bez názvu služby, oprávnění a podmínek platnosti není dostatečný inventář. Při odchodu kolegy nesmí znalost těchto vazeb odejít spolu s ním.
Do inventáře nevkládejte samotné tajné hodnoty. Stačí identifikátor, účel, vlastníci a vazba na chráněné uložení. Přehled má být použitelný při změně i incidentu, aniž by vznikl další seznam hesel. Zapište, zda odstranění položky ze správce skutečně odvolá přístup u cílové služby, nebo je potřeba samostatná operace.
02Omezte dlouhodobé údaje, kde to jde
Nejbezpečnější správa některých trvalých přístupů začíná tím, že je aplikace vůbec nepotřebuje. AWS doporučuje dočasné údaje a IAM role pro pracovní zátěže. Identita služby získá přístup podle nastavené role, místo abyste do každého nasazení ručně kopírovali dlouhodobý klíč uživatele.
V Azure může odpovídající scénář využít spravovanou identitu pro přístup do Key Vault. Nepřenášejte však název funkce mezi cloudy jako záruku stejného chování. Ověřte konkrétní běhové prostředí, způsob autentizace a potřebná oprávnění. Externí dodavatel nebo starší aplikace mohou stále vyžadovat jiný mechanismus.
Dočasná identita neřeší rozsah oprávnění sama. Služba má číst jen potřebná tajemství a provádět konkrétní operace. Oddělte identitu aplikace od identity člověka a nasazovacího procesu. Právo vydat nové tajemství nebo změnit politiku nemá automaticky získat každá služba, která potřebuje jednu hodnotu přečíst.
Pro každou výjimku s trvalým klíčem uveďte důvod a další kontrolu. Při změně dodavatele nebo běhového prostředí ověřte, zda už jde výjimku odstranit. Dlouhodobý přístup nesmí zůstat pouze proto, že byl první jednoduchou variantou během vývoje. Vyřazení nepoužívané integrace musí zahrnovat i její přístupové údaje.
03Nastavte hranice aplikací a prostředí
Oddělte vývoj, testování a produkci podle rizika a způsobu provozu. Sdílený přístup ke všem hodnotám zvětšuje dopad jedné chyby. U konkrétního nástroje ověřte hranice úložišť, role a přístup ke jednotlivým objektům. Microsoft jako běžné rozdělení popisuje samostatné vaulty podle aplikace, regionu a prostředí.
Lidé mají pracovat přes vlastní ověřené identity a dohledatelná oprávnění. Běžný vývoj často nevyžaduje čtení produkčních hesel. Připravte postup pro výjimečný zásah, schválení a odebrání přístupu. Nouzový přístup musí být dostupný i při problému hlavního přihlašování, ale jeho použití musí mít jasnou odpovědnost.
AWS Secrets Manager doporučuje nejmenší potřebná oprávnění, kontrolu širokého přístupu a audit. Samotné zašifrování uložených hodnot není náhradou přístupové politiky. Útočník nebo chybná služba s právem čtení může dostat dešifrovaný výsledek stejně jako oprávněná aplikace.
Zkontrolujte také síťová omezení a cesty automatizace. Politika, která vypadá bezpečně pro přístup člověka z kanceláře, může znemožnit rotaci nebo obnovu běžící služby. Prověřujte povolené i zakázané scénáře, včetně operací dodavatelských komponent. O širších hranicích pojednává bezpečnost v cloudu.
04Tajemství vydávejte bez zbytečných kopií
Rozhodněte, kdy a jak aplikace hodnotu získá. Může ji načíst při startu nebo podle potřeby přes podporovanou integraci. Nastavte práci s cache, verzi hodnoty a chování při nedostupnosti správce. Neopisujte citlivý údaj do dalšího souboru jen proto, aby se snáz kopíroval při nasazení.
Hodnota potřebná serverem nemá být zabalena do veřejného JavaScriptu nebo mobilního klienta. Distribuovaný klient je jiné bezpečnostní prostředí. Veřejné identifikátory některých služeb se mohou do klienta používat podle dokumentace, ale soukromé tajemství tam tímto způsobem nezíská ochranu. Každý údaj klasifikujte podle konkrétní služby a oprávnění.
OWASP rozebírá celý životní cyklus tajemství a upozorňuje na úniky přes konfiguraci kontejnerů i logování. Proměnná prostředí není sama automatickou zárukou bezpečí. Hodnota se může dostat do diagnostiky, výpisu procesu nebo chybové zprávy. Ověřte skutečné chování svého nasazení a podpůrných nástrojů.
Nasazovací pipeline potřebuje vlastní omezený přístup. Zkontrolujte výstupy buildů, testovací artefakty, exporty konfigurace a záznamy příkazů. Maskování jednoho přesného řetězce nemusí zachytit jeho jinou podobu. V článku o krádežích API klíčů navazuje riziko vývojového prostředí; zde řešíte trvalý provoz a distribuci.
05Rotaci naplánujte s příjemci nové hodnoty
Výměna hesla je změna napříč systémy. Musíte vědět, která služba ověřuje hodnotu, kdo ji čte a kdy se obnoví její místní kopie. Pokud změníte pouze položku ve správci, vzdálená služba může stále očekávat starý údaj. Pokud naopak nejdřív zrušíte starý přístup, část aplikace se může přestat připojovat.
Domluvte postup pro zavedení nové hodnoty, ověření provozu a odvolání staré. Některé služby umožní dočasný souběh více klíčů, jiné vyžadují odlišný plán. Konkrétní možnosti potvrďte s poskytovatelem. Automatická rotace musí být otestovaná jako celý řetězec, nikoli jen úspěšné spuštění naplánované úlohy.
- Zapište všechny příjemce a závislé operace.
- Ověřte načtení nové verze a chování cache.
- Zkontrolujte běžné i dlouho běžící úlohy.
- Odvolejte starou hodnotu a ověřte její nepoužitelnost.
Délku platnosti určujte podle typu tajemství, podpory systému a rizika. Pravidla pro strojové údaje nekopírujte bez rozlišení na hesla lidí. Šifrovací klíč navíc nemusí jít jednoduše zrušit, pokud je potřeba pro čtení starších dat. Před změnou ověřte obnovu a přístup k historickému obsahu. Rotace různých druhů materiálu má různé důsledky.
Rotaci si projděte také s pracovníkem podpory. Musí poznat změnu, která se ještě šíří, od chybného přihlášení nebo výpadku vzdálené služby. Záznam verze může pomoci bez zveřejnění její hodnoty. Pro dlouho běžící proces domluvte, zda si nový údaj načte sám, nebo potřebuje řízený restart s kontrolou rozpracovaných úloh.
06Připravte odvolání a reakci na únik
Při zveřejnění tajemství nestačí vymazat soubor nebo řádek v aktuální větvi repozitáře. Hodnota může existovat v historii, artefaktu nebo cizí kopii. Prioritou je podle situace omezit nežádoucí přístup, odvolat kompromitovaný údaj a zavést bezpečnou náhradu. Zásah musí zahrnout skutečnou službu, která klíč přijímá.
Sepište, kdo může tento krok provést a kde najde závislosti. Ověřte události přístupu a rozsah možného použití. Do vyšetřovacích podkladů nekopírujte samotné tajemství bez potřeby. Zaznamenávejte identitu, čas, objekt a operaci v rozsahu, který podporuje kontrolu a zároveň nevytváří nové nechráněné úložiště hodnot.
Vedle nečekaného čtení hlídejte změny politik, vypnutí rotace a pokusy použít odvolaný přístup. Alert potřebuje vlastníka a postup. Pokud se o něj nikdo nestará, auditní log pouze ukládá záznam problému. Domluvte také spolupráci s dodavatelem služby a přístup k potřebným důkazům.
Po zásahu odstraňte příčinu, která vedla k úniku. Může jít o chybný build, příliš široké oprávnění nebo běžné posílání hesel v chatu. Výměna jedné hodnoty bez opravy procesu připraví opakování stejné situace. Průběžně vyřazujte nepoužívaná tajemství a kontrolujte vlastníky, zejména po změnách týmu a integrací.
07Ověřte provoz na jedné integraci
Vyberte omezenou službu s jasným vlastníkem a přehlednými závislostmi. Zaveďte uloženou hodnotu, identitu, potřebná oprávnění a kontrolu načítání. Vyzkoušejte rotaci, výpadek správce i odvolání. Test provádějte v prostředí a rozsahu, který neohrozí skutečný provoz. Výsledek dokumentujte jako ověřený scénář, ne univerzální garanci.
- Inventarizujte údaje, vlastníky a příjemce.
- Omezte přístupy a vyberte způsob vydání.
- Projděte výměnu, odvolání a výpadek.
- Zapište provozní postup a pravidelnou kontrolu.
Přejímka má ověřit, že aplikace funguje s novou hodnotou a nepovolená identita ji nezíská. Prověřte také, zda se tajemství neobjeví v logu nebo artefaktu. U výpadku určete bezpečné chování podle služby. Tiché pokračování s neplatným údajem a nekonečné opakování mohou problém ještě zvětšit.
Provozní dokumentaci zpřístupněte oprávněným lidem nezávisle na sledované aplikaci. Obsahuje identifikátory a kontakty, nikoli kopii všech hesel. Při rozšiřování na další služby zachovejte společné zásady, ale ověřte konkrétní rozdíly. Úspěšná rotace databázového hesla neznamená připravenou obnovu všech šifrovacích klíčů firmy.
08Časté otázky ke správě tajemství
Patří každá konfigurace do správce tajemství?
Ne. Rozlišujte běžné nastavení, citlivé údaje, přístupová tajemství a kryptografický materiál. Pro každý typ zvolte vhodnou službu a provozní pravidla. Úložiště tajemství není obecná databáze.
Chrání proměnná prostředí heslo automaticky?
Není sama zárukou ochrany. Ověřte diagnostiku, build, logy a přístupy běhového prostředí. Tajemství nesmí být natvrdo vložené do veřejného klienta nebo kontejnerového artefaktu.
Potřebuje vývojář produkční klíče?
Posuzujte konkrétní práci. Běžný vývoj může používat omezené testovací údaje. Produkční zásah má mít vlastní ověřený přístup, odpovědnost a možnost jeho odebrání.
Jak často musíme klíče měnit?
Záleží na typu údaje, riziku a možnostech služby. Předem ověřte celý postup a příjemce. Nepoužívejte jeden univerzální interval pro všechny klíče, certifikáty a lidská hesla.
Stačí smazat uniklý klíč z repozitáře?
Je potřeba řešit jeho použitelnost ve službě a možné kopie. Připravte odvolání, bezpečnou náhradu a kontrolu událostí. Smazání aktuálního řádku samo nezruší oprávnění.
Nahrazuje dočasná identita kontrolu oprávnění?
Nenahrazuje. Také dočasný přístup může být příliš široký. Povolte konkrétní operace nad potřebnými objekty a pravidelně kontrolujte skutečné použití.
Co má zahrnovat pilot?
Načtení hodnoty, povolené i odmítnuté přístupy, rotaci, odvolání, výpadek a kontrolu úniků do výstupů. Uložte odpovědnost a postup obnovy pro konkrétní integraci.