Gemeinsame Verantwortung für AlloyDB Omni

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird beschrieben, wofür Sie als AlloyDB Omni-Kunde verantwortlich sind und wofür Google verantwortlich ist.

Als AlloyDB Omni-Kunde sind Sie dafür verantwortlich, AlloyDB Omni so zu konfigurieren und zu betreiben, dass Ihre Arbeitslasten den größtmöglichen Nutzen aus dem Dienst ziehen.

Layer Verantwortung von Google Verantwortung des Kunden
Hardware und Host Physische Infrastruktur Bei Bedarf Mindest- und empfohlene Anforderungen bereitstellen Physische Server, VMs oder Edge-Geräte wie Stromversorgung, Kühlung und Hardware bereitstellen.
Hostbetriebssystem Bei Bedarf Mindest- und empfohlene Anforderungen bereitstellen Den Linux-Kernel verwalten, Sicherheitspatches für das Betriebssystem anwenden und die Hostknoten härten.
Kubernetes Clusterverwaltung Bei Bedarf Mindest- und empfohlene Anforderungen bereitstellen Den Cluster täglich verwalten, einschließlich Upgrades, und dabei Best Practices der Branche befolgen.
Speicher (CSI/PV) Bei Bedarf Mindest- und empfohlene Anforderungen bereitstellen Die Speicherklasse bereitstellen und die zugrunde liegenden Appliances verwalten. Für AlloyDB Omni ist ein Blockgerät erforderlich. Wählen Sie daher eine Blockgeräteklasse aus.
Netzwerk (CNI) Bei Bedarf Mindest- und empfohlene Anforderungen bereitstellen Die Netzwerkschicht bereitstellen und verwalten, z. B. Pod-Netzwerke, Ingress-Controller, Load-Balancer und Firewallregeln zwischen Knoten.
Rollenbasierte Zugriffssteuerung (RBAC) Die für den AlloyDB Omni-Kubernetes-Operator erforderlichen Dienstkonten, Rollen und Rollenbindungen bereitstellen. Diese Regeln für die rollenbasierte Zugriffssteuerung (RBAC) auf den Cluster anwenden und darauf achten, dass sie mit den internen Sicherheitsrichtlinien übereinstimmen. Um auf AlloyDB Omni-Ressourcen zuzugreifen, zusätzliche RBAC-Rollen und Rollenbindungen erstellen.
Secret-Verwaltung Standard-Kubernetes-Secrets lesen, um Ressourcen wie den ersten postgres-Nutzer bereitzustellen. Kubernetes-Secrets im Cluster erstellen, schützen und rotieren.
Zertifikatsverwaltung Standard-Kubernetes-Secrets und cert-manager für die Zertifikatsintegration verwenden. cert-manager installieren, konfigurieren und den Lebenszyklus verwalten.
Operator software Entwicklung und Release Die AlloyDB Omni-Operatorlogik und CRDs entwickeln und Container-Images, Helm-Diagramme und OLM-Bundles veröffentlichen. – Sie können in Artifact Registry gespeicherte Artefakte für Ihre Bereitstellungen verwenden.
Installation und Lebenszyklus Dokumentation und Upgrade-Artefakte bereitstellen.
  • Die Kompatibilitätstabelle prüfen, bevor Sie den AlloyDB Omni-Operator installieren oder aktualisieren.
  • Der Anleitung folgen, um zu installieren oder zu aktualisieren AlloyDB Omni-Komponenten.
Datenbankmodul Binärdatei der Datenbank Die AlloyDB Omni-Container-Images mit proprietären Optimierungen wie der spaltenbasierten Engine und der KI-Beschleunigung bereitstellen. –
Patchen Sicherheitspatches und Updates für Neben- und Hauptversionen für das Modul veröffentlichen. Eine Upgradeanleitung bereitstellen. Upgrades so bald wie möglich planen, je nach Kritikalität der einzelnen Releases.
Nutzerverwaltung
  • Die ersten AlloyDB Omni-Operatornutzer bereitstellen.
  • Den postgres-Superuser für Nutzer mit einem vom Nutzer bereitgestellten Passwort aus einem Kubernetes-Secret bereitstellen.
  • Eine Anleitung zur Integration in Microsoft Active Directory bereitstellen.
  • Das Passwort für den ersten Superuser mit einem Kubernetes-Secret bereitstellen.
  • Alle anderen Rollen und Nutzer erstellen und verwalten.
Datenverwaltung Sicherungen Die CRDs `BackupPlan` und `Backup` sowie die Logik zum Verwalten von Sicherungen bereitstellen, die mit pgBackrest mit S3-kompatibler Integration verwaltet werden. Sicherungszeitpläne und Aufbewahrungsfristen konfigurieren und den lokalen, S3- oder Cloud Storage-Zielspeicher-Bucket bereitstellen.
Hochverfügbarkeit (HA) Die Logik für das automatische Failover und die Mechanismen zur Fehlerbehebung bereitstellen. Genügend Knoten und Zonen bereitstellen, um ein Standby-Ziel für das Failover bereitzustellen.
Verschlüsselung (ruhende Daten) Unterstützung für transparente Datenverschlüsselung (Transparent Data Encryption, TDE) bereitstellen. Die Verschlüsselung der Speicherebene verwalten, um sicherzustellen, dass sie Ihren Anforderungen entspricht.
Verschlüsselung (während der Übertragung) mTLS für interne Operator-Komponenten bereitstellen und serverseitiges TLS für Verbindungen zwischen Nutzer und Datenbank konfigurieren. Mit sicheren TLS-Clients eine Verbindung zur Datenbank herstellen und die zugrunde liegende Zertifikatsinfrastruktur verwalten.
Beobachtbarkeit Messwerte Interne Datenbankmesswerte über einen Prometheus-kompatiblen Endpunkt verfügbar machen. Den Scraper mit Prometheus, OpenTelemetry oder anderen kompatiblen Lösungen und dem zugehörigen Speicher-Stack bereitstellen und verwalten. Den allgemeinen Zustand des Systems überwachen.
Logging PostgreSQL- und Audit-Logs in Dateien auf dem Laufwerk im Container schreiben und rotieren. Log-Collector wie Fluentd und Fluent Bit bereitstellen, um Logs an ein Speicher-Backend wie Splunk oder ELK zu senden. Darauf achten, dass die Log-Collector so konfiguriert sind, dass Logs mindestens einen Monat lang aufbewahrt werden.
Visualisierung Beispiel-Dashboards für Messwerte und Logs bereitstellen, um Standardarbeitslasten zu überwachen. Das Visualisierungstool wie Grafana bereitstellen und den Zustand überwachen. Dashboards erstellen und in Ihre täglichen Betriebsaufgaben einbinden.
Benachrichtigungen – Die Benachrichtigungspipeline verwalten, z. B. die PagerDuty-Integration.
Support Fehlerbehebung Support für Softwarefehler und Modulfehler bereitstellen. Für diesen Support ist ein Lizenzabo erforderlich. Ersten Support über die Dokumentation und die Wissensdatenbank bereitstellen. Probleme im Zusammenhang mit der Infrastruktur beheben.

Sicherheit und FIPS-Compliance

Zum Schutz Ihrer Daten verwendet AlloyDB Omni kryptografische Module, die gemäß FIPS (Federal Information Processing Standards) 140-2 oder 140-3 validiert wurden. Die FIPS-Compliance ist eine gemeinsame Verantwortung von Google und dem Kunden.

Das folgende Diagramm zeigt, wie die Verantwortung für die FIPS-Compliance zwischen Google und dem Kunden auf die Architekturebenen von AlloyDB Omni aufgeteilt ist.

Diagramm mit den Verantwortlichkeitsgrenzen für die FIPS-Compliance, in dem die Verantwortlichkeiten zwischen Google, dem Kunden und gemeinsamen Bereichen aufgeteilt werden.

In der folgenden Tabelle werden die FIPS-Grenzen und -Verantwortlichkeiten für AlloyDB Omni beschrieben:

FIPS-Grenze Verantwortung Beschreibung
FIPS-konforme Hardware Kunde Physische Hardware und kryptografische Komponenten müssen NIST-zertifiziert und in einem FIPS-genehmigten Zustand konfiguriert sein.
Betriebssystem der Kubernetes-Knoten Kunde Das Hostbetriebssystem des Worker-Knotens, z. B. RHEL, muss im FIPS-Modus ausgeführt werden. Der FIPS-Status muss überprüft werden (cat /proc/sys/crypto/fips_enabled gibt 1 zurück).
Kubernetes-Steuerungsebene Kunde Komponenten der Steuerungsebene wie kubelet sowie Netzwerk- und Speicher-Plug-ins müssen FIPS-validierte kryptografische Module verwenden, z. B. solche, die mit Go-BoringCrypto erstellt wurden.
AlloyDB Omni-Operator-Controller Google Von Google entwickelt, auf einem FIPS-konformen Basis-Image (Red Hat UBI) aufgebaut, wobei die FIPS-Compliance auf dem Container aktiviert ist, auf dem die Datenbank ausgeführt wird.
AlloyDB Omni-Container-Image Google Verwendet FIPS-konforme kryptografische Bibliotheken wie BoringSSL und erzwingt FIPS-genehmigte Algorithmen für das Passwort-Hashing (scram-sha-256) und TLS-Verschlüsselungssuites.
Zertifikate von benutzerdefinierter CA Gemeinsam Digitale Zertifikate müssen die FIPS-Standards für die Schlüsselstärke und die Signaturalgorithmen erfüllen. Die Zertifikatskette muss zu einer FIPS-konformen Stamm-CA zurückverfolgt werden.

Gemeinsame Verantwortung für STIG

Die Defense Information Systems Agency (DISA) veröffentlicht Security Technical Implementation Guides (STIGs), um Cybersicherheitsstandards und Härtungsanforderungen für Software, Betriebssysteme und Datenbanken festzulegen. In diesen Leitfäden werden bestimmte Sicherheitsparameter definiert, um Systeme vor Schwachstellen und Cyberbedrohungen zu schützen.

Eine vollständige Liste der STIG-Regeln finden Sie unter AlloyDB Omni-STIG-Compliance.

Die Härtung Ihrer Umgebung gemäß den STIG-Anforderungen ist unerlässlich, um in hochsicheren oder staatlichen Sektoren eine Betriebsgenehmigung (Authorization to Operate, ATO) zu erhalten. AlloyDB Omni implementiert standardmäßig viele Sicherheitskontrollen auf Datenbankebene. Die vollständige STIG-Compliance ist jedoch eine gemeinsame Verantwortung, bei der der Kunde Einstellungen auf Infrastrukturebene konfigurieren und überprüfen muss.

In der folgenden Tabelle sind alle STIG-Schwachstellen-IDs aufgeführt, für die eine Aktion, Validierung oder Konfiguration durch den Kunden erforderlich ist. Umfassende Informationen finden Sie in der Checkliste für die STIG-Compliance (Security Technical Implementation Guide) für PostgreSQL 9.x unter Red Hat Enterprise Linux.

STIG- oder SRG-ID Beschreibung der Sicherheitskontrolle Standardverhalten von Plattform und Operator Erforderliche Kundenaktion oder -konfiguration
V-233535 Supportmitarbeiter sofort über Fehler im Audit-Log informieren. Standardmäßige Fehlerdiagnosen werden in stdout und stderr des Containers geschrieben. Der Kunde muss SIEM- oder Log-Forwarder-Messwerte konfigurieren, z. B. Splunk-/Elastic-Benachrichtigungen, die ausgelöst werden, wenn die Aufnahme sinkt.
V-233599 Supportmitarbeiter benachrichtigen, wenn der Auditspeicher 75% der Kapazität erreicht. Dateisystemmesswerte werden über Standard-Prometheus-Endpunkte verfügbar gemacht. Der Kunde muss Benachrichtigungsregeln in Prometheus und Grafana einrichten, um den Support zu benachrichtigen, wenn der Speicherplatz von /obs/ 75 % überschreitet.
V-233610 Audit-Daten an eine separate Einrichtung für kontinuierliche Logs auslagern. Audit-Logs werden dauerhaft in das Volume /obs/diagnostic/ geschrieben. Der Kunde muss einen Log-Forwarder konfigurieren, z. B. FluentBit und Vector, um Logdateien kontinuierlich an ein zentrales SIEM zu streamen.
V-233603 Nur Endentitätszertifikaten vertrauen, die von der Public Key Infrastructure (PKI) oder genehmigten Zertifizierungsstellen (Certificate Authorities, CAs) ausgestellt wurden. Der Operator verwendet cert-manager, um lokale TLS-Konfigurationen zu konfigurieren. Der Kunde muss dem Operator seine PKI-Root- und Intermediate-CA-Zertifikate zur Verfügung stellen, um die Vertrauenskette einzurichten.
V-233520 Genehmigte logische Zugriffsberechtigungen erzwingen. Lehnt Klartextpasswörter und den Message-Digest-Algorithmus 5 (MD5) ab. Ermöglicht scram-sha-256 über SSL. Der Kunde muss Clients so konfigurieren, dass sie SCRAM-SHA-256 mit sslmode=verify-full in ihren Verbindungsstrings verwenden.
V-233522 Grenzwerte für gleichzeitige Sitzungen pro Nutzer festlegen. Für Standarddatenbankrollen gelten unbegrenzte Grenzwerte, die durch max_connections begrenzt werden. Der Kunde muss die Verbindungslimits für benutzerdefinierte Anwendungsrollen explizit ändern (ALTER ROLE ... CONNECTION LIMIT).
V-233584 NSA-genehmigte Kryptografie für klassifizierte Informationen im Ruhezustand verwenden. Der Datenbankcontainer verwendet sichere, gehärtete UBI9-Basisebenen. Der Kunde muss prüfen, ob der zugrunde liegende Kubernetes-Hostkernel den FIPS 140-Modus aktiviert hat.
V-233515 Authentifizierungsmechanismen auf Organisationsebene in Active Directory (AD) und Lightweight Directory Access Protocol (LDAP) einbinden. Der Operator unterstützt benutzerdefinierte Authentifizierungskonfigurationen. Der Kunde muss AD- und LDAP-Identitäten in der Datenbankclusterkonfiguration zuordnen.
V-233583 FIPS-validierte kryptografische Module für Hashes verwenden. Der Container verwendet OpenSSL-FIPS-Module des Hosts für Hashing-Funktionen. Der Kunde muss den FIPS-Modus auf den Host-VM-Knoten aktivieren.
V-233585 FIPS-validierte Kryptografie verwenden, um nicht klassifizierte Informationen zu schützen. Kommunikation und Speicherung mit FIPS-fähigen Verschlüsselungen verschlüsseln. Der Kunde muss prüfen, ob die Hostknoten FIPS-validiert sind.
V-233619 FIPS-validierte Kryptografiemodule für alle Vorgänge verwenden. Erzwingt UBI9-Container-Image-Binärdateien, die für FIPS geeignet sind. Der Kunde muss den FIPS-Modus auf dem Hostkernel aktivieren.
V-233623 Darauf achten, dass das DBMS auf einem Host mit zertifiziertem OpenSSL-FIPS ausgeführt wird. Datenbank-Pods verwenden OpenSSL-FIPS-Konfigurationen des Hosts. Der Kunde muss prüfen, ob OpenSSL des Hosts mit der NIST-zertifizierten FIPS-Liste übereinstimmt.
V-233615 PKI-authentifizierte Identitäten zu den zugehörigen Nutzerkonten zuordnen. Der Operator verwendet die sichere SCRAM-SHA-256-Passwortauthentifizierung für Identitäten. Der Kunde muss externe Organisationsverzeichnisrollen Datenbankrollen zuordnen, wenn er sich nicht direkt mit einem Passwort anmeldet.
V-233540 Das Konto für die Datenbankinstallation auf autorisierte Nutzer beschränken. Der Container beschränkt Dateiberechtigungen und die Ausführung auf den postgres-Nutzer. Der Kunde muss den Zugriff auf Hostknoten (SSH/Kubectl) sperren, um unbefugten Terminalzugriff auf die Pods zu verhindern.