Geltungsbereich der Compliance für PCI-Umgebungen in Google Cloud verringern

In diesem Dokument werden Best Practices für die Gestaltung Ihrer Cloud-Umgebung für die Compliance mit dem Payment Card Industry (PCI) Security Standards Council beschrieben. Diese Best Practices eignen sich für Organisationen, die Systeme in die Cloud migrieren oder gestalten, die den PCI-Compliance-Anforderungen unterliegen. Dieses Dokument bezieht sich gegebenenfalls auf die Anforderungen für PCI DSS 4.0.

Informationen zum Geltungsbereich der PCI-DSS-Bewertung

Wenn Ihre Organisation E-Commerce betreibt, müssen Sie die PCI-Compliance unterstützen und beibehalten. Die Art und Weise, wie Sie Ihre Cloud-Umgebung gestalten und verwalten, wirkt sich darauf aus, ob Ihre Systeme in den Geltungsbereichs Ihrer PCI-DSS-Bewertung (Data Security Standard) einbezogen werden. Die Bestimmung des Geltungsbereichs hat wichtige Auswirkungen auf die Sicherheit Ihrer IT-Assets und die Fähigkeit, PCI-Compliance zu unterstützen und beizubehalten. Damit Ihre PCI-Umgebung ordnungsgemäß dimensioniert wird, müssen Sie wissen, wie sich Ihre Geschäftsprozesse und Designentscheidungen auf den Geltungsbereich auswirken.

Was ist der Geltungsbereich?

Alle Systeme, die Karteninhaberdaten (Cardholder Data, CHD) speichern, verarbeiten oder übertragen, liegen im Geltungsbereich der PCI-DSS-Bewertung. Sicherheit ist für die gesamte Cloud-Umgebung wichtig, aber die Gefährdung von Systemen innerhalb des Geltungsbereichs kann zu einer Datenpanne und zur Offenlegung der CHD führen.

In Abbildung 1 befinden sich die CDE-Umgebung (Cardholder Data Environment, Umgebung der Karteninhaberdaten), verbundene Systeme und sicherheitsrelevante Systeme innerhalb der Grenzen des Geltungsbereichs für die Bewertung. Nicht vertrauenswürdige Systeme und Systeme außerhalb des Geltungsbereichs befinden sich hingegen außerhalb dieser Grenzen.

Gemäß PCI-DSS sind Systeme, die sich innerhalb des Geltungsbereichs befinden, vertrauenswürdig. Systeme, die sich innerhalb des Geltungsbereichs befinden, sind beispielsweise die CDE und alle verbundenen Systeme, die sich auf die CDE-Sicherheit auswirken könnten.

Ein System ist verbunden, wenn es sich im selben Netzwerk befindet, Datenbanken oder Dateispeicher nutzt oder sonstigen Zugriff auf ein System oder Konnektivität zu einem System oder Prozess innerhalb der CDE hat, ohne jedoch direkten Zugriff auf CHD zu haben.

Ein System ist sicherheitsrelevant, wenn es dem Angreifer bei einem Systemmissbrauch Zugriff auf die CDE bieten kann. Alle verbundenen und sicherheitsrelevanten Systeme befinden sich immer innerhalb des Geltungsbereichs.

Systeme außerhalb des Geltungsbereichs sind gemäß der Definition in PCI-DSS nicht vertrauenswürdig und haben für den Angreifer, der Zugriff auf CHD oder vertrauliche Authentifizierungsdaten (Sensitive Authentication Data, SAD) sucht, keinen Wert. Ein System liegt außerhalb des Geltungsbereichs, wenn es keinen Einfluss auf die Sicherheit eines Systems innerhalb des Geltungsbereichs hat, auch wenn das System außerhalb des Geltungsbereichs manipuliert wurde. Systeme außerhalb des Geltungsbereichs werden zwar nicht direkt bewertet, aber der PCI Qualified Security Assessor (QSA) prüft, ob die Bestimmung der Geltungsbereich sachgemäß ist und CHD gemäß dem PCI-DSS schützt. Daher ist es wichtig, dass die Grenzen des Geltungsbereichs gut geschützt sind, kontinuierlich und umfassend überwacht werden und klar dokumentiert sind.

Verbindungen im PCI-Kontext

Verschiedene PCI-DSS-Anforderungen beziehen sich auf Verbindungen, aber der PCI DSS definiert keine expliziten Verbindungen. Die Bedeutung von Verbindungen in diesem Kontext wird mit dem Entscheidungsbaum zur Bestimmung des Geltungsbereichs in der PCI SSC-Anleitung zu PCI-DSS-Geltungsbereich und Netzwerksegmentierung (PDF) verdeutlicht.

Zur Bewertung des PCI-Geltungsbereichs wird eine Verbindung so definiert:

• Ein aktiver Informationstransport, der zwei Computer oder Systeme verbindet
• Von welchen beiden Parteien wird der Anruf initiiert

Wenn Sie Ihre Umgebung dokumentieren, ist es am besten, klar anzugeben, welche Partei zum Herstellen einer Verbindung berechtigt ist. Eine Firewall, die nur Traffic in einer Richtung zulässt, kann eine einseitige Verbindung erzwingen. Beispielsweise kann eine Anwendung zur Zahlungsabwicklung, die innerhalb des Geltungsbereichs liegt, Abfragen an einen anderen Datenbankserver außerhalb des Geltungsbereichs senden, ohne dass der Datenbankserver in den Geltungsbereich gelangt, wenn alles Nachstehende zutrifft:

• Die Verbindung und die Datenbank außerhalb des Geltungsbereichs speichern, verarbeiten oder übertragen keine CHD oder SAD.
• Die Datenbank befindet sich in einem separaten Netzwerk oder ist anderweitig von der CDE segmentiert.
• Die Datenbank kann keine direkten oder indirekten Aufrufe an die CDE auslösen.
• Die Datenbank stellt der CDE keine Sicherheitsdienste bereit.
• Die Datenbank hat keinen Einfluss auf die Konfiguration oder Sicherheit der CDE.
• Die Datenbank unterstützt PCI-DSS-Anforderungen.

Das folgende Diagramm zeigt die Faktoren, die den Geltungsbereich des Systems bestimmen:

In Abbildung 2 wird der Systemumfang so definiert:

• Systemkomponenten, die innerhalb des PCI-DSS-Geltungsbereichs liegen:

  • Systeme in der CDE, für die eine der folgenden Bedingungen erfüllt ist:
    • Eine Systemkomponente speichert, verarbeitet oder überträgt CHD oder SAD.
    • Eine Systemkomponente befindet sich im selben Netzwerksegment – beispielsweise im selben Subnetz oder VLAN – wie Systeme, die CHD speichern, verarbeiten oder übertragen.
  • Verbundene oder sicherheitsrelevante Systeme, für die eine der folgenden Bedingungen erfüllt ist:
    • Eine Systemkomponente stellt eine direkte Verbindung zur CDE her.
    • Eine Systemkomponente wirkt sich auf die Konfiguration oder Sicherheit der CDE aus.
    • Eine Systemkomponente segmentiert CDE-Systeme von Systemen und Netzwerken außerhalb des Geltungsbereichs.
    • Eine Systemkomponente stellt indirekt eine Verbindung zur CDE her.
    • Eine Systemkomponente stellt Sicherheitsdienste für die CDE bereit.
    • Eine Systemkomponente unterstützt PCI-DSS-Anforderungen.

• Systemkomponenten gelten als nicht vertrauenswürdig und außerhalb des PCI-DSS-Geltungsbereichs, wenn alle der folgenden Bedingungen erfüllt sind:

  • Eine Systemkomponente speichert, verarbeitet oder überträgt keine CHD oder SAD.
  • Eine Systemkomponente hat ein anderes Netzwerksegment, z. B. im selben Subnetz oder VLAN, als Systeme, die CHD oder SAD speichern, verarbeiten oder übertragen.
  • Eine Systemkomponente kann keine Verbindung zu einem System in der CDE herstellen.
  • Eine Systemkomponente erfüllt keine Kriterien für verbundene oder sicherheitsrelevante Systeme.

  Systeme außerhalb des Geltungsbereichs können Systeme sein, die mit einer verbundenen oder sicherheitsrelevanten Systemkomponente verbunden sind, bei der mit Steuerelementen verhindert wird, dass das System außerhalb des Geltungsbereichs über die Systemkomponente innerhalb des Geltungsbereichs Zugriff auf die CDE erhält.

In der Praxis kann die PCI-DSS-Definition des Systembereichs dazu führen, dass der Sitzungsspeicher und die E-Commerce-Datenbank Ihrer Webanwendung als außerhalb des Geltungsbereichs eingestuft wird, wenn die Segmentierung richtig implementiert und dokumentiert wurde. Das folgende Diagramm zeigt, wie Lese- und Schreibverbindungen bei Systemen innerhalb und außerhalb des Geltungsbereichs funktionieren:

Abbildung 3 zeigt die folgenden Verbindungen:

• Nur Lesezugriff:
  • Eine Anwendung zur Zahlungsabwicklung, die innerhalb des Geltungsbereichs liegt, liest eine Einkaufswagen-ID aus einer Einkaufswagen-Datenbank außerhalb des Geltungsbereichs und Daten aus einem DNS und NTP.
• Nur Schreibzugriff:
  • Eine Anwendung zur Zahlungsabwicklung, die innerhalb des Geltungsbereichs liegt, schreibt in die Hauptdatenbank einer Anwendung außerhalb des Geltungsbereichs und in Cloud Logging.
  • Die Hauptwebanwendung außerhalb des Geltungsbereichs schreibt Daten in einen Logging-Dienst. CHD oder SAD sind in diesen Daten nicht enthalten.
• Lese- und Schreibzugriff:
  • Ein Nutzer im öffentlichen Web liest und schreibt Anfrage-Metadaten so:
    • Der Nutzer liest und schreibt in eine Anwendung zur Zahlungsabwicklung, die innerhalb des Geltungsbereichs liegt. Diese Anfragemetadaten sind die Einkaufswagen-ID und der Einkaufswagen-Authentifizierungsschlüssel, die CHD und SAD enthalten.
    • Der Nutzer liest und schreibt aus der und in die Webanwendung außerhalb des Geltungsbereichs. Diese Anfragemetadaten sind eine Sitzungs-ID, die weder CHD noch SAD enthält.
  • Die Hauptwebanwendung außerhalb des Geltungsbereichs liest und schreibt Daten in eine Einkaufswagen-Datenbank, einen Sitzungsspeicher und in die Hauptdatenbank einer Anwendung, die außerhalb des Geltungsbereichs liegen. CHD oder SAD sind in diesen Daten nicht enthalten.
  • Eine Anwendung zur Zahlungsabwicklung, die innerhalb des Geltungsbereichs liegt, liest und schreibt Daten in einen Dienst zur Kartentokenisierung außerhalb des Geltungsbereichs und in einen Kreditkartenprozessor im öffentlichen Web. Diese Daten enthalten CHD und SAD.

Die Architektur in Abbildung 3 beschreibt zwei unterschiedliche Webanwendungen: die Haupt-Webanwendung (Hauptanwendung), die für PCI außerhalb des Geltungsbereichs liegt, und die Zahlungsabwicklungsanwendung (Kassenanwendung), die im Geltungsbereich liegt. In dieser Architektur kann eine Verbindung zwischen zwei Entitäten nur in die Richtungen eingeleitet werden, die in der vorherigen Liste beschrieben werden. Verbindungen zwischen Entitäten können aus der Perspektive des Aufrufers schreibgeschützt sein, Lese- und Schreibberechtigungen oder nur Schreibberechtigungen haben. Pfade oder Anfragen, die nicht explizit beschrieben werden, werden durch eine Segmentierung blockiert. Beispielsweise kann die Anwendung zur Zahlungsabwicklung Daten aus der Einkaufswagendatenbank lesen und in den Logging-Dienst schreiben. Dazu wird eine Verbindung zu diesen Entitäten initiiert.

Systeme innerhalb des Geltungsbereichs rufen häufig Systeme und Dienste außerhalb des Geltungsbereichs auf. Diese Verbindungen bleiben sicher, da die Segmentierung verhindert, dass Remote-Aufrufer (außer Karteninhaber) eine Verbindung direkt oder indirekt an die CDE initiieren können. Abbildung 3 zeigt, dass der einzige Ingress-Pfad zur Kassenanwendung vom Nutzer stammt.

In Abbildung 3 gibt es auch keine anderen Anwendungen oder Dienste außerhalb des Geltungsbereichs, die Konfigurations- oder Sicherheitsdaten für die Zahlungsabwicklungsanwendung bereitstellen. Der Datenfluss durch die Architektur erfolgt so:

1. Die Hauptanwendung leitet den Nutzer an die Kasse weiter und verwendet einen HTTP-POST, um die CartID und einen Validator namens CartAuthKey zu übertragen. CartAuthKey ist ein Hash-Wert der CartID und ein vorinstalliertes Secret, das nur den Haupt- und Kassenanwendungen bekannt ist.
2. Die Kassenanwendung validiert den Nutzer durch Hashing der CartID mit dem Secret und vergleicht diesen Wert mit CartAuthKey.
3. Nach der Authentifizierung der Nutzerdaten werden die Daten des Einkaufswagens mit der CartID aus der Einkaufswagendatenbank gelesen. Alle Karteninhaberdaten werden vom Nutzer direkt an die Kasse gesendet.
4. Bei Verwendung von Zahlungsprofilen werden die Karteninhaberdaten im Tokenisierungsdienst gespeichert.
5. Nach der Verarbeitung der Zahlung wird das Ergebnis in die Datenbank der Hauptanwendung mit einem schreibgeschützten Datenbank-Dienstkonto eingefügt.

Überlegungen zur Bestimmung des Geltungsbereichs

Im Leitfaden zur PCI DSS-Compliance und Segmentierung von Netzwerken wird vom PCI Security Standards Council (SSC) empfohlen, dass Sie davon ausgehen, dass alles im Geltungsbereich ist, bis das Gegenteil verifiziert wurde. Diese SSC-Empfehlung bedeutet nicht, dass Sie den Geltungsbereich so breit wie möglich gestalten sollten. Es bedeutet aber, dass das QSA alle Systeme als "vertrauenswürdig" bewertet, es sei denn, Sie weisen nach, dass ein System keine Verbindung oder keine Auswirkungen auf die CDE hat. Wenn Sie die behördlichen Complianceanforderungen erfüllen und Ihre IT-Assets sicher sind, sollten Sie Ihre Umgebung am Grundsatz der geringsten Berechtigung ausrichten, indem Sie so wenig Systemen wie möglich vertrauen.

Evaluieren Sie Ihre Umgebung vor der Bewertung, um die Grenze zwischen Ihren Systemen innerhalb und außerhalb des Geltungsbereichs zu verstehen. Die erste Aufgabe des QSA besteht darin, zu bestätigen, dass der dokumentierte Geltungsbereich die CDE und die verbundenen Systeme in angemessener Weise umfasst. Im Rahmen der Gesamtbewertung überprüft der QSA dann, dass keine Systeme außerhalb des Geltungsbereichs negative Auswirkungen auf Systeme innerhalb des Geltungsbereichs haben können.

Informieren Sie sich über Sonderfälle, die für Ihre Umgebung spezifisch sind. Beispiele:

• Wenn Sie Karteninhaberdaten über das Telefon oder über ein VoIP-System erfassen können zusätzliche Probleme bei der Bestimmung des Geltungsbereichs auftreten, die unter Telefonbasierte Zahlungskartendaten schützen (PDF) aufgeführt sind.
• Wenn Ihr Dienstanbieter Zugriff auf Ihre CDE benötigt (PDF), um ein Kassensystem zu betreiben, wird das von Ihrem Dienstanbieter verwendete System möglicherweise als verbundenes System behandelt. Dies erfordert möglicherweise zusätzliche Überlegungen zur Bestimmung des Geltungsbereichs und zur Due-Diligence.

Mit den Best Practices für die Sicherheit von Google können Sie eine klare und erkennbare Grenze zwischen Systemen außerhalb des Geltungsbereichs und vertrauenswürdigen Systemen festlegen. Dies hilft Ihnen bei der Bewertung. Wenn Sie den Zugriff und die Sicherheit verwalten, indem Sie das Prinzip der geringsten Berechtigung anwenden, können Sie die Anzahl der Offenlegungspunkte für Karteninhaberdaten reduzieren und die Angriffsfläche Ihrer CDE minimieren. Somit verringern Sie auch den Geltungsbereich. Wenn Sie das Vorhandensein von Systemen innerhalb des Geltungsbereichs reduzieren, können Sie die Systemkomplexität reduzieren und die PCI-DSS-Bewertung optimieren.

Risiken einer unsachgemäßen Bestimmung des Geltungsbereichs

Ein zu breit angelegter Geltungsbereich kann zu kostspieligen Bewertungen und höheren Compliancerisiken führen. Um den Geltungsbereich so eng wie möglich zu halten, vertrauen Sie möglichst wenigen Systemen und gewähren Sie nur bestimmten wenigen Nutzern Zugriff. Durch sorgfältige Bewertung und Selbstbewertung können Sie Systeme ermitteln, die nicht innerhalb des PCI-DSS-Geltungsbereichs liegen sollten, dafür sorgen, dass sie den Richtlinien für Systeme außerhalb des Geltungsbereichs entsprechen, und den Geltungsbereich entsprechend reduzieren. Diese Methode der Eliminierung stellt die sicherste Möglichkeit dar, zu ermitteln, welche Systeme nicht vertrauenswürdig sind, und dafür zu sorgen, dass sie keine Auswirkungen auf die Systeme innerhalb des Geltungsbereichs haben.

Wenn eine große Infrastruktur die PCI-DSS-Anforderungen erfüllen muss, kann dies dazu führen, dass irrelevante Systeme in den zu prüfenden Geltungsbereich aufgenommen werden. Wenn Sie in Ihrem Geltungsbereich irrelevante Systeme einschließen, kann das die Compliance beeinträchtigen. Es kann auch die allgemeine Sicherheitslage beeinträchtigen, da Sie die Angriffsfläche Ihrer vertrauenswürdigen Umgebung innerhalb des Geltungsbereichs erweitern.

Ein Kernprinzip von Netzwerksicherheit und PCI-DSS besteht darin, davon auszugehen, dass ein Teil Ihres Netzwerks oder auch Ihr gesamtes Netzwerk bereits manipuliert wurde. Dieses Prinzip basiert auf dem Zero-Trust-Sicherheitsmodell von Google, das die Nur-Perimetersicherheit zugunsten eines Modells ablehnt, bei dem jedes System für seine eigene Sicherheit verantwortlich ist. Das Sicherheitsmodell von Google ist im Einklang mit PCI-DSS, was empfiehlt, dass die CDE und die verbundenen Systeme in einem kleinen, vertrauenswürdigen Bereich bereitgestellt werden, der von Ihrer umfassenderen IT-Umgebung getrennt und nicht mit ihr verbunden ist.

Platzieren Sie Ihre CDE innerhalb Ihrer PCI-Umgebung im Geltungsbereich nicht an einem großen, vertrauenswürdigen Ort mit einem breiten Perimeter. Dies kann zu einem falschen Gefühl der Sicherheit führen und eine ganzheitliche Strategie zur gestaffelten Verteidigung untergraben. Wenn ein Angreifer die Perimetersicherheit verletzt, kann er ganz einfach in einem vertrauenswürdigen, privaten Intranet agieren. Überlegen Sie sich, wie Sie den vertrauenswürdigen Bereich so eingrenzen können, dass er nur das enthält, was er selbst für den Betrieb und die Sicherheit braucht, und verlassen Sie sich nicht nur auf die Perimetersicherheit. Wenn Sie diese Prinzipien verstehen und einhalten, können Sie Ihre Cloud-Umgebung so gestalten, dass Sie Ihre kritischen Systeme sichern und das Risiko einer Kontamination durch manipulierte Systeme verringern.

In einer großen Umgebung mit vertrauenswürdigen Systemen innerhalb des Geltungsbereichs ist ein ähnliches Verwaltungssystem erforderlich, um das kontinuierliche Monitoring, die Wartung, die Prüfung und die Inventarisierung dieser Systeme zu wahren. Die Komplexität der Systemarchitektur, der Änderungsmanagementprozesse und der Zugriffssteuerungsrichtlinien können zu Sicherheits- und Compliancerisiken führen. Schwierigkeiten bei der Verwaltung dieser Monitoringprozesse können zu Problemen mit den PCI DSS-Anforderungen 10 und 11 führen. Sie müssen diese Risiken unbedingt verstehen und Strategien implementieren, um den Geltungsbereich Ihrer geprüften Umgebung einzuschränken. Weitere Informationen finden Sie weiter unten in diesem Dokument unter Kontinuierliche Compliance unterstützen.

Google Cloud-Dienste im PCI-DSS-Geltungsbereich

Bevor Sie den Umfang Ihrer PCI-Umgebung verringern, sollten Sie sich darüber informieren, welche Google Cloud-Dienste im PCI-DSS-Geltungsbereich liegen. Diese Dienste bieten eine Infrastruktur, mit der Sie einen eigenen Dienst oder eine eigene Anwendung erstellen können, in der Karteninhaberdaten gespeichert, verarbeitet oder übertragen werden.

Strategien für die Reduzierung des Geltungsbereichs

In diesem Abschnitt werden die folgenden Strategien zur Reduzierung des Geltungsbereichs für die Bewertung erläutert: Steuerelemente für Ressourcenhierarchie, Segmentierung von VPC Service Controls und Tokenisierung. Anstatt nur einen Ansatz zu wählen, sollten Sie alle diese Strategien einsetzen, um die potenzielle Reduzierung des Geltungsbereichs zu maximieren.

Es gibt keine universelle Lösung für das Erstellen eines PCI-Geltungsbereichs. Möglicherweise ist in Ihrem Netzwerk bereits eine Segmentierung vorhanden oder eine Kartenverarbeitungslösung, die dafür sorgt, dass das Infrastrukturdesign etwas anders aussieht als hier beschrieben. Verwenden Sie diese Strategien als Prinzipien, die Sie auf Ihre eigene Umgebung übertragen können.

Steuerelemente für Ressourcenhierarchie einrichten

Google Cloud-Ressourcen sind so hierarchisch organisiert:

• Die Organisationsressource ist der Stammknoten in der Google Cloud-Ressourcenhierarchie. Organisationsressourcen enthalten Ordner- und Projektressourcen. Zugriffssteuerungsrichtlinien für das Identity and Access Management (IAM) für die Organisationsressource gelten innerhalb der Hierarchie für alle Ressourcen in der Organisation.
• Ordner können Projekte und andere Ordner enthalten und mit IAM-Berechtigungen auf Ordnerebene den Zugriff auf ihre Ressourcen steuern. Ordner werden häufig zum Gruppieren ähnlicher Projekte verwendet.
• Projekte sind eine Vertrauensgrenze für alle Ihre Ressourcen und ein IAM-Erzwingungspunkt.

Folgen Sie den Best Practices von Google, um Ihre Ressourcenhierarchie zu definieren. Die folgende Abbildung zeigt ein Beispiel für eine Ressourcenhierarchie zur PCI-Compliance:

In Abbildung 4 werden alle Projekte, die sich im PCI-Bereich befinden, in einem einzigen Ordner gruppiert, um sie auf Ordnerebene zu isolieren. Der Ordner innerhalb des PCI-Geltungsbereichs enthält die CDE und ein anderes Projekt mit freigegebenen Diensten. Wenn Sie eine ähnliche Ressourcenhierarchie implementieren, bildet der PCI-Bereich des Ordners einen logischen Stamm Ihres PCI-Compliancebereichs. Wenn Sie dafür sorgen, dass nur bestimmte Nutzer Zugriff auf diesen Ordner und dessen Projekte haben, können Sie andere Ordner, Projekte und Ressourcen in Ihrer Hierarchie aus Ihrem Bewertungsbereich ausschließen.

Wenn Sie Nutzern nach Bedarf nur Zugriff auf die Ordner und Projekte gewähren, die sie benötigen, sorgen Sie dafür, dass nur ausgewählte Nutzer Zugriff auf die Komponenten in Ihrem Geltungsbereich haben. Dies unterstützt PCI DSS-Anforderungen 7.2 und 7.3 (PDF) und weitere. Um sicherzustellen, dass die Berechtigungen für die übergeordnete Organisation und die Ordner entsprechend festgelegt sind, lesen Sie Auswirkungen der Richtlinienübernahme. Zur Unterstützung der PCI DSS-Anforderung 8.4.1 muss die Multi-Faktor-Authentifizierung (MFA) für bestimmte Nutzer erzwungen werden. Weitere Informationen finden Sie im PCI DSS-Zusatz zur Multi-Faktor-Authentifizierung (PDF). Zum Erzwingen von Compliance in Ihrer Ressourcenhierarchie sollten Sie wissen, wie Sie Einschränkungen für Organisationsrichtlinien festlegen können. Diese Einschränkungen unterstützen die kontinuierliche Compliance und können Ihre vertrauenswürdigen Umgebungen vor der Rechteausweitung schützen.

Wie bei allen PCI-Complianceanforderungen sind ein angemessenes Logging und Monitoring Ihrer Umgebung und der zugehörigen Komponenten im Geltungsbereich erforderlich, um den Geltungsbereich klar abzugrenzen. Die Ressourcenhierarchie ist untrennbar mit der Identitäts- und Zugriffsverwaltung verknüpft und zum Erzwingen und Beibehalten einer Trennung ist ein effektives Logging, Auditing und Monitoring von Nutzeraktionen erforderlich.

Netzwerksegmentierung implementieren

Die Netzwerksegmentierung ist ein wichtiges Architekturmuster, um Ihre CDE und die verbundenen Systeme zu schützen, wie im PCI-SSC-Zusatz zur Netzwerksegmentierung (PDF) erläutert. Bei einer ordnungsgemäßen Implementierung grenzt die Netzwerksegmentierung den Bewertungsbereich ein, indem sie Netzwerkrouten entfernt, über die nicht vertrauenswürdige Systeme auf Ihr CDE oder die damit verbundenen Komponenten zugreifen könnten. Definieren Sie nur die Routen, die erforderlich sind, um die Kommunikation zwischen vertrauenswürdigen Komponenten zu ermöglichen. Wenn vertrauenswürdige Systeme keine Route haben, über die Pakete von vertrauenswürdigen Systemen gesendet oder empfangen werden, befinden sich die nicht vertrauenswürdigen Systeme außerhalb des Geltungsbereichs und können die Sicherheit der Komponenten Ihres eigenen Geltungsbereichs nicht beeinflussen.

Zur Implementierung der Netzwerksegmentierung platzieren Sie Ihre CDE in einer dedizierten Virtual Private Cloud (VPC) mit aktiviertem VPC Service Controls. Erstellen Sie diese VPC im benutzerdefinierten Modus, um sicherzustellen, dass keine überflüssigen Subnetze oder Routen erstellt werden, die den Standardzugriff auf vertrauenswürdige Netzwerke ermöglichen. Implementieren Sie Einschränkungen für Organisationsrichtlinien, damit diese VPC nicht für andere Projekte freigegeben werden kann und nur mit anderen vertrauenswürdigen Netzwerken verbunden werden kann.

Das folgende Diagramm zeigt, wie Ihre Netzwerksegmentierungsstrategie eng mit Ihrer Ressourcenhierarchie zusammenhängt. Im folgenden Diagramm wird davon ausgegangen, dass eine Ressourcenhierarchie mit einem einzelnen Ordner für Ihre im PCI-Bereich enthaltene Umgebung und zwei Projekte in diesem Ordner für die CDE und freigegebene Dienste enthalten sind.

In Abbildung 5 ist das Projekt für freigegebene Dienste nicht Teil der CDE, es ist aber ein verbundenes System und fällt daher in den Geltungsbereich von PCI. Der Zugriff auf CDE wird auf Netzwerkebene vom Load-Balancer und von Firewallregeln oder Firewallrichtlinien eingeschränkt, um diese Netzwerke zu schützen und den PCI DSS-Anforderungen 1.2 und 1.3 zu genügen. Das Tokenisierungssystem und das Zahlungssystem werden in separaten Subnetzen platziert. Die Kommunikation zwischen den einzelnen Subnetzen unterliegt den einzelnen Firewallregeln, um nur die erforderliche Kommunikation zu ermöglichen. Die erforderlichen Logging-, Monitoring- und Benachrichtigungsfunktionen, um die PCI DSS-Anforderungen 10.2, 10.4 und 10.5 zu erfüllen, befinden sich in einem separaten Projekt. Die freigegebenen Dienste und die CDE befinden sich in einem VPC Service Controls-Sicherheitsperimeter, um eine versehentliche Fehlkonfiguration oder die Manipulation von IAM-Zugriffssteuerungen zu verhindern.

Wenn Ihr Deployment in Google Kubernetes Engine (GKE) erfolgt, können Sie Ihre CDE segmentieren und die Karteninhaberdaten vor nicht vertrauenswürdigen Systemen schützen:

• Namespaces bieten eine zusätzliche Ebene zur Zugriffskontrolle, mit der Nutzern nur Zugriff auf bestimmte Pods, Dienste und Deployments innerhalb Ihres Kubernetes-Clusters gewährt werden kann. Dies ist nützlich, um bestimmten Nutzern differenzierten Zugriff zu gewähren.
• Mit Netzwerkrichtlinien können Pods und Dienste voneinander isoliert werden, um Datenströme einzuschränken. Sie können außerdem eine zusätzliche Ebene der Netzwerksegmentierung in Ihrem Cluster bereitstellen.
• PodSecurity ist ein Kubernetes-Admission-Controller, mit dem Sie Pod-Sicherheitsstandards auf Pods anwenden können, die in Ihrem GKE-Cluster ausgeführt werden.

Jede dieser Ebenen bildet einen wichtigen Teil Ihrer gestaffelten Sicherheitsstrategie und hilft Ihnen, den Geltungsbereich einzuschränken, indem Sie Ihre vertrauenswürdigen Komponenten von der nahen Umgebung isolieren und zusätzlich schützen. Wenn Sie Ihre CDE vollständig oder teilweise in Kubernetes bereitstellen, lesen Sie die Informationen zum Ausführen Ihrer PCI-kompatiblen Umgebung in GKE.

Tokenisierung implementieren

Bei der Tokenisierung wird die primäre Kontonummer (Primary Account Number, PAN) verdeckt. Eine tokenisierte PAN (oder ein Token) kann nicht über mathematische Wege für eine PAN eingelöst werden. PCI-SSC bietet einen Leitfaden zu den Auswirkungen der Tokenisierung auf die Bestimmung des Geltungsbereichs, wie in Kapitel 3 der Tokenisierungsrichtlinien (PDF) erläutert. Der PCI-DSS-Geltungsbereich wird stark von den Komponenten beeinflusst, die Karteninhaberdaten speichern und übertragen. Bei einer ordnungsgemäßen Implementierung kann die Tokenisierung zur Reduzierung des Geltungsbereichs der Bewertung beitragen, da das Vorkommen und die Übertragung von primären Kontonummern minimiert werden.

Die Tokenisierung ist eine Form der Segmentierung nach Datenfluss, da sie Systeme, die Karteninhaberdaten speichern und übertragen, von denen trennt, auf denen Vorgänge nur mit Tokens ausgeführt werden können. Beispielsweise benötigen Systeme, die Nutzeraktivitäten auf Betrug analysieren, möglicherweise keine PANs, sondern können diese ebenfalls mithilfe von tokenisierten Daten durchführen. Die Vergabe von Tokens ermöglicht auch eine Trennung von Systemen, die PANs speichern und übertragen, und Ihrer E-Commerce-Webanwendung. Wenn Ihre Webanwendung nur mit Systemen interagiert, die Tokens verwenden, kann die Webanwendung aus dem Satz verbundener Systeme entfernt werden, wodurch der Geltungsbereich reduziert wird.

Das folgende Diagramm zeigt, wie CHD, eine PAN und tokenisierte Daten in einem typischen Tokenisierungssystem verarbeitet werden:

In Abbildung 6 werden eine PAN und andere Karteninhaberdaten vom Nutzer empfangen. Die Daten werden dann sofort an den Tokenisierungsdienst gesendet. Der Tokenisierungsdienst verschlüsselt die PAN, generiert ein Token und speichert dann beide in einem sicheren Token-Vault. Nur bestimmte Dienste, wie der Vergleichsdienst, können auf den Vault im Netzwerk zugreifen und eine PAN mit einem generierten Token einlösen. Der Vergleichsdienst verwendet die PAN nur, um sie an den Zahlungsabwickler zu senden. Weder die PAN noch andere Daten des Karteninhabers werden außerhalb dieses streng kontrollierten Datenflusses erhoben. Als Teil eines mehrstufigen Sicherheitskonzepts nutzt die Architektur auch den Schutz sensibler Daten als weitere Schutzschicht gegen unbeabsichtigte Datenlecks von PANs oder anderen Karteninhaberdaten.

In Abbildung 6 verwendet das Tokenisierungssystem Hashicorp Vault, einen streng geschützten Secret-Speicher, um die PAN-to-Token-Zuordnungen zu verwalten. Nur autorisierte Nutzer und Dienste können eine PAN aus einem Token mithilfe eines Lookup-Prozesses einlösen. Komponenten, die zum Zugriff auf den Token-Vault berechtigt sind, kann zeitbeschränkter Zugriff gewährt werden, sodass die Komponente nur eine PAN während des spezifischen Zeitfensters einlösen kann, das sie zum Ausführen ihrer Funktion benötigt. Außerdem können andere Datenspeicher je nach geschäftlichen Anforderungen geeignet sein. Weitere Informationen zur sicheren Implementierung der Tokenisierung in Ihrer Umgebung finden Sie unter Vertrauliche Karteninhaberdaten für PCI DSS tokenisieren.

Beispielarchitektur

Das folgende Diagramm zeigt eine Beispielarchitektur für die Verarbeitung von tokenisierten Transaktionen mit Pub/Sub und Dataflow und das Speichern von tokenisierten Transaktionsdatensätzen in Spanner.

In Abbildung 7 ist das Transaktionsverarbeitungsprojekt ein verbundenes System und liegt im PCI-Geltungsbereich. Dies ist nicht sicherheitsrelevant, da Angreifer bei der Manipulation einer Komponente im Transaktionsverarbeitungsprojekt keinen Zugriff auf CHD erhalten. Das webapp-Projekt liegt außerhalb des Geltungsbereichs, da es keine Verbindung zur CDE herstellt und nur mit bereinigten Daten interagiert.

Die tokenisierten Daten werden von der CDE an Pub/Sub gesendet. Bevor die tokenisierten Daten für andere Abonnenten veröffentlicht werden, überprüft der Schutz sensibler Daten, ob er keine CHD enthält. Tokenisierte Daten werden von Dataflow verarbeitet und in der Spanner-Transaktionsdatenbank gespeichert. Transaktionen können bestimmten Nutzern anhand von Tokens zugeordnet werden, ohne auf PANs zuzugreifen. Die Spanner-Transaktionsdatenbank kann auch für die Berichterstellung und Analyse mit Business-Intelligence-Tools (BI) wie Looker verwendet werden.

Kontinuierliche Compliance unterstützen

Sicherheit und Compliance sind mehr als eine geeignete Architektur und gutes Engineering. Eine geeignete Architektur kann zeigen, dass Ihre Umgebung in der Theorie sicher entworfen ist. Sie benötigen außerdem effektive Auditing-, Logging-, Monitoring- und Abhilfeprozesse, damit Ihre Umgebung in der Praxis sicher bleibt.

Um Compliance mit jeder der 12 PCI-DSS-Anforderungskategorien zu gewährleisten, müssen Sie Ihre Implementierung dieser Anforderung kontinuierlich überwachen. Sie müssen sich selbst und Ihrem Prüfer beweisen, dass alle Komponenten innerhalb des Geltungsbereichs auch lange nach Abschluss der PCI-DSS-Bewertung sicher sind. Eine ordnungsgemäße Aufsicht und schnelle Abhilfemaßnahmen werden als kontinuierliche Compliance bezeichnet. Eine kontinuierliche Compliance ist eine PCI-DSS-Anforderung. Durch eine ordnungsgemäße Implementierung können Sie damit die Auswirkungen der anderen Strategien zur Reduzierung des Geltungsbereichs verbessern.

Mit Google Cloud können Sie mithilfe von Firewallrichtlinien-Logs, VPC-Flow-Logs, VPC Service Controls-Logs und Cloud Load Balancing-Logs alle Vorgänge in Ihrem Netzwerk protokollieren. Mit Cloud-Audit-Logs können Sie die Aktivitäten Ihrer Systeme und Nutzer überwachen. Wenn Sie diese Logs regelmäßig überwachen, erfüllen Sie die PCI-DSS-Anforderung 10.4. Sie können somit schnell auf potenzielle Sicherheitsbedrohungen reagieren und Abhilfemaßnahmen ergreifen. Weitere Informationen finden Sie im PCI-DSS-Zusatz zur effektiven täglichen Logüberwachung (PDF).

Mit dem Security Command Center können Sie Ihre Sicherheits- und Datenangriffsfläche nachvollziehen, indem Sie Inventarisierung, Erkennung, Suche und Verwaltung von Assets bereitstellen. Security Command Center kann die Ergebnisse von Scans zum Schutz sensibler Daten analysieren, um den Verlust von Karteninhaberdaten zu erkennen und zu überprüfen, ob Ihr Tokenisierungssystem nicht dazu missbraucht wird, PANs böswillig einzulösen. Mit Event Threat Detection können Sie mit Security Command Center proaktiv Bedrohungen und ungewöhnliche Aktivitäten in Ihrem Netzwerk und auf Ihren VMs erkennen, die auf einen möglichen Angreifer hindeuten, der Ihr System prüft, um die Verteidigungsmöglichkeiten zu ermitteln. Mit Security Command Center können Sie auch benutzerdefinierte Sicherheitsquellen erstellen, die für Ihre Umgebung spezifisch sind.

Google Cloud Armor bietet zusätzlichen Schutz für Ihre öffentlich zugänglichen Google Cloud-Webanwendungen und unterstützt Sie bei der Einhaltung der PCI-DSS-Anforderung 6.4. Google Cloud Armor wertet eingehende Anfragen im Hinblick auf verschiedene gängige Webangriffe aus und hilft Ihnen, arbeitsintensive manuelle Codeprüfungen zu vermeiden, die in Anforderung 6.4 angegeben sind. Mit einem WAF-System können Sie eine kontinuierliche Compliance gewährleisten und gleichzeitig die laufenden Compliance-Kosten und -Risiken reduzieren.

Nächste Schritte

• Best Practices für die Verwaltung von Complianceverpflichtungen.
• Compliance mit dem PCI-Datensicherheitsstandard in Google Cloud
• PCI Council-Leitfaden zu Bestimmung des PCI-DSS-Geltungsbereichs und Netzwerksegmentierung (PDF)
• Blueprint PCI in GKE ausprobieren
• Kubernetes-Arbeitslasten für PCI-DSS sichern
• Vertrauliche Karteninhabern für PCI-DSS tokenisieren
• PCI Starter Terraform-Projekt bereitstellen
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center