Architectuur van een gereguleerd AKS-cluster voor PCI-DSS 3.2.1 (deel 2 van 9)

In dit artikel wordt een referentiearchitectuur beschreven voor een AKS-cluster (Azure Kubernetes Service) waarmee een workload wordt uitgevoerd in overeenstemming met de Pci-DSS 3.2.1 (Payment Card Industry Data Security Standard). Deze architectuur is gericht op de infrastructuur en niet op de PCI-DSS 3.2.1-workload.

Dit artikel maakt deel uit van een serie. Lees de inleiding.

De aanbevelingen en voorbeelden worden geëxtraheerd uit deze bijbehorende referentie-implementatie:

GitHub: Azure Kubernetes Service (AKS) Baseline Cluster for Regulated Workloads demonstreert de gereglementeerde infrastructuur. Deze implementatie biedt een microservicetoepassing. Het is inbegrepen om u te helpen de infrastructuur te ervaren en de netwerk- en beveiligingscontroles te illustreren. De toepassing vertegenwoordigt of implementeert geen daadwerkelijke PCI DSS-workload.

Een Visio-bestand van deze architectuur downloaden.

Deze netwerkarchitectuur is gebaseerd op een stertopologie. Het virtuele hubnetwerk bevat de firewall voor het beheren van uitgaand verkeer, gatewayverkeer van on-premises netwerken en een derde netwerk voor toegang tot clusters met SRE (sitebetrouwbaarheidstechnicus). Er zijn twee virtuele spoke-netwerken. Eén spoke bevat het AKS-cluster dat een onderdeel is van de CDE (Card-Holder Environment) en als host fungeert voor de PCI DSS-workload. Met de andere spoke worden installatiekopieën van virtuele machines gebouwd die worden gebruikt voor gecontroleerde SRE-toegang tot de omgeving.

Onderdelen

Dit zijn de belangrijkste onderdelen die in deze architectuur worden gebruikt. Als u niet bekend bent met deze services, raadpleegt u de gerelateerde Azure-services voor koppelingen naar productdocumentatie.

Azure Firewall

Het firewallexemplaren beveiligt uitgaand netwerkverkeer. Zonder deze beveiligingslaag kan de stroom communiceren met een kwaadwillende service van derden die gevoelige bedrijfsgegevens kan exfiltreren.

Azure Bastion

De basislijnarchitectuur biedt een subnet voor Azure Bastion, maar heeft de resource niet ingericht. Deze architectuur voegt Azure Bastion toe aan het subnet en biedt beveiligde toegang tot een jumpbox.

Azure Image Builder

In een afzonderlijk virtueel netwerk worden VM-installatiekopieën gemaakt met basisbeveiliging en -configuratie. In deze architectuur is het aangepast om beveiligde knooppuntinstallatiekopieën te bouwen met beheerhulpprogramma's zoals de Azure CLI kubectlen Flux CLI vooraf geïnstalleerd.

Azure Virtual Machine Scale Sets voor jump box-exemplaren

Het spoke-netwerk heeft extra rekenkracht voor een jumpbox. Deze schaalset is bedoeld als het beheerde toegangspunt voor het uitvoeren van hulpprogramma's voor het AKS-cluster, zoals , indien kubectlnodig.

Azure-toepassing Gateway met geïntegreerde WaF (Web Application Firewall)

Azure-toepassing gatewaytaakverdelingen op laag 7. WAF beveiligt binnenkomend verkeer van veelvoorkomende webverkeeraanvallen. Het exemplaar heeft een openbare front-end-IP-configuratie die gebruikersaanvragen ontvangt.

Azure Kubernetes Service (AKS)

De hostinginfrastructuur, die een belangrijk onderdeel is van de gegevensomgeving van de kaarthouder (CDE). Het AKS-cluster wordt geïmplementeerd als een privécluster. De Kubernetes-API-server wordt dus niet blootgesteld aan het openbare internet en verkeer naar de API-server is beperkt tot uw privénetwerk.

ACR-taken

Biedt een geautomatiseerde manier om containerinstallatiekopieën te bouwen en te onderhouden.

Azure Key Vault

Slaat geheimen op die nodig zijn voor clusterbewerkingen, zoals certificaten en versleutelingssleutels.

Clusterconfiguratie

Hier volgen enkele belangrijke wijzigingen van de basislijnarchitectuur:

Segmentatie van knooppuntgroep

In deze architectuur heeft het cluster twee gebruikersknooppuntgroepen en één systeemknooppuntgroep. De rekenoptie voor de knooppuntgroepen blijft hetzelfde. Elke knooppuntgroep bevindt zich in een toegewezen subnet om een extra netwerkisolatiegrens tussen rekenlagen te bieden.

De PCI-DSS 3.2.1 vereist isolatie van de PCI-workload van andere workloads in termen van bewerkingen en connectiviteit.

• Binnen het bereik: de PCI-workload, de omgeving waarin deze zich bevindt en bewerkingen.

• Buiten bereik: andere workloads die services kunnen delen, maar die zijn geïsoleerd van de onderdelen van het bereik.

De belangrijkste strategie is om het vereiste scheidingsniveau te bieden. De voorkeur wordt gegeven aan het implementeren van binnen- en buitenbereikonderdelen in afzonderlijke clusters. De onderzijde zijn hogere kosten voor de toegevoegde infrastructuur en de onderhoudsoverhead. Met deze implementatie worden alle onderdelen in een gedeeld cluster voor het gemak gevonden. Als u ervoor kiest dat model te volgen, gebruikt u een strikte segmentatiestrategie in het cluster. Ongeacht hoe u ervoor kiest om scheiding te behouden, houd er rekening mee dat wanneer uw oplossing zich ontwikkelt, sommige onderdelen buiten het bereik mogelijk binnen het bereik worden.

In de referentie-implementatie wordt de tweede benadering gedemonstreerd met een microservicestoepassing die is geïmplementeerd in één cluster. De workloads binnen het bereik en buiten het bereik worden gesegmenteerd in twee afzonderlijke gebruikersknooppuntgroepen. De toepassing heeft twee sets services; de ene set heeft pods binnen het bereik en de andere is buiten het bereik. Beide sets worden verdeeld over twee gebruikersknooppuntgroepen. Met het gebruik van Kubernetes-taints worden binnen- en buitenbereikpods geïmplementeerd op afzonderlijke knooppunten en delen ze nooit een knooppunt-VM of de IP-ruimte van het netwerk.

Toegangscontroller

De Kubernetes-ingangscontroller in het cluster is gewijzigd in NGINX. In de basislijnarchitectuur werd Traefik gebruikt. Deze wijziging illustreert dat dit onderdeel kan worden gewijzigd op basis van de vereisten van uw workloads.

Privé-Kubernetes-API-server

De basislijnarchitectuur heeft het AKS-cluster geïmplementeerd in de openbare modus. Dit betekent dat alle communicatie met de door AKS beheerde Kubernetes API-server via het openbare internet plaatsvindt. Dit is niet acceptabel in deze architectuur omdat PCI-DSS 3.2.1 openbare blootstelling aan systeemonderdelen verbiedt. In deze gereguleerde architectuur wordt het cluster geïmplementeerd als een privécluster. Netwerkverkeer naar de Kubernetes-API-server is beperkt tot uw privénetwerk. De API-server wordt weergegeven via een privé-eindpunt in het clusternetwerk. De beveiliging wordt verder verbeterd met het gebruik van netwerkbeveiligingsgroepen en andere ingebouwde functies. Deze worden beschreven in de netwerkconfiguratie.

Pod-beveiliging

Wanneer u de beveiligingsbehoeften van uw workload beschrijft, gebruikt u relevante securityContext instellingen voor uw containers. Dit omvat basisinstellingen zoals fsGroup,runAsGrouprunAsUser / en instelling allowPrivilegeEscalation op false (tenzij vereist). Wees duidelijk over het definiëren en verwijderen van Linux-mogelijkheden en het definiëren van uw SELinux-opties in seLinuxOptions.

Vermijd het verwijzen naar installatiekopieën door hun tags in uw implementatiemanifesten. Gebruik in plaats daarvan de werkelijke afbeeldings-id. Op die manier kunt u op betrouwbare wijze scanresultaten van containers toewijzen met de werkelijke inhoud die in uw cluster wordt uitgevoerd. U kunt dit afdwingen via Azure Policy voor de naam van de installatiekopie om het afbeeldings-id-patroon op te nemen in de toegestane reguliere expressie. Volg deze richtlijnen ook wanneer u de Dockerfile-instructie FROM gebruikt.

Netwerkconfiguratie

De hub-spokes worden allemaal geïmplementeerd in afzonderlijke virtuele netwerken, elk in hun privéadresruimte. Standaard is er geen verkeer toegestaan tussen twee virtuele netwerken. In het netwerk wordt segmentatie toegepast door subnetten te maken.

Een combinatie van verschillende Azure-services en -functies en systeemeigen Kubernetes-constructies biedt het vereiste controleniveau. Hier volgen enkele opties die in deze architectuur worden gebruikt.

Subnetbeveiliging via netwerkbeveiligingsgroepen (NSG's)

Er zijn verschillende NSG's die de stroom in en uit het cluster beheren. Hieronder volgen een aantal voorbeelden:

• De clusterknooppuntgroepen worden in toegewezen subnetten geplaatst. Voor elk subnet zijn er NSG's die SSH-toegang tot knooppunt-VM's blokkeren en verkeer van het virtuele netwerk toestaan. Verkeer van de knooppuntgroepen is beperkt tot het virtuele netwerk.

• Al het inkomende verkeer van internet wordt onderschept door Azure-toepassing Gateway. NSG-regels zorgen er bijvoorbeeld voor dat:

  • Alleen HTTPS-verkeer is toegestaan in.
  • Verkeer van het Azure-besturingsvlak is toegestaan. Zie Toegang tot enkele bron-IP-adressen toestaan voor meer informatie.

• Op de subnetten met Azure Container Registry-agents staan NSG's alleen benodigd uitgaand verkeer toe. Verkeer is bijvoorbeeld toegestaan voor Azure Key Vault, Microsoft Entra ID, Azure Monitor en andere services waarmee het containerregister moet communiceren.

• Het subnet met de jumpbox is bedoeld voor beheerbewerkingen. De NSG-regel staat alleen SSH-toegang toe vanuit Azure Bastion in de hub en beperkte uitgaande verbindingen. Jumpboxen hebben geen universele internettoegang en worden beheerd op zowel de subnet-NSG als de Azure Firewall.

Wanneer uw workloads, systeembeveiligingsagents en andere onderdelen worden geïmplementeerd, voegt u meer NSG-regels toe waarmee u het type verkeer kunt definiëren dat moet worden toegestaan. Verkeer mag deze subnetgrenzen niet passeren. Omdat elke knooppuntgroep zich in een eigen subnet bevindt, bekijkt u de verkeerspatronen en past u vervolgens specifiekere regels toe.

Pod-naar-pod-beveiliging met netwerkbeleid

Deze architectuur probeert de principes van 'nul vertrouwen' van Microsoft zoveel mogelijk te implementeren.

Voorbeelden van Zero Trust-netwerken als concept worden gedemonstreerd in de implementatie in a0005-i en a0005-o door de gebruiker geleverde naamruimten. Alle workloadnaamruimten moeten beperkende NetworkPolicy hebben toegepast. De beleidsdefinities zijn afhankelijk van de pods die in deze naamruimten worden uitgevoerd. Zorg ervoor dat u rekening moet houden met gereedheids-, levendigheids- en opstarttests en ook toelage voor metrische gegevens die zijn verzameld door de Log Analytics-agent. Overweeg om poorten in uw workloads te standaardiseren, zodat u een consistent NetworkPolicy en Azure Policy kunt bieden voor toegestane containerpoorten.

In bepaalde gevallen is dit niet praktisch voor communicatie binnen het cluster. Niet alle door de gebruiker opgegeven naamruimten kunnen gebruikmaken van een zero trust-netwerk (kan er bijvoorbeeld cluster-baseline-settings geen gebruiken).

TLS-versleuteling

De basislijnarchitectuur biedt TLS-versleuteld verkeer totdat de ingangscontroller in het cluster is, maar pod-naar-pod-communicatie is duidelijk. In deze architectuur wordt TLS uitgebreid tot pods-naar-pod-verkeer, met certificeringsinstantievalidatie (CA). Deze TLS wordt geleverd door een service-mesh, die mTLS-verbindingen en verificatie afdwingt voordat communicatie wordt toegestaan.

De implementatie maakt gebruik van mTLS. mTLS-ondersteuning kan worden geïmplementeerd met of zonder service-mesh. Als u een mesh gebruikt, moet u ervoor zorgen dat deze compatibel is met de certificaatverlener van uw keuze. Deze implementatie maakt gebruik van Open Service Mesh.

De ingangscontroller in deze implementatie maakt gebruik van een jokertekencertificaat om standaardverkeer te verwerken wanneer een toegangsbeheerobjectresource geen specifiek certificaat bevat. Dit kan acceptabel zijn, maar als uw organisatiebeleid het gebruik van jokertekencertificaten niet toestaat, moet u mogelijk uw toegangsbeheerobjectcontroller aanpassen om geen jokertekencertificaat te gebruiken.

Netwerkbeperkingen voor Azure Key Vault

Alle geheimen, sleutels en certificaten worden opgeslagen in Azure Key Vault. Key Vault verwerkt certificaatbeheertaken, zoals roulatie. Communicatie met Key Vault verloopt via Azure Private Link. De DNS-record die is gekoppeld aan Key Vault bevindt zich in een privé-DNS-zone, zodat deze niet kan worden omgezet via internet. Hoewel dit de beveiliging verbetert, zijn er enkele beperkingen.

Azure-toepassing Gateway ondersteunt geen TLS-certificaten voor de HTTP-listener van Key Vault-exemplaren die beschikbaar zijn met Private Link. De implementatie implementeert Key Vault dus in een hybride model. Er wordt nog steeds Private Link gebruikt voor verbindingen die deze ondersteunen, maar biedt ook openbare toegang voor Application Gateway-integratie. Als deze hybride benadering niet geschikt is voor uw implementatie, verplaatst u het certificaatbeheerproces naar Application Gateway. Hiermee wordt beheeroverhead toegevoegd, maar dan wordt het Key Vault-exemplaar volledig geïsoleerd. Voor informatie raadpleegt u:

• integratie van Azure-toepassing Gateway en Key Vault
• Maak een toepassingsgateway met TLS-beëindiging met behulp van de Azure CLI.

DDoS-bescherming

Schakel Azure DDoS-netwerkbeveiliging in voor virtuele netwerken met een subnet dat Application Gateway met een openbaar IP-adres bevat. Hierdoor worden de infrastructuur en workload beschermd tegen massas frauduleuze aanvragen. Dergelijke aanvragen kunnen serviceonderbrekingen veroorzaken of een andere gelijktijdige aanval maskeren. Azure DDoS kost veel kosten en wordt doorgaans afgeschreven voor veel workloads die veel IP-adressen omvatten. Werk samen met uw netwerkteam om de dekking voor uw workload te coördineren.

Identiteitstoegangsbeheer

Definieer rollen en stel toegangsbeheer in op basis van de vereisten van de rol. Wijs rollen toe aan Kubernetes-acties die zo beperkt als praktisch zijn. Vermijd rollen die meerdere functies omvatten. Als meerdere rollen door één persoon worden ingevuld, wijst u die persoon alle rollen toe die relevant zijn voor de equivalente taakfuncties. Dus zelfs als één persoon rechtstreeks verantwoordelijk is voor zowel het cluster als de workload, maakt u uw Kubernetes ClusterRoles alsof er afzonderlijke personen zijn. Wijs die afzonderlijke afzonderlijke relevante rollen vervolgens toe.

Minimaliseer permanente toegang, met name voor accounts met hoge impact, zoals SRE/Ops-interacties met uw cluster. Het AKS-besturingsvlak ondersteunt zowel Het Just-In-Time-beleid (JIT) van Microsoft Entra ID Privileged Access Management (PAM) als het beleid voor voorwaardelijke toegang. Dit biedt een extra laag vereiste verificatievalidatie voor bevoegde toegang, op basis van de regels die u bouwt.

Zie New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy en Remove-MgIdentityConditionalAccessPolicy voor meer informatie over het configureren van voorwaardelijke toegang.

Schijfversleuteling

Wanneer u versleuteling ontwerpt voor data-at-rest, kunt u opslagschijven, VM's van AKS-agentknooppunten, andere VM's en tijdelijke schijven en eventuele tijdelijke schijven en eventuele besturingssysteemschijven overwegen.

Opslagschijven

Standaard worden Azure Storage-schijven in rust versleuteld met door Microsoft beheerde sleutels. Als u niet-tijdelijke besturingssysteemschijven gebruikt of gegevensschijven toevoegt, wordt u aangeraden door de klant beheerde sleutels te gebruiken voor controle over de versleutelingssleutels. Versleutelen buiten de opslaglaag en schrijf alleen versleutelde gegevens naar het opslagmedium. Zorg er ook voor dat de sleutels nooit grenzen aan de opslaglaag.

Zie Bring Your Own Keys (BYOK) met Azure-schijven voor meer informatie.

Overweeg BYOK te gebruiken voor andere schijven die kunnen communiceren met het cluster, zoals uw Azure Bastion-fronted jumpboxs. Als u BYOK kiest, wordt de SKU-keuze voor VM's en regionale beschikbaarheid beperkt omdat deze functie niet wordt ondersteund voor alle SKU's of regio's.

VM-hosts

U wordt aangeraden de functie versleuteling op host in te schakelen. Hiermee worden de VM-host en eventuele tijdelijke besturingssystemen of gegevensschijven die zijn opgeslagen in de cache op een VM-host, versleuteld. Meer informatie over VM-ondersteuning voor versleuteling op basis van een host.

Deze functie wordt uitgebreid naar de gegevens die zijn opgeslagen op de VM-host van uw AKS-agentknooppunten via de functie Op host gebaseerde versleuteling . Net als bij BYOK kan deze functie uw VM-SKU en regio-keuzes beperken.

U kunt deze functies afdwingen via Azure Policy.

Clusterback-ups (status en resources)

Als uw workload opslag in het cluster vereist, moet u een robuust en veilig proces hebben voor back-up en herstel. Overweeg services zoals Azure Backup (voor Azure Disks en Azure Files) voor back-up en herstel van alle PersistantVolumeClaimservices. Er zijn voordelen als het back-upsysteem systeemeigen Kubernetes-resources ondersteunt. U kunt uw primaire methode aanvullen waarmee het cluster wordt afgestemd op een bekende status, met het back-upsysteem voor kritieke systeemhersteltechnieken. Het kan bijvoorbeeld helpen bij afwijkingsdetectie en het catalogiseren van systeemstatuswijzigingen in de loop van de tijd op het niveau van de Kubernetes-resource.

Back-upprocessen moeten gegevens in de back-up binnen of buiten het cluster classificeren. Als de gegevens binnen het bereik van PCI DSS 3.2.1 vallen, kunt u de nalevingsgrenzen uitbreiden om de levenscyclus en het doel van de back-up op te nemen, die zich buiten het cluster bevinden. Back-ups kunnen een aanvalsvector zijn. Overweeg bij het ontwerpen van uw back-up geografische beperkingen, versleutelings-at-rest, toegangsbeheer, rollen en verantwoordelijkheden, controle, time-to-live en preventie van manipulatie.

Back-upsystemen in het cluster worden naar verwachting uitgevoerd met hoge bevoegdheden tijdens de bewerkingen. Evalueer het risico en voordeel van het overbrengen van een back-upagent naar uw cluster. Overlapt de agentmogelijkheid met een andere beheeroplossing in het cluster? Wat is de minimale set hulpprogramma's die u nodig hebt om deze taak uit te voeren zonder het kwetsbaarheid voor aanvallen uit te breiden?

Overwegingen voor Azure Policy

Normaal gesproken hebben toegepaste Azure-beleidsregels geen instellingen voor workloads. In de implementatie passen we de beperkte beveiligingsstandaarden voor kubernetes-clusterpods toe voor linux-workloads , waardoor het afstemmen van instellingen niet is toegestaan. Overweeg dit initiatief te exporteren en de bijbehorende waarden voor uw specifieke workload aan te passen. U kunt alle Gatekeeper deny Azure-beleidsregels opnemen onder één aangepast initiatief en alle audit Azure-beleidsregels onder een ander initiatief. Als u dit doet, worden acties van beleid voor alleen-informatie geblokkeerd.

Overweeg om de kube-system en gatekeeper-system naamruimten toe te voegen aan beleidsregels in uw controlebeleid voor extra zichtbaarheid. Het opnemen van deze naamruimten in beleid voor weigeren kan leiden tot clusterfouten vanwege een niet-ondersteunde configuratie.

U kunt gegevensversleuteling afdwingen door enkele Azure Policy-waarschuwingen in te stellen. U kunt BIJVOORBEELD BYOK afdwingen met een waarschuwing waarmee clusters worden gedetecteerd die geen clusterresource hebben diskEncryptionSetID . Een ander beleid kan detecteren of Hostgebaseerde versleuteling is ingeschakeld agentPoolProfiles. De referentie-implementatie gebruikt geen schijven in het cluster en de besturingssysteemschijf is kortstondig. Beide voorbeelden van beleidsregels zijn ingesteld als herinnering aan de beveiligingsfunctie. Het beleid is ingesteld op audit, niet block.

Installatiekopieën beheren

Gebruik distributieloze basisinstallatiekopieën voor uw workloads. Met deze afbeeldingen wordt het beveiligingsoppervlak geminimaliseerd omdat aanvullende installatiekopieën, zoals shells en pakketbeheerders, worden verwijderd. Een voordeel is verlaagde CVE-hittarieven.

Azure Container Registry ondersteunt installatiekopieën die voldoen aan de indelingsspecificatie van het Open Container Initiative (OCI). In combinatie met een toegangscontroller die ondersteuning biedt voor het valideren van handtekeningen, kunt u ervoor zorgen dat u alleen afbeeldingen uitvoert die u hebt ondertekend met uw persoonlijke sleutels. Er zijn opensource-oplossingen zoals SSE Connaisseur of IBM Portieris die deze processen integreren.

Beveilig containerinstallatiekopieën en andere OCI-artefacten omdat ze het intellectuele eigendom van de organisatie bevatten. Gebruik door de klant beheerde sleutels en versleutel de inhoud van uw registers. Standaard worden de gegevens in rust versleuteld met door de service beheerde sleutels, maar soms zijn door de klant beheerde sleutels vereist om te voldoen aan wettelijke nalevingsstandaarden. Sla de sleutel op in een beheerde sleutelopslag, zoals Azure Key Vault. Omdat u de sleutel maakt en eigenaar bent, bent u verantwoordelijk voor bewerkingen met betrekking tot de levenscyclus van de sleutel, inclusief rotatie en beheer. Zie Register versleutelen met behulp van een door de klant beheerde sleutel voor meer informatie.

Operationele toegang tot Kubernetes API Server

U kunt opdrachten beperken die worden uitgevoerd op het cluster, zonder dat u noodzakelijkerwijs een operationeel proces hoeft te bouwen op basis van jumpboxs. Als u een IAM-gated IT-automatiseringsplatform hebt, gebruikt u de vooraf gedefinieerde acties om het type acties te beheren en te controleren.

Agents bouwen

Pijplijnagents moeten buiten het bereik van het gereglementeerde cluster vallen, omdat buildprocessen bedreigingsvectoren kunnen zijn. Hoewel het gebruikelijk is om Kubernetes te gebruiken als een infrastructuur voor elastische buildagents, voert u dat proces niet uit binnen de grens van de gereguleerde workloadruntime. Uw buildagents mogen geen directe toegang tot het cluster hebben. Geef bijvoorbeeld alleen buildagents netwerktoegang tot Azure Container Registry om containerinstallatiekopieën, Helm-grafieken enzovoort te pushen. Implementeer vervolgens via GitOps. Als veelvoorkomende procedure mogen build- en releasewerkstromen geen directe toegang hebben tot uw Kubernetes Cluster-API (of de bijbehorende knooppunten).

Controlebewerkingen

Activiteiten in het cluster

De pods in het cluster omsagent die worden kube-system uitgevoerd, zijn de Log Analytics-verzamelingsagent. Ze verzamelen telemetrie, scrape container stdout en stderr logboeken en verzamelen prometheus-metrische gegevens. U kunt de verzamelingsinstellingen afstemmen door het container-azm-ms-agentconfig.yaml ConfigMap-bestand bij te werken. In deze referentie-implementatie is logboekregistratie ingeschakeld voor kube-system al uw workloads. kube-system Standaard is dit uitgesloten van logboekregistratie. Zorg ervoor dat u het logboekverzamelingsproces aanpast om balans te bereiken tussen kostendoelstellingen, SRE-efficiëntie wanneer u logboeken en nalevingsbehoeften bekijkt.

Controleren van beveiliging

Gebruik Defender for Containers in Microsoft Defender voor Cloud om beveiligingsaankopen weer te geven en te herstellen en beveiligingswaarschuwingen voor uw containerresources weer te geven. Schakel Microsoft Defender-abonnementen in zoals deze van toepassing zijn op verschillende onderdelen van de gegevensomgeving van de kaarthouder.

Integreer logboeken zodat u gegevens efficiënt kunt controleren, analyseren en er query's op kunt uitvoeren. Azure biedt verschillende opties. U kunt diagnostische AKS-logboeken inschakelen en deze verzenden naar een Log Analytics-werkruimte die deel uitmaakt van Azure Monitor. Een andere optie is om gegevens te integreren in SIEM-oplossingen (Security Information and Event Management), zoals Microsoft Sentinel.

Zoals vereist volgens de standaard, worden alle Log Analytics-werkruimten ingesteld op een bewaarperiode van 90 dagen. Overweeg continue export in te stellen voor langetermijnopslag. Sla geen gevoelige informatie op in logboekgegevens en zorg ervoor dat de toegang tot gearchiveerde logboekgegevens onderhevig is aan dezelfde toegangsniveaus als recente logboekgegevens.

Zie Microsoft Defender voor Cloud Handleiding voor onboarding voor ondernemingen voor een volledig perspectief. In deze handleiding worden inschrijvingen, gegevensexports naar uw SIEM-oplossingen, reageren op waarschuwingen en het bouwen van werkstroomautomatisering aangepakt.

Gerelateerde Azure Services

Hier volgen koppelingen naar functiedocumentatie van enkele belangrijke onderdelen van deze architectuur.

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Azure-schaalvergrotingssets voor virtuele machines
• Azure-toepassing Gateway met geïntegreerde WaF (Web Application Firewall)
• Azure Container Registry-taken
• Azure Key Vault

Volgende stappen

Installeer en onderhoud een firewallconfiguratie om gegevens van de kaarthouder te beveiligen. Gebruik geen door de leverancier geleverde standaardwaarden voor systeemwachtwoorden en andere beveiligingsparameters.