Ochrana dat

Ochrana dat chrání citlivé informace před neoprávněným přístupem, exfiltrací a zneužitím v celém životním cyklu dat. Implementujte zjišťování a klasifikaci pro vytvoření inventáře dat, šifrování pro ochranu přenášených a neaktivních uložených dat a disciplíny správy klíčů a certifikátů za účelem zachování kryptografické integrity. Tento vícevrstvý přístup odpovídá zásadám nulová důvěra (Zero Trust) a strategiím hloubkové ochrany.

Bez komplexní ochrany dat čelí organizace únikům dat, regulačním sankcím a poškození reputace před exfiltrací citlivých informací.

Tady jsou tři základní pilíře domény zabezpečení ochrany dat.

Poznejte a klasifikujte svá data: Objevte citlivé informace a aplikujte konzistentní štítky k umožnění kontrol založených na rizicích.

Související ovládací prvky:

• DP-1: Zjišťování, klasifikace a označování citlivých dat
• DP-2: Monitorování anomálií a hrozeb, které cílí na citlivá data

Ochrana dat pomocí šifrování: Implementujte komplexní šifrování pro přenášená a neaktivní uložená data pomocí moderních kryptografických standardů.

Související ovládací prvky:

• DP-3: Šifrování citlivých dat během přenosu
• DP-4: Povolení šifrování neaktivních uložených dat ve výchozím nastavení
• DP-5: Použijte možnost klíče spravovaného zákazníkem v šifrování dat v klidovém stavu, když je to potřeba

Správa kryptografické infrastruktury: Vytvořte disciplinovanou správu životního cyklu pro kryptografické klíče a certifikáty s automatizovanou rotací a komplexními auditními záznamy.

Související ovládací prvky:

• DP-6: Použití zabezpečeného procesu správy klíčů
• DP-7: Použití zabezpečeného procesu správy certifikátů
• DP-8: Zajištění zabezpečení klíče a úložiště certifikátů

DP-1: Zjišťování, klasifikace a označování citlivých dat

Azure Policy: Viz Azure integrované definice zásad: DP-1.

Princip zabezpečení

Vytvořte a udržujte komplexní inventář citlivých dat zjišťováním, klasifikací a označováním dat napříč všemi úložišti. To umožňuje řízení přístupu na základě rizik, zásady šifrování a monitorování, které chrání před neoprávněným přístupem a exfiltrací.

Riziko ke zmírnění

Aktéři hrozeb zneužívají nedostatek viditelnosti a nekonzistentního zpracování citlivých dat za účelem exfiltrace nebo zneužití informací s vysokou hodnotou. Pokud se citlivá data nezjistí, klasifikují nebo označí:

• Nesměrovaná regulovaná data: (PCI, PHI, PII) uložená v nespravovaných umístěních (stínové IT) obchází požadované šifrování, uchovávání informací nebo kontrolní mechanismy monitorování.
• Více privilegovaný přístup: Široký přístup k uživatelům a službám přetrvává, protože není identifikován citlivost a obchodní dopad.
• Šíření replik: Replikace dat šíří citlivý obsah do analýz, testování nebo exportních kanálů v prostředích s nižší důvěryhodností.
• Forenzní slepá místa: Odpovědi na incidenty nemohou rychle určit rozsah výbuchu kvůli chybějícím nebo nesprávným metadatům citlivosti.
• Selhání automatizace: Zásady správného řízení (DLP, podmíněný přístup, pracovní postupy šifrování) se neaktivují bez konzistentního popisování.

Nedostatek základní klasifikace zvyšuje dobu setrvání, rozšiřuje příležitosti pro laterální pohyb a zvyšuje regulační a reputační expozici.

MITRE ATT&CK

• Rekognoskace (TA0043): shromažďování identit obětí / datových prostředků (T1596) pomocí výčtu účtů úložiště, katalogů schémat a metadat klasifikace pro profilování úložišť s vysokou hodnotou.
• Zjišťování (TA0007): výčet účtů a oprávnění (T1087, T1069), které odhalí nadměrné vazby rolí umožňující eskalaci horizontálního nebo vertikálního přístupu k datům.
• Kolekce (TA0009): Data z cloudového úložiště (T1530) extrahováním neoznačených blob kontejnerů nebo nespravovaných exportů bez sledovacích značek.
• Exfiltrace (TA0010): exfiltrace prostřednictvím webových služeb (T1567) přes ad hoc exportní koncové body, kde chybí kontrolní mechanismy popisků a zásad.
• Exfiltrace (TA0010): automatizovaná exfiltrace (T1020) pomocí skriptovaného procesu stránkování/smyčkování pro tiše sbírat chybně klasifikované datové sady.

DP-1.1: Zjišťování, klasifikace a označování citlivých dat

Pomocí Microsoft Purview můžete vytvořit komplexní mapu dat, která automaticky zjišťuje, klasifikuje a označuje citlivé informace v celém datovém majetku. Rozšiřte ochranu nad rámec šifrování na úrovni infrastruktury implementací Microsoft Purview Information Protection pro použití trvalých práv k šifrování a používání na úrovni dokumentu, která následují po datech kdekoli. Tato základní funkce umožňuje, aby podřízené bezpečnostní prvky, jako je ochrana před únikem informací, podmíněný přístup a zásady šifrování, fungovaly na základě citlivosti dat, a ne na umístění samotného.

Zjišťování a klasifikace dat:

• Nasaďte Microsoft Purview, abyste mohli zjišťovat, klasifikovat a označovat citlivá data napříč Azure, místními, Microsoft 365 a více cloudovými prostředími.
• Pomocí Microsoft Purview mapování dat můžete automaticky kontrolovat a katalogovat zdroje dat, včetně Azure Storage, Azure SQL Database, Azure Synapse Analytics a dalších podporovaných služeb.
• Povolte popisky citlivosti v mapě dat Purview, aby se automaticky použily popisky klasifikace (např. Důvěrné, Vysoce důvěrné, PII, PHI) na základě vzorů obsahu dat a zásad organizace.

Šifrování a ochrana na úrovni dokumentu:

• Nasaďte Microsoft Purview Information Protection pro použití trvalých práv k šifrování a používání dokumentů a e-mailů na základě popisků citlivosti. Nakonfigurujte popisky tak, aby automaticky šifrovaly soubory, použily vodoznaky, omezily přeposílání, nastavily data vypršení platnosti a odvolaly přístup i po opuštění dat ve vaší organizaci.
• Povolte službu Azure Rights Management Service (Azure RMS) jako základní technologii ochrany, která šifruje dokumenty a e-maily pomocí zásad použití (jen pro zobrazení, bez kopírování, bez tisku), které se uchovávají bez ohledu na to, kde jsou uložená nebo sdílená data.

Klasifikace a integrace databáze:

• Pro Azure SQL databáze zapněte SQL Data Discovery & Klasifikaci pro identifikaci, klasifikaci a označování sloupců obsahujících citlivé údaje, jako jsou čísla platebních karet, čísla sociálního pojištění nebo zdravotní záznamy.
• Integrovat metadata klasifikace s podřízenými ovládacími prvky: nakonfigurujte zásady ochrany před únikem informací v Microsoft Purview, použijte pravidla podmíněného přístupu v Entra ID a vynucujte zásady šifrování na základě popisků citlivosti.
• Vytvořte plán pravidelné kontroly, který bude průběžně zjišťovat nově vytvořené nebo upravené citlivé datové prostředky při vývoji vašich datových aktiv.

Příklad implementace

Globální organizace finančních služeb nasadila Microsoft Purview mapu dat, která automaticky zjišťuje a klasifikuje citlivá data napříč 200 účty Azure Storage, 50 databází SQL a pracovními prostory Synapse Analytics.

Challenge: Organizace neměla přehled o tom, kde se citlivá data nacházejí ve svých rychle rostoucích Azure datových aktivech. Ruční klasifikace dat byla nekonzistentní, zpozdila prosazování správy a vytvořila mezery v dodržování pravidel. Bez automatizovaného zjišťování zůstala regulovaná data (PHI, PII, PCI) nechráněná v nespravovaných umístěních a zásady ochrany před únikem informací se neaktivovaly správně.

Přístup řešení:

• Nasaďte Microsoft Purview Mapa dat pro objevování dat: Vytvořte účet Purview a zaregistrujte zdroje dat (účty Azure Storage, SQL databáze, pracovní prostory Synapse Analytics), nakonfigurujte mapu dat tak, aby mapovala zdroje pomocí ověřování spravované identity, udělte identitě pro skenování oprávnění ke čtení (role db_datareader) pro schémata katalogu a detekujte citlivé sloupce.
• Konfigurace klasifikace a detekce citlivosti: Nastavte pravidla kontroly pro detekci citlivých vzorů (SSN, čísla platebních karet, čísla lékařských záznamů, kódy SWIFT), definujte vlastní klasifikační pravidla v souladu se zásadami klasifikace dat ("Důvěrné – interní" pro podniková data, "Vysoce důvěrné – regulovaná" pro data PHI/PCI/PII), nakonfigurujte automatické prahové hodnoty označování (při ≥3 vzory PII zjištěné v jednom prostředku), nastavte plány kontrol na základě kritického stavu dat (týdenní pro produkční prostředí, měsíčně pro archivy), nakonfigurujte výstrahy, které upozorní bezpečnostní týmy při zjištění nových dat s vysokou citlivostí.
• Nasazení služby Microsoft Purview Information Protection pro šifrování na úrovni dokumentu: Vytváření popisků citlivosti v portálu dodržování předpisů Purview s nastavením ochrany (Veřejné: bez šifrování, pouze vizuální označení; Vnitřní: vodoznak, žádná omezení přeposílání; Důvěrné: šifrováno pomocí Azure RMS, povoleny zobrazení/úpravy pouze pro zaměstnance, blokováno přeposílání/tisk; Vysoce důvěrné – regulované: šifrováno pomocí Azure RMS, pouze zobrazení, bez kopírování/tisku/přeposílání, platnost 90 dnů, možnost odebrání přístupu), publikování popisků citlivosti pro uživatele prostřednictvím zásad štítků (rozsah: Finance, Právní, Executive oddělení), konfigurace zásad automatického označování pro automatické přiřazování štítků (≥10 čísel sociálního zabezpečení → "Vysoce důvěrné – regulované", ≥5 čísel kreditních karet → "Vysoce důvěrné – regulované"), povolte ochranu Azure RMS pro dokumenty s popisky uložené v účtech SharePoint, OneDrive a Azure Storage, nakonfigurujte označování na straně klienta pro aplikace Office tak, aby uživatelům před uložením/odesláním zobrazila klasifikaci dokumentů.

Výsledek: Automatická kontrola map Dat Purview zjistila více než 15 000 datových prostředků obsahujících regulovaná data v prvním týdnu, což zkracuje dobu zjišťování z měsíců na dny. Information Protection automatické označování během 72 hodin použilo šifrování na 8 500 dokumentů. Popisky citlivosti umožňují nepřetržitou viditelnost datových aktiv a trvalou ochranu i v případě, že se data přesunou na nespravovaná zařízení.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

• Kontroly CIS v8.1: 3.2, 3.7, 3.13
• NIST SP 800-53 Rev.5: RA-2, SC-28
• PCI-DSS v4: 3.2.1, 12.3.1
• NIST CSF v2.0: PR. DS-1, PR. DS-5
• ISO 27001:2022: A.8.11
• SOC 2: CC6.1

DP-2: Monitorování anomálií a hrozeb, které cílí na citlivá data

Azure Policy: Viz Azure integrované definice zásad: DP-2.

Princip zabezpečení

Monitorujte aktivity přístupu k citlivým datům a přenosy citlivých dat pro anomálie, které indikují neoprávněnou exfiltraci, vnitřní hrozby nebo ohrožené účty. Pomocí standardních hodnot chování a kontextu citlivosti dat můžete detekovat neobvyklé vzory, jako jsou velké přenosy, neobvyklé doby přístupu nebo neočekávané přesuny dat.

Riziko ke zmírnění

Nežádoucí osoby a zlými zaměstnanci se pokoušejí exfiltrovat, připravit nebo testovat citlivá data pomocí nenápadného nebo nízkoúrovňového chování. Bez nepřetržitého monitorování anomálií, které bere v potaz kontext a je spojené s citlivostí dat:

• Tiché exfiltrace: Hromadné exporty, velké sady výsledků nebo přírůstkové sifonování probíhají bez detekce kvůli nedostatku výchozích dat.
• Zneužití programu Insider: Legitimní přihlašovací údaje provádějí neobvyklé sekvence (denní, objem, lokalita), které obcházejí hrubé monitorování.
• Příprava a výčet: Útočníci mapují schémata nebo označení, aby před hromadnou extrakcí upřednostňují cíle s vysokou hodnotou.
• Živé dotazy mimo zemi: Standardní nástroje pro správu maskují rekognoskaci v normálním provozním šumu.
• Úniky mezi úložišti: Distribuovaný přístup napříč několika službami zabraňuje prahovým hodnotám a korelaci s jedním úložištěm.

Nedostatečná detekce anomálií eroduje účinnost reakce na incidenty a umožňuje eskalaci z rekognoskace do úplné exfiltrace s minimálním třením.

MITRE ATT&CK

• Shromažďování (TA0009): data z cloudového úložiště (T1530) prostřednictvím neobvyklých hromadných nebo širokých čtení ventilátorů napříč citlivými kontejnery.
• Přístup k přihlašovacím údajům (TA0006): platné účty (T1078) zneužívající ohrožené přihlašovací údaje nebo interní přihlašovací údaje, aby se smísily s legitimními vzorci provozu.
• Exfiltrace (TA0010): automatizovaná exfiltrace (T1020) pomocí skriptovaných, omezených dotazů navržených tak, aby se zabránilo prahovým hodnotám upozornění.
• Exfiltrace (TA0010): Exfiltrace do cloudového úložiště (T1567.002) příprava dat v oblastech nebo účtech kontrolovaných útočníkem pro následné načtení.
• Command & Control / Exfiltration (TA0011/TA0010): Protokol aplikační vrstvy (T1071) tuneluje citlivé řádky prostřednictvím normálních volání DB/API.
• Zjišťování (TA0007): Zjišťování systému / služeb (T1082, T1046) výčtování koncových bodů pro mapování bočních cest pohybu k úložištím s vyšší hodnotou.

DP-2.1: Povolení detekce hrozeb pro datové služby

Nasaďte služby Microsoft Defender, abyste zajistili detekci hrozeb v reálném čase a monitorování anomálií napříč úložišti dat a databázovými platformami. Tyto služby používají analýzu chování a analýzu hrozeb k identifikaci podezřelých aktivit, jako jsou pokusy o injektáž SQL, neobvyklé vzory dotazů, neobvyklé objemy přístupu k datům a potenciální indikátory exfiltrace, které tradiční řízení přístupu nedokáže rozpoznat.

Povolení detekce hrozeb pro datové služby:

• Povolte Microsoft Defender pro úložiště s kontrolou malwaru a detekcí citlivých datových hrozeb za účelem monitorování neobvyklých vzorů přístupu, neobvyklých svazků pro nahrávání a stahování a potenciálních pokusů o exfiltraci dat napříč účty Azure Storage.
• Povolte Microsoft Defender pro SQL a detekujte podezřelé databázové aktivity, včetně pokusů o injektáž SQL, neobvyklých vzorců dotazů, neobvyklých operací exportu dat a přístupu z neznámých umístění.
• Povolte Microsoft Defender pro Azure Cosmos DB k detekci neobvyklých vzorů přístupu k databázím, potenciální exfiltraci dat a podezřelých provozních aktivit.
• U opensourcových databází (PostgreSQL, MySQL) povolte Microsoft Defender pro opensourcové relační databáze a detekujte útoky hrubou silou, vzory podezřelého přístupu a neobvyklé operace správy.

DP-2.2: Monitorování a prevence exfiltrace dat

Implementujte proaktivní kontroly ochrany před únikem informací a monitorování chování, abyste před úspěchem detekovali a blokovali neoprávněné přenosy dat. Zkombinujte ochranu před únikem informací na základě zásad se správou vnitřních rizik, korelací SIEM a automatizovanou odezvou a vytvořte přístup hloubkové ochrany, který zastaví pokusy o exfiltraci napříč několika kanály a poskytne forenzní důkazy pro vyšetřování incidentů.

Nasadit DLP a kontrolní mechanismy rizik způsobených interními hrozbami:

• Pomocí zásad Ochrana před únikem informací Microsoft Purview (DLP) zabráníte exfiltraci citlivých dat monitorováním a blokováním neoprávněných přenosů klasifikovaných dat mezi službami Azure, Microsoft 365 a koncovými body.
• Nasaďte Správa insiderských rizik Microsoft Purview a detekujte rizikové chování uživatelů pomocí strojového učení a analýzy chování. Monitorujte indikátory, včetně neobvyklého stahování dat, kopírování souborů na USB zařízení nebo do osobního cloudového úložiště, přístupu k citlivým prostředkům mimo normální pracovní dobu nebo špiček přístupu k datům před datem rezignace. Insider Risk Management koreluje signály z Microsoft 365, Azure, systémů lidských zdrojů a nástrojů zabezpečení k identifikaci potenciálních krádeží dat nebo porušení zásad.

Konfigurace monitorování a odpovědi:

• Nakonfigurujte diagnostikové protokoly datových služeb a směrujte je na Azure Monitor nebo Microsoft Sentinel, abyste vytvořili směrné plány chování a zjistili odchylky od normálních vzorů přístupu.
• Integrujte protokoly datových služeb s Microsoft Sentinel a vytvořte analytická pravidla pro detekci neobvyklých vzorů přístupu k datům, jako jsou hromadné stahování, přístup mimo špičku nebo podezřelé chování dotazů.
• Implementujte automatizované pracovní postupy reakce na incidenty pomocí playbooků Azure Logic Apps nebo Microsoft Sentinel playbooků k izolaci ohrožených identit, odvolání přístupu a upozorňování bezpečnostních týmů při zjištění pokusů o exfiltraci dat.

Poznámka: Pro požadavky na ochranu před únikem informací na základě hostitele nasaďte Microsoft Purview Endpoint DLP nebo řešení třetích stran dostupná na Azure Marketplace k vynucení ovládacích prvků ochrany dat na úrovni koncového bodu.

Příklad implementace

Poskytovatel zdravotní péče povolil Microsoft Defender pro úložiště a Defender pro SQL k monitorování anomálií a hrozeb, které cílí na data pacientů napříč účty Azure Storage a databázemi SQL.

Výzva: Organizace zaznamenala slepá místa při zjišťování neoprávněného přístupu k datům a pokusů o exfiltraci. Tradiční hraniční obrana nezachytila vnitřní hrozby a kompromitované služební principály provádějící hromadné stahování. Bez analýzy chování a detekce anomálií se vzory podezřelého přístupu po delší dobu nepoznaly, což zvyšuje riziko porušení zabezpečení a dobu trvání.

Přístup řešení:

• Povolte Microsoft Defender pro Storage: Povolte Defender pro úložiště na úrovni předplatného pro účty úložiště obsahující citlivá data, nakonfigurujte vyhledávání malwaru pro zjišťování a karanténu škodlivých souborů v úložišti objektů blob, povolte detekci citlivých dat pomocí typů citlivých informací Purview k identifikaci vzorů PHI/PII, nastavte limity prohledávání transakcí nebo měsíční limity na řízení nákladů, použijte ochranu u skupin prostředků obsahujících produkční účty úložiště hostující lékařské zobrazování a exporty EHR.
• Enable Microsoft Defender pro SQL: Povolení Microsoft Defender pro SQL na úrovni předplatného pro Azure SQL Database a SQL Managed Instance, konfigurace posouzení ohrožení zabezpečení s opakovanými kontrolami a určení účtu úložiště pro výsledky kontroly, nastavení e-mailových oznámení k upozornění bezpečnostního týmu na identifikované zranitelnosti, povolení Advanced Threat Protection pro odhalování pokusů o SQL injektáž, neobvyklých vzorů dotazů, neobvyklého přístupu z neznámých oblastí a potenciální exfiltrace dat.
• Integrace s Microsoft Sentinel: Připojení Microsoft Defender for Cloud s Microsoft Sentinel pomocí datového konektoru, konfigurace nastavení diagnostiky (povolení diagnostických protokolů pro operace s úložištěm a protokoly auditování SQL, směrování do pracovního prostoru Log Analytics), vytvoření pravidel analýzy Sentinelu pro detekci anomálií (upozornění na hromadné stahování pro stahování >10 GB do 1 hodiny, přístup k databázi mimo pracovní dobu, vzory podezřelých dotazů), konfigurace playbooků automatizovaných odpovědí tak, aby izolovaly ohrožené identity, odvolaly přístup k úložišti a upozorňovaly bezpečnostní týmy.
• Deploy Správa insiderských rizik Microsoft Purview pro detekci hrozeb založených na chování: Povolit správu insiderských rizik a nakonfigurovat šablony zásad (krádež dat odcházejících uživatelů detekcí neobvyklých stažení souborů 30–90 dnů před odchodem, obecné úniky dat monitorující kopírování na USB/cloudové úložiště, úniky dat podle priority uživatelů s vylepšeným monitorováním rolí s vysokými oprávněními), nakonfigurujte indikátory a prahové hodnoty rizik (kumulativní upozornění na stahování souborů, nárůsty přístupu mimo pracovní dobu, detekci sekvencí kombinujících více rizikových signálů), integrujte zdroje dat (Azure protokoly aktivit, Microsoft 365 protokoly auditu, Defender for Cloud Apps, systémy lidských zdrojů, události ochrany před únikem informací koncového bodu), nakonfigurujte směrování pracovního postupu třídění výstrah se střední nebo vysokou závažností do vyhrazené fronty pro šetření.

Outcome: Defender pro službu Storage zjistila neobvyklou hromadnou aktivitu stahování z ohroženého principálu služby během 48 hodin. Automatizovaná reakce izolovala identitu a během několika minut oznámila SOC, což zkracuje dobu detekce od dnů do 15 minut. Řízení rizika zevnitř označilo odcházejícího zaměstnance, který stahoval výzkumná data výrazně nad osobní průměr do osobního cloudového úložiště, což umožnilo rychlý zásah.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

• Ovládání CIS v8.1: 3.13
• NIST SP 800-53 Rev.5: AC-4, SI-4
• PCI-DSS v4: 3.2.1, 10.4.1
• NIST CSF v2.0: DE. CM-1, PR. DS-5
• ISO 27001:2022: A.8.11, A.8.16
• SOC 2: CC6.1, CC7.2

DP-3: Šifrování citlivých dat během přenosu

Azure Policy: Viz Azure integrované definice zásad: DP-3.

Princip zabezpečení

Chraňte přenášená data pomocí silného šifrování (například TLS 1.2 nebo novější), abyste zabránili zachycení, manipulaci a neoprávněnému přístupu. Definujte hranice sítě a obory služeb, kde je šifrování povinné, stanovení priority externího a veřejného síťového provozu při zvažování interní ochrany sítě na základě citlivosti dat.

Riziko ke zmírnění

Nešifrované nebo slabě chráněné síťové kanály vystavují citlivá data riziku zachycení, manipulace a zneužití ke snížení úrovně zabezpečení. Chybí vynucené moderní šifrování přenosu (TLS 1.2+):

• Pasivní průsečík: Pozorovatelé sítě zaznamenávají přihlašovací údaje, tokeny, datové části rozhraní API nebo regulovaná data v prostém textu.
• Man-in-the-middle: Útočníci mění dotazy, vkládají škodlivé kódy nebo sbírají materiály z relace.
• Downgrade protokolu: Starší záložní verze (SSL/TLS < 1.2, prostý text HTTP/FTP) umožňuje zneužití zastaralých šifrovacích sad.
• Napadení relace: Nedostatek integrity komunikačního kanálu umožňuje znovu použití tokenu nebo krádež souborů cookie k umožnění laterálního pohybu.
• Manipulace s integritou: Zásahy narušují analýzy nebo spouštějí podvodné transakce.
• Neprůhledné boční cesty: Vnitřní provoz v prostém textu se stává průzkumným materiálem po dosažení opory.

Selhání vynucení silného šifrování při přenosu zvyšuje rozsah dopadu porušení zabezpečení, urychluje kompromitaci přihlašovacích údajů a podkopává předpoklady nulové důvěry.

MITRE ATT&CK

• Přístup k přihlašovacím údajům (TA0006): Nechráněné přihlašovací údaje (T1552) zachycené během relací protokolu TLS v čistém textu nebo downgradovaných relacích, které zveřejňují tokeny nebo materiál relace.
• Kolekce (TA0009): síťové šifrování (T1040) sběr datových částí rozhraní API a tajných kódů procházejících slabou šifrou nebo cleartextovými cestami.
• Exfiltrace (TA0010): exfiltrace přes webové služby (T1567) strukturovaná data streamovaná pomocí legitimních koncových bodů rozhraní API.
• Obrana před únikem (TA0005): útočník uprostřed (T1557) vynucování TLS downgradu nebo vložení zachytávacích proxy pro zobrazení a úpravu provozu.
• Command & Control (TA0011):: Protokol T1095 (Non-Application Layer Protocol) se vrací ke starším nebo méně kontrolovaným přenosům za účelem obejití monitorování.

DP-3.1: Vynucení šifrování TLS pro datové služby a aplikace

Vytvořte moderní standardy zabezpečení přenosové vrstvy napříč všemi zákaznickými službami a datovými platformami, které chrání před odposlechem, úpravami a útoky typu man-in-the-middle. Vynucujte používání minimální verze TLS 1.2 nebo 1.3 napříč úložišti, webovými aplikacemi, databázemi a bránami rozhraní API a deaktivujte zastaralé protokoly a slabé šifrovací sady, které představují riziko vystavení dat kryptografickým útokům downgrade.

Vynucení protokolu TLS pro datové služby a aplikace:

• Vynucujte nezabezpečený přenos (jenom HTTPS) pro účty Azure Storage, abyste zajistili, že všechna klientská připojení používají protokol TLS 1.2 nebo novější pro operace objektů blob, souborů, front a tabulek.
• U webových aplikací hostovaných na Azure App Service povolte nastavení pouze HTTPS a nakonfigurujte minimum TLS na verzi 1.2 nebo 1.3, abyste zabránili útokům downgradu a zajistili moderní kryptografické standardy.
• Nakonfigurujte Azure Application Gateway tak, aby vynucovali minimální verzi protokolu TLS 1.2/1.3 pro front-endové naslouchací procesy i šifrování back-endového připojení (end-to-end TLS).
• V případě Azure SQL Database a jiných datových služeb PaaS ověřte, že "Vyžadovat zabezpečená připojení" nebo ekvivalentní nastavení vynucují šifrovaná připojení. Zamítněte připojení ve formátu prostého textu.
• Pro službu API Management, Azure Front Door a další služby brány nakonfigurujte minimální zásady verze protokolu TLS tak, aby vynucovali protokol TLS 1.2 nebo vyšší a zakázali slabé šifrovací sady.

Note: Azure automaticky šifruje veškerý provoz mezi Azure datacentry pomocí MACsec (vrstva 2) a TLS (vrstva 7). Většina Azure služeb PaaS ve výchozím nastavení povoluje protokol TLS 1.2 nebo novější, ale ověřte minimální nastavení verze protokolu TLS pro služby s konfigurovatelnými zásadami zákazníka (Storage, App Service, Application Gateway, API Management, Front Door).

DP-3.2: Zabezpečení vzdáleného přístupu a protokolů přenosu souborů

Odstraňte přístup pro správu prostého textu a starší protokoly pro přenos souborů, které během provozních aktivit zpřístupňují přihlašovací údaje a citlivá data. Nahraďte nezabezpečené protokoly (FTP, nešifrované RDP/SSH) moderními šifrovanými alternativami a trasujte privilegovaný přístup prostřednictvím centralizovaných basek, abyste eliminovali přímé internetové vystavení rozhraní pro správu.

Zabezpečení protokolů vzdálené správy:

• Pro vzdálenou správu Azure virtuálních počítačů používejte výhradně zabezpečené protokoly:
  • Virtuální počítače s Linuxem: Použití SSH (port 22) s ověřováním na základě klíčů; zakázat ověřování heslem.
  • Windows virtuální počítače: Použijte RDP přes TLS (port 3389) s povoleným ověřováním na úrovni sítě (NLA).
  • Privilegovaný přístup: Směrování připojení pro správu prostřednictvím Azure Bastion k odstranění ohrožení veřejných IP adres a zajištění přístupu k prohlížeči nebo nativnímu klientovi přes protokol TLS.

Protokoly pro zabezpečený přenos souborů:

• Pro operace přenosu souborů použijte zabezpečené protokoly a zakažte starší alternativy:
  • Podpora SFTP se používá v Azure Blob Storage (vyžaduje hierarchický obor názvů).
  • Používejte FTPS v Azure App Service a Azure Functions.
  • Zakažte starší protokol FTP (prostý text).
• Pomocí Azure Policy vynucujte zásady zabezpečeného přenosu v celém prostředí a monitorujte dodržování předpisů pro požadavky na verzi protokolu TLS.

Příklad implementace

Minimální verze protokolu TLS 1.3 vynucovaná platformou elektronického obchodování napříč všemi službami orientovanými na zákazníky, aby splňovala požadavky PCI-DSS 4.0.

Výzva: Starší protokoly TLS 1.0/1.1 a slabé sady šifer vystavily zákaznická platební data riziku odposlech útoků. Nekonzistentní vynucování protokolu TLS napříč aplikačními vrstvami vytvořilo mezery zabezpečení, kdy by útočníci mohli downgradovat připojení. Bez centralizovaného vynucování zásad TLS dochází ke změnám v konfiguraci, které umožňují setrvání nezabezpečených protokolů v produkčním prostředí.

Přístup řešení:

• Konfigurujte Azure App Service pro protokol TLS 1.3: Nastavte minimální verzi PROTOKOLU TLS na 1.3 pro webové aplikace a rozhraní API určené pro zákazníky, povolte automatické přesměrování veškerého provozu HTTP na HTTPS, ověřte, že spravované certifikáty nebo vlastní certifikáty používají silné šifrovací sady.
• Konfigurujte Azure Application Gateway pro end-to-end TLS: Nakonfigurujte naslouchací proces HTTPS na front-endu pomocí zásad SSL AppGwSslPolicy20220101 (minimálně TLS 1.3 se zásadami CustomV2), nahrajte certifikát TLS nebo integrujte s Key Vault pro správu certifikátů; nakonfigurujte nastavení back-endu pro spojení HTTPS (nastavte back-endový protokol na HTTPS na portu 443 a umožněte 'Použít dobře známý certifikát CA', pokud back-endová služba App Services používá certifikáty spravované Azure, nastavte minimální verzi protokolu TLS na 1.2 pro back-endová připojení). Vytvořte pravidla směrování propojující naslouchací procesy HTTPS s back-endovými fondy s nastavením s povoleným TLS.
• Vynutit zabezpečený přenos pro Azure Storage: Povolit nastavení "Vyžadován zabezpečený přenos" pro vynucení pouze protokolu HTTPS pro operace s objekty blob, soubory, fronty a tabulkami, nastavit minimální verzi protokolu TLS na 1.2 pro všechna připojení úložiště, ověřit, že všechny tokeny SAS a sdílené klíče fungují jen přes připojení HTTPS.
• Konfigurujte Azure Bastion pro zabezpečený vzdálený přístup: Nasaďte Azure Bastion v hubovém VNet, abyste zajistili přístup RDP/SSH přes prohlížeč pomocí protokolu TLS 1.2, odeberte z virtuálních počítačů veřejné IP adresy a směrujte veškerý přístup pro správu výhradně prostřednictvím Bastionu.

Outcome: Účty úložiště Azure odmítnou HTTP připojení na hranici služby, Application Gateway vynucuje TLS 1.3 pro připojení k frontendové části s šifrováním TLS 1.2 na backendu a Azure Bastion eliminuje veřejnou IP adresu pro správu virtuálních počítačů.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

• Kontroly CIS v8.1: 3.10
• NIST SP 800-53 Rev.5: SC-8
• PCI-DSS v4: 4.2.1, 4.2.2
• NIST CSF v2.0: PR. DS-2
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1, CC6.7

DP-4: Povolení šifrování neaktivních uložených dat ve výchozím nastavení

Azure Policy: Viz Azure integrované definice zásad: DP-4.

Princip zabezpečení

Povolte ve výchozím nastavení šifrování dat v klidu, abyste chránili data před neoprávněným přístupem prostřednictvím základního úložiště, krádeže fyzických médií, vystavení snímků nebo ohroženého přístupu k infrastruktuře. Šifrování doplňuje řízení přístupu tím, že zajišťuje ochranu dat i v případě, že je vynecháno zabezpečení na úrovni úložiště.

Riziko ke zmírnění

Nešifrované nebo selektivní šifrované vrstvy úložiště umožňují útočníkům získat citlivá data ve velkém měřítku (ohrožení infrastruktury, odcizené médium, zneužití snímků). Bez výchozího šifrování:

• Získávání údajů z nezpracovaných médií: Odcizené disky, zálohy nebo nespravované snímky zpřístupňují datové sady s úplným prostým textem.
• Eroze hranic oprávnění: Správci platformy nebo ohrožení agenti hostitelů mohou číst data nájemce bez kryptografického oddělení.
• Tichá kopie a exfiltrace: Nešifrované repliky (test, analytika, export) se stávají kanály s nízkým odporem exfiltrace.
• Manipulace s integritou: Útočníci upravují neaktivní data (škodlivé knihovny DLL, konfigurace nebo referenční data) a aktivují ohrožení zabezpečení v pozdější fázi.
• Dodržování právních předpisů: Nedostatek systémového šifrování podkopává záruky vyžadované pro mnoho oborových certifikací.
• Zranitelnost obnovy bez klíčů: Image zotavení po havárii a studené archivy uchovávají citlivý obsah po neomezenou dobu v běžně přístupném prostém textu.

Pokud se nedaří vynutit univerzální šifrování dat v klidu, zvyšuje se rozsah narušení zabezpečení, komplikuje se forenzní analýza a zvětšuje se provozní a právní riziko.

MITRE ATT&CK

• Shromažďování (TA0009):: Data z cloudového úložiště (T1530) extrahováním nešifrovaných snímků, replik nebo odpojených disků.
• Obrana proti vyhýbání se detekci (TA0005): odstranění indikátorů (T1070), úprava nebo vymazání protokolů po přístupu k offline médiím nebo snímkům.
• Dopad (TA0040): Zničení dat (T1485) poškodí nešifrované neaktivní prostředky za účelem narušení podřízených procesů.
• Dopad (TA0040): Inhibuje obnovení systému (T1490) odstranění nebo změny nešifrovaných záloh a katalogů obnovení.
• Dopad (TA0040): Manipulace s daty (T1565) jemnou úpravou uložených referenčních nebo konfiguračních dat s cílem způsobit logické chyby v pozdějších fázích.

DP-4.1: Povolení šifrování neaktivních uložených dat ve výchozím nastavení

Zajistěte, aby všechna data uložená v Azure byla zašifrována v klidovém stavu, aby byla zajištěna ochrana před neoprávněným přístupem před ohrožením infrastruktury, odcizenými multimédii nebo neoprávněnými snímky. I když většina služeb Azure ve výchozím nastavení umožňuje šifrování, ověřte pokrytí mezi virtuálními počítači, účty úložiště a databázemi a povolte další šifrovací vrstvy (šifrování na hostiteli, šifrování infrastruktury, důvěrné výpočty a šifrování na úrovni sloupců) pro vysoce citlivé úlohy, které splňují zákonné požadavky a požadavky na suverenitu dat.

Povolení šifrování pro virtuální počítače a úložiště:

• Povolte encryption-at-host pro Azure Virtual Machines k šifrování dočasných disků, mezipaměti disku s operačním systémem, mezipaměti datových disků a dočasných disků s operačním systémem, než data dosáhnou Azure Storage. Zaregistrujte funkci EncryptionAtHost na úrovni předplatného a nasaďte virtuální počítače pomocí podporovaných velikostí virtuálních počítačů (např. DSv3, Easv4, Dadsv5 series).
• Povolte šifrování infrastruktury (dvojité šifrování) pro účty Azure Storage vyžadující další vrstvy šifrování. To poskytuje dvě vrstvy šifrování AES-256 s různými klíči na úrovni služby i infrastruktury – nakonfigurujte během vytváření účtu úložiště, protože po vytvoření se nedá povolit.

Nasazení důvěrného výpočetního prostředí a šifrování na úrovni sloupců:

• Nasaďte Azure důvěrné virtuální počítače s šifrováním důvěrných disků pro vysoce regulované úlohy zpracovávající exportovaná nebo citlivá data. K zajištění, že data zůstanou během zpracování zašifrována, používejte řadu DCasv5/DCadsv5-series (AMD SEV-SNP) nebo ECasv5/ECadsv5-series (Intel TDX) s šifrovacími klíči vázanými na vTPM.
• Pro Azure SQL Database implementujte Always Encrypted k zajištění šifrování na úrovni sloupců na straně klienta pro vysoce citlivá data (SSN, čísla platebních karet, zdravotnické záznamy), kde data zůstávají šifrovaná i od správců databáze, cloudových operátorů a vysoce privilegovaných, ale neautorizovaných uživatelů. Využijte Always Encrypted se zabezpečenými enklávami (Intel SGX) pro umožnění bohatších dotazů na šifrované sloupce.

Monitorování a vynucení dodržování předpisů šifrování:

• Vynucujte dodržování předpisů šifrování pomocí Azure Policy přiřazením předdefinovaných zásad, jako je například "Virtuální počítače by měly povolit šifrování hostitele", "Účty úložiště by měly mít šifrování infrastruktury" a "transparentní šifrování dat v databázích SQL by měly být povolené" v oboru předplatného nebo skupiny pro správu.
• Použijte Azure Resource Graph k dotazování a inventarizaci konfigurací šifrování v celém prostředí, identifikaci virtuálních počítačů bez šifrování na hostiteli, účtů úložiště bez šifrování infrastruktury nebo databází bez povoleného transparentního šifrování dat.

Note: Mnoho služeb Azure (Azure Storage, Azure SQL Database, Azure Cosmos DB) má ve výchozím nastavení povolené šifrování neaktivních uložených dat ve vrstvě infrastruktury pomocí klíčů spravovaných službou, které se automaticky obměňují každých dva roky. Pokud šifrování není ve výchozím nastavení povolené, povolte ho na úrovni úložiště, souboru nebo databáze na základě technické proveditelnosti a požadavků na úlohy.

Příklad implementace

Nadnárodní výrobní společnost standardizovala šifrování uložených dat v prostředí Azure pro ochranu dat ERP, aplikací dodavatelského řetězce a inženýrských obchodních tajemství.

Výzva: Nekonzistentní pokrytí šifrování ponechá citlivá data ohrožená ohrožením infrastruktury a krádeží snímků. Dočasná data disku a dočasné úložiště zůstaly nešifrované a vytvářely mezery v dodržování předpisů. Bez systematického vynucování šifrování mohou být technické obchodní tajemství a data dodavatelského řetězce zpřístupněna prostřednictvím odcizených disků, neoprávněných snímků nebo ohrožených agentů hostitelů.

Přístup řešení:

• Povolte šifrování na hostiteli pro Azure Virtual Machines: Registrovat funkci EncryptionAtHost na úrovni předplatného, povolit šifrování na hostiteli pro VMs pomocí podporovaných velikostí VM (řady DSv3, Easv4, Dadsv5), šifrování pokrývá dočasné disky, mezipaměť OS disku, mezipaměť datového disku a efemérní OS disky.
• Povolit šifrování infrastruktury (dvojité šifrování) pro Azure Storage: Ověřte, že je povolené šifrování služby Azure Storage (SSE) (ve výchozím nastavení šifrování AES-256), pro citlivé účty úložiště umožňují šifrování infrastruktury při vytváření účtu úložiště (po vytvoření nejde povolit), výsledek: dvě vrstvy šifrování AES-256 s různými klíči.
• Nasazení důvěrných virtuálních počítačů Azure pro vysoce regulované úlohy: Vyberte odpovídající řadu důvěrných virtuálních počítačů (DCasv5/DCadsv5-series pro AMD SEV-SNP nebo ECasv5/ECadsv5-series pro Intel TDX), povolte šifrování disků důvěrných virtuálních počítačů pomocí klíče spravovaného platformou (sváže šifrovací klíče disku s virtuálním čipem TPM virtuálního počítače), povolte zabezpečené spouštění a vTPM pro ověření identity, nasazení pro úlohy zpracovávající technická data řízená exportem nebo vysoce regulovaná PII, kde musí data zůstat zašifrována během zpracování.
• Implementace Always Encrypted pro citlivé sloupce databáze: Identifikujte vysoce citlivé sloupce v Azure SQL Database vyžadující šifrování na úrovni sloupců (SSN, CreditCardNumber, MedicalRecordNumber), generujte šifrovací klíče sloupců (CEK) a hlavní klíče sloupců (CMK), přičemž CMK ukládejte v Azure Key Vault. CEK šifruje datové sloupce a CMK šifruje CEK. Povolte funkci Always Encrypted se zabezpečenými enklávami (Intel SGX), abyste umožnili bohatší dotazy na šifrovaná data. Zašifrujte citlivé sloupce pomocí deterministického šifrování (pro vyhledávání rovnosti) nebo randomizovaného šifrování (maximální zabezpečení), a nakonfigurujte připojovací řetězce aplikací v nastavení Column Encryption Setting=Povoleno pro transparentní šifrování/dešifrování.
• Seznam nastavení šifrování pomocí Azure Resource Graph: Dotazujte stav šifrování virtuálních počítačů bez šifrování na hostiteli a účtů úložiště bez infrastrukturního šifrování, exportujte výsledky do CSV a přiřaďte úlohy nápravy vlastníkům zdrojů.

Výsledek: Šifrování na hostiteli vyřešilo mezery v dodržování předpisů, kdy byla dříve nešifrovaná data dočasného disku. Šifrování infrastruktury chránilo technické soubory dvěma vrstvami šifrování. Důvěrné virtuální počítače zajistily, že exportovaná data zůstala šifrovaná i od správců cloudu. Sloupce citlivé databáze chráněné funkcí Always Encrypted – správci databáze potvrdili, že není možné číst prostý text ze šifrovaných sloupců, což splňuje požadavky na dodržování předpisů.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

• Kontroly CIS v8.1: 3.11
• NIST SP 800-53 Rev.5: SC-28
• PCI-DSS v4: 3.5.1, 3.6.1
• NIST CSF v2.0: PR. DS-1
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1

DP-5: Při šifrování dat v klidu použijte možnost klíče spravovaného zákazníkem, když je to vyžadováno

Azure Policy: Viz Azure předdefinované definice zásad: DP-5.

Princip zabezpečení

Klíče spravované zákazníkem používejte, když dodržování právních předpisů, smluvní požadavky nebo požadavky na citlivost dat vyžadují přímou kontrolu nad životním cyklem šifrovacího klíče, včetně generování klíčů, obměně a autority pro odvolání. Ujistěte se, že jsou zavedeny správné procesy správy klíčů pro zpracování provozních režijních nákladů.

Riziko ke zmírnění

Spoléhání se výhradně na klíče spravované službou, u kterých regulační, smluvní nebo segregační záruky vyžadují řízení tenantů, představuje rizika dodržování předpisů a koncentrace. Bez správného řízení klíčů spravovaných zákazníkem (CMK):

• Nedostatečné regulační záruky: Auditoři můžou odmítnout důkazy o kryptografickém řízení, pokud není možné prokázat vazbu klíčů, četnost obměně nebo autoritu odvolání.
• Latence odvolání: Nemožnost rychle odvolat nebo otočit ohrožené klíče platformy rozšiřuje okno expozice po událostech přihlašovacích údajů nebo dodavatelského řetězce.
• Expozice jurisdikce: Mandáty suverenity dat mohou vyžadovat klíče spravované nájemcem nebo podporované HSM – jejich absence může ovlivnit životaschopnost regionálního nasazení.
• Poloměr výbuchu mezi tenanty: Ohrožení zabezpečení klíče platformy s více tenanty může mít vliv na široké datové sady, pokud kryptografická izolace není dostatečná.
• Proliferace stínů: Ad hoc nasazení CMK bez řízení životního cyklu vede k zastaralým, osamoceným nebo slabým klíčům.
• Provozní křehkost: Špatná automatizace rotace klíčů nebo chybějící mapování závislostí způsobuje výpadky aplikace během rotace klíčů.

Nesprávné nebo opomenuté použití CMK oslabuje kryptografickou záruku a podkopává strategickou pozici v oblasti dodržování předpisů pro citlivé úlohy.

MITRE ATT&CK

• Přístup k přihlašovacím údajům (TA0006):: Nechráněné přihlašovací údaje (T1552) vystavené slabě chráněnými nebo nesprávně segmentovanými klíči platformy.
• Dopad (TA0040): Data zašifrovaná pro dopad (T1486) zneužívající obměnu nebo odvolání CMK ke znepřístupnění dat.
• Dopad (TA0040): Manipulace s daty (T1565) úprava metadat stavu šifrování tak, aby desynchronizovala vrstvy ochrany.
• Exfiltrace (TA0010):Přenos dat do cloudového účtu (T1537) opětovným šifrováním a exportem datových sad do úložiště řízeného útočníkem.
• Exfiltrace (TA0010): exfiltrace prostřednictvím webových služeb (T1567) orchestrující vysoké objemové hromadné exporty zajištěné klíči v rámci běžných vzorců služeb.

DP-5.1: Použití možnosti klíče spravovaného zákazníkem v šifrování neaktivních uložených dat v případě potřeby

Implementace klíčů spravovaných zákazníkem při dodržování právních předpisů, mandátů suverenity dat nebo smluvních závazků vyžaduje přímou kontrolu nad správou šifrovacích klíčů, plány obměny a autoritou pro odvolání. Pro úlohy vyžadující konečnou kontrolu, kdy i Microsoft nemůže dešifrovat data, implementujte DKE (Double Key Encryption), kde vaše organizace udržuje druhý šifrovací klíč mimo Azure. Pomocí Azure Key Vault nebo spravovaného HSM udržujte kryptografickou kontrolu a současně vyrovnávejte provozní složitost správy životního cyklu klíčů, plánování zotavení po havárii a potenciální dopady na dostupnost služeb z chyb správy klíčů.

Vyhodnoťte požadavky CMK a zřiďte klíčovou infrastrukturu:

• Vyhodnoťte zákonné, dodržování předpisů nebo obchodní požadavky a určete, které úlohy vyžadují klíče spravované zákazníkem (CMK) místo klíčů spravovaných platformou. Mezi běžné faktory patří suverenita dat, požadavky na audit nebo smluvní závazky pro přímou správu klíčů.
• Zřízení Azure Key Vault (Standard nebo Premium) nebo Azure Key Vault Managed HSM pro ukládání a správu šifrovacích klíčů spravovaných zákazníkem. Spravované HSM použijte pro úlohy, které vyžadují ověřenou hardwarovou ochranu fiPS 140–3 úrovně 3.
• Vygenerujte šifrovací klíče v rámci Azure Key Vault pomocí generování klíčů nebo importujte klíče z místních hsM pomocí Bring Your Own Key (BYOK) pro maximální přenositelnost a kontrolu.

Konfigurace klíče CMK a vytvoření hierarchie klíčů:

• Pro extrémní požadavky na kontrolu implementujte Double Key Encryption (DKE) kde citlivé dokumenty vyžadují k dešifrování dva klíče: jeden spravovaný Microsoft (Azure RMS) a druhý klíč spravovaný výhradně vaší organizací místně nebo ve vaší vlastní službě pro správu externích klíčů. Pomocí DKE nemůže Microsoft dešifrovat vaše data, ani když je přinucen právním procesem, protože ovládáte druhý klíč potřebný k dešifrování.
• Nakonfigurujte služby Azure (Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Disk Encryption atd.) tak, aby používaly klíč CMK odkazováním na identifikátor URI klíče Key Vault. Povolte zásady automatické rotace klíčů, abyste snížili ruční provozní zátěž.
• Vytvořte hierarchii šifrovacího klíče klíče (KEK) a šifrovacího klíče dat (DEK kde klíč KEK (uložený v Key Vault) šifruje klíč DEK (používaný službami), což minimalizuje dopad obměny klíčů na dostupnost služby.
• Zdokumentujte postupy životního cyklu klíčů, včetně plánů obměny klíčů, procesů odvolání pro ohrožené klíče, pracovních postupů vyřazení klíčů a postupů zotavení po havárii. Integrujte správu klíčů do procesů správy změn organizace.

Poznámka: Klíče spravované zákazníkem vyžadují průběžné provozní investice, včetně správy životního cyklu klíčů, správy řízení přístupu, monitorování a plánování zotavení po havárii. Před přijetím cmk zajistěte provozní připravenost, protože nesprávná správa klíčů může vést k nedostupnosti nebo ztrátě dat.

Příklad implementace

Regulovaná finanční instituce nasadila klíče spravované zákazníkem (CMK) napříč Azure službami, aby splňovala zákonné požadavky na přímou kryptografickou kontrolu nad obchodními daty a finančními záznamy zákazníků.

Výzva: Regulační auditoři vyžadovali prokázání kryptografické kontroly, včetně správy klíčů, autority rotace a schopnosti odvolání. Klíče spravované službou nemohly poskytnout důkazy o životním cyklu klíčů řízeném tenantem. Bez klíčů spravovaných zákazníkem neměla organizace možnost rychle odvolat přístup během incidentů zabezpečení a nemohla splňovat požadavky na suverenitu dat pro regionální nasazení.

Přístup řešení:

• Provision Azure Key Vault Managed HSM: Vytvořte spravovaný HSM (FIPS 140-3 ověřeno na úrovni 3) s minimálně 3 oddíly HSM pro zajištění vysoké dostupnosti, aktivujte spravovaný HSM exportem bezpečnostní domény s quorum klíči (rozloženými do fragmentů klíčů uložených v geograficky distribuovaných offline trezorech), vygenerujte šifrovací klíče (RSA-4096 nazvané KEK-Prod-2024) s operacemi klíčů: Wrap Key, Unwrap Key, zašifrujte, dešifrujte.
• Konfigurujte klíče spravované zákazníkem pro služby Azure: Pro Azure Storage nakonfigurujte účet úložiště tak, aby používal typ šifrování CMK, vyberte Key Vault Managed HSM jako zdroj klíčů, povolte spravovanou identitu přiřazenou uživatelem s rolí uživatele Managed HSM Crypto Service Encryption User. Pro Azure SQL Database nakonfigurujte SQL Database tak, aby používala klíč spravovaný zákazníkem jako ochranu TDE, vyberte klíč ze spravovaného HSM, povolte automatickou obměnu; u Azure Cosmos DB povolte klíče spravované zákazníkem pro účet Cosmos DB, vyberte spravovaný klíč HSM a udělte spravované identitě Cosmos DB přístup.
• Implementace automatizované rotace klíčů: Nakonfigurujte zásady rotace s 90denní frekvencí, povolte automatickou rotaci, nakonfigurujte oznámení o vypršení platnosti (upozornění 7 dní před vypršením platnosti), vytvořte upozornění služby Azure Monitor pro metriku blížícího se vypršení klíče, aby se upozornil tým zabezpečení.
• Povolení protokolování auditu pro dodržování předpisů: Povolit diagnostické protokolování pro protokoly Spravovaného HSM (AuditEvent), odesílat protokoly do pracovního prostoru Log Analytics s neměnným úložištěm (uchovávání po dobu 90 dní pro nezměnitelné záznamy auditu), dotazovat se na protokoly přístupu ke klíčům pro monitorování operací Encrypt, Decrypt, WrapKey a UnwrapKey.
• Postupy životního cyklu klíče dokumentu: Vytvořte runbooky pro nouzové odvolání (kroky odvolání klíče, kontakty pro reakci na incidenty, postupy obnovy pomocí kvórových klíčů bezpečnostní domény), testujte runbooky čtvrtletně prostřednictvím cvičení na stole, integrujte operace CMK do pracovního postupu schvalování změn v rámci správy IT služeb.

Outcome: RSA-4096 KEKs ve spravovaných modulech HSM šifrují sady DEK na úrovni služby pro Azure Storage, SQL Database a Cosmos DB. Čtvrtletní automatizovaná obměna minimalizuje výpadky tím, že znovu zašifruje jenom sady DEK. Kvorum zabezpečovací domény zajišťuje zotavení po havárii i při úplném selhání regionu.

Úroveň závažnosti

Mělo by být.

Mapování ovládacích prvků

• Kontroly CIS v8.1: 3.11
• NIST SP 800-53 Rev.5: SC-12, SC-28
• PCI-DSS v4: 3.5.1, 3.6.1, 12.3.2
• NIST CSF v2.0: PR. DS-1, ID.AM-3
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1

DP-6: Použití zabezpečeného procesu správy klíčů

Azure Policy: Viz Azure předdefinované definice zásad: DP-6.

Princip zabezpečení

Implementujte procesy správy zabezpečených klíčů, které řídí celý životní cyklus klíče: generování, distribuci, úložiště, obměnu a odvolání. Používejte vyhrazené služby trezoru klíčů se silnými řízeními přístupu, udržujte kryptografické standardy, vynucujte oddělení povinností a zajistěte, aby se klíče při ohrožení zabezpečení pravidelně obměňovaly a odvolaly.

Riziko ke zmírnění

Slabé nebo nespravované životní cykly kryptografických klíčů snižují záruku poskytovanou šifrováním a můžou umožnit systémové ohrožení. Bez strukturovaného generování, rotace, ochrany a odvolání klíčů:

• Rozšíření klíčů a osamocení: Nesledované klíče přetrvávají déle, než je obchodně potřeba, s tím, že si zachovávají nezamýšlenou dešifrovací pravomoc.
• Zastaralá kryptografie: Nečastá rotace zvyšuje expozici snížení úrovně algoritmu, útokům hrubou silou nebo útokům postranním kanálem.
• Překročení oprávnění: Nedostatek oddělení rolí umožňuje správcům klíče nejen spravovat, ale i používat, čímž se otevírá prostor pro zneužití insiderů.
• Nezjištěné ohrožení zabezpečení: Žádné monitorování integrity ani rodokmen verzí nezakrývá, jestli byly klíče nahrazeny zlými úmysly.
• Odvolání se nezdařilo: Reakce na incidenty nemůže kryptograficky obsahovat přístup k datům po podezřelém porušení zabezpečení.
• Nekonzistentní hierarchie: Chybějící vrstvení KEK/DEK zvětšuje poloměr výbuchu při rotaci a zvyšuje provozní prostoje.

Nedostatečná správa klíčů promění šifrování na řízení pouze v jednom okamžiku, nikoli na trvalé zmírnění rizik plynoucích z vyvíjejících se hrozeb.

MITRE ATT&CK

• Přístup k přihlašovacím údajům (TA0006): přihlašovací údaje z úložišť hesel (T1555) extrahují nesprávně uložený nebo v mezipaměti uložený klíčový materiál nebo platné účty (T1078), zneužívající široké role správy klíčů RBAC k nelegitimnímu přístupu k klíčům nebo jejich výměně.
• Obrana před únikem (TA0005): oslabí šifrování (T1600) zachovává zastaralé algoritmy / nedostatečné velikosti klíčů, aby se snížila kryptografická síla.
• Dopad (TA0040): Zničení dat (T1485) spouštějící destruktivní vyprázdnění nebo nesprávně ošetřené události odvolání.
• Dopad (TA0040): Manipulace s daty (T1565) nahrazuje nebo mění verze klíčů za účelem přesměrování nebo zakázání toků šifrování.

DP-6.1: Vytvoření zásad správy klíčů a infrastruktury

Vytvořte základ zásad správného řízení pro správu kryptografických klíčů vytvořením centralizovaného úložiště klíčů, definováním kryptografických standardů a výběrem odpovídajících úrovní ochrany na základě citlivosti úloh. Nasaďte Azure Key Vault jako jediný zdroj pravdivých informací pro klíčové operace a implementujte komplexní protokolování auditu, abyste mohli sledovat všechny klíčové změny přístupu a správy pro účely dodržování předpisů a forenzních účelů.

Vytvoření centralizované infrastruktury správy klíčů:

• Pomocí Azure Key Vault jako centralizované služby pro správu kryptografických klíčů můžete řídit celý životní cyklus klíče: generování, distribuci, úložiště, obměna a odvolání.
• Definujte a vynucujte klíčové zásady určující minimální kryptografické standardy:
  • Typ klíče: RSA (doporučeno: 4096bitové nebo 3072bitové minimum) nebo EC (P-256, P-384, P-521 křivky).
  • Klíčové operace: Omezte povolené operace (šifrování, dešifrování, podepsání, ověření, zabalení, rozbalení) na základě principů nejnižších oprávnění.
  • Doba platnosti: Nastavte data aktivace a vypršení platnosti pro vynucení použití klíče vázaného na čas.

Zvolte odpovídající úroveň trezoru klíčů:

• Na základě požadavků na zabezpečení a dodržování předpisů vaší úlohy vyberte odpovídající úroveň Key Vault:
  • Klíče chráněné softwarem (SKU Standardní & Premium): Ověřeno FIPS 140–2 úroveň 1
  • Klíče chráněné modulem HSM (SKU Premium): Ověřeno fiPS 140–2 level 2 (sdílený back-end HSM s více tenanty)
  • Spravovaný HSM: Ověřená úroveň 3 FIPS 140–3 (vyhrazený fond HSM s jedním tenantem)
• Pokud chcete zvýšit zabezpečení, použijte Azure Key Vault Managed HSM pro jednoho tenanta ověřenou ochranu HSM úrovně 140–3 úrovně 3. Managed HSM podporuje kryptografickou doménu pro zálohování a zotavení po havárii.
• Nakonfigurujte protokolování Azure Key Vault a směrujte protokoly do Azure Monitor nebo Microsoft Sentinel ke sledování všech klíčových přístupů, událostí obměny a operací správy pro účely auditu a dodržování předpisů.

DP-6.2: Implementace automatizace klíčového životního cyklu

Automatizace obměny klíčů a vytvoření klíčových hierarchií za účelem snížení provozní zátěže, minimalizace lidských chyb a povolení rychlé výměny klíčů bez přerušení služeb Implementujte vzory KEK/DEK, které umožňují efektivní obměnu tím, že místo celých datových sad přešifrují malé klíče, a integrují postupy zotavení po havárii, aby se zachovala dostupnost klíčů napříč oblastmi selháními nebo katastrofickými událostmi.

Implementace automatizované obměně klíčů:

• Implementujte zásady automatické obměně klíčů v Azure Key Vault:
  • Nakonfigurujte frekvenci otáčení na základě požadavků na dodržování předpisů (běžné intervaly: 90 dní, 180 dní nebo ročně).
  • Povolte oznámení o rotaci, aby byly operační týmy upozorněny před vypršením platnosti klíče.
  • Nakonfigurujte automatickou rotaci tak, aby vygenerovala nové verze klíčů bez ručního zásahu.

Ustavení klíčové hierarchie a BYOK:

• Vytvoření hierarchie klíčů oddělující klíče pro šifrování klíčů (KEK) a klíče pro šifrování dat (DEK):
  • Ukládejte klíče KEK ve Azure Key Vault s omezenými řízeními přístupu.
  • Generování sad DEK na úrovni služby zašifrovaných sadami KEK minimalizuje poloměr výbuchu rotace klíčů.
  • Obměna KEK vyžaduje pouze opětovné šifrování DEKs (ne celých datových sad), což umožňuje efektivní rotaci klíčů bez výpadků.
• Pro scénáře Bring Your Own Key (BYOK) vygenerujte klíče v místních modulech HSM FIPS 140–2 úrovně 2+ a pomocí mechanismu přenosu BYOK bezpečně naimportujte klíče do Azure Key Vault nebo spravovaného HSM a zachovejte kryptografický důkaz o původu klíče a opatrovnictví.

Implementace postupů zotavení po havárii:

• Vytvořte geograficky replikované trezory klíčů v sekundárních oblastech.
• Zálohujte a obnovujte klíče, abyste zachovali dostupnost klíčů napříč oblastmi.
• Zdokumentujte a otestujte postupy zotavení po havárii s definovanými cíli RTO/RPO.

DP-6.3: Vynucení oddělení povinností pro přístup ke klíči

Znemožněte zneužití vnitřních hrozeb a oprávnění oddělením rolí správy klíčů od rolí kryptografických operací, abyste zajistili, že žádná jedna identita nemůže vytvářet klíče a používat je k šifrování nebo dešifrování dat. Implementujte průběžné monitorování, abyste zjistili neobvyklé vzory přístupu k klíčům a udržovali komplexní inventáře klíčů, které umožňují rychlé posouzení dopadu během incidentů zabezpečení nebo auditů dodržování předpisů.

Vynucení oddělení povinností:

• Implementovat řízení přístupu na základě role (RBAC) nebo zásady přístupu k vynucení oddělení povinností:
  • Samostatné role pro správce klíčů (kteří můžou vytvářet, otáčet nebo odstraňovat klíče, ale nemůžou provádět kryptografické operace).
  • Samostatné role pro klíčové uživatele (kteří můžou provádět operace šifrování/dešifrování, ale nemůžou spravovat klíče).
  • Ukázkové role: Key Vault Crypto Officer (správci), Key Vault Crypto User (aplikace/uživatelé).
• Ověřte, že žádná jedna identita nemá přístup ke správě a operačnímu klíči, aby se zabránilo zneužití oprávnění.

Monitorování přístupu ke klíčům a udržování inventáře:

• Integrujte monitorování přístupu ke klíčům s Microsoft Sentinel za účelem detekce anomálií:
  • Neobvyklé vzory přístupu ke klíčům (přístup z neznámých IP adres nebo oblastí)
  • Hromadné operace s klíči (příliš mnoho operací během krátkého časového úseku)
  • Administrativní změny mimo pracovní dobu (odstranění klíče nebo obměna mimo pracovní dobu)
• Udržujte přehled o inventáři klíčů, který zahrnuje název klíče, účel, plán obměny a závislé služby. Pravidelně kontrolujte inventář během kontrol zabezpečení.

Příklad implementace

Poskytovatel zdravotnického SaaS centralizoval správu kryptografických klíčů pomocí Azure Key Vault verze Premium s klíči chráněnými HSM pro šifrování PHI na víceuživatelské platformě.

Výzva: Fragmentovaná správa klíčů napříč vývojovými týmy vedla k rozrůstajícím se klíčům, nekonzistentním postupům obměny a problémům se sledováním využití klíčů během incidentů zabezpečení. Prostřednictvím rozsáhlých oprávnění RBAC můžou správci spravovat i používat klíče a vytvářet vnitřní riziko. Bez automatizované rotace a oddělení povinností se organizace potýkala s rozšířenými okny ohrožení klíčů a nedodržením požadavků auditu.

Přístup řešení:

• Provision Azure Key Vault Premium s klíči chráněnými HSM: Vytvořte Azure Key Vault s úrovní Premium pro podporu klíčů chráněných HSM. Povolte ochranu před vymazáním, abyste zabránili trvalému odstranění během doby uchovávání. Povolte funkci obnovitelného odstranění s 90denní dobou uchovávání pro obnovení nechtěně odstraněných klíčů. Generujte šifrovací klíče RSA-3072 chráněné HSM (KEK-PHI-Prod) s hardwarově podporovaným typem klíče.
• Umplementujte zásady automatizované obměnky klíčů: Nakonfigurujte zásady obměně s frekvencí 180 dnů, povolte automatické obměně a nastavte oznámení na upozornění 30 dní před vypršením platnosti, vytvořte skupiny akcí Azure Monitor, které upozorní tým operací zabezpečení, když se blíží vypršení platnosti klíčů, nakonfigurujte akci rotace tak, aby automaticky generovala nové verze klíčů.
• Konfigurujte RBAC oddělení rolí: Přiřaďte roli Key Vault krypto důstojníka členům bezpečnostního týmu (oprávnění: správa životního cyklu klíčů, ale bez možnosti šifrování/dešifrování), přiřaďte roli Key Vault crypto user identitám spravovaným aplikacemi (oprávnění: provádět pouze šifrování/dešifrování bez možnosti správy klíčů), ověřte oddělení rolí tím, že zajistíte, že žádná identita nemá současně roli kryptografického důstojníka i kryptografického uživatele.
• Vytvoření hierarchie KEK/DEK pro rychlé obměně klíčů: Generování šifrovacích klíčů na úrovni aplikace v kódu aplikace (AES-256) pro šifrování dat pacientů, ukládejte šifrované deky společně s šifrovanými daty, pomocí Key Vault KEK zabalte nebo zašifrujte DEK prostřednictvím operace WrapKey, načtěte a rozbalte DEK pomocí operace UnwrapKey při dešifrování dat pacientů, výhody: rotace KEK vyžaduje pouze opětovné šifrování deků místo celé databáze pacientů.
• Integrujte protokoly Key Vault pomocí protokolů Microsoft Sentinel: Povolte nastavení diagnostiky pro Key Vault a odesílání protokolů do pracovního prostoru Log Analytics, vytvořte analytická pravidla služby Sentinel, která detekují neobvyklé vzory přístupu ke klíčům, hromadné operace klíčů, změny správy mimo špičku.
• Přenos vlastního klíče (BYOK) z místního HSM: Stáhnout klíč pro přenos BYOK z Key Vaultu, exportovat klíč z místního HSM obalený veřejným klíčem přenosu BYOK od Key Vaultu, udržovat kryptografický důkaz původu klíče, importovat obalený klíč do Key Vaultu, kde dorazí chráněn HSM bez vystavení v čistém textu.

Výsledek: Klíče RSA-3072 se obměňují každých 180 dnů pomocí automatizovaných oznámení. Oddělení RBAC zabraňuje zneužití oprávnění. Hierarchie KEK/DEK umožňuje rychlou rotaci opětovným šifrováním pouze klíčů DEK. Funkce soft delete umožňuje obnovit náhodně smazané klíče. Microsoft Sentinel detekuje anomálie, jako je neznámý přístup k IP adresám nebo úpravy mimo špičku.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

• Ovládací prvky CIS v8.1: Není k dispozici
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-28
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, PR. DS-1
• ISO 27001:2022: A.8.24, A.8.3
• SOC 2: CC6.1, CC6.2

DP-7: Použití zabezpečeného procesu správy certifikátů

Azure Policy: Viz Azure integrované definice zásad: DP-7.

Princip zabezpečení

Spravujte životní cyklus certifikátů prostřednictvím centralizovaných procesů, které zahrnují inventář, automatizované obnovení, silné kryptografické standardy a včasné odvolání. Ujistěte se, že jsou certifikáty pro důležité služby sledovány, monitorovány a obnovovány před vypršením platnosti, aby se zabránilo přerušení služeb a zachovala zabezpečenou šifrovanou komunikaci.

Riziko ke zmírnění

Špatně řízené životní cykly certifikátů způsobují výpadky služeb, oslabují šifrované kanály a povolují zosobnění. Bez centralizovaného inventáře, vynucení zásad a automatizovaného obnovení:

• Neočekávaná vypršení platnosti: Propadlé certifikáty způsobí produkční výpadky, rozbijí rozhraní API, federace identit nebo cesty důvěry klientů.
• Trvání slabé kryptografie: Zastaralé velikosti klíčů / algoritmy podpisů (např. SHA-1, RSA < 2048) se nadále používají i po zastaralosti.
• Zneužití zástupných znaků a certifikátů podepsaných svým držitelem: Rozsáhlé nebo nespravované certifikáty podepsané svým držitelem mohou umožnit laterální zosobnění a riziko snížení úrovně zabezpečení protokolu TLS.
• Nezjištěné ohrožení zabezpečení: Ukradené privátní klíče umožňují transparentní útok typu man-in-the-middle nebo dešifrování provozu až do rotace.
• Stínové certifikáty: Neschválené vystavování mimo schválené certifikační autority roztříští správu a zvyšuje počet neodhalených slepých míst v procesu odvolání.
• Chyby ručního obnovení: Nekonzistentní sekvencování nahrazení způsobuje neshody řetězu důvěryhodnosti a částečný posun prostředí.

Nedostatečná správa certifikátů snižuje šifrovanou záruku a zavádí spolehlivost i nestabilitu zabezpečení napříč důležitými službami.

MITRE ATT&CK

• Vyhnutí se obraně (TA0005): podvracení mechanismů kontroly důvěry (T1553) vydání nebo zavedení podvodných/škodlivých certifikátů pro obejití ověření.
• Vývoj prostředků (TA0042): vývoj schopností (T1587) pro vytváření certifikátů nebo nástrojů pro budoucí fáze vniknutí.
• Obrana před únikem (TA0005): oslabuje šifrování (T1600) a pokračuje v používání zastaralých algoritmů podpisů, které snižují záruku ověření.
• Přístup k přihlašovacím údajům (TA0006):: Nechráněné přihlašovací údaje (T1552) extrahující privátní klíče z nezabezpečených úložišť souborů nebo paměti procesu.
• Trvalost (TA0003): Úprava procesu ověřování (T1556) přepsání toků ověřování na základě certifikátů za účelem implementace dlouhodobého přístupu.

DP-7.1: Vytvoření zásad certifikátů a integrace certifikační autority

Definujte standardy zásad správného řízení certifikátů a integrujte důvěryhodné certifikační autority, abyste zajistili konzistentní kryptografickou kvalitu a automatizované vystavování napříč vaší infrastrukturou. Vytvořte zásady, které vynucují moderní velikosti klíčů, algoritmy podpisů a období platnosti a zároveň eliminují rizikové postupy, jako jsou certifikáty podepsané svým držitelem a certifikáty se zástupnými znaménky, které rozšiřují možnosti útoku při ohrožení privátních klíčů.

Vytvoření infrastruktury správy certifikátů:

• Pomocí Azure Key Vault můžete centrálně spravovat celý životní cyklus certifikátu: vytváření, import, obnovení, obměně, odvolání a bezpečné odstranění.
• Definujte zásady certificate v Azure Key Vault k vynucení standardů zabezpečení organizace:
  • Typ a velikost klíče: Minimální hodnota RSA 2048 bitů (doporučeno: 3072bitová nebo 4096bitová verze pro dlouhodobé certifikáty); EC P-256 nebo vyšší pro certifikáty se třemi tečkami.
  • Algoritmus podpisu: SHA-256 nebo silnější (zakáže SHA-1 a MD5).
  • Doba platnosti: Maximálně 397 dnů pro veřejné certifikáty TLS (podle požadavků na standardní hodnoty pro ca/browser forum); kratší doby trvání (90 dnů) doporučená pro sníženou expozici.
  • Certifikační autorita: Používejte jenom schválené, integrované certifikační autority (DigiCert, GlobalSign) nebo privátní certifikační autoritu vaší organizace.

Integrace certifikačních autorit:

• Použití partnerských certifikačních autorit integrovaných s Azure Key Vault pro veřejné certifikáty TLS/SSL:
  • DigiCert: Certifikáty TLS/SSL ověřené organizací (OV)
  • GlobalSign: Certifikáty TLS/SSL ověřené organizací (OV)
• V případě privátních/interních služeb integrujte interní certifikační autoritu vaší organizace (např. certifikační službu služba Active Directory – ADCS) s Azure Key Vault pro automatické vystavování certifikátů.
• Vyhněte se samopodepsaným certifikátům a wildcard certifikátům v produkčních prostředích:
  • Certifikáty podepsané samy sebou: Postrádají ověření třetími stranami, nelze je odvolat prostřednictvím veřejných protokolů CRL/OCSP a moderní prohlížeče a klienti je odmítají.
  • Certifikáty se zástupnými znaky: Široký rozsah zvyšuje riziko v případě jejich kompromitace; místo toho použijte certifikáty alternativního názvu subjektu (SAN) s explicitními úplnými názvy domén (FQDN).

Note: Pro jednoduché scénáře můžete použít Azure App Service spravované certifikáty (bezplatné, automaticky obnovené certifikáty pro vlastní domény).

DP-7.2: Implementace automatického prodlužování platnosti certifikátů

Eliminujte výpadky služeb způsobené vypršením platnosti certifikátů tím, že automatizuje pracovní postupy obnovení, které se aktivují dobře před vypršením platnosti a bezproblémově aktualizují certifikáty napříč závislými službami bez ručního zásahu. Nakonfigurujte Azure služby tak, aby automaticky načítaly obnovené certifikáty z Key Vault pomocí spravovaných identit, což snižuje provozní náil a eliminuje riziko zapomenutých ručních prodlužování během svátků nebo přechodů zaměstnanců.

Konfigurace automatizovaného prodlužování platnosti:

• Povolte v Azure Key Vault automatické obnovení certifikátu automatické obnovení certifikátu tím, že nakonfigurujete akce životnosti, které aktivují obnovení v zadaném procentu životnosti certifikátu:
  • Doporučená aktivační událost: 80–90% doby platnosti (např. ~318 dní pro 397denní certifikát).
  • Akce: Automatické obnovení (Key Vault automaticky žádá o obnovení od certifikační autority bez ručního zásahu).
• Konfigurujte kontakty oznámení, aby správci upozorňovali na nadcházející vypršení platnosti certifikátů před aktivací automatického obnovení.

Povolení automatické vazby certifikátu:

• Pro služby Azure, které podporují automatickou obměnu certifikátů (Azure App Service, Azure Application Gateway, Azure Front Door), nakonfigurujte tyto služby tak, aby automaticky načítaly aktualizované certifikáty z Key Vault pomocí spravovaných identit nebo instančních objektů s příslušnými zásadami přístupu Key Vault:
  • Azure služby automaticky vytvoří vazbu nových verzí certifikátů při obnovení (obvykle do 24 hodin, nevyžaduje se žádné restartování služby).
• U aplikací, které nemůžou automaticky využívat Key Vault certifikáty, implementujte pracovní postupy obměny certifikátů s provozními runbooky a monitorováním výstrah, aby se zabránilo výpadkům souvisejícím s vypršením platnosti.
• Udržujte inventář všech certifikátů v Azure Key Vault a sledujte název certifikátu, účel, datum vypršení platnosti, závislé služby a stav obnovení.

DP-7.3: Monitorování životního cyklu certifikátů a zpracování odvolání

Udržujte nepřetržitý přehled o stavu certifikátů prostřednictvím automatizovaného monitorování, dotazů inventáře a řídicích panelů, které odhalují certifikáty blížící se vypršení platnosti, používající zastaralou kryptografii nebo postrádající řádnou správu. Vytvořte postupy pro rychlou revokaci ohrožených certifikátů a integrujte se s průmyslovou inteligencí hrozeb, abyste proaktivně blokovali certifikáty těch certifikačních autorit, které byly kompromitovány, ještě před tím, než umožní útoky typu man-in-the-middle.

Konfigurace monitorování a upozorňování:

• Konfigurace upozornění Azure Monitor pro události vypršení platnosti certifikátu:
  • Vytváření upozornění po 30 dnech před vypršením platnosti (upozornění)
  • Vytvořte výstrahy po 7 dnech před vypršením platnosti (kritická výstraha s eskalací týmu zabezpečení).

Údržba inventáře certifikátů a řídicích panelů:

• K dotazování inventáře certifikátů použijte Azure Resource Graph:
  • Dotaz na certifikáty blížící se vypršení platnosti (do 30/60/90 dnů).
  • Dotaz na vlastnoručně podepsané certifikáty
  • Dotazování certifikátů pomocí zastaralých algoritmů (např. SHA-1)
• Vytváření řídicích panelů auditu certifikátů (např. Power BI) s vizualizacemi:
  • Časová osa vypršení platnosti certifikátu podle časového intervalu
  • Počet samopodepsaných certifikátů podle skupiny prostředků
  • Certifikáty využívající zastaralé kryptografické standardy.
• Pravidelně kontrolujte řídicí panely auditu certifikátů během schůzek kontroly zabezpečení (doporučeno: čtvrtletně).

Stanovit postupy odvolání:

• Vytvořte postupy odvolání certifikátu pro ohrožené nebo vyřazené certifikáty:
  • Proces odvolání dokumentu (zakažte certifikát v Key Vault, upozorněte závislé služby).
  • Udržujte runbooky reakce na incidenty pro scénáře kompromitace certifikátů.
  • Sledujte průmyslová upozornění na ohrožené kořenové nebo zprostředkující certifikáty CA a blokujte je okamžitě.

Příklad implementace

Podnik s více než 200 veřejnými webovými aplikacemi centralizovanou správu životního cyklu certifikátů pomocí Azure Key Vault integrované s DigiCert jako certifikační autoritou.

Výzva: Procesy ručního obnovení certifikátů způsobily neočekávaně několik výpadků v produkčním prostředí. Certifikáty s wildcardem způsobily nadměrnou šíři dopadu, když byly kompromitovány privátní klíče. Fragmentovaná správa certifikátů napříč týmy způsobila stínové certifikáty, nekonzistentní kryptografické standardy a zpožděné odvolání během incidentů zabezpečení. Bez automatizovaného obnovení a centralizovaného inventáře organizace čelí selháním dodržování předpisů a přerušením služeb.

Přístup řešení:

• Konfigurovat integraci certifikační autority s Azure Key Vault: Přidat DigiCert (nebo jinou partnerovanou certifikační autoritu) k Key Vault s přihlašovacími údaji rozhraní API pro automatizované žádosti o certifikáty.
• Vytvořit zásady certifikátů, které vynucují standardy zabezpečení: Definovat zásady certifikátu se jménem certifikátu (www-contoso-com-2024), vystavitelem (DigiCert), subjektem (CN=www.contoso.com), názvy DNS (SAN: www.contoso.com, api.contoso.com, portal.contoso.com – vyhněte se použití certifikátů s hvězdičkou), typ klíče (RSA 4096 bitů), podpisový algoritmus (SHA-256), doba platnosti (maximálně 397 dnů dle základních parametrů CA/Browser Forum), nastavení akce pro automatické prodlužování životnosti certifikátu (spustit automatickou obnovu při dosažení 80 % životnosti certifikátu, přibližně 318 dní pro certifikát platný 397 dnů), akce: automatická obnova (Key Vault požádá o obnovu od DigiCert bez ručního zásahu).
• Konfigurujte automatickou vazbu certifikátů pro Azure služby: Pro Azure App Service importujte certifikát z Key Vault a přiřaďte uživatelsky přiřazenou spravovanou identitu s rolí uživatele tajných kódů Key Vault, zapněte automatické aktualizace certifikátů (služba App Service vytvoří vazbu na novou verzi certifikátu do 24 hodin po obnovení, není vyžadován restart). Pro Azure Application Gateway nakonfigurujte naslouchací proces tak, aby načítal certifikát z Key Vault, přiřaďte uživatelsky přiřazenou spravovanou identitu s rolemi uživatele tajných klíčů a uživatele certifikátů Key Vault, služba Application Gateway automaticky načte aktualizovaný certifikát po obnovení Key Vault.
• Konfigurujte upozornění na vypršení platnosti certifikátu: Vytvořte ve Azure Monitor dvě pravidla upozornění – 30denní upozornění na vypršení platnosti (odeslání oznámení kanálu Slack pro přípravu platformy), 7denní kritická výstraha vypršení platnosti (otevřete lístek Jira pro ruční kontrolu a odeslání e-mailu týmu zabezpečení).
• Odstranění certifikátů zástupných znaků ve prospěch certifikátů SAN: Proveďte audit stávajících certifikátů zástupných znaků (*.contoso.com) v Key Vaultu a nahraďte je certifikáty SAN obsahujícími explicitní názvy DNS (www.contoso.com, api.contoso.com). Výhoda: pokud dojde ke kompromitaci privátního klíče, ovlivní se jen uvedené plně kvalifikované názvy domén (ne všechny subdomény).
• Monitorovat vypršení platnosti certifikátu: Použít Azure Resource Graph k dotazování inventáře certifikátů a identifikaci certifikátů blížících se vypršení platnosti (do 30 dnů), certifikátů podepsaných svým držitelem nebo certifikátů pomocí zastaralého algoritmu podpisu SHA-1 zkontrolujte během schůzek kontroly zabezpečení řídicí panel čtvrtletně.

Výsledek: Automatické prodlužování platnosti certifikátů se aktivuje při 80% životnosti. Azure App Service a Application Gateway načítají aktualizované certifikáty do 24 hodin prostřednictvím spravovaných identit (nevyžaduje se restartování). Azure Monitor upozornění upozorňují platformní inženýry před vypršením platnosti. Certifikáty SAN nahrazují certifikáty zástupných znaků a snižují tak okruh kompromitace.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

• Ovládací prvky CIS v8.1: Není k dispozici
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, ID.AM-3
• ISO 27001:2022: A.8.3
• SOC 2: CC6.1, CC6.2

DP-8: Zajištění zabezpečení klíče a úložiště certifikátů

Azure Policy: Viz Azure integrované definice zásad: DP-8.

Princip zabezpečení

Zabezpečené služby trezoru klíčů prostřednictvím hloubkových kontrol ochrany: přístup s nejnižšími oprávněními, izolace sítě, komplexní protokolování a monitorování, možnosti zálohování a obnovení a ochrana založené na HSM, pokud je to potřeba. Trezory klíčů jsou kritická infrastruktura, která chrání kryptografické klíče a certifikáty používané k šifrování a ověřování.

Riziko ke zmírnění

Ohrožení zabezpečení klíče a úložiště certifikátů zneplatňuje upstreamové šifrování, podepisování a záruky identit. Bez zabezpečeného přístupu k trezoru, monitorování ani izolace:

• Exfiltrace klíčů: Ukradené KEK klíče / HSM materiál umožňují hromadné dešifrování uložených dat a zachycení provozu.
• Stínový přístup pro správu: Příliš široká konfigurace RBAC nebo politika umožňuje neoprávněný export klíčů, vymazání nebo vrácení verze zpět.
• Tiché manipulování: Výměna škodlivého klíče umožňuje transparentní prostředník nebo padělaný kód/podpisy.
• Vystavení sítě: Zneužití veřejného koncového bodu (nacpání přihlašovacích údajů, sondování rozhraní API) zvyšuje prostor pro útok hrubou silou nebo přehrání tokenu.
• Náhodné destruktivní akce: Chybějící ochrana proti obnovitelnému odstranění nebo vymazání vede k nevratné ztrátě kryptografických dat.
• Nedostatek sledovatelnosti auditu: Nedostatek neměnných protokolů ovlivňuje reakci na incidenty a zákonné potřeby.
• Nesegmentovaná tenantská architektura: Společné klíče aplikací rozšiřují dosah bočního pohybu po kompromitaci jedné identity.

Slabiny úložiště se rychle rozšiřují k systémovým problémům důvěrnosti, integrity a dostupnosti napříč závislými úlohami.

MITRE ATT&CK

• Přístup k přihlašovacím údajům (TA0006): nechráněné přihlašovací údaje / úložiště přihlašovacích údajů (T1552 / T1555) získané prostřednictvím chybně nakonfigurované role trezoru nebo zásad sítě.
• Obrana před únikem (TA0005): útočník uprostřed (T1557) zachytává provoz směřující do trezoru pro zachycení klíčů/certifikátů, nebo oslabuje šifrování (T1600) nahrazením silných klíčů materiálem kontrolovaným útočníkem.
• Eskalace oprávnění (TA0004): platné účty (T1078) zneužívají příliš široké role operátora trezoru k vyjmenování a úpravě tajemství.
• Dopad (TA0040): zničení dat / zamezení obnovení (T1485 / T1490) provádění destruktivních vyprázdňovacích sekvencí, které brání obnovení.

DP-8.1: Implementace řízení přístupu pro Key Vault

Chraňte kryptografickou základnu vaší infrastruktury vynucením přísných řízení přístupu založených na identitách, které brání neoprávněnému přístupu k klíčům, omezují oprávnění správce na oprávněné časové období a eliminují úložiště přihlašovacích údajů prostřednictvím spravovaných identit. Implementujte oddělení povinností mezi správci klíčů a klíčovými uživateli, abyste zabránili jakémukoli narušení identity ve správě a zneužití kryptografického materiálu.

Zavést řízení přístupu na základě role a oddělení povinností:

• Implementujte Azure RBAC pro Key Vault pro vynucení řízení přístupu s nejnižšími oprávněními:
  • Pro Azure Key Vault Managed HSM: Použijte local RBAC na úrovni jednotlivých klíčů, tajných kódů a certifikátů s předdefinovanými rolemi (spravovaný kryptografický pracovník HSM, crypto user, crypto auditor).
  • Pro Azure Key Vault Standard/Premium: Vytvořte vyhrazené trezory pro každou aplikaci nebo prostředí pro vynucení logického oddělení a přiřaďte role RBAC (Správce Key Vaultu, Důstojník pro tajemství, Důstojník pro certifikáty) s oborem specifikovaným pro aplikaci.
• Vynucování oddělení povinností: Samostatné role pro správu klíčů (kteří mohou vytvářet nebo otáčet klíče) od kryptografických operací (kteří můžou používat klíče pro šifrování/dešifrování).

Použití spravovaných identit a přístupu JIT:

• Použijte spravované identity pro prostředky Azure (App Services, VMs, Azure Functions atd.) pro přístup k Key Vault místo ukládání přihlašovacích údajů do kódu aplikace nebo konfiguračních souborů. Spravované identity eliminují složitost úložiště a rotace přihlašovacích údajů.
• Implementujte Azure AD Privileged Identity Management (PIM) pro just-in-time administrativní přístup k Key Vault.
  • Nakonfigurujte způsobilá přiřazení pro roli správce Key Vault (ne trvalá přiřazení).
  • Vyžadovat odůvodnění, vícefaktorové ověřování a schválení aktivace.
  • Nastavte maximální dobu aktivace (např. 8 hodin).
  • Provádění pravidelných kontrol přístupu pro odvolávání nepotřebných trvalých oprávnění.

DP-8.2: Posílení zabezpečení sítě Key Vault

Odstraňte plochy útoků dostupné z internetu směrováním veškerého přístupu ke Key Vault prostřednictvím privátních koncových bodů ve vaší virtuální síti. Tím zabráníte plnění přihlašovacích údajů, útokům hrubou silou a rekognoskaci externími hrozbami. Pokud je veřejný přístup pro scénáře CI/CD nepochybný, implementujte striktní seznam povolených IP adres a pravidla brány firewall pro vytvoření nejmenšího možného okna expozice.

Nasazení Private Link a konfigurace firewallu:

• Zabezpečený síťový přístup k Azure Key Vault pomocí Azure Private Link k navázání privátního připojení z virtuálních sítí bez zveřejnění Key Vault na veřejný internet.
• Nakonfigurujte bránu firewall Key Vault tak, aby omezovala přístup k určitým rozsahům IP adres nebo virtuálním sítím pro scénáře, kdy Private Link není možné:
  • Pokud je to možné, zakažte veřejný přístup (Key Vault přístupné jenom přes privátní koncový bod).
  • Pokud se vyžaduje veřejný přístup (např. pro kanály CI/CD), povolte přístup z vybraných sítí jenom s úzkými seznamy povolených IP adres.
• Vytvořte a propojte soukromé zóny DNS (např. privatelink.vaultcore.azure.net) k virtuálním sítím, abyste zajistili správné vyřešení DNS pro soukromé koncové body.

DP-8.3: Povolte ochranu a monitorování Key Vault

Implementujte ochranu v hloubce, která zabraňuje nevratné ztrátě kryptografických dat pomocí dílčího odstranění a ochrany proti vymazání při použití klíčů podporovaných HSM pro produkční zátěže vyžadující zabezpečení certifikované dle FIPS. Nasaďte komplexní monitorování pomocí Microsoft Defender pro Key Vault a Microsoft Sentinel za účelem detekce neobvyklých vzorů přístupu, neobvyklých klíčových operací a anomálií správy, které indikují ohrožení zabezpečení, vnitřní hrozby nebo aktivity rekognoskace, které cílí na kryptografickou infrastrukturu.

Povolit ochranu proti obnovitelnému odstranění a vymazání:

• Povolte soft delete a purge protection na všech Azure Key Vault, abyste zabránili náhodnému nebo škodlivému odstranění klíčů, tajných kódů a certifikátů:
  • Obnovitelné odstranění umožňuje obnovení během doby uchovávání (výchozí hodnota: 90 dnů).
  • Ochrana před vymazáním zabraňuje trvalému odstranění během doby uchovávání.
  • Vynucujte tato nastavení pomocí Azure Policy pomocí předdefinovaných zásad: Trezory klíčů by měly mít povolené obnovitelné odstranění a trezory klíčů by měly mít povolenou ochranu před vymazáním (účinek deployIfNotExists).
• Implementujte zásady životního cyklu klíčů, abyste se vyhnuli kryptografickému vymazání dat:
  • Před vymazáním šifrovaných dat ověřte, že se šifrovací klíče uchovávají po požadovanou dobu uchovávání dat.
  • Při vyřazení klíčů z provozu místo odstranění použijte operaci zákazu, abyste zabránili náhodné ztrátě dat při zachování klíčových metadat pro účely auditu.
  • Vytvořte a otestujte postupy zálohování Key Vault pro scénáře zotavení po havárii.

Použití klíčů založených na HSM a BYOK:

• Použití klíčů založených na HSM pro produkční úlohy vyžadující silnou kryptografickou ochranu:
  • Azure Key Vault Premium: RSA-HSM a EC-HSM klíče chráněné HSM zařízeními validovanými podle FIPS 140-2 úrovně 2 (sdílené vícetenantní).
  • Azure Key Vault Managed HSM: Klíče RSA-HSM a EC-HSM chráněné validovanými HSM podle FIPS 140-3 úroveň 3 (vyhrazené fondy s jedním nájemcem).
• Pro scénáře Bring Your Own Key (BYOK) vygenerujte klíče v místních modulech HSM FIPS 140-2 level 2+ a pomocí mechanismu přenosu BYOK bezpečně naimportujte klíče do Azure Key Vault a zachovejte kryptografický důkaz o původu klíče a vazbě.

Povolení monitorování a detekce hrozeb:

• Povolte diagnostické protokolování pro Azure Key Vault a směrujte protokoly do Azure Monitor, Log Analytics nebo Microsoft Sentinel k zachycení všech operací roviny správy a roviny dat. Monitorujte podezřelé aktivity, včetně neobvyklých vzorů přístupu ke klíčům, neúspěšných pokusů o ověření a změn správy.
• Povolte Microsoft Defender pro Key Vault k detekci neobvyklých vzorů přístupu, neobvyklých klíčových operací a potenciálních hrozeb, jako je zneužití přihlašovacích údajů, podezřelé načítání klíčů nebo anomálie správy. Integrujte Defender pro výstrahy Key Vault s pracovními postupy reakce na incidenty.
• Integrujte protokoly Key Vault s Microsoft Sentinel a vytvořte analytická pravidla pro detekci anomálií, jako je neobvyklý regionální přístup, potenciální pokusy o hrubou silou nebo podezřelé operace správy. Implementujte playbooky automatizovaných odpovědí za účelem izolace ohrožených identit a upozorněte bezpečnostní týmy.

Poznámka: Všechny SKU Key Vault záměrně zabraňují exportu klíče; kryptografické operace se provádějí v rámci zabezpečeného prostoru HSM. Nikdy neexportujte ani neukládejte klíče v prostém textu mimo Azure Key Vault.

Příklad implementace

Nadnárodní technologická společnost implementovala hloubkové zabezpečení pro svou Azure Key Vault infrastrukturu, která chrání šifrovací klíče, tajné kódy rozhraní API a certifikáty TLS pro 500 mikroslužeb a další.

Výzva: Nadměrná oprávnění RBAC umožňují vývojářům přímý přístup k produkčním trezorům klíčů Key Vault, což umožňuje vytvářet vnitřní rizika a porušení dodržování předpisů. Veřejné vystavení na internetu umožnilo zneužití přihlašovacích údajů a pokusy o průzkum. Bez komplexního monitorování a automatizované odpovědi nebyly zjištěny vzory podezřelého přístupu ke klíčům. Nedostatek obnovitelného odstranění a ochrany před vymazáním riskoval trvalou ztrátu kryptografických dat během incidentů.

Přístup řešení:

• Nasazení dedikovaných trezorů klíčů pro logickou segmentaci: Vytvořte trezor klíčů pro každé prostředí a obchodní jednotku s názvovou konvencí kv-{businessunit}-{environment}-{region} (např. kv-finance-prod-eastus2, kv-finance-dev-eastus2), nasaďte je v samostatných skupinách prostředků pro každé prostředí, aby byla zajištěna izolace (ohrožený instanční objekt pro vývoj nemá přístup k produkčním klíčům).
• Konfigurujte RBAC pro přístup s nejnižšími oprávněními: Pro neprodukční trezory klíčů (vývoj/příprava) přiřaďte uživatelskou roli tajných kódů Key Vault (jen pro čtení) ke skupinám zabezpečení vývojářů – vývojáři můžou číst tajné kódy v rámci vývoje/přípravy, ale mají nulový přístup k produkčním trezorům klíčů Key Vault; pro produkční trezory klíčů Key Vault přiřaďte uživatelskou roli tajných kódů Key Vault instančním objektům CI/CD (Azure DevOps pipeline spravované identity), s omezeným rozsahem na konkrétní pojmenované tajné kódy, žádný interaktivní přístup vývojářů k produkčním klíčům.
• Zpevněte zabezpečení sítě pomocí Azure Private Link: Nasaďte privátní koncové body pro Key Vault (vyberte virtuální síť a podsíť, vytvořte privátní zónu DNS privatelink.vaultcore.azure.net a propojte ji s VNet), nakonfigurujte bránu firewall Key Vault (zakažte veřejný přístup, takže Key Vault bude přístupný pouze prostřednictvím privátního koncového bodu, pokud je vyžadován veřejný přístup pro CI/CD, povolte přístup z vybraných sítí pouze se schválenými podsítěmi Azure VNet a rozsahy IP adres agentů CI/CD).
• Povolit Microsoft Defender pro Key Vault: Povolit Microsoft Defender pro Key Vault na úrovni předplatného, Defender monitoruje anomálie, včetně neobvyklého geografického přístupu, podezřelého výčtu (rychlé operace seznamu označující rekognoskaci), abnormálních administrativních operací (hromadný výmaz tajemství).
• Integrace se službou Microsoft Sentinel pro automatizovanou reakci: Přidejte konektor dat Microsoft Defender for Cloud do služby Sentinel, vytvořte analytická pravidla Sentinel pro neobvyklý regionální přístup, potenciální útok hrubou silou, podezřelé administrativní operace, nastavte playbooky pro automatizované odpovědi k blokování podezřelých identit a upozornění bezpečnostním týmům.
• Streamové diagnostické protokoly do Log Analytics: Povolte protokolování diagnostiky pro Key Vault s AuditEvent (všechny operace s klíčem, tajným klíčem nebo certifikátem), AllMetrics (frekvence využití, latence), odesílání do Log Analytics s uchováváním po dobu 2 let, vytváření vlastních KQL dotazů k detekci anomálií, včetně potenciální detekce hrubé síly (10+ neautorizovaných pokusů během 5 minut), zakázané operace měkkého odstranění (indikátor sabotáže).
• Implementace Just-In-Time přístupu správce pomocí Azure AD PIM: Konfigurovat způsobilá přiřazení pro roli správce Key Vault (přidat členy bezpečnostního týmu jako způsobilé ne trvalé přiřazení, vyžadovat odůvodnění a vícefaktorové ověřování pro aktivaci, nastavit maximální dobu aktivace 8 hodin, vyžadovat schválení od vedoucího architekta zabezpečení), provádět čtvrtletní kontroly přístupu pro všechna přiřazení k roli správce Key Vault; odvolat nepotřebný přístup.

Výsledek: Vyhrazené trezory klíčů pro každé prostředí vynucují segmentaci. RBAC omezuje vývojáře na neprodukční přístup jen pro čtení. Private Link eliminuje vystavení veřejnosti na internetu. Microsoft Defender detekuje anomálie. Playbooky Sentinel automaticky deaktivují podezřelé identity. PIM umožňuje přístup správce v reálném čase, což výrazně snižuje stálá privilegia.

Úroveň závažnosti

Musí to být.

Mapování ovládacích prvků

• Ovládací prvky CIS v8.1: Není k dispozici
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
• PCI-DSS v4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, PR. DS-1
• ISO 27001:2022: A.8.3, A.8.24
• SOC 2: CC6.1, CC6.2