Toegangsbeheer van een AKS-basislijncluster voor een PCI-DSS 3.2.1 (deel 6 van 9)

In dit artikel worden de overwegingen beschreven voor een AKS-cluster (Azure Kubernetes Service) dat is geconfigureerd in overeenstemming met de Pci-DSS 3.2.1 (Payment Card Industry Data Security Standard).

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

Kubernetes heeft systeemeigen op rollen gebaseerd toegangsbeheer (RBAC) waarmee machtigingen voor de Kubernetes-API worden beheerd. Er zijn verschillende ingebouwde rollen met specifieke machtigingen of acties voor Kubernetes-resources. Azure Kubernetes Service (AKS) ondersteunt die ingebouwde rollen en aangepaste rollen voor gedetailleerd beheer. Deze acties kunnen worden geautoriseerd (of geweigerd) aan een gebruiker via Kubernetes RBAC.

Deze architectuur en de implementatie zijn niet ontworpen om besturingselementen te bieden voor fysieke toegang tot on-premises resources of datacenters. Een voordeel van het hosten van uw CDE in Azure, in tegenstelling tot uw platform aan de rand of in uw datacenter, is dat het beperken van fysieke toegang meestal al wordt afgehandeld via azure-datacenterbeveiliging. Er zijn geen verantwoordelijkheden voor de organisatie bij het beheer van fysieke hardware.

Krachtige maatregelen voor toegangsbeheer implementeren

Vereiste 7 : de toegang tot gegevens van de kaarthouder beperken door zakelijke behoeften te weten

Ondersteuning voor AKS-functies

AKS is volledig geïntegreerd met Microsoft Entra ID als id-provider.

U hoeft geen afzonderlijke gebruikersidentiteiten en referenties voor Kubernetes te beheren. U kunt Microsoft Entra-gebruikers toevoegen voor Kubernetes RBAC. Met deze integratie kunt u rollen toewijzen aan Microsoft Entra-gebruikers. Met Behulp van Microsoft Entra-identiteiten kunt u verschillende ingebouwde rollen gebruiken, zoals viewer, schrijver, servicebeheerder en clusterbeheerder. U kunt ook aangepaste rollen maken voor gedetailleerdere controle.

Azure RBAC is standaard ingesteld op het weigeren van alle toegang, zodat een resource niet kan worden geopend zonder dat er machtigingen zijn verleend. AKS beperkt SSH-toegang tot AKS-werkknooppunten en maakt gebruik van AKS-netwerkbeleid om de toegang tot workloads in de pods te beheren.

Zie Azure RBAC gebruiken voor Kubernetes-autorisatie en uw cluster beveiligen met Azure Policy voor meer informatie.

Uw verantwoordelijkheden

Vereiste	Verantwoordelijkheid
Vereiste 7.1	Beperk de toegang tot systeemonderdelen en gegevens van kaartaanduidingen tot alleen personen waarvan de taak dergelijke toegang vereist.
Vereiste 7.2	Stel een toegangsbeheersysteem in voor systeemonderdelen die de toegang beperken op basis van de noodzaak van een gebruiker om te weten en is ingesteld op Alles weigeren, tenzij specifiek toegestaan.
Vereiste 7.3	Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beperken van de toegang tot gegevens van de kaarthouder worden gedocumenteerd, gebruikt en bekend bij alle betrokken partijen.

Vereiste 7.1

Beperk de toegang tot systeemonderdelen en gegevens van kaartaanduidingen tot alleen personen waarvan de taak dergelijke toegang vereist.

Uw verantwoordelijkheden

Hier volgen enkele overwegingen:

• Zorg ervoor dat uw implementatie is afgestemd op de vereisten van de organisatie en op nalevingsvereisten voor identiteitsbeheer.
• Minimaliseer permanente machtigingen, met name voor kritieke impactaccounts.
• Volg het principe van toegang met minimale bevoegdheden. Geef net genoeg toegang om de taak te voltooien.

Vereiste 7.1.1

Toegangsbehoeften definiëren voor elke rol, waaronder:

• Systeemonderdelen en gegevensbronnen waartoe elke rol toegang moet hebben voor hun functie
• Vereiste bevoegdheidsniveau (bijvoorbeeld gebruiker, beheerder, enzovoort) voor toegang tot resources.

Uw verantwoordelijkheden

Definieer rollen op basis van de taken en verantwoordelijkheden die nodig zijn voor de onderdelen binnen het bereik en hun interactie met Azure-resources. U kunt beginnen met brede categorieën, zoals:

• Bereik per Azure-beheergroep, -abonnementen of -resourcegroepen
• Azure Policy voor de workload of het abonnement
• Containerbewerkingen
• Geheimenbeheer
• Pijplijnen bouwen en implementeren

Hoewel de definitie van rollen en verantwoordelijkheden rond deze gebieden mogelijk aan uw teamstructuur is gekoppeld, moet u zich richten op de vereiste van de workload. Bepaal bijvoorbeeld wie verantwoordelijk is voor het onderhouden van beveiliging, isolatie, implementatie en waarneembaarheid. Hieronder volgen een aantal voorbeelden:

• Bepaal configuraties voor toepassingsbeveiliging, Kubernetes RBAC, netwerkbeleid, Azure-beleid en communicatie met andere services.
• Configureer en onderhoud Azure Firewall, Web Application Firewall (WAF), netwerkbeveiligingsgroepen (NSG's) en DNS.
• Bewaak en herstel serverbeveiliging, patching, configuratie en eindpuntbeveiliging.
• Stel de richting in voor het gebruik van RBAC, Microsoft Defender voor Cloud, strategie voor beheerdersbeveiliging en Azure Policy om Azure-resources te beheren.
• Identificeer het incidentbewakings- en reactieteam. Onderzoek en herstel beveiligingsincidenten met behulp van een SIEM-systeem (Security Information and Event Management), zoals Microsoft Sentinel of Microsoft Defender voor Cloud.

Formaliseer vervolgens de definitie door te bepalen welk toegangsniveau vereist is voor de rol met betrekking tot de workload en de infrastructuur. Hier volgt een eenvoudige definitie voor illustratieve doeleinden.

Rol	Verantwoordelijkheden	Toegangsniveaus
Eigenaren van toepassingen	Functies definiëren en prioriteren die zijn afgestemd op bedrijfsresultaten. Ze begrijpen hoe functies van invloed zijn op het nalevingsbereik van de workload en hoe de beveiliging en eigendom van klantgegevens worden afgestemd op bedrijfsdoelstellingen.	Lees de toegang tot logboeken en metrische gegevens die door de toepassing worden verzonden. Ze hebben geen machtigingen nodig voor toegang tot de werkbelasting of het cluster.
Toepassingsontwikkelaars	Ontwikkel de toepassing. Alle toepassingscode is onderworpen aan trainings- en kwaliteitspoorten die voldoen aan nalevings-, attestation- en releasebeheerprocessen. Kan de build-pijplijnen beheren, maar meestal niet implementatiepijplijnen.	Leestoegang tot Kubernetes-naamruimten en Azure-resources die binnen het bereik van de workload vallen. Geen schrijftoegang voor het implementeren of wijzigen van een status van het systeem.
Toepassingsoperators (of SRE)	Een goed begrip hebben van de codebasis, waarneembaarheid en bewerkingen. Voer livesite-sortering en probleemoplossing uit. Samen met ontwikkelaars van toepassingen kunt u de beschikbaarheid, schaalbaarheid en prestaties van de toepassing verbeteren. Beheer de implementatiepijplijn 'last-mile' en help de build-pijplijnen te beheren.	Zeer bevoegd binnen het bereik van de toepassing die gerelateerde Kubernetes-naamruimten en Azure-resources bevat. Waarschijnlijk hebben ze toegang tot delen van het Kubernetes-cluster.
Infrastructuureigenaren	Ontwerp een rendabele architectuur, met inbegrip van de connectiviteit en de functionaliteit van onderdelen. Het bereik kan cloud- en on-premises services omvatten. Bepaal mogelijkheden voor gegevensretentie, functies voor bedrijfscontinuïteit en andere.	Toegang tot platformlogboeken en kostenplaatsgegevens. Er is geen toegang vereist binnen het cluster.
Infrastructuuroperators (of SRE)	Bewerkingen met betrekking tot het cluster en afhankelijke services. Bouw, implementeer en bootstrap de pijplijn voor het cluster waarin de workload is geïmplementeerd. Stel doelknooppuntgroepen en de verwachte grootte- en schaalvereisten in. Controleer de status van de containerhostinginfrastructuur en afhankelijke services.	Leestoegang tot workloadnaamruimten. Zeer bevoegde toegang voor het cluster.
Beleid, beveiligingseigenaren	Beveiligings- of regelgevingsexpertise hebben. Definieer beleidsregels die de beveiliging en naleving van regelgeving van de werknemers van het bedrijf, de activa en die van de klanten van het bedrijf beschermen. Werkt met alle andere rollen om ervoor te zorgen dat beleid in elke fase wordt toegepast en gecontroleerd.	Leestoegang tot de workload en het cluster. Ook toegang tot logboek- en controlegegevens.
Netwerkoperators	Toewijzing van bedrijfsbrede virtuele netwerken en subnetten. Configuratie en onderhoud van Azure Firewall, WAF, NSG's en DNS-configuratie.	Zeer bevoegd in de netwerklaag. Er is geen schrijfmachtiging binnen het cluster.

Vereiste 7.1.2

Beperk de toegang tot bevoegde gebruikers-id's tot minimale bevoegdheden die nodig zijn om taakverantwoordelijkheden uit te voeren.

Uw verantwoordelijkheden

Op basis van de taakfuncties streeft u ernaar om de toegang te minimaliseren zonder onderbrekingen te veroorzaken. Hier volgen enkele best practices:

• Beperk de toegang die elke identiteit nodig heeft. Een identiteit moet net voldoende toegang hebben om hun taak te voltooien.
• Minimaliseer permanente machtigingen, met name voor identiteiten met kritieke gevolgen die toegang hebben tot onderdelen binnen het bereik.
• Voeg waar mogelijk extra beperkingen toe. Een manier is om voorwaardelijke toegang te bieden op basis van toegangscriteria.
• Voer regelmatig een controle en controle uit van gebruikers en groepen die toegang hebben in uw abonnementen, zelfs voor leestoegang. Vermijd het uitnodigen van externe identiteiten.

Vereiste 7.1.3

Wijs toegang toe op basis van de functieclassificatie en functie van afzonderlijke medewerkers.

Uw verantwoordelijkheden

Bepaal machtigingen op basis van de duidelijk toegewezen taaktaken van de persoon. Vermijd parameters zoals het systeem of de dienstverband van de werknemer. Toegangsrechten verlenen aan één gebruiker of aan een groep.

Hieronder vindt u enkele voorbeelden.

Taakclassificatie	Role
Een producteigenaar definieert het bereik van de workload en geeft prioriteit aan functies. Hiermee wordt de beveiliging en het eigendom van klantgegevens in balans met bedrijfsdoelstellingen. Heeft toegang nodig tot rapporten, de kostenplaats of Azure-dashboards. Er is geen toegang nodig voor machtigingen op cluster- of clusterniveau.	Eigenaren van toepassingen
Een software-engineer ontwerpt, ontwikkelt en containeriseert de toepassingscode. Een groep met staande leesmachtigingen binnen gedefinieerde bereiken binnen Azure (zoals Application Insights) en de workloadnaamruimten. Deze bereiken en machtigingen kunnen verschillen tussen preproductie- en productieomgevingen.	Toepassingsontwikkelaar
Een sitebetrouwbaarheidstechnicus voert live-site-sortering uit, beheert pijplijnen en stelt de toepassingsinfrastructuur in. Groep A met volledig beheer binnen de toegewezen naamruimten. Permanente machtigingen zijn niet vereist. Groep B voor dagelijkse bewerkingen op de workload. Het kan permanente machtigingen hebben binnen hun toegewezen naamruimten, maar zijn niet zeer bevoegd.	Toepassingsoperators
Een clusteroperator ontwerpt en implementeert een betrouwbaar en beveiligd AKS-cluster op het platform. Verantwoordelijk voor het onderhouden van de up-time van het cluster. Groep A met volledig beheer binnen de toegewezen naamruimten. Permanente machtigingen zijn niet vereist. Groep B voor dagelijkse bewerkingen op de workload. Het kan permanente machtigingen hebben binnen hun toegewezen naamruimten, maar zijn niet zeer bevoegd.	Infrastructuuroperators
Een netwerktechnicus wijst bedrijfsbrede virtuele netwerken en subnetten, on-premises toe aan cloudconnectiviteit en netwerkbeveiliging.	Infrastructuuroperators

Vereiste 7.1.4

Gedocumenteerde goedkeuring vereisen door geautoriseerde partijen die vereiste bevoegdheden opgeven.

Uw verantwoordelijkheden

Een gated-proces hebben voor het goedkeuren van wijzigingen in rollen en machtigingen, inclusief de eerste toewijzing van bevoegdheden. Zorg ervoor dat deze goedkeuringen zijn gedocumenteerd en beschikbaar zijn voor inspectie.

Vereiste 7.2

Stel een toegangsbeheersysteem in voor systeemonderdelen die de toegang beperken op basis van de noodzaak van een gebruiker om te weten en is ingesteld op Alles weigeren, tenzij specifiek toegestaan.

Uw verantwoordelijkheden

Na de volgende vereiste 7.1 moet u rollen en verantwoordelijkheden hebben geëvalueerd die van toepassing zijn op uw organisatie en de workload. Alle onderdelen in de architectuur die binnen het bereik vallen, moeten beperkte toegang hebben. Dit omvat de AKS-knooppunten die de workload, gegevensopslag, netwerktoegang en alle andere services uitvoeren die deelnemen aan het verwerken van de kaarthoudergegevens (CHD).

Wijs op basis van rollen en verantwoordelijkheden rollen toe aan het op rollen gebaseerde toegangsbeheer (RBAC) van de infrastructuur. Dit mechanisme kan het volgende zijn:

• Kubernetes RBAC is een systeemeigen Kubernetes-autorisatiemodel dat de toegang tot het Kubernetes-besturingsvlak beheert, die beschikbaar wordt gesteld via de Kubernetes-API-server. Deze set machtigingen definieert wat u met de API-server kunt doen. U kunt bijvoorbeeld een gebruiker de machtigingen weigeren om pods te maken of zelfs weer te geven.
• Azure RBAC is een op Microsoft Entra ID gebaseerd autorisatiemodel waarmee de toegang tot het Azure-besturingsvlak wordt beheerd. Dit is een koppeling van uw Microsoft Entra-tenant met uw Azure-abonnement. Met Azure RBAC kunt u machtigingen verlenen voor het maken van Azure-resources, zoals netwerken, een AKS-cluster en beheerde identiteiten.

Stel dat u machtigingen moet verlenen aan de clusteroperators (toegewezen aan de rol van de infrastructuuroperator). Alle personen aan wie de verantwoordelijkheden van de infrastructuuroperator zijn toegewezen, behoren tot een Microsoft Entra-groep. Zoals vastgesteld in 7.1.1, vereist deze rol de hoogste bevoegdheid in het cluster. Kubernetes heeft ingebouwde RBAC-rollen, zoals cluster-admin, die aan deze vereisten voldoen. U moet de Microsoft Entra-groep voor de infrastructuuroperator cluster-admin verbinden door rolbindingen te maken. Er zijn twee benaderingen. U kunt de ingebouwde rollen kiezen. Of maak aangepaste rollen voor uw bindingen als de ingebouwde rollen niet voldoen aan uw vereisten (ze kunnen bijvoorbeeld te veel machtigingen hebben).

De referentie-implementatie demonstreert het voorgaande voorbeeld met behulp van systeemeigen Kubernetes RBAC. Dezelfde koppeling kan worden uitgevoerd met Azure RBAC. Zie Toegang tot clusterresources beheren met behulp van op rollen gebaseerd toegangsbeheer van Kubernetes en Microsoft Entra-identiteiten in Azure Kubernetes Service voor meer informatie.

U kunt het machtigingsbereik kiezen op clusterniveau of op naamruimteniveau. Voor rollen met een bereik van verantwoordelijkheden, zoals toepassingsoperators, worden de machtigingen toegewezen op het niveau van de naamruimte voor de workload.

Daarnaast hebben de rollen ook Azure RBAC-machtigingen nodig, zodat ze hun taken kunnen uitvoeren. De clusteroperator moet bijvoorbeeld toegang krijgen tot Azure Monitor via de portal. De rol van de infrastructuuroperator moet dus de juiste RBAC-toewijzing hebben.

Naast personen en hun rollen hebben Azure-resources en zelfs pods binnen het cluster beheerde identiteiten. Deze identiteiten hebben een set machtigingen nodig via Azure RBAC en moeten nauw zijn afgestemd op de verwachte taken. Azure-toepassing Gateway moet bijvoorbeeld machtigingen hebben om geheimen (TLS-certificaten) op te halen uit Azure Key Vault. Het mag geen machtigingen hebben om geheimen te wijzigen.

Hier volgen enkele best practices:

• Onderhoud zorgvuldige documentatie over elke rol en de toegewezen machtigingen, evenals de redenen. Houd duidelijk onderscheid over welke machtigingen JIT zijn en welke staan.

• Bewaak de rollen voor wijzigingen, zoals in toewijzingswijzigingen of roldefinities. Maak waarschuwingen over wijzigingen, zelfs als ze worden verwacht, om inzicht te krijgen in intenties achter de wijzigingen.

Vereiste 7.2.1

Dekking van alle systeemonderdelen

Uw verantwoordelijkheden

Hier volgen enkele aanbevolen procedures voor het onderhouden van metingen voor toegangsbeheer:

• Geen staande toegang. Overweeg het Just-In-Time AD-groepslidmaatschap te gebruiken. Voor deze functie is Microsoft Entra Privileged Identity Management vereist.

• Beleid voor voorwaardelijke toegang instellen in Microsoft Entra-id voor uw cluster. Hierdoor worden de toegang tot het Kubernetes-besturingsvlak verder beperkt. Met beleid voor voorwaardelijke toegang kunt u meervoudige verificatie vereisen, verificatie beperken tot apparaten die worden beheerd door uw Microsoft Entra-tenant of niet-gebruikelijke aanmeldingspogingen blokkeren. Pas deze beleidsregels toe op Microsoft Entra-groepen die zijn toegewezen aan Kubernetes-rollen met hoge bevoegdheden.

  Notitie

  Voor zowel JIT- als voorwaardelijke toegangstechnologie zijn Microsoft Entra ID P1- of P2-licenties vereist.

• SSH-toegang tot de clusterknooppunten idealiter uitschakelen. Met deze referentie-implementatie worden hiervoor geen SSH-verbindingsdetails gegenereerd.

• Eventuele extra berekeningen, zoals jumpboxs, moeten worden geopend door geautoriseerde gebruikers. Maak geen algemene aanmeldingen die beschikbaar zijn voor het hele team.

Vereiste 7.2.2

Toewijzing van bevoegdheden aan personen op basis van taakclassificatie en functie.

Uw verantwoordelijkheden

Op basis van 7.1.3 zijn er veel rollen betrokken bij clusterbewerkingen. Naast de standaardresourcerollen van Azure moet u de mate en het toegangsproces definiëren.

Denk bijvoorbeeld aan de rol van de clusteroperator. Ze moeten een duidelijk gedefinieerd playbook hebben voor clustersorageactiviteiten. Hoe verschilt die toegang van het workloadteam? Afhankelijk van uw organisatie zijn ze mogelijk hetzelfde. Hier volgen enkele punten om rekening mee te houden:

• Hoe moeten ze toegang krijgen tot het cluster?
• Welke bronnen zijn toegestaan voor toegang?
• Welke machtigingen moeten ze hebben op het cluster?
• Wanneer worden deze machtigingen toegewezen?

Zorg ervoor dat de definities worden gedocumenteerd in governancedocumentatie, beleid en trainingsmateriaal rond workloadoperator en clusteroperator.

Vereiste 7.2.3

Standaardinstelling 'deny-all'.

Uw verantwoordelijkheden

Wanneer u de configuratie start, begint u met beleid voor nulvertrouwen. Maak waar nodig uitzonderingen en documenteer ze in detail.

• Kubernetes RBAC implementeert standaard alles weigeren. Overschrijven niet door zeer permissieve clusterrolbindingen toe te voegen die de instelling weigeren omkeren.

• Azure RBAC implementeert ook standaard weigeren . Overschrijven niet door RBAC-toewijzingen toe te voegen die de instelling voor het weigeren van alle instellingen omkeren.

• Alle Azure-services, waaronder Azure Key Vault en Azure Container Registry, weigeren standaard alle machtigingen.

• Alle beheertoegangspunten, zoals een jumpbox, moeten alle toegang in de eerste configuratie weigeren. Alle verhoogde machtigingen moeten expliciet worden gedefinieerd om de regel voor weigeren te overschrijven.

Vereiste 7.3

Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beperken van de toegang tot gegevens van de kaarthouder worden gedocumenteerd, gebruikt en bekend bij alle betrokken partijen.

Uw verantwoordelijkheden

Het is essentieel dat u grondige documentatie over de processen en beleidsregels onderhoudt. Dit omvat Azure- en Kubernetes RBAC-beleid en organisatiebeheerbeleid. Mensen die gereguleerde omgevingen bedienen, moeten worden opgeleid, geïnformeerd en geïncentiveerd om de beveiligingsgaranties te ondersteunen. Dit is met name belangrijk voor mensen die deel uitmaken van het goedkeuringsproces vanuit een beleidsperspectief.

Vereiste 8 : toegang tot systeemonderdelen identificeren en verifiëren

Ondersteuning voor AKS-functies

Vanwege de integratie van AKS en Microsoft Entra kunt u gebruikmaken van mogelijkheden voor identiteitsbeheer en autorisatie, waaronder toegangsbeheer, beheer van id-objecten en andere. Zie AKS-beheerde Microsoft Entra-integratie voor meer informatie.

Uw verantwoordelijkheden

Vereiste	Verantwoordelijkheid
Vereiste 8.1	Definieer en implementeer beleidsregels en procedures om het juiste gebruikersidentificatiebeheer voor niet-consumentengebruikers en beheerders op alle systeemonderdelen als volgt te garanderen:
Vereiste 8.2	Zorg er niet alleen voor dat u een unieke id toewijst, maar ook het juiste beheer van gebruikersverificatie voor niet-consumenten en beheerders voor alle systeemonderdelen door ten minste een van de volgende methoden te gebruiken om alle gebruikers te verifiëren:
Vereiste 8.3	Beveilig alle afzonderlijke niet-consolebeheertoegang en alle externe toegang tot de CDE met behulp van meervoudige verificatie.
Vereiste 8.4	Documenteer en communiceer verificatieprocedures en -beleidsregels en -procedures voor alle gebruikers, waaronder:
Vereiste 8,5	Gebruik als volgt geen groeps-, gedeelde of algemene id's, wachtwoorden of andere verificatiemethoden:
Vereiste 8.6	Wanneer andere verificatiemechanismen worden gebruikt (bijvoorbeeld fysieke of logische beveiligingstokens, smartcards, certificaten, enzovoort), moet het gebruik van deze mechanismen als volgt worden toegewezen:
Vereiste 8.7	Alle toegang tot een database met gegevens van kaartaanduidingen (inclusief toegang door toepassingen, beheerders en alle andere gebruikers) wordt als volgt beperkt:
Vereiste 8.8	Zorg ervoor dat beveiligingsbeleid en operationele procedures voor identificatie en verificatie worden gedocumenteerd, gebruikt en bekend bij alle betrokken partijen.

Vereiste 8.1

Definieer en implementeer beleidsregels en procedures om het juiste gebruikersidentificatiebeheer voor niet-consumentengebruikers en beheerders op alle systeemonderdelen als volgt te garanderen:

• 8.1.1 Wijs alle gebruikers een unieke id toe voordat ze toegang hebben tot systeemonderdelen of gegevens van kaartaanduidingen.
• 8.1.2 Besturingselementen toevoegen, verwijderen en wijzigen van gebruikers-id's, referenties en andere id-objecten.
• 8.1.3 Onmiddellijk de toegang intrekken voor beëindigde gebruikers.
• 8.1.4 Inactieve gebruikersaccounts verwijderen/uitschakelen binnen 90 dagen.
• 8.1.5 Beheer id's die door derden worden gebruikt voor toegang, ondersteuning of onderhoud van systeemonderdelen via externe toegang als volgt:
  • Alleen ingeschakeld tijdens de benodigde tijdsperiode en uitgeschakeld wanneer deze niet in gebruik is.
  • Bewaakt wanneer deze wordt gebruikt.
• 8.1.6 Beperk herhaalde toegangspogingen door de gebruikers-id na niet meer dan zes pogingen te vergrendelen.
• 8.1.7 Stel de vergrendelingsduur in op minimaal 30 minuten of totdat een beheerder de gebruikers-id inschakelt.
• 8.1.8 Als een sessie langer dan 15 minuten inactief is geweest, moet de gebruiker zich opnieuw verifiëren om de terminal of sessie opnieuw te activeren.

Uw verantwoordelijkheden

Hier volgen algemene overwegingen voor deze vereiste:

VAN TOEPASSING OP: 8.1.1, 8.1.2, 8.1.3

Deel of hergebruik geen identiteiten voor functioneel verschillende onderdelen van de CDE. Gebruik bijvoorbeeld geen teamaccount voor toegang tot gegevens of clusterbronnen. Zorg ervoor dat de identiteitsdocumentatie duidelijk is over het niet gebruiken van gedeelde accounts.

Breid deze identiteitsprincipaal uit naar beheerde identiteitstoewijzingen in Azure. Deel door de gebruiker beheerde identiteiten niet tussen Azure-resources. Wijs elke Azure-resource een eigen beheerde identiteit toe. Als u Microsoft Entra Workload-ID gebruikt in het AKS-cluster, moet u er ook voor zorgen dat elk onderdeel in uw workload een eigen identiteit ontvangt in plaats van een identiteit te gebruiken die breed is binnen het bereik. Deel nooit dezelfde beheerde identiteit tussen productie- en niet-productieomgevingen.

Meer informatie over toegangs- en identiteitsopties voor Azure Kubernetes Service (AKS).

VAN TOEPASSING OP: 8.1.2, 8.1.3, 8.1.4

Gebruik Microsoft Entra-id als identiteitsarchief. Omdat het cluster en alle Azure-resources Microsoft Entra ID gebruiken, is het automatisch uitschakelen of intrekken van de toegang van een principal van toepassing op alle resources. Als er onderdelen zijn die niet rechtstreeks worden ondersteund door Microsoft Entra ID, moet u ervoor zorgen dat u een proces hebt om de toegang te verwijderen. SSH-referenties voor toegang tot een jumpbox moeten bijvoorbeeld expliciet worden verwijderd als de gebruiker niet meer geldig is.

VAN TOEPASSING OP: 8.1.5

Profiteer van Microsoft Entra Externe ID die is ontworpen voor het hosten van B2B-accounts (business-to-business) van derden, zoals leveranciers en partners, als gastgebruikers. Verdeel het juiste toegangsniveau met behulp van voorwaardelijk beleid om bedrijfsgegevens te beveiligen. Deze accounts moeten minimale permanente machtigingen en verplichte vervaldatums hebben. Zie B2B-samenwerking met externe gasten voor uw medewerkers voor meer informatie.

Uw organisatie moet een duidelijk en gedocumenteerd patroon van leverancier en vergelijkbare toegang hebben.

VAN TOEPASSING OP: 8.1.6, 8.1.7, 8.1.8

Uw verantwoordelijkheden

Microsoft Entra ID biedt een slimme vergrendelingsfunctie om gebruikers te vergrendelen na mislukte aanmeldingspogingen. De aanbevolen manier om vergrendelingen te implementeren, is met beleid voor voorwaardelijke toegang van Microsoft Entra.

Implementeer de vergrendeling voor onderdelen die vergelijkbare functies ondersteunen, maar die niet worden ondersteund met Microsoft Entra-id (bijvoorbeeld machines met SSH-functionaliteit, zoals een jumpbox). Dit zorgt ervoor dat vergrendelingen zijn ingeschakeld om misbruik van toegang te voorkomen of te vertragen.

AKS-knooppunten zijn niet ontworpen om regelmatig te worden geopend. Directe SSH- of Extern bureaublad-toegang tot clusterknooppunten blokkeren. SSH-toegang moet alleen worden beschouwd als onderdeel van geavanceerde probleemoplossingsinspanningen. De toegang moet nauwkeurig worden bewaakt en onmiddellijk worden teruggedraaid na voltooiing van de specifieke gebeurtenis. Als u dit doet, moet u er rekening mee houden dat wijzigingen op knooppuntniveau ervoor kunnen zorgen dat uw cluster niet meer wordt ondersteund.

Vereiste 8.2

Zorg er niet alleen voor dat u een unieke id toewijst, maar ook voor het juiste beheer van gebruikersverificatie voor niet-consumentengebruikers en beheerders op alle systeemonderdelen door ten minste een van de volgende methoden te gebruiken om alle gebruikers te verifiëren: Iets wat u weet, zoals een wachtwoord of wachtwoordzin, iets dat u hebt, zoals een tokenapparaat of smartcard, iets wat u bent, zoals een biometrische gegevens.

• 8.2.1 Met sterke cryptografie worden alle verificatiereferenties (zoals wachtwoorden/woordgroepen) onleesbaar weergegeven tijdens verzending en opslag op alle systeemonderdelen.
• 8.2.2 Controleer de gebruikersidentiteit voordat u een verificatiereferentie wijzigt, bijvoorbeeld het opnieuw instellen van wachtwoorden, het inrichten van nieuwe tokens of het genereren van nieuwe sleutels.
• 8.2.3 Wachtwoorden/woordgroepen moeten aan het volgende voldoen:
  • Een minimale lengte van ten minste zeven tekens vereisen.
  • Bevatten zowel numerieke als alfabetische tekens.
• 8.2.4 Gebruikerswachtwoorden/wachtwoordzinnen ten minste één keer per 90 dagen wijzigen.
• 8.2.5 Staat een persoon niet toe een nieuw wachtwoord of een nieuwe woordgroep in te dienen die gelijk is aan een van de laatste vier wachtwoorden/woordgroepen die hij of zij heeft gebruikt.
• 8.2.6 Stel wachtwoorden/woordgroepen in voor het eerste gebruik en stel bij het opnieuw instellen van een unieke waarde voor elke gebruiker een unieke waarde in en wijzig onmiddellijk na het eerste gebruik.

Uw verantwoordelijkheden

Beleid voor voorwaardelijke toegang instellen in Microsoft Entra-id voor uw cluster. Hierdoor worden de toegang tot het Kubernetes-besturingsvlak verder beperkt.

Verschillende van de voorgaande set vereisten worden automatisch verwerkt door Microsoft Entra-id. Hieronder volgen een aantal voorbeelden:

• Wachtwoordbeveiliging

  Microsoft Entra ID biedt functies die het gebruik van sterke wachtwoorden afdwingen. Zwakke wachtwoorden die deel uitmaken van de algemene lijst met verboden wachtwoorden, worden bijvoorbeeld geblokkeerd. Dit is onvoldoende bescherming. Als u een organisatiespecifieke verbodslijst wilt maken, kunt u overwegen de functie Microsoft Entra-wachtwoordbeveiliging toe te voegen. Er wordt standaard een wachtwoordbeleid toegepast. Bepaalde beleidsregels kunnen niet worden gewijzigd en hebben betrekking op een deel van de voorgaande set vereisten. Dit zijn onder andere het verlopen van wachtwoorden en toegestane tekens. Zie Wachtwoordbeleid voor Microsoft Entra voor de volledige lijst. Overweeg geavanceerde afdwinging door gebruik te maken van beleid voor voorwaardelijke toegang, zoals beleidsregels op basis van gebruikersrisico's, waarmee gelekte gebruikersnaam- en wachtwoordparen worden gedetecteerd. Zie Voorwaardelijke toegang: Voorwaardelijke toegang op basis van gebruikersrisico's voor meer informatie.

  Notitie

  We raden u ten zeerste aan om opties zonder wachtwoord te overwegen. Zie Een implementatie van verificatie zonder wachtwoord plannen in Microsoft Entra-id voor meer informatie.

• Verificatie van gebruikersidentiteit

  U kunt het beleid voor voorwaardelijke toegang voor aanmeldingsrisico's toepassen om te detecteren of de verificatieaanvraag is uitgegeven door de aangevraagde identiteit. De aanvraag wordt gevalideerd op basis van bedreigingsinformatiebronnen. Dit zijn onder andere afwijkingen in wachtwoordspray en IP-adres. Zie Voorwaardelijke toegang: Op risico gebaseerde voorwaardelijke toegang aanmelden voor meer informatie.

Mogelijk hebt u onderdelen die geen Microsoft Entra-id gebruiken, zoals toegang tot jumpboxs met SSH. Gebruik voor dergelijke gevallen openbare-sleutelversleuteling met ten minste RSA 2048-sleutelgrootte. Geef altijd een wachtwoordzin op. Een validatieproces hebben waarmee bekende goedgekeurde openbare sleutels worden bijgehouden. Systemen die openbare-sleuteltoegang gebruiken, mogen niet worden blootgesteld aan internet. In plaats daarvan mag alle SSH-toegang alleen worden toegestaan via een intermediair, zoals Azure Bastion, om de impact van een lek met een persoonlijke sleutel te verminderen. Directe wachtwoordtoegang uitschakelen en een alternatieve oplossing zonder wachtwoord gebruiken.

Vereiste 8.3

Beveilig alle afzonderlijke niet-consolebeheertoegang en alle externe toegang tot de CDE met behulp van meervoudige verificatie. Opmerking: Meervoudige verificatie vereist dat minimaal twee van de drie verificatiemethoden (zie Vereiste 8.2 voor beschrijvingen van verificatiemethoden) worden gebruikt voor verificatie. Het gebruik van één factor twee keer (bijvoorbeeld het gebruik van twee afzonderlijke wachtwoorden) wordt niet beschouwd als meervoudige verificatie.

Uw verantwoordelijkheden

Gebruik beleid voor voorwaardelijke toegang om meervoudige verificatie af te dwingen, met name voor beheerdersaccounts. Deze beleidsregels worden aanbevolen voor verschillende ingebouwde rollen. Pas deze beleidsregels toe op Microsoft Entra-groepen die zijn toegewezen aan Kubernetes-rollen met hoge bevoegdheden.

Dit beleid kan verder worden beperkt met aanvullende beleidsregels. Hieronder volgen een aantal voorbeelden:

• U kunt verificatie beperken tot apparaten die worden beheerd door uw Microsoft Entra-tenant.
• Als de toegang afkomstig is van een netwerk buiten het clusternetwerk, kunt u meervoudige verificatie afdwingen.

Zie voor meer informatie:

• Voorwaardelijke toegang: MFA vereisen voor beheerders
• Voorwaardelijke toegang: Compatibele apparaten vereisen
• Voorwaardelijke toegang: meervoudige verificatie op basis van aanmeldingsrisico's

Vereiste 8.4

Documenteer en communiceer verificatieprocedures en -beleidsregels en -procedures voor alle gebruikers, waaronder:

• Richtlijnen voor het selecteren van sterke verificatiereferenties
• Richtlijnen voor hoe gebruikers hun verificatiereferenties moeten beveiligen
• Instructies voor het niet opnieuw gebruiken van eerder gebruikte wachtwoorden
• Instructies voor het wijzigen van wachtwoorden als er vermoedens zijn dat het wachtwoord kan worden aangetast.

Uw verantwoordelijkheden

Documentatie over het afgedwongen beleid onderhouden. Als onderdeel van de training voor onboarding van uw identiteit biedt u richtlijnen voor procedures voor het opnieuw instellen van wachtwoorden en aanbevolen procedures voor de organisatie voor het beveiligen van assets.

Vereiste 8,5

Gebruik als volgt geen groeps-, gedeelde of algemene id's, wachtwoorden of andere verificatiemethoden:

• Algemene gebruikers-id's worden uitgeschakeld of verwijderd.
• Gedeelde gebruikers-id's bestaan niet voor systeembeheer en andere kritieke functies.
• Gedeelde en algemene gebruikers-id's worden niet gebruikt om systeemonderdelen te beheren.

Uw verantwoordelijkheden

Deel of hergebruik geen identiteiten voor functioneel verschillende onderdelen van het cluster of pods. Gebruik bijvoorbeeld geen teamaccount voor toegang tot gegevens of clusterbronnen. Zorg ervoor dat de identiteitsdocumentatie duidelijk is over het niet gebruiken van gedeelde accounts.

Hoofdgebruikers uitschakelen in de CDE. Schakel het gebruik van lokale Kubernetes-accounts uit, zodat gebruikers de ingebouwde --admin toegang tot clusters in de CDE niet kunnen gebruiken.

Vereiste 8.6

Wanneer andere verificatiemechanismen worden gebruikt (bijvoorbeeld fysieke of logische beveiligingstokens, smartcards, certificaten, enzovoort), moet het gebruik van deze mechanismen als volgt worden toegewezen:

• Verificatiemechanismen moeten worden toegewezen aan een afzonderlijk account en niet worden gedeeld tussen meerdere accounts.
• Fysieke en/of logische besturingselementen moeten aanwezig zijn om ervoor te zorgen dat alleen het beoogde account dat mechanisme kan gebruiken om toegang te krijgen.

Uw verantwoordelijkheden

Zorg ervoor dat alle toegang tot de CDE wordt verstrekt voor identiteiten per gebruiker en dit wordt uitgebreid tot fysieke of virtuele tokens. Dit omvat vpn-toegang tot het CDE-netwerk, zodat punt-naar-site-toegang (indien aanwezig) per gebruiker certificaten per gebruiker gebruikt als onderdeel van die verificatiestroom.

Vereiste 8.7

Alle toegang tot een database met gegevens van kaartaanduidingen (inclusief toegang door toepassingen, beheerders en alle andere gebruikers) wordt als volgt beperkt:

• Alle gebruikerstoegang tot, gebruikersquery's van en gebruikersacties op databases zijn via programmatische methoden.
• Alleen databasebeheerders hebben de mogelijkheid om rechtstreeks toegang te krijgen tot of query's uit te voeren op databases.
• Toepassings-id's voor databasetoepassingen kunnen alleen worden gebruikt door de toepassingen (en niet door afzonderlijke gebruikers of andere niet-toepassingsprocessen).

Uw verantwoordelijkheden

Toegang bieden op basis van rollen en verantwoordelijkheden. Personen kunnen hun identiteit gebruiken, maar de toegang moet op basis van noodzaak tot kennis worden beperkt, met minimale permanente machtigingen. Personen mogen nooit toepassingsidentiteiten gebruiken en databasetoegangsidentiteiten mogen nooit worden gedeeld.

Toegang tot databases vanuit toepassingen via een beheerde identiteit, indien mogelijk. Anders beperkt u de blootstelling aan verbindingsreeks s en referenties. Gebruik Kubernetes-geheimen om gevoelige informatie op te slaan in plaats van ze te bewaren waar ze gemakkelijk kunnen worden gedetecteerd, zoals een poddefinitie. Een andere manier is het opslaan en laden van geheimen naar en van een beheerd archief dat is ontworpen voor beveiligde gegevens, zoals Azure Key Vault. Als beheerde identiteiten zijn ingeschakeld op een AKS-cluster, moet het zich verifiëren bij Key Vault om toegang te krijgen.

Vereiste 8.8

Zorg ervoor dat beveiligingsbeleid en operationele procedures voor identificatie en verificatie worden gedocumenteerd, gebruikt en bekend bij alle betrokken partijen.

Uw verantwoordelijkheden

Het is essentieel dat u grondige documentatie over de processen en beleidsregels onderhoudt. Documentatie over het afgedwongen beleid onderhouden. Als onderdeel van de training voor onboarding van uw identiteit biedt u richtlijnen voor procedures voor het opnieuw instellen van wachtwoorden en aanbevolen procedures voor de organisatie voor het beveiligen van assets. Mensen die gereguleerde omgevingen bedienen, moeten worden opgeleid, geïnformeerd en geïncentiveerd om de beveiligingsgaranties te ondersteunen. Dit is met name belangrijk voor mensen die deel uitmaken van het goedkeuringsproces vanuit een beleidsperspectief.

Vereiste 9 — Fysieke toegang tot kaartaanduidingsgegevens beperken

Ondersteuning voor AKS-functies

Er zijn geen toepasselijke AKS-functies voor deze vereiste.

Uw verantwoordelijkheden

Deze architectuur en de implementatie zijn niet ontworpen om besturingselementen te bieden voor fysieke toegang tot on-premises resources of datacenters. Raadpleeg voor overwegingen de richtlijnen in de officiële PCI-DSS 3.2.1-standaard.

Hier volgen enkele suggesties voor het toepassen van technische controles:

• Stem sessietime-outs af in elke toegang tot de beheerconsole, zoals jumpboxen in de CDE, om de toegang te minimaliseren.

• Pas het beleid voor voorwaardelijke toegang af om de TTL op Azure-toegangstokens te minimaliseren vanaf toegangspunten, zoals Azure Portal. Raadpleeg de volgende artikelen voor meer informatie:

  • Beleid voor levensduur van adaptieve sessies configureren
  • Configureerbare levensduur van tokens op het Microsoft-identiteitsplatform

• Voor CDE die in de cloud wordt gehost, zijn er geen verantwoordelijkheden voor het beheren van fysieke toegang en hardware. Vertrouw op fysieke en logische besturingselementen voor bedrijfsnetwerk.

• Minimaliseer het exporteren van CHD-back-ups naar on-premises bestemmingen. Gebruik oplossingen die worden gehost in Azure om fysieke toegang tot back-ups te beperken.

• Minimaliseer back-ups naar on-premises. Als dit vereist is, moet u er rekening mee houden dat de on-premises bestemming binnen het bereik van controle valt.

Volgende stappen

Houd alle toegang tot netwerkbronnen en kaartaanduidingsgegevens bij en bewaak deze. Test regelmatig beveiligingssystemen en -processen.