Cloudový správce důvěrných údajů: co to je, jak ho vybrat a co nepokrývá
Co cloudový správce důvěrných údajů ukládá a chrání, jak vybrat mezi AWS, Google, Azure a Vault, jak ho zavést a jakou mezeru nechává při předání lidem.
Každý tým se dřív nebo později dostane do bodu, kdy jsou přihlašovací údaje na příliš mnoha místech: soubor .env na každém notebooku, připnutá zpráva ve Slacku, tabulka s názvem „přihlašovačky“, proměnná v CI, kterou někdo nastavil před dvěma lety. Cloudový správce důvěrných údajů existuje proto, aby to všechno soustředil na jedno místo, které je šifrované, má řízený přístup a podléhá auditu.
Tento průvodce vysvětluje, co cloudový správce důvěrných údajů dělá, jak vybírat mezi hlavními možnostmi, jak ho zavést bez dlouhé migrace a kterou jednu práci nedělá: nedoručí důvěrný údaj člověku, který není uvnitř vašeho cloudového účtu.
Co cloudový správce důvěrných údajů dělá
Správce důvěrných údajů ukládá citlivé hodnoty a na požádání je vydává oprávněným identitám. Základní funkce jsou u všech poskytovatelů stejné:
- Šifrované úložiště pro uložená data s klíči ve službě pro správu klíčů příslušného poskytovatele a TLS při přenosu.
- Přístup podle identity: každý důvěrný údaj má zásadu, která určuje, kteří uživatelé, role nebo úlohy ho smí číst, zapisovat nebo rotovat. Aplikace se ověřuje vlastní identitou, ne hlavním heslem.
- Auditní log každého čtení, zápisu a rotace, s údaji kdo, co a kdy.
- Verze a rotace: novou hodnotu lze připravit, přepnout na ni aplikace a starou verzi vyřadit. Mnoho správců rotuje přihlašovací údaje k databázím automaticky.
- Načítání za běhu: aplikace si důvěrný údaj vyzvedne při spuštění nebo ve chvíli, kdy ho potřebuje, takže hodnota se nikdy nezapíše do kódu, obrazů ani konfiguračních souborů.
Tajný údaj je cokoli, co dává přístup. Konfigurace, která jen popisuje chování, například číslo portu nebo příznak funkce, patří do běžné konfigurace. Když se obojí smíchá, úložiště důvěrných údajů se zahltí balastem a z úložiště konfigurace se stane riziko.
Jak ho vybrat
Rozhodnutí obvykle závisí na tom, kde vaše úlohy běží a v kolika cloudech jste.
| Možnost | Nejlépe se hodí pro | Na co si dát pozor |
|---|---|---|
| AWS Secrets Manager / Parameter Store | Úlohy, které už běží v AWS, identity IAM všude | Cena za každý důvěrný údaj v Secrets Manager; Parameter Store je levnější pro obyčejné hodnoty |
| Google Secret Manager | Projekty GCP, úlohy v Cloud Run a GKE | Volba regionální replikace |
| Azure Key Vault | Úlohy v Azure, potřeba spravovat životní cyklus certifikátů | Oddělené trezory pro každé prostředí, aby zásady zůstaly jednoduché |
| HashiCorp Vault | Více cloudů nebo vlastní servery, dynamické krátkodobé přihlašovací údaje | Provoz ve vlastní režii, pokud nepoužijete hostovanou verzi |
| Doppler, Infisical, 1Password Secrets Automation | Malé týmy, které chtějí pro vývojáře pohodlnou synchronizaci na mnoho platforem | Další dodavatel v řetězci důvěry |
Většinu rozhodnutí vyřeší čtyři otázky. Napojí se na vaše nástroje pro nasazení a běhové prostředí bez vlastního lepicího kódu? Mohou se k němu úlohy ověřit identitou, kterou už mají? Umí rotovat typy přihlašovacích údajů, které skutečně používáte? A končí jeho auditní logy tam, kam se váš bezpečnostní tým už dívá? Cena, regiony a certifikace souladu s předpisy přicházejí na řadu až po těchto čtyřech.
Zavedení bez šestiměsíčního projektu
- Sepište inventuru a určete vlastníky. Vypište každý důvěrný údaj, kde je uložen, co ho používá a kdo za něj odpovídá. Vlastník rozhoduje o pravidlech rotace a o tom, kdo má přístup.
- Nejdřív nastavte identity. Vytvořte role nebo servisní účty pro každou úlohu a prostředí dřív, než přesunete jedinou hodnotu. Celý smysl spočívá v zásadách přístupu typu „tato služba, toto prostředí, jen čtení“.
- Migrujte podle rizika. Nejdřív hesla k produkčním databázím a platební klíče, potom klíče API třetích stran, potom vše ostatní. Každou hodnotu při přesunu odstraňte z kódu, proměnných CI a konfiguračních souborů a cestou ji vyměňte, protože stará hodnota už byla rozkopírována.
- Změňte způsob, jakým aplikace důvěrné údaje čtou. Natvrdo zapsané hodnoty a soubory s proměnnými prostředí nahraďte voláním SDK správce při spuštění, nebo je vkládejte nativní integrací platformy.
- Zapněte rotaci u všeho, co správce umí rotovat sám, a pro ostatní napište rotační funkci nebo provozní postup.
- Upozorňujte na neobvyklé. Čtení důvěrného údaje novou identitou, prudký nárůst čtení nebo čtení z regionu, kam nic nenasazujete, by mělo spustit upozornění pro pohotovost.
Časté chyby jsou předvídatelné: po migraci se ponechají staré kopie, úloha dostane přístup ke čtení celého úložiště místo jen svých důvěrných údajů a načtená hodnota se zapisuje do aplikačních logů.
Mezera, kterou správce důvěrných údajů nevyplní
Správce důvěrných údajů je postavený pro stroje a pro lidi uvnitř vašeho systému identit. Není postavený pro chvíli, kdy se přihlašovací údaj musí dostat k někomu mimo něj: k externistovi, který potřebuje dočasné heslo k databázi, ke klientovi, který dostává první administrátorské přihlášení, k technikovi dodavatele, který potřebuje token na jedno odpoledne, nebo k novému kolegovi v první den, kdy ještě nemá účet SSO.
Taková předání se dějí tak jako tak. Bez schválené cesty probíhají v e-mailu a chatu, tedy právě tam, odkud měli správci důvěrných údajů přihlašovací údaje dostat. Schválenou cestou je jednorázový tajný odkaz. Hodnota se zašifruje ve vašem prohlížeči ještě před uložením, zpráva obsahuje jen odkaz, uložená kopie se zničí při prvním otevření odkazu a pokud ho nikdo neotevře, platnost odkazu po nastavené době vyprší.
Osvědčený postup: správce důvěrných údajů je hlavní evidencí a jednorázový odkaz je způsob doručení, když člověk mimo systém potřebuje hodnotu jednou. Vygenerujte přihlašovací údaj, uložte ho do správce, pošlete ho dotyčnému jednorázovým odkazem a po skončení jeho přístupu ho vyměňte. Článek tajné odkazy, nebo správci hesel uplatňuje stejnou úvahu na týmového správce hesel a průvodce předáváním přihlašovacích údajů mezi týmy popisuje běžný postup.
Krátký kontrolní seznam
- Každý důvěrný údaj má vlastníka, zásadu přístupu a pravidlo rotace.
- Úlohy se ověřují vlastní identitou, nikdy sdíleným klíčem.
- Po migraci neexistuje žádný důvěrný údaj v kódu, obrazech, proměnných CI ani v chatu.
- Čtení se zaznamenává tam, kam se někdo skutečně dívá.
- Lidé mimo systém identit dostávají důvěrné údaje jednorázovým odkazem, ne zprávou.
Splňte těchto pět bodů a správce důvěrných údajů přestane být jen produktem, který jste si koupili, a stane se důvodem, proč přihlašovací údaje přestaly unikat.
Související články
- Jak bezpečně sdílet klíče API
- Bezpečné sdílení odkazů pro vývojáře
- Jak zavést bezpečné předávání přihlašovacích údajů mezi týmy
- Tajné odkazy, nebo správci hesel
Časté dotazy
Co je cloudový správce důvěrných údajů?
Spravovaná služba, která šifrovaně ukládá přihlašovací údaje, jako jsou klíče API, hesla k databázím a certifikáty, řídí, které identity smí jednotlivé údaje číst, zaznamenává každý přístup a umí hodnoty podle plánu rotovat. Aplikace si důvěrné údaje vyzvedávají za běhu, místo aby je měly v kódu nebo v konfiguraci.
Co do správce důvěrných údajů ukládat?
Vše, co dává přístup: hesla, klíče API, tokeny, soukromé klíče, certifikáty a připojovací řetězce s vloženými přihlašovacími údaji. Běžná konfigurace, například úrovně logování nebo příznaky funkcí, patří do konfigurace, ne do úložiště důvěrných údajů.
Jak z něj aplikace důvěrné údaje čtou?
Přes SDK nebo CLI poskytovatele a ověřují se vlastní identitou úlohy, například rolí IAM nebo servisním účtem Kubernetes. Aplikace nikdy nemá dlouhodobý přihlašovací údaj, kterým by se k úložišti důvěrných údajů připojovala.
Jak často důvěrné údaje rotovat?
Dlouhodobé hodnoty, které to podporují, podle plánu, a okamžitě při událostech, jako je odchod člověka z firmy, změna dodavatele nebo jakékoli podezření na únik. Většina správců umí hesla k databázím rotovat automaticky. Klíče API od třetích stran obvykle vyžadují rotační funkci nebo ruční krok.
Šifrují správci důvěrných údajů uložené hodnoty?
Ano, uložená data šifrují klíčem ze služby pro správu klíčů poskytovatele a při přenosu používají TLS. O přístupu ale stále rozhodují oprávnění, která nastavíte, takže šifrování nechrání před příliš širokou zásadou.
Jaký je rozdíl mezi ukládáním a sdílením důvěrných údajů?
Ukládání určuje, kde důvěrný údaj žije a jak si ho stroje a oprávnění lidé v průběhu času vyzvedávají. Sdílení je chvíle, kdy se hodnota musí dostat k člověku, který v tomto systému není: k externistovi, klientovi nebo novému kolegovi. Správce důvěrných údajů dělá to první. Jednorázový tajný odkaz dělá to druhé a nenechá kopii ve zprávě.