Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die in dieser Reihe bereitgestellten Anleitungen enthalten bewährte Prinzipien in allen Designentscheidungen. In diesem Artikel werden die betreffenden Optionen zusammengefasst.
Mit diesem Artikel wird diese Reihe beendet. Die Einführung finden Sie hier.
in Kürze verfügbar: Der Azure Kubernetes Service (AKS) Basiscluster für regulierte Workloads wird als Referenzimplementierung für PCI DSS 4.0.1 derzeit aktualisiert und wird in Kürze verfügbar sein. Diese Implementierung veranschaulicht eine regulierte Infrastruktur, die die Verwendung verschiedener Netzwerk- und Sicherheitskontrollen innerhalb Ihres CDE veranschaulicht. Dies umfasst sowohl native Netzwerksteuerungen von Azure als auch native Steuerungen von Kubernetes. Sie enthält auch eine Anwendung, um die Interaktionen zwischen der Umgebung und einer Beispielarbeitsauslastung zu veranschaulichen. In diesem Artikel liegt der Schwerpunkt auf der Infrastruktur. Die Stichprobe wird nicht auf einen tatsächlichen PCI-DSS 4.0.1-Workload hinweisen.
Well-Architected Framework
Beim Microsoft Azure Well-Architected Framework handelt es sich um eine Reihe von Leitsätzen, die für die Beurteilung einer Lösung über die Qualitätssäulen der Architekturexzellenz verwendet werden können:
PCI DSS 4.0.1-Workloads erfordern die Rigorosität einer gut konzipierten Lösung. Obwohl die Ausrichtung der Infrastruktur an PCI-Anforderungen von entscheidender Bedeutung ist, endet die Konformität nicht bei der Hostinginfrastruktur. Ohne Berücksichtigung der Qualitätspfeiler, insbesondere der Sicherheit, kann dadurch die Konformität gefährdet werden. Gut strukturierte Lösungen kombinieren sowohl die Infrastruktur- als auch die Workloadperspektive, um die hohen Anforderungen zu erfüllen, die zum Erreichen konformer Ergebnisse erforderlich ist. PCI DSS 4.0.1 führt neue Anforderungen für kontinuierliche Compliance, risikobasierte Bereichsdefinitionen, erweiterte Überwachung und sichere Softwareentwicklung ein, die alle in dieser Anleitung behandelt werden.
Zu den wichtigsten Verbesserungen in PCI DSS 4.0.1, die für Cloud- und Containerumgebungen relevant sind, gehören:
- Angepasster Ansatz: Flexibilität zur Erfüllung von Sicherheitszielen durch alternative Steuerelemente, die für cloudeigene Architekturen geeignet sind.
- Erweiterte Authentifizierung: Verstärkte mehrstufige Authentifizierungsanforderungen für den gesamten Zugriff auf die Kartenhalterdatenumgebung.
- Kontinuierliche Überprüfung: Fortlaufende Überwachung und Validierung von Sicherheitskontrollen anstelle von Punkt-in-Time-Bewertungen.
- Automatisierte Sicherheit: Integration von Sicherheit in DevSecOps-Pipelines mit automatisierter Sicherheitsrisikoüberprüfung und Sicherheitstests.
- Containersicherheit: Spezifische Anleitungen für containerisierte Workloads und kurzlebige Infrastruktur.
- Null-Vertrauensgrundsätze: Betonung auf überprüfungsbasierte Ansätze und den geringsten Berechtigungszugriff.
Zuverlässigkeit
Die Zuverlässigkeit regulierter Umgebungen muss vorhersagbar sein, damit sie zu Überwachungszwecken konsistent erklärt werden kann. Befolgen Sie die grundlegenden Anleitungen in der Beschreibung der Zuverlässigkeitsprinzipien. In den folgenden Abschnitten werden bewährte Methoden für Zuverlässigkeit für eine regulierte Umgebung zusammengefasst.
Wiederherstellungsziele und Notfallwiederherstellung
Aufgrund der sensiblen Natur der Daten, die in regulierten Workloads verarbeitet werden, müssen unbedingt Wiederherstellungsziele und Recovery Point Objectives (RPOs) definiert werden. Was ist akzeptabler Verlust von CHD? Für Wiederherstellungsmaßnahmen in der CDE gelten ebenfalls Anforderungen des Standards. Gehen Sie davon aus, dass Fehler auftreten, und sorgen Sie dafür, dass ein klarer Wiederherstellungsplan für solche Fehler vorhanden ist, der die jeweiligen Rollen, Zuständigkeiten und Datenzugriffsberechtigungen berücksichtigt. Probleme mit Livewebsites sind keine Rechtfertigung für eine Abweichung von Vorschriften. Dies ist besonders wichtig in einer umfassenden Notfallwiederherstellungssituation. Sorgen Sie dafür, dass eine klare Dokumentation für die Notfallwiederherstellung vorhanden ist, die die Anforderungen erfüllt und unerwartete Zugriffe auf CDE oder CHD minimiert. Überprüfen Sie nach der Wiederherstellung immer die Schritte des Wiederherstellungsprozesses, um sicherzustellen, dass kein unerwarteter Zugriff vorgekommen ist. Dokumentieren Sie geschäftliche Begründungen für diese Vorkommen.
Wiederherstellung
Durch Hinzufügen von Resilienz- und Wiederherstellungsstrategien zu Ihrer Architektur kann verhindert werden, dass Ad-hoc-Zugriffe auf die CDE nötig werden. Das System sollte sich beim definierten RPO selbst wiederherstellen können, ohne dass ein direkter menschlicher Eingriff erforderlich ist. Auf diese Weise können Sie eine unnötige Offenlegung von Karteninhaberdaten vermeiden, selbst für befugte Personen mit Notfallzugriff. Der Wiederherstellungsprozess muss überprüfbar sein.
Berücksichtigung von Sicherheitsrisiken
Überprüfen Sie Sicherheitsrisiken, da sie ursächlich für Workloaddowntime und Datenverluste sein können. Investitionen in die Sicherheit wirken sich auch auf die Zuverlässigkeit der Workload aus.
Betriebsprozesse
Die Zuverlässigkeit gilt auch für alle Betriebsprozesse in und neben der CDE. Klar definierte, automatisierte und getestete Prozesse für Aufgaben wie Imageerstellung und Jumpboxverwaltung tragen zu einer gut strukturierten Lösung bei.
Sicherheit
Befolgen Sie die grundlegenden Anleitungen unter Prinzipien für den Sicherheitsentwurf. In den folgenden Abschnitten werden bewährte Sicherheitsmethoden für eine regulierte Umgebung zusammengefasst.
Verwaltung
Die Governanceimplementierung wird durch die Complianceanforderungen in PCI DSS 4.0.1 gesteuert. Dies wirkt sich auf die technischen Steuerelemente für die Aufrechterhaltung der Segmentierung, den Zugriff auf Ressourcen, die Erkennung von Sicherheitsrisiken und vor allem den Schutz von Kundendaten aus. PCI DSS 4.0.1 betont gemeinsame Verantwortung, kontinuierliche Überwachung und die Verwendung automatisierter Tools für die Bestands- und Konfigurationsverwaltung in Cloud- und Containerumgebungen.
Kontinuierliche Complianceüberwachung: Im Gegensatz zum regelmäßigen Bewertungsansatz früherer Versionen erfordert PCI DSS 4.0.1 eine fortlaufende Überprüfung der Sicherheitskontrollen. Dies entspricht gut den cloudeigenen Überwachungsfunktionen wie Azure Monitor, Microsoft Defender für Cloud und automatisierte Richtlinienerzwingung über Azure-Richtlinie.
Risikobasierte Bereichsdefinition: Der Standard ermöglicht jetzt eine dynamischere Bereichsdefinition basierend auf tatsächlichen Datenflüssen und Risikobewertungen, die besonders für containerisierte Workloads relevant sind, bei denen Komponenten möglicherweise kurzlebig und dynamisch orchestriert werden.
Strategie der Unternehmenssegmentierung
Um eine vollständige Isolation aufrechtzuerhalten, wird die Bereitstellung der regulierten Infrastruktur in einem eigenständigen Abonnement empfohlen. Wenn Sie über mehrere Abonnements verfügen, die für die Compliance erforderlich sind, sollten Sie sie in einer Verwaltungsgruppenhierarchie gruppieren, die die relevanten Azure-Richtlinien in Ihren in-Scope-Abonnements einheitlich anwendet. Wenden Sie die entsprechenden Azure-Richtlinien im Abonnement auf Abonnementebene an, um die weitgehenden Richtlinien zu erfassen, die für alle Cluster in der Datenumgebung des Karteninhabers (Cardholder Data Environment, CDE) gelten sollten. Wenden Sie die entsprechenden Azure-Richtlinien auf Ressourcengruppenebene an, um Richtlinien zu erfassen, die für eine bestimmte Clusterinstanz gelten. Diese Richtlinien bilden die zentralen Leitlinien einer Zielzone.
Isolieren Sie die PCI-Workload (im Bereich) in Bezug auf Vorgänge und Konnektivität von anderen Workloads (außerhalb des Bereichs). Sie können eine Isolation erstellen, indem Sie separate Cluster bereitstellen oder Segmentierungsstrategien verwenden, um die Trennung aufrechtzuerhalten. Die Cluster können beispielsweise separate Knotenpools verwenden, sodass Workloads niemals einen virtuellen Knotencomputer gemeinsam nutzen.
Durchsetzung von Richtlinien
Erzwingen Sie Sicherheitskontrollen, indem Sie Azure-Richtlinien aktivieren. In dieser regulierten Architektur können Sie beispielsweise eine Fehlkonfiguration der Datenumgebung des Karteninhabers verhindern. Sie können eine Azure-Richtlinie anwenden, die keine Zuteilung von öffentlichen IP-Adressen für VM-Knoten zulässt. Solche Zuteilungen werden erkannt und gemeldet oder blockiert.
Informationen zu Richtlinien, die Sie für AKS aktivieren können, finden Sie in den integrierten Azure-Richtliniendefinitionen für Azure Kubernetes Service (AKS).
Azure umfasst mehrere integrierte Richtlinien für die meisten Dienste. Überprüfen Sie die integrierten Azure-Richtliniendefinitionen , und wenden Sie sie entsprechend an.
Überwachung der Konformität
Die Konformität muss systematisch überwacht und verwaltet werden. Es werden regelmäßige Konformitätsnachweise durchgeführt. Wenn Sie wissen, ob Ihre Cloudressourcen konform sind, können Sie sich auf Nachweise und Überwachung vorbereiten.
Nutzen Sie das Dashboard für die Einhaltung gesetzlicher Bestimmungen in Microsoft Defender für Cloud. Durch die kontinuierliche Überwachung des Dashboards können Sie den Konformitätsstatus Ihrer Workload nachverfolgen.
Netzwerksicherheit
In einer Hub-Spoke-Topologie ermöglicht die Verwendung separater virtueller Netzwerke für die einzelnen Entitäten eine grundlegende Segmentierung des Netzwerkbedarfs. Jedes Netzwerk wird weiter in Subnetze segmentiert.
Der AKS-Cluster bildet den Kern der CDE. Es sollte nicht über öffentliche IP-Adressen zugänglich sein, und die Konnektivität muss abgesichert werden. Typische ein- und ausgehende CDE-Datenflüsse können wie folgt kategorisiert werden:
- Eingehender Datenverkehr an den Cluster.
- Ausgehender Datenverkehr aus dem Cluster.
- Clusterinterner Datenverkehr zwischen Pods.
Um die Anforderungen einer regulierten Umgebung zu erfüllen, wird der Cluster als privater Cluster bereitgestellt. In diesem Modus wird der Datenverkehr zum und aus dem öffentlichen Internet eingeschränkt. Selbst die Kommunikation mit dem von AKS verwalteten Kubernetes-API-Server ist privat. Die Sicherheit wird mit strengen Netzwerkkontrollen und IP-Firewallregeln weiter verbessert:
- Netzwerksicherheitsgruppen (NSGs) ermöglichen eine sichere Kommunikation zwischen Ressourcen in einem Netzwerk.
- Azure Firewall ermöglicht die Filterung des Datenverkehrs zwischen Cloudressourcen, dem Internet und lokalen Umgebungen.
- Die Integration von Azure Application Gateway in Azure Web Application Framework ermöglicht die Filterung des gesamten eingehenden Datenverkehrs aus dem Internet, der von Azure Application Gateway empfangen wird.
- Kubernetes
NetworkPolicyermöglicht es, nur bestimmte Pfade zwischen den Pods im Cluster zuzulassen. - Azure Private Link zum Herstellen einer Verbindung mit anderen Azure-Plattform as a Service(PaaS)-Diensten, z. B. Azure Key Vault und Azure Container Registry, für operative Aufgaben.
Vorhandene Überwachungsprozesse stellen sicher, dass der Datenverkehr erwartungsgemäß fließt sowie Anomalien erkannt und gemeldet werden.
Weitere Informationen zur Netzwerksicherheit finden Sie unter "Netzwerksegmentierung".
Datensicherheit
PCI DSS 4.0.1 erfordert, dass alle Kartenhalterdaten (CHD) niemals klar sind, ob während der Übertragung oder im Speicher.
Da sich diese Architektur und die Implementierung auf die Infrastruktur und nicht auf die Workload konzentrieren, wird die Datenverwaltung nicht veranschaulicht. In den folgenden Abschnitten werden einige gut durchdachte Empfehlungen beschrieben.
Daten im Ruhezustand
Die Daten müssen mit standardisierten Verschlüsselungsalgorithmen verschlüsselt werden.
- Speichern Sie keine Daten in der CDE.
- Verschlüsseln Sie Daten außerhalb der Speicherebene.
- Schreiben Sie nur verschlüsselte Daten auf das Speichermedium.
- Speichern Sie die Schlüssel nicht auf der Speicherebene.
Alle Daten in Azure Storage werden mit sicheren Kryptografieverfahren ver- und entschlüsselt. Hierbei werden selbstverwaltete Verschlüsselungsschlüssel bevorzugt.
Wenn Sie Daten vorübergehend speichern müssen, gelten die gleichen Überlegungen für diese Daten. Es wird dringend empfohlen, die hostbasierte Verschlüsselung von AKS zu aktivieren. Sie können die Verschlüsselung temporärer Daten mit integrierten Azure-Richtlinien erzwingen.
Informieren Sie sich bei der Auswahl einer Speichertechnologie über die Features für die Datenaufbewahrung. Stellen Sie sicher, dass alle Daten sicher entfernt werden, wenn die konfigurierte Zeit abläuft.
Der Standard erfordert außerdem, dass vertrauliche Authentifizierungsdaten (SAD) nicht gespeichert werden. Stellen Sie sicher, dass die Daten nicht in Protokollen, Dateinamen, Cache und anderen Daten verfügbar gemacht werden.
Daten im Transit
Die gesamte Kommunikation mit Entitäten, die mit der CDE interagieren, muss über verschlüsselte Kanäle erfolgen. PCI DSS 4.0.1 stärkt Verschlüsselungsanforderungen mit aktualisierten Verschlüsselungssammlungen und Protokollstandards.
- In die CDE darf nur HTTPS-Datenverkehr fließen. In dieser Architektur verweigert Azure Application Gateway den gesamten Datenverkehr über Port 80.
- Vorzugsweise sollten Sie Daten nicht außerhalb der CDE verschlüsseln und entschlüsseln. Andernfalls sollten Sie die betreffende Entität als Teil der CDE betrachten.
- Sorgen Sie in der CDE mit mTLS für eine sichere Kommunikation zwischen Pods. Sie können zu diesem Zweck ein Dienstmesh implementieren.
- Lassen Sie nur sichere Verschlüsselungsverfahren sowie TLS 1.2 oder höher zu. PCI DSS 4.0.1 bietet aktualisierte Anleitungen zu akzeptablen Verschlüsselungsprotokollen und Verschlüsselungssammlungen.
- PCI DSS 4.0.1 erfordert ein strengeres Schlüssellebenszyklus-Management, einschließlich der automatisierten Schlüsselrotation und, wo zutreffend, der Integration in Hardware-Sicherheitsmodule (HSM).
Identität
Befolgen Sie beim Entwurf von Zugriffsrichtlinien die folgenden Sicherheitsprinzipien:
- Beginnen Sie mit Zero-Trust-Richtlinien. Machen Sie bei Bedarf Ausnahmen.
- Gewähren Sie die geringsten Berechtigungen – nur genug, um eine Aufgabe auszuführen.
- Minimieren Sie den ständigen Zugriff.
PCI DSS 4.0.1 stärkt die Authentifizierungsanforderungen erheblich und schreibt eine Mehrfaktor-Authentifizierung (MFA) für den gesamten Zugriff auf die Kartenhalterdatenumgebung vor. Dies schließt sowohl den administrativen als auch den gesamten Nicht-Konsolenzugriff ein.
Die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes verwaltet die Berechtigungen für die Kubernetes-API. AKS unterstützt diese Kubernetes-Rollen. AKS ist vollständig mit Microsoft Entra ID integriert. Sie können den Rollen Microsoft Entra-Identitäten zuweisen und auch andere Funktionen nutzen.
Zero-Trust-Zugriff
Kubernetes-RBAC, Azure-RBAC und Azure-Dienste implementieren standardmäßig die Einstellung Alles verweigern. Setzen Sie diese Einstellung mit Vorsicht außer Kraft, und lassen Sie einen Zugriff nur auf Entitäten zu, auf die ein Zugriff notwendig ist. Ein weiterer Bereich für die Implementierung von Zero-Trust besteht darin, den SSH-Zugriff auf die Clusterknoten zu deaktivieren.
Geringste Berechtigungen
Sie können verwaltete Identitäten für Azure-Ressourcen und -Pods verwenden und diese auf die erwarteten Aufgaben beschränken. Azure Application Gateway muss beispielsweise über Berechtigungen zum Abrufen von Geheimnissen (TLS-Zertifikaten) aus Azure Key Vault verfügen, darf aber keine Berechtigungen zum Ändern von Geheimnissen haben.
Minimieren des ständigen Zugriffs
Minimieren Sie den ständigen Zugriff durch Just-in-Time-Gruppenmitgliedschaft in Microsoft Entra. Stärken Sie die Kontrolle mit Richtlinien für bedingten Zugriff in Microsoft Entra ID. Diese Option unterstützt viele Anwendungsfälle, z. B. die mehrstufige Authentifizierung, die Einschränkung der Authentifizierung auf Geräte, die vom Microsoft Entra-Mandanten verwaltet werden, oder die Blockierung atypischer Anmeldeversuche.
Verwaltung von Geheimnissen
Speichern Sie Geheimnisse, Zertifikate, Schlüssel und Kennwörter außerhalb der CDE. Sie können die nativen Kubernetes-Geheimnisobjekte oder einen verwalteten Schlüsselspeicher wie Azure Key Vault verwenden. Die Verwendung eines verwalteten Speichers vereinfacht Verwaltungsaufgaben für Geheimnisse, z. B. Schlüsselrotation und Zertifikatsverlängerung.
Achten Sie darauf, dass für den Zugriff auf den Schlüsselspeicher eine Kombination von Netzwerkkontrollen und Zugriffssteuerungen verfügbar ist. Wenn verwaltete Identitäten aktiviert sind, muss sich der Cluster selbst bei Key Vault authentifizieren, um Zugriff zu erhalten. Außerdem darf die Konnektivität zum Schlüsselspeicher nicht über das öffentliche Internet erfolgen. Verwenden Sie ein privates Netzwerk, z. B. Private Link.
Kostenoptimierung
Befolgen Sie die grundlegenden Anleitungen unter Grundsätze der Kostenoptimierung.
Durch die Konformitätsanforderungen und strengen Sicherheitskontrollen entsteht ein Zielkonflikt mit den Kosten. Es wird empfohlen, erste Schätzungen mithilfe des Preisrechners einzurichten.
Das folgende Diagramm stellt eine allgemeine Darstellung der Kostenwirkungen der wichtigsten Ressourcen dar, die von dieser Architektur verwendet werden:

Die Haupttreiber sind die Skalierungsgruppen für virtuelle Computer, die die Knotenpools bilden, und Azure Firewall. Ein weiterer Kostenaspekt ist Log Analytics. Abhängig vom jeweils ausgewählten Plan fallen auch höhere Kosten für Microsoft Defender für Cloud an.
Sie müssen sich im Klaren sein, wie sich der Preis eines Diensts zusammensetzt. Azure protokolliert die gemessene Nutzung. Das folgende Diagramm enthält eine Aufschlüsselung der Azure Firewall für diese Architektur:

Die Kosten für einige Ressourcen, z. B. Azure Firewall, können auf mehrere Geschäftseinheiten oder Anwendungen verteilt werden. Eine andere Möglichkeit zum Optimieren der Kosten kann das Hosten eines mehrinstanzenfähigen Clusters in einer Organisation sein, um die Dichte durch Workloaddiversität zu maximieren. Diese Vorgehensweise wird für regulierte Workloads allerdings nicht empfohlen. Priorisieren Sie Konformität und Segmentierung immer gegenüber Kostenvorteilen.
Um innerhalb der Budgeteinschränkungen zu bleiben, können Sie die Kosten steuern, indem Sie die Azure Application Gateway-Infrastruktur anpassen, die Anzahl der Instanzen für die automatische Skalierung festlegen und die Protokollausgabe reduzieren, solange sie den von PCI DSS 4.0.1 erforderlichen Überwachungspfad noch erfüllen. Bewerten Sie die betreffenden Optionen immer gegenüber Zielkonflikten mit anderen Aspekten des Entwurfs, die eine Erfüllung der SLA ermöglichen, etwa, ob weiterhin eine geeignete Skalierung möglich ist, um Spitzen im Datenverkehr zu bewältigen.
Wenden Sie bei der Erstellung von Azure-Ressourcengruppen Tags an, damit diese in Hinblick auf die Kosten nachverfolgt werden können. Verwenden Sie Kostenverwaltungstools wie Azure Advisor und Microsoft Cost Management, um Kosten nachzuverfolgen und zu analysieren.
Erwägen Sie die Aktivierung AKS-Kostenanalyse für die granulare Kostenzuordnung von Clusterinfrastrukturen durch Kubernetes spezifische Konstrukte.
Operative Exzellenz
Befolgen Sie die grundlegenden Leitlinien, die in den Grundsätzen der operativen Exzellenz bereitgestellt werden. In den folgenden Abschnitten werden bewährte Methoden für operative Exzellenz für eine regulierte Umgebung zusammengefasst.
Trennung von Rollen
Das Durchsetzen einer klaren Aufgabentrennung ist für regulierte Umgebungen von entscheidender Bedeutung. Sorgen Sie dafür, dass Rollen und Zuständigkeiten basierend auf den Anforderungen der Workload und der Interaktion mit der CDE definiert werden. Beispielsweise kann u. U. eine Rolle als Infrastrukturoperator oder Site Reliability Engineer (SRE) für Vorgänge im Zusammenhang mit dem Cluster und abhängigen Diensten erforderlich sein. Die Rolle ist für die Aufrechterhaltung der Sicherheit, Isolation, Bereitstellung und Beobachtbarkeit verantwortlich. Formalisieren Sie die betreffenden Definitionen, und entscheiden Sie, welche Berechtigungen diese Rollen benötigen. SREs verfügen beispielsweise über hohe Clusterzugriffsrechte, benötigen aber lediglich Lesezugriff auf Workloadnamespaces.
Workloadisolation
PCI DSS 4.0.1 erfordert die Isolierung der PCI-Workload von anderen Workloads im Hinblick auf Vorgänge. In dieser Implementierung sind Workloads im Bereich und Workloads außerhalb des Bereichs in zwei separaten Benutzerknotenpools segmentiert. Anwendungsentwickler für Workloads im Bereich und Entwickler für Workloads außerhalb des Bereichs können u. U. über unterschiedliche Berechtigungen verfügen. Außerdem gibt es getrennte Qualitätsgates. Beispielsweise muss im Bereichscode für Konformität und deren Nachweis gesorgt werden, während dies für Code außerhalb des Bereichs nicht erforderlich ist. Außerdem müssen separate Buildpipelines und Releaseverwaltungsprozesse vorhanden sein.
PCI DSS 4.0.1 führt umfassende Anforderungen für die sichere Softwareentwicklung ein, darunter:
- Automatisierte Sicherheitstests, die in CI/CD-Pipelines integriert sind.
- Statische und dynamische Anwendungssicherheitstests (SAST/DAST).
- Schwachstellenprüfung von Container-Images vor der Bereitstellung.
- Abhängigkeitsüberprüfung für Komponenten von Drittanbietern.
- Codeüberprüfungsprozesse mit Sicherheitsfokus.
- Sicheres Codierungstraining für Entwicklungsteams.
Betriebsmetadaten
Anforderung 12 des PCI DSS 4.0.1-Standards erfordert, dass Sie Informationen zum Workloadbestand und zur Dokumentation zum Personalzugriff verwalten. Es wird dringend empfohlen, Azure-Tags zu verwenden, da Sie Umgebungsinformationen Azure-Ressourcen, Ressourcengruppen und Abonnements zuordnen können.
Pflegen Sie Informationen zu genehmigten Lösungen, die Teil der Infrastruktur und Workload sind. Dazu gehört eine Liste von VM-Images, Datenbanken und Drittanbieterlösungen Ihrer Wahl, die Sie in die CDE übernehmen. Sie können diesen Prozess sogar automatisieren, indem Sie einen Dienstkatalog erstellen. Er ermöglicht eine Self-Service-Bereitstellung, indem die betreffenden Lösungen in einer bestimmten Konfiguration verwendet werden, die dem laufenden Plattformbetrieb gerecht wird.
Observierbarkeit
Um die Einhaltung von Anforderung 10 zu erfüllen, ist ein Einblick in die CDE wichtig. Aktivitätsprotokolle enthalten Informationen zu Vorgängen im Zusammenhang mit der Konto- und Geheimnisverwaltung, der Verwaltung von Diagnoseeinstellungen, der Serververwaltung und anderen Ressourcenzugriffsvorgängen. Alle Protokolle werden mit Datum, Uhrzeit, Identität und anderen ausführlichen Informationen erstellt. Speichern Sie Protokolle bis zu einem Jahr, indem Sie Richtlinien für die Datenaufbewahrung und -archivierung in Azure Monitor-Protokollen konfigurieren.
Stellen Sie sicher, dass nur Rollen auf Protokolle zugreifen können, die die Protokolle wirklich benötigen. Log Analytics und Microsoft Sentinel unterstützen verschiedene rollenbasierte Zugriffssteuerungen zum Verwalten des Zugriffs auf Überwachungsprotokolle.
Reaktion und Korrektur
Die Azure-Überwachungsdienste Azure Monitor und Microsoft Defender for Cloud können Benachrichtigungen oder Warnungen generieren, wenn sie anormale Aktivitäten erkennen. Diese Warnungen enthalten Kontextinformationen wie Schweregrad, Status und Aktivitätszeit. Für generierte Warnungen muss eine Korrekturstrategie vorhanden sein, und der Fortschritt muss überprüft werden. Es wird empfohlen, Daten in einer SIEM-Lösung (Security Information and Event Management) zu zentralisieren, da die Integration von Daten einen umfangreichen Warnungskontext bereitstellen kann.
In der Ansicht Sicherheitswarnungen in Microsoft Defender für Cloud haben Sie Zugriff auf alle Warnungen, die Microsoft Defender für Cloud bei Ihren Ressourcen erkennt. Verwenden Sie einen Selektierungsprozess, um das Problem zu beheben. Arbeiten Sie mit Ihrem Sicherheitsteam zusammen, um zu verstehen, wie relevante Warnungen den Workloadbesitzern zur Verfügung gestellt werden.
Leistungseffizienz
Befolgen Sie die grundlegenden Anleitungen in den Grundsätzen der Leistungseffizienz. In den folgenden Abschnitten werden bewährte Methoden zur Leistungseffizienz für eine regulierte Umgebung zusammengefasst.
Skalierung
Durch Beobachtung, wie sich die Umgebung an veränderliche Anforderungen anpasst, kann das erwartete Laufzeitverhalten der Umgebung bei hoher Auslastung eingeschätzt werden. Die automatische Skalierung von Ressourcen in der Workload minimiert die Benutzerinteraktion in der CDE. Ein zusätzlicher Sicherheitsvorteil ist die stets kleinere Angriffsfläche. Sie können den Vorteil maximieren, indem Sie Ressourcen nutzen, die eine Scale-to-Zero-Strategie unterstützen. AKS unterstützt beispielsweise das Herunterskalieren der Benutzerknotenpools auf 0. Weitere Informationen finden Sie unter Skalieren von User-Knotenpools auf 0 (null).
Partitionierung
Die Partitionierung ist ein wichtiger Faktor für die Leistungseffizienz in regulierten Workloads. Diskrete Komponenten ermöglichen eine klare Definition der Verantwortung und sind für präzise Steuerungen hilfreich, z. B. Netzwerkrichtlinien. Ähnlich wie bei jeder Segmentierungsstrategie isoliert die Partitionierung Komponenten und steuert den Einfluss des Wirkradius auf unerwartete Fehler oder die Kompromittierung von Systemen.
Shared Nothing-Architektur
Die Shared Nothing-Architektur soll Konflikte zwischen kollokierten Workloads beseitigen. Außerdem ist dies eine Strategie zum Beseitigen von Single Points of Failure. In einer regulierten Umgebung müssen Komponenten durch logische oder physische Grenzen isoliert werden. Dies entspricht der Shared Nothing-Architektur, was zu Skalierbarkeitsvorteilen führt. Es ermöglicht die Zielbestimmung relevanter Sicherheitskontrollen und engere Überwachungsfunktionen der verschiedenen Komponenten.
Einfache Workloads
Die Komplexität von Workloads ist schwer zu dokumentieren und zu überwachen. Bemühen Sie sich aufgrund der Leistungsvorteile und der leichteren Überwachung gesetzlicher Anforderungen um Einfachheit. Überdenken Sie Optionen, die mehr Spielraum als nötig bieten, weil dadurch die Angriffsfläche vergrößert und das Potenzial für Missbrauch und Fehlkonfiguration erhöht wird.
Zusammenfügen des Gesamtbilds
Die Implementierung der PCI DSS 4.0.1-Compliance für Azure Kubernetes Service erfordert einen umfassenden Ansatz, der alle Aspekte des gut durchdachten Frameworks behandelt und gleichzeitig die spezifischen Anforderungen des Standards erfüllt. Diese Reihe bietet detaillierte Anleitungen für mehrere Domänen, von Netzwerksicherheit und Datenschutz bis hin zu Identitätsverwaltung und kontinuierlicher Überwachung.
Wichtige Erkenntnisse
Die Reise zur PCI DSS 4.0.1 Compliance auf AKS umfasst mehrere wichtige Überlegungen:
- Infrastruktur als Grundlage: Eine sichere, kompatible AKS-Infrastruktur ist unerlässlich, aber nicht ausreichend. Die Architektur muss die sicherheitstechnischen Kontrollen, Überwachungsfunktionen und operativen Prozesse unterstützen, die vom Standard benötigt werden.
- Kontinuierliche Compliance: Im Gegensatz zu früheren Versionen betont PCI DSS 4.0.1 eine kontinuierliche Validierung und Überwachung anstelle von Punkt-in-Time-Bewertungen. Dies erfordert automatisierte Tools, Echtzeitwarnungen und proaktive Sicherheitsmaßnahmen.
- Gemeinsame Verantwortung: Während Azure eine sichere Plattform bereitstellt, bleibt Ihre Organisation für die ordnungsgemäße Konfiguration und Aufrechterhaltung der Sicherheitskontrollen, die Implementierung geeigneter Zugriffsrichtlinien und die Sicherstellung der laufenden Compliance verantwortlich.
- Gut durchdachte Prinzipien: Sicherheit, Zuverlässigkeit, Kostenoptimierung, operative Exzellenz und Leistungseffizienz müssen alle zusammen betrachtet werden, um eine nachhaltige, kompatible Lösung zu schaffen.
Integrationspunkte
Die verschiedenen Komponenten, die in dieser Reihe diskutiert werden, arbeiten zusammen, um ein umfassendes Compliance-Framework zu schaffen:
- Die Netzwerksicherheit bietet die Grundlage zum Isolieren der Kartenhalterdatenumgebung.
- Der Datenschutz stellt sicher, dass CHD während des gesamten Lebenszyklus ordnungsgemäß verschlüsselt und verwaltet wird.
- Kryptografie und Schlüsselverwaltung ermöglichen sichere Speicherung und Übertragung vertraulicher Daten.
- Identity & Access Management mit erweiterten MFA-Steuerelementen, die auf die CDE zugreifen können.
- Schadsoftwareschutz schützt vor Bedrohungen, die die Umgebung gefährden könnten.
- Überwachung und Protokollierung bietet Einblicke in alle Aktivitäten innerhalb des CDE.
- Kontinuierliche Sicherheitsüberwachung ermöglicht die Erkennung und Reaktion auf Bedrohungen in Echtzeit.
- Sicherheitsrichtlinien richten das Governanceframework für die fortlaufende Compliance ein.
Nächste Schritte
Führen Sie die folgenden empfohlenen Schritte aus, um mit der Implementierung der PCI DSS 4.0.1 Compliance auf AKS zu beginnen:
Phase 1: Gründung und Planung (Wochen 1-4)
- Bewerten Sie den aktuellen Zustand: Bewerten Sie Ihre vorhandene AKS-Infrastruktur anhand der PCI DSS 4.0.1-Anforderungen.
- Bereich definieren: Identifizieren Sie eindeutig, welche Komponenten für die PCI DSS-Compliance im Gültigkeitsbereich sind.
- Überprüfen Sie den Implementierungsleitfaden: Untersuchen Sie die detaillierten Anleitungen in jedem Artikel dieser Reihe.
- Planen Sie Ihre Architektur: Entwerfen Sie Ihre Hub-Spoke-Netzwerktopologie und Sicherheitskontrollen.
- Governance einrichten: Definieren von Rollen, Zuständigkeiten und Genehmigungsprozessen.
Phase 2: Infrastrukturimplementierung (Wochen 5-12)
- Bereitstellen der Referenzarchitektur: Beginnen Sie mit der AKS-Basisarchitektur, und wenden Sie PCI DSS-Verbesserungen an.
- Implementieren der Netzwerksicherheit: Konfigurieren privater Cluster, Firewalls und Netzwerkrichtlinien.
- Einrichten der Identitätsverwaltung: Konfigurieren von Azure AD-Integrations- und MFA-Anforderungen.
- Bereitstellen der Überwachungsinfrastruktur: Einrichten von Azure Monitor, Log Analytics und Microsoft Defender für Cloud.
- Implementieren des Datenschutzes: Konfigurieren der Verschlüsselung im Ruhezustand und während der Übertragung.
Phase 3: Sicherheit und Compliance (Wochen 13-20)
- Konfigurieren von Sicherheitsrichtlinien: Anwenden von Azure-Richtlinien und Kubernetes-Richtlinien zur Einhaltung von Vorschriften.
- Implementieren der Schlüsselverwaltung: Einrichten von Azure Key Vault und kryptografischen Steuerelementen.
- Bereitstellen von Schadsoftwareschutz: Konfigurieren von Sicherheitsüberprüfungen und Bedrohungserkennung.
- Einrichten der Überwachung: Implementieren einer kontinuierlichen Sicherheitsüberwachung und -warnung.
- Testen sie Sicherheitskontrollen: Überprüfen Sie, ob alle Sicherheitsmaßnahmen ordnungsgemäß funktionieren.
Phase 4: Validierung und Wartung (Wochen 21-24)
- Durchführen von Sicherheitstests: Durchführen von Penetrationstests und Sicherheitsrisikobewertungen.
- Überprüfen der Compliance: Stellen Sie sicher, dass alle PCI DSS 4.0.1-Anforderungen erfüllt sind.
- Alles dokumentieren: Erstellen Sie umfassende Dokumentation für Überwachungszwecke.
- Mitarbeiter schulen: Stellen Sie sicher, dass alle Mitarbeiter ihre Rollen und Verantwortlichkeiten verstehen.
- Einrichten fortlaufender Prozesse: Implementieren von kontinuierlichen Überwachungs- und Wartungsverfahren.
Laufende Vorgänge
Nach der ersten Implementierung die Compliance aufrechterhalten durch:
- Regelmäßige Sicherheitsbewertungen: Führen Sie vierteljährliche Sicherheitsüberprüfungen und jährliche Compliancebewertungen durch.
- Kontinuierliche Überwachung: Überwachen Sie alle Sicherheitskontrollen und reagieren Sie umgehend auf Warnungen.
- Updateverwaltung: Halten Sie alle Systeme und Sicherheitskontrollen auf dem neuesten Stand.
- Reaktion auf Vorfälle: Verwalten und Testen von Verfahren zur Reaktion auf Vorfälle.
- Dokumentationswartung: Halten Sie alle Dokumentationen aktuell und barrierefrei.
Hier erhalten Sie Hilfe
Für zusätzliche Unterstützung bei der Implementierung der PCI DSS 4.0.1 Compliance auf AKS:
- Microsoft FastTrack: Wenden Sie sich an Microsoft FastTrack für Azure, um Anleitungen zur Implementierung zu erhalten.
- Microsoft-Partner: Arbeiten Sie mit zertifizierten Microsoft-Partnern zusammen, die sich auf Compliance spezialisiert haben.
- Professionelle Dienstleistungen: Ziehen Sie professionelle Dienste für komplexe Implementierungen in Betracht.
- Communityressourcen: Nutzen Sie die Azure- und Kubernetes-Communitys für bewährte Methoden.
Auf dem Laufenden bleiben
PCI DSS-Standards entwickeln sich im Laufe der Zeit weiter. Bleiben Sie über Updates und Änderungen informiert:
- Abonnieren Sie die PCI-SSC-Kommunikation: Folgen Sie dem PCI Security Standards Council für Updates.
- Überwachen von Azure-Updates: Bleiben Sie mit neuen Azure-Sicherheitsfeatures und -Funktionen auf dem laufenden.
- Treten Sie mit der Community in Kontakt: Nehmen Sie an Sicherheits- und Complianceforen teil.
- Regelmäßige Schulungen: Stellen Sie sicher, dass Ihr Team mit bewährten Sicherheitspraktiken auf dem Laufenden bleibt.
Verwandte Ressourcen
Diese Reihe bietet umfassende Anleitungen zur Implementierung der PCI DSS 4.0.1 Compliance auf AKS. Weitere Informationen:
Artikel der PCI DSS 4.0.1-Serie:
- Einführung in PCI DSS v4.0.1 auf AKS
- Netzwerksicherheit
- Datenschutz
- Kryptografie und Schlüsselverwaltung
- Identitäts- und Zugriffsverwaltung
- Erweiterte MFA-Implementierung
- Schutz vor Schadsoftware
- Überwachung und Protokollierung
- Kontinuierliche Sicherheitsüberwachung
- Sicherheitsrichtlinien
Azure-Dokumentation:
- Dokumentation zu Azure Kubernetes Service (AKS)
- Dokumentation zum Azure Security Center
- Azure Monitor-Dokumentation
- Azure-Richtliniendokumentation
Compliance-Ressourcen:
- Offizielle PCI DSS 4.0.1 Dokumentation
- Microsoft Azure-Complianceangebote
- Azure Architecture Center
- Azure Well-Architected Framework
Denken Sie daran, dass das Erreichen und Verwalten der PCI DSS 4.0.1-Compliance ein fortlaufender Prozess ist, der kontinuierliche Aufmerksamkeit auf Sicherheit, Überwachung und operative Exzellenz erfordert. Die Anleitung in dieser Reihe bietet eine Grundlage, aber Ihre spezifische Implementierung erfordert möglicherweise zusätzliche Überlegungen basierend auf Ihren individuellen Anforderungen und Ihrer Umgebung.
in Kürze verfügbar: Der Azure Kubernetes Service (AKS) Basiscluster für regulierte Workloads wird als Referenzimplementierung für PCI DSS 4.0.1 derzeit aktualisiert und wird in Kürze verfügbar sein. Diese Implementierung veranschaulicht eine regulierte Infrastruktur, die die Verwendung verschiedener Netzwerk- und Sicherheitskontrollen innerhalb Ihres CDE veranschaulicht. Dies umfasst sowohl native Netzwerksteuerungen von Azure als auch native Steuerungen von Kubernetes. Sie enthält auch eine Anwendung, um die Interaktionen zwischen der Umgebung und einer Beispielarbeitsauslastung zu veranschaulichen. In diesem Artikel liegt der Schwerpunkt auf der Infrastruktur. Die Stichprobe wird nicht auf einen tatsächlichen PCI-DSS 4.0.1-Workload hinweisen.