Aspekty zabezpečení pro klíčové úlohy v Azure

Zabezpečení je jedním ze základních principů návrhu a také klíčovou oblastí návrhu, kterou je potřeba považovat za prvotřídní problém v rámci klíčového architektonického procesu.

Vzhledem k tomu, že hlavním cílem klíčového návrhu je maximalizovat spolehlivost tak, aby aplikace zůstala výkonná a dostupná, aspekty zabezpečení a doporučení použitá v této oblasti návrhu se zaměří na zmírnění hrozeb s kapacitou ovlivnit dostupnost a bránit celkové spolehlivosti. Například úspěšné útoky DDoS (Denial-Of-Service) mají katastrofický dopad na dostupnost a výkon. Způsob, jakým aplikace zmírní tyto vektory útoku, například SlowLoris, ovlivní celkovou spolehlivost. Proto musí být aplikace plně chráněná před hrozbami, jejichž cílem je přímo nebo nepřímo ohrozit spolehlivost aplikace, aby byla skutečně kritická.

Je také důležité poznamenat, že s posíleným stavem zabezpečení jsou často spojeny významné kompromisy, zejména s ohledem na výkon, provozní flexibilitu a v některých případech spolehlivost. Například zahrnutí vložených síťových virtuálních zařízení (NVA) pro funkce brány firewall nové generace (NGFW), jako je hloubková kontrola paketů, přinese významné snížení výkonu, další provozní složitost a riziko spolehlivosti, pokud škálovatelnost a operace obnovení nejsou úzce sladěné s výkonem aplikace. Proto je nezbytné, aby další součásti zabezpečení a postupy určené ke zmírnění klíčových vektorů hrozeb byly také navrženy tak, aby podporovaly cíl spolehlivosti aplikace, což bude tvořit klíčový aspekt doporučení a aspektů uvedených v této části.

Důležité

Tento článek je součástí řady klíčových úloh Azure Well-Architected . Pokud tuto řadu neznáte, doporučujeme začít s tím, co je kritická úloha?

Projekt Pro klíčové open source

Referenční implementace jsou součástí projektu open source, který je k dispozici na GitHubu. Prostředky kódu používají model nulová důvěra (Zero Trust), který strukturuje a řídí přístup k návrhu a implementaci zabezpečení.

Zarovnání s modelem nulová důvěra (Zero Trust)

Model Microsoft nulová důvěra (Zero Trust) poskytuje proaktivní a integrovaný přístup k uplatňování zabezpečení ve všech vrstvách aplikace. Hlavní principy nulová důvěra (Zero Trust) se snaží explicitně a nepřetržitě ověřovat každou transakci, uplatňovat nejnižší oprávnění, používat inteligentní funkce a pokročilé zjišťování, aby bylo možné reagovat na hrozby téměř v reálném čase. V konečném důsledku se zaměřuje na odstranění důvěryhodnosti uvnitř i vně obvodů aplikací a vynucuje ověření čehokoli, co se pokouší připojit k systému.

Na co dát pozor při navrhování

Při posuzování stavu zabezpečení aplikace začněte těmito otázkami jako základem pro každou úvahu.

• Průběžné testování zabezpečení za účelem ověření zmírnění rizik klíčových ohrožení zabezpečení

  • Provádí se testování zabezpečení jako součást automatizovaných procesů CI/CD?
  • Pokud ne, jak často se provádí konkrétní testování zabezpečení?
  • Měří se výsledky testů podle požadovaného stavu zabezpečení a modelu hrozeb?

• Úroveň zabezpečení ve všech nižších prostředích.

  • Mají všechna prostředí v rámci životního cyklu vývoje stejný stav zabezpečení jako produkční prostředí?

• Kontinuita ověřování a autorizace v případě selhání

  • Pokud jsou ověřovací nebo autorizační služby dočasně nedostupné, bude aplikace moct dál fungovat?

• Automatizované dodržování předpisů a náprava zabezpečení

  • Dají se detekovat změny klíčových nastavení zabezpečení?
  • Jsou odpovědi na nápravu nevyhovujících změn automatizované?

• Kontrola tajných kódů za účelem zjištění tajných kódů před potvrzením kódu, aby se zabránilo úniku tajných kódů prostřednictvím úložišť zdrojového kódu.

  • Je ověřování ve službách možné bez přihlašovacích údajů jako součásti kódu?

• Zabezpečení softwarového dodavatelského řetězce.

  • Je možné sledovat běžná ohrožení zabezpečení a ohrožení zabezpečení (CVE) v rámci využívaných závislostí balíčků?
  • Existuje automatizovaný proces aktualizace závislostí balíčků?

• Životní cyklus klíčů ochrany dat.

  • Dají se klíče spravované službou použít k ochraně integrity dat?
  • Pokud se vyžadují klíče spravované zákazníkem, jaký je zabezpečený a spolehlivý životní cyklus klíče?

• Nástroje CI/CD by měly vyžadovat Microsoft Entra instanční objekty s dostatečným přístupem na úrovni předplatného, aby se usnadnil přístup k rovině řízení pro nasazení prostředků Azure do všech uvažovaných předplatných prostředí.

  • Pokud jsou prostředky aplikace uzamčené v rámci privátních sítí, existuje cesta připojení v rovině privátních dat, aby nástroje CI/CD mohly provádět nasazení a údržbu na úrovni aplikace.
    • To přináší další složitost a vyžaduje posloupnost v rámci procesu nasazení prostřednictvím požadovaných privátních agentů sestavení.

Doporučení k návrhu

• Pomocí Azure Policy vynucujte konfigurace zabezpečení a spolehlivosti pro všechny služby, abyste zajistili, že jakákoli odchylka bude buď napravena, nebo zakázána řídicí rovinou v době konfigurace, což pomáhá zmírnit hrozby spojené se scénáři "správce se zlými úmysly".

• Pomocí Microsoft Entra Privileged Identity Management (PIM) v rámci produkčních předplatných můžete odvolat trvalý přístup roviny řízení k produkčním prostředím. Tím se výrazně sníží riziko, které představují scénáře "se zlými správci" prostřednictvím dalších "kontrol a zůstatků".

• Spravované identity Azure používejte pro všechny služby, které tuto funkci podporují, protože usnadňují odebrání přihlašovacích údajů z kódu aplikace a odstraňují provozní zatížení správy identit pro komunikaci mezi službami.

• Pro autorizaci roviny dat se všemi službami, které podporují tuto funkci, použijte Microsoft Entra řízení přístupu na základě role (RBAC).

• K integraci s Microsoft Entra ID použijte knihovny ověřování Microsoft identity platform první strany v kódu aplikace.

• Zvažte možnost zabezpečeného ukládání tokenů do mezipaměti, abyste umožnili nižší, ale dostupné prostředí, pokud vybraná platforma identit není k dispozici nebo je pro autorizaci aplikací dostupná jenom částečně.

  • Pokud zprostředkovatel nemůže vydávat nové přístupové tokeny, ale přesto ověřuje ty stávající, aplikace a závislé služby můžou fungovat bez problémů, dokud jejich tokeny nevyprší.
  • Ukládání tokenů do mezipaměti se obvykle automaticky zpracovává pomocí knihoven ověřování (například MSAL).

• Pomocí infrastruktury jako kódu (IaC) a automatizovaných kanálů CI/CD můžete řídit aktualizace všech komponent aplikace, a to i v případě selhání.

  • Ujistěte se, že připojení ke službě nástrojů CI/CD jsou chráněná jako důležité citlivé informace a neměla by být přímo dostupná žádnému servisnímu týmu.
  • Použití podrobného řízení přístupu na základě role na produkční kanály CD za účelem zmírnění rizik pro správce se zlými úmysly.
  • Zvažte použití bran ručního schválení v kanálech nasazení v produkčním prostředí k dalšímu zmírnění rizik "škodlivých správců" a poskytnutí dodatečné technické záruky pro všechny produkční změny.
    • Další bezpečnostní brány mohou být kompromisem z hlediska flexibility a měly by být pečlivě vyhodnoceny s ohledem na to, jak je možné udržovat flexibilitu i s ručními branami.

• Definujte vhodný stav zabezpečení pro všechna nižší prostředí, abyste zajistili zmírnění klíčových ohrožení zabezpečení.

  • Nepoužívejte stejný stav zabezpečení jako v produkčním prostředí, zejména s ohledem na exfiltraci dat, pokud to zákonné požadavky nestanovují, protože to výrazně ohrožuje flexibilitu vývojářů.

• Povolte Microsoft Defender pro cloud (dříve označovaný jako Azure Security Center) pro všechna předplatná, která obsahují prostředky pro kritickou úlohu.

  • K vynucení dodržování předpisů použijte Azure Policy.
  • Povolte Azure Defender pro všechny služby, které tuto funkci podporují.

• Využijte DevSecOps a implementujte testování zabezpečení v rámci kanálů CI/CD.

  • Výsledky testů by se měly měřit podle vyhovujícího stavu zabezpečení, aby bylo možné informovat o schválení vydaných verzí, ať už automatizovaných, nebo ručních.
  • Použijte testování zabezpečení jako součást produkčního procesu cd pro každou verzi.
    • Pokud testování zabezpečení jednotlivých verzí ohrožuje provozní flexibilitu, ujistěte se, že se používá vhodná frekvence testování zabezpečení.

• Povolte kontrolu tajných kódů a kontrolu závislostí v úložišti zdrojového kódu.

Modelování hrozeb

Modelování hrozeb poskytuje přístup založený na rizicích k návrhu zabezpečení a využívá zjištěné potenciální hrozby k vývoji vhodných zmírnění zabezpečení. Existuje mnoho možných hrozeb s různou pravděpodobností výskytu a v mnoha případech mohou hrozby zřetězenými neočekávanými, nepředvídatelnými a dokonce i chaotickými způsoby. Tato složitost a nejistota jsou důvodem, proč jsou přístupy zabezpečení založené na tradičních technologiích do značné míry nevhodné pro klíčové cloudové aplikace. Očekávejte, že proces modelování hrozeb pro kritickou aplikaci bude složitý a nesrozumitější.

Aby se tyto výzvy zorientovaly, měl by se použít vrstvený přístup k hloubkové ochraně, který definuje a implementuje kompenzační zmírnění rizik pro modelované hrozby, a to s ohledem na následující obranné vrstvy.

1. Platforma Azure se základními možnostmi a ovládacími prvky zabezpečení.
2. Architektura aplikace a návrh zabezpečení.
3. Integrované, povolené a nasaditelné funkce zabezpečení, které se používají pro zabezpečení prostředků Azure.
4. Kód aplikace a logika zabezpečení.
5. Provozní procesy a DevSecOps.

Poznámka

Při nasazování v rámci cílové zóny Azure mějte na paměti, že implementace cílové zóny poskytuje další vrstvu zmírnění hrozeb prostřednictvím zřizování centralizovaných funkcí zabezpečení.

Na co dát pozor při navrhování

STRIDE poskytuje odlehčenou architekturu rizik pro vyhodnocování bezpečnostních hrozeb napříč klíčovými vektory hrozeb.

• Identita s falšováním identity: Zosobnění osob s oprávněním. Například útočník zosobní jiného uživatele pomocí
  • Identita
  • Authentication
• Manipulace se vstupem: Úprava vstupu odeslaného do aplikace nebo porušení hranic důvěryhodnosti za účelem úpravy kódu aplikace. Například útočník, který pomocí injektáže SQL odstraní data v databázové tabulce.
  • Integrita dat
  • Ověřování
  • Seznam blokovaných a povolených
• Odmítnutí akce: Schopnost vyvrátit již provedené akce a schopnost aplikace shromažďovat důkazy a řídit odpovědnost. Například odstranění důležitých dat, aniž by bylo možné trasovat škodlivého správce.
  • Auditování/protokolování
  • certifikát
• Zpřístupnění informací: Získání přístupu k omezeným informacím. Příkladem může být útočník, který získá přístup k souboru s omezeným přístupem.
  • Šifrování
  • Exfiltrace dat
  • Útoky man-in-the-middle
• Odepření služby: Narušení škodlivé aplikace s cílem snížit uživatelské prostředí. Například útok botnetu DDoS, jako je Například Slowloris.
  • DDoS
  • Botnety
  • Funkce CDN a WAF
• Zvýšení oprávnění: Získání přístupu k privilegovaným aplikacím prostřednictvím zneužití autorizace. Například útočník, který manipuluje s řetězcem adresy URL, aby získal přístup k citlivým informacím.
  • Vzdálené spouštění kódu
  • Autorizace
  • Izolace

Doporučení k návrhu

• Vydělte technický rozpočet v rámci každého sprintu, abyste mohli vyhodnotit potenciální nové hrozby a implementovat zmírnění rizik.

• Je třeba vynaložit vědomé úsilí, aby se zajistilo, že zmírnění rizik zabezpečení bude zachyceno v rámci společných technických kritérií, aby se zajistila konzistence napříč všemi týmy aplikačních služeb.

• Začněte s modelováním hrozeb na úrovni služby a sjednocte model sloučením modelu vlákna na úrovni aplikace.

Ochrana proti vniknutí do sítě

Zabránění neoprávněnému přístupu k kriticky důležité aplikaci a zahrnutím dat je nezbytné pro zachování dostupnosti a zajištění integrity dat.

Na co dát pozor při navrhování

• nulová důvěra (Zero Trust) předpokládá stav porušení zabezpečení a ověřuje každý požadavek, jako by pocházel z neřízené sítě.

  • Pokročilá implementace sítě s nulovou důvěryhodností využívá mikrosegmentaci a distribuované mikro perimetry příchozího/výchozího přenosu dat.

• Ke službám Azure PaaS se obvykle přistupuje přes veřejné koncové body. Azure poskytuje možnosti zabezpečení veřejných koncových bodů nebo dokonce jejich úplné soukromí.

  • Azure Private Link/privátní koncové body poskytují vyhrazený přístup k prostředku Azure PaaS pomocí privátních IP adres a připojení k privátní síti.
  • Virtual Network koncové body služby poskytují přístup na úrovni služby z vybraných podsítí k vybraným službám PaaS.
  • Virtual Network Injection poskytuje vyhrazená privátní nasazení pro podporované služby, například App Service prostřednictvím App Service Environment.
    • Provoz roviny správy stále prochází přes veřejné IP adresy.

• U podporovaných služeb Azure Private Link používáním privátních koncových bodů Azure řeší rizika exfiltrace dat spojená s koncovými body služby, jako je například škodlivý správce, který zapisuje data do externího prostředku.

• Při omezení síťového přístupu ke službám Azure PaaS pomocí privátních koncových bodů nebo koncových bodů služeb bude pro kanály nasazení nutný zabezpečený síťový kanál pro přístup k řídicí rovině Azure i rovině dat prostředků Azure, aby bylo možné nasadit a spravovat aplikaci.

  • Privátní agenti sestavení v místním prostředí nasazení do privátní sítě, protože prostředek Azure je možné použít jako proxy k provádění funkcí CI/CD přes privátní připojení. Pro agenty sestavení by se měla použít samostatná virtuální síť.
    • Vyžaduje se připojení k privátním agentům sestavení z nástrojů CI/CD.
  • Alternativním přístupem je upravit pravidla brány firewall pro prostředek v rámci kanálu tak, aby umožňovala připojení z veřejné IP adresy agenta Azure DevOps, přičemž brána firewall se po dokončení úlohy následně odebere.
    • Tento přístup se ale vztahuje pouze na podmnožinu služeb Azure. Například to není možné pro privátní clustery AKS.
  • K provádění vývojářských a administrativních úloh v jump boxech aplikační služby je možné použít.

• Dokončení úloh správy a údržby je dalším scénářem, který vyžaduje připojení k rovině dat prostředků Azure.

• Connections služby s odpovídajícím Microsoft Entra instančním objektem je možné použít v rámci Azure DevOps k uplatnění RBAC prostřednictvím Microsoft Entra ID.

• Značky služeb je možné použít u skupin zabezpečení sítě, aby se usnadnilo připojení ke službám Azure PaaS.

• Skupiny zabezpečení aplikací se netýknou více virtuálních sítí.

• Zachytávání paketů v Azure Network Watcher je omezené na maximálně pět hodin.

Doporučení k návrhu

• Omezte přístup k veřejné síti na absolutní minimum potřebné k tomu, aby aplikace splnila svůj obchodní účel a omezila prostor pro externí útoky.

  • Pomocí Azure Private Link můžete vytvořit privátní koncové body pro prostředky Azure, které vyžadují zabezpečenou integraci sítě.
  • Pomocí hostovaných privátních agentů sestavení pro nástroje CI/CD nasaďte a nakonfigurujte prostředky Azure chráněné službou Azure Private Link.
    • Agenti hostovaní Microsoftem se nebudou moct přímo připojit k prostředkům integrovaným v síti.

• Při práci s privátními agenty sestavení nikdy neotevírejte port RDP nebo SSH přímo na internetu.

  • Azure Bastion použijte k zajištění zabezpečeného přístupu k Azure Virtual Machines a provádění úloh správy v Azure PaaS přes internet.

• K zabezpečení všech veřejných IP adres v aplikaci použijte plán ochrany DDoS Standard.

• Použití služby Azure Front Door se zásadami firewallu webových aplikací k poskytování a ochraně globálních aplikací HTTP/S, které pokrývají více oblastí Azure.

  • Ověření ID hlaviček použijte k uzamčení veřejných koncových bodů aplikace tak, aby přijímaly pouze provoz pocházející z instance Služby Azure Front Door.

• Pokud další požadavky na zabezpečení sítě, jako je hloubková kontrola paketů nebo kontrola protokolu TLS, vyžadují použití Azure Firewall Premium nebo síťového virtuálního zařízení (NVA), ujistěte se, že je nakonfigurované pro maximální vysokou dostupnost a redundanci.

• Pokud požadavky na zachytávání paketů existují, použijte k zachycení paketů Network Watcher i přes omezené okno zachycení.

• Pomocí skupin zabezpečení sítě a skupin zabezpečení aplikací můžete provoz aplikací v mikrosegmentech.

  • Nepoužívejte zařízení zabezpečení k filtrování toků provozu uvnitř aplikace.
  • Zvažte použití Azure Policy k vynucení konkrétních pravidel NSG, která jsou vždy přidružená k podsítím aplikací.

• Povolte protokoly toku NSG a zasílejte je do Analýzy provozu, abyste získali přehled o interních a externích tocích provozu.

• Pokud jsou k dispozici, použijte Azure Private Link nebo privátní koncové body k zabezpečení přístupu ke službám Azure PaaS v rámci návrhu aplikace. Informace o službách Azure, které podporují Private Link, najdete v tématu dostupnost Azure Private Link.

• Pokud privátní koncový bod není dostupný a rizika exfiltrace dat jsou přijatelná, použijte koncové body služby Virtual Network k zabezpečení přístupu ke službám Azure PaaS z virtuální sítě.

  • Ve výchozím nastavení nepovolujte koncové body služeb virtuální sítě ve všech podsítích, protože tím dojde k významnému kanálu exfiltrace dat.

• V případě scénářů hybridních aplikací získejte přístup ke službám Azure PaaS z místního prostředí přes ExpressRoute s využitím privátního partnerského vztahu.

Poznámka

Při nasazování v cílové zóně Azure mějte na paměti, že síťové připojení k místním datacentrům zajišťuje implementace cílové zóny. Jedním z přístupů je použití ExpressRoute nakonfigurovaného s privátním peeringem.

Ochrana integrity dat

Šifrování je zásadním krokem k zajištění integrity dat a v konečném důsledku je jednou z nejdůležitějších bezpečnostních funkcí, které lze použít ke zmírnění široké škály hrozeb. Tato část proto obsahuje klíčové aspekty a doporučení související s šifrováním a správou klíčů, aby se zajistila ochrana dat bez ohrožení spolehlivosti aplikací.

Na co dát pozor při navrhování

• Azure Key Vault má limity transakcí pro klíče a tajné kódy, přičemž v určitém období se na trezor použije omezení.

• Azure Key Vault poskytuje hranici zabezpečení, protože přístupová oprávnění ke klíčům, tajným klíčům a certifikátům se používají na úrovni trezoru.

  • Key Vault přiřazení zásad přístupu udělují oprávnění samostatně ke klíčům, tajným klíčům nebo certifikátům.
    • Nyní jsou možná podrobná oprávnění na úrovni objektu ke konkrétnímu klíči, tajnému klíči nebo certifikátu.

• Po změně přiřazení role je k dispozici latence až 10 minut (600 sekund), aby se role použila.

  • Pro jedno předplatné platí limit 2 000 přiřazení rolí Azure.

• Azure Key Vault základní moduly hardwarového zabezpečení (HSM) mají ověření FIPS 140.

  • Pro scénáře vyžadující dodržování předpisů standardu FIPS 140-2 úrovně 3 je k dispozici vyhrazený modul HSM spravovaný službou Azure Key Vault.

• Azure Key Vault poskytuje vysokou dostupnost a redundanci, které pomáhají udržovat dostupnost a předcházet ztrátě dat.

• Během převzetí služeb při selhání oblasti může trvat několik minut, než služba Key Vault převezme služby při selhání.

  • Během převzetí služeb při selhání bude Key Vault v režimu jen pro čtení, takže nebude možné měnit vlastnosti trezoru klíčů, jako jsou konfigurace a nastavení brány firewall.

• Pokud se k připojení k Azure Key Vault používá privátní propojení, může obnovení připojení během převzetí služeb při selhání v oblasti trvat až 20 minut.

• Zálohování vytvoří snímek tajného klíče, klíče nebo certifikátu k určitému bodu v čase jako šifrovaného objektu blob, který nejde dešifrovat mimo Azure. Pokud chcete získat použitelná data z objektu blob, musí se obnovit do Key Vault v rámci stejného předplatného Azure a zeměpisné oblasti Azure.

  • Tajné kódy se můžou obnovit během zálohování, což způsobí neshodu.

• Díky klíčům spravovaným službou bude Azure provádět funkce správy klíčů, jako je obměně, čímž se zmenšuje rozsah operací aplikací.

• Regulační kontroly můžou stanovit použití klíčů spravovaných zákazníkem pro funkce šifrování služeb.

• Při přesunu provozu mezi datovými centry Azure se šifrování datového propojení MACsec používá na podkladovém síťovém hardwaru k zabezpečení přenášených dat mimo fyzické hranice, které neřídí Microsoft nebo jménem Microsoftu.

Doporučení k návrhu

• Pokud je to možné, používejte klíče spravované službou pro ochranu dat, abyste nemuseli spravovat šifrovací klíče a zpracovávat provozní úlohy, jako je obměně klíčů.

  • Klíče spravované zákazníkem používejte pouze v případech, kdy k tomu existují jasné zákonné požadavky.

• Pokud je potřeba vzít v úvahu další šifrovací mechanismy nebo klíče spravované zákazníkem, použijte Azure Key Vault jako zabezpečené úložiště pro všechny tajné kódy, certifikáty a klíče.

  • Zřiďte Azure Key Vault s povolenými zásadami obnovitelného odstranění a vymazání, které umožňují ochranu uchovávání informací pro odstraněné objekty.
  • V produkčních prostředích aplikací použijte skladovou položku Azure Key Vault s podporou HSM.

• Nasaďte samostatnou instanci Azure Key Vault v rámci každého místního razítka nasazení, čímž zajistíte izolaci chyb a výhody výkonu prostřednictvím lokalizace a přejdete na limity škálování stanovené jednou instancí Key Vault.

  • Pro globální prostředky aplikace použijte vyhrazenou instanci Azure Key Vault.

• Postupujte podle modelu nejnižších oprávnění tím, že omezíte autorizaci k trvalému odstranění tajných kódů, klíčů a certifikátů na specializované vlastní Microsoft Entra role.

• Ujistěte se, že jsou šifrovací klíče a certifikáty uložené v Key Vault zálohované, aby se offline kopie v nepravděpodobné události Key Vault stala nedostupnou.

• Pomocí Key Vault certifikátů můžete spravovat zajišťování a podepisování certifikátů.

• Vytvořte automatizovaný proces obměně klíčů a certifikátů.

  • Automatizace procesu správy a obnovení certifikátů pomocí veřejných certifikačních autorit pro usnadnění správy.
    • Nastavte upozornění a oznámení pro doplnění automatizovaných prodlužování platnosti certifikátů.

• Monitorování použití klíčů, certifikátů a tajných kódů

  • Definujte upozornění na neočekávané využití ve službě Azure Monitor.

Řízení založené na zásadách

Konvence zabezpečení jsou v konečném důsledku účinné pouze v případě, že se konzistentně a holisticky vynucují napříč všemi aplikačními službami a týmy. Azure Policy poskytuje rámec pro vynucení standardních hodnot zabezpečení a spolehlivosti a zajišťuje trvalé dodržování společných technických kritérií pro kritickou aplikaci. Konkrétně Azure Policy tvoří klíčovou součást řídicí roviny Azure Resource Manager (ARM), doplňuje řízení přístupu na základě role omezením akcí, které můžou autorizovaní uživatelé provádět, a dají se použít k vynucení důležitých konvencí zabezpečení a spolehlivosti napříč službami využívané platformy.

Tato část se proto zaměří na klíčové aspekty a doporučení týkající se používání zásad správného řízení řízeného Azure Policy pro klíčové aplikace a zajistí nepřetržité dodržování zásad zabezpečení a spolehlivosti.

Na co dát pozor při navrhování

• Azure Policy poskytuje mechanismus pro zajištění dodržování předpisů tím, že vynucuje zásady zabezpečení a spolehlivosti, jako je použití privátních koncových bodů nebo použití Zóny dostupnosti.

Poznámka

Při nasazování v rámci cílové zóny Azure mějte na paměti, že v implementaci skupin pro správu cílové zóny a předplatných se pravděpodobně použije vynucování centralizovaných přiřazení zásad standardních hodnot.

• Azure Policy lze použít k řízení automatizovaných aktivit správy, jako je zřizování a konfigurace.

  • Registrace poskytovatele prostředků.
  • Ověřování a schvalování jednotlivých konfigurací prostředků Azure

• Azure Policy rozsah přiřazení určuje pokrytí a umístění definic Azure Policy informuje o opakovaném použití vlastních zásad.

• Azure Policy má několik omezení, například počet definic v libovolném konkrétním oboru.

• Spuštění zásad DINE (Deploy If Not Exist) může trvat několik minut.

• Azure Policy poskytuje důležitý vstup pro vytváření sestav dodržování předpisů a auditování zabezpečení.

Doporučení k návrhu

• Namapovat zákonné požadavky a požadavky na dodržování předpisů na definice Azure Policy.

  • Pokud například existují požadavky na rezidenci dat, měly by se použít zásady k omezení dostupných oblastí nasazení.

• Definujte společná technická kritéria pro zachycení bezpečných a spolehlivých definic konfigurace pro všechny využívané služby Azure a ujistěte se, že tato kritéria jsou namapovaná na Azure Policy přiřazení k vynucování dodržování předpisů.

  • Můžete například použít Azure Policy k vynucení použití Zóny dostupnosti pro všechny relevantní služby a zajistit tak spolehlivé konfigurace nasazení v rámci oblasti.

Referenční implementace pro klíčové úkoly obsahuje širokou škálu zásad zabezpečení a spolehlivosti, které definují a vynucuje ukázková běžná technická kritéria.

• Monitorujte odchylku konfigurace služby vzhledem k běžným technickým kritériím pomocí Azure Policy.

V klíčových scénářích s několika produkčními předplatnými v rámci vyhrazené skupiny pro správu určete prioritu přiřazení v oboru skupiny pro správu.

• Pokud je to možné, používejte integrované zásady, abyste minimalizovali provozní režii spojenou s údržbou vlastních definic zásad.

• Pokud se vyžadují vlastní definice zásad, ujistěte se, že jsou definice nasazené ve vhodném rozsahu skupiny pro správu, aby bylo možné je opakovaně používat napříč předplatnými obsažených prostředí, což umožňuje opakované použití zásad v produkčním a nižším prostředí.

  • Při sladění plánu aplikace s plány Azure využijte dostupné prostředky Microsoftu k prozkoumání, jestli je možné důležité vlastní definice začlenit jako předdefinované definice.

Poznámka

Při nasazování v rámci cílové zóny Azure zvažte nasazení vlastních definic Azure Policy v rámci zprostředkujícího oboru kořenové skupiny pro správu společnosti, aby bylo možné opakovaně používat všechny aplikace v rámci širšího majetku Azure. V prostředí cílové zóny se určité centralizované zásady zabezpečení použijí ve výchozím nastavení v rámci vyšších oborů skupin pro správu, aby se vynutily dodržování předpisů zabezpečení v rámci celého majetku Azure. Zásady Azure by se například měly použít k automatickému nasazení softwarových konfigurací prostřednictvím rozšíření virtuálních počítačů a vynucování odpovídající standardní konfigurace virtuálních počítačů.

• Použijte Azure Policy k vynucování konzistentního schématu označování v celé aplikaci.
  • Identifikujte požadované značky Azure a použijte režim zásad připojení k vynucení využití.

Pokud je aplikace přihlášená k odběru podpory Microsoft Mission-Critical, ujistěte se, že použité schéma označování poskytuje smysluplný kontext, který rozšiřuje prostředí podpory o hluboké porozumění aplikacím.

• Exportujte protokoly aktivit Microsoft Entra do globálního pracovního prostoru služby Log Analytics, který aplikace používá.
  • Zajistěte, aby se protokoly aktivit Azure archivovaly v rámci globálního účtu úložiště spolu s provozními daty pro dlouhodobé uchovávání.

V cílové zóně Azure se protokoly aktivit Microsoft Entra také ingestují do pracovního prostoru log analytics centralizované platformy. V tomto případě je potřeba vyhodnotit, jestli se v globálním pracovním prostoru služby Log Analytics stále vyžadují Microsoft Entra ID.

• Integrace správy informací o zabezpečení a událostí se službou Microsoft Defender for Cloud (dříve označovanou jako Azure Security Center).

Aspekty specifické pro IaaS při používání Virtual Machines

Ve scénářích, kde se vyžaduje použití Virtual Machines IaaS, je potřeba vzít v úvahu určitá specifika.

Na co dát pozor při navrhování

• Image se po nasazení automaticky neaktualizují.
• Aktualizace se automaticky nenainstalují do spuštěných virtuálních počítačů.
• Image a jednotlivé virtuální počítače obvykle nejsou posílené.

Doporučení k návrhu

• Nepovolujte přímý přístup přes veřejný internet k Virtual Machines poskytnutím přístupu k protokolům SSH, RDP nebo jiným protokolům. Vždy používejte Azure Bastion a jumpboxy s omezeným přístupem pro malou skupinu uživatelů.
• Omezte přímé připojení k internetu pomocí skupin zabezpečení sítě, brány Firewall (Azure) nebo služby Application Gateway (úroveň 7) k filtrování a omezení výchozího provozu.
• U vícevrstvých aplikací zvažte použití různých podsítí a k omezení přístupu mezi jednotlivými aplikacemi použijte skupiny zabezpečení sítě.
• Pokud je to možné, určete prioritu použití ověřování pomocí veřejného klíče. Ukládejte tajné kódy na bezpečném místě, jako je Azure Key Vault.
• Chraňte virtuální počítače pomocí ověřování a řízení přístupu.
• Použijte stejné postupy zabezpečení, které jsou popsané pro klíčové scénáře aplikací.

Dodržujte a použijte postupy zabezpečení pro klíčové scénáře aplikací, jak je popsáno výše, pokud je to možné, a také osvědčené postupy zabezpečení pro úlohy IaaS v Azure.

Další krok

Projděte si osvědčené postupy pro provozní postupy pro klíčové scénáře aplikací.

Provozní postupy