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 Azure Kubernetes Service-cluster (AKS) dat is geconfigureerd in overeenstemming met de Payment Card Industry Data Security Standard (PCI-DSS 3.2.1).

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

Kubernetes heeft op rollen gebaseerd toegangsbeheer (RBAC) dat machtigingen voor de Kubernetes-API beheert. Er zijn verschillende ingebouwde rollen met specifieke machtigingen of acties voor Kubernetes-resources. Azure Kubernetes Service (AKS) ondersteunt deze ingebouwde rollen en aangepaste rollen voor gedetailleerde controle. 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 grotendeels al wordt afgehandeld via de beveiliging van azure-datacenters. 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 kaartaanduidingen beperken op bedrijfsinformatie

Ondersteuning voor AKS-functies

AKS is volledig geïntegreerd met Azure Active Directory (Azure AD) als id-provider.

U hoeft geen afzonderlijke gebruikersidentiteiten en -referenties voor Kubernetes te beheren. U kunt Azure AD-gebruikers toevoegen voor Kubernetes RBAC. Dankzij deze integratie kunt u roltoewijzingen uitvoeren voor Azure AD-gebruikers. Azure AD RBAC ondersteunt roldefinities, zoals viewer, schrijver, servicebeheerder en clusterbeheerder als ingebouwde rollen. U kunt ook aangepaste rollen maken voor gedetailleerdere controle.

Azure RBAC is standaard ingesteld op alles weigeren, zodat een resource niet toegankelijk is zonder machtigingen. AKS beperkt SSH-toegang tot AKS-werkknooppunten en gebruikt AKS-netwerkbeleid om de toegang tot werkbelastingen in de pods te controleren.

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

Uw verantwoordelijkheden

Vereiste	Verantwoordelijkheid
Vereiste 7.1	Beperk de toegang tot systeemonderdelen en gegevens van kaartaanduidingen tot alleen de personen voor wie deze toegang is vereist.
Vereiste 7.2	Stel een toegangsbeheersysteem in voor systeemonderdelen die de toegang beperken op basis van de behoefte van een gebruiker en die is ingesteld op alles weigeren, tenzij dit specifiek is toegestaan.
Vereiste 7.3	Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beperken van de toegang tot gegevens van kaartaanduidingen worden gedocumenteerd, in gebruik zijn en bekend zijn bij alle betrokken partijen.

Vereiste 8 — Toegang tot systeemonderdelen identificeren en verifiëren

Ondersteuning voor AKS-functies

Vanwege AKS- en Azure AD-integratie kunt u gebruikmaken van mogelijkheden voor id-beheer en autorisatie, waaronder toegangsbeheer, beheer van id-objecten en andere. Zie integratie van met AKS beheerde Azure Active Directory voor meer informatie.

Uw verantwoordelijkheden

Vereiste	Verantwoordelijkheid
Vereiste 8.1	Definieer en implementeert beleidsregels en procedures om als volgt te zorgen voor een correct beheer van gebruikersidentificatie voor niet-consumentengebruikers en beheerders op alle systeemonderdelen:
Vereiste 8.2	Naast het toewijzen van een unieke id, moet u ervoor zorgen dat niet-consumentengebruikers en beheerders op alle systeemonderdelen het juiste beheer van gebruikersverificatie hebben door ten minste een van de volgende methoden te gebruiken om alle gebruikers te verifiëren:
Vereiste 8.3	Beveilig alle afzonderlijke beheerderstoegang buiten de console en alle externe toegang tot de CDE met meervoudige verificatie.
Vereiste 8.4	Documenteren en communiceren van verificatieprocedures en -beleidsregels en -procedures aan alle gebruikers, waaronder:
Vereiste 8.5	Gebruik als volgt geen groeps-, gedeelde of algemene ID's, wachtwoorden of andere verificatiemethoden:
Vereiste 8.6	Als er 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 kaartgegevens (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, in gebruik zijn en bekend zijn bij alle betrokken partijen.

Vereiste 9 — Fysieke toegang tot kaarthoudergegevens beperken

Vereiste 7.1

Beperk de toegang tot systeemonderdelen en gegevens van kaartaanduidingen tot alleen de personen voor wie deze toegang is vereist.

Uw verantwoordelijkheden

Hier zijn enkele overwegingen:

• Zorg ervoor dat uw implementatie is afgestemd op de vereisten van de organisatie en voldoet aan de nalevingsvereisten voor identiteitsbeheer.
• Minimaliseren van permanente machtigingen met name voor accounts met kritieke gevolgen.
• Volg het principe van toegang met de minste bevoegdheden. Geef net voldoende toegang om de taak te voltooien.

Vereiste 7.1.1

Definieer de toegangsbehoeften voor elke rol, waaronder:

• Systeemonderdelen en gegevensbronnen die elke rol nodig heeft om toegang te krijgen tot hun functie
• Het vereiste bevoegdheidsniveau (bijvoorbeeld gebruiker, beheerder, enzovoort) voor toegang tot resources.

Uw verantwoordelijkheden

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

• Bereik per Azure-beheergroepen, -abonnementen of -resourcegroepen
• Azure Policy voor de workload of het abonnement
• Containerbewerkingen
• Geheimenbeheer
• Build- en implementatiepijplijnen

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

• Beslissingen over toepassingsbeveiliging, Kubernetes RBAC, netwerkbeleid, Azure-beleid en communicatie met andere services.
• Configuratie en onderhoud van Azure Firewall, Web Application Firewall (WAF), netwerkbeveiligingsgroepen (NSG's) en DNS-configuratie.
• Serverbeveiliging, patching, configuratie en eindpuntbeveiliging bewaken en herstellen.
• Stel de richting in voor het gebruik van RBAC, Azure Security Center, beveiligingsstrategie voor beheerders en Azure Policy om Azure-resources te beheren.
• Incidentbewaking en responsteam. Beveiligingsincidenten onderzoeken en herstellen in SIEM (Security Information and Event Management) of Azure Security Center.

Vervolgens formaliseert u de definitie door te bepalen welk toegangsniveau vereist is voor de rol met betrekking tot de workload en de infrastructuur. Hier is een eenvoudige definitie voor illustratieve doeleinden.

Rol	Verantwoordelijkheden	Toegangsniveaus
Toepassingseigenaren	Functies definiëren en prioriteren die zijn afgestemd op bedrijfsresultaten. Ze begrijpen hoe functies van invloed zijn op het bereik van de naleving van de workload en zorgen voor een goede balans tussen klantgegevensbescherming en eigendom met bedrijfsdoelstellingen.	Leestoegang tot logboeken en metrische gegevens die door de toepassing worden uitgezonden. Ze hebben geen machtigingen nodig voor toegang tot de workload of het cluster.
Toepassingsontwikkelaars	Ontwikkel de toepassing. Alle toepassingscode is onderhevig aan trainings- en kwaliteitspoorten die nalevings-, attestation- en releasebeheerprocessen handhaven. Kan de build-pijplijnen beheren, maar meestal geen 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)	Hebt u een diepgaand inzicht in de codebasis, waarneembaarheid en bewerkingen. Een live-site-triage en probleemoplossing. Samen met toepassingsontwikkelaars verbetert u de beschikbaarheid, schaalbaarheid en prestaties van de toepassing. Beheer de implementatiepijplijn 'last-mijl' en help bij het beheren van de build-pijplijnen.	Met hoge bevoegdheden binnen het bereik van de toepassing met gerelateerde Kubernetes-naamruimten en Azure-resources. Waarschijnlijk permanente toegang hebben tot onderdelen van het Kubernetes-cluster.
Infrastructuureigenaren	Ontwerp een kosteneffectieve architectuur, inclusief 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 start de pijplijn op voor het cluster waarin de workload is geïmplementeerd. Stel doelen in voor knooppuntgroepen en verwachte vereisten voor de omvang en schaal. Controleer de status van de infrastructuur voor containerhosting en afhankelijke services.	Leestoegang tot workloadnaamruimten. Toegang met hoge bevoegdheden voor het cluster.
Beleid, beveiligingseigenaren	Ervaring met naleving op het gebied van beveiliging of regelgeving. 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 het beleid in elke fase wordt toegepast en gecontroleerd.	Leestoegang tot de workload en het cluster. Ook toegang tot logboek- en controlegegevens.
Netwerkoperators	Toewijzing van bedrijfsbreed virtueel netwerk en subnetten. Configuratie en onderhoud van Azure Firewall, WAF, NSG's en DNS-configuratie.	Met hoge bevoegdheden in de netwerklaag. Er is geen schrijfmachtiging binnen het cluster.

Vereiste 7.1.2

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

Uw verantwoordelijkheden

Probeer op basis van de taakfuncties de toegang te minimaliseren zonder onderbrekingen te veroorzaken. Hier volgen enkele best practices:

• De identiteit moet net voldoende toegang hebben om een taak te voltooien.
• Minimaliseer permanente machtigingen, met name voor identiteiten met een kritieke impact die toegang hebben tot onderdelen binnen het bereik.
• Voeg waar mogelijk extra beperkingen toe. Eén manier is om voorwaardelijke toegang te bieden op basis van toegangscriteria.
• Regelmatig controleren en controleren van gebruikers en groepen die toegang hebben tot 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

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

Hier volgen enkele voorbeelden.

Taakclassificatie	Rol
Een producteigenaar definieert het bereik van de workload en geeft prioriteit aan functies. Balans tussen gegevensbescherming van klanten en eigendom met bedrijfsdoelstellingen. Moet toegang hebben tot rapporten, de kostenplaats of Azure-dashboards. Er is geen toegang nodig voor machtigingen op cluster- of clusterniveau.	Toepassingseigenaren
Een softwaretechnicus ontwerpt, ontwikkelt en containeriseert de toepassingscode. Een groep met permanente leesmachtigingen binnen gedefinieerde scopes binnen Azure (zoals Application Insights) en de naamruimten van de workload. Deze scopes en machtigingen kunnen verschillen tussen preproductie- en productieomgevingen.	Toepassingsontwikkelaar
Een sitebetrouwbaarheidstechnicus doet live site triage, beheert pijplijnen en stelt een toepassingsinfrastructuur in. Groep A met volledig beheer binnen de toegewezen naamruimte(en). Permanente machtigingen zijn niet vereist. Groep B voor dagelijkse bewerkingen op de workload. Het kan permanente machtigingen hebben binnen de toegewezen naamruimten, maar heeft geen hoge bevoegdheden.	Toepassingsoperators
Een clusteroperator ontwerpt en implementeert een betrouwbaar en veilig AKS-cluster op het platform. Verantwoordelijk voor het onderhouden van de up time van het cluster. Groep A met volledig beheer binnen de toegewezen naamruimte(en). Permanente machtigingen zijn niet vereist. Groep B voor dagelijkse bewerkingen op de workload. Het kan permanente machtigingen hebben binnen de toegewezen naamruimten, maar heeft geen hoge bevoegdheden.	Infrastructuuroperators
Een netwerktechnicus wijst bedrijfsbrede virtuele netwerken en subnetten toe, on-premises aan cloudconnectiviteit en netwerkbeveiliging.	Infrastructuuroperators

Vereiste 7.1.4

Vereist gedocumenteerde goedkeuring door geautoriseerde partijen die vereiste bevoegdheden opgeven.

Uw verantwoordelijkheden

Een gated proces hebben voor het goedkeuren van wijzigingen in rollen en machtigingen, met inbegrip van 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 behoefte van een gebruiker om dit te weten en is ingesteld op Alles weigeren, tenzij dit specifiek is toegestaan.

Uw verantwoordelijkheden

Nadat u Vereiste 7.1 hebt voldaan,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 werkbelasting, gegevensopslag, netwerktoegang en alle andere services uitvoeren die deelnemen aan de verwerking van de gegevens van de kaarthouder (CHD).

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

• Kubernetes RBAC is een native Kubernetes-autorisatiemodel dat de toegang tot het Kubernetes-besturingsvlak beheert, dat beschikbaar wordt gemaakt via de Kubernetes API-server. Deze set machtigingen definieert wat u met de API-server kunt doen. U kunt een gebruiker bijvoorbeeld de machtigingen weigeren om pods te maken of zelfs weer te geven.
• Azure RBAC is een op Azure AD gebaseerd autorisatiemodel dat de toegang tot het Azure-besturingsvlak beheert. Dit is een associatie van uw Azure AD-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 (aan de rol van infrastructuuroperator). Alle personen aan wie de verantwoordelijkheden van de infrastructuuroperator zijn toegewezen, behoren tot een Azure AD-groep. Zoals ingesteld 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 Azure AD-groep voor infrastructuuroperator binden aan door cluster-admin rolbindingen te maken. Er zijn twee benaderingen. U kunt de ingebouwde rollen kiezen. Of als de ingebouwde rollen niet voldoen aan uw vereisten (ze kunnen bijvoorbeeld te ruim worden gebruikt), maakt u aangepaste rollen voor uw bindingen.

In de referentie-implementatie wordt het voorgaande voorbeeld gedemonstreerd met behulp van native Kubernetes RBAC. Dezelfde associatie kan worden bereikt met Azure RBAC. Zie Toegang tot clusterresources beheren met op kubernetes-rollen gebaseerd toegangsbeheeren identiteiten Azure Active Directory in Azure Kubernetes Service.

U kunt het machtigingsbereik op clusterniveau of op naamruimteniveau kiezen. Voor rollen met bereikverantwoordelijkheden, zoals toepassingsoperators, worden de machtigingen toegewezen op naamruimteniveau voor de workload.

Daarnaast hebben de rollen ook Azure RBAC-machtigingen nodig, zodat ze hun taken kunnen uitvoeren. De clusteroperator moet bijvoorbeeld toegang hebben tot Azure Monitor via de portal. De rol van 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 worden beperkt op basis van de verwachte taken. Zo moeten Azure Application Gateway 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 de documentatie over elke rol en de toegewezen machtigingen. Houd duidelijk onderscheid over welke machtigingen JIT zijn en welke er al staan.

• Controleer de rollen op wijzigingen, zoals in toewijzingswijzigingen of roldefinities. Maak waarschuwingen over wijzigingen, zelfs als wordt verwacht dat ze inzicht krijgen in de intenties achter de wijzigingen.

Vereiste 7.2.1

Dekking van alle systeemonderdelen

Uw verantwoordelijkheden

Hier volgen enkele best practices voor het onderhouden van metingen voor toegangsbeheer:

• Ik heb geen permanente toegang. Overweeg het gebruik van Just-In-Time AD-groepslidmaatschap. Voor deze functie zijn Azure AD-Privileged Identity Management.

• Stel beleid voor voorwaardelijke toegang in Azure AD in voor uw cluster. Hiermee worden ook beperkingen voor toegang tot het Kubernetes-besturingsvlak opgelegd. Met beleid voor voorwaardelijke toegang kunt u meervoudige verificatie vereisen, verificatie beperken tot apparaten die worden beheerd door uw Azure AD-tenant of niet-gebruikelijke aanmeldingspogingen blokkeren. Pas deze beleidsregels toe op Azure AD-groepen die zijn toewijzen aan Kubernetes-rollen met hoge bevoegdheden.

  Notitie

  Voor zowel JIT- als voorwaardelijke toegangstechnologie is een Azure AD Premium.

• Schakel in het ideale moment SSH-toegang tot de clusterknooppunten uit. Deze referentie-implementatie genereert geen SSH-verbindingsgegevens voor dat doel.

• Eventuele extra berekeningen, zoals jumpboxs, moeten worden gebruikt door gemachtigde 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 standaard Azure-resourcerollen moet u de mate en het toegangsproces definiëren.

Neem bijvoorbeeld de rol van clusteroperator. Ze moeten een duidelijk gedefinieerd playbook hebben voor clusters triage-activiteiten. Hoe anders is die toegang van het workloadteam? Afhankelijk van uw organisatie kunnen ze hetzelfde zijn. Hier zijn 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 voor het cluster?
• Wanneer worden deze machtigingen toegewezen?

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

Vereiste 7.2.3

Standaardinstelling voor alles weigeren.

Uw verantwoordelijkheden

Wanneer u de configuratie start, begint u met zero-trust-beleid. Maak zo nodig uitzonderingen en documenteren deze in detail.

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

• Azure RBAC implementeert ook standaard alles weigeren. Overschrijven niet door RBAC-toewijzingen toe te voegen die de instelling alles weigeren inverse.

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

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

Vereiste 7.3

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

Uw verantwoordelijkheden

Het is essentieel dat u uitgebreide documentatie bijhoudt over de processen en het beleid. Dit omvat Azure- en Kubernetes RBAC-beleid en governancebeleid voor organisaties. Personen die met gereguleerde omgevingen werken, moeten worden geleid, geïnformeerd en gecentreerd om de beveiligingsgaranties te ondersteunen. Dit is met name belangrijk voor mensen die vanuit beleidsperspectief deel uitmaken van het goedkeuringsproces.

---

Vereiste 8.1

Definieer en implementeert beleidsregels en procedures om als volgt te zorgen voor een correct beheer van gebruikersidentificatie voor niet-consumentengebruikers en beheerders op alle systeemonderdelen:

• 8.1.1 Wijs alle gebruikers een unieke id toe voordat ze toegang krijgen tot systeemonderdelen of gegevens van kaartaanduidingen.
• 8.1.2 Controle over het optelling, verwijderen en wijzigen van gebruikers-id's, referenties en andere id-objecten.
• 8.1.3 De toegang voor beëindigde gebruikers onmiddellijk intrekken.
• 8.1.4 Inactieve gebruikersaccounts binnen 90 dagen verwijderen/uitschakelen.
• 8.1.5 Manage IDs used by third parties to access, support, or maintain system components via remote access as volgt:
  • Alleen ingeschakeld tijdens de benodigde tijdsperiode en uitgeschakeld wanneer deze niet in gebruik is.
  • Bewaakt wanneer deze in gebruik is.
• 8.1.6 Herhaalde toegangspogingen beperken door de gebruikers-id na niet meer dan zes pogingen te vergrendelen.
• 8.1.7 Stel de duur van de vergrendeling in op minimaal 30 minuten of totdat een beheerder de gebruikers-id in staat stelt.
• 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 zijn algemene overwegingen voor deze vereiste:

VAN TOEPASSING OP: 8.1.1, 8.1.2, 8.1.3

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

Breid deze identiteits-principal uit naar beheerde identiteitstoewijzingen in Azure. Deel geen door de gebruiker beheerde identiteiten tussen Azure-resources. Wijs elke Azure-resource een eigen beheerde identiteit toe. En als u Azure AD Pod Identity in het AKS-cluster gebruikt, moet u er ook voor zorgen dat elk onderdeel in uw workload een eigen identiteit ontvangt in plaats van een identiteit te gebruiken die uitgebreid is in het bereik. Gebruik nooit dezelfde beheerde identiteit in preproductie en productie.

Toegangs- en identiteitsopties voor Azure Kubernetes Service (AKS)

VAN TOEPASSING OP: 8.1.2, 8.1.3, 8.1.4

Gebruik Azure AD als identiteitsopslag. Omdat het cluster en alle Azure-resources Azure AD gebruiken, wordt het uitschakelen of inroepen van Azure AD-toegang automatisch toegepast op alle resources. Als er onderdelen zijn die niet rechtstreeks worden gemaakt door Azure AD, zorg er dan voor 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 Azure AD Business-to-Business (B2B) dat is ontworpen voor het hosten van accounts van derden, zoals leveranciers, partners, als gastgebruikers. Het juiste toegangsniveau verlenen met behulp van voorwaardelijk beleid om bedrijfsgegevens te beveiligen. Deze accounts moeten minimale permanente machtigingen en verplichte vervaldatums hebben. Zie Wat is toegang voor gastgebruikers in Azure Active Directory B2B voor meer informatie.

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

VAN TOEPASSING OP: 8.1.6, 8.1.7, 8.1.8

Uw verantwoordelijkheden

Azure AD 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 Azure AD.

Implementeert de vergrendeling voor onderdelen die vergelijkbare functies ondersteunen, maar niet worden ondersteund met Azure AD (bijvoorbeeld machines met SSH-functionaliteit, zoals een jumpbox). Dit zorgt ervoor dat vergrendelingen zijn ingeschakeld om misbruik van toegangspogingen te voorkomen of traag te maken.

AKS-knooppunten zijn niet ontworpen om regelmatig te worden gebruikt. Directe SSH of toegang Extern bureaublad 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

Naast het toewijzen van een unieke id moet u ervoor zorgen dat niet-consumentengebruikers en beheerders op alle systeemonderdelen het juiste beheer van gebruikersverificatie hebben door ten minste een van de volgende methoden te gebruiken om alle gebruikers te verifiëren: Iets dat u weet, zoals een wachtwoord of wachtwoordzin, Iets dat u hebt, zoals een tokenapparaat of smartcard, iets dat u bent, zoals een biometrie.

• 8.2.1 Als u sterke cryptografie gebruikt, worden alle verificatiereferenties (zoals wachtwoorden/zinnen) onleesbaar tijdens de overdracht en opslag op alle systeemonderdelen.
• 8.2.2 Verifieer de gebruikersidentiteit voordat u verificatiereferenties wijzigt, bijvoorbeeld het opnieuw instellen van wachtwoorden, het inrichten van nieuwe tokens of het genereren van nieuwe sleutels.
• 8.2.3 Wachtwoorden/zinnen moeten voldoen aan het volgende:
  • Een minimale lengte van ten minste zeven tekens vereisen.
  • Zowel numerieke als alfabetische tekens bevatten.
• 8.2.4 Wijzig gebruikerswachtwoorden/wachtwoordzinnen ten minste eenmaal per 90 dagen.
• 8.2.5 Sta niet toe dat een persoon een nieuw wachtwoord/nieuwe zinsdeel indient dat hetzelfde is als een van de laatste vier wachtwoorden/zinnen die hij of zij heeft gebruikt.
• 8.2.6 Stel wachtwoorden/zinnen in voor het eerste gebruik en bij het opnieuw instellen op een unieke waarde voor elke gebruiker en wijzig onmiddellijk na het eerste gebruik.

Uw verantwoordelijkheden

Stel beleid voor voorwaardelijke toegang in Azure AD in voor uw cluster. Hiermee worden ook beperkingen opgelegd aan de toegang tot het Kubernetes-besturingsvlak.

Verschillende van de voorgaande reeks vereisten worden automatisch verwerkt door Azure AD. Hier volgen enkele voorbeelden:

• Wachtwoordbeveiliging

  Azure AD 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 niet voldoende beveiliging. U kunt de azure AD-functie voor wachtwoordbeveiliging toevoegen om een organisatiespecifieke lijst met verboden te maken. Er wordt standaard een wachtwoordbeleid toegepast. Bepaalde beleidsregels kunnen niet worden gewijzigd en kunnen betrekking hebben op enkele van de voorgaande reeks vereisten. Dit zijn onder andere verlopen van wachtwoorden en toegestane tekens. Zie Azure AD-wachtwoordbeleid voor de volledige lijst. Overweeg het gebruik van geavanceerde functies die kunnen worden afgedwongen met beleid voor voorwaardelijke toegang, zoals functies 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 inAzure Active Directory.

• Verificatie van gebruikersidentiteit

  U kunt het beleid voor voorwaardelijke toegang tot aanmeldingsrisico's toepassen om te detecteren of de verificatieaanvraag is uitgegeven door de aanvragende identiteit. De aanvraag wordt gevalideerd op basis van bedreigingsinformatiebronnen. Dit zijn bijvoorbeeld afwijkingen in wachtwoordsprays en IP-adressen. Zie Voorwaardelijke toegang: Voorwaardelijke toegang op basis van aanmeldingsrisico's voor meer informatie.

Mogelijk hebt u onderdelen die azure AD niet gebruiken, zoals toegang tot jumpboxs met SSH. Gebruik in dergelijke gevallen openbare-sleutelversleuteling met ten minste RSA 2048-sleutelgrootte. Geef altijd een wachtwoordzin op. Een validatieproces hebben dat bekende goedgekeurde openbare sleutels bij houdt. Systemen die gebruikmaken van openbare-sleuteltoegang mogen niet worden blootgesteld aan internet. In plaats daarvan moet alle SSH-toegang worden toegestaan via een intermediair, zoals Azure Bastion om de impact van een lekken van persoonlijke sleutels te beperken. Directe wachtwoordtoegang uitschakelen en een alternatieve oplossing zonder wachtwoord gebruiken.

Vereiste 8.3

Beveilig alle afzonderlijke beheerderstoegang buiten de console en alle externe toegang tot de CDE met meervoudige verificatie. Opmerking: Multi-Factor Authentication vereist dat minimaal twee van de drie verificatiemethoden (zie Vereiste 8.2 voor beschrijvingen van verificatiemethoden) worden gebruikt voor verificatie. Het tweemaal gebruiken van één factor (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 dit beleid toe op Azure AD-groepen die zijn toewijzen aan Kubernetes-rollen met hoge bevoegdheden.

Dit beleid kan verder worden gehard met extra beleid. Hier volgen enkele voorbeelden:

• U kunt de verificatie beperken tot apparaten die worden beheerd door uw Azure AD-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
• Hoe: Beheerde apparaten vereisen voor toegang tot cloud-apps met voorwaardelijke toegang
• Hoe: MFA vereisen voor toegang vanaf niet-vertrouwde netwerken met voorwaardelijke toegang

Vereiste 8.4

Documenteren en communiceren van verificatieprocedures en -beleidsregels en -procedures aan 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 wordt vermoed dat het wachtwoord is aangetast.

Uw verantwoordelijkheden

Documentatie onderhouden over het afgedwongen beleid. Als onderdeel van uw training voor het onboarden van identiteiten, biedt u richtlijnen voor procedures voor wachtwoord opnieuw instellen en best practices van 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 zijn uitgeschakeld of verwijderd.
• Gedeelde gebruikers-ID's bestaan niet voor systeembeheer en andere kritieke functies.
• Gedeelde en algemene gebruikers-ID's worden niet gebruikt voor het beheren van systeemonderdelen.

Uw verantwoordelijkheden

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

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

Vereiste 8.6

Als er 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.
• Er moeten fysieke en/of logische besturingselementen 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 geboden op identiteiten per gebruiker. Dit wordt uitgebreid naar fysieke of virtuele tokens. Dit omvat vpn-toegang tot het CDE-netwerk, zodat zakelijke punt-naar-site-toegang (indien van toepassing) certificaten per gebruiker gebruiken als onderdeel van deze verificatiestroom.

Vereiste 8.7

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

• Alle gebruikerstoegang tot, gebruikersquery's van en gebruikersacties voor databases zijn via programmatische methoden.
• Alleen databasebeheerders hebben de mogelijkheid om rechtstreeks toegang te krijgen tot databases of er query's op uit te voeren.
• 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. Mensen kunnen hun identiteit gebruiken, maar de toegang moet worden beperkt op basis van de noodzaak om te weten, met minimale permanente machtigingen. Mensen mogen nooit toepassings-id's gebruiken en identiteiten voor databasetoegang mogen nooit worden gedeeld.

Toegang tot de database vanuit toepassingen via een beheerde identiteit, indien mogelijk. Anders beperkt u de blootstelling aan verbindingsreeksen en referenties. Gebruik Kubernetes-geheimen om gevoelige informatie op te slaan in plaats van ze te bewaren op plaatsen waar ze eenvoudig kunnen worden gevonden, zoals poddefinitie. Een andere manier is om geheimen op te slaan en te laden van en naar een beheerde opslag, zoals Azure Key Vault. Als beheerde identiteiten zijn ingeschakeld op een AKS-cluster, moet het zichzelf verifiëren aan de hand van Key Vault toegang te krijgen.

Vereiste 8.8

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

Uw verantwoordelijkheden

Het is essentieel dat u uitgebreide documentatie bijhoudt over de processen en het beleid. Documentatie over het afgedwongen beleid onderhouden. Als onderdeel van uw training voor het onboarden van identiteiten, biedt u richtlijnen voor procedures voor wachtwoord opnieuw instellen en best practices van de organisatie voor het beveiligen van assets. Personen die met gereguleerde omgevingen werken, moeten worden geleid, geïnformeerd en gecentreerd om de beveiligingsgaranties te ondersteunen. Dit is vooral belangrijk voor mensen die vanuit beleidsperspectief deel uitmaken van het goedkeuringsproces.

Vereiste 9

Fysieke toegang tot kaartgegevens beperken

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 zijn enkele suggesties voor het toepassen van technische besturingselementen:

• Stem sessie-time-outs af in elke beheerconsole, zoals jumpboxs in de CDE, om de toegang te minimaliseren.

• Stem beleidsregels voor voorwaardelijke toegang af om de TTL op Azure-toegangstokens van toegangspunten, zoals de Azure Portal. Zie de volgende artikelen voor meer informatie:

  • Beheer van verificatiesessies met voorwaardelijke toegang configureren
  • Configureerbare levensduur van token - Microsoft identity platform

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

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

• Back-ups naar on-premises minimaliseren. Als dit vereist is, moet u er rekening mee houden dat de on-premises bestemming binnen het controlebereik valt.

Volgende stappen

Alle toegang tot netwerkbronnen en kaartgegevens bijhouden en bewaken. Test regelmatig beveiligingssystemen en -processen.