Architektura regulovaného clusteru AKS pro PCI-DSS 3.2.1 (část 2 z 9)

Tento článek popisuje referenční architekturu pro cluster Azure Kubernetes Service (AKS), který spouští úlohu v souladu se standardem PCI-DSS 3.2.1 ( Payment Card Industry Data Security Standard). Tato architektura se zaměřuje na infrastrukturu a ne na úlohu PCI-DSS 3.2.1.

Tento článek je součástí série článků. Přečtěte si úvod.

Doporučení a příklady se extrahují z této doprovodné referenční implementace:

GitHub: Standardní cluster Azure Kubernetes Service (AKS) pro regulované úlohy ukazuje regulovanou infrastrukturu. Tato implementace poskytuje aplikaci mikroslužeb. Součástí je pomoct vám s infrastrukturou a ilustrovat ovládací prvky sítě a zabezpečení. Aplikace nepředstavuje ani neimplementuje skutečnou úlohu PCI DSS.

Stáhněte si soubor aplikace Visio s touto architekturou.

Tato síťová architektura je založená na hvězdicové topologii. Virtuální síť centra obsahuje bránu firewall pro řízení odchozího provozu, provozu brány z místních sítí a třetí sítě pro přístup ke clusteru SRE (site reliability engineer). Existují dvě paprskové virtuální sítě. Jeden paprsk obsahuje cluster AKS, který je součástí prostředí CDE (Card Holder Environment) a hostuje úlohu PCI DSS. Druhý paprskový model sestavuje image virtuálních počítačů používané pro řízený přístup SRE k prostředí.

Komponenty

Tady jsou hlavní komponenty používané v této architektuře. Pokud tyto služby neznáte, podívejte se na související služby Azure, kde najdete odkazy na dokumentaci k produktu.

Azure Firewall

Instance brány firewall zabezpečuje odchozí síťový provoz. Bez této vrstvy zabezpečení může tok komunikovat se zlými službami třetích stran, které by mohly exfiltrovat citlivá firemní data.

Azure Bastion

Základní architektura poskytla podsíť pro Azure Bastion, ale nezřídila prostředek. Tato architektura přidává Azure Bastion do podsítě a poskytuje zabezpečený přístup k jump boxu.

Azure Image Builder

Zřízené v samostatné virtuální síti vytvoří image virtuálních počítačů se základním zabezpečením a konfigurací. V této architektuře je přizpůsobená k vytváření zabezpečených imagí uzlů pomocí nástrojů pro správu, kubectljako jsou Azure CLI a rozhraní příkazového řádku Flux, které jsou předinstalované.

Škálovací sady virtuálních počítačů Azure pro instance jump boxu

Paprsková síť má další výpočetní prostředky pro jump box. Tato škálovací sada je určená jako řídicí přístupový bod pro spouštění nástrojů v clusteru AKS, například kubectlpodle potřeby.

Aplikace Azure lication Gateway s integrovaným firewallem webových aplikací (WAF)

Aplikace Azure vyrovnávání zatížení brány ve vrstvě 7. WAF zabezpečuje příchozí provoz před běžnými webovými útoky. Instance má konfiguraci veřejné front-endové IP adresy, která přijímá požadavky uživatelů.

Azure Kubernetes Service (AKS)

Hostitelská infrastruktura, která je klíčovou součástí datového prostředí držitelů karet (CDE). Cluster AKS se nasadí jako privátní cluster. Server rozhraní API Kubernetes proto není vystavený veřejnému internetu a provoz na server rozhraní API je omezený na vaši privátní síť.

Úlohy ACR

Poskytuje automatizovaný způsob vytváření a údržby imagí kontejnerů.

Azure Key Vault

Ukládá a spravuje tajné kódy potřebné pro operace clusteru, jako jsou certifikáty a šifrovací klíče.

Konfigurace clusteru

Tady jsou některé významné změny základní architektury:

Segmentace fondu uzlů

V této architektuře má cluster dva fondy uzlů uživatele a jeden fond systémových uzlů. Volba výpočetních prostředků pro fondy uzlů zůstává stejná jako v základní architektuře. Na rozdíl od základní architektury se každý fond uzlů nachází ve vyhrazené podsíti a poskytuje přidanou hranici izolace sítě mezi úrovněmi výpočetních prostředků.

PCI-DSS 3.2.1 vyžaduje izolaci úlohy PCI od jiných úloh z hlediska provozu a připojení.

• V oboru: Úloha PCI, prostředí, ve kterém se nachází, a operace.

• Mimo rozsah: Jiné úlohy, které můžou sdílet služby, ale jsou izolované od komponent v oboru.

Klíčovou strategií je poskytnout požadovanou úroveň oddělení. Upřednostňovaným způsobem je nasazení komponent v oboru a mimo rozsah v samostatných clusterech. Nevýhodou používání více clusterů je vyšší náklady na přidanou infrastrukturu a režijní náklady na údržbu. Tato implementace společně vyhledá všechny komponenty ve sdíleném clusteru kvůli jednoduchosti. Pokud se rozhodnete postupovat podle modelu s jedním clusterem, použijte důkladnou strategii segmentace v clusteru. Bez ohledu na to, jak se rozhodnete zachovat oddělení, mějte na paměti, že jak se vaše řešení vyvíjí, můžou se některé komponenty mimo rozsah stát v oboru.

V referenční implementaci předvedeme sdílený přístup ke clusteru nasazením aplikace mikroslužeb do jednoho clusteru. Úlohy v oboru a mimo rozsah jsou segmentovány ve dvou samostatných fondech uzlů uživatele. Aplikace má dvě sady služeb; jedna sada má pody v oboru a druhá je mimo rozsah. Obě sady jsou rozdělené mezi dva fondy uzlů uživatele. Pomocí taintů Kubernetes se pody v oboru a mimo rozsah nasazují do samostatných uzlů a nikdy nesdílejí virtuální počítač uzlu ani síťový prostor IP adres.

Kontroler příchozího přenosu dat

Základní architektura používala Traefik pro řízení příchozího přenosu dat. V této referenční architektuře místo toho používáme Nginx. Tato změna ukazuje, že tuto komponentu je možné změnit na základě požadavků vašich úloh.

Server privátního rozhraní Kubernetes API

Základní architektura nasadila cluster AKS ve veřejném režimu. To znamená, že veškerá komunikace se serverem rozhraní Kubernetes API spravovaným službou AKS je přes veřejný internet. To není v této architektuře přijatelné, protože PCI-DSS 3.2.1 zakazuje veřejné vystavení všem systémovým komponentám. V této regulované architektuře se cluster nasadí jako privátní cluster. Síťový provoz na server rozhraní API Kubernetes je omezený na vaši privátní síť. Server rozhraní API je vystaven prostřednictvím privátního koncového bodu v síti clusteru. Zabezpečení je dále rozšířeno o použití skupin zabezpečení sítě a dalších integrovaných funkcí. Jsou popsány v konfiguraci sítě.

Zabezpečení podů

Při popisu potřeb zabezpečení vašich úloh použijte relevantní securityContext nastavení pro kontejnery. To zahrnuje základní nastavení, jako fsGroupje ,runAsGrouprunAsUser / a nastavení allowPrivilegeEscalation na false (pokud není povinné). Buďte si jisti definováním a odebráním možností Linuxu a definováním možností SELinux v seLinuxOptionssouboru .

Vyhněte se odkazování na image podle jejich značek v manifestech nasazení. Místo toho použijte skutečné ID image. Díky tomu můžete spolehlivě mapovat výsledky prohledávání kontejnerů se skutečným obsahem spuštěným v clusteru. Můžete ho vynutit prostřednictvím služby Azure Policy, aby název image zahrnoval vzor ID image do povoleného regulárního výrazu. Pokud používáte pokyny k souboru Dockerfile FROM , postupujte také podle těchto pokynů.

Konfigurace sítě

Hvězdicové paprsky jsou všechny nasazené v samostatných virtuálních sítích, a to každý v jejich privátním adresním prostoru. Ve výchozím nastavení mezi dvěma virtuálními sítěmi není povolený žádný provoz. V rámci sítě se segmentace použije vytvořením podsítí.

Kombinace různých služeb a funkcí Azure a nativních konstruktorů Kubernetes poskytuje požadovanou úroveň řízení. Tady jsou některé možnosti, které se v této architektuře používají.

Zabezpečení podsítě prostřednictvím skupin zabezpečení sítě (NSG)

Existuje několik skupin zabezpečení sítě, které řídí tok v clusteru i mimo cluster. Několik příkladů:

• Fondy uzlů clusteru jsou umístěné ve vyhrazených podsítích. Pro každou podsíť existují skupiny zabezpečení sítě, které blokují veškerý přístup SSH k virtuálním počítačům uzlů a povolují provoz z virtuální sítě. Provoz z fondů uzlů je omezený na virtuální síť.

• Veškerý příchozí provoz z internetu je zachycen službou Aplikace Azure lication Gateway. Pravidla skupiny zabezpečení sítě například zajišťují, že:

  • Povolený je jenom provoz HTTPS.
  • Provoz z řídicí roviny Azure je povolený pomocí značek služeb. Další informace najdete v tématu Povolení přístupu k několika zdrojovým IP adresám.

• V podsítích s agenty služby Azure Container Registry umožňují skupiny zabezpečení sítě pouze nezbytný odchozí provoz. Provoz je například povolený pro Azure Key Vault, Microsoft Entra ID, Azure Monitor a další služby, se kterými musí registr kontejneru komunikovat.

• Podsíť s jump boxem je určená pro operace správy. Pravidlo NSG v podsíti jump boxu povoluje přístup SSH jenom z Azure Bastionu v centru a omezená odchozí připojení. Jump boxy nemají univerzální přístup k internetu a řídí se v podsíti NSG i ve službě Azure Firewall.

Při nasazení úloh, agentů zabezpečení systému a dalších komponent přidejte další pravidla NSG, která pomáhají definovat typ povoleného provozu. Provoz by neměl procházet těmito hranicemi podsítě. Vzhledem k tomu, že každý fond uzlů žije ve své vlastní podsíti, sledujte vzory provozu a pak použijte konkrétnější pravidla.

Zabezpečení pod-to-pod pomocí zásad sítě

Tato architektura se snaží co nejvíce implementovat principy nulové důvěryhodnosti Microsoftu.

Příklady sítí nulové důvěry jako konceptu jsou demonstrované v implementaci v rámci a0005-i a0005-o oborů názvů poskytovaných uživatelem. Každý obor názvů úloh by měl mít použitou omezující zásadu NetworkPolicy. Definice zásad budou záviset na podech spuštěných v těchto oborech názvů. Ujistěte se, že používáte monitorování připravenosti, aktuálnosti a spouštění sond a povolte metriky shromážděné agentem Log Analytics. Zvažte standardizaci portů napříč vašimi úlohami, abyste mohli poskytovat konzistentní zásady sítě a Azure Policy pro povolené porty kontejnerů.

V některých případech to není praktické pro komunikaci v rámci clusteru. Ne všechny obory názvů poskytované uživatelem můžou používat síť nulové důvěryhodnosti (například cluster-baseline-settings nemůže použít jeden).

Šifrování TLS

Základní architektura poskytuje provoz šifrovaný protokolem TLS, dokud kontroler příchozího přenosu dat v clusteru není jasný, ale komunikace typu pod-to-pod je jasná. V této architektuře se tls rozšiřuje na provoz podů na pody s ověřováním certifikační autority (CA). Tento protokol TLS poskytuje síť služeb, která před povolením komunikace vynucuje připojení mTLS a ověřování.

Implementace používá mTLS. Podporu mTLS je možné implementovat se sítí služeb nebo bez této sítě. Pokud používáte síť, ujistěte se, že je kompatibilní s vámi zvoleným vystavitelem certifikátu. Tato implementace používá Open Service Mesh.

Kontroler příchozího přenosu dat v této implementaci používá k zpracování výchozího provozu certifikát se zástupným znakem, pokud prostředek příchozího přenosu dat neobsahuje konkrétní certifikát. To může být přijatelné, ale pokud vaše zásady organizace nepovolují používání certifikátů se zástupnými cardy, možná budete muset upravit kontroler příchozího přenosu dat tak, aby nepoužíl zástupný certifikát.

Omezení sítě ve službě Azure Key Vault

Všechny tajné kódy, klíče a certifikáty jsou uložené ve službě Azure Key Vault. Key Vault zpracovává úlohy správy certifikátů, jako je rotace. Komunikace se službou Key Vault je přes Azure Private Link. Záznam DNS přidružený ke službě Key Vault je v privátní zóně DNS, aby ho nebylo možné přeložit z internetu. I když to zvyšuje zabezpečení, existují určitá omezení.

Aplikace Azure lication Gateway nepodporuje získání certifikátů TLS pro naslouchací proces HTTP z instancí služby Key Vault, které jsou vystavené službou Private Link. Implementace tedy nasadí službu Key Vault v hybridním modelu. Stále používá službu Private Link pro připojení, která ho podporují, ale také umožňuje veřejný přístup pro integraci služby Application Gateway. Pokud tento hybridní přístup není vhodný pro vaše nasazení, přesuňte proces správy certifikátů do služby Application Gateway. Tím se zvýší režijní náklady na správu, ale instance služby Key Vault bude zcela izolovaná. Další informace najdete tady:

• integrace brány Aplikace Azure lication a služby Key Vault
• Vytvořte aplikační bránu s ukončením protokolu TLS pomocí Azure CLI.

Ochrana před útoky DDoS

Pokud máte nějaké virtuální sítě s veřejnými IP adresami, povolte službu Azure DDoS Network Protection. V této referenční architektuře má podsíť, která obsahuje službu Application Gateway, připojenou veřejnou IP adresu, takže je v oboru ochrany před útoky DDoS.

Azure DDoS Network Protection chrání infrastrukturu a úlohu před hromadně podvodnými požadavky. Takové žádosti můžou způsobit přerušení služeb nebo zamaskovat jiný souběžný útok. Azure DDoS Network Protection má značné náklady a obvykle se amortizuje napříč mnoha úlohami, které zahrnují mnoho IP adres. Spolupracujte se svým síťovým týmem a koordinujte pokrytí vašich úloh.

Správa identit a přístupu

Definujte role a nastavte řízení přístupu podle požadavků role. Namapovat role na akce Kubernetes s vymezeným rozsahem tak úzce jako praktické. Vyhněte se rolím, které pokrývají více funkcí. Pokud je více rolí vyplněných jednou osobou, přiřaďte této osobě všechny role, které jsou relevantní pro ekvivalentní pracovní funkce. Takže i když je jedna osoba přímo zodpovědná za cluster i za úlohu, vytvořte kubernetes ClusterRoletak, jako by existovaly samostatné osoby. Pak přiřaďte jednotlivé jednotlivé role.

Minimalizujte stálý přístup, zejména pro účty s vysokým dopadem, jako jsou interakce SRE/Ops s vaším clusterem. Řídicí rovina AKS podporuje microsoft Entra ID Privileged Access Management (PAM) za běhu (JIT) i zásady podmíněného přístupu, které poskytují další vrstvy požadovaného ověření ověřování pro privilegovaný přístup na základě pravidel, která vytváříte.

Další podrobnosti o konfiguraci podmíněného přístupu pomocí PowerShellu najdete v tématech New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy a Remove-MgIdentityConditionalAccessPolicy.

Šifrování disku

Při navrhování šifrování neaktivních uložených dat zvažte disky úložiště, virtuální počítače uzlů agenta AKS, další virtuální počítače a všechny dočasné a disky operačního systému.

Disky úložiště

Ve výchozím nastavení se disky Azure Storage šifrují neaktivní uloženými klíči spravovanými Microsoftem. Pokud používáte jiné než dočasné disky operačního systému nebo přidáváte datové disky, doporučujeme použít klíče spravované zákazníkem pro kontrolu nad šifrovacími klíči. Zašifrujte mimo vrstvu úložiště a zapište jenom šifrovaná data do úložného média. Také se ujistěte, že klíče nejsou nikdy sousedící s vrstvou úložiště. Další informace najdete v tématu Používání vlastních klíčů (BYOK) s disky Azure.

Zvažte použití BYOK pro všechny ostatní disky, které můžou s clusterem pracovat, jako jsou například jump boxy azure Bastion. Pokud zvolíte BYOK, volba skladové položky pro virtuální počítače a regionální dostupnost bude omezená, protože tato funkce není podporovaná ve všech skladových posílaných položek.

Hostitelé virtuálních počítačů

Doporučujeme povolit funkci šifrování na hostiteli. Tím se zašifruje hostitel virtuálního počítače a jakýkoli dočasný operační systém nebo datové disky uložené v mezipaměti na hostiteli virtuálního počítače. Přečtěte si další informace o podpoře virtuálních počítačů pro šifrování na základě hostitele.

Tato funkce se rozšiřuje na data uložená na hostiteli virtuálního počítače uzlů agenta AKS prostřednictvím funkce Šifrování na základě hostitele. Podobně jako BYOK může tato funkce omezit možnosti skladových položek a oblastí virtuálních počítačů.

Tyto funkce můžete vynutit prostřednictvím služby Azure Policy.

Zálohování clusteru (stav a prostředky)

Pokud vaše úloha vyžaduje úložiště v clusteru, máte robustní a zabezpečený proces zálohování a obnovení. Zvažte služby, jako je Azure Backup (pro disky Azure a Soubory Azure), pro zálohování a obnovení libovolného PersistentVolumeClaim. Existují výhody, pokud systém zálohování podporuje nativní prostředky Kubernetes. Můžete doplnit primární metodu, která cluster odsouhlasí s dobře známým stavem, se systémem zálohování pro kritické techniky obnovení systému. Může například pomoct s detekcí odchylek a katalogizací změn stavu systému v průběhu času na úrovni prostředků Kubernetes.

Procesy zálohování musí klasifikovat data v zálohování bez ohledu na to, jestli tato data pocházejí z clusteru, nebo byla externí. Pokud jsou data v rozsahu pro PCI DSS 3.2.1, rozšiřte hranice dodržování předpisů tak, aby zahrnovaly životní cyklus a cíl zálohování, které budou mimo cluster. Zálohy mohou být vektorem útoku. Při navrhování zálohování zvažte geografická omezení, šifrování neaktivních uložených dat, řízení přístupu, role a odpovědnosti, auditování, ochranu před únikem času a prevenci manipulace.

U systémů zálohování v clusteru se očekává, že se během operací budou spouštět s vysokými oprávněními. Vyhodnoťte riziko a výhodu přenesení agenta zálohování do clusteru. Překrývají se možnosti agenta s jiným řešením pro správu v clusteru? Jaká je minimální sada nástrojů, které potřebujete k provedení této úlohy bez rozšíření prostoru pro útoky?

Důležité informace o službě Azure Policy

Použité zásady Azure obvykle nemají nastavení vyladěná úlohou. V implementaci používáme standardy zabezpečení podů clusteru Kubernetes pro iniciativu založené na linuxových úlohách , což je jedna z předdefinovaných iniciativ zásad. Tato iniciativa neumožňuje ladění nastavení. Zvažte export této iniciativy a přizpůsobení jejích hodnot pro konkrétní úlohu. Všechny zásady Azure Gatekeeper deny můžete zahrnout do jedné vlastní iniciativy a všechny audit zásady Azure v rámci jiné iniciativy. Tím kategorizujete blokované akce ze zásad pouze informací.

Zvažte přidání viditelnosti zahrnutím kube-system zásad a gatekeeper-system oborů názvů dozásadch Zahrnutí těchto oborů názvů do zásad zamítnutí může způsobit selhání clusteru kvůli nepodporované konfiguraci.

Šifrování dat můžete vynutit nastavením některých upozornění služby Azure Policy. Můžete například vynutit BYOK s upozorněním, které detekuje clustery, které v prostředku clusteru nemají diskEncryptionSetID . Další zásada může zjistit, jestli je zapnuté agentPoolProfilesšifrování na základě hostitele . Referenční implementace nepoužívá žádné disky v clusteru a disk operačního systému je dočasný. Obě tyto ukázkové zásady se používají jako připomenutí funkce zabezpečení. Zásady jsou nastaveny na audit, nikoli block.

Správa imagí

Pro úlohy používejte základní image bez distribuce. U těchto imagí je oblast zabezpečení minimalizovaná, protože se odeberou doplňkové image, jako jsou shelly a správci balíčků. Výhodou je snížení míry dosažení CVE.

Azure Container Registry podporuje image, které splňují specifikaci formátu image Open Container Initiative (OCI). To společně s kontrolerem přístupu, který podporuje ověřování podpisů, může zajistit, že spouštíte jenom image, které jste podepsali pomocí privátních klíčů. Existují opensourcová řešení, jako je SSE Connaisseur nebo IBM Portieris, která tyto procesy integrují.

Chraňte image kontejnerů a další artefakty OCI, protože obsahují duševní vlastnictví organizace. Používejte klíče spravované zákazníkem a zašifrujte obsah vašich registrů. Ve výchozím nastavení se neaktivní uložená data šifrují pomocí klíčů spravovaných službou, ale klíče spravované zákazníkem se někdy vyžadují ke splnění standardů dodržování právních předpisů. Uložte klíč do spravovaného úložiště klíčů, jako je Azure Key Vault. Protože klíč vytváříte a vlastníte, zodpovídáte za operace související s životním cyklem klíčů, včetně obměně a správy. Další informace najdete v tématu Šifrování registru pomocí klíče spravovaného zákazníkem.

Provozní přístup k serveru rozhraní API Kubernetes

Příkazy spouštěné proti clusteru můžete omezit, aniž byste museli vytvářet provozní proces založený na jump boxech. Pokud máte platformu automatizace IT s bránou IAM, využijte předdefinované akce k řízení a auditování typu akcí.

Sestavení agentů

Agenti kanálu by měli být mimo rozsah regulovaného clusteru, protože procesy sestavení můžou být vektory hrozeb. Procesy sestavení například často pracují s neotestovanými a nedůvěryhodnými komponentami.

I když je běžné používat Kubernetes jako infrastrukturu agenta elastického sestavení, nespouštět tento proces v rámci hranice regulovaného modulu runtime úloh. Agenti sestavení by neměli mít přímý přístup ke clusteru. Například udělte agentům sestavení síťový přístup jenom ke službě Azure Container Registry, aby mohli odesílat image kontejnerů, charty Helm atd. Pak proveďte nasazení prostřednictvím GitOps. Jako běžný postup by pracovní postupy sestavení a vydávání neměli mít přímý přístup k rozhraní API clusteru Kubernetes (nebo jeho uzlům).

Operace sledování

Aktivity v clusteru

Pody v kube-system clusteru omsagent spuštěné jsou agentem kolekce Log Analytics. Shromažďují telemetrii, sešrotují kontejnery stdout a stderr protokoly a shromažďují metriky Prometheus. Nastavení kolekce můžete vyladit aktualizací container-azm-ms-agentconfig.yaml souboru ConfigMap. V této referenční implementaci je protokolování povolené napříč kube-system všemi vašimi úlohami. Ve výchozím nastavení kube-system je vyloučeno z protokolování. Při kontrole protokolů a potřeb dodržování předpisů se ujistěte, že upravujete proces shromažďování protokolů, abyste dosáhli rovnováhy mezi cíli nákladů, efektivitou SRE.

Monitorování zabezpečení

Pomocí defenderu pro kontejnery v Programu Microsoft Defender for Cloud můžete zobrazit a opravit doporučení zabezpečení a zobrazit výstrahy zabezpečení u vašich prostředků kontejneru. Povolte plány Microsoft Defenderu tak, jak se vztahují na různé komponenty datového prostředí držitelů karet.

Integrujte protokoly, abyste mohli efektivně kontrolovat, analyzovat a dotazovat data. Azure nabízí několik možností. Diagnostické protokoly AKS můžete zapnout a odeslat je do pracovního prostoru služby Log Analytics, který je součástí služby Azure Monitor. Další možností je integrace dat do řešení zabezpečení a správy událostí (SIEM), jako je Microsoft Sentinel.

Podle standardu jsou všechny pracovní prostory služby Log Analytics nastavené na dobu uchovávání 90 dnů. Zvažte nastavení průběžného exportu pro dlouhodobé úložiště. Neukládejte citlivé informace do dat protokolu a ujistěte se, že přístup k archivovaným datům protokolu podléhá stejným úrovním řízení přístupu jako nedávná data protokolu.

Kompletní perspektivu najdete v průvodci onboardingem v programu Microsoft Defender for Cloud Enterprise. Tento průvodce řeší registraci, exporty dat do řešení SIEM, reakce na výstrahy a vytváření automatizace pracovních postupů.

Související služby Azure

Tady jsou odkazy na dokumentaci k funkcím některých klíčových komponent této architektury.

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Škálovací sady virtuálních počítačů Azure
• Aplikace Azure lication Gateway s integrovaným firewallem webových aplikací (WAF)
• Úlohy služby Azure Container Registry
• Azure Key Vault

Další kroky

Nainstalujte a udržujte konfiguraci brány firewall pro ochranu dat držitelů karet. Nepoužívejte výchozí hodnoty dodané dodavatelem pro systémová hesla a další parametry zabezpečení.