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

In dit artikel wordt een referentiearchitectuur beschreven voor een Azure Kubernetes Service-cluster (AKS) met een workload die voldoet aan de Payment Card Industry Data Security Standard (PCI-DSS 3.2.1). 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 basislijncluster (AKS) voor gereguleerde workloads demonstreert de gereguleerde infrastructuur. Deze implementatie biedt een microservicetoepassing. Het is opgenomen om u te helpen de infrastructuur te ervaren en de netwerk- en beveiligingscontroles te illustreren. De toepassing vertegenwoordigt of implementeert geen werkelijke PCI DSS workload.

Deze netwerkarchitectuur is gebaseerd op een hub-spoke-topologie. Het virtuele hubnetwerk bevat de firewall voor het beheren van het toegangsbeheer voor het verkeer van de gateway van on-premises netwerken en een derde netwerk voor toegang tot het SRE-cluster. Er zijn twee virtuele spoke-netwerken. Eén spoke bevat het AKS-cluster dat een onderdeel is van de kaarthouder-omgeving (CDE) en host de PCI DSS workload. De andere spoke bouwt virtuele-machine-afbeeldingen die worden gebruikt voor gecontroleerde SRE-toegang tot de omgeving.

Onderdelen

Dit zijn de belangrijkste onderdelen die in deze architectuur worden gebruikt. Zie Gerelateerde Azure-services voor koppelingen naar productdocumentatie als u niet bekend bent met deze services.

Azure Firewall

Het firewall-exemplaar 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. Het biedt beveiligde toegang tot een jumpbox.

Azure Image Builder

Ingericht in een afzonderlijk virtueel netwerk. Hiermee maakt u VM-installatiebestanden met basisbeveiliging en -configuratie. In deze architectuur is het aangepast voor het bouwen van beveiligde knooppuntafbeeldingen met beheerhulpprogramma's zoals de Azure CLI, kubectl en Flux CLI die vooraf zijn geïnstalleerd.

Azure Virtual Machine Scale Sets voor jump box-exemplaren

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

Azure Application Gateway met Geïntegreerde Web Application Firewall (WAF)

Azure Application Gateway load balances op laag 7. WAF beveiligt binnenkomend verkeer tegen veelvoorkomende aanvallen op internetverkeer. 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 particuliere netwerk.

ACR-taken

Biedt een geautomatiseerde manier om containerafbeeldingen te bouwen en onderhouden.

Azure Key Vault

Bewaart en beheert geheimen die nodig zijn voor clusterbewerkingen, zoals certificaten en versleutelingssleutels.

Clusterconfiguratie

Hier zijn enkele belangrijke wijzigingen tengezien van de basislijnarchitectuur:

Segmentatie van knooppuntgroep

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

Pci-DSS 3.2.1 vereist isolatie van de PCI-workload van andere workloads wat betreft bewerkingen en connectiviteit.

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

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

De belangrijkste strategie is om het vereiste niveau van scheiding te bieden. De voorkeursmethode is het implementeren van binnen- en buiten het bereik van onderdelen in afzonderlijke clusters. De keerzijde zijn hogere kosten voor de toegevoegde infrastructuur en de onderhoudsoverhead. Met deze implementatie worden alle onderdelen in een gedeeld cluster voor het gemak op dezelfde locatie gevonden. Als u ervoor kiest om dat model te volgen, gebruikt u een strenge in-clustersegmentatiestrategie. Ongeacht hoe u ervoor kiest om de scheiding te behouden, houd er rekening mee dat wanneer uw oplossing zich ontwikkelt, sommige onderdelen buiten het bereik mogelijk binnen het bereik vallen.

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

Controller voor ingress

De Kubernetes-controller voor ingress binnen het cluster is gewijzigd in NGINX. In de basislijnarchitectuur gebruikte Traefik. Deze wijziging illustreert dat dit onderdeel kan worden gewijzigd op basis van de vereisten van uw workloads.

Persoonlijke 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 gebeurt. 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 particuliere netwerk. De API-server wordt beschikbaar gemaakt via een privé-eindpunt in het netwerk van het cluster. De beveiliging wordt verder verbeterd met het gebruik van netwerkbeveiligingsgroepen en andere ingebouwde functies. Deze worden beschreven in Netwerkconfiguratie.

Pod-beveiliging

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

Vermijd te verwijzen naar afbeeldingen met hun tags in uw implementatiemanifests. Gebruik in plaats daarvan de werkelijke afbeeldings-id. Op die manier kunt u containerscanresultaten betrouwbaar in kaart brengen met de werkelijke inhoud die in uw cluster wordt uitgevoerd. U kunt dit afdwingen via Azure Policy de naam van de afbeelding het afbeeldings-id-patroon in de toegestane reguliere expressie op te nemen. Volg ook deze richtlijnen wanneer u de instructie Dockerfile 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. Binnen het netwerk wordt segmentering toegepast door subnetten te maken.

Een combinatie van verschillende Azure-services en -functies en native Kubernetes-constructies bieden het vereiste controleniveau. Hier zijn 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 bepalen. Hier volgen enkele 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 wordt beperkt tot het virtuele netwerk.
• Al het inkomende verkeer van internet wordt onderschept door Azure Application Gateway. NSG-regels zorgen er bijvoorbeeld voor dat:
  • Alleen HTTPS-verkeer is toegestaan in .
  • Verkeer van Azure Control Plane is toegestaan.
    Zie Toegang tot enkele bron-IP's toestaan voor meer informatie.
• Op de subnetten met Azure Container Registry agents staan NSG's alleen het benodigde uitgaande verkeer toe. Verkeer kan bijvoorbeeld worden gebruikt Azure Key Vault, Azure Active Directory, Azure Monitor en andere services die het containerregister moet gebruiken.
• 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. Jumpboxs hebben geen universele internettoegang en worden beheerd op zowel de subnet-NSG als Azure Firewall.

Naarmate uw workloads, systeembeveiligingsagents en andere onderdelen worden geïmplementeerd, voegt u meer NSG-regels toe die helpen bij het definiëren van het type verkeer dat moet worden toegestaan. Verkeer mag deze subnetgrenzen niet overschrijden. Omdat elke knooppuntgroep zich in een eigen subnet woont, kunt u de verkeerspatronen observeren en vervolgens specifiekere regels toepassen.

Pod-to-pod-beveiliging met netwerkbeleid

Deze architectuur probeert zo veel mogelijk de 'zero trust'-principes van Microsoft te implementeren.

Voorbeelden van Zero Trust netwerken als concept worden gedemonstreerd in de implementatie in en door de gebruiker a0005-i a0005-o opgegeven naamruimten. Op alle workloadnaamruimten moet een beperkend NetworkPolicy worden toegepast. De beleidsdefinities zijn afhankelijk van de pods die worden uitgevoerd in deze naamruimten. Zorg ervoor dat u zorgt voor gereedheid, actualiteit en opstarttests en voor metrische gegevens die worden verzameld door de Log Analytics-agent. Overweeg het standaardiseren van poorten voor uw workloads, zodat u een consistent NetworkPolicy en Azure Policy toegestane containerpoorten kunt bieden.

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

TLS-versleuteling

De basislijnarchitectuur biedt met TLS versleuteld verkeer tot de controller voor toegangsverkeer in het cluster, maar de communicatie tussen pods is niet duidelijk. In deze architectuur wordt TLS uitgebreid naar pods-naar-pod-verkeer, met validatie van de certificeringsinstantie (CA). Deze TLS wordt geleverd door een service-mesh, die mTLS-verbindingen en -verificatie afdwingt voordat communicatie wordt toe te staan.

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

De controller voor ingress in deze implementatie maakt gebruik van een jokertekencertificaat voor het afhandelen van standaardverkeer wanneer een resource voor binnenverkeer geen specifiek certificaat bevat. Dit kan acceptabel zijn, maar als het gebruik van jokertekencertificaten niet is toegestaan in uw organisatiebeleid, moet u mogelijk uw controller voor ingress aanpassen om geen jokertekencertificaat te gebruiken.

Azure Key Vault netwerkbeperkingen

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

Azure Application Gateway biedt geen ondersteuning voor het verkrijgen van TLS-certificaten voor de HTTP-listener van Key Vault exemplaren die worden blootgesteld met Private Link. De implementatie implementeert dus Key Vault in een hybride model. Er wordt nog steeds Private Link gebruikt voor verbindingen die dit 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. Dit voegt beheeroverhead toe, maar vervolgens wordt Key Vault exemplaar volledig geïsoleerd. Zie voor informatie:

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

DDoS-bescherming

Schakel Azure DDoS Protection Standard in voor virtuele netwerken met een subnet Application Gateway een openbaar IP-adres bevat. Dit beschermt de infrastructuur en workload tegen grootschalige frauduleuze aanvragen. Dergelijke aanvragen kunnen serviceonderbreking veroorzaken of een andere gelijktijdige aanval maskeren. Azure DDoS heeft aanzienlijke 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

Rollen definiëren en toegangsbeleid instellen 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 bespannen. Als meerdere rollen door één persoon worden ingevuld, wijst u die persoon alle rollen toe die relevant zijn voor de equivalente functie van de functie. Dus zelfs als één persoon rechtstreeks verantwoordelijk is voor zowel het cluster als de workload, maakt u uw Kubernetes alsof er ClusterRoles afzonderlijke personen zijn. Wijs vervolgens die ene persoon alle relevante rollen toe.

Minimaliseer permanente toegang, met name voor accounts met een hoge impact, zoals SRE/Ops-interacties met uw cluster. Het AKS-besturingsvlak ondersteunt zowel Azure AD Privileged Access Management (PAM) Just-In-Time (JIT). Beleid voor voorwaardelijke toegang kan extra lagen bieden voor de vereiste verificatievalidatie voor bevoegde toegang, op basis van de regels die u bouwt.

Zie Voorwaardelijke toegang van Azure AD voor meer informatie over het gebruik van PowerShell voor het configureren van voorwaardelijke toegang.

Schijfversleuteling

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

Storage schijven

Standaard worden Azure Storage schijven in rust versleuteld met door Microsoft beheerde sleutels. Als u niet-kortstondige 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 naast de opslaglaag liggen.

Zie uw eigen Bing (BYOK) gebruiken met Azure-schijvenvoor meer informatie.

Overweeg het gebruik van BYOK voor alle andere schijven die mogelijk met het cluster communiceren, 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 in alle SKU's of regio's.

VM-hosts

U wordt aangeraden de functie encryption-at-host in teschakelen. Hiermee worden de VM-host en eventuele tijdelijke besturingssystemen of gegevensschijven die op een VM-host in de cache zijn opgeslagen, versleuteld. Lees meer over VM-ondersteuning voor hostgebaseerde versleuteling.

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

U kunt deze functies afdwingen via Azure Policy.

Clusterback-ups (status en resources)

Als voor uw workload opslag in het cluster is vereist, moet u een robuust en veilig proces voor back-up en herstel hebben. Overweeg services zoals Azure Backup (voor Azure Disks en Azure Files) voor back-up en herstel van een PersistantVolumeClaim . Er zijn voordelen als het back-upsysteem systeemeigen Kubernetes-resources ondersteunt. U kunt uw primaire methode die het cluster afstemmt op een bekende status, aanvullen met het back-upsysteem voor kritieke systeemhersteltechnieken. Het kan bijvoorbeeld helpen bij de detectie van driften en het catalogiseren van systeemtoestandswijzigingen gedurende een periode op Kubernetes-resourceniveau.

Back-upprocessen moeten gegevens classificeren in de back-up binnen of buiten het cluster. Als de gegevens binnen het bereik van PCI DSS 3.2.1 vallen, breidt u uw nalevingsgrenzen uit met de levenscyclus en het doel van de back-up, die zich buiten het cluster zullen stellen. Back-ups kunnen een aanvalsvector zijn. Houd bij het ontwerpen van uw back-up rekening met geografische beperkingen, versleuteling in rust, toegangsbesturingselementen, rollen en verantwoordelijkheden, controle, time-to-live en manipulatiepreventie.

Back-upsystemen binnen clusters worden naar verwachting uitgevoerd met hoge bevoegdheden tijdens de bewerkingen. Evalueer het risico en de voordelen van het in uw cluster brengen van een back-upagent. 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 aanvalsoppervlak uit te breiden?

Azure Policy overwegingen

Azure-beleidsregels die worden toegepast, hebben doorgaans geen op workload afgestemde instellingen. In de implementatie passen we de beperkte kubernetes-clusterpodbeveiligingsstandaarden toe voor het op Linux gebaseerde initiatief voor workloads, waardoor instellingen niet kunnen worden afgestemd. Overweeg dit initiatief te exporteren en de waarden ervan aan te passen voor uw specifieke workload. U kunt alle Gatekeeper deny Azure-beleidsregels onder één aangepast initiatief en alle audit Azure-beleidsregels onder een ander initiatief opnemen. Als u dit doet, worden blokacties van alleen-informatiebeleid gecategoriseerd.

U kunt overwegen om kube-system de gatekeeper-system naamruimten en toe te voegen aan beleidsregels in uw controlebeleid voor meer zichtbaarheid. Als u deze naamruimten opsommen in beleid voor weigeren, kan dit leiden tot clusterstoringen vanwege een niet-ondersteunde configuratie.

U kunt gegevensversleuteling afdwingen door een aantal Azure Policy instellen. U kunt bijvoorbeeld BYOK afdwingen met een waarschuwing die clusters detecteert die geen diskEncryptionSetID clusterresource hebben. Een ander beleid kan detecteren Host-Based versleuteling is ingeschakeld op agentPoolProfiles . De referentie-implementatie maakt geen gebruik van schijven in het cluster en de besturingssysteemschijf is kortstondig. Beide voorbeeldbeleidsregels zijn ter herinnering van de beveiligingsfunctie. Het beleid is ingesteld op audit , niet block op .

Afbeeldingen beheren

Gebruik distributie-minder basisafbeeldingen voor uw workloads. Met deze afbeeldingen wordt de surface area geminimaliseerd omdat aanvullende afbeeldingen, zoals shells en pakketmanagers, worden verwijderd. Een voordeel is lagere CVE-treffers.

Azure Container Registry ondersteunt afbeeldingen die voldoen aan de OCI-specificatie (Open Container Initiative). Dit, in combinatie met een toegangscontroller die ondersteuning biedt voor het valideren van handtekeningen, kan ervoor zorgen dat u alleen afbeeldingen gebruikt die u hebt ondertekend met uw persoonlijke sleutels. Er zijn opensource-oplossingen, zoals SSE Connaisseur of IBM Moetenis, die deze processen integreren.

Bescherm containerafbeeldingen en andere OCI-artefacten omdat ze het intellectueel eigendom van de organisatie bevatten. Gebruik door de klant beheerde sleutels en versleutel de inhoud van uw registers. De gegevens worden standaard 'at rest' versleuteld met door de service beheerde sleutels, maar door de klant beheerde sleutels zijn soms vereist om te voldoen aan wettelijke nalevingsstandaarden. Sla de sleutel op in een beheerd sleutelopslag zoals Azure Key Vault. Omdat u de sleutel maakt en er eigenaar van bent, bent u verantwoordelijk voor bewerkingen met betrekking tot de levenscyclus van sleutels, waaronder roulatie en beheer. Zie Register versleutelen met een door de klant beheerde sleutel voor meer informatie.

Operationele toegang tot Kubernetes API Server

U kunt opdrachten die worden uitgevoerd op het cluster beperken, zonder dat u per se 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 controleren en te controleren.

Buildagents

Pijplijnagents moeten buiten het bereik van het gereguleerde cluster vallen, omdat buildprocessen bedreigingsvectoren kunnen zijn. Hoewel het gebruikelijk is om Kubernetes te gebruiken als een elastische buildagentinfrastructuur, moet u dat proces niet uitvoeren binnen de grenzen van de gereguleerde workloadruntime. Uw buildagents mogen geen directe toegang hebben tot het cluster. Geef buildagents bijvoorbeeld alleen netwerktoegang tot de Azure Container Registry om containerafbeeldingen, Helm-grafieken, bijvoorbeeld te pushen. Implementeer vervolgens via GitOps. Het is gebruikelijk om werkstromen voor bouwen en vrijgeven rechtstreeks toegang te geven tot uw Kubernetes Cluster-API (of de knooppunten ervan).

Bewakingsbewerkingen

Activiteiten binnen het cluster

De pods binnen omsagent het cluster die worden uitgevoerd in zijn de Agent voor log kube-system analytics-verzamelingen. Ze verzamelen telemetrie, verzamelen container en stdout stderr logboeken en verzamelen metrische Prometheus-gegevens. U kunt de verzamelingsinstellingen ervan afstemmen door het container-azm-ms-agentconfig.yaml bestand ConfigMap bij te werken. In deze referentie-implementatie wordt logboekregistratie ingeschakeld voor kube-system al uw workloads. Is standaard kube-system uitgesloten van logboekregistratie. Zorg ervoor dat u het logboekverzamelingsproces aanpast om een balans te vinden tussen kostendoelstellingen, SRE-efficiëntie bij het controleren van logboeken en nalevingsbehoeften.

Beveiligingsbewaking

Gebruik Azure Security Center om beveiligingsaanbevelingen weer te geven en te herstellen. Bekijk ook beveiligingswaarschuwingen voor uw resources. Schakel Azure Defender toe wanneer deze van toepassing zijn op verschillende onderdelen van de gegevensomgeving van de kaarthouder.

Integreer logboeken zodat u gegevens efficiënt kunt controleren, analyseren en opvragen. Azure biedt verschillende technologieopties. U kunt deze Azure Monitor logboeken naar een Log Analytics-werkruimte te schrijven. Een andere optie is het integreren van gegevens in SIEM-oplossingen (Security Information and Event Management), zoals Azure Sentinel.

Zoals vereist door 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. Zorg ervoor dat de toegang tot gearchiveerde logboekgegevens is onderworpen aan dezelfde toegangsniveaus als recente logboekgegevens.

Zie de Enterprise OnboardingGuide Azure Security Center voor een volledig perspectief. Deze handleiding heeft betrekking op inschrijving, gegevensexports naar uw SIEM-oplossingen, reageren op waarschuwingen en het bouwen van werkstroomautomatisering.

Gerelateerde Azure-services

Hier zijn koppelingen naar de functiedocumentatie van een aantal belangrijke onderdelen van deze architectuur.

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Virtuele Azure-machineschaalsets
• Azure Application Gateway met integrated Web Application Firewall (WAF)
• Azure Container Registry taken
• Azure Key Vault

Volgende

Een firewallconfiguratie installeren en onderhouden om gegevens van kaartaanduidingen te beveiligen. Gebruik geen door de leverancier geleverde standaardwaarden voor systeemwachtwoorden en andere beveiligingsparameters.