Netzwerksicherheit für einen AKS regulierten Cluster für PCI DSS 4.0.1

In diesem Artikel werden die Netzwerküberlegungen für einen Azure Kubernetes Service (AKS)-Cluster beschrieben, der gemäß dem Payment Card Industry Data Security Standard (PCI DSS 4.0.1) konfiguriert ist.

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

Das Hauptthema des PCI DSS 4.0.1-Standards ist Sicherheit mit erweiterten Anforderungen für die Netzwerksegmentierung, risikobasierte Bereichsdefinition und kontinuierliche Überwachung. 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 Kubernetes hosten, reicht es nicht aus, sich auf herkömmliche Netzwerkkonstrukte wie Firewallregeln zu verlassen. PCI DSS 4.0.1 betont die Verwendung von cloud-nativen und Kubernetes-nativen Steuerelementen für segmentierungs- und sichere Kommunikation. Es gibt auch Kubernetes-native Konstrukte, mit denen der Datenverkehrsfluss im Cluster kontrolliert wird, z. B. die Ressource NetworkPolicy. Es wird dringend empfohlen, auf die Kubernetes-Dokumentation zu verweisen, um die Kernkonzepte von isolierten Pods und Eingangs- und Ausgangsrichtlinien zu verstehen.

Erstellen und Verwalten eines sicheren Netzwerks und sicherer Systeme

Anforderung 1: Installieren und Verwalten einer Firewallkonfiguration zum Schutz von Kartenhalterdaten

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.

Sie können Azure Firewall in AKS integrieren und ausgehenden Datenverkehr aus dem Cluster einschränken, bei dem es sich um eine Schlüsselkomponente des CDE handelt. Die Konfiguration wird mit einem AKS-FQDN-Tag leicht gemacht. Der empfohlene Prozess wird in der Verwendung der Azure Firewall zum Schutz von Azure Kubernetes Service (AKS)-Bereitstellungen bereitgestellt.

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, den Sie für zusätzliche ausgehende Datenverkehrskontrolle und -überwachung für den Cluster verwenden können. 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. Daher wird empfohlen, dass Workloads dieselben Proxyinformationen erben können. Pods können Proxyinformationen außer Kraft setzen, daher empfiehlt es sich, 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, das viele der in PCI DSS 4.0.1 beschriebenen Firewallanforderungen behandelt.

PCI DSS 4.0.1 erweitert Anforderungen für die Netzwerksegmentierung, die risikobasierte Validierung des Umfangs und die kontinuierliche Überprüfung von Firewall- und Routerkonfigurationen. Verwenden Sie cloudeigene Netzwerksicherheitstools wie virtuelle Netzwerke, Sicherheitsgruppen und Mikrosegmentierung. Stellen Sie sicher, dass containerisierte Workloads die richtige Namespace-Isolation und sichere Kommunikationsprotokolle verwenden. Integrieren Sie mehrschichtige Verteidigung mithilfe von Kubernetes-Netzwerkrichtlinien oder ähnlichen Tools in Containerumgebungen.

Ihre Zuständigkeiten

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. Wenn IaC keine Option ist, verfügen Sie über einen gut dokumentierten Prozess zum Nachverfolgen, Implementieren und sicheren Bereitstellen von Firewallregeländerungen. 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.

Die folgende Abbildung zeigt das Netzwerkdiagramm der Referenzimplementierung:

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 einen Schritt hinzu, um das Datenflussdiagramm im Rahmen des Änderungsverwaltungsprozesses zu aktualisieren.

Da sich diese Architektur auf die Infrastruktur und nicht auf die Arbeitsauslastung konzentriert, haben wir hier keine Abbildungen angegeben.

Anforderung 1.1.4

Anforderungen für eine Firewall in jeder Internetverbindung und zwischen jeder demilitarisierten 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.

Diese Architektur verwendet verschiedene Firewalltechnologien, um Datenverkehr zu und vom Cluster zu prüfen, der das CDE hostet:

• Das Azure Application Gateway für Container dient als Datenverkehrsrouter, und seine integrierte Webanwendungsfirewall (WAF) sichert eingehenden Datenverkehr für den Cluster.

• Azure Firewall schützt den gesamten ausgehenden (Ausgehenden) Datenverkehr von jedem Netzwerk und seinen Subnetzen.

  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 sichern den Datenverkehr zwischen dem Cluster und anderen Komponenten innerhalb der Infrastruktur. 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 Steuerelemente für die Netzwerkflü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.

Wissen Sie beispielsweise, wer für die Governance der Sicherung von Netzwerken 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.

In der folgenden Tabelle sind Beispiele aufgeführt, in denen Sie Datenverkehr zulassen können:

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. Dadurch wird sichergestellt, dass die Sicherheitsüberprüfungen aktuell und gültig sind. Stellen Sie sicher, dass Sie die folgenden Konfigurationen überprüfen:

• Azure-Firewallregeln
• NSG-Regeln
• Azure-Anwendungsgateway für Container 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 Netzwerksteuerelemente, die der Architektur hinzugefügt wurden.

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). Es wird dringend empfohlen, den Cluster als privaten Cluster für erhöhte Sicherheit bereitzustellen. 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 nicht für Cluster empfohlen, die regulierte Workloads enthalten. Der API-Server wird für das Internet verfügbar gemacht, und der DNS-Eintrag ist immer auffindbar, sodass Sie über Steuerelemente verfügen müssen, um die Cluster-API vor öffentlichem Zugriff zu schützen. 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. In dieser Architektur gelten beide Hub-Spoke-Netzwerke innerhalb des Umkreises der PCI DSS 4.0.1-Workload als vertrauenswürdige Netzwerke.

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 (AKS)-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 einen UDR 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.

• Das in Azure Application Gateway für Container integrierte WAF fängt den gesamten HTTP(S)-Eingangsdatenverkehr ab und leitet den überprüften Datenverkehr an den Cluster weiter.

  Dieser Datenverkehr kann aus vertrauenswürdigen oder nicht vertrauenswürdigen Netzwerken stammen. Das Anwendungsgateway für Container wird in einem Subnetz des Speichennetzwerks bereitgestellt und durch eine NSG gesichert. Während Datenverkehr einfließt, erlauben oder verweigern WAF-Regeln, und Application Gateway für Container leitet Datenverkehr an das konfigurierte Backend weiter. Beispielsweise schützt der Application Gateway für Container das CDE, indem es die folgenden Arten von Netzwerkverkehr blockiert:

  • Der gesamte Datenverkehr, der nicht 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 schützt den gesamten ausgehenden (Ausgehenden) Datenverkehr von vertrauenswürdigen und nicht vertrauenswürdigen Netzwerken.

  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 der Azure Firewall zum Schutz von Azure Kubernetes Service (AKS)-Bereitstellungen.

• Optional ist es möglich, einen HTTP-Proxy für die Überwachung und Sicherung 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, dass Sie weiterhin über die benutzerdefinierten Routen zur Firewall verfügen und den Ausgehenden Datenverkehr einschränken möchten, um einfach zum HTTP-Proxy zu wechseln. 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 (AKS).

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. Die folgenden Beispiele veranschaulichen diese Architektur, in der das CDE durch Denkung des Datenverkehrs geschützt ist:

• 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 eine Konfigurationsverlaufsquelle sein.

Anforderung 1.2.3

Installieren Sie Umkreisfirewalls zwischen allen Drahtlosnetzwerken und der Datenumgebung des Kartenhalters, und konfigurieren Sie diese Firewalls so, dass nur autorisierter Datenverkehr zwischen der drahtlosen Umgebung und der Kartenhalterdatenumgebung verweigert oder zugelassen wird, wenn Datenverkehr für geschäftliche Zwecke erforderlich ist.

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. Bewahren Sie die Isolation auf, indem Sie die Zuordnung öffentlicher IPs zu Clusterknoten verhindern und NSG-Regeln auf die Cluster-Subnetze anwenden, um sicherzustellen, dass der Internetdatenverkehr blockiert ist. 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 verwendet wird, um systemeigene Kubernetes-Aufgaben auszuführen, z. B. den Status des Clusters und der Konfiguration beizubehalten. 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 (AKS)-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

Überprüfen Sie die folgenden bewährten Methoden für die Implementierung einer DMZ:

• Konfigurieren Sie keine öffentlichen IP-Adressen auf den Knotenpoolknoten.
• Verwenden Sie Azure-Richtlinie, um sicherzustellen, dass Kubernetes kein öffentliches Lastenausgleichsmodul verfügbar macht. Der Datenverkehr innerhalb des Clusters muss über interne Lastenausgleichsmodule geleitet werden.
• Machen Sie interne Load-Balancer nur für das Azure Application Gateway für Container verfügbar, das mit WAF integriert ist.
• Für alle Netzwerksteuerungen sollten Einschränkungen für Quelle, Ziel, Port und Protokoll angegeben werden (falls zutreffend).
• Machen Sie den API-Server nicht für das Internet verfügbar. Wenn Sie den Cluster im privaten Modus ausführen, wird der Endpunkt nicht verfügbar gemacht und die Kommunikation zwischen den Knotenpools und dem API-Server erfolgt über ein privates Netzwerk.

Sie können ein Umkreisnetzwerk implementieren, um AKS-Cluster zu schützen. Weitere Informationen 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 vom Subnetz akzeptiert wird, das über das Azure-Anwendungsgateway für Container verfügt, die in WAF integriert sind. 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

Lassen Sie nicht autorisierten ausgehenden Datenverkehr aus der Datenumgebung des Kartenhalters in das Internet zu.

Ihre Zuständigkeiten

Sie können nicht autorisierte ausgehenden Datenverkehr mit den folgenden bewährten Methoden blockieren:

• 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 nicht autorisierte Parteien weiter.

Ihre Zuständigkeiten

Um diese Anforderung zu erfüllen, ist ein öffentlicher AKS-Cluster keine Option. 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. Wir empfehlen, dieses Feature explizit zu deaktivieren, indem sie enablePrivateClusterPublicFQDN zu false umstellen, um die Offenlegung der privaten IP-Adresse Ihrer Kontrollebene zu verhindern. Erwägen Sie das Verwenden von Azure Policy, um die Verwendung privater Cluster ohne öffentliche DNS-Einträge zu erzwingen.

Verwenden Sie außerdem eine private DNS-Zone für das Routing zwischen dem Subnetz, das Azure-Anwendungsgateway für Container enthält, die mit WAF integriert sind, und dem Subnetz, das über den internen Lastenausgleich verfügt. Stellen Sie sicher, dass HTTP-Antworten in den Headern oder im Text keine Informationen zu privaten IP-Adressen enthalten. Stellen Sie sicher, dass alle Protokolle, die IP- und DNS-Einträge enthalten könnten, nicht außerhalb der betrieblichen Anforderungen offengelegt 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 wie Kubectl aus einer separaten 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: Verwenden Sie keine vom Anbieter bereitgestellten Standardwerte für Systemwörter und andere Sicherheitsparameter

Ihre Zuständigkeiten

Verwenden Sie keine vom Anbieter bereitgestellten Standardwerte für Systempasswörter und andere Sicherheitsparameter

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. Berücksichtigen Sie die folgenden bewährten Methoden:

• 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.
• Generieren oder bereitstellen Sie keinen SSH-Schlüsselzugriff auf Knoten für Administratorbenutzer. 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

Ändern Sie bei drahtlosen Umgebungen, die mit der Kartenhalterdatenumgebung verbunden sind oder Kartenhalterdaten übertragen werden, alle Standardeinstellungen für drahtlosanbieter bei der Installation, einschließlich, aber nicht beschränkt auf: Standardmäßige drahtlose Verschlü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. Weitere Informationen finden Sie in den Anleitungen des offiziellen PCI DSS 4.0.1-Standards.

Anforderung 2.2

Entwickeln Sie Konfigurationsstandards für alle Systemkomponenten.

Ihre Zuständigkeiten

Implementieren Sie die Empfehlungen der Microsoft-Benchmark für Cloudsicherheit. Es bietet eine einzige, konsolidierte Ansicht von Azure-Sicherheitsempfehlungen, die Branchenframeworks wie CIS, NIST und PCI DSS 4.0.1 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 im 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 ist die Verschlüsselung in der Standard-TLS-Richtlinie für Azure Application Gateway for Containers. Ü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

Das Anwendungsgateway für Container verfügt über ein integriertes WAF und verhandelt den TLS-Handshake für die an seinen öffentlichen Endpunkt gesendete Anforderung, wodurch nur sichere Chiffren zulässig sind. 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 durch. 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.

Wenn eine Arbeitsauslastung in Ihrem Cluster nicht an die Organisationsrichtlinie für Sicherheitscomplianceprofile oder andere Steuerelemente (z. B. Grenzwerte und Kontingente) halten kann, stellen Sie sicher, dass die Ausnahme dokumentiert ist. 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 verfügbar.

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. Mit der sorgfältigen Kategorisierung können Sie Ressourcen abfragen, einen Bestand behalten, 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 von Objekten auswählen und inventarisieren.

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 Architekturauswahl hat erhebliche Kostenauswirkungen 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.