PCI DSS-Compliance in GKE

Dieser Leitfaden soll Ihnen dabei helfen, Probleme zu lösen, die nur bei GKE-Anwendungen (Google Kubernetes Engine) auftreten, wenn Sie die Kundenverantwortlichkeiten für PCI DSS-Anforderungen (Payment Card Industry Data Security Standard) implementieren.

Haftungsausschluss: Dieser Leitfaden dient nur zu Informationszwecken. Die von Google darin zur Verfügung gestellten Informationen und Empfehlungen stellen keine Rechts- oder Prüfungsberatung dar. Jeder Kunde muss seine eigene konkrete Nutzung der Dienste jeweils eigenständig bestimmen, um die Einhaltung der gültigen Rechtsvorschriften zu gewährleisten.

Einführung in PCI DSS-Compliance und GKE

Jedes Unternehmen, das Zahlungskartendaten verarbeitet, muss diese sichern – unabhängig davon, ob sich die Daten in einer lokalen Datenbank oder in der Cloud befinden. PCI DSS wurde entwickelt, um den Schutz von Karteninhaberdaten zu verbessern und einen weltweiten Standard zur Datensicherheit einzuführen. PCI DSS stellt die Grundlage für technische und betriebliche Anforderungen zum Schutz von Kreditkartendaten dar. PCI DSS muss von allen Entitäten eingehalten werden, die an der Verarbeitung von Zahlungskarten beteiligt sind, darunter Händler, Auftragsverarbeiter, Acquirer, Kartenaussteller und Dienstleister. PCI DSS gilt auch für alle anderen Entitäten, die Karteninhaberdaten oder vertrauliche Authentifizierungsdaten oder beides speichern, verarbeiten oder übertragen.

Containerbasierte Anwendungen werden zunehmend beliebter; so werden beispielsweise viele Legacy-Arbeitslasten von einer VM-basierten Architektur zu einer containerbasierten Architektur migriert. Google Kubernetes Engine ist eine produktionsreife, verwaltete Umgebung für das Deployment von containerbasierten Anwendungen. Sie vereint die neuesten Innovationen von Google im Hinblick auf die Produktivität der Entwickler, den effizienten Einsatz von Ressourcen, automatisierte Abläufe und Open-Source-Flexibilität, um die Produkteinführungszeit zu verkürzen.

Compliance ist eine geteilte Verantwortung in der Cloud. Google Cloud und GKE (sowohl Autopilot- als auch Standardbetriebsmodus) erfüllen die PCI-DSS-Anforderungen. Unsere Verantwortlichkeiten werden in unserer Gemeinsamen Verantwortungsmatrix beschrieben.

Zielgruppe

• Kunden, die PCI-konforme Arbeitslasten unter Verwendung von GKE in Google Cloud übertragen möchten
• Entwickler, Sicherheitsbeauftragte, Compliance-Beauftragte, IT-Administratoren und andere Mitarbeiter, die für die Implementierung von Kontrollen und die Einhaltung der PCI DSS-Anforderungen verantwortlich sind

Vorbereitung

Für die weiter unten beschriebenen Empfehlungen müssen Sie möglicherweise Folgendes verwenden:

• Google Cloud-Ressourcen wie Organisation, Ordner und Projekte
• Identitäts- und Zugriffsverwaltung
• Google Kubernetes Engine
• Google Cloud VPCs
• Google Cloud Armor
• Cloud Data Loss Prevention API (Teil von Sensitive Data Protection)
• Identity-Aware Proxy (IAP)
• Security Command Center

Dieser Leitfaden richtet sich an Personen, die mit Containern und GKE vertraut sind.

Umfang

In diesem Leitfaden werden die folgenden Anforderungen von PCI DSS aufgeführt, die für GKE von besonderer Bedeutung sind. Darüber hinaus werden Anleitungen zu deren Erfüllung bereitgestellt. Der Leitfaden bezieht sich auf Version 4.0 des Standards. Dieser Leitfaden deckt nicht alle Anforderungen in PCI DSS ab. Die in diesem Leitfaden enthaltenen Informationen können Organisationen bei der Umsetzung der PCI DSS-Compliance helfen. Sie sind jedoch keine umfassende Beratung. Organisationen können einen PCI Qualified Security Assessor (QSA) zur formellen Validierung beauftragen.

PCI-DSS-Ziele	PCI DSS-Anforderungen
Umgebung für Karteninhaberdaten segmentieren	Wird manchmal als Anforderung 0 bezeichnet. Wir empfehlen diese Anforderung zur Beschränkung des PCI-Bereichs; sie ist für die PCI-Compliance jedoch nicht zwingend notwendig.
Sicheres Netzwerk und Systeme erstellen und verwalten	1. Installation und Verwaltung von Netzwerksicherheit Anforderung 1.1 Anforderung 1.1.2 Anforderung 1.2 Anforderung 1.2.2 Anforderung 1.2.5 Anforderung 1.3 Anforderung 1.3.1 Anforderung 1.4 Anforderung 1.4.3 Anforderung 1.4.5 2. Sichere Konfigurationen auf alle Systemkomponenten anwenden Anforderung 2.2 Anforderung 2.2.4 Anforderung 2.2.5 Anforderung 2.2.6
Kontodaten schützen	3. Gespeicherte Kontodaten speichern Anforderung 3.5 Anforderung 3.6 4. Karteninhaberdaten mit starker Kryptografie während der Übertragung über offene, öffentliche Netzwerke schützen Anforderung 4.1
Programm zur Verwaltung von Sicherheitslücken pflegen	5. Alle Systeme und Netzwerke vor schädlicher Software schützen Anforderung 5.2 Anforderung 5.2.3 Anforderung 5.3 6. Entwicklung und Wartung sicherer Systeme und Software Anforderung 6.2 Anforderung 6.2.1 Anforderung 6.3 Anforderung 6.3.1 Anforderung 6.4
Strenge Maßnahmen zur Zugriffssteuerung implementieren	7. Beschränkung des Zugriffs auf Systemkomponenten und Karteninhaberdaten je nach Geschäftsinformationsbedarf Anforderung 7.2 Anforderung 7.2.2 8. Zugriff auf Systemkomponenten ermitteln und authentifizieren Anforderung 8.2 Anforderung 8.2.1 Anforderung 8.2.5 Anforderung 8.3 Anforderung 8.3.1 9. Beschränkung des physischen Zugriffs auf Karteninhaberdaten
Netzwerke regelmäßig überwachen und testen	10. Logging und Monitoring des gesamten Zugriffs auf Systemkomponenten und Karteninhaberdaten Anforderung 10.2 Anforderung 10.2.2 11. Sicherheit von Systemen und Netzwerken regelmäßig testen Anforderung 11.3 Anforderung 11.3.1 Anforderung 11.5 Anforderung 11.5.1
Informationssicherheitsrichtlinie pflegen	12. Datensicherheit mit Organisationsrichtlinien und -programmen unterstützen

Terminologie

In diesem Abschnitt werden die in diesem Leitfaden verwendeten Begriffe definiert. Weitere Informationen finden Sie im PCI DSS-Glossar.

CHD

Cardholder Data (Karteninhaberdaten). Bestehen mindestens aus der vollständigen primären Kontonummer (Primary Account Number, PAN). Karteninhaberdaten können auch mit der vollständigen PAN plus einer der folgenden Angaben aufgeführt werden:

• Name des Karteninhabers
• Ablaufdatum und/oder Dienstcode
• Vertrauliche Authentifizierungsdaten (Sensitive Authentication Data, SAD)

CDE

Cardholder Data Environment (Umgebung für Karteninhaberdaten). Die Personen, Prozesse und Technologien, die Daten von Karteninhabern oder vertrauliche Authentifizierungsdaten speichern, verarbeiten oder übertragen.

PAN

Primary Account Number (primäre Kontonummer). Ein Schlüsselelement der Karteninhaberdaten, zu deren Schutz Sie im Rahmen von PCI DSS verpflichtet sind. Die PAN ist in der Regel eine 16-stellige Nummer, die für eine Zahlungskarte (Kredit- oder Debitkarte) eindeutig ist und den Aussteller sowie den Karteninhaber identifiziert.

PIN

Personal Identification Number (Persönliche Identifikationsnummer). Ein numerisches Kennwort, das nur dem Nutzer und einem System bekannt ist. Die PIN wird zur Authentifizierung des Nutzers beim System verwendet.

QSA

Qualified Security Assessor (Qualifizierter Sicherheitsprüfer). Eine Person, die vom PCI Security Standards Council (PCI SSC) zur Durchführung von PCI DSS-Prüfungen vor Ort qualifiziert wird.

SAD

Sensitive Authentication Data (Vertrauliche Authentifizierungsdaten). Im Rahmen der PCI-Compliance Daten, die von Kartenausstellern zum Autorisieren von Transaktionen verwendet werden. Ähnlich wie bei Karteninhaberdaten erfordert PCI DSS den Schutz von SAD. Darüber hinaus können SAD nicht von Händlern und deren Zahlungsabwicklern einbehalten werden. SAD umfassen Folgendes:

• Daten von Magnetstreifen "verfolgen"
• "Äquivalente Daten verfolgen", die von Chipkarten und kontaktlosen Karten generiert wurden
• Sicherheitsprüfcodes (z. B. die auf Zahlungskarten aufgedruckte 3–4-stellige Nummer), die für Onlinetransaktionen und Transaktionen ohne Karte verwendet werden
• PINs und PIN-Blöcke

Segmentierung

Im Zusammenhang mit PCI DSS der Vorgang zum Isolieren der CDE vom restlichen Netzwerk der Entität. Die Segmentierung ist keine PCI DSS-Anforderung. Die Verwendung dieser Methode wird jedoch dringend empfohlen, um Folgendes zu reduzieren:

• Umfang und Kosten der PCI DSS-Bewertung
• Die Kosten und Herausforderungen bei der Implementierung und Verwaltung von PCI DSS-Kontrollen
• Das Risiko für eine Organisation – durch Konsolidierung der Karteninhaberdaten an weniger und besser kontrollierten Standorten

Umgebung für Karteninhaberdaten segmentieren

Die CDE umfasst Personen, Prozesse und Technologien, die Daten von Karteninhabern oder vertrauliche Authentifizierungsdaten speichern, verarbeiten oder übertragen. Im Zusammenhang mit GKE umfasst die CDE auch Folgendes:

• Systeme, die Sicherheitsdienste bereitstellen (z. B. IAM)
• Systeme zur Vereinfachung der Segmentierung (z. B. Projekte, Ordner, Firewalls, Virtual Private Clouds (VPCs) und Subnetze)
• Anwendungspods und -cluster, die Karteninhaberdaten speichern, verarbeiten oder übertragen Ohne eine angemessene Segmentierung kann Ihre gesamte Cloudumgebung in den Geltungsbereich von PCI DSS geraten

Damit eine Systemkomponente als außerhalb des Geltungsbereichs für PCI DSS betrachtet wird, muss sie ordnungsgemäß von der CDE isoliert werden. Dies ist erforderlich, damit die Sicherheit der CDE auch dann nicht beeinträchtigt wird, wenn die betroffene Systemkomponente gefährdet ist.

Eine wichtige Voraussetzung für die Reduzierung des Geltungsbereichs der CDE ist ein klares Verständnis der Geschäftsanforderungen und -prozesse im Zusammenhang mit der Speicherung, Verarbeitung und Übertragung von Karteninhaberdaten. Wenn Sie die Daten von Karteninhabern auf so wenige Standorte wie möglich beschränken möchten, indem Sie unnötige Daten entfernen und die erforderlichen Daten konsolidieren, müssen Sie möglicherweise langjährige Geschäftspraktiken neu entwickeln.

Es gibt unterschiedliche Methoden in Google Cloud zum Segmentieren Ihrer CDE. In diesem Abschnitt werden die folgenden Methoden erläutert:

• Logische Segmentierung unter Verwendung der Ressourcenhierarchie
• Netzwerksegmentierung mithilfe von VPCs und Subnetzen
• Segmentierung auf Dienstebene mithilfe von VPC
• Sonstige Überlegungen für Cluster innerhalb des Geltungsbereichs

Logische Segmentierung anhand der Ressourcenhierarchie

Es gibt verschiedene Möglichkeiten, Ihre CDE mithilfe der Ressourcenhierarchie von Google Cloud innerhalb Ihrer Organisationsstruktur zu isolieren. Google Cloud-Ressourcen sind hierarchisch organisiert. Die Organisationsressource ist der Stammknoten in der Google Cloud-Ressourcenhierarchie. Darunter fallen Ordner und Projekte. Ordner können Projekte und Ordner enthalten. Ordner werden verwendet, um den Zugriff auf Ressourcen in der Ordnerhierarchie über IAM-Berechtigungen auf Ordnerebene zu steuern. Sie werden auch zum Gruppieren ähnlicher Projekte verwendet. Ein Projekt ist eine Vertrauensgrenze für alle Ihre Ressourcen und ein IAM-Erzwingungspunkt.

Sie können alle Projekte im PCI-Bereich in einem Ordner gruppieren, um sie auf Ordnerebene zu isolieren. Sie können auch ein Projekt für alle bereichsspezifischen PCI-Cluster und -Anwendungen verwenden oder ein Projekt und einen Cluster für jede bereichsspezifische PCI-Anwendung erstellen und diese zum Organisieren Ihrer Google Cloud-Ressourcen verwenden. In jedem Fall empfehlen wir, Arbeitslasten innerhalb und außerhalb des Geltungsbereichs in verschiedenen Projekten aufzubewahren.

Netzwerksegmentierung mit VPC-Netzwerken und Subnetzen

Sie können Virtual Private Cloud (VPC) und Subnetze verwenden, um Ihr Netzwerk bereitzustellen und CDE-bezogene Ressourcen zu gruppieren und zu isolieren. VPC ist die logische Isolierung eines Bereichs einer öffentlichen Cloud. VPC-Netzwerke bieten skalierbare und flexible Netzwerke für Ihre Compute Engine-VM-Instanzen und für die Dienste, die VM-Instanzen nutzen, einschließlich GKE. Weitere Informationen finden Sie in der VPC-Übersicht und in den Best Practices und Referenzarchitekturen.

Segmentierung auf Dienstebene mit VPC Service Controls und Google Cloud Armor

VPC und Subnetze ermöglichen Segmentierung und erstellen einen Perimeter zum Isolieren Ihrer CDE. VPC Service Controls hingegen erweitern den Sicherheitsumfang auf Ebene 7. Mit VPC Service Controls können Sie einen Dienstperimeter für Ihre bereichsspezifischen CDE-Projekte definieren. Mit den VPC Service Controls erhalten Sie folgende Kontrollmöglichkeiten:

• Zugangskontrolle: Nur autorisierte Identitäten und Clients dürfen in den Sicherheitsbereich gelangen.
• Ausgangskontrolle: Nur autorisierte Ziele sind für Identitäten und Clients im Sicherheitsbereich zulässig.

Mit Google Cloud Armor können Sie Listen mit IP-Adressen erstellen, um den Zugriff auf Ihren HTTP(S)-Load-Balancer am Rande des Google Cloud-Netzwerks zuzulassen oder abzulehnen. Indem Sie die IP-Adressen so nah wie möglich am Nutzer und am schädlichen Traffic untersuchen, können Sie verhindern, dass dieser schädliche Traffic Ressourcen verbraucht oder in Ihre VPC-Netzwerke eindringt.

Verwenden Sie VPC Service Controls, um einen Dienstperimeter für Ihre bereichsspezifischen Projekte zu definieren. Dieser Perimeter regelt die Pfade von VM-zu-Dienst und Dienst-zu-Dienst sowie den ein- und ausgehenden VPC-Traffic.

Sicheres Netzwerk und Systeme erstellen und verwalten

Der Aufbau und die Pflege eines sicheren Netzwerks werden in den Anforderungen 1 und 2 von PCI DSS definiert.

Anforderung 1

Installation und Verwaltung einer Firewallkonfiguration zum Schutz von Karteninhaberdaten und von Traffic in die CDE und aus der CDE.

Die Netzwerkkonzepte für Container und GKE unterscheiden sich von denen für herkömmliche VMs. Pods können miteinander auch ohne NAT direkt über Knoten hinweg kommunizieren. Auf diese Weise wird eine einfache Netzwerktopologie geschaffen, die Sie überraschen wird, wenn Sie die Verwaltung von komplexen Systemen gewohnt sind. Der erste Schritt zur Netzwerksicherheit für GKE besteht darin, sich mit diesen Netzwerkkonzepten vertraut zu machen.

Bevor Sie auf die einzelnen Anforderungen unter "Anforderung 1" eingehen, prüfen Sie die folgenden Netzwerkkonzepte in Bezug auf GKE:

• Firewallregeln: Mit Firewallregeln können Sie den Traffic auf Ihre Knoten beschränken. GKE-Knoten werden als Compute Engine-Instanzen bereitgestellt und verwenden dieselben Firewallmechanismen wie andere Instanzen. Innerhalb Ihres Netzwerks können Sie Tags verwenden, um diese Firewallregeln auf jede Instanz anzuwenden. Jeder Knotenpool erhält einen eigenen Satz Tags, die Sie in Regeln verwenden können. Standardmäßig erhält jede Instanz eines Knotenpools ein Tag zur Identifizierung eines bestimmten Kubernetes Engine-Clusters, zu dem dieser Knotenpool gehört. Dieses Tag wird in Firewallregeln verwendet, die GKE automatisch für Sie erstellt. Beim Erstellen von Clustern oder Knotenpools können Sie benutzerdefinierte Tags hinzufügen. Geben Sie dazu in der Google Cloud CLI das Flag --tags an.

• Netzwerkrichtlinien: Mit Netzwerkrichtlinien können Sie die Netzwerkverbindungen zwischen Pods begrenzen. Damit lassen sich Netzwerk-Pivoting und seitliche Bewegungen innerhalb des Clusters beschränken, falls eine Sicherheitslücke bei einem Pod auftritt. Wenn Sie Netzwerkrichtlinien verwenden möchten, müssen Sie dieses Feature beim Erstellen des GKE-Clusters ausdrücklich aktivieren. Sie können das Feature zwar auch in einem vorhandenen Cluster aktivieren, doch werden die Clusterknoten hierdurch neu gestartet. Standardmäßig ist die gesamte Kommunikation von Pod zu Pod immer offen. Wenn Sie Ihr Netzwerk segmentieren möchten, müssen Sie daher Netzwerkrichtlinien auf Pod-Ebene erzwingen. In GKE können Sie Netzwerkrichtlinien mit der Kubernetes Network Policy API oder mit dem kubectl-Tool definieren. Diese Traffic-Richtlinienregeln auf Pod-Ebene bestimmen, welche Pods und Dienste in einem Cluster aufeinander zugreifen können.

• Namespaces: Namespaces ermöglichen die Segmentierung von Ressourcen in Ihrem Kubernetes-Cluster. Im Lieferumfang von Kubernetes ist standardmäßig ein Namespace enthalten. Sie können jedoch mehrere Namespaces in Ihrem Cluster erstellen. Namespaces sind logisch voneinander isoliert. Sie legen den Umfang für Pods, Dienste und Deployments im Cluster fest. Nutzer, die mit einem Namespace interagieren, können somit keine Inhalte in anderen Namespaces sehen. Namespaces innerhalb desselben Clusters beschränken jedoch nicht die Kommunikation zwischen Namespaces. Hierzu werden Netzwerkrichtlinien verwendet. Weitere Informationen zum Konfigurieren von Namespaces finden Sie im Blogpost zu Best Practices für Namespaces.

Das folgende Diagramm veranschaulicht die oben erläuterten Konzepte in Bezug aufeinander und auf andere GKE-Komponenten wie Cluster, Knoten und Pods.

Anforderung 1.1

Prozesse und Mechanismen für die Installation und Wartung der Netzwerksicherheitskontrollen werden definiert und verstanden.

Anforderung 1.1.2

Beschreibung der Gruppen, Rollen und Verantwortungsbereiche für die Verwaltung der Netzwerkkomponenten.

Wie bei den meisten Diensten in Google Cloud müssen Sie zuerst IAM konfigurieren, um die Autorisierung in GKE einzurichten. Nachdem Sie die IAM-Rollen eingerichtet haben, müssen Sie im Rahmen einer Kubernetes-Autorisierungsstrategie die Konfiguration der rollenbasierten Zugriffssteuerung (Role-based Access Control, RBAC) von Kubernetes hinzufügen.

Grundsätzlich gilt die gesamte IAM-Konfiguration für alle Google Cloud-Ressourcen und alle Cluster innerhalb eines Projekts. Die RBAC-Konfiguration von Kubernetes gilt für die Ressourcen in jedem Kubernetes-Cluster und ermöglicht eine differenzierte Autorisierung auf Namespace-Ebene. In GKE werden diese Ansätze zur Autorisierung parallel verfolgt, wobei die Funktionen von Nutzern die Gesamtheit der ihnen zugewiesenen IAM- und RBAC-Rollen darstellen:

• IAM nutzen, um Gruppen, Rollen und Verantwortlichkeiten für die logische Verwaltung von Netzwerkkomponenten in GKE zu steuern.
• Kubernetes RBAC nutzen, um Netzwerkrichtlinien in Kubernetes-Clustern detaillierte Berechtigungen zu erteilen, den Traffic von Pod zu Pod zu steuern und unbefugte oder versehentliche Änderungen durch Nutzer außerhalb der CDE zu verhindern.
• In der Lage sein, alle IAM- und RBAC-Nutzer und -Berechtigungen rechtfertigen zu können. Wenn QSAs Kontrollen testen, suchen sie in der Regel nach einer geschäftlichen Rechtfertigung für eine Auswahl von IAM und RBAC.

Anforderung 1.2

Netzwerksicherheitsfunktionen (NSCs) werden konfiguriert und verwaltet.

Zuerst konfigurieren Sie Firewallregeln für Compute Engine-Instanzen, auf denen Ihre GKE-Knoten ausgeführt werden. Firewallregeln schützen diese Clusterknoten.

Als Nächstes konfigurieren Sie Netzwerkrichtlinien, um Datenströme einzuschränken und Pods in einem Cluster zu schützen. Eine Netzwerkrichtlinie gibt an, wie Gruppen von Pods miteinander und mit anderen Netzwerkendpunkten kommunizieren dürfen. Sie haben in GKE die Möglichkeit, Netzwerkrichtlinien zu erzwingen, um die Kommunikation zwischen den Pods und Diensten eines Clusters zu steuern. Erstellen Sie mehrere Namespaces, um den Cluster weiter zu segmentieren. Namespaces sind logisch voneinander isoliert. Sie bieten Platz für Pods, Dienste und Deployments im Cluster, damit Nutzer, die mit einem Namespace interagieren, keine Inhalte in einem anderen Namespace sehen können. Namespaces innerhalb desselben Clusters beschränken jedoch nicht die Kommunikation zwischen Namespaces. Hierzu werden Netzwerkrichtlinien verwendet. Namespaces ermöglichen die Segmentierung von Ressourcen in Ihrem Kubernetes-Cluster. Weitere Informationen zum Konfigurieren von Namespaces finden Sie im Blogpost zu Best Practices für Namespaces.

Wenn in einem Namespace keine Richtlinien vorhanden sind, wird standardmäßig der gesamte ein- und ausgehende Traffic zu und von Pods in diesem Namespace zugelassen. Sie können beispielsweise eine Isolierungsrichtlinie für einen Namespace einrichten. Dazu definieren Sie eine Netzwerkrichtlinie, die alle Pods auswählt, jedoch keinen eingehenden Traffic für diese Pods zulässt.

Anforderung 1.2.2

Alle Änderungen an Netzwerkverbindungen und an Konfigurationen von NSCs werden gemäß dem Änderungskontrollprozess, der in Anforderung 6.5.1 definiert ist, genehmigt und verwaltet.

Damit Ihre Netzwerkkonfigurationen und -infrastruktur als Code behandelt werden, müssen Sie im Rahmen der verwendeten Änderungsmanagement- und Änderungskontrollprozesse eine CI/CD-Pipeline für kontinuierliche Integration und kontinuierliches Deployment einrichten.

Sie haben die Möglichkeit, über Cloud Deployment Manager- oder Terraform-Vorlagen als Teil der CI/CD-Pipeline Netzwerkrichtlinien in Ihren Clustern zu erstellen. Mit Deployment Manager oder Terraform können Sie Konfiguration und Infrastruktur als Code behandeln, der konsistente Kopien der aktuellen Produktion oder anderer Umgebungen reproduzieren kann. Anschließend können Sie Komponententests und andere Tests schreiben, um zu überprüfen, ob die vorgenommenen Netzwerkänderungen wie erwartet funktionieren. Ein Änderungskontrollprozess, der eine Genehmigung enthält, kann über Konfigurationsdateien verwaltet werden, die in einem Versions-Repository gespeichert sind.

Mit Terraform Config Validator können Sie Einschränkungen definieren, um Sicherheitsrichtlinien und Governance-Richtlinien zu erzwingen. Wenn Sie Ihre CI/CD-Pipeline durch Config Validator erweitern, können Sie jedem Workflow einen Schritt hinzufügen. In diesem Schritt wird ein Terraform-Plan validiert und abgelehnt, wenn Verstöße festgestellt werden.

Anforderung 1.2.5

Alle zulässigen Dienste, Protokolle und Ports werden identifiziert, genehmigt und haben einen definierten Geschäftsbedarf.

Zur Festlegung strikter Kontrollen für eingehenden Traffic für Ihre GKE-Cluster können Sie autorisierte Netzwerke verwenden. Dies bietet die Möglichkeit, bestimmte IP-Bereiche, die Zugang zur Steuerungsebene Ihres Clusters haben, einzuschränken. GKE nutzt sowohl Transport Layer Security (TLS) als auch Authentifizierung, um einen sicheren Zugriff auf den Clustermaster-Endpunkt über das Internet zu ermöglichen. Dank der Flexibilität dieses Zugriffs können Sie Ihren Cluster standortunabhängig verwalten. Mit einem autorisierten Netzwerk können Sie den Zugriff auf bestimmte Gruppen von IP-Adressen weiter einschränken.

Mit Google Cloud Armor können Sie Zulassungs- und Sperrlisten sowie Sicherheitsrichtlinien für GKE-gehostete Anwendungen erstellen. In einem GKE-Cluster wird eingehender Traffic über das HTTP(S)-Load-Balancing abgewickelt, einer Komponente von Cloud Load Balancing. Der HTTP(S)-Load Balancer wird in der Regel vom GKE-Ingress-Controller konfiguriert. Dieser ruft die Konfigurationsinformationen von einem Kubernetes-Ingress-Objekt ab. Weitere Informationen finden Sie unter Google Cloud Armor über Ingress konfigurieren.

Anforderung 1.3

Der Netzwerkzugriff auf die und aus der Umgebung des Karteninhaberdaten ist eingeschränkt.

Zum Schutz vertraulicher Daten können Sie die private Kommunikation zwischen GKE-Clustern in Ihren VPC-Netzwerken und lokalen Hybrid-Deployments mithilfe von VPC Service Controls und privatem Google-Zugriff konfigurieren.

Anforderung 1.3.1

Es kann sinnvoll sein, eine Cloud NAT-Einrichtung mit GKE zu implementieren, um den eingehenden Traffic aus dem Internet nur auf diesen Cluster zu beschränken. Sie können für die nicht öffentlich zugänglichen Cluster in Ihrer CDE einen privaten Cluster einrichten. Die Knoten in einem privaten Cluster haben nur interne IP-Adressen vom Typ RFC 1918. Die Arbeitslasten der Knoten sind dadurch vom öffentlichen Internet isoliert.

Anforderung 1.4

Netzwerkverbindungen zwischen vertrauenswürdigen und nicht vertrauenswürdigen Netzwerken werden gesteuert.

Sie können diese Anforderung mit den gleichen Methoden erfüllen, die für Anforderung 1.3 aufgeführt sind.

Anforderung 1.4.3

Es werden Anti-Spoofing-Maßnahmen implementiert, um gefälschte Quell-IP-Adressen für den Zugriff auf das vertrauenswürdige Netzwerk zu erkennen und zu blockieren.

Zum Implementieren von Anti-Spoofing-Maßnahmen verwenden Sie Alias-IP-Adressen auf GKE-Pods und -Clustern, um gefälschte Quell-IP-Adressen für den Zugriff auf das Netzwerk zu erkennen und zu blockieren. Ein Cluster, der Alias-IP-Bereiche verwendet, ist ein VPC-nativer Cluster.

Anforderung 1.4.5

Die Offenlegung interner IP-Adressen und Routinginformationen ist auf autorisierte Parteien beschränkt.

Sie können einen GKE-Agent zur IP-Maskierung verwenden, um den NAT-Dienst (Network Address Translation) für mehrere IP-Adressen in einem Cluster zu nutzen. Bei der Maskierung werden mehrere Quell-IP-Adressen hinter einer einzigen IP-Adresse verborgen.

Anforderung 2

Wenden Sie sichere Konfigurationen auf alle Systemkomponenten an.

Anforderung 2 legt fest, wie Sicherheitsparameter durch Entfernen der Standardeinstellungen und der vom Anbieter angegebenen Anmeldeinformationen gehärtet werden. Die Härtung Ihres Clusters liegt in Ihrer Verantwortung als Kunde.

Anforderung 2.2

Anforderung 2.2.4

Nur erforderliche Dienste, Protokolle, Daemons und Funktionen werden aktiviert und alle unnötigen Funktionen werden entfernt oder deaktiviert.

Anforderung 2.2.5

Anforderung 2.2.6

Systemsicherheitsparameter sind so konfiguriert, dass Missbrauch verhindert wird.

Vor dem Deployment

Bevor Sie Container in GKE verschieben, empfehlen wir Folgendes:

• Beginnen Sie mit einem von Containern verwalteten Basis-Image, das von einer vertrauenswürdigen Quelle erstellt, verwaltet und auf Sicherheitslücken geprüft wird. Erwägen Sie die Erstellung einer Reihe von "als funktionierend bekannten" bzw. "goldenen" Basis-Images, die von Ihren Entwicklern verwendet werden können. Eine restriktivere Option ist die Verwendung eines Distroless-Image bzw. eines Scratch-Basis-Image.
• Verwenden Sie Artefaktanalyse, um Ihre Container-Images auf Sicherheitslücken zu überprüfen.
• Richten Sie eine interne DevOps/SecOps-Richtlinie ein, um nur genehmigte, vertrauenswürdige Bibliotheken und Binärdateien in die Container aufzunehmen.

Während der Einrichtung

Während der Einrichtung empfehlen wir Folgendes:

• Verwenden Sie standardmäßig Container-Optimized OS als Knoten-Image für GKE. Container-Optimized OS basiert auf Chromium OS und ist für die Knotensicherheit optimiert.
• Aktivieren Sie automatische Upgrades von Knoten für die Cluster, auf denen Ihre Anwendungen ausgeführt werden. Dieses Feature aktualisiert den Knoten automatisch auf die Kubernetes-Version, die auf der verwalteten Steuerebene ausgeführt wird, und bietet so mehr Stabilität und Sicherheit.
• Aktivieren Sie die automatische Reparatur von Knoten. Wenn dieses Feature aktiviert ist, überprüft GKE regelmäßig den Systemstatus des Knotens und bestimmt anhand dieses Status, ob ein Knoten repariert werden muss. Wenn ein Knoten repariert werden muss, wird auf diesen Knoten Draining angewendet sowie ein neuer Knoten erstellt und dem Cluster hinzugefügt.
• Aktivieren Sie Cloud Monitoring und Cloud Logging, damit alle Ereignisse erfasst werden, einschließlich Sicherheitsereignisse und Systemstatus von Knoten. Erstellen Sie Cloud Monitoring-Benachrichtigungsrichtlinien, um bei einem Sicherheitsvorfall benachrichtigt zu werden.
• Wenden Sie Dienstkonten mit minimalen Berechtigungen für GKE-Knoten an.
• Lesen Sie den GKE-Abschnitt im Google Cloud-CIS-Benchmark und wenden Sie die darin enthaltenen Informationen (bei Bedarf) an. Kubernetes-Audit-Logging ist standardmäßig bereits aktiviert. Logs für Anfragen an sowohl kubectl als auch an die GKE API werden in Cloud-Audit-Logs geschrieben.
• Konfigurieren Sie Audit-Logging.

Kontodaten schützen

Der Schutz von Karteninhaberdaten umfasst die Anforderungen 3 und 4 von PCI DSS.

Anforderung 3

Gespeicherte Kontodaten schützen.

In der Anforderung 3 von PCI DSS ist festgelegt, dass Schutzmechanismen wie Verschlüsselung, Kürzung, Maskierung und Hashing kritische Komponenten zum Schutz von Karteninhaberdaten darstellen. Wenn ein Angreifer andere Sicherheitskontrollen umgeht und ohne die richtigen kryptografischen Schlüssel Zugriff auf verschlüsselte Daten erlangt, sind die Daten für diese Person unlesbar und unbrauchbar.

Sie können auch andere Methoden zum Schutz gespeicherter Daten als potenzielle Möglichkeiten zur Risikominimierung in Betracht ziehen. Zu den Methoden zur Risikominimierung gehören beispielsweise das Speichern von Karteninhaberdaten nur, wenn dies unbedingt erforderlich ist, das Kürzen von Karteninhaberdaten, wenn nicht die vollständige PAN benötigt wird, und der Verzicht auf das Senden ungeschützter PANs mithilfe von Endnutzer-Messaging-Technologien wie E-Mail und Instant Messaging.

Beispiele für Systeme, in denen Karteninhaberdaten im Rahmen der Zahlungsabwicklung bei Ausführung in Google Cloud möglicherweise bestehen bleiben:

• Cloud Storage-Buckets
• BigQuery-Instanzen
• Datastore
• Cloud SQL

Beachten Sie, dass Karteninhaberdaten möglicherweise versehentlich in E-Mail- oder Kundenservice-Kommunikationslogs gespeichert werden. Es wird empfohlen, Sensitive Data Protection zu verwenden, um diese Datenströme zu filtern, um die im Geltungsbereich liegende Umgebung auf die Zahlungsverarbeitungssysteme zu beschränken.

Beachten Sie, dass Daten in Google Cloud standardmäßig im inaktiven Zustand verschlüsselt und standardmäßig bei der Übertragung verschlüsselt werden, wenn sie physische Grenzen überschreiten. Zum Aktivieren dieser Schutzfunktionen ist keine weitere Konfiguration erforderlich.

Anforderung 3.5

Die primäre Kontonummer (PAN) ist sicher, wo sie gespeichert ist.

Einer der Mechanismen, mit denen PAN-Daten unlesbar gemacht werden können, ist die Tokenisierung. Weitere Informationen zur Tokenisierung finden Sie unter Geltungsbereich der Compliance für PCI-Umgebungen in Google Cloud verringern.

Sie können die DLP API verwenden, um die Karteninhaberdaten zu scannen, zu erkennen und in Berichten zu erfassen. Vertraulicher Datenschutz bietet native Unterstützung für das Scannen und Klassifizieren von 12- bis 19-stelligen PAN-Daten in Cloud Storage, BigQuery und Datastore. Es verfügt auch über eine API für Streaming-Inhalte, um die Unterstützung zusätzlicher Datenquellen, benutzerdefinierter Arbeitslasten und Anwendungen zu ermöglichen. Sie können auch die DLP API verwenden, um die Daten zu kürzen (zu entfernen) oder zu hashen.

Anforderung 3.6

Kryptografische Schlüssel zum Schutz gespeicherter Kontodaten werden gesichert.

Cloud Key Management Service (KMS) ist ein verwaltetes Speichersystem für kryptografische Schlüssel. Sie können kryptografische Schlüssel generieren, verwenden, rotieren und löschen. Cloud KMS führt zwar keine direkte Speicherung von Secrets wie Karteninhaberdaten durch, kann jedoch zum Verschlüsseln solcher Daten verwendet werden.

Secrets im Kontext von Kubernetes sind Secret-Objekte von Kubernetes, mit denen Sie vertrauliche Informationen wie Passwörter, Tokens und Schlüssel speichern können.

Google Cloud verschlüsselt inaktive Kundendaten standardmäßig. GKE verarbeitet und verwaltet diese Standardverschlüsselung, sodass von Ihrer Seite keine weiteren Maßnahmen erforderlich sind. Die Verschlüsselung von Secrets auf Anwendungsebene bietet eine zusätzliche Sicherheitsebene für vertrauliche Daten wie Secrets. Mit dieser Funktionalität können Sie einen in Cloud KMS verwalteten Schlüssel verwenden, um Daten auf der Anwendungsebene zu verschlüsseln. Dies schützt vor Angreifern, die Zugriff auf eine Kopie der Kubernetes-Konfigurationsspeicherinstanz Ihres Clusters haben.

Anforderung 4

Karteninhaberdaten mit einer starken Kryptografie während der Übertragung über offene, öffentliche Netzwerke schützen.

Die im Geltungsbereich liegenden Daten müssen während der Übertragung über Netzwerke, auf die Angreifer leicht zugreifen können, verschlüsselt werden. Dazu zählen beispielsweise öffentliche Netzwerke.

Istio ist ein Open-Source-Service Mesh, das sich transparent auf vorhandene verteilte Anwendungen legt. Istio verwaltet die Authentifizierung, Autorisierung und Verschlüsselung des Traffics zwischen Mikrodiensten auf skalierbare Weise. Istio ist eine Plattform mit APIs, die eine Einbindung in jede Logging-Plattform, Telemetrie und jedes Richtliniensystem ermöglicht. Mit den Features von Istio können Sie eine verteilte Mikrodienst-Architektur effizient ausführen und auf einheitliche Weise Mikrodienste sichern, verbinden und überwachen.

Anforderung 4.1

Prozesse und Mechanismen zum Schutz von Karteninhaberdaten mit starker Kryptografie während der Übertragung über offene, öffentliche Netzwerke werden definiert und dokumentiert.

Mit Istio können Sie ein Netzwerk aus bereitgestellten Diensten erstellen – mit Load-Balancing, Dienst-zu-Dienst-Authentifizierung und Monitoring. Sie können damit auch eine sichere Dienst-zu-Dienst-Kommunikation in einem Cluster herstellen – mit starker identitätsbasierter Authentifizierung und Autorisierung basierend auf gegenseitigem TLS. Gegenseitiges TLS (Mutual TLS, mTLS) ist ein TLS-Handshake, der zweimal ausgeführt wird. Dabei wird die gleiche Vertrauensebene in beide Richtungen hergestellt (im Gegensatz zum unidirektionalen Client-Server-Vertrauen).

Mit Istio können Sie TLS-Zertifikate für jeden der GKE-Pods in einer Anwendung bereitstellen. Dienste, die auf dem Pod ausgeführt werden, können mithilfe von mTLS ihre Peer-Identitäten eindeutig identifizieren. Die Dienst-zu-Dienst-Kommunikation erfolgt über clientseitige und serverseitige Envoy. Envoy verwendet SPIFFE, um mTLS-Verbindungen zwischen Diensten herzustellen. Informationen zum Deployment von Istio in GKE finden Sie in der GKE-Dokumentation. Informationen zu unterstützten TLS-Versionen finden Sie in der Istio-Referenz zur Trafficverwaltung. Verwenden Sie die TLS-Version 1.2 und höher.

Wenn Ihre Anwendung dem Internet ausgesetzt ist, verwenden Sie GKE HTTP(S)-Load-Balancing. Dabei muss das Routing von eingehendem Traffic auf HTTP(S) eingestellt sein. Das von einem Ingress-Objekt konfigurierte HTTP(S)-Load-Balancing umfasst die folgenden Features:

• Flexible Konfiguration für Dienste: Ein Ingress-Objekt definiert, wie der Traffic Ihre Dienste erreicht und an Ihre Anwendung weitergeleitet wird. Darüber hinaus stellt ein Ingress-Objekt eine einzelne IP-Adresse für mehrere Dienste in Ihrem Cluster bereit.
• Einbindung in Google Cloud-Netzwerkdienste Ein Ingress-Objekt kann Google Cloud-Features konfigurieren, beispielsweise von Google verwaltete SSL-Zertifikate (Beta), Google Cloud Armor, Cloud CDN und Identity-Aware Proxy.
• Unterstützung mehrerer TLS-Zertifikate: Ein Ingress-Objekt kann die Verwendung mehrerer TLS-Zertifikate für die Beendigung der Anfrage festlegen.

Wenn Sie ein Ingress-Objekt erstellen, konfiguriert der GKE-Ingress-Controller einen Cloud-HTTP(S)-Load-Balancer gemäß den Informationen im Ingress und den zugehörigen Diensten.

Programm zur Verwaltung von Sicherheitslücken pflegen

Das Pflegen eines Programms zur Verwaltung von Sicherheitslücken umfasst die Anforderungen 5 und 6 von PCI DSS.

Anforderung 5

Alle Systeme und Netzwerke vor schädlicher Software schützen.

Die Anforderung 5 von PCI DSS legt fest, dass auf allen Systemen, die häufig von Malware betroffen sind, Antivirensoftware verwendet werden muss, um Systeme vor aktuellen und sich entwickelnden Bedrohungen durch schädliche Software zu schützen. Container sind keine Ausnahme.

Anforderung 5.2

Malware (Malware) wird verhindert oder erkannt und behoben.

Sie müssen Programme zur Verwaltung von Sicherheitslücken für Ihre Container-Images implementieren.

Wir empfehlen Folgendes:

• Überprüfen Sie Container in regelmäßigen Abständen und wenden Sie aktuelle Sicherheitspatches auf Container an.
• Führen Sie regelmäßige Scans auf Sicherheitslücken für containerbasierte Anwendungen und Binärdateien/Bibliotheken durch.
• Scannen Sie Images als Teil der Build-Pipeline.
• Abonnieren Sie einen Dienst zum Erkennen von Sicherheitslücken, um aktuelle Informationen zu Sicherheitslücken zu erhalten, die für die Umgebung und die in den Containern verwendeten Bibliotheken relevant sind.

Google Cloud arbeitet mit verschiedenen Anbietern von Lösungen zur Containersicherheit zusammen, um die Sicherheit in den Google Cloud-Deployments der Kunden zu verbessern. Wir empfehlen die Nutzung validierter Sicherheitslösungen und -technologien, um den Schutz vor Angriffen in Ihrer GKE-Umgebung zu verbessern. Eine aktuelle Liste der Google Cloud-validierten Sicherheitspartner finden Sie unter Sicherheitspartner.

Anforderung 5.2.2

Anforderung 5.2.3

Es gibt viele Lösungen für die Durchführung von Malware-Scans. PCI DSS erkennt jedoch an, dass nicht alle Systeme gleichermaßen anfällig sind. Es ist üblich, dass Händler ihre Linux-Server, Mainframes und ähnliche Computer als nicht "häufig von schädlicher Software betroffen" deklarieren und daher von 5.2.2 ausnehmen. In diesem Fall gilt Anforderung 5.2.3, nach der ein System zur regelmäßigen Bewertung von Bedrohungen implementiert werden muss.

Beachten Sie, dass diese Regeln sowohl für Knoten als auch für Pods in einem GKE-Cluster gelten.

Anforderung 5.3

Anti-Malware-Mechanismen und -Prozesse sind aktiv, werden gewartet und überwacht.

Mit den Anforderungen 5.2, 5.3 und 11.5 werden Antivirenscans und Dateiintegritätsüberwachung (File Integrity Monitoring, FIM) auf allen Hosts innerhalb des Geltungsbereichs verlangt. Es wird empfohlen, eine Lösung zu implementieren, bei der alle Knoten von einem vertrauenswürdigen Agent innerhalb des Clusters gescannt werden können, oder bei der jeder Knoten über einen Scanner verfügt, der Berichte über einzelne Verwaltungsendpunkte erstellen kann.

Weitere Informationen finden Sie in der Sicherheitsübersicht für GKE und in der Sicherheitsübersicht für Container-Optimized OS.

Eine gängige Lösung sowohl für die Antiviren- als auch für die FIM-Anforderungen besteht darin, den Container zu sperren, damit nur bestimmte zulässige Ordner Schreibzugriff haben. Zu diesem Zweck führen Sie Ihre Container als Nutzer ohne Rootberechtigung aus und verwenden Dateisystemberechtigungen, um den Schreibzugriff auf alle Verzeichnisse mit Ausnahme der Arbeitsverzeichnisse im Containerdateisystem zu verhindern. Deaktivieren Sie die Rechteausweitung, um eine Umgehung der Dateisystemregeln zu vermeiden.

Anforderung 6

Entwicklung und Wartung sicherer Systeme und Software.

In der Anforderung 6 von PCI DSS ist festgelegt, dass Sie einen strikten Lebenszyklus für die Softwareentwicklung einrichten, der in jedem Schritt die Einbindung von Sicherheitsmaßnahmen vorsieht.

Anforderung 6.2

Individuelle und maßgeschneiderte Software wird sicher entwickelt.

Anforderung 6.2.1

Sie können die Binärautorisierung verwenden, damit nur vertrauenswürdige Container in GKE bereitgestellt werden. Wenn Sie nur Images aktivieren möchten, die von einem oder mehreren bestimmten Attestierern autorisiert wurden, können Sie die Binärautorisierung zum Erzwingen einer Richtlinie mit Regeln konfigurieren, die Attestierungen auf der Grundlage der Ergebnisse des Scans auf Sicherheitslücken erfordern. Sie können auch Richtlinien erstellen, nach denen eine oder mehrere vertrauenswürdige Parteien (sogenannte "Attestierer") ein Image genehmigen müssen, bevor es bereitgestellt werden kann. Bei einer mehrstufigen Deployment-Pipeline, bei der Images von der Entwicklung über Tests bis hin zu Produktionsclustern übertragen werden, können Attestierer dafür sorgen, dass alle erforderlichen Prozesse abgeschlossen sind, bevor die Software in die nächste Stufe übergeht.

Während des Deployments wird die Richtlinie von der Binärautorisierung erzwungen. Hierbei wird überprüft, ob das Container-Image alle erforderlichen Prüfungen bestanden hat. Dazu gehört die Prüfung der erforderlichen Attestierer, ob das Image für das Deployment bereit ist. Wenn das Image die Prüfung erfolgreich besteht, kann es vom Dienst bereitgestellt werden. Andernfalls wird das Deployment blockiert und das Image kann erst bereitgestellt werden, wenn es kompatibel ist.

Weitere Informationen zur Binärautorisierung finden Sie unter Für GKE einrichten.

Im Notfall können Sie eine Richtlinie der Binärautorisierung mithilfe des Ausnahmezugriff-Workflows umgehen. Alle Ausnahmezugriffvorfälle werden in Cloud-Audit-Logs aufgezeichnet.

GKE Sandbox verringert die Notwendigkeit für direkte Interaktionen zwischen Container und Host. Dies verkleinert auch die Angriffsfläche für Hostmanipulationen und schränkt bösartige Akteure in ihren Möglichkeiten ein.

Anforderung 6.3

Sicherheitslücken werden identifiziert und behoben.

Anforderung 6.3.1

Für die Sicherheit in der Cloud sind der Cloudanbieter und der Kunde gemeinsam verantwortlich.

In GKE verwaltet Google die Steuerungsebene, die die Master-VMs, den API-Server und andere auf diesen VMs ausgeführte Komponenten sowie die etcd-Datenbank enthält. Dies umfasst Upgrades und Patches, Skalierungen und Reparaturen, die alle von einem Service Level Objective (SLO) unterstützt werden. Für das Betriebssystem der Knoten, wie z. B. Container-Optimized OS oder Ubuntu, stellt GKE Patches für diese Images umgehend zur Verfügung. Wenn Sie die Funktion für automatische Upgrades aktiviert haben, werden diese Patches automatisch bereitgestellt. (Dies ist die Basisebene des Containers. Sie ist nicht mit dem Betriebssystem identisch, das in den Containern ausgeführt wird.)

Weitere Informationen zum GKE-Modell der geteilten Verantwortung finden Sie unter Containersicherheit: Modell der geteilten Verantwortung in GKE.

Google bietet verschiedene Sicherheitsdienste, mit denen Sie die Sicherheit Ihrer CI/CD-Pipeline verbessern können. Zum Identifizieren von Sicherheitslücken in Container-Images können Sie Google Artefaktanalyse – Scannen auf Sicherheitslücken verwenden. Wenn ein Container-Image in die Google Container Registry (GCR) übertragen wird, werden Images automatisch auf bekannte Sicherheitslücken und Gefährdungen aus bekannten CVE überprüft. Sicherheitslücken werden Schweregrade (kritisch, hoch, mittel, niedrig und minimal) basierend auf CVSS-Bewertungen zugewiesen.

Anforderung 6.4

Öffentliche Webanwendungen sind vor Angriffen geschützt.

Mit Web Security Scanner können Sie öffentlich zugängliche App Engine-, Compute Engine- und GKE-Webanwendungen auf gängige Sicherheitslücken prüfen – vom Cross-Site-Scripting über Fehlkonfigurationen bis hin zu anfälligen Ressourcen. Scans können bei Bedarf über die Google Cloud Console ausgeführt und geplant werden. Mit den Security Scanner APIs können Sie den Scan als Teil Ihrer Sicherheitstestsuite in der Erstellungspipeline Ihrer Anwendung automatisieren.

Strenge Maßnahmen zur Zugriffssteuerung implementieren

Die Implementierung strenger Maßnahmen zur Zugriffssteuerung umfasst die Anforderungen 7, 8 und 9 von PCI DSS.

Anforderung 7

Zugriff auf Systemkomponenten und Karteninhaberdaten je nach Geschäftsinformationsbedarf beschränken.

Die Anforderung 7 konzentriert sich auf den Grundsatz der geringsten Berechtigung bzw. den Informationsbedarf. Gemäß der Definition von PCI DSS werden hierbei Zugriff auf die geringste Datenmenge und Bereitstellung der geringsten Berechtigungen gewährt, die für die Ausführung eines Jobs erforderlich sind.

Anforderung 7.2

Der Zugriff auf Systemkomponenten und Daten ist entsprechend definiert und zugewiesen.

IAM und die rollenbasierte Zugriffssteuerung von Kubernetes (Role-based Access Control, RBAC) ermöglichen in Kombination eine differenzierte Zugriffssteuerung auf Ihre GKE-Umgebung. IAM wird zum Verwalten des Nutzerzugriffs und der Berechtigungen für Google Cloud-Ressourcen in Ihrem CDE-Projekt verwendet. In GKE können Sie mit IAM auch den Zugriff und die Aktionen verwalten, die Nutzer und Dienstkonten in Ihren Clustern ausführen können, z. B. das Erstellen und Löschen von Clustern.

Mit Kubernetes RBAC können Sie detaillierte Berechtigungssätze konfigurieren, die festlegen, welche Interaktionsmöglichkeiten ein bestimmter Google Cloud-Nutzer, bestimmte Google Cloud-Dienstkonten oder eine bestimmte Gruppe von Nutzern (Google Groups-Gruppe) in Bezug auf ein Kubernetes-Objekt im Cluster oder in einem bestimmten Namespace des Clusters hat. Beispiele für RBAC-Berechtigungen sind das Bearbeiten von Deployments oder ConfigMaps, das Löschen von Pods oder das Anzeigen von Logs aus einem Pod. Sie gewähren Nutzern oder Diensten eingeschränkte IAM-Berechtigungen, z. B. Google Kubernetes Engine-Clusterbetrachter oder benutzerdefinierte Rollen und wenden RBAC-RoleBindings von Kubernetes entsprechend an.

Cloud Identity-Aware Proxy (IAP) kann über Ingress für GKE eingebunden werden, um den Zugriff auf Anwendungsebene für Mitarbeiter oder Personen zu steuern, die Zugriff auf Ihre PCI-Anwendungen benötigen.

Darüber hinaus können Sie mithilfe von Organisationsrichtlinien die in einem Projekt verfügbaren APIs und Dienste einschränken.

Anforderung 7.2.2

Der Grundsatz der geringsten Berechtigung muss nicht nur von Nutzern und Dienstkonten, sondern auch von Containern befolgt werden. Eine bewährte Methode beim Ausführen von Containern besteht darin, den Prozess mit einem Nutzer ohne Rootberechtigung auszuführen. Sie können diese Vorgehensweise mit dem PodSecurity-Admission-Controller ausführen und erzwingen.

PodSecurity ist ein Kubernetes-Admission-Controller, mit dem Sie Pod-Sicherheitsstandards auf Pods anwenden können, die in Ihren GKE-Clustern ausgeführt werden. Pod-Sicherheitsstandards sind vordefinierte Sicherheitsrichtlinien, die die allgemeinen Anforderungen der Pod-Sicherheit in Kubernetes abdecken. Diese Richtlinien reichen von äußerst weit gefassten bis zu sehr restriktiven Richtlinien. PodSecurity ersetzt den vorherigen PodSecurityPolicy-Admission-Controller, der in Kubernetes v1.25 entfernt wurde. Für die Migration von PodSecurityPolicy zum PodSecurity-Admission-Controller sind Anweisungen verfügbar.

Anforderung 8

Nutzer identifizieren und den Zugriff auf Systemkomponenten authentifizieren

Die Anforderung 8 legt fest, dass jeder Person, die Zugriff auf PCI-Systeme im Geltungsbereich hat, eine eindeutige ID zugewiesen werden muss. Damit wird gewährleistet, dass jede Person für ihre Handlungen eindeutig verantwortlich ist.

Anforderung 8.2

Nutzeridentifikation und zugehörige Konten für Nutzer und Administratoren werden während des gesamten Lebenszyklus eines Kontos strikt verwaltet.

Anforderung 8.2.1

Allen Nutzern wird eine eindeutige ID zugewiesen, bevor der Zugriff auf Systemkomponenten oder Karteninhaberdaten zugelassen wird.

Anforderung 8.2.5

Der Zugriff für beendete Nutzer wird sofort widerrufen.

Sowohl IAM als auch Kubernetes RBAC können verwendet werden, um den Zugriff auf Ihren GKE-Cluster zu steuern. In beiden Fällen können Sie einem Nutzer Berechtigungen erteilen. Es wird empfohlen, dass sich die Nutzer auf ihr vorhandenes Identitätssystem beziehen, damit Sie Nutzerkonten und Richtlinien zentral an einem Ort verwalten können.

Anforderung 8.3

Eine starke Authentifizierung für Nutzer und Administratoren wird eingerichtet und verwaltet.

Anforderung 8.3.1

Zertifikate sind an die Identität eines Nutzers gebunden, wenn sie sich bei kubectl authentifizieren. Alle GKE-Cluster sind so konfiguriert, dass sie Identitäten von Google Cloud-Nutzern und -Dienstkonten akzeptieren, indem sie die Anmeldedaten validieren und die mit dem Nutzer oder Dienstkonto verknüpfte E-Mail-Adresse abrufen. Die Anmeldedaten dieser Konten müssen daher für die Authentifizierung den OAuth-Bereich userinfo.email enthalten.

Anforderung 9

Beschränken des physischen Zugriffs auf Karteninhaberdaten.

Google ist verantwortlich für die physischen Sicherheitskontrollen in allen Google-Rechenzentren, die Google Cloud zugrunde liegen.

Netzwerke regelmäßig überwachen und testen

Das regelmäßige Überwachen und Testen von Netzwerken umfasst die Anforderungen 10 und 11 von PCI DSS.

Anforderung 10

Logging und Monitoring des gesamten Zugriffs auf Systemkomponenten und Karteninhaberdaten.

Anforderung 10.2

Audit-Logs werden implementiert, um die Erkennung von Anomalien und verdächtigen Aktivitäten sowie die forensische Analyse von Ereignissen zu unterstützen.

Alle Kubernetes-Cluster bieten Kubernetes-Audit-Logging mit einer chronologischen Aufzeichnung von Aufrufen, die an den Kubernetes API-Server gesendet wurden. Dieses Feature ist standardmäßig aktiviert. Die Einträge im Kubernetes-Audit-Log sind nützlich, um verdächtige API-Anfragen zu untersuchen, Statistiken zu erfassen oder Monitoringbenachrichtigungen für unerwünschte API-Aufrufe zu erstellen.

GKE-Cluster ermöglichen die Einbindung einer Standardkonfiguration für GKE-Audit-Logging mit Cloud-Audit-Logs und Logging. Dadurch können Sie Audit-Logeinträge von Kubernetes im Google Cloud-Projekt ansehen.

Neben den von Kubernetes geschriebenen Einträgen enthalten die Audit-Logs des Projekts auch Einträge, die aus GKE stammen.

Um zwischen CDE- und Nicht-CDE-Workloads zu unterscheiden, empfehlen wir, dass Sie Ihren GKE-Pods Labels hinzufügen, die sich in Messwerten und Logs niederschlagen, die von diesen Arbeitslasten ausgegeben werden.

Anforderung 10.2.2

Jeder Audit-Logeintrag in Logging ist ein Objekt vom Typ LogEntry, das die folgenden Felder enthält:

• Eine Nutzlast vom Typ protoPayload. Die Nutzlast jedes Audit-Logeintrags ist ein Objekt vom Typ AuditLog. Die Nutzeridentität finden Sie im Feld AuthenticationInfo von AuditLog-Objekten.
• Das spezifische Ereignis, das im Feld methodName des Objekts AuditLog aufgeführt ist.
• Einen Zeitstempel
• Den Ereignisstatus, den Sie in den response-Objekten im Objekt AuditLog finden.
• Die Vorgangsanfrage, die Sie in den Objekten request und requestMetadata im Objekt AuditLog finden.
• Den auszuführenden Dienst, den Sie im Objekt AuditData in serviceData finden.

Anforderung 11

Sicherheit von Systemen und Netzwerken regelmäßig testen.

Anforderung 11.3

Externe und interne Sicherheitslücken werden regelmäßig identifiziert, priorisiert und behoben.

Anforderung 11.3.1

Artefaktanalyse führt folgende Arten von Scans auf Sicherheitslücken für Images in Container Registry aus:

• Erstes Scannen: Wenn Sie die Artifact Analysis API zum ersten Mal aktivieren, werden alle Images in Container Registry gescannt und der Paketmanager, die Image-Basis und die Sicherheitslücken für die Images extrahiert.

• Inkrementelles Scannen: Artefaktanalyse scannt neue Images, sobald sie in Container Registry hochgeladen werden.

• Kontinuierliche Analyse: Wenn Artefaktanalyse neue und aktualisierte Informationen zu Sicherheitslücken aus Sicherheitslückenquellen erhält, wird die Analyse der Container noch einmal ausgeführt, damit die Liste der Sicherheitslücken für bereits gescannte Images immer auf dem neuesten Stand bleibt.

Anforderung 11.5

Netzwerkangriffe und unerwartete Dateiänderungen werden erkannt und beantwortet.

Anforderung 11.5.1

Die Paketspiegelung von Google Cloud kann mit Cloud IDS verwendet werden, um Netzwerkangriffe zu erkennen. Die Google Cloud-Paketspiegelung leitet den gesamten Netzwerktraffic von Ihren Compute Engine-VMs oder Google Cloud-Clustern an eine festgelegte Adresse weiter. Cloud IDS kann diesen gespiegelten Traffic nutzen, um eine Vielzahl von Bedrohungen, wie Exploit-Versuche, Portscans, Pufferüberläufe, Protokollfragmentierung, Befehls- und Steuerungszugriffe (C2) und Malware, zu erkennen.

Mit Security Command Center erhalten Sie einen zentralen Überblick über den Sicherheitsstatus von Google Cloud-Diensten (einschließlich GKE) und Assets im gesamten Unternehmen, sodass Bedrohungen leichter verhindert, erkannt und bekämpft werden können. Mithilfe des Security Command Center können Sie anhand Ihrer Cloud Logging-Logs feststellen, ob Bedrohungen mit hohem Risiko erkannt wurden, wie Malware, Kryptomining, nicht autorisierter Zugriff auf Google Cloud-Ressourcen, ausgehende DDoS-Angriffe, Portüberwachung und Brute-Force-SSH.

Informationssicherheitsrichtlinie pflegen

Eine strenge Sicherheitsrichtlinie gibt den Ton bezüglich Sicherheit an und informiert die Menschen darüber, was von ihnen erwartet wird. In diesem Fall bezieht sich "Personen" auf Vollzeit- und Teilzeitbeschäftigte, Zeitarbeiter, Auftragnehmer und Berater, die Zugriff auf Ihre CDE haben.

Anforderung 12

Datensicherheit mit Organisationsrichtlinien und -programmen unterstützen.

Weitere Informationen zu Anforderung 12 finden Sie in der PCI-Matrix für geteilte Verantwortung der Google Cloud.

Bereinigen

Wenn Sie in diesem Artikel Ressourcen verwendet haben, beispielsweise VMs neu gestartet oder die Terraform-Skripts ausgeführt haben, löschen Sie das Projekt, in dem diese Ressourcen verwendet wurden. Dadurch vermeiden Sie Gebühren für Ihr Google Cloud-Konto.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Nächste Schritte

• Weitere Informationen zur Compliance mit dem PCI-Datensicherheitsstandard
• Terraform-Starter-Kit testen
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center