Identitäts- und Zugriffsverwaltung für einen AKS regulierten Cluster für PCI DSS 4.0.1

In diesem Artikel werden Überlegungen zur Identitäts- und Zugriffsverwaltung für einen Azure Kubernetes Service (AKS)-Cluster beschrieben, der gemäß dem Data Security Standard (PCI-DSS 4.0.1) konfiguriert ist.

Dieser Artikel ist Teil einer Serie. Die Einführung finden Sie hier.

Kubernetes verfügt über eine native rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), die Berechtigungen für die Kubernetes-API verwaltet. Es gibt mehrere integrierte Rollen mit bestimmten Berechtigungen oder Aktionen für Kubernetes-Ressourcen. Azure Kubernetes Service (AKS) unterstützt diese integrierten Rollen sowie benutzerdefinierte Rollen, um eine granulare Steuerung zu ermöglichen. Diese Aktionen können für einen Benutzer über Kubernetes RBAC autorisiert oder verweigert werden.

Diese Architektur und die Implementierung sind nicht für die Bereitstellung von Kontrollmöglichkeiten für den physischen Zugriff auf lokale Ressourcen oder Rechenzentren konzipiert. Ein Vorteil des Hostings Ihrer CDE in Azure im Gegensatz zum Hosten Ihrer Plattform im Edgebereich oder in Ihrem Rechenzentrum besteht darin, dass die Einschränkung des physischen Zugriffs größtenteils bereits über die Sicherheitsvorkehrungen des Azure-Rechenzentrums erfolgt. Es gibt keine Zuständigkeiten für die Organisation der Verwaltung physischer Hardware.

Implementieren strikter Maßnahmen zur Zugriffssteuerung

Anforderung 7: Einschränken des Zugriffs auf Kartenhalterdaten nach Geschäftsanforderungen

Unterstützung von AKS-Features

AKS ist vollständig mit Microsoft Entra ID als Identitätsanbieter integriert.

Sie müssen keine separaten Benutzeridentitäten und Anmeldeinformationen für Kubernetes verwalten. Sie können Microsoft Entra-Benutzer*innen für Kubernetes-RBAC hinzufügen. Durch diese Integration können Microsoft Entra-Benutzern Rollen zugewiesen werden. Mithilfe von Microsoft Entra-Identitäten können Sie eine Vielzahl integrierter Rollen wie Viewer, Writer, Dienstadministrator und Clusteradministrator verwenden. Darüber hinaus können Sie benutzerdefinierte Rollen für eine granularere Steuerung erstellen.

Standardmäßig ist Azure RBAC so festgelegt, dass der Zugriff verweigert wird, sodass auf eine Ressource nicht zugegriffen werden kann, ohne dass Berechtigungen erteilt werden. AKS schränkt den SSH-Zugriff auf AKS-Workerknoten ein und verwendet die AKS-Netzwerkrichtlinie, um den Zugriff auf Workloads in den Pods zu steuern.

Weitere Informationen finden Sie unter Verwenden von Azure RBAC für Kubernetes-Autorisierung und Sichern Ihres Clusters mit Azure-Richtlinie.

Ihre Zuständigkeiten

Anforderung 7.1

PCI DSS 4.0.1 ermöglicht einen angepassten Ansatz zur Zugriffssteuerung, sofern die Sicherheitsziele erfüllt sind und der Ansatz vollständig dokumentiert und gerechtfertigt ist. Organisationen können alternative Steuerelemente implementieren, wenn sie gleichwertige oder bessere Sicherheitsergebnisse nachweisen können.

Beschränken Sie den Zugriff auf Systemkomponenten und Karteninhaberdaten auf diejenigen Personen, deren Funktion einen solchen Zugriff erfordert.

Ihre Zuständigkeiten

Berücksichtigen Sie die folgenden bewährten Methoden:

• Stellen Sie sicher, dass Ihre Implementierung den Anforderungen der Organisation und den Complianceanforderungen zur Identitätsverwaltung entspricht.
• Minimieren Sie die ständigen Berechtigungen, insbesondere für Konten mit schwerwiegenden Folgen.
• Befolgen Sie das Prinzip der geringsten Rechte für Zugriffe. Stellen Sie lediglich ausreichende Zugriffsrechte bereit, um die Aufgabe zu erledigen.

Anforderung 7.1.1

PCI DSS 4.0.1 verdeutlicht die Notwendigkeit einer kontinuierlichen Überprüfung und Dokumentation der Zugriffsanforderungen für jede Rolle und erfordert, dass der Zugriff regelmäßig überprüft und aktualisiert werden muss, wenn sich Die Auftragsfunktionen ändern.

Definieren Sie die Zugriffsanforderungen für die einzelnen Rollen, einschließlich:

• Systemkomponenten und Datenressourcen, auf die jede Rolle für ihre Auftragsfunktion zugreifen muss.
• Erforderliche Berechtigungsstufe (z. B. Benutzer, Administrator usw.) für den Zugriff auf Ressourcen

Ihre Zuständigkeiten

Definieren Sie Rollen basierend auf den Aufgaben und Zuständigkeiten, die für die Komponenten im Bereich und deren Interaktion mit Azure-Ressourcen erforderlich sind. Sie können mit umfassenden Kategorien beginnen, z. B.:

• Umfang nach Azure-Verwaltungsgruppen, Abonnements oder Ressourcengruppen.
• Azure-Richtlinie für die Workload oder das Abonnement.
• Containervorgänge.
• Geheime Verwaltung.
• Erstellen und Bereitstellen von Pipelines

Konzentrieren Sie sich auf die Anforderung der Workload, obwohl die Definition von Rollen und Zuständigkeiten in Bezug auf diese Bereiche von der Teamstruktur abhängen kann. Bestimmen Sie beispielsweise, wer für die Aufrechterhaltung von Sicherheit, Isolation, Bereitstellung und Observability verantwortlich ist. Hier sind einige Beispiele für Verantwortlichkeiten:

• Festlegen von Konfigurationen für Anwendungssicherheit, Kubernetes-RBAC, Netzwerkrichtlinien, Azure-Richtlinien und die Kommunikation mit anderen Diensten.
• Konfigurieren und Verwalten von Azure Firewall, Web Application Firewall (WAF), Netzwerksicherheitsgruppen (NSGs) und DNS.
• Überwachen und Korrigieren von Serversicherheit, Patching, Konfiguration, Endpunktsicherheit usw.
• Festlegen von Anweisungen für die Verwendung von RBAC, Microsoft Defender for Cloud, der Administrator-Schutzstrategie und Azure Policy zum Steuern von Azure-Ressourcen.
• Identifizieren des Teams für die Überwachung und Reaktion auf Vorfälle. Untersuchen und Beheben von Sicherheitsvorfällen unter Verwendung eines SIEM-Systems (Security Information and Event Management) wie Microsoft Sentinel oder Microsoft Defender for Cloud.

Formalisieren Sie dann die Definition, indem Sie die erforderliche Zugriffsebene für die Rolle in Bezug auf die Workload und die Infrastruktur bestimmen. Die folgende Tabelle enthält einige Beispiele für Rollen, deren Zuständigkeiten und die Zugriffsstufen, die möglicherweise erforderlich sind:

Anforderung 7.1.2

PCI DSS 4.0.1 betont die Minimierung von ständigen Berechtigungen und fördert die Verwendung von JIT-Zugriffsrichtlinien (Just-in-Time) und Richtlinien für bedingten Zugriff. Es ist eine erweiterte Überwachung und Warnung für privilegierten Zugriff erforderlich.

Beschränken Sie den Zugriff auf privilegierte Benutzer-IDs auf die geringsten Rechte, die für die Ausführung von Aufgaben erforderlich sind.

Ihre Zuständigkeiten

Versuchen Sie, Zugriffsrechte basierend auf den Jobfunktionen zu minimieren, ohne Störungen zu verursachen. Berücksichtigen Sie die folgenden bewährten Methoden:

• Verringern Sie den Zugriff, den jede Identität benötigt. Eine Identität sollte gerade genug Zugriffsrechte haben, um ihre Aufgabe zu erledigen.
• Minimieren Sie die ständigen Berechtigungen, insbesondere für Identitäten mit schwerwiegenden Auswirkungen, die Zugriff auf Komponenten im Bereich haben.
• Fügen Sie nach Möglichkeit zusätzliche Einschränkungen hinzu. Eine Möglichkeit besteht darin, basierend auf Zugriffskriterien einen bedingten Zugriff zu ermöglichen.
• Führen Sie eine regelmäßige Überprüfung und Überwachung von Benutzern und Gruppen durch, die in Ihren Abonnements Zugriff haben, auch für Lesezugriff. Vermeiden Sie das Einladen externer Identitäten.

Anforderung 7.1.3

Zugriffszuweisungen müssen kontinuierlich überprüft und aktualisiert werden, um Änderungen an Personal- oder Stellenfunktionen widerzuspiegeln. PCI DSS 4.0.1 erfordert, dass alle Zugriffszuweisungen dokumentiert und gerechtfertigt sind.

Weisen Sie den Zugriff auf der Grundlage der Stellenklassifizierung und der Funktion der einzelnen Mitarbeiter zu.

Ihre Zuständigkeiten

Bestimmen Sie Berechtigungen basierend auf den klar zugewiesenen Auftragspflichten der jeweiligen Person. Vermeiden Sie Parameter wie System oder Anstellung des Mitarbeiters. Erteilen Sie einem einzelnen Benutzer oder einer Gruppe Zugriffsrechte.

Hier sind einige Beispiele für Auftragsklassifizierungen und die zugehörigen Rollen:

Anforderung 7.1.4

PCI DSS 4.0.1 erfordert, dass alle Berechtigungszuweisungen und Änderungen von autorisierten Parteien genehmigt und dokumentiert werden und dass der Genehmigungsprozess überwacht werden kann.

Fordern Sie eine dokumentierte Genehmigung durch autorisierte Stellen an, die die erforderlichen Berechtigungen festlegen.

Ihre Zuständigkeiten

Verfügbarkeit eines geschlossenen Prozesses zum Genehmigen von Änderungen an Rollen und Berechtigungen, einschließlich der anfänglichen Zuweisung von Berechtigungen. Sicherstellen, dass diese Genehmigungen dokumentiert werden und für Überprüfungen verfügbar sind.

Anforderung 7.2

PCI DSS 4.0.1 erfordert, dass Zugriffssteuerungssysteme kontinuierliche Überwachung und Warnung für nicht autorisierte Zugriffsversuche unterstützen und dass alle Zugriffssteuerungsrichtlinien regelmäßig überprüft und aktualisiert werden.

Richten Sie ein Zugriffssteuerungssystem für Systemkomponenten ein, das den Zugriff je nach erforderlichem Maß eines Benutzers einschränkt und auf „Alles verweigern“ eingestellt ist, sofern dies nicht ausdrücklich erlaubt ist.

Ihre Zuständigkeiten

Nach Befolgung von Anforderung 7.1 sollten Sie die Rollen und Zuständigkeiten beurteilt haben, die für Ihre Organisation und die Workload gelten. Alle Komponenten in der Architektur, die sich im Bereich befinden, müssen eingeschränkten Zugriff haben. Dies umfasst die AKS-Knoten, die die Workload ausführen, den Datenspeicher, den Netzwerkzugriff und alle anderen Dienste, die an der Verarbeitung der Karteninhaberdaten (Card Holder Data, CHD) beteiligt sind.

Weisen Sie basierend auf Rollen und Zuständigkeiten Rollen dem rollenbasierten Zugriffssteuerungsmechanismus (RBAC) der Infrastruktur zu, z. B.:

• Kubernetes RBAC: Ein systemeigenes Kubernetes-Autorisierungsmodell, das den Zugriff auf die Kubernetes-Steuerungsebene steuert, die über den Kubernetes-API-Server verfügbar gemacht wird. Dieser Berechtigungssatz definiert die möglichen API-Serverfunktionen. Sie können beispielsweise einem Benutzer die Berechtigungen zum Erstellen oder sogar zum Auflisten von Pods verweigern.
• Azure RBAC: Ein auf Microsoft Entra ID basierendes Autorisierungsmodell, das den Zugriff auf die Azure-Kontrollebene steuert. Hierbei handelt es sich um eine Zuordnung des Microsoft Entra-Mandanten zum Azure-Abonnement. Mit Azure-RBAC können Sie Berechtigungen zum Erstellen von Azure-Ressourcen wie Netzwerken, AKS-Clustern und verwalteten Identitäten erteilen.

Angenommen, Sie müssen den Clusteroperatoren (der Infrastrukturoperatorrolle zugeordnet) Berechtigungen erteilen. Alle Personen, denen die Zuständigkeiten von Infrastrukturoperator*innen zugewiesen wurden, gehören zu einer Microsoft Entra-Gruppe. Laut 7.1.1 erfordert diese Rolle die höchsten Berechtigungen im Cluster. Kubernetes verfügt über integrierte RBAC-Rollen wie cluster-admin, die diese Anforderungen erfüllen. Sie müssen die Microsoft Entra-Gruppe für den Infrastrukturoperator cluster-admin binden, indem Sie Rollenbindungen erstellen, indem Sie die integrierten Rollen auswählen. Wenn die integrierten Rollen Ihre Anforderungen nicht erfüllen (z. B. sind sie möglicherweise übermäßig zulässig), können Sie benutzerdefinierte Rollen für Ihre Bindungen erstellen.

Die Referenzimplementierung veranschaulicht das obige Beispiel mit nativer Kubernetes-RBAC. Die gleiche Zuordnung kann mit Azure-RBAC erreicht werden. Weitere Informationen finden Sie unter "Steuern des Zugriffs auf Clusterressourcen mithilfe von Kubernetes rollenbasierter Zugriffssteuerung und Microsoft Entra-Identitäten in Azure Kubernetes Service (AKS)".

Sie können den Berechtigungsbereich auf Clusterebene oder auf Namespaceebene festlegen. Für Rollen mit bereichsgebundenen Zuständigkeiten, z. B. Anwendungsoperatoren, werden die Berechtigungen auf Namespaceebene für die Workload zugewiesen.

Darüber hinaus benötigen die Rollen auch Azure-RBAC-Berechtigungen, damit sie ihre Aufgaben erledigen können. Der Clusteroperator muss beispielsweise über das Portal auf Azure Monitor zugreifen. Daher muss die Infrastrukturoperatorrolle über die entsprechende RBAC-Zuweisung verfügen.

Neben Personen und ihren Rollen, Azure-Ressourcen und sogar Pods innerhalb des Clusters verfügen sie über verwaltete Identitäten. Diese Identitäten benötigen eine Reihe von Berechtigungen über Azure RBAC und müssen basierend auf den erwarteten Aufgaben eng auf den Bereich ausgerichtet sein. Azure Application Gateway muss beispielsweise über Berechtigungen zum Abrufen von Geheimnissen (TLS-Zertifikaten) aus Azure Key Vault verfügen, darf aber keine Berechtigungen zum Ändern von Geheimnissen haben.

Nachstehend finden Sie einige bewährte Methoden für die Verwaltung von Zugriffssteuerungsmaßnahmen:

• Unterhalten Sie eine akkurate Dokumentation zu jeder Rolle und den zugewiesenen Berechtigungen sowie den Begründungen hierfür. Unterscheiden Sie klar, welche Berechtigungen JIT-Berechtigungen und welche ständige Berechtigungen sind.
• Überwachen Sie die Rollen auf Änderungen, z. B. in Arbeitsauftragsänderungen oder Rollendefinitionen. Erstellen Sie Benachrichtigungen zu Änderungen, auch wenn diese erwartet werden, um einen Einblick in die Absichten hinter den Änderungen zu erhalten.

Anforderung 7.2.1

PCI DSS 4.0.1 erfordert, dass Zugriffssteuerungsmaßnahmen alle Systemkomponenten, einschließlich Cloud- und Hybridumgebungen, abdecken und die Kontrollen kontinuierlich auf Effektivität überwacht werden.

Ihre Zuständigkeiten

Berücksichtigen Sie die folgenden bewährten Methoden:

• Gewähren Sie keinen ständigen Zugriff. Erwägen Sie die Verwendung von Just-In-Time-Gruppenmitgliedschaften in Azure AD. Dieses Feature erfordert Microsoft Entra Privileged Identity Management.

• Richten Sie Richtlinien für bedingten Zugriff in Microsoft Entra ID für Ihren Cluster ein. Dadurch wird der Zugriff auf die Kubernetes-Steuerebene weiter eingeschränkt. Mit Richtlinien für bedingten Zugriff können Sie Multi-Faktor-Authentifizierung vorschreiben, die Authentifizierung auf Geräte beschränken, die von Ihrem Microsoft Entra-Mandanten verwaltet werden, oder untypische Anmeldeversuche blockieren. Wenden Sie diese Richtlinien auf Microsoft Entra-Gruppen an, die Kubernetes-Rollen mit hohen Berechtigungen zugeordnet sind.

  Hinweis

  Unabhängig davon, welche Technologie Sie auswählen (JIT-Zugriff oder bedingter Zugriff), sind Microsoft Entra ID P1- oder P2-Lizenzen erforderlich.

• Deaktivieren Sie idealerweise den SSH-Zugriff auf die Clusterknoten. Diese Referenzimplementierung generiert keine SSH-Verbindungsdetails für diesen Zweck.

• Der Zugriff auf alle zusätzlichen Computeressourcen, z. B. Jumpboxen, muss durch autorisierte Benutzer erfolgen. Erstellen Sie keine generischen Anmeldungen, die für das gesamte Team verfügbar sind.

Anforderung 7.2.2

Zugriffsberechtigungen müssen basierend auf der Auftragsklassifizierung und -funktion zugewiesen und überprüft werden und aktualisiert werden, wenn rollen geändert werden. PCI DSS 4.0.1 erfordert, dass dieser Prozess dokumentiert und auditierbar ist.

Zuweisung von Berechtigungen an Einzelpersonen auf der Grundlage von Stellenklassifizierung und Funktion.

Ihre Zuständigkeiten

Gemäß 7.1.3 sind viele Rollen an Clustervorgängen beteiligt. Über die standardmäßigen Azure-Ressourcenrollen hinaus müssen Sie Umfang und Prozess des Zugriffs definieren.

Betrachten Sie beispielsweise die Clusteroperatorrolle. Sie sollte über ein klar definiertes Playbook für Clusterselektierungsaktivitäten verfügen. Wie unterschiedlich ist dieser Zugriff im Workloadteam? Je nach Organisation können diese auch identisch sein. Beachten Sie folgende Punkte:

• Wie soll der Zugriff auf den Cluster erfolgen?
• Auf welche Quellen ist ein Zugriff zulässig?
• Welche Berechtigungen sollten für den Cluster erteilt werden?
• Wann werden diese Berechtigungen zugewiesen?

Stellen Sie sicher, dass die Definitionen in der Governancedokumentation, Richtlinien und Schulungsmaterial für Workloadoperator und Clusteroperator dokumentiert sind.

Anforderung 7.2.3

PCI DSS 4.0.1 erfordert, dass die Standardeinstellung "Alle verweigern" erzwungen und regelmäßig durch automatisierte Tests und Überwachung überprüft wird.

Ihre Zuständigkeiten

Beginnen Sie mit Zero-Trust Richtlinien, wenn Sie die Konfiguration beginnen. Machen Sie bei Bedarf Ausnahmen, und dokumentieren Sie diese detailliert.

• Kubernetes-RBAC implementiert standardmäßig die Einstellung Alles verweigern. Setzen Sie diese Einstellung nicht außer Kraft, indem Sie äußerst freizügige Clusterrollenbindungen hinzufügen, die die Einstellung „Alles verweigern“ umkehren.
• Azure.RBAC implementiert standardmäßig ebenfalls die Einstellung Alles verweigern. Setzen Sie diese Einstellung nicht außer Kraft, indem Sie RBAC-Zuweisungen hinzufügen, die die Einstellung „Alles verweigern“ umkehren.
• Alle Azure-Dienste, einschließlich Azure Key Vault und Azure Container Registry, verweigern standardmäßig alle Berechtigungen.
• Alle Verwaltungszugriffspunkte, z. B. eine Jumpbox, sollten in der Erstkonfiguration jeglichen Zugriff verweigern. Alle erhöhten Berechtigungen müssen explizit definiert werden, um die „Alles verweigern“-Regel außer Kraft zu setzen.

Anforderung 7.3

PCI DSS 4.0.1 setzt voraus, dass Sicherheitsrichtlinien und betriebliche Verfahren zum Einschränken des Zugriffs auf Karteninhaberdaten kontinuierlich überprüft, aktualisiert und allen betroffenen Parteien mitgeteilt werden.

Stellen Sie sicher, dass Sicherheitsrichtlinien und betriebliche Verfahren für das Einschränken des Zugriffs auf Daten von Karteninhabern dokumentiert und verwendet werden sowie allen beteiligten Parteien bekannt sind.

Ihre Zuständigkeiten

Es ist wichtig, dass Sie eine umfassende Dokumentation zu den Prozessen und Richtlinien führen. Dies umfasst Richtlinien für Azure- und Kubernetes-RBAC sowie Governancerichtlinien für Organisationen. Personen, die in regulierten Umgebungen arbeiten, müssen geschult werden, informiert sein und Anreize erhalten, damit sie die Sicherheitsgarantien unterstützen. Dies ist besonders wichtig für Personen, die aus Richtliniensicht Teil des Genehmigungsprozesses sind.

Anforderung 8: Identifizieren und Authentifizieren des Zugriffs auf Systemkomponenten

Unterstützung von AKS-Features

Durch die Integration von AKS und Microsoft Entra können Sie Identitätsverwaltungs- und Autorisierungsfunktionen nutzen, beispielsweise Zugriffsverwaltung, Verwaltung von Bezeichnerobjekten u. v. m. Weitere Informationen finden Sie unter Von AKS verwaltete Microsoft Entra-Integration.

Ihre Zuständigkeiten

Anforderung 8.1

PCI DSS 4.0.1 erweitert anforderungen für die eindeutige Identifikation und Authentifizierung, einschließlich der kontinuierlichen Überwachung von Benutzerkonten und automatisierten Warnungen für verdächtige Aktivitäten. Organisationen müssen Prozesse zur regelmäßigen Überprüfung und Entfernung unnötiger Konten implementieren.

Definieren und implementieren Sie wie folgt Richtlinien und Verfahren, um eine ordnungsgemäße Identifizierungsverwaltung für Benutzer (außer Endverbraucher) und Administratoren in allen Systemkomponenten sicherzustellen:

Ihre Zuständigkeiten

Nachstehend finden Sie allgemeine Überlegungen zu dieser Anforderung:

GILT FÜR 8.1.1, 8.1.2, 8.1.3

Achten Sie darauf, dass Identitäten für funktional verschiedene Teile der CDE nicht gemeinsam oder wiederverwendet werden. Verwenden Sie beispielsweise kein Teamkonto, um auf Daten oder Clusterressourcen zuzugreifen. Stellen Sie sicher, dass die Identitätsdokumentation klar macht, keine gemeinsam verwendeten Konten zu verwenden.

Erweitern Sie dieses Identitätsprinzip auf Zuweisungen verwalteter Identitäten in Azure. Verwenden Sie keine vom Benutzer verwalteten Identitäten in Azure-Ressourcen gemeinsam. Weisen Sie jeder Azure-Ressource eine eigene verwaltete Identität zu. Wenn Sie die Microsoft Entra Workload-ID im AKS-Cluster verwenden, stellen Sie auch sicher, dass jede Komponente in Ihrer Workload eine eigene Identität erhält, anstatt eine im Bereich breite Identität zu verwenden. Teilen Sie niemals dieselbe verwaltete Identität zwischen Produktions- und Nicht-Produktionsumgebungen.

Weitere Informationen finden Sie unter Access- und Identitätsoptionen für Azure Kubernetes Service (AKS).For more information, see Access and identity options for Azure Kubernetes Service (AKS).

GILT FÜR 8.1.2, 8.1.3, 8.1.4

Verwenden Sie Microsoft Entra ID als Identitätsspeicher. Da der Cluster und alle Azure-Ressourcen Microsoft Entra ID verwenden, gilt das Deaktivieren oder Widerrufen des Zugriffs eines Prinzipals automatisch für alle Ressourcen. Wenn es Komponenten gibt, die nicht direkt von Microsoft Entra ID unterstützt werden, ist ein Prozess zum Entfernen des Zugriffs erforderlich. Beispielsweise müssen SSH-Anmeldeinformationen für den Zugriff auf eine Jumpbox u. U. explizit entfernt werden, wenn der Benutzer nicht mehr gültig ist.

GILT FÜR 8.1.5

Nutzen Sie Microsoft Entra External ID zum Hosten von Drittanbieter-B2B-Konten (z. B. Anbietern und Partnern) als Gastbenutzer. Gewähren Sie die entsprechende Zugriffsebene mithilfe von bedingten Richtlinien, um Unternehmensdaten zu schützen. Diese Konten müssen über minimale ständige Berechtigungen und obligatorische Ablauftermine verfügen. Weitere Informationen finden Sie unter B2B Collaboration mit externen Gästen für Ihre Mitarbeitenden.

Ihre Organisation sollte über ein klares und dokumentiertes Muster für den Zugriff von Anbietern und ähnlichen Zugriffen verfügen.

GILT FÜR 8.1.6, 8.1.7, 8.1.8

Microsoft Entra ID umfasst ein intelligentes Sperrfeature, um Benutzer nach fehlerhaften Anmeldeversuchen zu sperren. Zum Implementieren von Sperren wird die Verwendung von Microsoft Entra-Richtlinien für bedingten Zugriff empfohlen.

Implementieren Sie die Sperre für Komponenten, die ähnliche Features unterstützen, sich aber nicht auf Microsoft Entra ID stützen (z. B. SSH-fähige Computer wie eine Jumpbox). Dadurch wird sichergestellt, dass Sperren aktiviert sind, um missbräuchliche Zugriffsversuche zu verhindern oder zu verlangsamen.

AKS-Knoten sind nicht für den routinemäßigen Zugriff konzipiert. Blockieren Sie den direkten SSH- oder Remotedesktopzugriff auf Clusterknoten. Ein SSH-Zugriff sollte nur im Rahmen erweiterter Problembehandlungsmaßnahmen erwogen werden. Der Zugriff sollte genau überwacht und sofort nach Abschluss des jeweiligen Vorfalls rückgängig gemacht werden. Achten Sie dabei darauf, dass Änderungen auf Knotenebene dazu führen können, dass Ihr Cluster nicht mehr unterstützt wird.

Anforderung 8.2

PCI DSS 4.0.1 aktualisiert Kennwort- und Authentifizierungsanforderungen, um die anforderungen an moderne bewährte Methoden zur Sicherheit anzupassen, einschließlich längerer Mindestkennwortlängen, Komplexitätsanforderungen und Unterstützung für Kennwortlose Authentifizierungsmethoden. Eine erweiterte Überwachung von Authentifizierungsereignissen ist erforderlich.

Sorgen Sie neben der Zuweisung einer eindeutigen ID für eine ordnungsgemäße Authentifizierungsverwaltung für Benutzer (außer Endverbraucher) und Administratoren in allen Systemkomponenten, indem Sie mindestens eine der folgenden Methoden zum Authentifizieren aller Benutzer einsetzen:

• Etwas, das Sie kennen, z. B. ein Kennwort oder eine Passphrase.
• Etwas, das Sie haben, z. B. ein Tokengerät oder eine Smartcard.
• Etwas, das Sie sind, z. B. ein biometrisches Element.

Ihre Zuständigkeiten

Richten Sie Richtlinien für bedingten Zugriff in Microsoft Entra ID für Ihren Cluster ein. Dadurch wird der Zugriff auf die Kubernetes-Steuerebene weiter eingeschränkt.

Einige der oben genannten Anforderungen werden automatisch von Microsoft Entra ID erfüllt. Hier sind einige Beispiele:

• Kennwortsicherheit

  Microsoft Entra ID umfasst Features, mit denen die Verwendung von sicheren Kennwörtern erzwungen wird. Schwache Kennwörter, die zur globalen Liste gesperrter Kennwörter gehören, werden beispielsweise blockiert. Dies ist kein ausreichender Schutz. Um eine organisationsspezifische Sperrliste zu erstellen, sollten Sie erwägen, die Kennwortschutzfunktion von Microsoft Entra hinzuzufügen. Standardmäßig wird eine Kennwortrichtlinie angewendet. Bestimmte Richtlinien können nicht geändert werden und decken einige der oben genannten Anforderungen ab. Dazu gehören Kennwortablauf und zulässige Zeichen. Die vollständige Liste finden Sie unter Microsoft Entra-Kennwortrichtlinien. Erwägen Sie eine erweiterte Durchsetzung mithilfe von Richtlinien für bedingten Zugriff, z. B. Richtlinien, die auf dem Benutzerrisiko basieren, mit denen kompromittierte Benutzername/Kennwort-Paare erkannt werden. Weitere Informationen finden Sie unter Bedingter Zugriff: Auf dem Benutzerrisiko basierender bedingter Zugriff.

  Hinweis

  Es wird dringend empfohlen, kennwortlose Optionen zu berücksichtigen. Weitere Informationen finden Sie unter Planen einer kennwortlosen Authentifizierungsbereitstellung in microsoft Entra ID.

• Überprüfung der Benutzeridentität

  Sie können die Richtlinie für den risikobasierten bedingten Zugriff beim Anmelden anwenden, um festzustellen, ob die Authentifizierungsanforderung von der anfordernden Identität ausgegeben wurde. Die Anforderung wird anhand von Threat Intelligence-Quellen überprüft. Dazu gehören Kennwortspray und IP-Adressanomalien. Weitere Informationen finden Sie unter Bedingter Zugriff: Risikobasierter bedingter Zugriff beim Anmelden.

Möglicherweise verfügen Sie über Komponenten, die nicht Microsoft Entra ID verwenden, z. B. Jumpboxzugriff per SSH. Verwenden Sie in solchen Fällen eine Verschlüsselung mit öffentlichem Schlüssel mit mindestens RSA 2048-Schlüsselgröße. Geben Sie immer eine Passphrase an. Implementieren Sie einen Überprüfungsprozess, der bekannte zugelassene öffentliche Schlüssel nachverfolgt. Systeme, die Zugriff mit einem öffentlichen Schlüssel verwenden, dürfen nicht über das Internet verfügbar gemacht werden. Stattdessen sollte der SSH-Zugriff nur über einen Vermittler, z. B. Azure Bastion, zulässig sein, um die Auswirkungen der Kompromittierung eines privaten Schlüssels zu verringern. Deaktivieren Sie den direkten Kennwortzugriff, und verwenden Sie eine alternative Lösung ohne Kennwort.

Anforderung 8.3

PCI DSS 4.0.1 mandatiert die mehrstufige Authentifizierung (MFA) für den gesamten Zugriff auf die Kartenhalterdatenumgebung (CDE), einschließlich interner Benutzer. MFA-Kontrollen müssen kontinuierlich überwacht und auf Wirksamkeit geprüft werden.

Sichern Sie alle einzelnen Nicht-Konsolenverwaltungszugriffe und den gesamten Remotezugriff auf das CDE mithilfe der mehrstufigen Authentifizierung. Hinweis: Die mehrstufige Authentifizierung erfordert, dass mindestens zwei der drei Authentifizierungsmethoden (siehe Anforderung 8.2 für Beschreibungen der Authentifizierungsmethoden) für die Authentifizierung verwendet werden. Die Verwendung eines Faktors zweimal (z. B. die Verwendung von zwei separaten Kennwörtern) gilt nicht als mehrstufige Authentifizierung.

Ihre Zuständigkeiten

Verwenden Sie Richtlinien für bedingten Zugriff, um eine mehrstufige Authentifizierung zu erzwingen, insbesondere für Administratorkonten. Diese Richtlinien werden für mehrere integrierte Rollen empfohlen. Wenden Sie diese Richtlinien auf Microsoft Entra-Gruppen an, die Kubernetes-Rollen mit hohen Berechtigungen zugeordnet sind.

Diese Richtlinie kann mit zusätzlichen Richtlinien weiter gehärtet werden, z. B.:

• Sie können die Authentifizierung auf Geräte beschränken, die von Ihrem Microsoft Entra-Mandanten verwaltet werden.
• Wenn der Zugriff von einem Netzwerk außerhalb des Clusternetzwerks erfolgt, können Sie eine mehrstufige Authentifizierung erzwingen.

Weitere Informationen finden Sie unter:

• Bedingter Zugriff: Vorschreiben der MFA für Administratoren
• Bedingter Zugriff: Erfordern von kompatiblen Geräten
• Bedingter Zugriff: risikobasierte Multi-Faktor-Authentifizierung bei der Anmeldung

Anforderung 8.4

PCI DSS 4.0.1 erfordert, dass Authentifizierungsverfahren und Richtlinien regelmäßig überprüft, aktualisiert und allen Benutzern mitgeteilt werden. Schulung zum Sicherheitsbewusstsein muss Anleitungen zu bewährten Authentifizierungsmethoden und neuen Bedrohungen enthalten.

Dokumentieren und kommunizieren Sie Authentifizierungsverfahren und -richtlinien und -verfahren für alle Benutzer, einschließlich:

• Anleitung zum Auswählen sicherer Authentifizierungsanmeldeinformationen.
• Anleitung zum Schutz ihrer Authentifizierungsanmeldeinformationen durch Benutzer.
• Anweisungen zum Wiederverwenden zuvor verwendeter Kennwörter.
• Anweisungen zum Ändern von Kennwörtern, wenn ein Verdacht besteht, dass das Kennwort kompromittiert werden könnte.

Ihre Zuständigkeiten

Dokumentieren Sie die erzwungenen Richtlinien. Stellen Sie im Rahmen Ihrer Schulung für das Onboarding von Identitäten Anleitungen für Kennwortzurücksetzungsverfahren und bewährte Methoden in der Organisation für den Schutz von Ressourcen zur Verfügung.

Anforderung 8.5

PCI DSS 4.0.1 verbietet die Verwendung von Gruppen-, freigegebenen oder generischen IDs für administrative oder kritische Funktionen und erfordert eine kontinuierliche Überwachung auf Verstöße.

Verwenden Sie keine Gruppen-, freigegebenen oder generischen IDs, Kennwörter oder andere Authentifizierungsmethoden wie folgt:

• Generische Benutzer-IDs werden deaktiviert oder entfernt.
• Freigegebene Benutzer-IDs sind für die Systemverwaltung und andere wichtige Funktionen nicht vorhanden.
• Freigegebene und generische Benutzer-IDs werden nicht zum Verwalten von Systemkomponenten verwendet.

Ihre Zuständigkeiten

Achten Sie darauf, dass Identitäten für funktional verschiedene Teile des Clusters oder der Pods nicht gemeinsam oder wiederverwendet werden. Verwenden Sie beispielsweise kein Teamkonto, um auf Daten oder Clusterressourcen zuzugreifen. Stellen Sie sicher, dass die Identitätsdokumentation klar macht, keine gemeinsam verwendeten Konten zu verwenden.

Deaktivieren Sie Stammbenutzer in der CDE. Deaktivieren Sie die Verwendung lokaler Kubernetes-Konten, damit Benutzer nicht den integrierten --admin-Zugriff auf Cluster innerhalb der CDE nutzen können.

Anforderung 8.6

PCI DSS 4.0.1 erfordert, dass alle Authentifizierungsmechanismen (z. B. Token, Smartcards, Zertifikate) einzelnen Konten zugewiesen und nicht freigegeben werden. Physische und logische Kontrollen müssen eingerichtet sein, um sicherzustellen, dass nur das beabsichtigte Konto den Mechanismus verwenden kann.

Wenn andere Authentifizierungsmechanismen (z. B. physische oder logische Sicherheitstoken, Smartcards, Zertifikate usw.) verwendet werden, muss die Verwendung dieser Mechanismen wie folgt zugewiesen werden:

• Authentifizierungsmechanismen müssen einen einzelnen Konto zugewiesen sein und dürfen nicht für mehrere Konten gemeinsam verwendet werden.
• Physische und/oder logische Maßnahmen müssen angewendet sein, um sicherzustellen, dass nur das gewünschte Konto diesen Mechanismus verwenden kann, um Zugriff zu erhalten.

Ihre Zuständigkeiten

Stellen Sie sicher, dass der gesamte Zugriff auf das CDE pro Benutzer bereitgestellt wird und dass er auf physische oder virtuelle Token erweitert wird. Dies umfasst jeglichen VPN-Zugriff auf das CDE-Netzwerk, damit für den Point-to-Site-Zugriff im Unternehmen (sofern vorhanden) benutzerspezifische Zertifikate im Rahmen des betreffenden Authentifizierungsablaufs verwendet werden.

Anforderung 8.7

PCI DSS 4.0.1 erfordert, dass der gesamte Zugriff auf Datenbanken mit Kartenhalterdaten eingeschränkt und überwacht wird, und dass der Anwendungs- und Benutzerzugriff kontinuierlich auf Angemessenheit überprüft wird.

Der gesamte Zugriff auf eine Datenbank, die Daten von Karteninhabern enthält (einschließlich des Zugriffs durch Anwendungen, Administratoren und alle anderen Benutzer) ist wie folgt eingeschränkt:

• Der gesamte Benutzerzugriff auf, Benutzerabfragen von und Benutzeraktionen für Datenbanken erfolgen über programmgesteuerte Methoden.
• Nur Datenbankadministratoren haben die Möglichkeit, direkt auf Datenbanken zuzugreifen oder diese abzufragen.
• Anwendungs-IDs für Datenbankanwendungen können nur von den Anwendungen (und nicht von einzelnen Benutzer oder andere Prozesse außerhalb der Anwendung) verwendet werden.

Ihre Zuständigkeiten

Ermöglichen Sie den Zugriff basierend auf Rollen und Zuständigkeiten. Personen können ihre Identität verwenden, der Zugriff muss aber mit minimalen ständigen Berechtigungen auf „need-to-know“-Basis eingeschränkt werden. Personen sollten niemals Anwendungsidentitäten verwenden, und Datenbankzugriffsidentitäten dürfen nie gemeinsam verwendet werden.

Der Datenbankzugriff von Anwendungen sollte nach Möglichkeit über eine verwaltete Identität erfolgen. Schränken Sie andernfalls die Enttarnung von Verbindungszeichenfolgen und Anmeldeinformationen ein. Verwenden Sie Kubernetes-Geheimnisse zum Speichern von vertraulichen Informationen, anstatt solche Informationen an Stellen zu speichern, an denen sie leicht entdeckt werden können, wie z. B. einer Poddefinition. Eine andere Möglichkeit ist das Speichern und Laden von Geheimnissen in und aus einem verwalteten Speicher für sichere Daten, z. B. Azure Key Vault. Wenn verwaltete Identitäten in einem AKS-Cluster aktiviert sind, muss sich die Identität bei Key Vault authentifizieren, um Zugriff zu erhalten.

Anforderung 8.8

PCI DSS 4.0.1 setzt voraus, dass Sicherheitsrichtlinien und Betriebliche Verfahren zur Identifizierung und Authentifizierung kontinuierlich überprüft, aktualisiert und allen betroffenen Parteien mitgeteilt werden.

Stellen Sie sicher, dass Sicherheitsrichtlinien und betriebliche Verfahren für Identifizierung und Authentifizierung dokumentiert und verwendet werden sowie allen beteiligten Parteien bekannt sind.

Ihre Zuständigkeiten

Es ist wichtig, dass Sie eine umfassende Dokumentation zu den Prozessen und Richtlinien führen. Dokumentieren Sie die erzwungenen Richtlinien. Stellen Sie im Rahmen Ihrer Schulung für das Onboarding von Identitäten Anleitungen für Kennwortzurücksetzungsverfahren und bewährte Methoden in der Organisation für den Schutz von Ressourcen zur Verfügung. Personen, die in regulierten Umgebungen arbeiten, müssen geschult werden, informiert sein und Anreize erhalten, damit sie die Sicherheitsgarantien unterstützen. Dies ist besonders wichtig für Personen, die aus Richtliniensicht Teil des Genehmigungsprozesses sind.

Anforderung 9: Einschränken des physischen Zugriffs auf Karteninhaberdaten

Unterstützung von AKS-Features

Für diese Anforderung gibt es keine anwendbaren AKS-Features.

Ihre Zuständigkeiten

Diese Architektur und die Implementierung sind nicht für die Bereitstellung von Kontrollmöglichkeiten für den physischen Zugriff auf lokale Ressourcen oder Rechenzentren konzipiert. Weitere Informationen finden Sie in den Leitlinien im offiziellen PCI-DSS 4.0.1 Standard.

Nachstehend finden Sie einige Vorschläge zum Anwenden technischer Steuerelemente:

• Optimieren Sie Sitzungstimeouts bei jedem Verwaltungskonsolenzugriff, z. B. Jumpboxen in der CDE, um den Zugriff zu minimieren.

• Optimieren Sie Richtlinien für bedingten Zugriff, um die TTL für Azure-Zugriffstoken von Zugriffspunkten, z. B. Azure-Portal, zu minimieren. Informationen finden Sie in diesen Artikeln:

  • Konfigurieren von Richtlinien für die adaptive Sitzungslebensdauer
  • Konfigurierbare Tokengültigkeitsdauer in Microsoft Identity Platform

• Für eine in der Cloud gehostete CDE gibt es keine Zuständigkeiten für die Verwaltung von physischen Zugriffen und der Hardware. Verlassen Sie sich auf physische und logische Steuerelemente des Unternehmensnetzwerks.

• Minimieren Sie den Export von CHD-Sicherungen an lokale Ziele. Verwenden Sie in Azure gehostete Lösungen, um den physischen Zugriff auf Sicherungen einzuschränken.

• Minimieren Sie Sicherungen in lokalen Umgebungen. Beachten Sie, dass sich das lokale Ziel im Überwachungsbereich befindet, wenn dies erforderlich ist.

Nächste Schritte

Implementieren Sie erweiterte mehrstufige Authentifizierungsanforderungen (MFA) für den sicheren Zugriff auf die Kartenhalterdatenumgebung.