Důležité informace o 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, která musí být považována 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, aby aplikace zůstala výkonná a dostupná, bezpečnostní aspekty a doporučení použitá v této oblasti návrhu se zaměří na zmírnění hrozeb s kapacitou, aby ovlivnila dostupnost a zabránila celkové spolehlivosti. Například úspěšné útoky DDoS (Denial-Of-Service) mají závažný dopad na dostupnost a výkon. Způsob, jakým aplikace tyto vektory útoku zmírní, například SlowLoris, ovlivní celkovou spolehlivost. Proto musí být aplikace plně chráněná před hrozbami určenými k přímému nebo nepřímou ohrožení spolehlivosti aplikací, aby byla skutečně kritická v podstatě.

Je také důležité si uvědomit, že často existují významné kompromisy spojené s posíleným stavem zabezpečení, 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í 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 v případě, že operace škálovatelnosti a obnovení nejsou úzce v souladu s aplikací. Proto je nezbytné, aby byly další součásti zabezpečení a postupy, které mají zmírnit klíčové vektory hrozeb, navrženy tak, aby podporovaly cíl spolehlivosti aplikace, který 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 úloh, která je důležitá pro architekturu Azure. Pokud tuto řadu neznáte, doporučujeme začít tím , co je kritická úloha?

Opensourcový projekt kritické pro klíčové úkoly

Referenční implementace jsou součástí opensourcového projektu dostupného na GitHubu. Prostředky kódu přijímají 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 použití 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čilou detekci k reakci na hrozby téměř v reálném čase. Nakonec je zaměřen na odstranění důvěry uvnitř a mimo hraniční sítě aplikace a vynucuje ověření pro cokoli, co se pokouší připojit k systému.

Aspekty návrhu

Při posuzování stavu zabezpečení aplikace začněte těmito otázkami jako základem pro jednotlivé aspekty.

• Průběžné testování zabezpečení za účelem ověření omezení rizik pro klíčová 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ápravy zabezpečení

  • Dají se zjistit změny nastavení zabezpečení klíčů?
  • Jsou odpovědi na nápravu nekompatibilní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í pro služby 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í (CVE) v rámci využitých závislostí balíčků?
  • Existuje automatizovaný proces aktualizace závislostí balíčků?

• Životní cyklus klíče ochrany dat

  • Dají se klíče spravované službou používat 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 instanční objekty Microsoft Entra s dostatečným přístupem na úrovni předplatného, aby se usnadnil přístup roviny řízení pro nasazení prostředků Azure do všech považovaných předplatných prostředí.

  • Pokud jsou prostředky aplikace v privátních sítích uzamčené, existuje cesta připojení roviny privátních dat, aby nástroje CI/CD mohly provádět nasazení a údržbu na úrovni aplikace.
    • To představuje 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í služby Azure Policy vynucujte konfigurace zabezpečení a spolehlivosti pro všechny služby a zajistěte, aby všechny odchylky byly buď odstraněny, nebo zakázány řídicí rovinou v době konfigurace, což pomáhá zmírnit hrozby spojené se scénáři "škodlivého správce".

• K odvolání trvalého přístupu k produkčním prostředím použijte Microsoft Entra Privileged Identity Management (PIM) v rámci produkčních předplatných. Tím se výrazně sníží riziko vyplývající ze scénářů "škodlivých správců" prostřednictvím dalších kontrolních kontrol a zůstatků.

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

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

• K integraci s ID Microsoft Entra použijte knihovny ověřování Microsoft Identity Platform v kódu aplikace.

• Zvažte použití zabezpečeného ukládání tokenů do mezipaměti, abyste umožnili snížený výkon, ale dostupné prostředí, pokud vybraná platforma identit není dostupná nebo je k dispozici pouze částečně pro autorizaci aplikací.

  • Pokud poskytovatel nemůže vydávat nové přístupové tokeny, ale stále ověřuje stávající tokeny, může aplikace a závislé služby fungovat bez problémů, dokud jejich tokeny nevyprší platnost.
  • Ukládání tokenů do mezipaměti se obvykle zpracovává automaticky 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, včetně za okolností selhání.

  • Ujistěte se, že připojení služeb nástrojů CI/CD jsou chráněná jako kritické citlivé informace a neměla by být přímo dostupná žádnému týmu služeb.
  • Použití podrobného řízení přístupu na základě role na produkční kanály CD za účelem zmírnění rizik "škodlivých správců".
  • Zvažte použití ručních schvalovacích bran v rámci kanálů produkčního nasazení k dalšímu zmírnění rizik "škodlivých správců" a zajištění dodatečné technické záruky pro všechny produkční změny.
    • Další bezpečnostní brány mohou přijít na kompromis z hlediska flexibility a měly by být pečlivě vyhodnoceny, s ohledem na to, jak lze agilitu udržovat i s ručními branami.

• Definujte odpovídající 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 zákonné požadavky nevymezí nutnost, protože tím výrazně dojde k ohrožení flexibility vývojářů.

• Povolte Microsoft Defender for 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í.

• Přijměte DevSecOps a implementujte testování zabezpečení v rámci kanálů CI/CD.

  • Výsledky testů by se měly měřit v souladu s stavem zabezpečení, aby bylo možné informovat schválení vydaných verzí, ať už jsou automatizované nebo ruční.
  • Testování zabezpečení použijte jako součást produkčního procesu CD pro každou verzi.
    • Pokud testování zabezpečení každé verze ohrožuje provozní flexibilitu, zajistěte, aby se použilo vhodné tempo 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 návrhu zabezpečení s využitím identifikovaných potenciálních hrozeb k vývoji vhodných omezení zabezpečení. Existuje mnoho možných hrozeb s různou pravděpodobností výskytu a v mnoha případech se hrozby můžou řetězit neočekávanými, nepředvídatelnými a dokonce chaotickými způsoby. Tato složitost a nejistota je důvodem, proč jsou přístupy zabezpečení založené na tradičních technologických požadavcích do značné míry nevhodné pro klíčové cloudové aplikace. Očekáváme, že proces modelování hrozeb pro kritickou aplikaci bude složitý a neudělený.

Aby bylo možné tyto výzvy procházet, je třeba použít vícevrstvý přístup hloubkové ochrany k definování a implementaci kompenzačních omezení pro modelované hrozby s ohledem na následující obranné vrstvy.

1. Platforma Azure se základními možnostmi zabezpečení a ovládacími prvky.
2. Návrh architektury aplikací a zabezpečení.
3. Funkce zabezpečení integrované, povolené a nasaditelné pro zabezpečení prostředků Azure
4. Aplikační kód a logika zabezpečení
5. Provozní procesy a DevSecOps

Poznámka:

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

Aspekty návrhu

STRIDE poskytuje jednoduchý rámec rizika pro vyhodnocení bezpečnostních hrozeb napříč klíčovými vektory hrozeb.

• Identita zosobnění: zosobnění jednotlivců s autoritou Útočník například zosobní jiného uživatele pomocí svého
  • Identita
  • Ověřování
• Manipulace se vstupem: Úprava vstupu odeslaného do aplikace nebo porušení hranic důvěryhodnosti pro úpravu kódu aplikace. Útočník například pomocí injektáže SQL odstraní data v tabulce databáze.
  • Integrita dat
  • Ověřování
  • Zablokování nebo povolení
• Odmítnutí akce: Schopnost odvolat již provedené akce a schopnost aplikace shromáždit důkazy a řídit odpovědnost. Například odstranění důležitých dat bez možnosti trasování pro správce se zlými úmysly.
  • 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: Přerušení škodlivé aplikace, které snižuje uživatelské prostředí. Například útok DDoS botnet, například Slowloris.
  • DDoS
  • Botnety
  • Možnosti CDN a WAF
• Zvýšení oprávnění: Získání privilegovaného přístupu k aplikaci prostřednictvím zneužití autorizace Útočník například manipuluje s řetězcem adresy URL, aby získal přístup k citlivým informacím.
  • Vzdálené spuštění kódu
  • Autorizace
  • Izolace

Doporučení k návrhu

• Přidě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 použít vědomé úsilí, aby se zajistilo, že se zmírnění rizik zabezpečení zachytí 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 se službou podle modelování hrozeb na úrovni služby a sjednocte model sloučením modelu vlákna na úrovni aplikace.

Ochrana před neoprávněným vniknutím sítě

Zabránění neoprávněnému přístupu k klíčové aplikaci a zahrnutí dat je nezbytné pro zachování dostupnosti a zabezpečení integrity dat.

Aspekty návrhu

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

  • Pokročilá implementace sítě s nulovou důvěryhodností využívá mikros segmentaci a distribuované mikro-hraniční sítě pro příchozí a odchozí přenos 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 jejich úplné privátní nastavení.

  • Privátní koncové body Azure Private Linku a privátních koncových bodů poskytují vyhrazený přístup k prostředku Azure PaaS pomocí privátních IP adres a připojení k privátní síti.
  • Koncové body služby virtuální sítě poskytují přístup na úrovni služeb z vybraných podsítí k vybraným službám PaaS.
  • Injektáž virtuální sítě poskytuje vyhrazená privátní nasazení pro podporované služby, jako je App Service prostřednictvím služby App Service Environment.
    • Provoz roviny správy stále prochází přes veřejné IP adresy.

• U podporovaných služeb řeší Azure Private Link s využitím privátních koncových bodů Azure rizika exfiltrace dat spojená s koncovými body služby, jako je š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žby bude pro kanály nasazení potřeba 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 agentům privátního 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 odebrala.
    • 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.

• Připojení služeb s odpovídajícím instančním objektem Microsoft Entra je možné použít v rámci Azure DevOps k použití 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 nepřesahují do více virtuálních sítí.

• Zachytávání paketů ve službě 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 vyžadované k tomu, aby aplikace splňovala svůj obchodní účel, aby se snížil prostor pro vnější útoky.

  • Pomocí služby Azure Private Link můžete vytvořit privátní koncové body pro prostředky Azure, které vyžadují zabezpečenou integraci sítě.
  • K nasazení a konfiguraci prostředků Azure chráněných službou Azure Private Link použijte agenty hostovaného privátního sestavení pro nástroje CI/CD.
    • Agenti hostovaní Microsoftem se nebudou moct přímo připojit k síťovým integrovaným prostředkům.

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

  • Azure Bastion slouží k zajištění zabezpečeného přístupu k virtuálním počítačům Azure a k provádění úloh správy v Azure PaaS přes internet.

• Pomocí plánu ochrany před útoky DDoS standard můžete zabezpečit všechny veřejné IP adresy v rámci aplikace.

• Pomocí služby Azure Front Door se zásadami firewallu webových aplikací můžete poskytovat globální aplikace HTTP/S, které pokrývají více oblastí Azure, a chránit je.

  • Ověření ID hlavičky slouží k uzamčení koncových bodů veřejné aplikace, 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í síťového virtuálního zařízení (NVA) služby Azure Firewall Premium nebo síťového virtuálního zařízení, ujistěte se, že je nakonfigurovaná pro maximální vysokou dostupnost a redundanci.

• Pokud existují požadavky na zachytávání paketů, pomocí paketů Network Watcheru zachyťte navzdory omezenému intervalu zachycení.

• Pomocí skupin zabezpečení sítě a skupin zabezpečení aplikací můžete provádět mikrosou segmenty provozu aplikací.

  • Vyhněte se použití zabezpečovacího zařízení k filtrování toků provozu uvnitř aplikací.
  • Zvažte použití služby 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 dejte je do Analýzy provozu, abyste získali přehled o interních a externích tocích provozu.

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

• Pokud privátní koncový bod není dostupný a rizika exfiltrace dat jsou přijatelná, pomocí koncových bodů služby virtuální sítě zabezpečte přístup ke službám Azure PaaS z virtuální sítě.

  • Nepovolujte ve výchozím nastavení koncové body služby virtuální sítě ve všech podsítích, protože to bude představovat významné kanály exfiltrace dat.

• V případě scénářů hybridních aplikací přistupovat ke službám Azure PaaS z místního prostředí prostřednictvím ExpressRoute s privátním partnerským vztahem.

Poznámka:

Při nasazování v cílové zóně Azure mějte na paměti, že implementace cílové zóny poskytuje síťové připojení k místním datovým centrům. Jedním zpřístupch

Ochrana integrity dat

Šifrování je zásadní krok k zajištění integrity dat a je nakonec jednou z nejdůležitějších funkcí zabezpečení, které je možné použít ke zmírnění široké škály hrozeb. Tato část proto poskytne klíčové aspekty a doporučení související se šifrováním a správou klíčů, aby se zajistila ochrana dat bez ohrožení spolehlivosti aplikací.

Aspekty návrhu

• Azure Key Vault má limity transakcí pro klíče a tajné kódy s omezením použitým pro jednotlivé trezory v určitém období.

• 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žijí na úrovni trezoru.

  • Přiřazení zásad přístupu ke službě Key Vault udělují oprávnění samostatně klíčům, tajným klíčům nebo certifikátům.
    • Podrobná oprávnění na úrovni objektu pro konkrétní klíč, tajný klíč nebo certifikát jsou teď možná.

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

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

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

  • Vyhrazený spravovaný HSM služby Azure Key Vault je k dispozici pro scénáře vyžadující dodržování předpisů FIPS 140–2 úrovně 3.

• Azure Key Vault poskytuje vysokou dostupnost a redundanci, která pomáhá udržovat dostupnost a zabránit 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 brány firewall a nastavení.

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

• Záloha 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íte je obnovit do služby Key Vault ve stejném předplatném Azure a v zeměpisné oblasti Azure.

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

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

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

• Při přesunu provozu mezi datovými centry Azure se šifrování vrstvy maCsec používá na základní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 k ochraně 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 jenom v případech, kdy je k tomu jasný zákonný požadavek.

• Azure Key Vault použijte jako zabezpečené úložiště pro všechny tajné klíče, certifikáty a klíče, pokud je potřeba zvážit další mechanismy šifrování nebo klíče spravované zákazníkem.

  • Zřízení služby Azure Key Vault pomocí zásad obnovitelného odstranění a vymazání, které umožňují ochranu uchovávání informací pro odstraněné objekty.
  • Pro produkční prostředí aplikací používejte skladovou položku azure Key Vault s podporou HSM.

• Nasaďte samostatnou instanci služby Azure Key Vault v rámci každého razítka místního nasazení, která zajišťuje izolaci chyb a výhody výkonu prostřednictvím lokalizace a také procházení limitů škálování, které je vynuceno jednou instancí služby Key Vault.

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

• Pokud chcete omezit autorizaci na trvalé odstranění tajných kódů, klíčů a certifikátů na specializované vlastní role Microsoft Entra, postupujte podle modelu s nejnižšími oprávněními.

• Ujistěte se, že se šifrovací klíče a certifikáty uložené ve službě Key Vault zálohují a poskytují offline kopii v nepravděpodobném případě, že služba Key Vault nebude dostupná.

• Ke správě zajišťování a podepisování certifikátů použijte certifikáty služby Key Vault.

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

  • Automatizujte proces správy certifikátů a obnovování s veřejnými certifikačními autoritami, abyste usnadnili správu.
    • Nastavte upozorňování a oznámení a doplňte automatické prodlužování platnosti certifikátů.

• Monitorujte použití klíče, certifikátu a tajného kódu.

  • Definujte výstrahy pro neočekávané využití ve službě Azure Monitor.

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

Konvence zabezpečení jsou nakonec efektivní pouze v případě, že se konzistentně a holisticky vynucují napříč všemi aplikačními službami a týmy. Azure Policy poskytuje architekturu pro vynucování standardních hodnot zabezpečení a spolehlivosti a zajišťuje trvalé dodržování společných technických kritérií pro nepostradatelnou aplikaci. Konkrétně Azure Policy tvoří klíčovou součást řídicí roviny Azure Resource Manageru (ARM), doplňuje RBAC 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říč využívanými službami platformy.

Tato část proto prozkoumá klíčové aspekty a doporučení týkající se používání zásad správného řízení řízeného službou Azure Policy pro nepostradatelnou aplikaci a zajistí průběžné vynucování zásad zabezpečení a spolehlivosti.

Aspekty návrhu

• Azure Policy poskytuje mechanismus pro zajištění dodržování předpisů vynucováním zásad 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 cílové zóně Azure mějte na paměti, že vynucení centralizovaných přiřazení zásad standardních hodnot se pravděpodobně použije v implementaci pro skupiny pro správu cílové zóny a předplatná.

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

  • Registrace poskytovatele prostředků.
  • Ověření a schválení jednotlivých konfigurací prostředků Azure

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

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

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

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

Doporučení k návrhu

• Namapování zákonných požadavků a požadavků na dodržování předpisů na definice azure Policy

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

• Definujte společná technická kritéria pro zachycení zabezpečených a spolehlivých definic konfigurace pro všechny využívané služby Azure a zajistěte, aby tato kritéria byla namapována na přiřazení azure Policy k vynucení dodržování předpisů.

  • Použijte například Azure Policy k vynucení použití Zóny dostupnosti pro všechny relevantní služby a zajištění spolehlivých konfigurací nasazení v rámci oblasti.

Referenční implementace Mission Critical obsahuje širokou škálu zásad orientovaných na zabezpečení a spolehlivost, které definují a vynucuje ukázková společná technická kritéria.

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

V případě kritických scénářů s několika produkčními předplatnými ve vyhrazené skupině pro správu upřednostníte přiřazení v oboru skupiny pro správu.

• Pokud je to možné, použijte předdefinované zásady, abyste minimalizovali provozní režii při údržbě vlastních definic zásad.

• Pokud jsou požadovány vlastní definice zásad, zajistěte, aby se definice nasazovaly v vhodném rozsahu skupiny pro správu, aby bylo možné je opakovaně používat napříč zahrnutími předplatnými prostředí, což umožňuje opakované použití zásad v produkčních a nižších prostředích.

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

Poznámka:

Při nasazování v cílové zóně Azure zvažte nasazení vlastních definic Azure Policy v rámci oboru zprostředkující 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 ve výchozím nastavení použijí určité centralizované zásady zabezpečení v rámci vyšších oborů skupin pro správu k vynucení dodržování předpisů zabezpečení v rámci celého majetku Azure. Například zásady Azure by se měly použít k automatickému nasazování konfigurací softwaru prostřednictvím rozšíření virtuálních počítačů a vynucování konfigurace standardních virtuálních počítačů vyhovujících předpisům.

• Pomocí Služby Azure Policy vynucujte konzistentní schéma označování v celé aplikaci.
  • Identifikujte požadované značky Azure a pomocí režimu zásad připojení vynucujte použití.

Pokud se aplikace přihlásí k odběru podpory Microsoft Mission-Critical Support, ujistěte se, že použité schéma označování poskytuje smysluplný kontext pro obohacení 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 centralizované platformy Log Analytics. V tomto případě je potřeba ho vyhodnotit, pokud se ID Microsoft Entra stále vyžaduje v globálním pracovním prostoru služby Log Analytics.

• Integrujte informace o zabezpečení a správu událostí s programem Microsoft Defender for Cloud (dříve Označovaný jako Azure Security Center).

Specifické aspekty IaaS při používání virtuálních počítačů

V situacích, kdy je vyžadováno použití virtuálních počítačů IaaS, je potřeba vzít v úvahu některé konkrétní skutečnosti.

Aspekty návrhu

• 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 se obvykle nevytvrdí.

Doporučení k návrhu

• Nepovolujte přímý přístup přes veřejný internet k virtuálním počítačům tím, že poskytujete přístup k SSH, RDP nebo jiným protokolům. Vždy používejte Azure Bastion a jumpboxes s omezeným přístupem k malé skupině uživatelů.
• Omezte přímé připojení k internetu pomocí skupin zabezpečení sítě (Azure) Firewall nebo application Gateway (úroveň 7) k filtrování a omezení odchozího provozu.
• U vícevrstvých aplikací zvažte použití různých podsítí a použití skupin zabezpečení sítě k omezení přístupu mezi různými podsítěmi.
• 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í, jak je popsáno v klíčových scénářích aplikací.

Pokud je to možné, dodržujte a použijte postupy zabezpečení pro klíčové scénáře aplikací, jak je popsáno výše, 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