Zugriffsverwaltung eines AKS-Baselineclusters für PCI-DSS 3.2.1 (Teil 6 von 9)

In diesem Artikel werden die Aspekte eines AKS-Clusters (Azure Kubernetes Service) beschrieben, der gemäß des Payment Card Industry Data Security Standard (PCI-DSS 3.2.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. Die betreffenden Aktionen können für einen Benutzer über Kubernetes-RBAC genehmigt (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 – Beschränken des Zugriffs auf Karteninhaberdaten auf das geschäftlich erforderliche Maß

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 eingestellt, dass jeglicher Zugriff verweigert wird, sodass ohne erteilte Berechtigungen kein Zugriff auf eine Ressource möglich ist. 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 die Kubernetes-Autorisierung und Schützen Ihres Clusters mit Azure Policy.

Ihre Zuständigkeiten

Anforderung	Verantwortlichkeit
Anforderung 7.1	Beschränken Sie den Zugriff auf Systemkomponenten und Karteninhaberdaten auf diejenigen Personen, deren Funktion einen solchen Zugriff erfordert.
Anforderung 7.2	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.
Anforderung 7.3	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.

Anforderung 7.1

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

Ihre Zuständigkeiten

Hier einige Überlegungen dazu:

• Stellen Sie sicher, dass Ihre Implementierung den Anforderungen der Organisation und den Complianceanforderungen für die 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

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

• Systemkomponenten und Datenressourcen, auf die jede Rolle für ihre Funktion 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.:

• Bereich nach Azure-Verwaltungsgruppen, Abonnements oder Ressourcengruppen
• Azure Policy für die Workload oder das Abonnement
• Containervorgänge
• Verwaltung von Geheimnissen
• Build- und Bereitstellungspipelines

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. Legen Sie beispielsweise fest, wer für die Aufrechterhaltung der Sicherheit, Isolation, Bereitstellung und Beobachtbarkeit verantwortlich ist. Im Folgenden finden Sie einige Beispiele:

• 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. Zur Veranschaulichung folgt eine einfache Definition.

Rolle	Aufgaben	Zugriffsebenen
Anwendungsbesitzer	Definieren und Priorisieren von Features in Übereinstimmung mit den Geschäftsergebnissen. Sie wissen, wie sich Features auf den Compliancebereich der Workload auswirken, und sorgen dafür, dass Schutz und Besitz von Kundendaten mit geschäftsspezifischen Zielen in Einklang stehen.	Lesezugriff auf Protokolle und Metriken, die von der Anwendung ausgegeben werden. Sie benötigen keine Zugriffsberechtigungen für die Workload oder den Cluster.
Anwendungsentwickler	Entwickeln der Anwendung. Der gesamte Anwendungscode unterliegt Trainings- und Qualitätsgates, die Compliance-, Nachweis- und Releaseverwaltungsprozesse einhalten. Sie können die Buildpipelines, normalerweise aber keine Bereitstellungspipelines verwalten.	Lesezugriff auf Kubernetes-Namespaces und Azure-Ressourcen, die sich im Bereich der Workload befinden. Kein Schreibzugriff zum Bereitstellen oder Ändern eines Systemzustands.
Anwendungsoperatoren (oder SRE)	Umfassende Kenntnisse der Codebasis, der Beobachtbarkeit und der Vorgänge. Durchführen von Live-Site-Selektierung und Problembehandlung. Verbessern von Verfügbarkeit, Skalierbarkeit und Leistung der Anwendung zusammen mit Anwendungsentwicklern. Verwalten der Last-Mile-Bereitstellungspipeline und Helfen bei der Verwaltung der Buildpipelines.	Hohe Berechtigungen im Bereich der Anwendung, der zugehörige Kubernetes-Namespaces und Azure-Ressourcen enthält. Sie verfügen wahrscheinlich über ständigen Zugriff auf Teile des Kubernetes-Clusters.
Infrastrukturbesitzer	Entwerfen einer kostengünstige Architektur, einschließlich der jeweiligen Konnektivität und der Funktionalität von Komponenten. Der Bereich kann cloudbasierte und lokale Dienste umfassen. Bestimmen von Funktionen, Datenaufbewahrung, Features für die Geschäftskontinuität u. a.	Zugriff auf Plattformprotokolle und Kostenstellendaten. Im Cluster ist kein Zugriff erforderlich.
Infrastrukturoperatoren (oder SRE)	Vorgänge im Zusammenhang mit dem Cluster und abhängigen Diensten. Erstellen, Bereitstellen und Urladen der Pipeline für den Cluster, in dem die Workload bereitgestellt wird. Festlegen von Zielknotenpools sowie der erwarteten Dimensionierungs- und Skalierungsanforderungen. Überwachen der Integrität der Containerhostinginfrastruktur und der abhängigen Dienste.	Lesezugriff auf Workloadnamespaces. Zugriff mit hohen Berechtigungen für den Cluster.
Richtlinien-, Sicherheitsbesitzer	Kenntnisse in Bezug auf Sicherheits- oder Verordnungskonformität. Definieren von Richtlinien, die die Sicherheit und Einhaltung gesetzlicher Bestimmungen durch Mitarbeiter des Unternehmens, seiner Ressourcen und der Kunden des Unternehmens sicherstellen. Zusammenarbeit mit allen anderen Rollen, um sicherzustellen, dass die Richtlinie in jeder Phase angewendet wird und überwacht werden kann.	Lesezugriff auf die Workload und den Cluster. Außerdem Zugriff auf Protokoll- und Überwachungsdaten.
Netzwerkoperatoren	Zuteilung von unternehmensweiten virtuellen Netzwerken und Subnetzen. Konfiguration und Wartung von Azure Firewall, WAF, NSGs und DNS-Konfiguration.	Hohe Berechtigungen in der Netzwerkebene. Keine Schreibberechtigung im Cluster.

Anforderung 7.1.2

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. Hier sind einige bewährte Methoden angegeben:

• 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

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.

Beispiele:

Auftragsklassifizierung	Rolle
Ein Produktbesitzer definiert den Umfang der Workload und priorisiert Features. Er sorgt dafür, dass Schutz und Besitz von Kundendaten mit geschäftsspezifischen Zielen in Einklang stehen. Er benötigt Zugriff auf Berichte, Kostenstelle oder Azure-Dashboards. Kein Zugriff für clusterinterne Berechtigungen oder Berechtigungen auf Clusterebene.	Anwendungsbesitzer
Ein Softwareentwickler entwirft, entwickelt und containerisiert den Anwendungscode. Eine Gruppe mit ständigen Leseberechtigungen in definierten Bereichen in Azure (z. B. Application Insights) und den Workloadnamespaces. Diese Bereiche und Berechtigungen können in Präproduktions- und Produktionsumgebungen verschieden sein.	Anwendungsentwickler
Ein Site Reliability Engineer (SRE) führt die Live-Site-Selektierung durch, verwaltet Pipelines und richtet die Anwendungsinfrastruktur ein. Gruppe A mit Vollzugriff in den jeweils zugeordneten Namespaces. Ständige Berechtigungen sind nicht erforderlich. Gruppe B für alltägliche Vorgänge in Bezug auf die Workload. Sie kann über ständige Berechtigungen in den jeweils zugeordneten Namespaces verfügen, verfügt jedoch nicht über hohe Berechtigungen.	Anwendungsoperatoren
Ein Clusteroperator entwirft einen zuverlässigen und sicheren AKS-Cluster und stellt diesen auf der Plattform bereit. Verantwortlich für die Aufrechterhaltung der Cluster-Uptime. Gruppe A mit Vollzugriff in den jeweils zugeordneten Namespaces. Ständige Berechtigungen sind nicht erforderlich. Gruppe B für alltägliche Vorgänge in Bezug auf die Workload. Sie kann über ständige Berechtigungen in den jeweils zugeordneten Namespaces verfügen, verfügt jedoch nicht über hohe Berechtigungen.	Infrastrukturoperatoren
Ein Netzwerktechniker teilt unternehmensweite virtuelle Netzwerke und Subnetze, die Konnektivität von der lokalen Umgebung zur Cloud und Netzwerksicherheitsfunktionen zu.	Infrastrukturoperatoren

Anforderung 7.1.4

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

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 der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) für die Infrastruktur Rollen basierend auf Rollen und Zuständigkeiten zu. Dafür sind folgende Mechanismus verfügbar:

• Kubernetes-RBAC ist ein natives 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 ist ein Microsoft Entra ID-basiertes Autorisierungsmodell, das den Zugriff auf die Azure-Steuerungsebene 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 Infrastrukturoperator*innen an cluster-admin binden, indem Sie Rollenbindungen erstellen. Es gibt zwei Verfahrensweisen. Sie können die integrierten Rollen verwenden. Wenn die integrierten Rollen Ihre Anforderungen nicht erfüllen (wenn sie z. B. zu viele Berechtigungen gewähren), 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 per rollenbasierter Zugriffssteuerung von Kubernetes und mit Microsoft Entra-Identitäten in Azure Kubernetes Service.

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.

Abgesehen von Personen und deren Rollen verfügen Azure-Ressourcen und sogar Pods im Cluster über verwaltete Identitäten. Diese Identitäten benötigen einen Berechtigungssatz über Azure-RBAC und müssen basierend auf den erwarteten Aufgaben eng an den Bereich gebunden werden. 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.

Hier sind einige bewährte Methoden angegeben:

• 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

Abdeckung aller Systemkomponenten

Ihre Zuständigkeiten

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

• 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-Steuerungsebene 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 im Idealfall 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

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

Standardeinstellung „Alles verweigern“.

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

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 – Erkennen 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	Verantwortlichkeit
Anforderung 8.1	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:
Anforderung 8.2	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:
Anforderung 8.3	Sichern Sie den gesamten einzelnen Administratorzugriff, der nicht über die Konsole erfolgt, sowie den gesamten Remotezugriff auf die CDE mit mehrstufiger Authentifizierung.
Anforderung 8.4	Dokumentieren Sie Authentifizierungsverfahren und -richtlinien, und teilen Sie sie allen Benutzern mit, einschließlich:
Anforderung 8.5	Verwenden Sie IDs, Kennwörter oder andere Authentifizierungsmethoden, die für Gruppen bestimmt, freigegeben oder generisch sind nicht wie folgt:
Anforderung 8.6	Wenn andere Authentifizierungsmechanismen (z. B. physische oder logische Sicherheitstoken, Smartcards, Zertifikate usw.) verwendet werden, muss die Verwendung dieser Mechanismen wie folgt zugewiesen werden:
Anforderung 8.7	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:
Anforderung 8.8	Stellen Sie sicher, dass Sicherheitsrichtlinien und betriebliche Verfahren für Identifizierung und Authentifizierung dokumentiert und verwendet werden sowie allen beteiligten Parteien bekannt sind.

Anforderung 8.1

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:

• 8.1.1 Weisen Sie allen Benutzern eine eindeutige ID zu, bevor Sie auf Systemkomponenten oder Daten von Karteninhabern zugreifen können.
• 8.1.2 Kontrollieren Sie das Hinzufügen, Löschen und Ändern von Benutzer-IDs, Anmeldeinformationen und anderen Bezeichnerobjekten.
• 8.1.3 Widerrufen Sie den Zugriff für ausgeschiedene Benutzer umgehend.
• 8.1.4 Entfernen/deaktivieren Sie inaktive Benutzerkonten innerhalb von 90 Tagen.
• 8.1.5 Verwalten Sie wie folgt IDs, die von Drittanbietern für den griff auf bzw. für Support- oder Wartungsaktivitäten für Systemkomponenten über Remotezugriff verwendet werden:
  • Nur während des erforderlichen Zeitraums aktiviert und bei Nichtverwendung deaktiviert.
  • Während der Verwendung überwacht.
• 8.1.6 Begrenzen Sie wiederholte Zugriffsversuche, indem Sie die Benutzer-ID nach höchstens sechs Versuchen sperren.
• 8.1.7 Legen Sie die Sperrdauer auf mindestens 30 Minuten oder bis zur Aktivierung der Benutzer-ID durch einen Administrator fest.
• 8.1.8 Legen Sie fest, dass sich der Benutzer erneut authentifizieren muss, um das Terminal oder die Sitzung erneut zu aktivieren, wenn eine Sitzung mehr als 15 Minuten inaktiv ist.

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. Stellen Sie ebenso bei Verwendung von Microsoft Entra-Workloadidentität im AKS-Cluster sicher, dass jede Komponente in Ihrer Workload eine eigene Identität erhält, anstatt eine weit gefasste Identität zu verwenden. Teilen Sie niemals dieselbe verwaltete Identität zwischen Produktions- und Nicht-Produktionsumgebungen.

Weitere Informationen zu Zugriffs- und Identitätsoptionen für 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

Ihre Zuständigkeiten

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

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 man weiß, z. B. ein Kennwort oder eine Passphrase, Etwas, das man hat, z. B. ein Token-Gerät oder eine Smartcard, Etwas, das einen auszeichnet, z. B. ein biometrisches Merkmal.

• 8.2.1 Verwenden Sie starke Kryptografie, um alle Authentifizierungsinformationen (z. B. Kennwörter/Passphrasen) während der Übertragung und Speicherung auf allen Systemkomponenten unlesbar zu machen.
• 8.2.2 Überprüfen Sie die Benutzeridentität, bevor Sie Änderungen an Anmeldeinformationen für die Authentifizierung vornehmen, z. B. Kennwörter zurücksetzen, neue Token bereitstellen oder neue Schlüssel generieren.
• 8.2.3 Kennwörter/Passphrasen müssen folgende Anforderungen erfüllen:
  • Sie bestehen aus mindestens sieben Zeichen.
  • Sie enthalten sowohl numerische als auch alphabetische Zeichen.
• 8.2.4 Ändern Sie Benutzerkennwörter/-passphrasen mindestens alle 90 Tage.
• 8.2.5 Lassen Sie nicht zu, dass ein Benutzer neue Kennwörter/Passphrasen übermittelt, die mit einem/einer der vier zuletzt verwendeten Kennwörter/Passphrasen identisch sind.
• 8.2.6 Legen Sie Kennwörter/Passphrasen zur erstmaligen Verwendung und nach dem Zurücksetzen auf einen eindeutigen Wert für jeden Benutzer fest, und ändern Sie diese unmittelbar nach der ersten Verwendung.

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-Steuerungsebene weiter eingeschränkt.

Einige der oben genannten Anforderungen werden automatisch von Microsoft Entra ID erfüllt. Hier sehen Sie 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 in Betracht zu ziehen. 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 kennwortlose Lösung.

Anforderung 8.3

Sichern Sie den gesamten einzelnen Administratorzugriff, der nicht über die Konsole erfolgt, sowie den gesamten Remotezugriff auf die CDE mit mehrstufiger Authentifizierung. Hinweis: Die mehrstufige Authentifizierung erfordert, dass mindestens zwei der drei Authentifizierungsmethoden (siehe Beschreibungen der Authentifizierungsmethoden in Anforderung 8.2) für die Authentifizierung verwendet werden. Die zweimalige Verwendung eines Faktors (z. B. mit 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 gefestigt werden. Hier sehen Sie einige Beispiele:

• 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

Dokumentieren Sie Authentifizierungsverfahren und -richtlinien, und teilen Sie sie allen Benutzern mit, einschließlich:

• Anleitungen für die Auswahl sicherer Authentifizierungsanmeldeinformationen
• Anleitungen dazu, wie Benutzer ihre Anmeldeinformationen für die Authentifizierung schützen müssen
• Die Anweisung, Kennwörter nicht wiederzuverwenden
• Die Anweisung, Kennwörter zu ändern, wenn ein Verdacht besteht, dass sie gefährdet sind

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

Verwenden Sie IDs, Kennwörter oder andere Authentifizierungsmethoden, die für Gruppen bestimmt, freigegeben oder generisch sind nicht wie folgt:

• Generische Benutzer-IDs werden deaktiviert oder entfernt.
• Für die Systemverwaltung und andere wichtige Funktionen sind keine freigegebenen Benutzer-IDs vorhanden.
• Zur Verwaltung von Systemkomponenten werden keine freigegebenen und generischen Benutzer-IDs 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

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 die CDE für benutzerspezifische Identitäten ermöglicht und 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

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

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 – Beschrä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. Informationen zu den zu berücksichtigenden Punkten finden Sie im Leitfaden zum offiziellen PCI-DSS 3.2.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

Nachverfolgen und Überwachen des gesamten Zugriffs auf Netzwerkressourcen und Karteninhaberdaten Regelmäßiges Testen der Sicherheitssysteme und -prozesse