Freigeben über

Microsoft Entra ID und PCI-DSS-Anforderung 8

  • Artikel

Anforderung 8: Identifizieren von Benutzern und Authentifizieren des Zugriffs auf Systemkomponenten
Anforderungen des definierten Ansatzes

8.1 Prozesse und Mechanismen zum Identifizieren von Benutzern und Authentifizieren des Zugriffs auf Systemkomponenten werden definiert und verstanden.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
8.1.1 Alle Sicherheitsrichtlinien und Betriebsabläufe, die in der Anforderung 8 identifiziert werden, sind:
Dokumentiert
Auf dem neuesten Stand
In Gebrauch
Allen betroffenen Parteien bekannt		 Verwenden Sie die hierin enthaltenen Anleitungen und Links zum Erstellen der Dokumentation, um die Anforderungen basierend auf Ihrer Umgebungskonfiguration zu erfüllen.
8.1.2 Rollen und Verantwortlichkeiten für die Durchführung von Aktivitäten in Anforderung 8 werden dokumentiert, zugewiesen und verstanden. Verwenden Sie die hierin enthaltenen Anleitungen und Links zum Erstellen der Dokumentation, um die Anforderungen basierend auf Ihrer Umgebungskonfiguration zu erfüllen.
Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
8.2.1 Allen Benutzern wird eine eindeutige ID zugewiesen, bevor ihnen Zugriff auf Systemkomponenten oder Karteninhaberdaten gewährt wird. Für CDE-Anwendungen, die Microsoft Entra ID verwenden, ist die eindeutige Benutzer-ID das UPN-Attribut (User Principal Name). Auffüllung von Microsoft Entra UserPrincipalName
8.2.2 Gruppenkonten, freigegebene oder generische Konten oder andere Anmeldeinformationen für die gemeinsame Authentifizierung werden nur verwendet, wenn dies ausnahmsweise erforderlich ist. Sie werden wie folgt verwaltet:
Die Kontonutzung wird verhindert, sofern dies nicht aufgrund eines außergewöhnlichen Umstands erforderlich ist.
Die Nutzung ist auf den Zeitraum beschränkt, der für den außergewöhnlichen Umstand erforderlich ist.
Die geschäftliche Begründung der die Nutzung wird dokumentiert.
Die Nutzung wird explizit vom Management genehmigt.
Die individuelle Benutzeridentität wird bestätigt, bevor der Zugriff auf ein Konto gewährt wird.
Jede ausgeführte Aktion lässt sich einem einzelnen Benutzer zuordnen.		 Stellen Sie sicher, dass CDE, die Microsoft Entra ID für den Anwendungszugriff verwenden, über Prozesse verfügen, um gemeinsam genutzte Konten zu verhindern. Erstellen Sie sie als Ausnahme, die genehmigt werden muss.
Verwenden Sie für in Azure bereitgestellte CDE-Ressourcen verwaltete Identitäten für Azure-Ressourcen, um die Workloadidentität darzustellen, anstatt ein gemeinsames Dienstkonto zu erstellen. Was sind verwaltete Identitäten für Azure-Ressourcen?
Wenn Sie keine verwalteten Identitäten verwenden können und die Ressourcen, auf die zugegriffen wird, das OAuth-Protokoll verwenden, stellen Sie Workloadidentitäten unter Verwendung von Dienstprinzipalen dar. Gewähren Sie Identitäten über OAuth-Bereiche Zugriff mit geringsten Rechten. Administratoren können den Zugriff einschränken und zum Erstellen Genehmigungsworkflows definieren. Was sind Workloadidentitäten?
8.2.3Zusätzliche Anforderung für Dienstanbieter: Dienstanbieter mit Remotezugriff auf Kundenstandorte verwenden für jeden Kundenstandort eindeutige Authentifizierungsfaktoren. Microsoft Entra ID verfügt über lokale Connectors, um Hybridfunktionen zu ermöglichen. Connectors sind identifizierbar und verwenden eindeutig generierte Anmeldeinformationen. Microsoft Entra Connect-Synchronisierung: Grundlegendes und Anpassen der Synchronisierung
Ausführliche Informationen zur Cloudsynchronisierung
Architektur der lokalen Microsoft Entra-Anwendungsbereitstellung
Planen einer HR-Cloudanwendung für die Azure AD-Benutzerbereitstellung
Installieren der Azure AD Connect Health-Agents
8.2.4 Das Hinzufügen, Löschen und Ändern von Benutzer-IDs, Authentifizierungsfaktoren und anderen Bezeichnerobjekten wird wie folgt verwaltet:
Der Vorgang wird durch die entsprechende Genehmigung autorisiert.
Der Vorgang wird nur mit den Berechtigungen implementiert, die in der dokumentierten Genehmigung angegeben sind.		 Microsoft Entra ID verfügt über eine automatisierte Bereitstellung von Benutzerkonten über HR-Systeme. Verwenden Sie dieses Feature, um einen Lebenszyklus zu erstellen. Worum handelt es sich bei der personalbasierten Bereitstellung?
Microsoft Entra ID verfügt über Lebenszyklusworkflows, die eine individuelle Logik für Neueinstellungs-, Versetzungs- und Kündigungsprozesse zulassen. Was sind Lebenszyklus-Workflows?
Microsoft Entra ID verfügt über eine programmgesteuerte Schnittstelle zum Verwalten von Authentifizierungsmethoden mit Microsoft Graph. Einige Authentifizierungsmethoden wie Windows Hello for Business- und FIDO2-Schlüssel erfordern einen Benutzereingriff zur Registrierung. Erste Schritte mit der Graph-Authentifizierungsmethoden-API
Administratoren und/oder automatisierte Prozesse generieren mithilfe der Graph-API die Anmeldeinformationen für den befristeten Zugriffspass. Verwenden Sie diese Anmeldeinformationen für das kennwortlose Onboarding. Konfigurieren eines befristeten Zugriffspasses in Microsoft Entra ID für die Registrierung von kennwortlosen Authentifizierungsmethoden
8.2.5 Der Zugriff gekündigter Benutzer wird sofort widerrufen. Um den Zugriff auf Konten zu widerrufen, deaktivieren Sie lokale Konten für Hybridkonten, die von Microsoft Entra ID synchronisiert werden, deaktivieren Sie die Konten in Microsoft Entra ID, und widerrufen Sie die Token. Widerrufen des Benutzerzugriffs in Microsoft Entra ID
Verwenden Sie die fortlaufende Zugriffsevaluierung für kompatible Anwendungen, um eine bidirektionale Konversation mit Microsoft Entra ID zu führen. Apps können über Ereignisse benachrichtigt werden, z. B. Kontobeendigung und Ablehnungstoken. Fortlaufende Zugriffsevaluierung
8.2.6 Inaktive Benutzerkonten werden innerhalb von 90 Tagen Inaktivität entfernt oder deaktiviert. Bei Hybridkonten überprüfen Administratoren alle 90 Tage die Aktivität in Active Directory und Microsoft Entra. Um das Datum der letzten Anmeldung zu ermitteln, verwenden Sie Microsoft Graph für Microsoft Entra ID. So geht‘s: Verwalten inaktiver Benutzerkonten in Microsoft Entra ID
8.2.7 Konten, die von Drittanbietern für den Zugriff auf, die Unterstützung oder die Wartung von Systemkomponenten über Remotezugriff verwendet werden, werden wie folgt verwaltet:
Aktiviert nur während des erforderlichen Zeitraums, und deaktiviert, wenn sie nicht verwendet werden.
Die Verwendung wird auf unerwartete Aktivitäten überwacht.		 Microsoft Entra ID verfügt über Funktionen zur Verwaltung externer Identitäten.
Verwenden Sie den verwalteten Gastlebenszyklus mit der Berechtigungsverwaltung. Externe Benutzer werden im Kontext von Apps, Ressourcen und Zugriffspaketen integriert, die Sie für einen begrenzten Zeitraum zulassen und für die Sie regelmäßige Zugriffsüberprüfungen verlangen können. Überprüfungen können zum Entfernen oder Deaktivieren des Kontos führen. Steuern des Zugriffs für externe Benutzer in der Berechtigungsverwaltung
Microsoft Entra ID generiert Risikoereignisse auf Benutzer- und Sitzungsebene. Erfahren Sie, wie Sie unerwartete Aktivitäten, erkennen, darauf reagieren und sich davor schützen. Was bedeutet Risiko?
8.2.8 Wenn eine Benutzersitzung länger als 15 Minuten inaktiv ist, muss sich der Benutzer erneut authentifizieren, um das Terminal oder die Sitzung erneut zu aktivieren. Verwenden Sie Endpunktverwaltungsrichtlinien mit Intune und Microsoft Endpoint Manager. Um den Zugriff von kompatiblen Geräten zuzulassen, verwenden Sie dann den bedingten Zugriff. Legen Sie mithilfe von Konformitätsrichtlinien Regeln für Geräte fest, die Sie mit Intune verwalten
Wenn Ihre CDE-Umgebung auf Gruppenrichtlinienobjekten (Group Policy Objects, GPO) basiert, konfigurieren Sie GPO, um ein Leerlauftimeout festzulegen. Konfigurieren Sie Microsoft Entra ID, um den Zugriff von in Microsoft Entra eingebundenen Hybridgeräten zuzulassen. In Microsoft Entra eingebundene Hybridgeräte

8.3 Starke Authentifizierung für Benutzer und Administratoren wird eingerichtet und verwaltet.

Weitere Informationen zu Microsoft Entra-Authentifizierungsmethoden, die PCI-Anforderungen erfüllen, finden Sie unter Informationsergänzung: Multi-Faktor-Authentifizierung.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
8.3.1 Alle Benutzerzugriffe auf Systemkomponenten werden für Benutzer und Administratoren über mindestens einen der folgenden Authentifizierungsfaktoren authentifiziert:
Etwas, das Ihnen bekannt ist, z. B. ein Kennwort oder eine Passphrase.
Etwas, das Sie haben, z. B. ein Tokengerät oder eine Smartcard.
Etwas, das Sie haben, z. B. biometrisches Merkmal.		 Microsoft Entra ID erfordert kennwortlose Methoden, um die PCI-Anforderungen zu erfüllen.
Weitere Informationen finden Sie unter „Ganzheitliche kennwortlose Bereitstellung“. Planen einer Bereitstellung mit kennwortloser Authentifizierung in Microsoft Entra ID
8.3.2 Starke Kryptografie wird verwendet, um alle Authentifizierungsfaktoren während der Übertragung und Speicherung auf allen Systemkomponenten unlesbar zu machen. Die von Microsoft Entra ID verwendete Kryptografie ist mit der PCI-Definition von starker Kryptografie kompatibel. Microsoft Entra Datenschutzaspekte
8.3.3 Die Benutzeridentität wird überprüft, bevor ein Authentifizierungsfaktor geändert wird. Microsoft Entra ID erfordert, dass sich Benutzer authentifizieren müssen, um ihre Authentifizierungsmethoden über ein Self-Service-Portal zu aktualisieren, z. B. das mysecurityinfo-Portal und das SSPR-Portal (Self-Service-Kennwortzurücksetzung). Einrichten von Sicherheitsinformationen über eine Anmeldeseite
Allgemeine Richtlinie für bedingten Zugriff: Sichern der Registrierung von Sicherheitsinformationen
Self-Service-Kennwortzurücksetzung in Microsoft Entra
Administratoren mit privilegierten Rollen können die Authentifizierungsfaktoren „Global“, „Kennwort“, „Benutzer“, „Authentifizierung“ und „Privilegierter Authentifizierung“ ändern. Rollen mit den geringsten Berechtigungen nach Aufgabe in Microsoft Entra ID. Microsoft empfiehlt die Aktivierung von JIT-Zugriff und Governance für privilegierten Zugriff mithilfe von Microsoft Entra Privileged Identity Management
8.3.4 Ungültige Authentifizierungsversuche werden durch Folgendes eingeschränkt:
Sperren der Benutzer-ID nach höchstens 10 Versuchen.
Festlegen der Sperrdauer auf mindestens 30 Minuten oder bis zur abgeschlossenen Bestätigung der Benutzeridentität.		 Stellen Sie Windows Hello for Business für Windows-Geräte bereit, die Hardware mit TPM (Trusted Platform Module) 2.0 oder höher unterstützen.
Bei Windows Hello for Business bezieht sich die Sperre auf das Gerät. Die Geste, PIN oder Biometrie entsperrt den Zugriff auf das lokale TPM. Administratoren konfigurieren das Sperrverhalten mit GPO- oder Intune-Richtlinien. TPM-Gruppenrichtlinieneinstellungen
Verwalten von Windows Hello for Business auf Geräten zum Zeitpunkt der Registrierung mit Intune
TPM-Grundlagen
Windows Hello for Business funktioniert für die lokale Authentifizierung bei Active Directory- und Cloudressourcen in Microsoft Entra ID.
Bei FIDO2-Sicherheitsschlüsseln bezieht sich der Schutz vor Brute-Force-Angriffen auf den Schlüssel. Die Geste, PIN oder Biometrie entsperrt den Zugriff auf den lokalen Schlüsselspeicher. Administratoren konfigurieren Microsoft Entra ID, um die Registrierung von FIDO2-Sicherheitsschlüsseln von Herstellern zuzulassen, die den PCI-Anforderungen entsprechen. Aktivieren der kennwortlosen Anmeldung mit Sicherheitsschlüssel

Microsoft Authenticator-App
Um Brute-Force-Angriffe mithilfe der kennwortlosen Anmeldung der Microsoft Authenticator-App zu entschärfen, aktivieren Sie den Zahlenabgleich und mehr Kontext.
Microsoft Entra ID generiert im Authentifizierungsfluss eine Zufallszahl. Der Benutzer gibt sie in der Authentificator-App ein. Die Authentifizierungsaufforderung für mobile Apps zeigt den Speicherort, die IP-Adresse der Anforderung und die Anforderungsanwendung an. Verwenden des Zahlenabgleichs in MFA-Benachrichtigungen
Verwenden von zusätzlichem Kontext in Microsoft Authenticator-Benachrichtigungen
8.3.5 Wenn Kennwörter/Passphrasen als Authentifizierungsfaktoren verwendet werden, um die Anforderung 8.3.1 zu erfüllen, werden sie für jeden Benutzer wie folgt festgelegt und zurückgesetzt:
Festlegen eines eindeutigen Werts für die erstmalige Verwendung und beim Zurücksetzen.
Muss unmittelbar nach der ersten Verwendung geändert werden.		 Gilt nicht für Microsoft Entra ID.
8.3.6 Wenn Kennwörter/Passphrasen als Authentifizierungsfaktoren verwendet werden, um der Anforderung 8.3.1 zu genügen, erfüllen sie das folgende Mindestmaß an Komplexität:
Eine Mindestlänge von 12 Zeichen (oder WENN das System keine 12 Zeichen unterstützt, eine Mindestlänge von acht Zeichen).
Sie enthalten sowohl numerische als auch alphabetische Zeichen.		 Gilt nicht für Microsoft Entra ID.
8.3.7 Benutzer dürfen keine neuen Kennwörter/Passphrasen übermittelt, die mit einem/einer der vier zuletzt verwendeten Kennwörter/Passphrasen identisch sind. Gilt nicht für Microsoft Entra ID.
8.3.8 Authentifizierungsrichtlinien und -verfahren werden dokumentiert und allen Benutzern mitgeteilt, einschließlich:
Leitfaden zur Auswahl starker Authentifizierungsfaktoren.
Anleitungen dazu, wie Benutzer ihre Authentifizierungsfaktoren schützen müssen
Anweisung, Kennwörter/Passphrasen nicht wiederzuverwenden
Anweisungen zum Ändern von Kennwörtern/Passphrasen, wenn der Verdacht besteht oder bekannt ist, dass das Kennwort/die Passphrasen kompromittiert wurden, und zum Melden des Vorfalls.		 Dokumentieren Sie Richtlinien und Verfahren, und teilen Sie diese den Benutzern gemäß dieser Anforderung mit. Microsoft stellt anpassbare Vorlagen im Download Center bereit.
8.3.9 Wenn Kennwörter/Passphrasen als einziger Authentifizierungsfaktor für den Benutzerzugriff verwendet werden (d. h. in jeder Implementierung der Single-Factor-Authentifizierung), dann gilt Folgendes: Entweder müssen Kennwörter/Passphrasen mindestens einmal alle 90 Tage geändert werden
ODER
der Sicherheitsstatus von Konten wird dynamisch analysiert, und der Echtzeitzugriff auf Ressourcen wird automatisch entsprechend bestimmt.		 Gilt nicht für Microsoft Entra ID.
8.3.10Zusätzliche Anforderung für Dienstanbieter: Wenn Kennwörter/Passphrasen als einziger Authentifizierungsfaktor für den Benutzerzugriff des Kunden auf Karteninhaberdaten verwendet werden (d. h. bei jeder Implementierung der Single-Faktor-Authentifizierung), erhalten die Kunden einen Leitfaden, der Folgendes umfasst:
Anleitung für Kunden, ihre Benutzerkennwörter/-passphrasen regelmäßig zu ändern.
Anleitung, wann und unter welchen Umständen Kennwörter/Passphrasen geändert werden müssen.		 Gilt nicht für Microsoft Entra ID.
8.3.10.1 Zusätzliche Anforderung für Dienstanbieter: Wenn Kennwörter/Passphrasen als einziger Authentifizierungsfaktor für den Benutzerzugriff verwendet werden (d. h. in jeder Implementierung der Single-Factor-Authentifizierung), dann gilt Folgendes:
Entweder müssen Kennwörter/Passphrasen mindestens einmal alle 90 Tage geändert werden
ODER
der Sicherheitsstatus von Konten wird dynamisch analysiert, und der Echtzeitzugriff auf Ressourcen wird automatisch entsprechend bestimmt.		 Gilt nicht für Microsoft Entra ID.
8.3.11 Wenn Authentifizierungsfaktoren wie physische oder logische Sicherheitstoken, Smartcards oder Zertifikate verwendet werden:
Faktoren werden einem einzelnen Benutzer zugewiesen und von mehreren Benutzern gemeinsam genutzt.
Physische und/oder logische Kontrollen stellen sicher, dass nur der dafür vorgesehene Benutzer den betreffenden Faktor nutzen kann, um Zugriff zu erhalten.		 Verwenden Sie kennwortlose Authentifizierungsmethoden wie Windows Hello for Business, FIDO2-Sicherheitsschlüssel und Microsoft Authenticator-App für die Anmeldung per Telefon. Verwenden Sie Smartcards, die auf öffentlichen oder privaten Schlüsseln basieren, die Benutzern zugeordnet sind, um eine Wiederverwendung zu verhindern.

8.4 Die Multi-Faktor-Authentifizierung (MFA) wird implementiert, um den Zugriff auf die CDE (Cardholder Data Environment) zu schützen.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
8.4.1 MFA wird für Zugriffe, die nicht über die Konsole erfolgen, für Mitarbeiter*innen mit Administratorzugriff in der CDE implementiert. Verwenden Sie den bedingten Zugriff, um eine starke Authentifizierung für den Zugriff auf CDE-Ressourcen zu erfordern. Definieren Sie Richtlinien für eine Administratorrolle oder eine Sicherheitsgruppe, die den Administratorzugriff auf eine Anwendung darstellt.
Verwenden Sie für den Administratorzugriff Microsoft Entra Privileged Identity Management (PIM), um die JIT-Aktivierung (Just-in-Time) von privilegierten Rollen zu aktivieren. Was ist bedingter Zugriff?
Vorlagen für bedingten Zugriff
Erste Schritte mit PIM
8.4.2 MFA wird für alle Zugriffe auf die CDE implementiert. Blockieren Sie den Zugriff auf Legacy-Protokolle, die keine starke Authentifizierung unterstützen. Blockieren von Legacy-Authentifizierung mit Microsoft Entra ID mit bedingtem Zugriff
8.4.3 MFA wird für alle Remotenetzwerkzugriffe von außerhalb des Netzwerks der Entität, die auf die CDE zugreifen oder sie beeinflussen könnte, wie folgt implementiert:
Alle Remotezugriffe durch Mitarbeiter*innen (sowohl Benutzer als auch Administratoren) erfolgt von Geräten außerhalb des Netzwerks der Entität.
Alle Remotezugriffe durch Dritte und Anbieter.		 Integrieren Sie Zugriffstechnologien wie ein virtuelles privates Netzwerk (VPN), einen Remotedesktop und Netzwerkzugriffspunkte für die Authentifizierung und Autorisierung in Microsoft Entra ID. Verwenden Sie bedingten Zugriff, um eine starke Authentifizierung für den Zugriff auf Remotezugriffsanwendungen zu verlangen. Vorlagen für bedingten Zugriff

8.5 Multi-Faktor-Authentifizierungssysteme (MFA) werden so konfiguriert, dass Missbrauch verhindert wird.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
8.5.1 MFA-Systeme werden wie folgt implementiert:
Das MFA-System ist nicht anfällig für Replay-Angriffe.
MFA-Systeme können für einen begrenzten Zeitraum nicht von Benutzern umgangen werden, einschließlich Administratoren, es sei denn, es wurde ausdrücklich dokumentiert und vom Management ausnahmsweise für einen begrenzten Zeitraum autorisiert.
Es werden mindestens zwei verschiedene Arten von Authentifizierungsfaktoren verwendet.
Alle Authentifizierungsfaktoren müssen erfolgreich verwendet werden, bevor Zugriff gewährt wird.		 Die empfohlenen Microsoft Entra-Authentifizierungsmethoden verwenden Nonce oder Herausforderungen. Die Methoden sind widerstandsfähig gegen Replay-Angriffe, da Microsoft Entra ID wiederholte Authentifizierungstransaktionen erkennt.
Windows Hello for Business, FIDO2- und Microsoft Authenticator-App für die kennwortlose Anmeldung per Telefon verwenden eine Nonce, um die Anforderung zu identifizieren und Replay-Angriffsversuche zu erkennen. Verwenden Sie kennwortlose Anmeldeinformationen für Benutzer in der CDE.
Die zertifikatbasierte Authentifizierung verwendet Herausforderungen, um Replay-Angriffsversuche zu erkennen.
NIST Authenticator Assurance Level 2 mit Microsoft Entra ID
NIST Authenticator Assurance Level 3 mithilfe von Microsoft Entra ID

8.6 Die Verwendung von Anwendungs- und Systemkonten sowie der zugehörigen Authentifizierungsfaktoren wird streng kontrolliert.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
8.6.1 Wenn von Systemen oder Anwendungen genutzte Konten für die interaktive Anmeldung verwendet werden können, werden sie wie folgt verwaltet:
Die interaktive Nutzung wird verhindert, sofern dies nicht aufgrund eines außergewöhnlichen Umstands erforderlich ist.
Die interaktive Nutzung ist auf den Zeitraum beschränkt, der für den außergewöhnlichen Umstand erforderlich ist.
Die geschäftliche Begründung für die interaktive Nutzung wird dokumentiert.
Die interaktive Verwendung wird vom Management explizit genehmigt.
Die Identität einzelner Benutzer wird bestätigt, bevor der Zugriff auf das Konto gewährt wird.
Jede ausgeführte Aktion lässt sich einem einzelnen Benutzer zuordnen.		 Für CDE-Anwendungen mit moderner Authentifizierung und für in Azure bereitgestellte CDE-Ressourcen, die eine moderne Authentifizierung verwenden, verfügt Microsoft Entra ID über zwei Arten von Dienstkonten für Anwendungen: verwaltete Identitäten und Dienstprinzipale.
Weitere Informationen zur Governance von Microsoft Entra-Dienstkonten: Planung, Bereitstellung, Lebenszyklus, Überwachung, Zugriffsüberprüfungen usw. Verwalten von Microsoft Entra-Dienstkonten
So schützen Sie Microsoft Entra-Dienstkonten. Schützen verwalteter Identitäten in Microsoft Entra ID
Schützen von Dienstprinzipalen in Microsoft Entra ID
Für CDEs mit Ressourcen außerhalb von Azure, die Zugriff benötigen, konfigurieren Sie Workloadidentitätsverbunde, ohne Geheimnisse oder interaktive Anmeldungen zu verwalten. Workloadidentitätsverbund
Um Genehmigungs- und Nachverfolgungsprozesse zur Erfüllung von Anforderungen zu ermöglichen, orchestrieren Sie Workflows mithilfe von IT Service Management (ITSM) und Datenbanken für die Konfigurationsverwaltung (CMDB). Diese Tools verwenden die MS Graph-API, um mit Microsoft Entra ID zu interagieren und das Dienstkonto zu verwalten.
Für CDEs, die Dienstkonten erfordern, die mit lokalem Active Directory kompatibel sind, verwenden Sie gruppenverwaltete Dienstkonten (Group Managed Service Accounts, GMSAs) und eigenständige verwaltete Dienstkonten (sMSA), Computerkonten oder Benutzerkonten. Schützen lokaler Dienstkonten
8.6.2 Kennwörter/Passphrasen für alle Anwendungs- und Systemkonten, die für die interaktive Anmeldung verwendet werden können, werden in Skripts, Konfigurations-/Eigenschaftsdateien oder maßgeschneidertem und benutzerdefiniertem Quellcode nicht hartcodiert. Verwenden Sie moderne Dienstkonten wie verwaltete Azure-Identitäten und Dienstprinzipale, die keine Kennwörter erfordern.
Anmeldeinformationen für verwaltete Microsoft Entra-Identitäten werden bereitgestellt und in der Cloud rotiert, wodurch die Verwendung gemeinsamer Geheimnisse wie Kennwörter und Passphrasen verhindert wird. Bei Verwendung systemseitig zugewiesener verwalteter Identitäten ist der Lebenszyklus an den der zugrunde liegenden Azure-Ressource gebunden.
Verwenden Sie Dienstprinzipale, um Zertifikate als Anmeldeinformationen zu verwenden zu können, wodurch die Verwendung gemeinsamer Geheimnisse wie Kennwörter und Passphrasen verhindert wird. Wenn Zertifikate nicht praktikabel sind, verwenden Sie Azure Key Vault, um Clientgeheimnisse des Dienstprinzipals zu speichern. Best Practices für die Verwendung von Azure Key Vault
Für CDEs mit Ressourcen außerhalb von Azure, die Zugriff benötigen, konfigurieren Sie Workloadidentitätsverbunde, ohne Geheimnisse oder interaktive Anmeldungen zu verwalten. Workloadidentitätsverbund
Stellen Sie den bedingten Zugriff für Workloadidentitäten bereit, um die Autorisierung basierend auf Standort und/oder Risikostufe zu steuern. Bedingter Zugriff für Workloadidentitäten
Verwenden Sie zusätzlich zu den vorherigen Anleitungen Codeanalysetools, um hartcodierte Geheimnisse in Code und Konfigurationsdateien zu erkennen. Erkennen von offengelegten Geheimnissen im Code
Sicherheitsregeln
8.6.3 Kennwörter/Passphrasen für alle Anwendungs- und Systemkonten werden wie folgt gegen Missbrauch geschützt:
Kennwörter/Passphrasen werden regelmäßig (in der Häufigkeit, die in der gezielten Risikoanalyse der Entität definiert ist, die nach allen in Anforderung 12.3.1 angegebenen Elementen durchgeführt wird) und bei Verdacht oder Bestätigung einer Kompromittierung geändert.
Kennwörter/Passphrasen werden mit ausreichender Komplexität erstellt, je nachdem, wie häufig die Entität die Kennwörter/Passphrasen ändert.		 Verwenden Sie moderne Dienstkonten wie verwaltete Azure-Identitäten und Dienstprinzipale, die keine Kennwörter erfordern.
Für Ausnahmen, die Dienstprinzipale mit Geheimnissen erfordern, abstrahieren Sie den Lebenszyklus von Geheimnissen mit Workflows und Automatisierungen, die zufällige Passwörter für Dienstprinzipale festlegen, sie regelmäßig wechseln und auf Risikoereignisse reagieren.
Sicherheitsteams können von Microsoft Entra generierte Berichte überprüfen und korrigieren, z. B. risikobehaftete Workloadidentitäten. Schützen von Workloadidentitäten mit Identity Protection

Nächste Schritte

Die Anforderungen des Datensicherheitsstandards der Zahlungskartenbranche (Payment Card Industry Data Security Standard, PCI-DSS) 3, 4, 9 und 12 gelten nicht für Microsoft Entra ID. Daher gibt es keine entsprechenden Artikel. Alle Anforderungen finden Sie auf pcisecuritystandards.org: Offizielle Website des PCI Security Standards Council.

Informationen zum Konfigurieren von Microsoft Entra ID zur Einhaltung der PCI-DSS-Anforderungen finden Sie in den folgenden Artikeln.