Delen via

Microsoft Entra ID en PCI-DSS-vereiste 8

  • Artikel

Vereiste 8: Gebruikers identificeren en toegang tot door systeemonderdelen
gedefinieerde benaderingsvereisten verifiëren

8.1 Processen en mechanismen voor het identificeren van gebruikers en het verifiëren van toegang tot systeemonderdelen worden gedefinieerd en begrepen.

Vereisten voor gedefinieerde PCI-DSS-benadering Richtlijnen en aanbevelingen voor Microsoft Entra
8.1.1 Alle beveiligingsbeleidsregels en operationele procedures die zijn geïdentificeerd in vereiste 8 zijn:
Gedocumenteerd
up-to-date
in gebruik
Bekend bij alle betrokken partijen		 Gebruik de richtlijnen en koppelingen hier om de documentatie te produceren om te voldoen aan de vereisten op basis van uw omgevingsconfiguratie.
8.1.2 Rollen en verantwoordelijkheden voor het uitvoeren van activiteiten in vereiste 8 worden gedocumenteerd, toegewezen en begrepen. Gebruik de richtlijnen en koppelingen hier om de documentatie te produceren om te voldoen aan de vereisten op basis van uw omgevingsconfiguratie.
Vereisten voor gedefinieerde PCI-DSS-benadering Richtlijnen en aanbevelingen voor Microsoft Entra
8.2.1 Alle gebruikers krijgen een unieke id toegewezen voordat toegang tot systeemonderdelen of gegevens van kaartaanduidingen is toegestaan. Voor CDE-toepassingen die afhankelijk zijn van Microsoft Entra ID, is de unieke gebruikers-id het UPN-kenmerk (User Principal Name). Microsoft Entra UserPrincipalName-populatie
8.2.2 Groeps-, gedeelde of algemene accounts of andere gedeelde verificatiereferenties worden alleen gebruikt wanneer dit nodig is op uitzonderingsbasis en worden als volgt beheerd:
Accountgebruik wordt voorkomen tenzij dit nodig is voor een uitzonderlijke situatie.
Gebruik is beperkt tot de tijd die nodig is voor de uitzonderlijke omstandigheden.
Zakelijke reden voor gebruik wordt gedocumenteerd.
Gebruik wordt expliciet goedgekeurd door de individuele gebruikersidentiteit van het beheer
wordt bevestigd voordat toegang tot een account wordt verleend.
Elke actie die wordt ondernomen, is toe te schrijven aan een afzonderlijke gebruiker.		 Zorg ervoor dat CDE's die gebruikmaken van Microsoft Entra ID voor toegang tot toepassingen processen hebben om gedeelde accounts te voorkomen. Maak ze als een uitzondering waarvoor goedkeuring is vereist.
Voor CDE-resources die zijn geïmplementeerd in Azure, gebruikt u beheerde identiteiten voor Azure-resources om de workloadidentiteit weer te geven in plaats van een gedeeld serviceaccount te maken. Wat zijn beheerde identiteiten voor Azure-resources?
Als u geen beheerde identiteiten kunt gebruiken en de resources die worden geopend, gebruikmaken van het OAuth-protocol, gebruikt u service-principals om workloadidentiteiten weer te geven. Verken identiteiten met minimale bevoegdheden via OAuth-bereiken. Beheerders kunnen de toegang beperken en goedkeuringswerkstromen definiëren om ze te maken. Wat zijn workloadidentiteiten?
8.2.3 Alleen aanvullende vereiste voor serviceproviders: serviceproviders met externe toegang tot de locatie van de klant gebruiken unieke verificatiefactoren voor elke klantlocatie. Microsoft Entra ID heeft on-premises connectors om hybride mogelijkheden in te schakelen. Connectors zijn identificeerbaar en gebruiken unieke gegenereerde referenties. Microsoft Entra Connect Sync: De cloudsynchronisatie
van
Microsoft Entra on-premises toepassingsinrichtingsarchitectuur
Cloud-HR-toepassing plannen voor Microsoft Entra-gebruikersinrichting
Installeer de Microsoft Entra Connect Health-agents
8.2.4 Toevoeging, verwijdering en wijziging van gebruikers-id's, verificatiefactoren en andere id-objecten worden als volgt beheerd:
Geautoriseerd met de juiste goedkeuring.
Geïmplementeerd met alleen de bevoegdheden die zijn opgegeven voor de gedocumenteerde goedkeuring.		 Microsoft Entra ID heeft geautomatiseerde inrichting van gebruikersaccounts vanuit HR-systemen. Gebruik deze functie om een levenscyclus te maken. Wat is inrichten op basis van HR?
Microsoft Entra ID heeft levenscycluswerkstromen om aangepaste logica in te schakelen voor joiner-, mover- en verlofprocessen. Wat zijn levenscycluswerkstromen?
Microsoft Entra ID heeft een programmatische interface voor het beheren van verificatiemethoden met Microsoft Graph. Voor sommige verificatiemethoden, zoals Windows Hello voor Bedrijven- en FIDO2-sleutels, moet de gebruiker zich registreren. Aan de slag met de Graph-verificatiemethoden API-beheerders
en/of automatisering genereert de referentie voor tijdelijke toegangspas met behulp van Graph API. Gebruik deze referentie voor onboarding zonder wachtwoord. Een tijdelijke toegangspas in Microsoft Entra-id configureren om verificatiemethoden zonder wachtwoord te registreren
8.2.5 Toegang voor beëindigde gebruikers wordt onmiddellijk ingetrokken. Als u de toegang tot een account wilt intrekken, schakelt u on-premises accounts uit voor hybride accounts die zijn gesynchroniseerd vanuit Microsoft Entra-id, schakelt u accounts uit in Microsoft Entra ID en trekt u tokens in. Gebruikerstoegang intrekken in Microsoft Entra ID
: Continue toegangsevaluatie (CAE) gebruiken voor compatibele toepassingen om een tweerichtingsgesprek te voeren met Microsoft Entra ID. Apps kunnen worden gewaarschuwd voor gebeurtenissen, zoals het beëindigen van accounts en het weigeren van tokens. Continue toegangsevaluatie
8.2.6 Inactieve gebruikersaccounts worden verwijderd of uitgeschakeld binnen 90 dagen na inactiviteit. Voor hybride accounts controleren beheerders elke 90 dagen de activiteit in Active Directory en Microsoft Entra. Voor Microsoft Entra-id gebruikt u Microsoft Graph om de laatste aanmeldingsdatum te vinden. Procedure: Inactieve gebruikersaccounts beheren in Microsoft Entra-id
8.2.7 Accounts die door derden worden gebruikt voor toegang, ondersteuning of onderhoud van systeemonderdelen via externe toegang, worden als volgt beheerd:
Alleen ingeschakeld tijdens de benodigde periode en uitgeschakeld wanneer deze niet in gebruik is.
Gebruik wordt gecontroleerd op onverwachte activiteit.		 Microsoft Entra ID heeft mogelijkheden voor extern identiteitsbeheer.
Gebruik beheerde levenscyclus van gasten met rechtenbeheer. Externe gebruikers worden onboarding uitgevoerd in de context van apps, resources en toegangspakketten, die u gedurende een beperkte periode kunt verlenen en periodieke toegangsbeoordelingen vereisen. Beoordelingen kunnen leiden tot het verwijderen of uitschakelen van accounts. Beheer de toegang voor externe gebruikers in rechtenbeheer
Microsoft Entra ID genereert risico-gebeurtenissen op gebruikers- en sessieniveau. Leer hoe u onverwachte activiteiten beveiligt, detecteert en erop reageert. Wat is risico?
8.2.8 Als een gebruikerssessie langer dan 15 minuten inactief is geweest, moet de gebruiker opnieuw verifiëren om de terminal of sessie opnieuw te activeren. Gebruik eindpuntbeheerbeleid met Intune en Microsoft Endpoint Manager. Gebruik vervolgens voorwaardelijke toegang om toegang vanaf compatibele apparaten toe te staan. Gebruik nalevingsbeleid om regels in te stellen voor apparaten die u beheert met Intune
als uw CDE-omgeving afhankelijk is van groepsbeleidsobjecten (GPO), groepsbeleidsobject configureren om een time-out voor inactiviteit in te stellen. Configureer de Microsoft Entra-id om toegang toe te staan vanaf hybride apparaten die zijn toegevoegd aan Microsoft Entra. Hybride apparaten van Microsoft Entra

8.3 Sterke verificatie voor gebruikers en beheerders wordt ingesteld en beheerd.

Zie voor meer informatie over Microsoft Entra-verificatiemethoden die voldoen aan PCI-vereisten: Informatiesupplement: Multi-Factor Authentication.

Vereisten voor gedefinieerde PCI-DSS-benadering Richtlijnen en aanbevelingen voor Microsoft Entra
8.3.1 Alle gebruikerstoegang tot systeemonderdelen voor gebruikers en beheerders wordt geverifieerd via ten minste een van de volgende verificatiefactoren:
Iets wat u weet, zoals een wachtwoord of wachtwoordzin.
Iets wat u hebt, zoals een tokenapparaat of smartcard.
Iets wat u bent, zoals een biometrisch element.		 Microsoft Entra ID vereist methoden zonder wachtwoord om te voldoen aan de PCI-vereisten
Zie holistische implementatie zonder wachtwoord. Een implementatie van verificatie zonder wachtwoord plannen in Microsoft Entra-id
8.3.2 Sterke cryptografie wordt gebruikt om alle verificatiefactoren onleesbaar te maken tijdens verzending en opslag op alle systeemonderdelen. Cryptografie die door Microsoft Entra ID wordt gebruikt, voldoet aan de PCI-definitie van Strong Cryptography. Overwegingen voor Microsoft Entra-gegevensbescherming
8.3.3 Gebruikersidentiteit wordt geverifieerd voordat u een verificatiefactor wijzigt. Microsoft Entra ID vereist dat gebruikers zich verifiëren om hun verificatiemethoden bij te werken met behulp van selfservice, zoals de portal mysecurityinfo en de selfservice voor wachtwoordherstel (SSPR). Beveiligingsgegevens instellen vanaf een aanmeldingspagina Algemeen beleid voor voorwaardelijke toegang: Het beveiligen van registratie
van beveiligingsgegevens Microsoft Entra selfservice voor wachtwoordherstel
beheerders met bevoorrechte rollen kunnen verificatiefactoren wijzigen: Globaal, Wachtwoord, Gebruiker, Verificatie en Bevoegde verificatie.
Rollen met minimale bevoegdheden per taak in Microsoft Entra-id. Microsoft raadt u aan JIT-toegang en -beheer in te schakelen voor bevoegde toegang met Behulp van Microsoft Entra Privileged Identity Management
8.3.4 Ongeldige verificatiepogingen worden beperkt door:
Vergrendel de gebruikers-id na niet meer dan tien pogingen.
De vergrendelingsduur instellen op minimaal 30 minuten of totdat de identiteit van de gebruiker is bevestigd.		 Implementeer Windows Hello voor Bedrijven voor Windows-apparaten die ondersteuning bieden voor TPM (Trusted Platform Modules) 2.0 of hoger.
Voor Windows Hello voor Bedrijven heeft vergrendeling betrekking op het apparaat. De beweging, pincode of biometrische gegevens ontgrendelt de toegang tot de lokale TPM. Beheerders configureren het vergrendelingsgedrag met GPO- of Intune-beleid. TPM-groepsbeleidsinstellingen Beheer Windows Hello voor Bedrijven op apparaten op het moment dat apparaten worden ingeschreven met de basisprincipes van Intune
TPM Windows Hello voor Bedrijven werkt voor on-premises verificatie bij Active Directory en cloudresources
op Microsoft Entra-id.

Voor FIDO2-beveiligingssleutels is beveiliging tegen beveiligingsaanvallen gerelateerd aan de sleutel. De beweging, pincode of biometrische gegevens ontgrendelt de toegang tot de lokale sleutelopslag. Beheerders configureren Microsoft Entra-id om registratie van FIDO2-beveiligingssleutels van fabrikanten toe te staan die zijn afgestemd op PCI-vereisten. Schakel aanmelding zonder wachtwoordloze beveiligingssleutel in

microsoft Authenticator-app
in om beveiligingsaanvallen te beperken met behulp van aanmelding zonder wachtwoord van de Microsoft Authenticator-app, het inschakelen van nummerkoppeling en meer context.
Microsoft Entra ID genereert een willekeurig getal in de verificatiestroom. De gebruiker typt deze in de verificator-app. De verificatieprompt voor mobiele apps toont de locatie, het IP-adres van de aanvraag en de aanvraagtoepassing. Nummerkoppeling gebruiken in MFA-meldingen
: aanvullende context gebruiken in Microsoft Authenticator-meldingen
8.3.5 Als wachtwoorden/wachtwoordzinnen worden gebruikt als verificatiefactoren om te voldoen aan vereiste 8.3.1, worden ze als volgt ingesteld en opnieuw ingesteld voor elke gebruiker:
Ingesteld op een unieke waarde voor het eerste gebruik en bij het opnieuw instellen.
Gedwongen om onmiddellijk na het eerste gebruik te worden gewijzigd.		 Niet van toepassing op Microsoft Entra-id.
8.3.6 Als wachtwoorden/wachtwoordzinnen worden gebruikt als verificatiefactoren om te voldoen aan vereiste 8.3.1, voldoen ze aan het volgende minimale complexiteitsniveau:
Een minimumlengte van 12 tekens (of als het systeem geen ondersteuning biedt voor 12 tekens, een minimumlengte van acht tekens).
Bevatten zowel numerieke als alfabetische tekens.		 Niet van toepassing op Microsoft Entra-id.
8.3.7 Personen mogen geen nieuw wachtwoord/wachtwoordzin indienen die hetzelfde is als een van de laatste vier gebruikte wachtwoorden/wachtwoordzinnen. Niet van toepassing op Microsoft Entra-id.
8.3.8 Verificatiebeleid en -procedures worden gedocumenteerd en gecommuniceerd aan alle gebruikers, waaronder:
Richtlijnen voor het selecteren van sterke verificatiefactoren.
Richtlijnen voor hoe gebruikers hun verificatiefactoren moeten beveiligen.
Instructies voor het niet opnieuw gebruiken van eerder gebruikte wachtwoorden/wachtwoordzinnen.
Instructies voor het wijzigen van wachtwoorden/wachtwoordzinnen als er vermoedens of kennis is dat de wachtwoord-/wachtwoordzinnen zijn gecompromitteerd en hoe u het incident kunt rapporteren.		 Documenteer beleidsregels en procedures en communiceer vervolgens aan gebruikers volgens deze vereiste. Microsoft biedt aanpasbare sjablonen in het Downloadcentrum.
8.3.9 Als wachtwoorden/wachtwoordzinnen worden gebruikt als de enige verificatiefactor voor gebruikerstoegang (dat wil zeggen, in elke implementatie met één factor verificatie), dan kunnen wachtwoorden/wachtwoordzinnen ten minste eenmaal per 90 dagen worden gewijzigd,
OF
de beveiligingspostuur van accounts wordt dynamisch geanalyseerd en realtime toegang tot resources automatisch wordt bepaald.		 Niet van toepassing op Microsoft Entra-id.
8.3.10 Aanvullende vereiste voor serviceproviders alleen: als wachtwoorden/wachtwoordzinnen worden gebruikt als de enige verificatiefactor voor de gebruikerstoegang van de klant tot gegevens van de kaarthouder (dat wil gezegd, in elke implementatie met één factor verificatie), worden er richtlijnen verstrekt aan gebruikers van klanten, waaronder:
Richtlijnen voor klanten om hun gebruikerswachtwoorden/wachtwoordzinnen periodiek te wijzigen.
Richtlijnen voor wanneer en onder welke omstandigheden wachtwoorden/wachtwoordzinnen moeten worden gewijzigd.		 Niet van toepassing op Microsoft Entra-id.
8.3.10.1 Alleen aanvullende vereiste voor serviceproviders: Als wachtwoorden/wachtwoordzinnen worden gebruikt als de enige verificatiefactor voor gebruikerstoegang van de klant (dat wil zeggen in elke implementatie met één factor verificatie),
worden wachtwoorden/wachtwoordzinnen ten minste één keer per 90 dagen gewijzigd,
OF
de beveiligingspostuur van accounts wordt dynamisch geanalyseerd en wordt realtime toegang tot resources automatisch dienovereenkomstig bepaald.		 Niet van toepassing op Microsoft Entra-id.
8.3.11 Wanneer verificatiefactoren zoals fysieke of logische beveiligingstokens, smartcards of certificaten worden gebruikt:
Factoren worden toegewezen aan een afzonderlijke gebruiker en worden niet gedeeld tussen meerdere gebruikers.
Fysieke en/of logische besturingselementen zorgen ervoor dat alleen de beoogde gebruiker die factor kan gebruiken om toegang te krijgen.		 Gebruik verificatiemethoden zonder wachtwoord, zoals Windows Hello voor Bedrijven, FIDO2-beveiligingssleutels en de Microsoft Authenticator-app voor telefoon aanmelden. Gebruik smartcards op basis van openbare of persoonlijke keypairs die zijn gekoppeld aan gebruikers om hergebruik te voorkomen.

8.4 Multi-Factor Authentication (MFA) wordt geïmplementeerd om de toegang tot de gegevensomgeving van de kaarthouder te beveiligen (CDE)

Vereisten voor gedefinieerde PCI-DSS-benadering Richtlijnen en aanbevelingen voor Microsoft Entra
8.4.1 MFA wordt geïmplementeerd voor alle niet-consoletoegang tot de CDE voor personeel met beheerderstoegang. Gebruik voorwaardelijke toegang om sterke verificatie te vereisen voor toegang tot CDE-resources. Definieer beleidsregels voor een beheerrol of een beveiligingsgroep die beheerderstoegang tot een toepassing vertegenwoordigt.
Voor beheerderstoegang gebruikt u Microsoft Entra Privileged Identity Management (PIM) om Just-In-Time-activering van bevoorrechte rollen in te schakelen. Wat is voorwaardelijke toegang?
Sjablonen voor voorwaardelijke toegang
beginnen met PIM
8.4.2 MFA wordt geïmplementeerd voor alle toegang tot de CDE. Toegang tot verouderde protocollen blokkeren die geen ondersteuning bieden voor sterke verificatie. Verouderde verificatie bij Microsoft Entra ID met voorwaardelijke toegang blokkeren
8.4.3 MFA wordt geïmplementeerd voor alle externe netwerktoegang die afkomstig is van buiten het netwerk van de entiteit die als volgt toegang kan krijgen tot of van invloed kan zijn op de CDE:
Alle externe toegang door alle medewerkers, zowel gebruikers als beheerders, afkomstig van buiten het netwerk van de entiteit.
Alle externe toegang door derden en leveranciers.		 Integreer toegangstechnologieën zoals VPN (Virtual Private Network), extern bureaublad en netwerktoegangspunten met Microsoft Entra-id voor verificatie en autorisatie. Gebruik Voorwaardelijke toegang om sterke verificatie te vereisen voor toegang tot toepassingen voor externe toegang. Sjablonen voor voorwaardelijke toegang

8.5 MFA-systemen (Multi-Factor Authentication) zijn geconfigureerd om misbruik te voorkomen.

Vereisten voor gedefinieerde PCI-DSS-benadering Richtlijnen en aanbevelingen voor Microsoft Entra
8.5.1 MFA-systemen worden als volgt geïmplementeerd:
het MFA-systeem is niet vatbaar voor het opnieuw afspelen van aanvallen.
MFA-systemen kunnen niet worden overgeslagen door gebruikers, met inbegrip van gebruikers met beheerdersrechten, tenzij ze specifiek zijn gedocumenteerd en geautoriseerd door beheer op uitzonderingsbasis, gedurende een beperkte periode.
Er worden ten minste twee verschillende typen verificatiefactoren gebruikt.
Het slagen van alle verificatiefactoren is vereist voordat toegang wordt verleend.		 De aanbevolen Microsoft Entra-verificatiemethoden maken gebruik van nonce of uitdagingen. Deze methoden weerstaan herhalingsaanvallen omdat Microsoft Entra ID opnieuw afgespeelde verificatietransacties detecteert.
Windows Hello voor Bedrijven, FIDO2 en Microsoft Authenticator-app voor aanmelding zonder wachtwoord gebruiken een nonce om de aanvraag te identificeren en herhalingspogingen te detecteren. Gebruik referenties zonder wachtwoord voor gebruikers in de CDE.
Verificatie op basis van certificaten maakt gebruik van uitdagingen voor het detecteren van herhalingspogingen.
NIST authenticator assurance level 2 met Microsoft Entra ID
NIST authenticator assurance level 3 met behulp van Microsoft Entra ID

8.6 Het gebruik van toepassings- en systeemaccounts en bijbehorende verificatiefactoren wordt strikt beheerd.

Vereisten voor gedefinieerde PCI-DSS-benadering Richtlijnen en aanbevelingen voor Microsoft Entra
8.6.1 Als accounts die worden gebruikt door systemen of toepassingen kunnen worden gebruikt voor interactieve aanmelding, worden ze als volgt beheerd:
Interactief gebruik wordt voorkomen tenzij dit nodig is voor een uitzonderlijke situatie.
Interactief gebruik is beperkt tot de tijd die nodig is voor de uitzonderlijke omstandigheden.
Zakelijke reden voor interactief gebruik wordt gedocumenteerd.
Interactief gebruik wordt expliciet goedgekeurd door beheer.
Afzonderlijke gebruikersidentiteit wordt bevestigd voordat toegang tot het account wordt verleend.
Elke actie die wordt ondernomen, is toe te schrijven aan een afzonderlijke gebruiker.		 Voor CDE-toepassingen met moderne verificatie en voor CDE-resources die zijn geïmplementeerd in Azure die moderne verificatie gebruiken, heeft Microsoft Entra ID twee serviceaccounttypen voor toepassingen: Beheerde identiteiten en service-principals.
Meer informatie over microsoft Entra-serviceaccountbeheer: planning, inrichting, levenscyclus, bewaking, toegangsbeoordelingen, enzovoort. Microsoft Entra-serviceaccounts
beheren Om Microsoft Entra-serviceaccounts te beveiligen. Het beveiligen van beheerde identiteiten in Microsoft Entra ID
Het beveiligen van service-principals in Microsoft Entra ID
voor CDE's met resources buiten Azure die toegang vereisen, federaties van workloadidentiteiten configureren zonder geheimen of interactief aanmelden te beheren. Federatie van workloadidentiteit
om goedkeurings- en traceringsprocessen in te schakelen om te voldoen aan vereisten, werkstromen te organiseren met BEHULP van IT Service Management (ITSM) en CMDB (Configuration Management Databases) Deze hulpprogramma's gebruiken MS Graph API om te communiceren met Microsoft Entra ID en het serviceaccount te beheren.
Voor CDE's waarvoor serviceaccounts vereist zijn die compatibel zijn met on-premises Active Directory, gebruikt u Group Managed Service Accounts (GMSAs) en zelfstandige beheerde serviceaccounts (sMSA), computeraccounts of gebruikersaccounts. On-premises serviceaccounts beveiligen
8.6.2 Wachtwoorden/wachtwoordzinnen voor toepassingen en systeemaccounts die kunnen worden gebruikt voor interactieve aanmelding, zijn niet vastgelegd in scripts, configuratie-/eigenschapsbestanden of op maat gemaakte en aangepaste broncode. Gebruik moderne serviceaccounts, zoals Azure Managed Identities en service-principals waarvoor geen wachtwoorden zijn vereist.
Door Microsoft Entra beheerde identiteiten worden ingericht en geroteerd in de cloud, waardoor het gebruik van gedeelde geheimen, zoals wachtwoorden en wachtwoordzinnen, wordt voorkomen. Wanneer u door het systeem toegewezen beheerde identiteiten gebruikt, is de levenscyclus gekoppeld aan de onderliggende levenscyclus van Azure-resources.
Gebruik service-principals om certificaten als referenties te gebruiken, waardoor het gebruik van gedeelde geheimen, zoals wachtwoorden en wachtwoordzinnen, wordt voorkomen. Als certificaten niet haalbaar zijn, gebruikt u Azure Key Vault om clientgeheimen van de service-principal op te slaan. Aanbevolen procedures voor het gebruik van Azure Key Vault
voor CDE's met resources buiten Azure die toegang vereisen, workloadidentiteitsfederaties configureren zonder geheimen of interactieve aanmelding te beheren. Workloadidentiteitsfederatie
Implementeer voorwaardelijke toegang voor workloadidentiteiten om autorisatie te beheren op basis van locatie- en/of risiconiveau. Voorwaardelijke toegang voor workloadidentiteiten
Naast de vorige richtlijnen gebruikt u hulpprogramma's voor codeanalyse om in code- en configuratiebestanden vastgelegde geheimen te detecteren. Blootgestelde geheimen detecteren in codebeveiligingsregels
8.6.3 Wachtwoorden/wachtwoordzinnen voor toepassingen en systeemaccounts worden als volgt beschermd tegen misbruik:
Wachtwoorden/wachtwoordzinnen worden periodiek gewijzigd (met de frequentie die is gedefinieerd in de beoogde risicoanalyse van de entiteit, die wordt uitgevoerd op basis van alle elementen die zijn opgegeven in Vereiste 12.3.1) en bij vermoeden of bevestiging van inbreuk.
Wachtwoorden/wachtwoordzinnen worden samengesteld met voldoende complexiteit die geschikt is voor hoe vaak de entiteit de wachtwoorden/wachtwoordzinnen wijzigt.		 Gebruik moderne serviceaccounts, zoals Azure Managed Identities en service-principals waarvoor geen wachtwoorden zijn vereist.
Voor uitzonderingen waarvoor service-principals met geheimen zijn vereist, abstracte levenscyclus van geheimen met werkstromen en automatiseringen waarmee willekeurige wachtwoorden worden ingesteld op service-principals, deze regelmatig roteert en reageert op risicogebeurtenissen.
Beveiligingsteams kunnen rapporten bekijken en herstellen die zijn gegenereerd door Microsoft Entra, zoals riskante workloadidentiteiten. Workloadidentiteiten beveiligen met Identity Protection

Volgende stappen

PCI-DSS-vereisten 3, 4, 9 en 12 zijn niet van toepassing op Microsoft Entra-id, daarom zijn er geen bijbehorende artikelen. Als u alle vereisten wilt zien, gaat u naar pcisecuritystandards.org: officiële site van de PCI Security Standards Council.

Zie de volgende artikelen voor het configureren van Microsoft Entra ID om te voldoen aan PCI-DSS.