Důležité důvody správy klíčů a tajných kódů v Azure

Šifrování je zásadní nástroj pro zabezpečení, protože omezuje přístup. Je ale stejně důležité chránit klíč tajných kódů (klíčů, certifikátů), který poskytuje přístup k datům.

Klíčové body

  • Místo kryptografických klíčů použijte řízení přístupu na základě identity.
  • Používejte standardní a doporučené šifrovací algoritmy.
  • Ukládání klíčů a tajných kódů do spravované služby trezoru klíčů Řízení oprávnění u přístupového modelu.
  • Střídání klíčů a dalších tajných kódů často. Nahraďte prošlé nebo ohrožené tajné klíče.

Řízení přístupu na základě identity

Organizace by neměly vyvíjet a udržovat vlastní šifrovací algoritmy. Existuje mnoho způsobů, jak poskytnout řízení přístupu k dostupným prostředkům úložiště, například:

  • Sdílené klíče
  • Sdílené podpisy
  • Anonymní přístup
  • Metody založené na zprostředkovateli identity

Zabezpečené standardy již na trhu existují a měly by být preferované. Algoritmus AES by měl být použit jako symetrický blokový šifra,, AES-128 AES-192 a AES-256 jsou přijatelné. Rozhraní API pro šifrování, která jsou integrovaná v operačních systémech, by se měla používat tam, kde je to možné, nikoli z knihoven kryptografických knihoven V případě .NET se ujistěte, že dodržujete kryptografický model .NET.

Přiřazujete u služby identity ověřování pomocí služeb identit pro úlohy přes kryptografické klíče?


Ochrana kryptografických klíčů se často může Přečtěte nebo je nesprávně implementovaná. Zabezpečená správa klíčů pomocí kódu aplikace je mimořádně obtížná a může vést k chybám, jako je například nechtěné publikování citlivých přístupových klíčů do veřejných úložišť kódu.

Doporučuje se použití možností založených na identitě pro řízení přístupu k úložišti. Tato možnost používá pro prostředky úložiště řízení přístupu na základě role (RBAC). Pomocí RBAC můžete přiřadit oprávnění uživatelům, skupinám a aplikacím v určitém oboru. systémy identit, jako je Azure Active Directory (Azure AD), nabízejí zabezpečené a použitelné prostředí pro řízení přístupu s integrovanými mechanismy pro zpracování rotace klíčů, monitorování anomálií a dalších.

Poznámka

Udělte přístup na základě principu nejnižší úrovně oprávnění. Riziko poskytnutí více oprávnění, než je nutné, může vést k ohrožení bezpečnosti dat.

Předpokládejme, že potřebujete uložit citlivá data do Azure Blob Storage. K ověření instančního objektu, který má požadovaná oprávnění pro přístup k úložišti, můžete použít Azure AD a RBAC. Další informace o této funkci najdete v referenčních informacích k autorizaci přístupu k objektům blob a frontám pomocí Azure Active Directory.

Tip

Použití tokenů SAS je běžný způsob, jak řídit přístup. Tokeny SAS se vytvářejí pomocí přihlašovacích údajů Azure AD vlastníka služby. Tokeny se vytvoří pro každý prostředek a můžete použít Azure RBAC k omezení přístupu. Tokeny SAS mají časový limit, který řídí okno expozice. Zde jsou zdroje pro předchozí příklad:

GitHub GitHub pro logo : implementace referenčních informací pro Azure Cognitive Services.

Pokyny k návrhu jsou popsané v tématu přepisy řeči s Azure Cognitive Services.

Úložiště klíčů

Chcete-li zabránit únikům zabezpečení, uložte následující klíče a tajné klíče do zabezpečeného úložiště:

  • Klíče rozhraní API
  • Databázové připojovací řetězce
  • Šifrovací klíče dat
  • Hesla

Citlivé údaje by neměly být uloženy v rámci kódu nebo konfigurace aplikace. Útočník získá přístup pro čtení ke zdrojovému kódu by neměl získat znalosti tajných klíčů týkajících se aplikace a prostředí.

Uložte všechny klíče aplikace a tajné klíče do služby trezoru spravovaného klíče, jako je Azure Key Vault nebo trezor HashiCorp. Ukládání šifrovacích klíčů ve spravovaném úložišti má další omezení přístupu. Úlohy mají přístup k tajným klíčům pomocí ověřování proti Key Vault pomocí spravovaných identit. Přístup se dá omezit pomocí Azure RBAC.

Zajistěte, aby žádné klíče a tajné kódy pro žádné typy prostředí (vývoj, testování nebo produkce) nebyly uloženy v konfiguračních souborech aplikace nebo kanálech CI/CD. vývojáři můžou k přístupu k přihlašovacím údajům použít Visual Studio připojené služby nebo jenom místní soubory.

Mít procesy, které pravidelně zjišťují vystavené klíče v kódu aplikace. Možnost je skener přihlašovacích údajů. Informace o úloze konfigurace úlohy najdete na stránce nástroje pro kontrolu přihlašovacích údajů.

Máte přístupový model pro trezory klíčů, kterým udělíte přístup k klíčům a tajným klíčům?


Chcete-li zabezpečit přístup k vašim trezorům klíčů, řízení přístupu k klíčům a tajným klíčům prostřednictvím přístupového modelu. Další informace najdete v přehledu referenčního modelu přístupu.

Navrhované akce

Zvažte použití Azure Key Vault pro tajné klíče a klíče.

Provozní hlediska

Kdo zodpovídá za správu klíčů a tajných kódů v kontextu aplikace?


Střídání klíčů a certifikátů je často příčinou výpadků aplikací. I přes Azure vypršela platnost certifikátů. Je důležité, aby se rotace klíčů a certifikátů plánovala a byla plně funkční. Proces otáčení by měl být automatizovaný a testován, aby se zajistila efektivita. Azure Key Vault podporuje rotaci a auditování klíčů.

Centrální tým SecOps poskytuje pokyny pro správu klíčů a tajných kódů (zásad správného řízení). aplikace DevOps tým zodpovídá za správu klíčů a tajných klíčů souvisejících s aplikacemi.

Jaké typy klíčů a tajných kódů se používají a jak se generují?


Mezi tyto přístupy patří:

  • Klíče spravované společností Microsoft
  • Klíče spravované zákazníkem
  • Bring Your Own Key

Rozhodnutí se často řídí zabezpečením, dodržováním předpisů a konkrétními požadavky klasifikace dat. Seznámení s těmito požadavky vám pomůže určit nejvhodnější typ klíčů.

Jsou klíče a tajné klíče často otočeny?


Aby bylo možné omezit vektory útoku, tajné klíče vyžadují rotaci a jsou náchylné k vypršení platnosti. Proces by měl být automatizovaný a spuštěný bez jakýchkoli lidských interakcí. Uložením do spravovaného úložiště tyto provozní úlohy zjednodušuje zpracováním střídání klíčů.

Výměna tajných kódů po dosažení konce své aktivní životnosti nebo v případě ohrožení bezpečnosti. Obnovené certifikáty by měly také používat nový klíč. Mít proces pro situace, kdy se klíče nastanou ohrozit (nevráceno) a že je potřeba je znovu vygenerovat na vyžádání. Například rotace tajných kódů v SQL Database.

Další informace najdete v referenčním Key Vaultovém otočení klíče.

Pomocí spravovaných identit odeberete provozní režii pro ukládání tajných klíčů nebo certifikátů instančních objektů.

Jsou sledována data vypršení platnosti certifikátů protokolu SSL/TLS a jsou k dispozici procesy pro jejich obnovení?


Běžnou příčinou výpadku aplikace jsou certifikáty SSL/TLS s vypršenou platností.

Vyhněte se výpadkům sledováním data vypršení platnosti certifikátů SSL/TLS a jejich obnovením včas. V ideálním případě by se měl proces automatizovat, i když to často závisí na používané certifikační autoritě (CA). Pokud není automatizovaná, používejte výstrahy, abyste se ujistili, že se data vypršení platnosti nestanou měnit.

Navrhované akce

Implementujte proces pro správu certifikátů SSL a proces automatického obnovování s Azure Key Vault.

Další informace

Kurz: Konfigurace automatického rotace certifikátů v Key Vault

Služba pro správu identit a přístupu ověří a udělí oprávnění těmto skupinám:

  • Uživatelé
  • Partneři
  • Zákazníci
  • Aplikace
  • Služby
  • Další entity

Informace o zabezpečení najdete v referenčních informacích o správě identit a přístupu k Azure.

Zpět k hlavnímu článku: Ochrana dat

Další kroky

Ochrana dat v klidovém provozu a přenosech prostřednictvím šifrování. Ujistěte se, že používáte standardní šifrovací algoritmy.