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.
Dieses Dokument bezieht sich gegebenenfalls auf die Anforderungen für PCI DSS 4.0.
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, JCB oder UnionPay 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.
Ausgleichsmaßnahmen: Alternative Lösungen, die in Betracht gezogen werden können, wenn ein Rechtssubjekt eine Anforderung aufgrund legitimer technischer oder dokumentierter geschäftlicher Einschränkungen nicht ausdrücklich erfüllen kann. Rechtssubjekte müssen das mit der Anforderung verbundene Risiko ausreichend minimieren, wenn sie diese anderen Kontrollmechanismen implementieren. Eine Anleitung zur Verwendung von ergänzenden Kontrollen finden Sie in den Anhängen B und C unter „Compensating Controls“ (Ergänzende Kontrollen) im Dokument PCI DSS Requirements and Security Assessment Procedures (Anforderungen und Verfahren zur Sicherheitsbewertung des PCI-Datensicherheitsstandards).
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. Die Qualifikationsanforderungen für qualifizierte Sicherheitsprüfer (QSA, Qualified Security Assessors) enthalten Details zu den Anforderungen für QSA-Unternehmen und -Mitarbeiter.
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. Dies gilt nur für Rechtssubjekte, die eine Selbstbewertung vornehmen können.
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
Der PCI DSS umfasst 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 4.0-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, wenn Sie für die Selbstbewertung infrage kommen. 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 darf also in keinster Weise mit Kundenkartendaten in Berührung kommen. |
| 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. Anders ausgedrückt: 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. |
Compliance
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. Sie können die PCI DSS-Complianceberichte von Google im Compliance Reports Manager herunterladen. 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 von 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
Dieser Abschnitt enthält Informationen zu häufig verwendeten Google Cloud-Diensten in Architekturen, die für PCI DSS-Umgebungen verwendet werden.
App Engine
Verwenden Sie App Engine-Firewallregeln und Steuerelemente für ausgehenden Traffic.
Cloud Run
Verwenden Sie die Einstellungen für eingehenden Traffic von Cloud Run, VPC Service Controls und die Steuerelemente für ausgehenden Traffic in VPC-Connectors. Konfigurieren Sie bei Bedarf eine statische ausgehende IP-Adresse.
Cloud Run-Funktionen
Verwenden Sie die Netzwerkeinstellungen für den eingehenden und ausgehenden Traffic von Cloud Run Functions.
Cloud Logging
Interaktionen mit Cloud Logging erfassen
Cloud Monitoring
Interaktionen mit Cloud Monitoring überwachen
Google Kubernetes Engine
Informationen zur Verwendung der Google Kubernetes Engine für PCI DSS-Umgebungen finden Sie unter PCI DSS-Compliance in GKE.
Cloud Storage
In der Anforderung 3.5 ist festgelegt, dass eine primäre Kontonummer (PAN) dort sicher ist, wo sie gespeichert wird. 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.
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:
Der Kunde trifft seine Auswahl und fährt mit dem Checkout fort.
Die Checkout-App leitet den Kunden an einen externen Zahlungsabwickler weiter.
Der Kunde gibt seine Zahlungskartendaten in ein Zahlungsformular ein, das dem externen Zahlungsabwickler gehört und von diesem verwaltet wird.
Der externe Zahlungsabwickler prüft die Zahlungskartendaten und belastet dann die Karte oder lehnt sie ab.
Nach der Transaktionsverarbeitung leitet der externe Zahlungsabwickler den Kunden zusammen mit den Transaktionsdetails an die Händleranwendung zurück.
Die Händleranwendung sendet eine Bestätigungsanfrage an den Zahlungsabwickler, um die Transaktion zu bestätigen.
Der Zahlungsabwickler antwortet, um die Transaktionsdetails zu überprüfen.
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:
Der Kunde gibt seine Zahlungskartendaten in ein Zahlungsformular ein, das Ihrem Unternehmen gehört und von diesem verwaltet wird.
Die vom Kunden im Formular angegebenen Informationen werden auf sicherem Weg an einen externen Zahlungsabwickler übergeben.
Der externe Zahlungsabwickler prüft die Zahlungskartendaten und belastet dann die Karte oder lehnt sie ab.
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.
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:
Der Kunde gibt seine Zahlungskartendaten in ein Zahlungsformular ein, das Ihrem Unternehmen gehört und von diesem verwaltet wird.
Die vom Kunden in das Formular eingegebenen Informationen werden an die Zahlungsanwendung gesendet.
Die Zahlungsanwendung überprüft die Zahlungsinformationen und leitet sie über eine Back-End-API sicher an einen externen Zahlungsabwickler weiter.
Der externe Zahlungsabwickler prüft die Zahlungskartendaten und belastet dann die Karte oder lehnt sie ab.
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.
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.
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.
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.
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.
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.
Ihre Zahlungsbearbeitungs-App validiert die vom Kunden gesendeten Zahlungskartendaten und leitet sie über eine Backend-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:
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.5.3). 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.2 und Anforderung 8.2.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, nach Möglichkeit Rollen zu verwenden und diese so zuzuweisen, dass nur Berechtigungen gewährt werden, die für die Ausführung der erwarteten Arbeit unbedingt erforderlich sind. Die Rolle "Inhaber" wird dabei nur solchen Mitgliedern zugewiesen, die auch wirklich 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.3.6 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:
- Cloud Next Generation-Firewall-Richtlinien oder Compute Engine-Firewallregeln
- Ein Cloud VPN-Tunnel
- Ein externer Application Load Balancer
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 Richtlinien für Cloud Next Generation Firewall oder Firewallregeln für VPC, um eingehenden Traffic auf jede Ihrer Compute Engine-Instanzen zu beschränken (Anforderungen 1.3 und 1.4). 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 in diesem Dokument 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
Sie können Cloud VPN verwenden, um einen sicheren VPN-Tunnel zwischen Ihrer lokalen Umgebung und Ihrer Zahlungsbearbeitungsumgebung einzurichten (Abschnitte 2.2.7 und 4.2).
Externen Application Load Balancer erstellen
Durch die Erstellung eines externen Application Load Balancers (Abschnitte 2.2.7 und 4.2) können Sie dafür sorgen, dass eingehender Kundentraffic sicher ist. Zum Erstellen eines externen Application Load Balancer 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:
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.4). Dazu können das Google Cloud CLI, sprachspezifische Laufzeiten und Bibliotheken oder ein Webserver gehören.
Erstellen Sie eine Compute Engine-Instanz, die eins der in Compute Engine vorkonfigurierten Betriebssystem-Images verwendet.
Installieren Sie die Bibliotheken und die Software, die vorher aufgeführt wurden.
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.6).Das Image muss den Best Practices für das Erstellen eines sicheren Compute Engine-Images entsprechen (gesamter Abschnitt 2.2).
Nachdem Sie das Basis-Image konfiguriert haben, erstellen Sie damit ein benutzerdefiniertes Laufwerk-Image für Compute Engine. 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 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 Terraform erstellen. Mit Terraform können Sie die gesamte Zahlungsbearbeitungsumgebung, einschließlich der Firewallregeln, Gateways, Load Balancer und Instanzen, in Code beschreiben.
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 in den Anleitungen für die Notfallwiederherstellung, das Konzipieren robuster Systeme und das 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.
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.3) 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.
Fluss-Logs in der Virtual Private Cloud implementieren
Mit VPC-Fluss-Logs (Beta) wird eine Stichprobe der von VM-Instanzen gesendeten oder empfangenen Netzwerkflüsse erfasst. Sie können diese Logs für Netzwerküberwachung, Forensik und Echtzeit-Sicherheitsanalysen (Abschnitt 10.2) 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 bzw. Monitoring, um diese Logs beizubehalten und Benachrichtigungen bei verdächtigen Aktivitäten zu generieren. Installieren Sie dazu den Logging-Agent auf jedem Server (Abschnitt 10.3).
Intrusion Detection System integrieren
Zur Gewährleistung der Sicherheit Ihrer Zahlungsbearbeitungsumgebung verwenden Sie ein im Abschnitt 11.5 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.
Cloud IDS (Cloud Intrusion Detection System) ist ein Einbruchserkennungsdienst, der Bedrohungserkennung bei Einbrüchen, Malware, Spyware und Command-and-Control-Angriffen in Ihrem Netzwerk bietet. Er ermöglicht vollständigen Einblick in den Netzwerktraffic, einschließlich Nord-Süd- und Ostwest-Traffic, sowie die Überwachung der VM-zu-VM-Kommunikation für die Erkennung von seitlichen Bewegungen. Sie können auch Cloud IDS verwenden, um die Einhaltung von Anforderung 11.5 zu vereinfachen.
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 Security Command Center können Sicherheitsteams Daten erheben, Bedrohungen erkennen 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.4.
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 zuvor 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 (Abschnitt 11.3) und zur Überprüfung des Codes verwendet werden können (Anforderung 6.2.3).
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
Mit 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 Zugriffsgenehmigung wurden zum Beispiel über den Google-Support eröffnete Tickets, bei denen Datenzugriffe erforderlich waren, nicht vom Cloud-Audit-Logging verfolgt. Dank der Zugriffsgenehmigung wird diese Lücke geschlossen. Dabei werden Logs manueller, gezielter Zugriffe des Support- oder Entwicklerteams nahezu in Echtzeit erfasst.
Mit der Zugriffsgenehmigung können Sie den Zugriff auf Ihre Daten oder Konfigurationen in Google Cloud vorab explizit erlauben. Die Zugriffsgenehmigung bietet auch Einblick in Zugriffe durch den Support und das Technikteam von Google.
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 können Sie einen Sicherheitsbereich um Google Cloud-Ressourcen wie Cloud Storage-Buckets, Bigtable-Instanzen und BigQuery-Datasets definieren, um Daten in einem VPC-Netzwerk einzuschränken und die Risiken einer Daten-Exfiltration zu minimieren (Anforderungen 1.3.1 und 1.3.2). 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.
VPC-Fluss-Logs einrichten
VPC-Fluss-Logs zeichnen den VM-Instanzen gesendeten oder empfangenen Netzwerktraffic auf. 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).
Das folgende Diagramm zeigt, wie VPC-Fluss-Logs den von VM-Instanzen gesendeten oder empfangenen Netzwerktraffic aufzeichnen.“
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
Optional können Sie Logging-Logs zur späteren Analyse an BigQuery weiterleiten. Weitere Informationen finden Sie unter Routing und Speicher: Senken. 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.4.1).
Sensitive Data Protection zum Bereinigen von Daten verwenden
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 Sensitive Data Protection bereinigt wurden (Anforderung 6.5.1).
App-Sicherheit
Zum Sichern der App müssen Sie zuerst die Administratoroberfläche auswerten. Sie können auch den Cloud Key Management Service verwenden.
Administratoroberfläche auswerten
Die meisten E-Commerce-Apps haben eine eigene Administratoroberflä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.4). 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.2.7 muss jeder Zugriff auf ein solches Tool eine starke Transportverschlüsselung verwenden. Verwenden Sie Sensitive Data Protection, um vertrauliche Informationen zu filtern, bevor sie in einem Administrator-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 Abschnitte 2.2.2, 3.6, 3.7 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
- PCI DSS-Dokumentbibliothek
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center