Konfigurieren des Netzwerks eines regulierten AKS-Clusters für PCI-DSS 3.2.1 (Teil 3 von 9)

In diesem Artikel werden Überlegungen zur Netzwerkkonfiguration 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.

Der Hauptaspekt des PCI-DSS 3.2.1-Standards ist die Sicherheit. Die Hub-Spoke-Topologie ist eine natürliche Wahl für die Einrichtung einer regulierten Netzwerkumgebung. Es ist einfacher, eine Infrastruktur zu erstellen, die eine sichere Kommunikation ermöglicht. Netzwerksteuerungen werden in beiden Hub-Spoke-Netzwerken platziert und basieren auf dem Zero-Trust-Modell von Microsoft. Die Steuerungen können nach dem Prinzip der geringsten Rechte optimiert werden, um Datenverkehr zu schützen und jeweils nur den erforderlichen Zugriff zu ermöglichen. Darüber hinaus können Sie mehrere Defense-in-Depth-Ansätze (tiefgehende Verteidigung) anwenden, indem Sie Steuerungen an jedem Netzwerkshop und jeder Netzwerkebene hinzufügen.

Wenn Sie eine Workload in einer Kubernetes-Umgebung hosten, reicht es nicht aus, herkömmliche Netzwerkkonstrukte, z. B. Firewallregeln, zu verwenden. Es gibt auch Kubernetes-native Konstrukte, mit denen der Datenverkehrsfluss im Cluster kontrolliert wird, z. B. die Ressource NetworkPolicy. Wir empfehlen Ihnen dringend, sich in der Kubernetes-Dokumentation mit den grundlegenden Konzepten von isolierten Pods und Richtlinien für den Ein- und Ausgang vertraut zu machen.

Erstellen und Verwalten eines sicheren Netzwerks und sicherer Systeme

Anforderung 1: Installieren und Pflegen einer Firewallkonfiguration zum Schützen der Karteninhaberdaten

Unterstützung von AKS-Features

AKS unterstützt die Bereitstellung eines Clusters in einem privaten virtuellen Netzwerk als privaten Cluster. Die Kommunikation zwischen dem Cluster und dem von AKS verwalteten Kubernetes-API-Server erfolgt über ein vertrauenswürdiges Netzwerk. Mit einem privaten Cluster können Sie Azure Virtual Network, eine Netzwerksicherheitsgruppe (NSG) und andere integrierte Netzwerksteuerungen verwenden, um die gesamte Datenumgebung des Karteninhabers (Cardholder Data Environment, CDE) zu schützen. Diese Konfiguration unterbindet den unbefugten öffentlichen Zugriff zwischen dem Internet und der Umgebung. Ausführlichere Informationen, wie Sie einen Cluster dieser Art bereitstellen, finden Sie unter Erstellen eines privaten Azure Kubernetes Service-Clusters.

Azure Firewall kann in AKS integriert werden und ermöglicht die Einschränkung des ausgehenden Datenverkehrs für den Cluster. Dies ist eine wichtige Komponente der Datenumgebung des Karteninhabers. Mit einem AKS-FQDN-Tag ist die Konfiguration sehr einfach. Der empfohlene Prozess ist unter Verwenden von Azure Firewall zum Schützen von AKS-Bereitstellungen (Azure Kubernetes Service) beschrieben.

AKS-Cluster erfordern ein gewisses Maß an öffentlichem Internetzugriff. Schränken Sie den ausgehenden Datenverkehr ins Internet ein, indem Sie Azure Firewall und NSGs im Clustersubnetz verwenden. Informationen hierzu finden Sie unter Steuern des ausgehenden Datenverkehrs für Clusterknoten in Azure Kubernetes Service (AKS).

AKS unterstützt optional die Möglichkeit, einen HTTP-Proxy zu definieren, der für zusätzliche Kontrolle und Überwachung des ausgehenden Datenverkehrs für den Cluster verwendet werden kann. Die Clusterknoten verwenden die angegebene HTTP-Proxykonfiguration für das Routing ausgehenden Datenverkehrs. Außerdem wird ein MutatingWebhook registriert, um die Proxyinformationen zur Erstellungszeit in die Pods einzufügen, sodass es sich empfiehlt, dass Workloads dieselben Proxyinformationen erben können. Pods können Proxyinformationen außer Kraft setzen, sodass es sich empfiehlt, zusätzlich zu einer Azure Firewall einen HTTP-Proxy zu verwenden.

AKS-Cluster sollten mit dem NetworkPolicy-Plug-In erstellt werden. In AKS haben Sie mehrere Optionen für Ihr Netzwerkrichtlinien-Plug-In, darunter Calico, die Azure-Netzwerkrichtlinienverwaltung und Cilium. Mit der Calico-Netzwerkrichtlinie können Sie entweder Kubenet oder Azure CNI verwenden. Für die Azure-Netzwerkrichtlinienverwaltung können Sie nur Azure CNI (nicht Kubenet) verwenden. Sowohl das Azure- als auch das Calico-Netzwerkrichtlinien-Plug-In sind quelloffen. Weitere Informationen zu Project Calico finden Sie im umfassenden Whitepaper zur PCI-Lösung, in dem viele der unten aufgeführten Firewallanforderungen behandelt werden.

Ihre Zuständigkeiten

Anforderung	Verantwortlichkeit
Anforderung 1.1	Führen Sie die Einrichtung und Implementierung von Standards für die Firewall- und Routerkonfiguration durch.
Anforderung 1.2	Erstellen Sie Firewall- und Routerkonfigurationen, die Verbindungen zwischen nicht vertrauenswürdigen Netzwerken und allen Systemkomponenten in der Datenumgebung des Karteninhabers einschränken.
Anforderung 1.3	Verbieten Sie den direkten öffentlichen Zugriff zwischen dem Internet und allen Systemkomponenten in der Datenumgebung des Karteninhabers.
Anforderung 1.4	Installieren Sie persönliche Firewallsoftware oder gleichwertige Funktionen auf allen tragbaren Computergeräten (einschließlich unternehmenseigener und/oder mitarbeitereigener Geräte), die sich außerhalb des Netzwerks mit dem Internet verbinden (z. B. Laptops, die von Mitarbeitern verwendet werden) und die auch für den Zugriff auf die CDE verwendet werden.
Anforderung 1.5	Stellen Sie sicher, dass Sicherheitsrichtlinien und betriebliche Verfahren für die Verwaltung von Firewalls dokumentiert und verwendet werden sowie allen beteiligten Parteien bekannt sind.

Anforderung 1.1

Erstellen und implementieren Sie Firewall- und Routerkonfigurationsstandards, die Folgendes umfassen:

Anforderung 1.1.1

Ein formaler Prozess zum Genehmigen und Testen aller Netzwerkverbindungen und Änderungen an der Firewall sowie den Routerkonfigurationen.

Ihre Zuständigkeiten

Implementieren Sie Konfigurationen nicht manuell, z. B. über das Azure-Portal oder direkt über die Azure CLI. Wir empfehlen Ihnen, Infrastructure-as-Code (IaC) zu verwenden. Bei IaC wird die Infrastruktur über ein beschreibendes Modell verwaltet, für das ein Versionsverwaltungssystem verwendet wird. Das IaC-Modell generiert jedes Mal, wenn es angewendet wird, die gleiche Umgebung. Gängige Beispiele für IaC sind Bicep, Azure Resource Manager-Vorlagen (ARM-Vorlagen) oder Terraform. Falls IaC für Sie keine Option ist, sollten Sie über einen gut dokumentierten Prozess für die Nachverfolgung, Implementierung und sichere Bereitstellung der Änderungen von Firewallregeln verfügen. Weitere Informationen finden Sie unter Anforderung 11.2.

Sie müssen eine Kombination aus unterschiedlichen Netzwerksteuerungen verwenden, z. B. Azure Firewall, Netzwerksicherheitsgruppen (NSGs) und der Kubernetes-Ressource NetworkPolicy.

Minimieren Sie die Anzahl von Personen, die berechtigt sind, auf Netzwerksteuerungen zuzugreifen und diese zu ändern. Definieren Sie die Rollen und eindeutige Zuständigkeiten für die Teams. Das Netzwerkteam einer Organisation überprüft beispielsweise die Änderungen anhand der Governancerichtlinien, die von IT-Teams festgelegt werden. Legen Sie einen abgegrenzten Genehmigungsprozess fest, bei dem über Personen und Prozesse Änderungen von Netzwerkkonfigurationen genehmigt werden. Der Prozess sollte auch einen Schritt zum Testen aller Netzwerksteuerungen enthalten. Erstellen Sie eine ausführliche Dokumentation, in der der Prozess beschrieben wird.

Anforderung 1.1.2

Aktuelles Netzwerkdiagramm, das alle Verbindungen zwischen der Datenumgebung des Karteninhabers und anderen Netzwerken, einschließlich drahtloser Netzwerke, identifiziert.

Ihre Zuständigkeiten

Erstellen Sie im Rahmen Ihrer Dokumentation ein Netzwerkflussdiagramm, in dem der ein- und ausgehende Datenverkehr mit Sicherheitskontrollen dargestellt ist. Hierin ist auch der Datenverkehrsfluss aus anderen Netzwerken enthalten, z. B. aus dem Drahtlosnetzwerk in die Datenumgebung des Karteninhabers. Im Diagramm sollten auch die Datenflüsse im Cluster angezeigt werden. Es gibt einige spezifische Anforderungen für Diagramme. Diese sollten beispielsweise Sensoren für Eindringversuche und alle angewendeten Kontrollen anzeigen.

In dieser Abbildung ist das Netzwerkdiagramm der Referenzimplementierung dargestellt.

Laden Sie eine Visio-Datei mit dieser Architektur herunter.

Abbildung 1.1.2: Datenfluss im Netzwerk

Dieser Datenfluss wird in den folgenden Abschnitten beschrieben.

Sie können die Topologie eines virtuellen Azure-Netzwerks anzeigen, wenn Sie über Azure Network Watcher verfügen. Sie können alle Ressourcen eines virtuellen Netzwerks, die Ressourcenzuordnung in einem virtuellen Netzwerk und die Beziehungen zwischen den Ressourcen anzeigen.

Anforderung 1.1.3

Aktuelles Diagramm, in dem alle Datenflüsse der Karteninhaber system- und netzwerkübergreifend dargestellt sind.

Ihre Zuständigkeiten

Fügen Sie Ihrer Dokumentation ein Diagramm zum Datenfluss hinzu, in dem dargestellt ist, wie Daten im ruhenden Zustand und während der Übertragung geschützt werden.

Im Diagramm sollte dargestellt sein, wie Daten zur und von der Workload fließen und welche Informationen zwischen den Ressourcen übergeben werden. Stellen Sie sicher, dass das Diagramm immer auf dem aktuellen Stand ist. Fügen Sie dem Change Management-Prozess einen Schritt hinzu, mit dem das Datenflussdiagramm aktualisiert wird.

Da es bei dieser Architektur nicht um die Workload geht, sondern um die Infrastruktur, haben wir Abbildungen hier weggelassen.

Anforderung 1.1.4

Anforderungen an eine Firewall für jede Internetverbindung und zwischen jeder entmilitarisierten Zone (Demilitarized Zone, DMZ) und der internen Netzwerkzone.

Ihre Zuständigkeiten

Sorgen Sie für eine eindeutige Definition der Grenze einer DMZ. Die Datenumgebung für Karteninhaber (Cardholder Data Environment, CDE) könnte sich beispielsweise in einer DMZ befinden, die durch eine Firewall, Netzwerkrichtlinien und andere Kontrollen geschützt ist. Weitere Informationen finden Sie unter Cloud-DMZ.

Bei einer PCI-DSS-Infrastruktur sind Sie für den Schutz der CDE verantwortlich. Hierfür nutzen Sie Netzwerksteuerungen, um einen unbefugten Zugriff auf das Netzwerk, in dem die CDE enthalten ist, und aus diesem Netzwerk zu blockieren. Netzwerksteuerungen müssen richtig konfiguriert werden, um einen hohen Sicherheitsstatus zu erreichen, und auf Folgendes angewendet werden:

• Kommunikation zwischen den zusammen angeordneten Komponenten innerhalb des Clusters.
• Kommunikation zwischen der Workload und anderen Komponenten in vertrauenswürdigen Netzwerken.
• Kommunikation zwischen der Workload und dem öffentlichen Internet.

In dieser Architektur werden verschiedene Firewalltechnologien verwendet, um den Datenverkehr in beiden Richtungen für den Cluster, in dem die CDE gehostet wird, zu untersuchen:

• Azure Application Gateway wird als Datenverkehrsrouter und die darin integrierte Web Application Firewall (WAF) zum Schützen des eingehenden Datenverkehrs an den Cluster verwendet.

• Azure Firewall wird genutzt, um den gesamten ausgehenden Datenverkehr aller Netzwerke und der zugehörigen Subnetze zu schützen.

  Im Rahmen der Verarbeitung einer Transaktion oder von Verwaltungsvorgängen muss der Cluster mit externen Endpunkten kommunizieren. Der Cluster könnte beispielsweise eine Kommunikation mit der AKS-Steuerungsebene, mit dem Betriebssystem und Paketaktualisierungssystemen erfordern. Außerdem interagieren viele Workloads mit externen APIs. Einige dieser Interaktionen erfolgen unter Umständen über HTTP und sollten als Angriffsvektoren betrachtet werden. Diese Vektoren sind Ziele für einen Man-in-the-Middle-Angriff, der zu einer Datenexfiltration führen kann. Durch das Hinzufügen einer Firewall für ausgehenden Datenverkehr wird diese Bedrohung entschärft.

  Wir empfehlen Ihnen, auch die Kommunikation zwischen Pods per TLS zu verschlüsseln. Diese Vorgehensweise ist in der Referenzimplementierung mit gegenseitiger TLS (mTLS)-Authentifizierung dargestellt.

• NSGs werden hinzugefügt, um Datenverkehr zwischen dem Cluster und anderen Komponenten innerhalb der Infrastruktur zu schützen. In der Referenzimplementierung befinden sich beispielsweise NSGs im Subnetz mit Knotenpools, die alle SSH-Zugriffsversuche blockieren. Nur Datenverkehr von innerhalb des virtuellen Netzwerks ist zulässig.

  Erwägen Sie beim Hinzufügen von Komponenten zur Architektur das Hinzufügen von weiteren NSGs, mit denen Datenverkehrstypen an den Subnetzgrenzen zugelassen oder abgelehnt werden. Da sich jeder Knotenpool in einem dedizierten Subnetz befindet, sollten Sie spezifischere Regeln basierend auf den erwarteten Datenverkehrsmustern Ihrer Workload anwenden.

• Kubernetes-Objekte NetworkPolicy werden zum Steuern der clusterinternen Kommunikation verwendet.

  Standardmäßig gibt es keine Einschränkungen für die Kommunikation zwischen Pods. Sie müssen eine Netzwerkrichtlinie (NetworkPolicy) auf die clusterinterne Kommunikation anwenden, indem Sie mit einem Zero-Trust-Netzwerk und dem Öffnen von Pfaden je nach Bedarf beginnen. In der Referenzimplementierung sind Zero-Trust-Netzwerke in den Namespaces a0005-i und a0005-o dargestellt. Auf alle Namespaces (mit Ausnahme von kube-system, gatekeeper-system und anderen von AKS bereitgestellten Namespaces) werden restriktive Netzwerkrichtlinien angewendet. Die Richtliniendefinition hängt von den Pods ab, die in diesen Namespaces ausgeführt werden. Stellen Sie sicher, dass Sie Pfade für Bereitschaft, Aktualität und Starttests öffnen. Öffnen Sie außerdem den Pfad zu oms-agent, damit Metriken auf Knotenebene gesendet werden können. Standardisieren Sie ggf. die Ports für die Workloads, um eine konsistente Netzwerkrichtlinie (NetworkPolicy) und eine Azure Policy-Instanz für die zulässigen Containerports bereitstellen zu können.

Anforderung 1.1.5

Beschreibung von Gruppen, Rollen und Verantwortlichkeiten für die Verwaltung von Netzwerkkomponenten.

Ihre Zuständigkeiten

Sie müssen Steuerungen für die Netzwerkdatenflüsse und die beteiligten Komponenten bereitstellen. Die sich ergebende Infrastruktur verfügt über mehrere Netzwerksegmente, die jeweils viele Steuerungen aufweisen und einen bestimmten Zweck haben. Stellen Sie sicher, dass Ihre Dokumentation von der Netzwerkplanung bis hin zu allen angewendeten Konfigurationen alle Bereiche abdeckt. Sie sollte auch Angaben zur Zuständigkeit enthalten und eine eindeutige Beschreibung der Zuständigkeiten sowie der dafür jeweils verantwortlichen Rollen umfassen.

Beispielsweise sollte klar sein, wer für die Governance in Bezug auf den Schutz der Netzwerke zwischen Azure und dem Internet verantwortlich ist. In einem Unternehmen ist das IT-Team in der Regel für die Konfiguration und Wartung von Azure-Firewallregeln, Web Application Firewall (WAF)-Regeln, NSGs und anderem netzwerkübergreifendem Datenverkehr zuständig. Darüber hinaus ist das Team unter Umständen auch für die unternehmensweite Zuordnung virtueller Netzwerke und Subnetze sowie für die Planung von IP-Adressen verantwortlich.

Auf Workloadebene ist ein Clusteroperator für die Durchsetzung des Zero-Trust-Prinzips über Netzwerkrichtlinien verantwortlich. Weitere Zuständigkeiten können auch die Kommunikation mit der Azure-Steuerungsebene, Kubernetes-APIs und Überwachungstechnologien betreffen.

Beginnen Sie immer mit einer Strategie vom Typ „Alle ablehnen“ (Deny All). Erteilen Sie die Berechtigung nur, wenn dafür eine geschäftliche Notwendigkeit besteht oder dies für eine Rolle erforderlich ist.

Anforderung 1.1.6

Dokumentation der betrieblichen Rechtfertigung und Genehmigung der Nutzung aller zulässigen Dienste, Protokolle und Ports, einschließlich der Dokumentation der Sicherheitsmaßnahmen, die für die als unsicher geltenden Protokolle implementiert wurden.

Ihre Zuständigkeiten

Erstellen Sie eine ausführliche Dokumentation, in der die Dienste, Protokolle und Ports beschrieben sind, die für die Netzwerksteuerungen verwendet werden. Verweigern Sie alle Ports – mit Ausnahme explizit zugelassener Ports. Dokumentieren Sie die geschäftliche Begründung und die jeweiligen Sicherheitsfeatures, falls die Verwendung von unsicheren Protokollen nicht vermieden werden kann. Hier sind einige Beispiele aus der Referenzimplementierung für Azure Firewall aufgeführt. Der Bereich von Firewallregeln muss ausschließlich auf die zugehörigen Ressourcen beschränkt sein. Dies bedeutet, dass nur Datenverkehr aus bestimmten Quellen an bestimmte FQDN-Ziele fließen darf.

Hier einige Beispiele, bei denen Sie Datenverkehr zulassen können:

Regel	Protokoll:Port	`Source`	Ziel	Begründung
Sichere Kommunikation zwischen den Knoten und der Steuerungsebene zulassen.	HTTPS: 443	Autorisierte IP-Adressbereiche, die den Clusterknotenpools zugewiesen sind	Liste mit FQDN-Zielen auf der AKS-Steuerungsebene. Wird mit dem FQDN-Tag AzureKubernetesService angegeben.	Die Knoten benötigen Zugriff auf die Steuerungsebene für Verwaltungstools, Status- und Konfigurationsinformationen sowie Informationen darüber, welche Knoten skaliert werden können.
Sichere Kommunikation zwischen Flux und GitHub zulassen.	HTTPS: 443	AKS-Knotenpools	github.com, api.github.com	Flux ist eine Drittanbieterintegration, die auf den Knoten ausgeführt wird. Sie dient zum Synchronisieren der Clusterkonfiguration mit einem privaten GitHub-Repository.

Anforderung 1.1.7

Anforderung zur Überprüfung von Firewall- und Routerregelsätzen mindestens alle sechs Monate.

Ihre Zuständigkeiten

Richten Sie Prozesse ein, mit denen mindestens alle sechs Monate die Netzwerkkonfigurationen und die Bereichsregeln überprüft werden. Hierdurch wird sichergestellt, dass die Sicherheitsgarantien aktuell und gültig sind. Überprüfen Sie die folgenden Konfigurationen:

• Azure-Firewallregeln
• NSG-Regeln
• Azure Application Gateway- und WAF-Regeln
• Native Kubernetes-Netzwerkrichtlinien
• Firewallsteuerungen auf den entsprechenden Azure-Ressourcen. Bei dieser Architektur wird beispielsweise eine Regel in Azure Container Registry verwendet, mit der nur Datenverkehr von einem privaten Endpunkt zugelassen wird.
• Alle anderen Netzwerksteuerungen, die Sie der Architektur hinzugefügt haben

Wenn Sie seit der letzten Überprüfung Workloads außer Betrieb genommen oder die Konfiguration des Clusters geändert haben, ist es wichtig zu überprüfen, ob alle Ihre Annahmen über erforderliche Firewallausnahmen oder NSG-Regeln weiterhin gültig sind.

Anforderung 1.2

Erstellen Sie Firewall- und Routerkonfigurationen, die Verbindungen zwischen nicht vertrauenswürdigen Netzwerken und allen Systemkomponenten in der Datenumgebung des Karteninhabers einschränken.

Ihre Zuständigkeiten

Bei dieser Architektur ist der AKS-Cluster eine wichtige Komponente der Datenumgebung des Karteninhabers (Cardholder Data Environment, CDE). Wir empfehlen Ihnen dringend, den Cluster als privaten Cluster bereitzustellen, um die Sicherheit zu erhöhen. In einem privaten Cluster ist der Netzwerkdatenverkehr zwischen dem von AKS verwalteten Kubernetes-API-Server und Ihren Knotenpools privat. Der API-Server wird über einen privaten Endpunkt im Netzwerk des Clusters verfügbar gemacht.

Sie können auch einen öffentlichen Cluster auswählen, aber dieses Design wird für Cluster mit regulierten Workloads nicht empfohlen. Der API-Server ist über das Internet zugänglich. Der DNS-Eintrag kann immer ermittelt werden. Daher benötigen Sie Steuerungen, damit die Cluster-API vor öffentlichem Zugriff geschützt ist. Wenn ein öffentlicher Cluster verwendet werden muss, besteht der empfohlene Ansatz darin, enge Kontrollen über rollenbasierte Zugriffssteuerung (RBAC) in Kubernetes einzurichten, gekoppelt mit dem AKS-Feature für autorisierte IP-Adressbereiche, um einzuschränken, wer auf den AKS-API-Server zugreifen kann. Diese Lösung ist aber nicht für Cluster zu empfehlen, die regulierte Workloads enthalten.

Bei der Verarbeitung von Karteninhaberdaten (Card Holder Data, CHD) muss der Cluster mit Netzwerken interagieren, die als vertrauenswürdig oder als nicht vertrauenswürdig eingestuft sind. Bei dieser Architektur wurden beide Hub-Spoke-Netzwerke im Umkreis der PCI-DSS 3.2.1-Workload als vertrauenswürdige Netzwerke eingestuft.

Nicht vertrauenswürdige Netzwerke sind die Netzwerke außerhalb dieses Umkreises. Zu nicht vertrauenswürdigen Netzwerken gehören:

• Die anderen möglicherweise in derselben Infrastruktur befindlichen Hubs und Spokes, die sich jedoch außerhalb des Workloadumkreises befinden.
• Das öffentliche Internet.
• Das Unternehmensnetzwerk.
• Andere virtuelle Netzwerke in Azure oder einer anderen Cloudplattform.

Bei dieser Architektur ist das virtuelle Netzwerk, in dem der Image Builder gehostet wird, nicht vertrauenswürdig, da es nicht an der Verarbeitung der Karteninhaberdaten beteiligt ist. Die Interaktion der Datenumgebung für Karteninhaber (Cardholder Data Environment, CDE) mit diesen Netzwerken sollte gemäß den jeweiligen Anforderungen geschützt werden. Bei diesem privaten Cluster können Sie virtuelle Netzwerke, NSGs und andere integrierte Features verwenden, um die gesamte Umgebung zu schützen.

Informationen zu privaten Clustern finden Sie unter Erstellen eines privaten Azure Kubernetes Service-Clusters.

Anforderung 1.2.1

Beschränken Sie den ein- und ausgehenden Datenverkehr auf das für die Datenumgebung des Karteninhabers erforderliche Maß, und verweigern Sie insbesondere jeglichen anderen Datenverkehr.

Ihre Zuständigkeiten

Standardmäßig sind virtuelle Azure-Netzwerke nicht direkt über das öffentliche Internet erreichbar. Der gesamte eingehende Datenverkehr muss über einen zwischengeschalteten Datenverkehrsrouter fließen. Allerdings können alle Komponenten im Netzwerk standardmäßig öffentliche Endpunkte erreichen. Sie können dieses Verhalten deaktivieren, indem Sie ein privates Subnetz konfigurieren oder eine benutzerdefinierte Route verwenden, um den gesamten ausgehenden Datenverkehr über eine Firewall zu senden. Dieser ausgehende Datenverkehr muss explizit geschützt werden, um nur sichere Verschlüsselungsverfahren und TLS 1.2 oder höher zuzulassen.

• Die in Azure Application Gateway integrierte WAF fängt den gesamten eingehenden HTTP(S)-Datenverkehr ab und leitet den untersuchten Datenverkehr an den Cluster weiter.

  Dieser Datenverkehr kann aus vertrauenswürdigen oder nicht vertrauenswürdigen Netzwerken stammen. Application Gateway wird in einem Subnetz des Spoke-Netzwerks bereitgestellt und per NSG geschützt. Wenn Datenverkehr eintrifft, wird er anhand von WAF-Regeln abgelehnt oder zugelassen und Application Gateway leitet den Datenverkehr an das konfigurierte Back-End weiter. Die Datenumgebung für Karteninhaber (Cardholder Data Environment, CDE) wird mit Application Gateway geschützt, indem die folgenden Arten von Datenverkehr abgelehnt werden:

  • Jeglicher Datenverkehr, der nicht per TLS verschlüsselt ist.
  • Datenverkehr außerhalb des Portbereichs für die Kommunikation auf Steuerungsebene aus der Azure-Infrastruktur.
  • Integritätstestanforderungen, die von anderen Entitäten als dem internen Load Balancer im Cluster gesendet werden.

• Azure Firewall wird verwendet, um den gesamten ausgehenden Datenverkehr aus vertrauenswürdigen und nicht vertrauenswürdigen Netzwerken zu schützen.

  Azure Firewall wird in einem Subnetz des Hub-Netzwerks bereitgestellt. Um Azure Firewall als einzigen Ausgangspunkt zu erzwingen, werden benutzerdefinierte Routen (User-Defined Routes, UDRs) in Subnetzen verwendet, die ausgehenden Datenverkehr generieren können. Hierzu gehören auch Subnetze in nicht vertrauenswürdigen Netzwerken, z. B. das virtuelle Image Builder-Netzwerk. Nachdem der Datenverkehr Azure Firewall erreicht hat, werden mehrere Bereichsregeln angewendet, die es zulassen, dass Datenverkehr aus bestimmten Quellen an bestimmte Ziele fließt.

  Weitere Informationen finden Sie unter Verwenden von Azure Firewall, um AKS-Bereitstellungen (Azure Kubernetes Service) zu schützen.

• Optional ist es möglich, einen HTTP-Proxy zum Überwachen und Sichern von ausgehendem Datenverkehr vom Cluster zu externen Ressourcen zu verwenden.

  Zusätzlich zu einer Firewall möchten einige Organisationen möglicherweise einen HTTP-Proxy verwenden, um zusätzliche Steuerelemente zum Ausgang zu haben. Es wird empfohlen, weiterhin die benutzerdefinierten Routen zu haben, über die Firewall zu gehen und den Ausstiegsdatenverkehr zu beschränken, um nur über den HTTP-Proxy zu gehen. Wenn ein Pod versucht, den Proxy außer Kraft zu setzen, kann mit dieser Einrichtung die Firewall ausgehenden Datenverkehr weiterhin blockieren.

  Weitere Informationen finden Sie unter HTTP-Proxyunterstützung in Azure Kubernetes Service.

Der Cluster erfordert möglicherweise Zugriff über das öffentliche Internet auf andere Dienste. Wenn Sie beispielsweise Antischadsoftware eines Drittanbieters verwenden, müssen die Virendefinitionen dafür von einem Server über das öffentliche Internet abgerufen werden.

Interaktionen mit Endpunkten anderer Azure-Dienste erfolgen über den Azure-Backbone. Im Rahmen der regulären Vorgänge muss der Cluster beispielsweise Zertifikate aus dem verwalteten Schlüsselspeicher abrufen, Images aus einer Containerregistrierung pullen usw. Stellen Sie mittels Azure Private Link sicher, dass diese Interaktionen privat und sicher sind.

Zusätzlich zu Firewallregeln und privaten Netzwerken werden Datenverkehrsflüsse auch mit NSG-Regeln geschützt. Hier sind einige Beispielfälle aus dieser Architektur aufgeführt, in denen die Datenumgebung für Karteninhaber (Cardholder Data Environment, CDE) durch das Ablehnen von Datenverkehr geschützt wird:

• NSGs in Subnetzen mit Knotenpools lehnen jeglichen SSH-Zugriff auf die Knoten ab. Stellen Sie sicher, dass Sie über einen Prozess für den Just-In-Time-Notfallzugriff verfügen und gleichzeitig das Prinzip „Alle ablehnen“ beibehalten.
• Ein NSG in dem Subnetz, das über die Jumpbox für die Ausführung von Verwaltungstools verfügt, lehnt den gesamten Datenverkehr ab, mit Ausnahme des Datenverkehrs von Azure Bastion im Hubnetzwerk.
• NSGs in Subnetzen, die die privaten Endpunkte für Azure Key Vault und Azure Container Registry enthalten, lehnen den gesamten Datenverkehr ab, mit Ausnahme des Datenverkehrs vom internen Load Balancer und über Azure Private Link.

Anforderung 1.2.2

Schützen und synchronisieren Sie die Routerkonfigurationsdateien.

Ihre Zuständigkeiten

Richten Sie einen Mechanismus für die Erkennung des Deltawerts ein, der die Abweichung zwischen der tatsächlichen Bereitstellung und dem gewünschten Zustand angibt. Infrastructure-as-Code (IaC) ist hierfür eine gute Wahl. Bicep-Dateien oder Azure Resource Manager-Vorlagen (ARM-Vorlagen) zeichnen beispielsweise den gewünschten Zustand auf.

Für die Bereitstellungsressourcen, wie z. B. Bicep-Dateien, muss die Quellcodeverwaltung genutzt werden, damit Sie über den gesamten Änderungsverlauf verfügen. Sammeln Sie Informationen aus Azure-Aktivitätsprotokollen, Bereitstellungspipeline-Protokollen und Azure-Bereitstellungsprotokollen. Mit diesen Quellen können Sie die bereitgestellten Ressourcen verfolgen.

Im Cluster sollte für Netzwerksteuerungen, z. B. Kubernetes-Netzwerkrichtlinien, auch der Weg über die Quellcodeverwaltung gewählt werden. Bei dieser Implementierung wird Flux als GitOps-Operator verwendet. Wenn Sie eine Clusterkonfiguration synchronisieren, z. B. Netzwerkrichtlinien, kann Ihr Git-Verlauf in Kombination mit Flux- und API-Protokollen als Quelle für den Konfigurationsverlauf dienen.

Anforderung 1.2.3

Installieren Sie Umkreisfirewalls zwischen allen drahtlosen Netzwerken und der Datenumgebung des Karteninhabers, und konfigurieren Sie diese Firewalls so, dass sie nur autorisierten Datenverkehr zwischen der drahtlosen Umgebung und der Datenumgebung des Karteninhabers zulassen.

Ihre Zuständigkeiten

Die AKS-Knoten und die Knotenpools dürfen nicht über Drahtlosnetzwerke erreichbar sein. Außerdem müssen an den Kubernetes-API-Server gesendete Anforderungen abgelehnt werden. Der Zugriff auf diese Komponenten ist auf autorisierte und geschützte Subnetze beschränkt.

Im Allgemeinen sollten Sie für lokalen Datenverkehr den Zugriff auf das Spoke-Netzwerk einschränken.

Anforderung 1.3

Verbieten Sie den direkten öffentlichen Zugriff zwischen dem Internet und allen Systemkomponenten in der Datenumgebung des Karteninhabers.

Ihre Zuständigkeiten

AKS-Clusterknotenpools werden innerhalb des virtuellen Netzwerks betrieben und sind von öffentlichen Netzwerken, z. B. dem Internet, isoliert. Stellen Sie die Isolation sicher, indem Sie die Zuordnung von öffentlichen IP-Adressen auf Clusterknoten verhindern und NSG-Regeln auf die Clustersubnetze anwenden, um dafür zu sorgen, dass Internetdatenverkehr blockiert wird. Informationen zum kontrollierten Zugriff finden Sie im Abschnitt zur DMZ.

Der AKS-Cluster verfügt über Systemknotenpools, in denen wichtige Systempods gehostet werden. Auch die Benutzerknotenpools enthalten Pods, in denen andere Dienste ausgeführt werden, die an Clustervorgängen beteiligt sind. Von Pods kann Flux ggf. ausgeführt werden, um die Clusterkonfiguration mit einem GitHub-Repository zu synchronisieren, oder der Eingangsdatencontroller, um Datenverkehr an die Workloadpods zu leiten. Unabhängig vom Typ des Knotenpools müssen alle Knoten geschützt werden.

Eine weitere wichtige Systemkomponente ist der API-Server, der zum Durchführen nativer Kubernetes-Aufgaben verwendet wird, z. B. zum Aufrechterhalten des gewünschten Zustands des Clusters und der Konfiguration. Ein Vorteil der Verwendung eines privaten Clusters ist, dass der API-Serverendpunkt standardmäßig nicht verfügbar gemacht wird. Informationen zu privaten Clustern finden Sie unter Erstellen eines privaten Azure Kubernetes Service-Clusters.

Interaktionen mit anderen Endpunkten müssen ebenfalls geschützt werden. Eine Möglichkeit besteht in der Einschränkung der Kommunikation über ein privates Netzwerk. Legen Sie beispielsweise fest, dass der Cluster Images über eine private Verbindung aus Azure Container Registry pullt.

Anforderung 1.3.1

Implementieren Sie eine DMZ, um den eingehenden Datenverkehr auf Systemkomponenten zu beschränken, die autorisierte öffentlich zugängliche Dienste, Protokolle und Ports bereitstellen.

Ihre Zuständigkeiten

Hier sind einige bewährte Methoden angegeben:

• Konfigurieren Sie keine öffentlichen IP-Adressen auf den Knoten des Knotenpools.
• Verwenden Sie Azure Policy, um sicherzustellen, dass Kubernetes keinen öffentlichen Lastenausgleich verfügbar macht. Der Datenverkehr innerhalb des Clusters muss über interne Lastenausgleichsmodule geleitet werden.
• Machen Sie interne Lastenausgleichsmodule nur für Azure Application Gateway mit WAF-Integration verfügbar.
• Für alle Netzwerksteuerungen sollten Einschränkungen für Quelle, Ziel, Port und Protokoll angegeben werden (falls zutreffend).
• Verhindern Sie, dass der API-Server über das Internet zugänglich ist. Wenn Sie den Cluster im privaten Modus ausführen, ist der Endpunkt nicht öffentlich zugänglich, und die Kommunikation zwischen den Knotenpools und dem API-Server verläuft über ein privates Netzwerk.

Benutzer können ein Umkreisnetzwerk implementieren, um AKS-Cluster zu schützen. Informationen hierzu finden Sie unter Cloud-DMZ.

Anforderung 1.3.2

Beschränken Sie den eingehenden Internetdatenverkehr auf IP-Adressen innerhalb der DMZ.

Ihre Zuständigkeiten

Nutzen Sie im Clusternetzwerk eine NSG in dem Subnetz mit dem internen Lastenausgleichsmodul. Konfigurieren Sie Regeln so, dass nur Datenverkehr aus dem Subnetz akzeptiert wird, in dem Azure Application Gateway mit WAF-Integration vorhanden ist. Verwenden Sie innerhalb des AKS-Clusters Netzwerkrichtlinien (NetworkPolicies) von Kubernetes, um den eingehenden Datenverkehr für die Pods zu einzuschränken.

Anforderung 1.3.3

Implementieren Sie Antispoofingmaßnahmen, um gefälschte Quell-IP-Adressen zu erkennen und zu blockieren.

Azure-Zuständigkeiten

Von Azure wird eine Netzwerkfilterung implementiert, um gefälschten Datenverkehr zu verhindern und eingehenden wie ausgehenden Datenverkehr auf vertrauenswürdige Plattformkomponenten zu beschränken.

Anforderung 1.3.4

Erlauben Sie keinen unbefugten ausgehenden Datenverkehr von der Datenumgebung des Karteninhabers ins Internet.

Ihre Zuständigkeiten

Hier sind Möglichkeiten angegeben, wie Sie nicht autorisierten ausgehenden Datenverkehr blockieren können:

• Erzwingen, dass der gesamte vom AKS-Cluster ausgehende Datenverkehr durch eine Azure Firewall läuft, indem Sie benutzerdefinierte Routen (UDRs) für alle Clustersubnetze verwenden. Hierzu gehören Subnetze mit System- und Benutzerknotenpools.
• Schränken Sie ausgehenden Datenverkehr ein, indem Sie NSGs in Subnetzen mit Knotenpools hinzufügen.
• Verwenden Sie Netzwerkrichtlinien (NetworkPolicies) von Kubernetes, um den ausgehenden Datenverkehr der Pods einzuschränken.
• Verwenden Sie ein Dienstnetz (Service Mesh), um zusätzliche Richtlinien zu verarbeiten. Wenn Sie beispielsweise nur per TLS verschlüsselten Datenverkehr zwischen Pods zulassen, kann die TLS-Überprüfung vom Dienstnetzproxy verarbeitet werden. Dieses Beispiel wird im Rahmen dieser Implementierung veranschaulicht. Envoy wird als Proxy bereitgestellt.
• Verhindern Sie das Hinzufügen öffentlicher IP-Adressen zu den Netzwerken innerhalb der Datenumgebung für Karteninhaber (Cardholder Data Environment, CDE), sofern dies nicht über explizit autorisierte Subnetze erfolgt, z. B. die Firewallsubnetze.
• Verwenden Sie einen HTTP-Proxy, zusätzlich zu Azure Firewall, um ausgehenden Datenverkehr aus dem AKS-Cluster ins Internet zu beschränken.
• Verwenden Sie den Azure Monitor Private Link-Dienst (AMPLS), um Protokolle von Containererkenntnissen zu erhalten, die über eine sichere, private Verbindung an Azure Monitor gesendet werden. Verstehen Sie die Auswirkungen der Aktivierung von AMPLS.

Ausführlichere Informationen finden Sie unter Steuern des ausgehenden Datenverkehrs für Clusterknoten in Azure Kubernetes Service (AKS).

Anforderung 1.3.5

Erlauben Sie nur „eingerichtete“ Verbindungen ins Netzwerk.

Azure-Zuständigkeiten

Von Azure wird eine Netzwerkfilterung implementiert, um gefälschten Datenverkehr zu verhindern und eingehenden wie ausgehenden Datenverkehr auf vertrauenswürdige Plattformkomponenten zu beschränken. Das Azure-Netzwerk ist abgetrennt, um den kundenseitigen Datenverkehr vom Verwaltungsdatenverkehr zu trennen.

Anforderung 1.3.6

Platzieren Sie Systemkomponenten, die Karteninhaberdaten (z. B. eine Datenbank) in einer internen Netzwerkzone speichern, die von der DMZ und anderen nicht vertrauenswürdigen Netzwerken getrennt ist.

Ihre Zuständigkeiten

Machen Sie Ihre Speichersysteme nur über ein privates Netzwerk zugänglich, z. B. über Private Link. Schränken Sie außerdem den Zugriff aus den Knotenpoolsubnetzen ein, die hierfür erforderlich sind. Halten Sie den Status aus dem Cluster heraus und in einer eigenen dedizierten Sicherheitszone.

Anforderung 1.3.7

Geben Sie keine privaten IP-Adressen und Routinginformationen an Unbefugte weiter.

Ihre Zuständigkeiten

Zur Erfüllung dieser Anforderung kommt ein öffentlicher AKS-Cluster nicht in Frage. Bei Verwendung eines privaten Clusters werden DNS-Einträge über eine private DNS-Zone aus dem öffentlichen Internet herausgehalten. Es ist jedoch weiterhin möglich, einen privaten AKS-Cluster mit einer öffentlichen DNS-Adresse zu erstellen. Daher wird empfohlen, dieses Feature explizit zu deaktivieren, indem Sie enablePrivateClusterPublicFQDN auf false festlegen, damit die private IP-Adresse Ihrer Steuerungsebene nicht offengelegt wird. Erwägen Sie das Verwenden von Azure Policy, um die Verwendung privater Cluster ohne öffentliche DNS-Einträge zu erzwingen.

Verwenden Sie darüber hinaus eine private DNS-Zone für das Routing zwischen dem Subnetz, das über Azure Application Gateway mit WAF-Integration verfügt, und dem Subnetz, in dem das interne Lastenausgleichsmodul enthalten ist. Stellen Sie sicher, dass HTTP-Antworten in den Headern oder im Text keine Informationen zu privaten IP-Adressen enthalten. Vergewissern Sie sich, dass Protokolle, die ggf. IP-Adress- und DNS-Einträge enthalten können, nicht über ihren betriebsbezogenen Zweck hinaus verfügbar gemacht werden.

Ein Azure-Dienst, der über Private Link verbunden ist, weist keinen öffentlichen DNS-Eintrag auf, über den Ihre privaten IP-Adressen verfügbar gemacht werden. In Ihrer Infrastruktur sollte Private Link möglichst optimal genutzt werden.

Anforderung 1.4

Installieren Sie persönliche Firewallsoftware oder gleichwertige Funktionen auf allen tragbaren Computergeräten, die sich außerhalb des Netzwerks mit dem Internet verbinden und die auch für den Zugriff auf die CDE verwendet werden.

Ihre Zuständigkeiten

Der private Cluster wird über die AKS-Steuerungsebene verwaltet. Sie haben keinen direkten Zugriff auf Knoten. Für administrative Aufgaben müssen Sie Verwaltungstools, z. B. kubectl, über eine separate Computeressource verwenden. Eine Option ist die Nutzung einer Jumpbox mit „Air Gap“, auf der Sie die Befehle ausführen können. Darüber hinaus muss ein- und ausgehender Datenverkehr der Jumpbox eingeschränkt und geschützt sein. Falls ein VPN für den Zugriff verwendet wird, sollten Sie sicherstellen, dass der Clientcomputer über eine Unternehmensrichtlinie verwaltet wird und alle Richtlinien für bedingten Zugriff vorhanden sind.

Bei dieser Architektur befindet sich diese Jumpbox in einem separaten Subnetz innerhalb des Spoke-Netzwerks. Der Zugriff auf die Jumpbox in eingehender Richtung wird durch die Verwendung einer NSG eingeschränkt, die den Zugriff nur über Azure Bastion per SSH zulässt.

Für die Ausführung bestimmter Befehle auf der Jumpbox müssen Sie öffentliche Endpunkte erreichen können. Ein Beispiel hierfür sind Endpunkte, die über die Azure-Verwaltungsebene verwaltet werden. Dieser ausgehende Datenverkehr muss geschützt sein. Ähnlich wie bei anderen Komponenten im Spoke-Netzwerk wird ausgehender Datenverkehr von der Jumpbox mit einer benutzerdefinierten Route eingeschränkt, die erzwingt, dass HTTPS-Datenverkehr über Azure Firewall fließt.

Anforderung 1.5

Stellen Sie sicher, dass Sicherheitsrichtlinien und betriebliche Verfahren für die Verwaltung von Firewalls dokumentiert und verwendet werden sowie allen beteiligten Parteien bekannt sind.

Ihre Zuständigkeiten

Es ist wichtig, dass Sie eine umfassende Dokumentation zum Prozess und zu den Richtlinien führen. Dies gilt insbesondere, wenn Sie Azure-Firewallregeln verwalten, bei denen der AKS-Cluster segmentiert wird. 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 mit Konten, für die umfassende Administratorrechte gewährt wurden.

Anforderung 2: Vermeiden der Verwendung der vom Anbieter angegebenen Standardwerte für Systemkennwörter und andere Sicherheitsparameter

Ihre Zuständigkeiten

Anforderung	Verantwortlichkeit
Anforderung 2.1	Ändern Sie vom Anbieter bereitgestellte Standardwerte immer, und entfernen oder deaktivieren Sie unnötige Standardkonten vor dem Installieren eines Systems im Netzwerk.
Anforderung 2.2	Entwickeln Sie Konfigurationsstandards für alle Systemkomponenten. Stellen Sie sicher, dass diese Standards alle bekannten Sicherheitsrisiken berücksichtigen und den branchenweit anerkannten Standards zur Verstärkung der Systemsicherheit entsprechen.
Anforderung 2.3	Verschlüsseln Sie Administratorzugriff, der nicht über die Konsole erfolgt, mit sicheren Kryptografieverfahren.
Anforderung 2.4	Verwalten Sie einen Bestand an Systemkomponenten, die sich für PCI-DSS im zulässigen Bereich befinden.
Anforderung 2.5	Stellen Sie sicher, dass Sicherheitsrichtlinien und betriebliche Verfahren für das Verwalten von Standardwerten vom Anbieter und andere Sicherheitsparameter dokumentiert und verwendet werden sowie allen beteiligten Parteien bekannt sind.
Anforderung 2.6	Gemeinsam genutzte Hostinganbieter müssen die gehostete Umgebung und Karteninhaberdaten der einzelnen Entitäten schützen.

Ändern von Kennwörtern und anderen Sicherheitseinstellungen nach der Werksauslieferung

Anforderung 2.1

Ändern Sie vom Anbieter bereitgestellte Standardwerte immer, und entfernen oder deaktivieren Sie unnötige Standardkonten vor dem Installieren eines Systems im Netzwerk.

Ihre Zuständigkeiten

Die von Anbietern bereitgestellten Standardeinstellungen müssen geändert werden. Standardeinstellungen sind häufig genutzte Angriffsvektoren, die das System anfällig für Angriffe machen. Hier einige Überlegungen dazu:

• Deaktivieren Sie den Administratorzugriff auf die Containerregistrierung.
• Stellen Sie sicher, dass Jumpboxes und Build-Agents die Verfahren der Benutzerverwaltung befolgen und nicht benötigte Systembenutzer entfernen.
• Vermeiden Sie es, einen SSH-Schlüsselzugriff auf Knoten zu generieren oder diese Art von Zugriff für Administratorbenutzer zu gewähren. Falls ein Notfallzugriff erforderlich ist, sollten Sie den Azure-Wiederherstellungsprozess nutzen, um Just-In-Time-Zugriff zu erhalten.

Azure-Zuständigkeiten

Microsoft Entra ID verfügt über Kennwortrichtlinien, deren Anwendung für neue Kennwörter erzwungen wird, die von Benutzern angegeben werden. Wenn Sie ein Kennwort ändern, ist eine Überprüfung des alten Kennworts erforderlich. Ein von einem Administrator zurückgesetztes Kennwort muss geändert werden, wenn sich der Benutzer das nächste Mal anmeldet.

Anforderung 2.1.1

Für Drahtlosumgebungen, die mit der Umgebung der Karteninhaberdaten verbunden sind oder Karteninhaberdaten übertragen, ändern Sie bei der Installation ALLE Standardwerte des Anbieters für Drahtlosumgebungen, einschließlich, aber nicht beschränkt auf standardmäßige Drahtlosverschlüsselungsschlüssel, Kennwörter und SNMP-Communityzeichenfolgen.

Ihre Zuständigkeiten

Diese Architektur und die Implementierung sind nicht für die Durchführung von lokalen oder unternehmensinternen Netzwerk-zu-Cloud-Transaktionen über Drahtlosverbindungen konzipiert. Informationen zu den zu berücksichtigenden Punkten finden Sie im Leitfaden zum offiziellen PCI-DSS 3.2.1-Standard.

Anforderung 2.2

Entwickeln Sie Konfigurationsstandards für alle Systemkomponenten.

Ihre Zuständigkeiten

Implementieren Sie die Empfehlungen der Microsoft-Benchmark für Cloudsicherheit. Hierbei erhalten Sie einen zentralen, konsolidierten Überblick über die Azure-Sicherheitsempfehlungen, die Branchenframeworks wie CIS, NIST, PCI-DSS 3.2.1 und andere abdecken. Verwenden Sie die Features von Microsoft Defender für Cloud und Azure Policy, um die Nachverfolgung für die Standards durchzuführen. Der Azure-Sicherheitsvergleichstest ist die Standardinitiative für Microsoft Defender für Cloud. Erwägen Sie, zusätzliche automatisierte Überprüfungen in Azure Policy und Azure Tenant Security Solution (AzTS) zu erstellen.

Dokumentieren Sie den gewünschten Konfigurationsstatus aller Komponenten in der CDE, insbesondere für AKS-Knoten, Jumpbox, Build-Agents und andere Komponenten, die mit dem Cluster interagieren.

Weitere Informationen finden Sie unter Microsoft Cloud Security Benchmark.

Azure-Zuständigkeit

Azure verfügt über Standards für die Sicherheitskonfiguration, die den in der Branche akzeptierten Härtungsstandards entsprechen. Die Standards werden mindestens einmal jährlich überprüft.

Anforderung 2.2.1

Implementieren Sie nur eine primäre Funktion pro Server, um zu verhindern, dass sich Funktionen, die unterschiedliche Sicherheitsstufen erfordern, auf demselben Server befinden. (Beispielsweise müssen Webserver, Datenbankserver und DNS auf separaten Servern implementiert werden.)

Ihre Zuständigkeiten

Die zentrale Strategie besteht darin, für die nötige Segmentierung zu sorgen. Eine Möglichkeit besteht darin, die Komponenten, die sich innerhalb des Geltungsbereichs befinden, und die Komponenten, die sich außerhalb des Geltungsbereichs befinden, jeweils in separaten Clustern bereitzustellen. Beachten Sie hierbei, dass dies zu höheren Kosten für die hinzugefügte Infrastruktur und aufgrund des zusätzlichen Wartungsaufwands führt. Ein weiterer Ansatz besteht darin, alle Komponenten zusammen in einem freigegebenen Cluster anzuordnen. Nutzen Sie Segmentierungsstrategien, um hierbei für die Trennung zu sorgen. Verwenden Sie innerhalb eines Clusters beispielsweise separate Knotenpools.

In der Referenzimplementierung wird der zweite Ansatz durch eine Microserviceanwendung veranschaulicht, die in einem einzelnen Cluster bereitgestellt wird. Die Anwendung verfügt über zwei Gruppen von Diensten: Eine Gruppe verfügt über Pods innerhalb des Geltungsbereichs, und die andere befindet sich außerhalb des Geltungsbereichs. Beide Gruppen sind auf zwei Benutzerknotenpools verteilt. Durch die Verwendung von Kubernetes-Taints werden Pods innerhalb des Geltungsbereichs und Pods außerhalb des Geltungsbereichs in separaten Knotenpools bereitgestellt und nutzen niemals denselben virtuellen Computer.

Bei Containertechnologien wird diese Segmentierung standardmäßig bereitgestellt, da nur eine Instanz eines Containers jeweils für eine Funktion im System verantwortlich ist.

Jeder Workloadpod sollte seine eigene Identität verwenden. Sie darf keine Identitäten auf Cluster- oder Knotenebene erben.

Verwenden Sie nach Möglichkeit externen Speicher anstelle von Speicher auf dem Knoten (im Cluster). Reservieren Sie Clusterpods ausschließlich für Arbeitsschritte, die im Rahmen der Verarbeitung von Karteninhaberdaten ausgeführt werden müssen. Verschieben Sie nicht in den Geltungsbereich fallende Vorgänge an Orte außerhalb des Clusters. Diese Anleitung gilt für Build-Agents, nicht verbundene Workloads oder Aktivitäten, z. B. die Nutzung einer Jumpbox innerhalb des Clusters.

Anforderung 2.2.2

Aktivieren Sie nur Dienste, Protokolle, Daemons usw., die für die richtige Funktionsweise des Systems erforderlich sind.

Ihre Zuständigkeiten

Überprüfen Sie die Features und die Auswirkungen, bevor Sie sie aktivieren. Die Standardeinstellungen können Features enthalten, die Sie nicht benötigen, und für diese Features ist unter Umständen der Einblick in die Workload erforderlich. Ein Beispiel hierfür sind die Verschlüsselungsverfahren in der SSL-Standardrichtlinie für Azure Application Gateway. Überprüfen Sie, ob mit der Richtlinie zu viele Berechtigungen gewährt werden. Die Empfehlung lautet, eine benutzerdefinierte Richtlinie zu erstellen, indem Sie nur die benötigten Verschlüsselungsverfahren auswählen.

Entfernen Sie bei Komponenten, über die Sie die vollständige Kontrolle haben, alle nicht benötigten Systemdienste aus den Images. Überprüfen Sie beispielsweise die Images für Jumpboxes und Build-Agents, und entfernen Sie alle nicht benötigten Komponenten.

Dokumentieren Sie für Komponenten, in die Sie Einblick haben, z. B. AKS-Knoten, was von Azure auf den Knoten installiert wird. Erwägen Sie die Verwendung von DaemonSets, um zusätzliche Überprüfungen zu ermöglichen, die für diese cloudgesteuerten Komponenten erforderlich sind.

Anforderung 2.2.3

Implementieren Sie zusätzliche Sicherheitsfeatures für alle erforderlichen Dienste, Protokolle oder Daemons, die als unsicher gelten.

Ihre Zuständigkeiten

Application Gateway verfügt über eine integrierte WAF und handelt den TLS-Handshake für die Anforderung aus, die an den zugehörigen öffentlichen Endpunkt gesendet wird. Auf diese Weise werden nur sichere Verschlüsselungsverfahren zugelassen. Von der Referenzimplementierung werden nur TLS 1.2 und genehmigte Verschlüsselungsverfahren unterstützt.

Angenommen, Sie verfügen über ein Legacy-Gerät, das über Azure Application Gateway mit der CDE interagieren muss. Um diese Anforderung zu erfüllen, muss Application Gateway ein unsicheres Protokoll aktivieren. Dokumentieren Sie diese Ausnahme, und überwachen Sie, ob dieses Protokoll über dieses Legacy-Gerät hinaus verwendet wird. Deaktivieren Sie dieses Protokoll sofort, nachdem die Nutzung dieser Legacy-Interaktion eingestellt wurde.

Application Gateway darf nicht auf Anforderungen an Port 80 reagieren. Führen Sie keine Umleitungen auf Anwendungsebene aus. Diese Referenzimplementierung verfügt über eine NSG-Regel, mit der Datenverkehr über Port 80 blockiert wird. Die Regel befindet sich im Subnetz mit Application Gateway.

Falls für eine Workload in Ihrem Cluster eine Organisationsrichtlinie, die sich auf Sicherheitskonformitätsprofile oder andere Kontrollen (z. B. Grenzwerte und Kontingente) bezieht, nicht eingehalten werden kann, sollten Sie sicherstellen, dass diese Ausnahme dokumentiert wird. Sie müssen eine Überwachung durchführen, um sicherzustellen, dass nur die erwartete Funktionalität möglich ist.

Anforderung 2.2.4

Konfigurieren Sie Systemsicherheitsparameter, um Missbrauch zu verhindern.

Ihre Zuständigkeiten

Alle in der Architektur verwendeten Azure-Dienste müssen die Empfehlungen des Microsoft-Benchmarks für Cloudsicherheit befolgen. Diese Empfehlungen dienen Ihnen als Ausgangspunkt für die Auswahl bestimmter Einstellungen für die Sicherheitskonfiguration. Vergleichen Sie Ihre Konfiguration außerdem mit der Baselineimplementierung für diesen Dienst. Weitere Informationen zu den Sicherheitsbaselines finden Sie unter Sicherheitsbaselines für Azure.

Der Open Policy Agent-Zugangscontroller arbeitet mit Azure Policy zusammen, um Fehlkonfigurationen im Cluster zu erkennen und zu verhindern. Angenommen, es ist eine Organisationsrichtlinie vorhanden, bei der keine Zuordnungen von öffentlichen IP-Adressen auf den Knoten zugelassen werden. Wenn eine Zuordnung dieser Art erkannt wird, wird sie für die Überprüfung gekennzeichnet oder basierend auf der Aktion, die in der Richtliniendefinition angegeben ist, abgelehnt.

Auf der Infrastrukturebene können Sie Einschränkungen für den Typ und die Konfiguration von Azure-Ressourcen anwenden. Verwenden Sie Azure Policy, um Fehlkonfigurationen zu verhindern. Diese Referenzimplementierung enthält eine Richtlinie, mit der die Erstellung von AKS-Clustern abgelehnt wird, die nicht privat sind.

Stellen Sie sicher, dass alle Ausnahmen dokumentiert und regelmäßig überprüft werden.

Azure-Zuständigkeiten

Azure stellt sicher, dass nur entsprechend berechtigte Mitarbeiter die Sicherheitskontrollen der Azure-Plattform konfigurieren können. Hierfür werden mehrstufige Zugriffssteuerungen und eine dokumentierte Geschäftsanforderung genutzt.

Anforderung 2.2.5

Entfernen Sie alle unnötigen Funktionen wie Skripts, Treiber, Features, Subsysteme, Dateisysteme und unnötige Webserver.

Ihre Zuständigkeiten

Installieren Sie keine Software auf Jumpboxes oder Build-Agents, die nicht an der Verarbeitung einer Transaktion beteiligt sind oder Einblick in Konformitätsanforderungen, z. B. Sicherheits-Agents, ermöglichen. Diese Empfehlung gilt auch für die Clusterentitäten, z. B. DaemonSet und Pods. Stellen Sie sicher, dass alle Installationen erkannt und protokolliert werden.

Anforderung 2.3

Verschlüsseln Sie Administratorzugriff, der nicht über die Konsole erfolgt, mit sicheren Kryptografieverfahren.

Ihre Zuständigkeiten

Der gesamte Administratorzugriff auf den Cluster sollte über die Konsole erfolgen. Machen Sie die Steuerungsebene des Clusters nicht zugänglich.

Azure-Zuständigkeiten

Von Azure wird sichergestellt, dass beim Zugriff auf die Hypervisor-Infrastruktur die Nutzung von sicheren Kryptografieverfahren durchgesetzt wird. Darüber hinaus wird sichergestellt, dass Kunden über das Azure-Portal mit sicheren Kryptografieverfahren auf ihre Dienst- und Hostkonsolen zugreifen können.

Anforderung 2.4

Verwalten Sie einen Bestand an Systemkomponenten, die sich für PCI-DSS im zulässigen Bereich befinden.

Ihre Zuständigkeiten

Alle in der Architektur verwendeten Azure-Ressourcen müssen richtig mit Tags versehen werden. Die Tags dienen als Hilfe bei der Datenklassifizierung und geben an, ob sich der Dienst innerhalb oder außerhalb des Geltungsbereichs befindet. Bei sorgfältiger Verwendung von Tags können Sie Ressourcen abfragen, den Bestand verwalten, Kosten nachverfolgen und Warnungen festlegen. Darüber hinaus sollten Sie regelmäßig eine Momentaufnahme dieser Dokumentation erstellen.

Vermeiden Sie es, die innerhalb und außerhalb des Geltungsbereichs befindlichen Ressourcen auf sehr niedriger Ebene mit Tags zu versehen. Während der weiteren Entwicklung kann es sein, dass zunächst außerhalb des Geltungsbereichs befindliche Ressourcen später in den Geltungsbereich fallen. Dies kann auch der Fall sein, wenn sie indirekt mit den Karteninhaberdaten interagieren oder sich in der Nähe dieser Daten befinden. Diese Ressourcen unterliegen der Überwachung und können bei einer Überprüfung Teil einer repräsentativen Stichprobe sein. Erwägen Sie, Tags auf einer höheren Ebene, also auf Abonnement- und Clusterebene, zu verwenden.

Informationen zu Tags finden Sie im Leitfaden zur Entscheidungsfindung für Ressourcenbenennung und -markierung.

Versehen Sie im Cluster enthaltene Objekte mit Tags, indem Sie Kubernetes-Bezeichnungen verwenden. Auf diese Weise können Sie Objekte organisieren, eine Sammlung mit Objekten auswählen und den Bestand melden.

Anforderung 2.5

Stellen Sie sicher, dass Sicherheitsrichtlinien und betriebliche Verfahren für das Verwalten von Standardwerten vom Anbieter und andere Sicherheitsparameter 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. Ihre Mitarbeiter sollten in Bezug auf die Sicherheitsfeatures und Konfigurationseinstellungen der einzelnen Azure-Ressourcen geschult sein. Personen, die in regulierten Umgebungen arbeiten, müssen geschult werden, informiert sein und Anreize erhalten, damit sie die Sicherheitsgarantien unterstützen. Diese Schritte sind besonders wichtig für Personen, denen umfassende Administratorrechte gewährt werden.

Anforderung 2.6

Gemeinsam genutzte Hostinganbieter müssen die gehostete Umgebung und Karteninhaberdaten der einzelnen Entitäten schützen.

Ihre Zuständigkeiten

Azure bietet Sicherheitsgarantien für alle gemeinsam genutzten Komponenten einer gehosteten Umgebung. Es wird dringend empfohlen, Ihre AKS-Knoten als dedizierten Host für diese Workload zu behandeln. Das heißt, alle Computeressourcen sollten sich in einem einzelnen Mandantenmodell befinden und nicht mit anderen ggf. verwendeten Workloads geteilt werden.

Wenn eine vollständige Computeisolation auf Azure-Infrastrukturebene erforderlich ist, können Sie Azure Dedicated Host zu einem AKS-Cluster (Azure Kubernetes Service) hinzufügen. Bei diesem Angebot werden physische, für Ihre Workload dedizierte Server bereitgestellt, sodass Sie AKS-Knoten direkt in diesen bereitgestellten Hosts platzieren können. Diese Architekturoption hat erhebliche Auswirkungen auf die Kosten und erfordert eine sorgfältige Kapazitätsplanung. Sie ist für die meisten Szenarien nicht typisch.

Nächste Schritte

Sorgen Sie für den Schutz der gespeicherten Karteninhaberdaten. Verschlüsseln Sie die Daten, wenn Karteninhaberdaten über offen zugängliche öffentliche Netzwerke übertragen werden.

Zugehörige Ressourcen

• Azure Kubernetes Service (AKS)-Architekturentwurf
• Vorstellung eines regulierten AKS-Clusters für PCI-DSS 3.2.1 (Teil 1 von 9)
• Architektur eines regulierten AKS-Clusters für PCI-DSS 3.2.1 (Teil 2 von 9)
• Baselinearchitektur für einen AKS-Cluster (Azure Kubernetes Service)
• AKS-Baseline für Cluster in mehreren Regionen