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, wenn Sie die Bereitstellungsoption mit dem RPM-Orchestrator verwenden.

Als AlloyDB Omni-Kunde sind Sie dafür verantwortlich, AlloyDB Omni so zu konfigurieren und zu betreiben, dass Ihre Arbeitslasten den Dienst optimal nutzen.

Matrix der gemeinsamen Verantwortung

In der folgenden Tabelle sind die Verantwortlichkeiten von Google und dem Kunden auf jeder Ebene einer AlloyDB Omni-Bereitstellung mit dem RPM-Orchestrator zusammengefasst:

Ebene Verantwortlichkeit von Google Verantwortlichkeit des Kunden
Hardware und Host Physische Infrastruktur Bei Bedarf Mindest- und empfohlene Anforderungen bereitstellen. Physische Server, VMs oder Edge-Geräte bereitstellen, einschließlich Stromversorgung, Kühlung und Hardware.
Hostbetriebssystem Bei Bedarf Mindest- und empfohlene Anforderungen bereitstellen. Den Linux-Kernel verwalten, Sicherheitspatches für das Betriebssystem anwenden und die Hostknoten härten (z. B. RHEL 9 oder Rocky Linux 9).
Infrastruktur- und Betriebssystemkomponenten Speicher Bei Bedarf Mindest- und empfohlene Anforderungen bereitstellen. Lokale Laufwerke oder SAN-Volumes bereitstellen. Für AlloyDB Omni ist ein Blockgerät erforderlich, das mit einem unterstützten Dateisystem wie XFS oder ext4 konfiguriert ist.
Netzwerk Bei Bedarf Mindest- und empfohlene Anforderungen bereitstellen. Die Netzwerkschicht bereitstellen und verwalten, z. B. IP-Routing, Load-Balancer und Firewallregeln mit firewalld oder iptables, um erforderliche Ports wie 5432 für PostgreSQL und 2379 und 2380 für etcd zu öffnen.
Zugriffssteuerung für Hosts Die für die AlloyDB Omni-Orchestratorkomponenten erforderlichen Dienstkonten und Rollen bereitstellen. SSH-Zugriff, sudo-Berechtigungen, SELinux-Richtlinien und Linux-Nutzerkonten gemäß Ihren internen Sicherheitsrichtlinien verwalten.
Secret-Verwaltung Standardvariablen und Inventardateien lesen, um Ressourcen bereitzustellen, z. B. den ersten postgres-Nutzer. Passwörter, SSH-Schlüssel und Tokens, die für die Ansible-Orchestrierung und den Datenbankzugriff verwendet werden, sicher speichern.
Zertifikatsverwaltung Konfigurationsoptionen für die Zertifikatsintegration bereitstellen. Den Lebenszyklus von Transport Layer Security (TLS)- und SSL-Zertifikaten auf den Hostmaschinen generieren, verteilen und verwalten.
Orchestrator-Software Entwicklung und Release Den AlloyDB Omni-Orchestrator entwickeln, einschließlich CLI- und Ansible-Sammlungen, und RPM-Pakete veröffentlichen. – Sie können Artefakte aus dem bereitgestellten Yum-Repository für Ihre Bereitstellungen verwenden.
Installation und Lebenszyklus Dokumentation, RPM-Artefakte und Vorlagen für die Bereitstellungsinventur bereitstellen.

Kompatibilität vor der Installation prüfen.

Folgen Sie der Anleitung, um AlloyDB Omni mit der alloydbctl-Orchestrator-CLI oder Ansible-Playbooks zu installieren oder zu aktualisieren.
Datenbankmodul Binärdatei der Datenbank Die AlloyDB Omni-RPM-Pakete 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. Anleitung für das Upgrade bereitstellen. Upgrades so bald wie möglich planen, je nach Kritikalität der einzelnen Releases.
Nutzerverwaltung

Die ersten administrativen Nutzer bereitstellen.

Den für Nutzer sichtbaren postgres-Superuser bereitstellen.

Anleitung für die LDAP- und Active Directory-Integration bereitstellen.

Das Passwort für den ersten Superuser bereitstellen.

Alle anderen Rollen und Nutzer erstellen und verwalten.
Datenverwaltung Sicherungen Die Automatisierung zur Verwaltung von Sicherungen mit pgBackRest mit S3-kompatibler Integration bereitstellen. Sicherungszeitpläne und Aufbewahrungsfristen konfigurieren und den lokalen, S3- oder Cloud Storage-Zielbucket bereitstellen.
Hochverfügbarkeit (HA) Die Logik für das automatische Failover und die Mechanismen zur Wiederherstellung mit etcd und dem Cluster Manager bereitstellen. Ausreichend Knoten bereitstellen, z. B. einen Steuerknoten, etcd-Knoten und primäre und Standby-Datenbankknoten, um Failover- und Hochverfügbarkeitsarchitekturen zu unterstützen.
Verschlüsselung ruhender Daten Bereitstellungen auf verschlüsselten Volumes auf Blockebene unterstützen. Die Verschlüsselung der Speicherebene verwalten, z. B. Linux Unified Key Setup (LUKS) und dm-crypt, um Ihre Sicherheitsanforderungen zu erfüllen.
Verschlüsselung während der Übertragung Serverseitiges TLS für Verbindungen zwischen Nutzern und Datenbanken sowie für die interne Clusterkommunikation 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 bereitstellen. Den Scraper mit Prometheus, OpenTelemetry oder anderen kompatiblen Lösungen und deren Speicherstack bereitstellen und verwalten. Den Gesamtzustand des Systems überwachen.
Logging PostgreSQL- und Audit-Logs in Dateien auf der Festplatte schreiben und die Rotation verwalten. Log-Collector wie Fluent Bit oder Vector bereitstellen, um Logs an ein Speicher-Backend wie Splunk oder den ELK-Stack zu senden. Logs mindestens einen Monat lang aufbewahren.
Visualisierung Beispielmesswerte und Dashboards zur Überwachung von Standardarbeitslasten bereitstellen. Ein Visualisierungstool wie Grafana bereitstellen und dessen Zustand überwachen. Dashboards erstellen und in Ihre täglichen Betriebsaufgaben einbinden.
Benachrichtigungen – Die Benachrichtigungspipeline verwalten, z. B. mit einer PagerDuty-Integration.
Support Fehlerbehebung Support für Softwarefehler und Modulfehler bereitstellen. Für diesen Support ist ein Abo erforderlich. Ersten Support über die Dokumentation und die Wissensdatenbank bereitstellen. Infrastrukturbezogene Probleme beheben.

Sicherheit und FIPS-Compliance

Zum Schutz Ihrer Daten verwendet AlloyDB Omni kryptografische Module, die gemäß FIPS 140-2 oder 140-3 validiert wurden. Die FIPS-Compliance ist eine gemeinsame Verantwortung zwischen Google und dem Kunden, wie in der folgenden Tabelle beschrieben:

FIPS-Grenze Zuständigkeit Beschreibung
FIPS-konforme Hardware Kunde Physische Hardware und kryptografische Komponenten müssen vom NIST zertifiziert und in einem FIPS-genehmigten Zustand konfiguriert sein.
Hostbetriebssystem Kunde Das Betriebssystem der VM oder des Bare-Metal-Hosts (z. B. RHEL 9) muss im FIPS-Modus ausgeführt werden. Prüfen Sie, ob der Befehl cat /proc/sys/crypto/fips_enabled den Wert 1 zurückgibt.
Steuerungsebene des Orchestrators Kunde Der Steuerknoten, auf dem der Ansible-Orchestrator oder die CLI ausgeführt wird, muss eine FIPS-validierte Betriebssystemkonfiguration verwenden.
Orchestratorkomponenten Google Von Google entwickelt, als RPMs verteilt, die mit einem FIPS-fähigen Basisbetriebssystem kompatibel sind, und Clusteroperationen sicher verwalten.
Binärdateien der Datenbank Google Mit FIPS-validierten OpenSSL-Kryptografiemodulen des Hosts verknüpfen und FIPS-genehmigte Algorithmen für das Passwort-Hashing (SCRAM-SHA-256) und TLS-Cipher Suites erzwingen.
Zertifikate von benutzerdefinierter Zertifizierungsstelle Freigegeben 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 Root-Zertifizierungsstelle 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.

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 zwar 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 die STIG-Schwachstellen-IDs aufgeführt, für die Maßnahmen, Validierung oder Konfiguration durch den Kunden erforderlich sind. Umfassende Informationen finden Sie in der Checkliste zur Einhaltung des Security Technical Implementation Guide (STIG) für PostgreSQL 9.x unter Red Hat Enterprise Linux.

STIG- oder SRG-ID Beschreibung der Sicherheitskontrolle Standardverhalten von Plattform und Operator Erforderliche Maßnahmen oder Konfiguration durch den Kunden
V-233535 Supportmitarbeiter sofort über Fehler im Audit-Log informieren. Standardfehlerdiagnosen werden in stdout und stderr geschrieben. Der Kunde muss SIEM- oder Log-Forwarder-Messwerte so konfigurieren, dass sie 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 bereitgestellt. Der Kunde muss Benachrichtigungsregeln in Prometheus und Grafana einrichten, um den Support zu benachrichtigen, wenn der Speicherplatz auf der Log-Festplatte 75 % übersteigt.
V-233610 Audit-Daten an eine separate Einrichtung für kontinuierliche Logs auslagern. Audit-Logs werden dauerhaft in das lokale Logverzeichnis geschrieben. Der Kunde muss einen Log-Forwarder konfigurieren, 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 (CAs) ausgestellt wurden. Der Orchestrator verwendet lokale TLS-Konfigurationen. Der Kunde muss die Root- und Intermediate-CA-Zertifikate seiner PKI bereitstellen, um die Vertrauenskette einzurichten.
V-233520 Genehmigte logische Zugriffsberechtigungen erzwingen. Lehnt Nur-Text-Passwörter und den Message-Digest-Algorithmus 5 (MD5) ab. SCRAM-SHA-256 über SSL zulassen. Der Kunde muss Clients so konfigurieren, dass sie SCRAM-SHA-256 mit sslmode=verify-full in ihren Verbindungsstrings verwenden.
V-233522 Gleichzeitige Sitzungsgrenzwerte pro Nutzer begrenzen. Standarddatenbankrollen haben unbegrenzte Grenzwerte, die durch max_connections begrenzt werden. Der Kunde muss die Verbindungslimits explizit mit ALTER ROLE ... CONNECTION LIMIT für benutzerdefinierte Anwendungsrollen ändern.
V-233584 NSA-genehmigte Kryptografie für klassifizierte ruhende Informationen verwenden. RPM-Pakete basieren auf sicheren, gehärteten RHEL 9-Bibliotheken. Der Kunde muss prüfen, ob der FIPS 140-Modus für den zugrunde liegenden Linux-Kernel des Hosts aktiviert ist.
V-233515 In die Authentifizierungsmechanismen auf Organisationsebene von AD und LDAP einbinden. Die Datenbank 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. RPMs verwenden OpenSSL-FIPS-Module des Hosts für Hashing-Funktionen. Der Kunde muss den FIPS-Modus im Hostbetriebssystem aktivieren.
V-233585 FIPS-validierte Kryptografie zum Schutz nicht klassifizierter Informationen verwenden. Kommunikation und Speicherung mit FIPS-fähigen Verschlüsselungen verschlüsseln. Der Kunde muss prüfen, ob die Hostmaschinen FIPS-validiert sind.
V-233619 FIPS-validierte Kryptografiemodule für alle Vorgänge verwenden. Erzwingt FIPS-fähige RPM-Binärdateien. Der Kunde muss den FIPS-Modus im Hostkernel aktivieren.
V-233623 Das DBMS auf einem Host mit einem zertifizierten OpenSSL-FIPS-Modul ausführen. Die Datenbank basiert auf OpenSSL-FIPS-Konfigurationen des Hosts. Der Kunde muss prüfen, ob das OpenSSL-Modul des Hosts mit der NIST-zertifizierten FIPS-Liste übereinstimmt.
V-233615 PKI-authentifizierte Identitäten den zugehörigen Nutzerkonten zuordnen. Die Datenbank verwendet die sichere SCRAM-SHA-256-Passwortauthentifizierung für Identitäten. Der Kunde muss Rollen aus dem externen Organisationsverzeichnis Datenbankrollen zuordnen, wenn er sich nicht direkt mit einem Passwort anmeldet.
V-233540 Das Konto für die Datenbankinstallation auf autorisierte Nutzer beschränken. RPM beschränkt Dateiberechtigungen und die Ausführung auf den postgres-Nutzer. Der Kunde muss den Zugriff auf Hostknoten sperren, z. B. mit SSH-Beschränkungen, um unbefugten Terminalzugriff auf die VMs zu verhindern.