Schützen von Daten in einem regulierten AKS-Cluster für PCI-DSS 3.2.1 (Teil 4 von 9)

In diesem Artikel werden die Aspekte eines AKS-Clusters (Azure Kubernetes Service) beschrieben, in dem eine mit Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) konforme Workload ausgeführt wird.

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

Bei dieser Architektur und Implementierung liegt der Schwerpunkt nicht auf der Workload, sondern auf der Infrastruktur. In diesem Artikel werden die allgemeinen Aspekte und die bewährten Methoden beschrieben, die Ihnen das Treffen von Entwurfsentscheidungen erleichtern. Erfüllen Sie die Anforderungen des offiziellen PCI-DSS 3.2.1-Standards, und nutzen Sie diesen Artikel bei Bedarf als zusätzliche Informationsquelle.

Schützen von Karteninhaberdaten

Anforderung 3: Schützen der gespeicherten Daten von Karteninhabern

Ihre Zuständigkeiten

Anforderung 3.1

Minimieren Sie die Speicherung von Karteninhaberdaten, indem Sie Richtlinien, Verfahren und Prozesse zur Datenaufbewahrung und -entsorgung implementieren, die mindestens Folgendes für die Speicherung aller Karteninhaberdaten (Cardholder Data, CHD) umfassen:

• Einschränkung der Datenspeichermenge und der Aufbewahrungszeit auf Werte, die für gesetzliche, behördliche und geschäftliche Anforderungen erforderlich sind
• Prozesse zur sicheren Löschung von Daten, wenn diese nicht mehr benötigt werden
• Bestimmte Aufbewahrungsanforderungen für Karteninhaberdaten
• Ein vierteljährlicher Prozess zur Identifizierung und sicheren Löschung gespeicherter Karteninhaberdaten, die die definierte Aufbewahrungsdauer überschreiten

Ihre Zuständigkeiten

Speichern Sie den Status nicht im AKS-Cluster. Wenn Sie sich für die Speicherung der Karteninhaberdaten entscheiden, sollten Sie sich über die Optionen für die sichere Speicherung informieren. Zu den verfügbaren Optionen gehören Azure Storage für die Dateispeicherung oder Datenbanken, z. B. Azure SQL-Datenbank oder Azure Cosmos DB.

Halten Sie sich strikt an die Standardvorgaben zur Art der Karteninhaberdaten, die gespeichert werden können. Definieren Sie die Richtlinien zur Datenaufbewahrung basierend auf Ihren Geschäftsanforderungen und der Art des verwendeten Speichers. Hier sind einige wichtige Aspekte aufgeführt:

• Wie und wo werden die Daten gespeichert?
• Werden die Daten verschlüsselt gespeichert?
• Welche Länge hat der Aufbewahrungszeitraum?
• Welche Aktionen sind während des Aufbewahrungszeitraums zulässig?
• Wie löschen Sie die gespeicherten Daten, nachdem der Aufbewahrungszeitraum abgelaufen ist?

Legen Sie Governancerichtlinien fest, die sich auf die getroffene Auswahl beziehen. Diese Auswahl wird dann mithilfe der integrierten Azure-Richtlinien durchgesetzt. Beispielsweise können Sie die Volumetypen auf den Clusterpods einschränken oder Schreibvorgänge im Stammdateisystem verweigern.

Sehen Sie sich diese Liste mit Richtliniendefinitionen an, und wenden Sie sie bei Bedarf auf den Cluster an.

Unter Umständen müssen Sie Daten vorübergehend zwischenspeichern. Wir empfehlen Ihnen, die zwischengespeicherten Daten zu schützen, während diese in eine Speicherlösung verschoben werden. Erwägen Sie, in AKS das Feature für die hostbasierte Verschlüsselung zu aktivieren. Hierdurch werden die auf Knoten-VMs gespeicherten Daten verschlüsselt. Weitere Informationen finden Sie unter Hostbasierte Verschlüsselung in Azure Kubernetes Service (AKS). Aktivieren Sie außerdem eine integrierte Azure-Richtlinie, mit der die Verschlüsselung temporärer Datenträger und des Caches für Knotenpools erzwungen wird.

Informieren Sie sich bei der Auswahl einer Speichertechnologie über die Features für die Datenaufbewahrung. Bei Azure Blob Storage können Sie beispielsweise zeitbasierte Aufbewahrungsrichtlinien verwenden. Eine andere Möglichkeit ist die Implementierung einer benutzerdefinierten Lösung, bei der Daten gemäß den Aufbewahrungsrichtlinien gelöscht werden. Ein Beispiel hierfür ist die Verwaltung des Datenlebenszyklus (Data Lifecycle Management, DLM), bei der die Aktivitäten des Lebenszyklus von Daten verwaltet werden. Die Lösung wurde mit Diensten wie Azure Data Factory, Microsoft Entra ID und Azure Key Vault entwickelt.

Weitere Informationen finden Sie unter Verwalten des Datenlebenszyklus mit Azure Data Factory.

Anforderung 3.2

Speichern Sie keine vertraulichen Authentifizierungsdaten nach der Autorisierung (auch nicht verschlüsselt). Wenn vertrauliche Authentifizierungsdaten empfangen werden, sorgen Sie dafür, dass alle Daten nach Abschluss des Autorisierungsprozesses nicht mehr wiederhergestellt werden können.

Ihre Zuständigkeiten

(GILT FÜR: Anforderung 3.2.1, Anforderung 3.2.2, Anforderung 3.2.3)

Die Verarbeitung und der Schutz von Daten sind Workload-Angelegenheiten und gehen über den Rahmen dieser Architektur hinaus. Hier sind nur Informationen zu einigen allgemeinen Aspekten angegeben.

Gemäß Standard bestehen vertrauliche Authentifizierungsdaten aus den vollständigen Nachverfolgungsdaten, der Kartenprüfnummer und den PIN-Daten. Stellen Sie im Rahmen der Verarbeitung von Karteninhaberdaten sicher, dass Authentifizierungsdaten nicht in Quellen der folgenden Art verfügbar gemacht werden:

• Protokolle, die von den Pods ausgegeben werden
• Ausnahmebehandlungsroutinen
• Dateinamen
• Caches.

Eine allgemeine Faustregel lautet, dass diese Informationen von Händlern nicht gespeichert werden sollten. Falls eine Anforderung in dieser Hinsicht besteht, sollten Sie die geschäftliche Begründung dafür dokumentieren.

Anforderung 3.3

Maskieren Sie die PAN bei der Anzeige (die ersten sechs und die letzten vier Ziffern sind die maximale Anzahl von anzuzeigenden Ziffern), sodass nur Mitarbeiter mit einem berechtigten geschäftlichen Anspruch die vollständige PAN sehen können.

Ihre Zuständigkeiten

Die Hauptkontonummer (Primary Account Number, PAN) gilt als vertrauliches Datenelement, dessen Offenlegung verhindert werden muss. Eine Möglichkeit besteht darin, die Anzahl angezeigter Ziffern per Maskierung zu verringern.

Vermeiden Sie es, die Datenmaskierung in der Workload zu implementieren. Verwenden Sie stattdessen Konstrukte auf Datenbankebene. Für die Azure SQL-Reihe der Dienste, z. B. Azure Synapse Analytics, wird die dynamische Datenmaskierung unterstützt, mit der der Grad der Offenlegung auf der Anwendungsebene reduziert wird. Hierbei handelt es sich um ein richtlinienbasiertes Sicherheitsfeature, mit dem definiert wird, wer die nicht maskierten Daten anzeigen kann und welcher Anteil der Daten bei der Maskierung verfügbar gemacht wird. Bei der integrierten Maskierungsmethode vom Typ Kreditkarte werden die letzten vier Ziffern der festgelegten Felder angezeigt, und es wird eine konstante Zeichenfolge in Form einer Kreditkarte als Präfix hinzugefügt.

Weitere Informationen finden Sie unter Dynamische Datenmaskierung.

Falls Sie nicht maskierte Daten in Ihren Cluster übertragen müssen, sollten Sie die Maskierung so schnell wie möglich durchführen.

Anforderung 3.4

Stellen Sie die PAN überall dort, wo sie gespeichert ist, unlesbar dar (einschließlich tragbarer digitaler Medien, Sicherungsmedien und in Protokollen), indem Sie einen der folgenden Ansätze verwenden:

• Unidirektionale Hashes basierend auf starker Kryptografie (Hash muss gesamte PAN umfassen)
• Kürzung (Hashing kann nicht verwendet werden, um das abgeschnittene Segment der PAN zu ersetzen)
• Indextoken und -blöcke (Blöcke müssen sicher aufbewahrt werden)
• Starke Kryptografie mit zugehörigen Schlüsselverwaltungsprozessen und -verfahren

Ihre Zuständigkeiten

Zur Erfüllung dieser Anforderung müssen Sie unter Umständen die direkte Kryptografie in der Workload verwenden. Im PCI-DSS-Leitfaden wird empfohlen, bereits in der Branche getestete Algorithmen zu nutzen, damit sie realen Angriffen standhalten. Vermeiden Sie die Verwendung von benutzerdefinierten Verschlüsselungsalgorithmen.

Diese Anforderung kann auch mit geeigneten Datenmaskierungsverfahren erfüllt werden. Sie sind dafür verantwortlich, alle Daten der Hauptkontonummer (Primary Account Number, PAN) zu maskieren. Für die Azure SQL-Reihe der Dienste, z. B. Azure Synapse Analytics, wird die dynamische Datenmaskierung unterstützt. Informationen hierzu finden Sie unter Anforderung 3.3.

Stellen Sie sicher, dass die Hauptkontonummer nicht im Rahmen Ihrer Workflowprozesse verfügbar gemacht wird. Hier einige Überlegungen dazu:

• Nehmen Sie die Hauptkontonummer von der Protokollierung aus. Dies gilt sowohl für Workflowprotokolle (erwartet oder unerwartet) als auch für Protokolle zur Ausnahmebehandlung. Darüber hinaus dürfen diese Daten auch nicht in Diagnosedatenflüssen, z. B. HTTP-Headern, verfügbar gemacht werden.

• Verwenden Sie die Hauptkontonummer nicht als Schlüssel für die Cachesuche oder als Teil eines Dateinamens, der bei diesem Prozess generiert wird.

• Es kann vorkommen, dass Ihre Kunden die Hauptkontonummer unaufgefordert in Feldern für Freitext angeben. Stellen Sie sicher, dass Prozesse zur Inhaltsüberprüfung und -erkennung für alle Freitextfelder vorhanden sind und alle Inhalte bereinigt werden, die Hauptkontonummer-Daten ähneln.

Anforderung 3.4.1

Wenn die Datenträgerverschlüsselung verwendet wird (anstelle der Datenbankverschlüsselung auf Datei- oder Spaltenebene), muss der logische Zugriff separat und unabhängig von nativen Authentifizierungs- und Zugriffssteuerungsmechanismen des Betriebssystems verwaltet werden (z. B. durch den Verzicht auf lokale Benutzerkontendatenbanken oder allgemeine Netzwerkanmeldeinformationen). Entschlüsselungsschlüssel dürfen nicht zu Benutzerkonten zugeordnet werden.

Ihre Zuständigkeiten

Es gilt die allgemeine Empfehlung, dass der Status nicht im AKS-Cluster gespeichert werden sollte. Verwenden Sie einen externen Datenspeicher, für den die Verschlüsselung auf der Ebene der Speicher-Engine unterstützt wird.

Alle gespeicherten Daten in Azure Storage werden mit sicheren Kryptografieverfahren ver- und entschlüsselt. Die zugehörigen Schlüssel werden von Microsoft verwaltet. Hierbei werden selbstverwaltete Verschlüsselungsschlüssel bevorzugt. Führen Sie die Verschlüsselung immer außerhalb der Speicherebene durch, und schreiben Sie nur verschlüsselte Daten auf das Speichermedium. Stellen Sie sicher, dass sich die Schlüssel niemals in der Nähe der Speicherebene befinden.

Bei Azure Storage können Sie auch selbstverwaltete Schlüssel verwenden. Ausführlichere Informationen finden Sie unter Kundenseitig verwaltete Schlüssel für die Azure Storage-Verschlüsselung.

Für Datenbanken sind ähnliche Funktionen verfügbar. Informationen zu Azure SQL-Optionen finden Sie unter Azure SQL Transparent Data Encryption mithilfe eines kundenseitig verwalteten Schlüssels.

Stellen Sie sicher, dass Sie Ihre Schlüssel in einem verwalteten Schlüsselspeicher wie Azure Key Vault, einem verwalteten Azure-HSM oder einer Drittanbieterlösung für die Schlüsselverwaltung speichern.

Falls Sie Daten vorübergehend speichern müssen, sollten Sie das Feature Hostverschlüsselung von AKS aktivieren, um sicherzustellen, dass die auf den VM-Knoten gespeicherten Daten verschlüsselt sind.

Anforderung 3.5

Dokumentieren und implementieren Sie Verfahren zum Schutz von Schlüsseln, mit denen gespeicherte Karteninhaberdaten vor Offenlegung und Missbrauch geschützt werden.

Ihre Zuständigkeiten

Diese Punkte sind in den Unterabschnitten beschrieben:

• Nutzen Sie für die kryptografischen Schlüssel den Zugriff mit den geringsten Rechten.
• Azure Key Vault und Microsoft Entra ID sind so konzipiert, dass die Anforderungen in Bezug auf die Autorisierung und die Überwachungsprotokollierung unterstützt werden. Ausführlichere Informationen finden Sie im Abschnitt zum Anfordern der Authentifizierung für Azure Key Vault.
• Schützen Sie alle Datenverschlüsselungsschlüssel mit einem Schlüssel für die Schlüsselverschlüsselung, der auf einem kryptografischen Gerät gespeichert ist.
• Achten Sie bei Verwendung von selbstverwalteten Schlüsseln (anstelle von durch Microsoft verwalteten Schlüsseln) darauf, dass ein Prozess und eine Dokumentation vorhanden sind, in der die Aufgaben der Schlüsselverwaltung beschrieben sind.

Anforderung 3.5.1

Zusätzliche Anforderung nur für Dienstanbieter: Erstellen Sie eine dokumentierte Beschreibung der kryptografischen Architektur, die Folgendes enthält:

• Details zu allen Algorithmen, Protokollen und Schlüsseln, die zum Schutz der Karteninhaberdaten verwendet werden, einschließlich der Schlüsselstärke und des Ablaufdatums.
• Beschreibung der Verwendung für jeden Schlüssel
• Bestandsaufnahme aller HSMs und anderer SCDs, die für die Schlüsselverwaltung verwendet werden

Ihre Zuständigkeiten

Eine Möglichkeit zum Speichern von vertraulichen Informationen (Schlüssel, Verbindungszeichenfolgen und andere) ist die Nutzung der nativen Kubernetes-Ressource Secret. Sie müssen die Verschlüsselung ruhender Daten explizit aktivieren. Speichern Sie sie alternativ in einem verwalteten Speicher, z. B. Azure Key Vault. Der von uns empfohlene Ansatz ist die Verwendung eines verwalteten Speicherdiensts. Ein Vorteil ist eine Reduzierung des Mehraufwands bei den Aufgaben zur Schlüsselverwaltung, z. B. die Schlüsselrotation.

Standardmäßig werden in Azure für alle verschlüsselten Daten für jeden Kunden von Microsoft verwaltete Schlüssel genutzt. Bei einigen Diensten werden aber auch selbstverwaltete Schlüssel für die Verschlüsselung unterstützt. Wenn Sie selbstverwaltete Schlüssel für die Verschlüsselung im ruhenden Zustand verwenden, sollten Sie sicherstellen, dass Sie über einen Prozess und eine Strategie für die Aufgaben zur Schlüsselverwaltung verfügen.

Fügen Sie in Ihre Dokumentation auch Informationen zur Schlüsselverwaltung ein, z. B. Details zu Ablauf, Standort und Wartungsplan.

Anforderung 3.5.2

Beschränken Sie den Zugriff auf kryptografische Schlüssel auf die geringstmögliche Anzahl von Verwaltungsberechtigten.

Ihre Zuständigkeiten

Halten Sie die Anzahl von Personen, die Zugriff auf die Schlüssel haben, möglichst gering. Richten Sie bei Verwendung von gruppenbasierten Rollenzuweisungen einen wiederkehrenden Überwachungsprozess ein, bei dem die Rollen überprüft werden, für die Zugriff besteht. Wenn sich die Mitglieder des Projektteams ändern, müssen die Berechtigungen für Konten, die nicht mehr relevant sind, entfernt werden. Nur die richtigen Personen sollten jeweils Zugriff haben. Verwenden Sie Microsoft Entra ID-Zugriffsüberprüfungen, um Gruppenmitgliedschaften regelmäßig zu überprüfen.

Erwägen Sie, fest zugeordnete Berechtigungen durch JIT-Rollenzuweisungen (Just-In-Time) und eine zeit- bzw. genehmigungsbasierte Aktivierung von Rollen zu ersetzen. Ziehen Sie beispielsweise die Verwendung von Privileged Identity Management in Betracht.

Anforderung 3.5.3

Speichern Sie geheime und private Schlüssel, die zum Ver-/Entschlüsseln von Karteninhaberdaten verwendet werden, immer in einem (oder mehreren) der folgenden Formate:

• Verschlüsselt mit einem Schlüssel für die Schlüsselverschlüsselung, der mindestens so stark ist wie der Datenverschlüsselungsschlüssel, und der getrennt vom Datenverschlüsselungsschlüssel gespeichert wird.
• Innerhalb eines sicheren kryptografischen Geräts (z. B. eines Hardwaresicherheitsmoduls (HSM) oder eines PTS-zugelassenen Interaktionspunktgeräts)
• Als mindestens zwei vollständige Schlüsselkomponenten oder Schlüsselfreigaben gemäß einer branchenüblichen Methode

Ihre Zuständigkeiten

Für eine PCI-DSS 3.2.1-Workload muss im Rahmen der Schutzstrategie für ruhende Daten mehr als ein Verschlüsselungsschlüssel verwendet werden. Ein Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) wird verwendet, um die Karteninhaberdaten zu ver- und entschlüsseln. Sie selbst sind aber für das Vorhandensein eines zusätzlichen Schlüssels für die Schlüsselverschlüsselung (Key Encryption Key, KEK) verantwortlich, mit dem der DEK geschützt wird. Darüber hinaus müssen Sie auch sicherstellen, dass der KEK auf einem kryptografischen Gerät gespeichert wird.

Sie können Azure Key Vault zum Speichern des DEK und das Azure Dedicated HSM zum Speichern des KEK nutzen. Informationen zur HSM-Schlüsselverwaltung finden Sie unter Was ist Azure Dedicated HSM?.

Anforderung 3.6

Dokumentieren und implementieren Sie alle Schlüsselverwaltungsprozesse und -verfahren für kryptografische Schlüssel, die zur Verschlüsselung von Karteninhaberdaten verwendet werden, z. B.:

Ihre Zuständigkeiten

(GILT FÜR: Anforderung 3.6.1, Anforderung 3.6.2, Anforderung 3.6.3, Anforderung 3.2.4)

Wenn Sie Azure Key Vault zum Speichern von Geheimnissen wie Schlüsseln, Zertifikaten und Verbindungszeichenfolgen verwenden, sollten Sie die Daten vor unbefugtem Zugriff schützen. Microsoft Defender für Key Vault erkennt verdächtige Zugriffsversuche und generiert Warnungen. Sie können diese Warnungen in Microsoft Defender für Cloud anzeigen. Weitere Informationen finden Sie unter Einführung in Microsoft Defender für Key Vault.

Befolgen Sie die NIST-Anleitung zur Schlüsselverwaltung. Einzelheiten dazu finden Sie unter:

• Verwalten von kryptografischen Schlüsseln
• SP 800-133 Rev. 2, Empfehlung zur Generierung kryptografischer Schlüssel
• SP 800-57 Teil 1 Rev. 5, Empfehlung zur Schlüsselverwaltung

Lesen Sie auch die Informationen unter Einführung in Microsoft Defender für Key Vault.

Anforderung 3.6.7

Verhinderung der unbefugten Ersetzung von kryptografischen Schlüsseln.

Ihre Zuständigkeiten

• Aktivieren Sie die Diagnose für alle Schlüsselspeicher. Verwenden Sie Azure Monitor für Key Vault. Hiermit werden Protokolle und Metriken gesammelt und an Azure Monitor gesendet. Weitere Informationen finden Sie unter Überwachen Ihres Schlüsseltresordiensts mit Azure Monitor für Key Vault.
• Erteilen Sie allen Consumern Leseberechtigungen.
• Verwenden Sie für Verwaltungsbenutzer oder -prinzipale keine fest zugeordneten Berechtigungen. Nutzen Sie stattdessen Just-In-Time-Rollenzuweisungen (JIT) und die zeit- bzw. genehmigungsbasierte Rollenaktivierung.
• Erstellen Sie eine zentrale Ansicht, indem Sie Protokolle und Warnungen in SIEM-Lösungen (Security Information & Event Management) integrieren, z. B. Microsoft Sentinel.
• Ergreifen Sie Maßnahmen in Bezug auf Warnungen und Benachrichtigungen. Dies gilt vor allem für unerwartete Änderungen.

Anforderung 3.6.8

Anforderung an Verwaltungsberechtigte für kryptografische Schlüssel zur formellen Anerkennung, dass sie ihre Verantwortung als Schlüsselverwaltungsberechtigte verstehen und akzeptieren.

Ihre Zuständigkeiten

Legen Sie eine Dokumentation an, in der die Zuständigkeiten der Parteien beschrieben sind, die für die Durchführung der Schlüsselverwaltung verantwortlich sind.

Anforderung 3.7

Stellen Sie sicher, dass Sicherheitsrichtlinien und betriebliche Verfahren zum Schützen gespeicherter Daten von Karteninhabern dokumentiert und verwendet werden sowie allen beteiligten Parteien bekannt sind.

Ihre Zuständigkeiten

Erstellen Sie eine Dokumentation mit allgemeinen Informationen sowie aktuelle Rollenleitfäden für alle Personas. Führen Sie Schulungen für neu eingestellte Mitarbeiter und fortlaufende Schulungen durch.

Es ist wichtig, dass Sie eine umfassende Dokumentation zu den Prozessen und Richtlinien führen. Mehrere Teams sind daran beteiligt sicherzustellen, dass die Daten im ruhenden Zustand und während der Übertragung geschützt sind. Stellen Sie in Ihrer Dokumentation Rollenleitfäden für alle Personas bereit. Die Rollen sollten die Bereiche SRE, Kundensupport, Vertrieb, Netzwerkbetrieb, Sicherheitsabläufe, Softwareentwickler, Datenbankadministratoren und mehr abdecken. Mitarbeiter sollten in Bezug auf NIST-Leitfäden und Strategien für ruhende Daten geschult werden, um deren Skillset auf dem neuesten Stand zu halten. Die Trainingsanforderungen sind unter Anforderung 6.5 und Anforderung 12.6 beschrieben.

Anforderung 4: Verschlüsseln der Übertragung von Karteninhaberdaten über offen zugängliche öffentliche Netzwerke

Ihre Zuständigkeiten

Anforderung 4.1

Verwenden Sie sichere Kryptografieverfahren und Sicherheitsprotokolle (z. B. TLS, IPSEC, SSH usw.), um vertrauliche Daten von Karteninhabern während der Übertragung über offen zugängliche öffentliche Netzwerke zu schützen, z. B.:

Ihre Zuständigkeiten

Karteninhaberdaten, die über das öffentliche Internet übertragen werden, müssen verschlüsselt sein. Daten müssen per TLS 1.2 (oder höher) verschlüsselt werden, und bei allen Übertragungen sollte mit einer reduzierten Verschlüsselungsunterstützung gearbeitet werden. Unterstützen Sie für Datenübertragungsdienste keine Umleitungen von „Nicht-TLS“ zu „TLS“.

Ihr Entwurf sollte über eine strategische Kette mit TLS-Abschlusspunkten verfügen. Wenn Daten über Netzwerkhops übertragen werden, sollten Sie TLS an Hops nutzen, die eine Paketüberprüfung erfordern. Verwenden Sie mindestens den letzten TLS-Abschlusspunkt auf der Eingangsressource des Clusters. Erwägen Sie, dies auch auf die anderen Clusterressourcen zu erweitern.

Nutzen Sie Azure Policy, um die Erstellung von Ressourcen zu steuern:

• Lehnen Sie die Erstellung von Eingangsressourcen ab, für die nicht HTTPS verwendet wird.
• Lehnen Sie die Erstellung einer öffentlichen IP-Adresse oder eines öffentlichen Lastenausgleichsmoduls in Ihrem Cluster ab, um sicherzustellen, dass für Webdatenverkehr die Tunnelung über Ihr Gateway erfolgt.

Weitere Informationen finden Sie unter Übersicht über die Azure-Verschlüsselung.

Anforderung 4.1.1

Stellen Sie sicher, dass für Drahtlosnetzwerke, die Daten von Karteninhabern übertragen oder mit der Umgebung der Karteninhaberdaten verbunden sind, die bewährten Methoden der Branche (z. B. IEEE 802.11i) genutzt werden, um eine sichere Verschlüsselung für die Authentifizierung und Übertragung zu implementieren.

Ihre Zuständigkeiten

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

Anforderung 4.2

Senden Sie niemals ungeschützte PANs über Messagingtechnologien für Endbenutzer (z. B. E-Mail, Sofortnachrichten, SMS, Chat usw.).

Ihre Zuständigkeiten

Falls für Ihre Workload das Senden von E-Mails erforderlich ist, sollten Sie erwägen, ein Gate für die E-Mail-Quarantäne zu erstellen. Bei dieser Überprüfung haben Sie die Möglichkeit, alle ausgehenden Nachrichten auf Konformität zu untersuchen und sicherzustellen, dass keine vertraulichen Daten enthalten sind. Idealerweise sollten Sie diesen Ansatz auch für Kundensupportnachrichten in Betracht ziehen.

Die Überprüfung sollte auf Workloadebene und während des Prozesses für die Änderungssteuerung erfolgen. Für die Genehmigungsgates sollte klar sein, um was es bei der Anforderung geht.

Informationen zu den zu berücksichtigenden Punkten finden Sie im Leitfaden zum offiziellen PCI-DSS 3.2.1-Standard.

Anforderung 4.3

Stellen Sie sicher, dass Sicherheitsrichtlinien und betriebliche Verfahren für die Verschlüsselung der Übertragungen von Daten von Karteninhabern dokumentiert und verwendet werden sowie allen beteiligten Parteien bekannt sind.

Ihre Zuständigkeiten

Es ist wichtig, dass Sie eine umfassende Dokumentation zu den Prozessen und Richtlinien führen. Dies gilt besonders für die Verwaltung von Richtlinien für Transport Layer Security (TLS). Hier sind einige Bereiche aufgeführt:

• Öffentliche Internetzugangspunkte. Ein Beispiel hierfür ist die Azure Application Gateway-Unterstützung für TLS-Verschlüsselungsverfahren.
• Netzwerkhops zwischen Umkreisnetzwerk und Workloadpods.
• Pod-zu-Pod-Verschlüsselung (falls implementiert). Dies kann auch Details zur Konfiguration eines Dienstnetzes (Service Mesh) enthalten.
• Pod zu Speicher (falls dies Teil der Architektur ist).
• Pod zu externen Diensten, Azure PaaS-Dienste, für die TLS genutzt wird, ein Zahlungsgateway oder ein System zum Erkennen von Betrugsversuchen.

Personen, die in regulierten Umgebungen arbeiten, müssen geschult werden, informiert sein und Anreize erhalten, damit sie die Sicherheitsgarantien unterstützen. Dies ist besonders wichtig für Personen, die aus Richtliniensicht Teil des Genehmigungsprozesses sind.

Nächste Schritte

Schützen Sie alle Systeme vor Schadsoftware, und führen Sie regelmäßige Aktualisierungen der Virenschutzsoftware bzw. -programme durch. Entwickeln Sie sichere Systeme und Anwendungen, und führen Sie die Wartungsaufgaben dafür durch.