Compliance mit dem PCI-Datensicherheitsstandard

In diesem Leitfaden erfahren Sie, wie Sie den Payment Card Industry Data Security Standard (PCI DSS) für Ihr Unternehmen in Google Cloud implementieren. Neben Hintergrundinformationen zu den Cloud-Computing-Richtlinien des PCI SSC (PDF) wird auch Ihre Rolle hinsichtlich der cloudbasierten Compliance erläutert. Außerdem erfahren Sie mehr zu den Richtlinien für die Entwicklung, Bereitstellung und Konfiguration einer Zahlungsbearbeitungsanwendung mithilfe von PCI DSS. In dieser Anleitung werden auch Methoden für Überwachung, Logging und Validierung der Anwendung beschrieben.

Der vom PCI Security Standards Council entwickelte PCI-Datensicherheitsstandard richtet sich an Unternehmen, die Daten von Kreditkarten und Debitkarten verarbeiten. Der PCI Security Standards Council umfasst alle großen Kreditkartenunternehmen. Dabei wird davon ausgegangen, dass Unternehmen, die Visa, MasterCard, Discover, American Express oder JCB akzeptieren, PCI DSS-konform sind. Wenn dies nicht der Fall ist, können sie belangt oder bestraft werden.

PCI DSS umfasst Klassifizierungen für verschiedene Händlertypen, von Händlern, die Informationen persönlich erfassen, bis hin zu Händlern, die die Zahlungsbearbeitung vollständig auslagern. In dieser Anleitung werden die Händlertypen SAQ A, SAQ A-EP und SAQ D behandelt.

Ziele

  • Prüfen der Architektur der App zur Zahlungsbearbeitung
  • Einrichten der Zahlungsbearbeitungsumgebung
  • Bereitstellen und Konfigurieren der App-Server
  • Einrichten von Logging und Monitoring
  • Validieren der Zahlungsbearbeitungsumgebung

Definitionen

In dieser Anleitung werden viele spezifische Begriffe verwendet. Die häufigsten Begriffe werden im Folgenden erläutert. Weitere Informationen finden Sie im PCI DSS-Glossar.

CDE: Akronym für Cardholder Data Environment (Umgebung für Daten von Karteninhabern). Dieses Akronym bezieht sich auf jeden Teil der App, der Daten von Karteninhabern enthält oder überträgt, einschließlich der Zahlungskontonummer oder aller personenbezogenen Daten im Zusammenhang mit der Karte.

Kompensationskontrollen: Alternative Lösungen für jede Anforderung, die der Absicht und Gründlichkeit der ursprünglichen Anforderung entsprechen und eine ähnliche Verteidigungsebene bieten. Die offizielle Definition besagt, dass Kompensationskontrollen "über die anderen PCI-DSS-Anforderungen hinausgehen" und dem zusätzlichen Risiko angemessen sein müssen, das sich aus der Nichteinhaltung der ursprünglichen Anforderung ergibt.

PAN: Akronym für Primary Account Number wird auch als Kontonummer bezeichnet. Hierbei handelt es sich um die eindeutige Kreditkartennummer, anhand derer der Aussteller und das Konto des Karteninhabers identifiziert werden.

QSA: Akronym für Qualified Security Assessor (qualifizierter Sicherheitsprüfer). QSAs werden vom PCI Security Standards Council (SSC) zur Durchführung von PCI-DSS-Prüfungen vor Ort qualifiziert. Einzelheiten zu den Anforderungen für QSA-Unternehmen und -Mitarbeiter finden Sie in den QSA-Qualifikationsanforderungen.

SAQ: Akronym für Self-Assessment Questionnaire (Fragebogen zur Selbstbewertung). Mit diesem Berichterstellungstool werden die Ergebnisse der Selbstbewertung aus der PCI DSS-Bewertung einer Entität dokumentiert.

Umfang: Die Systeme, Verfahren und Personen, die in eine PCI DSS-Bewertung einbezogen werden.

Tokenisierung: Ein Prozess, bei dem ein als Token bezeichneter Ersatzwert für die primäre Kontonummer (PAN) verwendet wird. Die PAN wird dann sicher gespeichert. Ent-Tokenisierung ist der umgekehrte Vorgang der Suche einer PAN anhand ihres Tokens. Ein Token kann entweder ein Hash oder ein zugewiesener Wert sein.

Hintergrund

PCI DSS enthält eine Liste von Anforderungen zur Verbesserung der Sicherheit von Karteninhabern. Diese Anforderungen sind in zwölf große nummerierte Abschnitte und viele Unterabschnitte untergliedert. Dieses Dokument verweist auf diese Abschnittsnummern, um Kontext hinzuzufügen, die Abschnittsverweise sind jedoch keine vollständige Liste der geltenden Anforderungen.

Die PCI DSS-Konformitätsanforderungen hängen davon ab, wie Ihr Unternehmen Transaktionen mit Zahlungskarten (Typ) abwickelt und wie viele Transaktionen jedes Jahr (Ebene) durchgeführt werden.

Mit der wachsenden Anzahl von Transaktionen wächst auch die PCI DSS-Händlerebene. Je höher die Händlerebene, desto strenger werden die PCI DSS-Compliancerichtlinien. Auf der höchsten Händlerebene, Ebene 1, schreibt der PCI DSS ein obligatorisches Audit vor. Die Ebenen variieren je nach Kartenmarke. Ebene 1 wird von American Express mit 2,5 Millionen Transaktionen pro Jahr und von Visa, Mastercard und Discover mit 6 Millionen jährlichen Transaktionen definiert. Jede Kartenmarke hat zusätzliche Ebenenanforderungen, die im vorliegenden Dokument nicht behandelt werden. Die Zahlungsbearbeitungsumgebung muss für Ihre Händlerebene auditiert sein.

Da Google Cloud ein PCI DSS 3.2.1-kompatibler Dienstanbieter der Ebene 1 ist, kann sie Ihre PCI DSS-Compliance-Anforderungen unabhängig von der Händlerebene Ihres Unternehmens unterstützen. Im Abschnitt Der Compliance verpflichtet wird angegeben, welche Bereiche von Google abgedeckt werden.

Die andere grundlegende Variable ist Ihr SAQ-Typ. Das SAQ beschreibt Kriterien, die Sie erfüllen müssen, um PCI DSS zu entsprechen. Der SAQ-Typ wird durch Ihre Anwendungsarchitektur und der genauen Verarbeitungsart von Zahlungskartendaten ab. Die meisten Händler in der Cloud gehören einem der folgenden Typen an:

SAQ-Typ Beschreibung
A Händler, die alle Bezahlprozesse an eine Drittanbieter-Site ausgelagert haben. Kunden verlassen Ihre Domain (z. B. über ein <iframe>-Webformular), schließen die Zahlung ab und kehren dann zu Ihrer App zurück.

Ihr Unternehmen kommt somit in keinster Weise mit Kundenkartendaten in Berührung.
A-EP Händler, die alle Zahlungsprozesse an einen Drittanbieter auslagern, aber an jedem Punkt des Prozesses auf Kundendaten zugreifen können. Dazu zählen auch von Händlern gesteuerte Seitenelemente wie JavaScript oder CSS, die in die Zahlungsseite des Drittanbieters eingebettet sind.

Das heißt, Ihre Zahlungsbearbeitungs-App leitet Kartendaten an einen Abwickler auf Clientseite weiter oder der Abwickler rendert von Ihnen gehostete Inhalte.
D Händler, die Zahlungen online akzeptieren und nicht für SAQ A oder SAQ A-EP qualifiziert sind. Dieser Typ umfasst alle Händler, die unabhängig von der Tokenisierung eine Zahlungsabwickler-API von ihren eigenen Servern aus aufrufen.

Das heißt, wenn Sie nicht dem Typ SAQ A oder SAQ A-EP zugewiesen sind, gehören Sie dem Typ SAQ D an.

SAQ D unterscheidet zwischen Händlern und Dienstanbietern. Dienstanbieter werden in diesem Dokument nicht behandelt, und alle SAQ D-Verweise gelten für Händler wie in PCI DSS definiert.
Venn-Diagramm der SAQ-Anforderungen. SAQ A-EP ist eine Obermenge von SAQ A und SAQ D ist eine Obermenge von SAQ A-EP.
Venn-Diagramm der SAQ-Anforderungen. SAQ A-EP ist eine Obermenge von SAQ A und SAQ D ist eine Obermenge von SAQ A-EP.

Händler können einer beliebigen Kombination aus Ebene und Typ entsprechen und Ihre Complianceanforderungen können je nach Situation sehr unterschiedlich sein.

Der Einhaltung verpflichtet

Google verwendet eine Vielzahl von Technologien und Verfahren zum Schutz von Informationen, die auf Google-Servern gespeichert sind. Google hat die PCI DSS-Anforderungen, die für von Google verwaltete Google Cloud-Technologien und -Infrastruktur gelten, unabhängig validiert. Obwohl Google Händlern eine umfassende Kontrolle über ihre Recheninstanzen bietet, die die Google-Infrastruktur nutzen, kontrolliert Google nicht die Sicherheit für das Betriebssystem, die Pakete oder Apps, die Händler in Google Cloud bereitstellen. Es liegt in Ihrer Verantwortung, die PCI DSS-Anforderungen für Betriebssystempakete und -Apps zu erfüllen, die Sie zusätzlich zu anderen Anpassungen bereitstellen, die für Ihre Architektur erforderlich sind.

Google Cloud erfüllt die PCI DSS-Anforderungen für Dienstanbieter der Ebene 1 und alle geltenden Anforderungen an Dienstanbieter. In der Matrix für geteilte Verantwortung der Google Cloud werden die Compliance-Anforderungen von PCI DSS beschrieben. Die Verantwortungsmatrix kann in Bezug auf die Einhaltung der PCI DSS-Compliance und die Durchführung eigener PCI DSS-Audits eine hilfreiche Referenz sein.

Produktspezifische Anleitung

App Engine

Firewall-Regeln für eingehenden App Engine-Traffic sind verfügbar, Regeln für ausgehenden Traffic liegen derzeit jedoch nicht vor. Gemäß den Anforderungen 1.2.1 und 1.3.4 muss der gesamte ausgehende Traffic autorisiert sein. Händler vom Typ SAQ A-EP und SAQ D müssen Kompensationskontrollen bereitstellen oder ein anderes Google Cloud-Produkt verwenden. Compute Engine und GKE sind die bevorzugten Alternativen.

Cloud Functions

Ähnlich wie App Engine unterstützt Cloud Functions derzeit keine Firewallregeln für ausgehenden Traffic. Händler vom Typ SAQ A-EP und SAQ D müssen Kompensationskontrollen bereitstellen oder ein anderes Google Cloud-Produkt verwenden. Compute Engine und GKE sind die bevorzugten Alternativen.

Google Kubernetes Engine

Gehen Sie bei den Knoten und Pods in einem GKE-Cluster auf die gleiche Weise wie bei einem von einem Händler verwalteten Server vor. Implementieren Sie Logging, Instrumentierung und Patching auf Knoten- und Pod-Ebene. Speichern Sie die Daten von Karteninhabern nicht auf der Knotenebene. Die Knoten müssen aber trotzdem den Vorgaben entsprechen, falls sie Pods enthalten bzw. enthalten können, die unter die Vorgaben fallen.

Den Zugriff auf Ihre Steuerungsebene (Clustermaster) können Sie durch autorisierte Netzwerke einschränken, um nicht vertrauenswürdige IP-Adressen von außerhalb der Google Cloud zu blockieren. Diese CIDR-Regeln sind mit privaten Clustern kompatibel und dienen als eine weiße Liste (auch Whitelist genannt).

Implementieren Sie Netzwerkrichtlinien im GDE-Cluster, wenn Ihre den Vorgaben entsprechenden Projekte unterschiedliche Arten von Pods enthalten. Netzwerkrichtlinien funktionieren ähnlich wie VPC-Firewalls (Virtual Private Cloud), mit denen Sie möglicherweise bereits vertraut sind. Sie können Traffic basierend auf IP-Regeln oder Labels zulassen oder verweigern.

In der Anforderung 2.2.1 ist festgelegt, dass pro Server nur eine primäre Funktion implementiert werden kann. Gemäß dieser Anforderung ist es zulässig, dass von einem einzelnen GKE-Cluster mehrere Pod-Typen gehostet werden. Die Hauptfunktion von GKE-Knoten besteht darin, Container bereitzustellen und zu verwalten. Bei optimaler Konzeption können einzelne Pods diese primäre Funktionsregel auch in einem einzelnen Cluster einhalten.

Cloud Storage

In der Anforderung 3.4 ist festgelegt, dass ein PAN an keinem Speicherort lesbar sein darf. Obwohl Google die automatische Verschlüsselung inaktiver Daten anbietet, werden keine automatischen unidirektionalen Hashes, Kürzungen oder Tokenisierungen durchgeführt, die die Regeln ebenfalls erfordern.

Beispielarchitekturen

In diesem Abschnitt werden die Ansätze zum Implementieren einer Umgebung erläutert, die SAQ A, SAQ A-EP und SAQ D entspricht.

Überblick über die Architektur

SAQ A

SAQ A ist die einfachste Zahlungsbearbeitungsarchitektur. Zahlungen werden von einem Drittanbieter bearbeitet und von Händler-Apps oder -seiten werden keine Kartendaten abgerufen.

Auf einer hohen Ebene stellt sich der Zahlungsbearbeitungsfluss so dar:

  1. Der Kunde trifft seine Auswahl und fährt mit dem Checkout fort.

  2. Die Checkout-App leitet den Kunden an einen externen Zahlungsabwickler weiter.

  3. Der Kunde gibt seine Zahlungskartendaten in ein Zahlungsformular ein, das dem externen Zahlungsabwickler gehört und von diesem verwaltet wird.

  4. Der externe Zahlungsabwickler prüft die Zahlungskartendaten und belastet dann die Karte oder lehnt sie ab.

  5. Nach der Transaktionsverarbeitung leitet der externe Zahlungsabwickler den Kunden zusammen mit den Transaktionsdetails an die Händleranwendung zurück.

  6. Die Händleranwendung sendet eine Bestätigungsanfrage an den Zahlungsabwickler, um die Transaktion zu bestätigen.

  7. Der Zahlungsabwickler antwortet, um die Transaktionsdetails zu überprüfen.

Informationen zwischen dem Browser des Kunden, der Website des Händlers, dem Zahlungsabwickler und dem Zahlungsgateway verarbeiten.
Architektur einer Umgebung für externe Zahlungsabwickler gemäß SAQ A.

SAQ A-EP

Die Zahlungsbearbeitungsarchitektur von SAQ A-EP ist um eine App zur Zahlungsbearbeitung aufgebaut, die auf Compute Engine-VM-Instanzen ausgeführt wird. Diese Instanzen sind innerhalb eines sicheren privaten Netzwerks enthalten und verwenden sichere Kanäle zur Kommunikation mit Diensten außerhalb dieses Netzwerks.

Auf einer hohen Ebene stellt sich der Zahlungsbearbeitungsfluss so dar:

  1. Der Kunde gibt seine Zahlungskartendaten in ein Zahlungsformular ein, das Ihrem Unternehmen gehört und von diesem verwaltet wird.

  2. Die vom Kunden im Formular angegebenen Informationen werden auf sicherem Weg an einen externen Zahlungsabwickler übergeben.

  3. Der externe Zahlungsabwickler prüft die Zahlungskartendaten und belastet dann die Karte oder lehnt sie ab.

  4. Der Zahlungsabwickler sendet eine Antwort an die Zahlungsanwendung zurück, die dann eine Nachricht an Ihre Kernanwendung sendet.

Alle diese Interaktionen werden mit Cloud Logging und Cloud Monitoring in Logs erfasst und überwacht.

Architektur einer SAQ A-EP-Zahlungsbearbeitungsumgebung
Architektur einer SAQ A-EP-Zahlungsbearbeitungsumgebung

SAQ D

Die Zahlungsbearbeitungsarchitektur von SAQ D ist um eine App zur Zahlungsbearbeitung aufgebaut, die auf Google Compute Engine-VM-Instanzen ausgeführt wird. Diese Instanzen befinden sich in einem sicheren privaten Netzwerk und verwenden sichere Kanäle für die Kommunikation mit Diensten außerhalb des Netzwerks.

Auf einer hohen Ebene stellt sich der Zahlungsbearbeitungsfluss so dar:

  1. Der Kunde gibt seine Zahlungskartendaten in ein Zahlungsformular ein, das Ihrem Unternehmen gehört und von diesem verwaltet wird.

  2. Die vom Kunden in das Formular eingegebenen Informationen werden an die Zahlungsanwendung gesendet.

  3. Die Zahlungsanwendung überprüft die Zahlungsinformationen und leitet sie über eine Back-End-API sicher an einen externen Zahlungsabwickler weiter.

  4. Der externe Zahlungsabwickler prüft die Zahlungskartendaten und belastet dann die Karte oder lehnt sie ab.

  5. Der Zahlungsabwickler sendet eine Antwort an die Zahlungsanwendung zurück, die dann eine Nachricht an Ihre Kernanwendung sendet.

Alle diese Interaktionen werden mithilfe von Logging und Monitoring in Logs erfasst und überwacht.

Architektur einer SAQ D-Zahlungsbearbeitungsumgebung
Architektur einer SAQ D-Zahlungsbearbeitungsumgebung

Kundenseitiger Fluss der Zahlungsbearbeitung

SAQ A

In diesem Abschnitt wird der Fluss der Zahlungsbearbeitung durch Drittanbieter aus der Perspektive der Kunden beschrieben, die Ihre App verwenden.

Kundenseitiger Fluss der SAQ A-Zahlungsbearbeitung durch Drittanbieter
Kundenseitiger Fluss der externen SAQ A-Zahlungsbearbeitung

Wenn der Kunde auf Ihr Zahlungsformular zugreift, wird in der App ein <iframe> angezeigt, das vom Zahlungsabwickler gehostet wird. Ihre App kann aufgrund von Einschränkungen beim Cross-Origin Resource Sharing nicht auf den Inhalt von <iframe> zugreifen oder diesen überwachen. Wenn der Kunde seine Zahlungskartendaten sendet, akzeptiert der Zahlungsabwickler die Karte oder lehnt sie ab und sendet den Kunden zurück zu Ihrer App. Diese prüft dann die Transaktionsantwort des Zahlungsabwicklers und handelt entsprechend. Die App hat weder auf Zahlungskartendaten zugegriffen noch diese verarbeitet.

SAQ A-EP

In diesem Abschnitt wird der gleiche interne Zahlungsbearbeitungsfluss erläutert wie weiter oben, jedoch aus der Sicht der Kunden, die Ihre App verwenden.

Kundenseitiger Fluss der SAQ A-EP-Zahlungsbearbeitung durch Drittanbieter
Kundenseitiger Fluss der SAQ A-EP-Zahlungsbearbeitung durch Drittanbieter

Wenn der Kunde auf die URL für Ihr Zahlungsformular zugreift, wird auf der Website ein von Ihrer Zahlungs-App gehostetes Formular angezeigt. Wenn der Kunde seine Zahlungskartendaten sendet, wird das Formular direkt an den Zahlungsabwickler weitergeleitet. Der Zahlungsabwickler akzeptiert oder lehnt die Karte ab und leitet den Kunden dann zurück zu Ihrer App. Ihre App prüft dann die Transaktionsantwort des Zahlungsabwicklers und handelt entsprechend. Der Kunde kann den externen Zahlungsabwickler möglicherweise nicht sehen, aber Ihre App hat auf keine serverseitigen Zahlungskartendaten zugegriffen.

SAQ D

In diesem Abschnitt wird der interne Fluss der Zahlungsbearbeitung aus der Perspektive der Kunden beschrieben, die Ihre App verwenden.

Kundenseitiger Fluss der SAQ D-Zahlungsbearbeitung durch Drittanbieter
Kundenseitiger Fluss der SAQ D-Zahlungsbearbeitung durch Drittanbieter

Wenn der Kunde die URL für das Zahlungsformular aufruft, wird er über einen HTTPS-Load-Balancer sicher zu dem Formular weitergeleitet. Wenn der Kunde seine Zahlungskartendaten einreicht, sendet die Zahlungsbearbeitungs-App die Informationen sicher an einen externen Zahlungsabwickler. Der externe Zahlungsabwickler akzeptiert die Karte oder lehnt sie ab und gibt dann eine Antwort an die Zahlungsbearbeitungs-App zurück.

Interner Zahlungsbearbeitungsfluss

SAQ A & A-EP

In diesem Abschnitt wird der Zahlungsbearbeitungsfluss aus der Perspektive der Server beschreiben, auf denen Ihre App ausgeführt wird.

Interner SAQ A- und SAQ A-EP-Fluss
Interner SAQ A- und SAQ A-EP-Fluss

Ihre Zahlungsbearbeitungs-App empfängt und analysiert die vom externen Zahlungsabwickler zurückgegebene Antwort und sendet dann einige oder alle Antwortdaten an die Kern-App. Die Transaktion zur Zahlungsbearbeitung ist nun abgeschlossen. Die Kern-App übernimmt die Aufgabe, Ihre Kunden zu benachrichtigen.

SAQ D

In diesem Abschnitt wird der interne Zahlungsbearbeitungsfluss aus der Perspektive der Server beschrieben, auf denen Ihre App ausgeführt wird.

Interner SAQ D-Fluss
Interner SAQ D-Fluss

Ihre Zahlungsbearbeitungs-App validiert die vom Kunden gesendeten Zahlungskartendaten und leitet sie über eine Back-End-API an den Zahlungsabwickler weiter. Der Auftragsverarbeiter versucht die Belastung und antwortet mit Transaktionsdetails. Ihre App empfängt und verarbeitet die Antwort und sendet dann einige oder alle Antwortdaten an die Kern-App. Die Transaktion zur Zahlungsbearbeitung ist nun abgeschlossen. Die Kern-App übernimmt nun die Benachrichtigung des Kunden und die Bereitstellung des Produkts.

Monitoring- und Logging-Datenfluss

Der Monitoring- und Logging-Fluss ist so aufgebaut:

Monitoring- und Logging-Fluss
Monitoring- und Logging-Fluss

Zahlungsbearbeitungsumgebung einrichten

In diesem Abschnitt wird die Einrichtung der Zahlungsbearbeitungsumgebung beschrieben. Die Einrichtung umfasst Folgendes:

  • Erstellen eines neuen Google Cloud-Kontos, um die Zahlungsbearbeitungsumgebung von der Produktionsumgebung zu isolieren
  • Begrenzen des Zugriffs auf Ihre Umgebung
  • Einrichten der virtuellen Ressourcen
  • Entwerfen des Linux-Basis-Images, das Sie zum Einrichten der Anwendungsserver verwenden
  • Implementieren einer sicheren Paketverwaltungslösung

Neues Konto einrichten

Erstellen Sie zur Vereinfachung der Zugriffsbeschränkung und der Complianceprüfung eine Zahlungsbearbeitungsumgebung in Produktionsqualität, die vollständig von Ihrer Standardproduktionsumgebung und allen Entwicklungs-/QA-Umgebungen isoliert ist (Anforderung 6.4.1). Erstellen Sie ein Google Cloud-Konto, das von Ihrem Konto der Kernproduktionsumgebung getrennt ist, und verwenden Sie es, um die Isolierung zu garantieren. Nutzer, die mit der IAM-Konfiguration (Identitäts- und Zugriffsverwaltung) vertraut sind, können eine gleichwertige Isolierung durch die Verwendung separater Projekte für Arbeiten erreichen, die den Vorgaben entsprechen.

Begrenzung des Zugriffs auf Ihre Umgebung

Erlauben Sie den Zugriff auf die Zahlungsbearbeitungsumgebung nur solchen Personen, die den Code für Ihr Zahlungssystem bereitstellen oder die zugehörigen Computer verwalten (Abschnitt 7.1 und Anforderung 8.1.1). Dies wird auch als Grundsatz der geringsten Berechtigung bezeichnet. Mit IAM-Rollen können Sie den Zugriff einschränken. Zu den Best Practices gehört, dass nach Möglichkeit Rollen verwendet werden, dass nur die Berechtigungen gewährt werden, die für die Ausführung der erwarteten Arbeit erforderlich sind, und dass die Rolle "Inhaber" nur den Mitgliedern zugewiesen wird, die vollständigen Root-Zugriff auf Ihre Dienste benötigen. Weitere Informationen finden Sie im IAM-Sicherheitsleitfaden.

Der automatisierte Zugriff auf einen verwalteten Dienst sollte auf Dienstkonten basieren. Dienstkonten vereinfachen den Lebenszyklus der App-Verwaltung. Dabei erhalten Sie die Möglichkeit, die Authentifizierung und Autorisierung der App zu verwalten. Diese Konten bieten Ihnen eine flexible und sichere Möglichkeit, VM-Instanzen mit ähnlichen Apps und Funktionen zu gruppieren, die eine gemeinsame Identität haben. Sie können die Sicherheits- und Zugriffssteuerung auf Dienstkontoebene durch IAM-Rollen und VPC-Firewallregeln erzwingen.

IAM-Regeln, die Sie auf Ordner anwenden, werden von allen in diesem Ordner enthaltenen Elementen übernommen. Standardberechtigungen sind "Alle ablehnen" (Anforderung 7.2.3), und jede Regel, die Sie anwenden, fügt nur Berechtigungen hinzu.

Anforderung 8.2.3 enthält einige grundlegende Regeln für Nutzerpasswörter. Das National Institute of Standards and Technology (NIST) definiert in Abschnitt 5.1.1 von NIST SP800-63B sicherere Passwörter. Google empfiehlt, wenn möglich die Richtlinien zur NIST Digital Identity einzuhalten.

Gemäß Abschnitt 12.7 von PCI DSS SAQ D müssen Personen, die Zugriff auf Ihre Umgebung haben, eine Zuverlässigkeitsprüfung gemäß der örtlichen Gesetzgebung durchlaufen, bevor ihnen Zugriff auf die Umgebung gewährt wird. Zur Verringerung des Risikos von Complianceverstößen sollten diese Zuverlässigkeitsprüfungen und Prüfungen auf Referenzen für jede Person unabhängig vom Compliancetyp erfolgen.

Netzwerk sichern

Sie müssen Folgendes erstellen, um den ein- und ausgehenden Traffic des Netzwerks Ihrer Zahlungsbearbeitungs-App zu sichern:

  • Compute Engine-Firewallregeln
  • Compute Engine-VPN-Tunnel (Virtual Private Network)
  • HTTPS-Load-Balancer für Compute Engine

Für die Erstellung Ihrer VPC empfehlen wir als zusätzliche Netzwerksicherheitsebene Cloud NAT. Zum Schutz der Netzwerke von Compute Engine- und GKE-Instanzen können Sie aus zahlreichen leistungsfähigen Optionen wählen.

Firewallregeln erstellen

Verwenden Sie Firewallregeln, um eingehenden Traffic auf jeder Ihrer Compute Engine-Instanzen zu beschränken (Anforderungen 1.2.1 und 1.3.2). Lassen Sie eingehenden Traffic nur von den folgenden drei Quellen zu:

  • Öffentliches HTTPS, damit Kunden Ihre Zahlungsseite aufrufen können
  • Ihr Anwendungsnetzwerk, damit die Zahlungsbearbeitungsanwendung Antworten vom externen Zahlungsabwickler empfangen kann
  • Ihr internes Büronetzwerk, damit Sie zu Prüfungs- und Verwaltungszwecken auf die Instanzen zugreifen können

Verwenden Sie Firewallregeln für einzelne Instanzen, um ausgehenden Traffic zu beschränken. Sie können diese Regeln lokal mit iptables oder allgemeiner mit VPC-Firewallregeln und Netzwerk-Tags implementieren. Erlauben Sie nur ausgehenden Traffic von Ihrem Zahlungsformular an den externen Zahlungsabwickler. Diese Verbindung muss eine Nur-HTTPS-Verbindung sein. Wie Sie Ihre Arbeit testen, erfahren Sie weiter unten im Abschnitt "Firewallregel-Logging aktivieren".

Cloud DNS bietet private DNS-Zonen, sodass Sie Hosts in der CDE sicher benennen können, ohne Gefahr zu laufen, dass vertrauliche Daten zur Netzwerktopologie offengelegt werden.

Beschränken Sie den Datenverkehr so:

Quelle Ziel Port Richtung und Grund
Öffentlicher Load-Balancer Zahlungsformular des externen Zahlungsabwicklers tcp:443 Eingehend
Öffentlicher Zugriff auf die Zahlungsbearbeitungs-App
Zahlungsformular des externen Zahlungsabwicklers Externer Zahlungsabwickler tcp:443 Ausgehend
Weiterleitung von AUTH-Anfragen an den Zahlungsdienstanbieter
Externer Zahlungsabwickler Ihre Zahlungsbearbeitungs-App tcp:5480 Eingehend
Annahme von AUTH-Anfragen von Zahlungssystemen (enthält keine Karteninhaberdaten)
Büronetzwerk Ihres Unternehmens VPN-Gateway tcp:8000 Eingehend
Zugriff auf die Zahlungsbearbeitungsumgebung für den Zugriff auf Logs und Entwicklungsmaschinen

Außerdem wird der folgende Traffic sicher innerhalb des internen Netzwerks der Zahlungsbearbeitungs-App abgewickelt:

Quelle Ziel Port Grund
Kartenformular PCI-Proxy tcp:5480 Austausch von verschlüsselten Kartendaten für Zahlungsmitteltoken
Alle Hosts Google NTP-Server udp:123 Zeitsynchronisierung
VPN-Gateway Alle Hosts tcp:22 SSH-Verbindungen (Secure Shell)

Sicheren VPN-Tunnel einrichten

Compute Engine stellt einen VPN-Dienst bereit, mit dem Sie einen sicheren VPN-Tunnel zwischen Ihrer lokalen Umgebung und Ihrer Zahlungsbearbeitungsumgebung einrichten können (Abschnitte 2.3 und 4.1).

HTTPS-Lastenausgleichsmodul erstellen

Durch die Erstellung eines HTTP(S)-Lastenausgleichsmoduls in Compute Engine können Sie dazu beitragen, dass eingehender Kundentraffic sicher ist (Abschnitte 2.3 und 4.1). Für das Erstellen eines HTTPS-Load-Balancers benötigen Sie Folgendes:

  • Eine Subdomain Ihrer Website, die für Ihr Zahlungsbearbeitungsformular verwendet wird, z. B. payments.your-domain-name.com.
  • Ein gültiges, signiertes SSL-Zertifikat, das für Ihre Subdomain registriert wurde

Sorgen Sie durch die Überprüfung der DNS-Einstellungen in der Konfigurationsoberfläche der Domain des Webregistrators dafür, dass Ihre Domain gültig ist.

Basis-Linux-Image erstellen

Der PCI DSS enthält Anforderungen, in denen die Einrichtung von Computern beschrieben wird, die Teil einer konformen Zahlungsbearbeitungsarchitektur sind. Sie können diese Anforderungen auf verschiedene Arten implementieren. Die folgende Lösung ist jedoch die einfachste:

  1. Erstellen Sie eine Liste der Software und Bibliotheken, die auf jedem Server installiert werden müssen, der unter die Vorgaben für Ihre Zahlungsbearbeitungsanwendung fällt. Verwenden Sie nur die Software und Bibliotheken, die Sie zum Ausführen der Anwendung benötigen, um unnötige Sicherheitslücken im System zu vermeiden (Anforderung 2.2.2). Dazu können Cloud SDK, sprachspezifische Laufzeiten und Bibliotheken oder ein Webserver gehören.

  2. Erstellen Sie eine Compute Engine-Instanz, die eins der in Compute Engine vorkonfigurierten Betriebssystem-Images verwendet.

  3. Installieren Sie die Bibliotheken und die Software, die vorher aufgeführt wurden.

  4. Installieren und konfigurieren Sie ntp, um die Systemuhren synchron zu halten. Durch die Verwaltung von Serveruhren mit dem NTP (Network Time Protocol) gewährleisten Sie die Integrität von Zeitstempeln in Logs (Abschnitt 10.4).

  5. Das Image muss den Best Practices für das Erstellen eines sicheren Compute Engine-Images entsprechen (gesamter Abschnitt 2.2).

  6. Nachdem Sie das Basis-Image konfiguriert haben, erstellen Sie ein benutzerdefiniertes Compute Engine-Laufwerks-Image anhand Ihres Images. Mit diesem Image können Sie zum Erstellen von VM-Instanzen Ihr Linux-Basis-Image verwenden.

Sichere Paketverwaltung verwenden

Paketverwaltung ist eine wichtige Komponente einer sicherheitsoptimierten Hosting-Umgebung. Gemäß Abschnitt 2.2 müssen Sie branchenübliche Optimierungsstandards implementieren. Sofern Sie kein Container-optimiertes Betriebssystem von Google verwenden, ist wahrscheinlich ein Paketmanager wie RPM, Yum oder Apt installiert. Die App verwendet möglicherweise einen eigenen programmiersprachenspezifischen Paketmanager wie NPM, PyPi oder Composer und lädt Abhängigkeiten beim ersten Start herunter.

Wenn die App Updates aus dem Internet abrufen kann, müssen Sie Updatequellen als potenzielles Sicherheitsrisiko behandeln. Versorgungs- oder Upstream-Angriffe, die böswillig in öffentlich gehosteten Paketen enthalten sind, werden immer häufiger. Stellen Sie sich die Auswirkungen der Installation eines Updates für SSH vor, das schädlichen Code enthält.

Sie können das Risiko von lieferseitigen Angriffen minimieren. Erstellen Sie dazu eine Liste mit sicheren Empfängern für Ihre Pakete und überprüfen Sie, ob sie mit der Liste übereinstimmen. Führen Sie eine Liste der getesteten und genehmigten Versionsnummern für jedes verwendete Paket. Notieren Sie die Versionsnummer zusammen mit dem Hash oder der Signatur. Der Paketmanager muss den Hash oder die Signatur vor dem Installieren oder Aktualisieren einer App überprüfen.

Die meisten Paketverwaltungssysteme ermöglichen privates Hosting. Starten Sie nach Möglichkeit Ihren eigenen privaten Paketverwaltungsserver und hosten Sie nur geprüfte und genehmigte Software. Sperren Sie den Paketmanager, damit er nicht auf andere Server für Updates zugreifen kann.

Im Idealfall ruft der App-Build-Prozess alle Pakete ab und überprüft sie. Anschließend erstellt er eine Überarbeitung des benutzerdefinierten Laufwerks-Images, das alles enthält, was der Container benötigt. Auf diese Weise starten und skalieren Ihre Server ohne Installationsverzögerung und die Wahrscheinlichkeit zufälliger Fehler beim Starten ist geringer. Sie können auch jede frühere Version der App genau wie in der Produktion aufrufen. Dazu starten Sie einfach ihr Image, was für die Diagnose und Forensik hilfreich sein kann.

Bereitstellung und Konfiguration

Als Nächstes richten Sie die Bereitstellung und die Konfiguration der Instanzen anhand des Basis-Images ein.

Umgebung bereitstellen

Sorgen Sie entsprechend den PCI DSS-Anforderungen dafür, dass Sie jedes Mal die richtige App sicher bereitstellen und während der Bereitstellung keine anderen Softwarepakete installieren. Wenn Sie den Bereitstellungsprozess vereinfachen möchten, können Sie eine automatisierte Bereitstellung für die Anwendung mit Cloud Deployment Manager erstellen.

Mit Deployment Manager können Sie die gesamte Zahlungsbearbeitungsumgebung beschreiben, einschließlich der Firewallregeln, Gateways, Load-Balancer und Instanzen. Deployment Manager kann Ihnen auch dabei helfen, einen Audit-Trail zu erstellen, der zeigt, wie jede Anwendungsumgebung erstellt wurde. Außerdem können Sie damit Umgebungen versionieren, wenn Sie diese verbessern und ändern.

In einer automatisierten Bereitstellung müssen Sie die Integrität der bereitgestellten Software prüfen, und zwar unabhängig davon, ob sie von einem Drittanbieter oder Ihnen selbst stammt. Sie können zum Überprüfen Ihrer Software einen automatisierten Hash für jedes Paket während dessen Installation ausführen. Nach Überprüfung des Hash können Sie ein automatisiertes Testframework zur Ausführung von Sicherheits- und anderen Tests verwenden. Mit diesem Framework können Sie auch prüfen, ob die Tests erfolgreich waren.

Schließlich müssen Sie bei der Bereitstellung von Compute Engine-Instanzen einen Wiederherstellungsplan entwickeln, falls bei den Instanzen Fehler auftreten. Wenn das Fenster für eine zulässige Ausfallzeit groß genug ist, reicht ein manueller Wiederherstellungsplan gegebenenfalls aus. Andernfalls müssen Sie einen automatisierten Wiederherstellungsplan entwickeln. Weitere Informationen finden Sie im Leitfaden zur Planung der Notfallwiederherstellung sowie in den Anleitungen zum Konzipieren robuster Systeme und zum Erstellen skalierbarer und robuster Webanwendungen.

Umgebung konfigurieren

Nachdem die Instanzen bereitgestellt wurden, müssen sie ordnungsgemäß konfiguriert werden. Installieren Sie nach Bedarf zusätzliche Software und Bibliotheken auf dem Basis-Image jeder Instanz. Wenn Sie ein Tool für automatisierte Konfigurationsverwaltung, z. B. Skaffold, Chef, Puppet, Ansible oder Salt verwenden, können Sie die Komplexität, den Aufwand und das Risiko einer manuellen Konfiguration vermeiden.

Lieferkettenangriffe auf Upstream-Quellen werden immer mehr zum Problem. Daher können Sie neben der Verwendung von Basis-Linux-Images ein Tool wie die Grafeas-API verwenden, um Upstream-Code zu überprüfen.

Forseti Security implementieren

Forseti Security ist eine Sammlung von Community-basierten Open-Source-Tools, mit denen Sie die Sicherheit Ihrer Google Cloud-Umgebungen verbessern können. Dank der modularen Architektur können Sie Komponenten individuell aktivieren und damit zum Teil auch spezielle PCI DSS-Anforderungen erfüllen.

Inventory erstellt einen Inventar-Snapshot Ihrer Google Cloud-Ressourcen, sodass Sie eine Verlaufsaufzeichnung Ihrer Architektur haben.

Scanner verwendet die von Forseti Inventory erfassten Informationen, um regelmäßig rollenbasierte Zugriffsrichtlinien für Ihre Google Cloud-Ressourcen zu vergleichen. Scanner wendet Regeln an, um Google Cloud-Ressourcen wie die folgenden zu prüfen:

  • IAM-Richtlinien (Identitäts- und Zugriffsverwaltung) für Organisationen, Ordner und Projekte
  • Bucket-ACLs
  • BigQuery-Dataset-ACLs
  • Für Cloud SQL autorisierte Netzwerke

Mit Scanner können Sie angeben, welche Nutzer, Gruppen und Domains zulässige, erforderliche oder von Ressourcen ausgeschlossene sind. Außerdem gewährleisten Sie die Konsistenz dieser Zugriffsrichtlinien. Wenn Scanner Zugriffsrichtlinien findet, die nicht den Scanner-Regeln entsprechen, können Informationen zu diesen Regelverstößen in Cloud SQL oder Cloud Storage gespeichert werden. Dies trägt zum Schutz vor unsicheren oder unbeabsichtigten Änderungen bei.

Enforcer vergleicht anhand der von Ihnen erstellten Richtlinien den aktuellen Status Ihrer Compute Engine-Firewall mit einem festgelegten Status. Enforcer ist ein On-Demand-Befehlszeilentool, das Richtlinien im Batchmodus wahlweise mit allen verwalteten Projekten oder nur mit ausgewählten Projekten vergleicht. Wenn Enforcer Richtlinienunterschiede feststellt, verwendet es Google Cloud APIs, um Änderungen vorzunehmen und die Ausgabe der Ergebnisse anzuzeigen.

Das Add-on-Modul Explain bietet Einblick in Ihre IAM-Richtlinien. Explain liefert folgende Informationen:

  • Wer Zugriff auf welche Ressourcen hat und wie der jeweilige Nutzer mit der Ressource interagieren kann
  • Warum ein Hauptnutzer Berechtigungen für eine Ressource hat bzw. warum nicht und wie dies behoben werden kann
  • Welche Rollen eine Berechtigung gewähren und welche Rollen nicht mit den zuletzt vorgenommenen Änderungen synchron sind

Für Inventory und Scanner können Sie E-Mail-Benachrichtigungen konfigurieren.

Unveränderliches Audit-Logging implementieren

Logging erstellt automatisch Audit-Logs für eine Vielzahl von Aktivitäten in vielen Produkten. Langfristig können Sie unveränderliche Logs mithilfe von Cloud Storage-Bucket-Sperren (Abschnitt 10.5) sicher speichern. Anhand von Bucket-Sperren können Sie eine Richtlinie festlegen, mit der alle Objekte für einen bestimmten Zeitraum (von Sekunden bis Jahren) als unveränderlich und nicht löschbar festgelegt werden. Wenn Sie Zugriff auf das Early Access-Programm benötigen, wenden Sie sich an Ihren Google Cloud-Ansprechpartner.

Fluss-Logs in der Virtual Private Cloud implementieren

Mit VPC-Fluss-Logs wird eine Stichprobe der von VM-Instanzen gesendeten oder empfangenen Netzwerkflüsse erfasst. Sie können diese Logs zur Netzwerküberwachung (Abschnitt 10.2), Forensik (Anforderung 10.6.3) und Echtzeit-Sicherheitsanalyse verwenden.

Logging-Agent installieren

Nachdem Sie iptables auf den Servern eingerichtet haben, protokolliert jeder Server jede Aktivität im Blockspeicher des Servers. Weitere Informationen zum kostenlosen Kontingent und zu den Preisen für die Datenübertragung finden Sie auf der Seite Logging. Streamen Sie die Logs in Logging oder Monitoring, um sie beizubehalten und Benachrichtigungen bei anormalen Aktivitäten zu generieren. Installieren Sie dazu den Logging-Agent auf jedem Server (Anforderung 10.5.3).

Intrusion Detection System integrieren

Zur Gewährleistung der Sicherheit Ihrer Zahlungsbearbeitungsumgebung verwenden Sie ein im Abschnitt 11.4 beschriebenes Intrusion Detection System (IDS), mit dem ein Angriff auf das System durch Personen identifiziert wird. Es gibt zwei Möglichkeiten, ein IDS in eine Zahlungsbearbeitungsumgebung aufzunehmen. Platzieren Sie ein IDS an jedem Einstiegspunkt oder installieren Sie ein IDS auf jedem Server.

Installieren Sie auf jedem Server ein IDS, um die Komplexität Ihrer Umgebungsarchitektur zu reduzieren und die Einhaltung von 11.5 zu vereinfachen. Nachdem Sie die zu verwendende IDS-Software geprüft und ausgewählt haben, können Sie deren Installation zu einem Teil des Skripts für die Startinstallation für jeden Server machen.

IDS-Logs fallen in den Bereich der PCI DSS-Compliance und müssen zu Berichtserstellungs-, Warnungs- und Auditingzwecken an Logging und Monitoring gesendet werden.

Security Command Center implementieren

Mit dem Dienst Security Command Center (Beta) können Sicherheitsteams Daten erheben, Bedrohungen ermitteln und Maßnahmen dagegen ergreifen, bevor sie zu Unternehmensschäden oder -verlusten führen. Er bietet detaillierte Informationen zum App- und Datenrisiko, sodass Sie Bedrohungen für Ihre Cloudressourcen schnell minimieren und den allgemeinen Zustand bewerten können. Mit dem Security Command Center können Sie ein Inventar Ihrer Cloud-Assets ansehen und beobachten, Speichersysteme auf sensible Daten scannen, gängige Sicherheitslücken im Web erkennen und Zugriffsrechte für Ihre kritischen Ressourcen überprüfen – alles über ein zentrales Dashboard. Dies kann Ihnen bei der Erfüllung mehrerer Anforderungen helfen, einschließlich der Abschnitte 5 und 6.6.

App-Bereitstellung automatisieren

Konfigurieren Sie das Tool zur Konfigurationsverwaltung so, dass die neueste Version der App sicher abgerufen und gestartet wird. Die App kann von jedem Speicherort wie beispielsweise Cloud Storage abgerufen werden, vorausgesetzt, der Speicherort ist sicher.

Viele der oben erwähnten Tools zur Konfigurationsverwaltung unterstützen Workflows für die kontinuierliche Integration und Bereitstellung (Continuous Integration and Deployment, CI/CD), die auch zum automatischen Scannen (Anforderung 11.2.3) und zur Überprüfung des Codes verwendet werden können (Anforderung 6.3.2).

Konfigurationsmanager-Logs erfassen

Wenn Sie den Konfigurationsmanager einrichten, müssen alle Installationsdetails protokolliert werden. Nach Abschluss des Konfigurationsprozesses müssen die Logs an Logging und Monitoring gesendet werden.

Logging und Monitoring

Sorgen Sie dafür, dass jeder in Ihrer Zahlungsbearbeitungsumgebung durchgeführte Schritt überwacht und aufgezeichnet wird, um die PCI DSS-Konformität gemäß Abschnitt 10 sicherzustellen. Jede Serveraktivität in jeder Instanz muss protokolliert werden. Außerdem muss jede Benutzeraktion später überprüft werden können.

Zugriffstransparenz aktivieren

Über die Funktion Access Transparency bietet Logging jetzt Logs nahezu in Echtzeit, wenn Google Cloud-Administratoren auf Ihre Inhalte zugreifen. Cloud-Audit-Logs geben bereits Einblick in die Handlungen Ihrer eigenen Administratoren. Dieser Audit-Trail schließt allerdings in der Regel Maßnahmen aus, die vom Support- oder Entwicklerteam Ihres Cloudanbieters durchgeführt wurden. Vor dem Logging mit Zugriffstransparenz wurde zum Beispiel ein über den Google-Support eröffnetes Ticket, bei dem Datenzugriffe erforderlich waren, nicht beim Cloud-Audit-Logging verfolgt. Mit der Zugriffstransparenz wird diese Lücke geschlossen. Dabei werden Logs manueller, gezielter Zugriffe des Support- oder Entwicklerteams nahezu in Echtzeit erfasst.

Google hat kürzlich Access Approval veröffentlicht. Access Approval befindet sich in der Phase "Early Access". Während Sie mit Access Transparency einen Einblick in die Zugriffe durch den Support und das Technikteam von Google erhalten, können Sie mit Access Approval diesen Zugriff auf Ihre Daten und Konfigurationen auf in Google Cloud vorab explizit erlauben. Mehr über den Dienst und wie Sie Vorabzugriff anfordern, erfahren Sie auf der verlinkten Seite.

Firewallregel-Logging aktivieren

Mit Firewallregel-Logging können Sie das Logging auf der jeweiligen Regelebene aktivieren. Sie können damit für alle von Ihnen erstellten Regeln TCP- und UDP-Verbindungen in einer VPC aufzeichnen. Diese Informationen sind mitunter nützlich, um den Netzwerkzugriff zu überprüfen oder frühzeitig auf eine unzulässige Netzwerknutzung hinzuweisen.

VPC Service Controls verwenden

Mit VPC Service Controls (Beta) können Sie einen Sicherheitsbereich um Google Cloud-Ressourcen wie Cloud Storage-Buckets, Cloud Bigtable-Instanzen und BigQuery-Datasets definieren, um Daten in einer VPC einzuschränken und die Risiken einer unbefugten Daten-Exfiltration zu minimieren (Anforderungen 1.2.1 und 1.3.4). Mit VPC Service Controls können Sie Ihre privaten Daten schützen und gleichzeitig von den vollständig verwalteten Speicher- und Datenverarbeitungsfunktionen von Google Cloud profitieren. Fordern Sie Early Access an, um weitere Informationen zu erhalten.

VPC-Fluss-Logs einrichten

Cardholder Data Environment (Umgebung für Daten von Karteninhabern) mit aktivierten VPC-Fluss-Logs
CDE mit aktivierten VPC-Fluss-Logs

VPC-Fluss-Logs zeichnen Netzwerktraffic-Flüsse auf, die von VM-Instanzen gesendet oder empfangen werden. Die Logs sind im Rahmen von PCI DSS für Monitoring, Auditing, Forensik und Echtzeit-Sicherheitsanalysen nützlich. In jedem Subnetz eines VPC-Netzwerks können Fluss-Logs unabhängig voneinander aktiviert oder deaktiviert sein. Sie können die Anzahl der Log-Daten minimieren. Aktivieren Sie dazu die Fluss-Logs nur in Ihren CDE, die unter die Vorgaben fallen.

Fluss-Logs in Kombination mit Firewallregeln für ausgehenden Traffic ermöglichen Ihnen die Beschränkung von ausgehendem Traffic auf autorisierte Endpunkte auf eine Weise, die überprüfbar und schwer zu umgehen ist (Anforderungen 1.2.1 und 1.3.4).

Wenn Sie detailliertere Daten als Fluss-Logs benötigen (z. B. individuelles HTTP-Anfrage-Logging), können Sie Kontrollen in die App oder in ausgehende Proxyanfragen implementieren. Dies erfolgt über Ihren eigenen Reverse-Proxyserver, der so konfiguriert ist, dass er Zugriffslogs an Logging weiterleitet. Anweisungen zum Einrichten eines Squid-Proxyservers in Compute Engine finden Sie unter Netzwerkproxy einrichten. Richten Sie mindestens zwei redundante Proxyserver ein, um Engpässe zu vermeiden.

Interne Zugangsdaten protokollieren

Überwachen und protokollieren Sie nicht nur externe Bedrohungen, sondern auch die Aktivitäten von Personen mit Administratorzugriff auf die Zahlungsbearbeitungsumgebung (Abschnitt 10.2). Dazu können Sie Shell-Befehle protokollieren. Mehrere Open-Source-Tools können Shell-Befehle überwachen und zum Erfassen in Logs senden. Beliebte Tools für diese Aufgabe sind zum Beispiel OSSEC oder Tripwire.

Warnbenachrichtigungen einrichten

Konfigurieren Sie das Monitoring so, dass Warnungen gesendet werden, wenn in der Zahlungsbearbeitungsumgebung etwas schiefgeht (Abschnitt 10.6). Die Warnungen müssen die Ereignisse in den Bereichen Umwelt, Audit und interne Apps abdecken. Bauen Sie die Benachrichtigungsstrategie auf den möglichen Risiko- oder Angriffsvektoren für jede Komponente der Zahlungsbearbeitungs-App auf. Sie können beispielsweise Monitoring-Benachrichtigungen auslösen, wenn Ihr IDS Versuche von nicht autorisiertem Eindringen erkennt, unabhängig davon, ob sie erfolgreich oder nicht erfolgreich sind. Firewallregel-Logging ermöglicht Ihnen außerdem, beim Versuch der Verletzung bestimmter Netzwerkrichtlinien Benachrichtigungen auszulösen.

Logs zu BigQuery streamen

Logging von Streaming-Logs in Cloud Storage und BigQuery
Logging von Streaming-Logs in Cloud Storage und BigQuery

Optional können Sie Logging-Logs in BigQuery exportieren, um sie später zu analysieren. Da BigQuery für die Abfrage großer Datasets optimiert wurde, ist es ein ideales Tool für die Analyse umfangreicher Logs. Logging kann für Logs, die eine Analyse nahezu in Echtzeit erfordern, sogar direkt in BigQuery protokollieren (Anforderung 10.6.1).

Daten mit Cloud Data Loss Prevention bereinigen

Daten, die selbst nicht unter die Vorgaben fallen, aber in Ihrer unter die Vorgaben fallenden App enthalten sind, können anderweitig verwendet werden, z. B. für Analysen oder Entwicklung. Gewähren Sie diesen Apps erst dann Zugriff auf PCI-Daten, wenn sie mit Cloud Data Loss Prevention (Anforderung 6.4.3) bereinigt wurden.

App-Sicherheit

Zum Sichern der App müssen Sie zuerst die Verwaltungsoberfläche auswerten. Sie können auch den Cloud Key Management Service verwenden.

Verwaltungsoberfläche auswerten

Die meisten E-Commerce-Apps haben eine eigene Verwaltungsoberfläche, die keine Konsole verwendet, z. B. ein Kundenservice-/Abrechnungsportal. Ein solches Tool muss robuste Zugriffskontrollen und einen individualisierten Zugriff haben, der die Multi-Faktor-Authentifizierung verwendet (Abschnitt 8.3). Es muss außerdem mit Audit-Logging (Abschnitt 10.2) instrumentiert werden.

Alle Logs, die Sie erstellen, sollten die folgenden Fragen beantworten: Wer hat was getan? Wo hat er es getan? Wann hat er es getan? Gemäß Abschnitt 2.3 muss jeder Zugriff auf ein solches Tool eine starke Transportverschlüsselung verwenden. Verwenden Sie Cloud Data Loss Prevention, um vertrauliche Informationen zu filtern, bevor sie in einem Admin-Tool angezeigt werden.

Cloud Key Management Service (Cloud KMS) verwenden

Cloud KMS ist ein Dienst, mit dem Sie Verschlüsselungsschlüssel verwalten können. Es kann die Verschlüsselungsschlüssel AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 generieren, verwenden, rotieren und löschen. Mit Cloud KMS können Sie Nur-Text-Passwörter entfernen, die in Code- oder Konfigurationsdateien gespeichert sind. Dadurch wird die Einhaltung der Anforderungen 3.5, 3.6, 6.3.1 und 8.2 vereinfacht.

Umgebung validieren

Die Umgebung muss validiert werden, nachdem sie implementiert wurde, aber bevor Produktionstraffic durch sie fließt:

  • Wenn Sie ein Händler der Ebene 1 sind, muss Ihre Umgebung von einem Qualified Security Assessor (QSA) (qualifizierten Sicherheitsprüfer) validiert werden. Ein QSA ist ein Unternehmen oder eine Einzelperson, die vom PCI Security Standards Council zur Validierung von PCI-Umgebungen und zur Erteilung des Gütesiegels zugelassen wurde.
  • Als Händler der Ebene 2 oder niedriger können Sie Ihre Umgebung validieren. Dazu müssen Sie den Self-Assessment Questionnaire (Fragebogen zur Selbstbewertung) ausfüllen.

Weitere Informationen