Als AlloyDB Omni-Kunde sind Sie dafür verantwortlich, AlloyDB Omni so zu konfigurieren und zu betreiben, dass Ihre Arbeitslasten den Dienst optimal nutzen.
| Ebene | Verantwortlichkeit von Google | Verantwortung des Kunden | |
|---|---|---|---|
| Hardware und Host | Physische Infrastruktur | Geben Sie gegebenenfalls Mindestanforderungen und empfohlene Anforderungen an. | Stellen Sie physische Server, VMs oder Edge-Geräte wie Stromversorgung, Kühlung und Hardware bereit. |
| Hostbetriebssystem | Geben Sie gegebenenfalls Mindestanforderungen und empfohlene Anforderungen an. | Verwalten Sie den Linux-Kernel, wenden Sie Betriebssystem-Sicherheitspatches an und härten Sie die Hostknoten. | |
| Kubernetes | Clusterverwaltung | Geben Sie gegebenenfalls Mindestanforderungen und empfohlene Anforderungen an. | Verwalten Sie den Cluster täglich, einschließlich Upgrades, gemäß den branchenüblichen Best Practices. |
| Speicher (CSI/PV) | Geben Sie gegebenenfalls Mindestanforderungen und empfohlene Anforderungen an. | Stellen Sie die Speicherklasse bereit und verwalten Sie die zugrunde liegenden Geräte. Für AlloyDB Omni ist ein Blockgerät erforderlich. Wählen Sie daher eine Blockgeräteklasse aus. | |
| Netzwerk (CNI) | Geben Sie gegebenenfalls Mindestanforderungen und empfohlene Anforderungen an. | Bereitstellung und Verwaltung der Netzwerkschicht, z. B. Pod-Netzwerke, Ingress-Controller, Load Balancer und Firewallregeln zwischen Knoten. | |
| Rollenbasierte Zugriffssteuerung | Geben Sie die für den AlloyDB Omni Kubernetes-Operator erforderlichen Dienstkonten, Rollen und Rollenbindungen an. | Wenden Sie diese Regeln für die rollenbasierte Zugriffssteuerung (RBAC) auf den Cluster an und achten Sie darauf, dass sie mit den internen Sicherheitsrichtlinien übereinstimmen. Wenn Sie auf AlloyDB Omni-Ressourcen zugreifen möchten, erstellen Sie zusätzliche RBAC-Rollen und ‑Rollenbindungen. | |
| Secret-Verwaltung | Standardmäßige Kubernetes-Secrets lesen, um Ressourcen wie den ersten postgres-Nutzer bereitzustellen. |
Kubernetes-Secrets im Cluster erstellen, schützen und rotieren. | |
| Zertifikatsverwaltung | Verwenden Sie standardmäßige Kubernetes-Secrets und cert-manager für die Zertifikatsintegration. |
cert-manager installieren, konfigurieren und den Lebenszyklus verwalten. |
|
| Operator-Software | Entwicklung und Veröffentlichung | Entwickeln Sie die Logik und CRDs des AlloyDB Omni-Operators und veröffentlichen Sie Container-Images, Helm-Diagramme und OLM-Bundles. | Keine. Sie können in Artifact Registry gespeicherte Artefakte für Ihre Bereitstellungen verwenden. |
| Installation und Lebenszyklus | Dokumentation und Upgrade-Artefakte bereitstellen |
|
|
| Datenbankmodul | Binärdatei der Datenbank | Bereitstellung der AlloyDB Omni-Container-Images mit proprietären Optimierungen wie der spaltenbasierten Engine und KI-Beschleunigung. | Keine. |
| Patchen | Sicherheitspatches und Updates für Neben- und Hauptversionen für die Engine veröffentlichen. Stellen Sie eine Anleitung für das Upgrade bereit. | Planen Sie Upgrades so bald wie möglich ein, je nach Wichtigkeit der einzelnen Releases. | |
| Nutzerverwaltung |
|
|
|
| Datenverwaltung | Sicherungen | Stellen Sie die CRDs `BackupPlan` und `Backup` sowie die Logik zum Verwalten von Sicherungen bereit, die mit pgBackrest mit S3-kompatibler Integration verwaltet werden. |
Konfigurieren Sie Sicherungszeitpläne und Aufbewahrungsrichtlinien und stellen Sie den lokalen, S3- oder Cloud Storage-Ziel-Bucket bereit. |
| Hochverfügbarkeit (HA) | Stellen Sie die Logik für das automatische Failover und die Reparaturmechanismen bereit. | Stellen Sie genügend Knoten und Zonen bereit, um ein Stand-by-Ziel für den Failover zu haben. | |
| Verschlüsselung (inaktive Daten) | Unterstützung für Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) | Verwalten Sie die Verschlüsselung der Speicherebene, 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 Nutzern und Datenbanken konfigurieren. | Stellen Sie eine Verbindung zur Datenbank über sichere TLS-Clients her und verwalten Sie die zugrunde liegende Zertifikatinfrastruktur. | |
| Beobachtbarkeit | Messwerte | Interne Datenbankmesswerte über einen mit Prometheus kompatiblen Endpunkt verfügbar machen. | Stellen Sie den Scraper mit Prometheus, OpenTelemetry oder anderen kompatiblen Lösungen und deren Speichereinheit bereit und verwalten Sie ihn. Gesamtzustand des Systems überwachen. |
| Logging | PostgreSQL- und Audit-Logs in Dateien auf der Festplatte im Container schreiben und rotieren. | Stellen Sie Log-Collector wie Fluentd und Fluent Bit bereit, um Logs an ein Speicher-Back-End (z. B. Splunk oder ELK) zu senden. Achten Sie darauf, dass die Log-Collector so konfiguriert sind, dass Logs für mindestens einen Monat aufbewahrt werden. | |
| Visualisierung | Beispieldashboards für Messwerte und Logs zum Überwachen von Standardarbeitslasten bereitstellen. | Stellen Sie das Visualisierungstool wie Grafana bereit und überwachen Sie seinen Zustand. Dashboards erstellen und in Ihre täglichen betrieblichen Aufgaben einbinden | |
| Benachrichtigungen | Keine | Benachrichtigungspipeline verwalten, z. B. PagerDuty-Integration | |
| Support | Fehlerbehebung | Support für Softwarefehler und Engine-Fehler Für diesen Support benötigen Sie ein Lizenzabo. | Bieten Sie ersten Support über Dokumentation und Wissensdatenbank. Infrastrukturbezogene Probleme beheben |
Sicherheit und FIPS-Compliance
Zum Schutz Ihrer Daten verwendet AlloyDB Omni kryptografische Module, die gemäß Federal Information Processing Standards (FIPS) 140‑2 oder 140‑3 validiert wurden. Die FIPS-Compliance ist eine geteilte Verantwortung zwischen Google und dem Kunden.
Das folgende Diagramm zeigt, wie die Verantwortung für die FIPS-Konformität zwischen Google und dem Kunden auf die Architekturschichten von AlloyDB Omni aufgeteilt ist.
In der folgenden Tabelle werden die FIPS-Grenzen und Verantwortlichkeiten für AlloyDB Omni beschrieben:
| FIPS-Grenzschicht | Zuständigkeit | Beschreibung |
|---|---|---|
| FIPS-konforme Hardware | Kunde | Physische Hardware und kryptografische Komponenten müssen NIST-zertifiziert und in einem FIPS-genehmigten Zustand konfiguriert sein. |
| Betriebssystem von Kubernetes-Knoten | Kunde | Das Betriebssystem des Worker-Knoten-Hosts, 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 | Steuerungsebenenkomponenten wie kubelet sowie Netzwerk- und Speicher-Plug-ins müssen FIPS-validierte kryptografische Module verwenden, die beispielsweise mit Go-BoringCrypto erstellt wurden. |
| AlloyDB Omni-Operator-Controller | Von Google entwickelt, auf einem FIPS-konformen Basis-Image (Red Hat UBI) aufgebaut, mit aktivierter FIPS-Konformität im Container, in dem die Datenbank ausgeführt wird. | |
| AlloyDB Omni-Container-Image | Es werden FIPS-konforme kryptografische Bibliotheken wie BoringSSL verwendet und FIPS-genehmigte Algorithmen für das Passwort-Hashing (scram-sha-256) und TLS-Chiffrierverfahren erzwungen. |
|
| Zertifikate von benutzerdefinierten Zertifizierungsstellen | Freigegeben | Digitale Zertifikate müssen die FIPS-Standards für Schlüsselstärke und Signaturalgorithmen erfüllen. Die Zertifikatskette muss auf eine FIPS-konforme Stammzertifizierungsstelle zurückzuführen sein. |
Gemeinsame Verantwortung für STIG
Die Defense Information Systems Agency (DISA) veröffentlicht Security Technical Implementation Guides (STIGs), um Cybersicherheitsstandards und Anforderungen an die Härtung für Software, Betriebssysteme und Datenbanken festzulegen. In diesen Leitfäden werden spezifische Sicherheitsparameter definiert, um Systeme vor Schwachstellen und Cyberbedrohungen zu schützen.
Eine vollständige Liste der STIG-Regeln finden Sie unter STIG-Konformität von AlloyDB Omni.
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. In AlloyDB Omni sind viele Sicherheitskontrollen auf Datenbankebene standardmäßig implementiert. Die vollständige STIG-Konformität ist jedoch eine gemeinsame Verantwortung, bei der der Kunde Einstellungen auf Infrastrukturebene konfigurieren und überprüfen muss.
In der folgenden Tabelle sind alle STIG-Sicherheitslücken-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 Plattformen und Betreibern | Erforderliche Kundenaktion oder Konfiguration |
|---|---|---|---|
| V-233535 | Supportmitarbeiter sofort über Fehler im Audit-Log benachrichtigen | Standardfehlerdiagnosen werden in die Container stdout und stderr geschrieben. |
Der Kunde muss SIEM- oder Log-Forwarder-Messwerte konfigurieren, z. B. Splunk-/Elastic-Benachrichtigungen, die ausgelöst werden, wenn die Aufnahme abnimmt. |
| V-233599 | Supportmitarbeiter benachrichtigen, wenn der Speicherplatz für Prüfungen 75% erreicht. | Dateisystemmesswerte werden über Standard-Prometheus-Endpunkte bereitgestellt. | Der Kunde muss Benachrichtigungsregeln in Prometheus und Grafana einrichten, um den Support zu benachrichtigen, wenn der /obs/-Festplattenspeicherplatz 75 % überschreitet. |
| V-233610 | Lagern Sie Audit-Daten in eine separate Einrichtung für kontinuierliche Protokollierung aus. | 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 | Vertrauen Sie nur Endentitätszertifikaten, die von der Public-Key-Infrastruktur (PKI) oder von genehmigten Zertifizierungsstellen (Certificate Authorities, CAs) ausgestellt wurden. | Der Operator verwendet cert-manager, um lokale TLS-Konfigurationen zu konfigurieren. |
Der Kunde muss dem Betreiber seine PKI-Stamm- und Zwischenzertifikate der Zertifizierungsstelle zur Verfügung stellen, um die Vertrauenskette einzurichten. |
| V-233520 | Genehmigte logische Zugriffsberechtigungen erzwingen. | Lehnt Klartextpasswörter und den Message-Digest Algorithm 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 | Gleichzeitige Sitzungslimits pro Nutzer festlegen | Standarddatenbankrollen haben unendliche Limits, die durch max_connections begrenzt werden. |
Der Kunde muss die Verbindungslimits (ALTER ROLE ... CONNECTION LIMIT) für benutzerdefinierte Anwendungsrollen explizit ändern. |
| V-233584 | Verwenden Sie von der NSA genehmigte Kryptografie für vertrauliche Informationen im Ruhezustand. | 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 | Integration mit Authentifizierungsmechanismen auf Organisationsebene für Active Directory (AD) und Lightweight Directory Access Protocol (LDAP). | Der Operator unterstützt benutzerdefinierte Authentifizierungskonfigurationen. | Der Kunde muss AD- und LDAP-Identitäten in der Datenbankclusterkonfiguration zuordnen. |
| V-233583 | Verwenden Sie FIPS-validierte kryptografische Module für Hashes. | Der Container verwendet die OpenSSL-FIPS-Module des Hosts für Hash-Funktionen. | Der Kunde muss den FIPS-Modus auf Host-VM-Knoten aktivieren. |
| V-233585 | Verwenden Sie FIPS-validierte Kryptografie, um nicht klassifizierte Informationen zu schützen. | Verschlüsselt die Kommunikation und den Speicher mit FIPS-kompatiblen Chiffren. | Der Kunde muss bestätigen, dass die Hostknoten FIPS-validiert sind. |
| V-233619 | Verwenden Sie für alle Vorgänge FIPS-validierte Kryptografiemodule. | Erzwingt die Verwendung von Binärdateien für UBI9 FIPS-ready-Container-Images. | Der Kunde muss den FIPS-Modus im Host-Kernel aktivieren. |
| V-233623 | Das DBMS muss auf einem Host mit zertifiziertem OpenSSL FIPS ausgeführt werden. | Datenbank-Pods basieren auf OpenSSL-FIPS-Konfigurationen des Hosts. | Der Kunde muss prüfen, ob das Host-OpenSSL mit der NIST-zertifizierten FIPS-Liste übereinstimmt. |
| V-233615 | PKI-authentifizierte Identitäten den zugehörigen Nutzerkonten zuordnen | Der Betreiber verwendet die sichere SCRAM-SHA-256-Passwortauthentifizierung für Identitäten. |
Kunden müssen externe Organisationsverzeichnisrollen Datenbankrollen zuordnen, wenn sie sich nicht direkt mit einem Passwort anmelden. |
| V-233540 | Beschränken Sie das Konto für die Datenbankinstallation auf autorisierte Nutzer. | Der Container schränkt Dateiberechtigungen und die Ausführung auf den Nutzer postgres ein. |
Kunden müssen den Zugriff auf Hostknoten (SSH/Kubectl) sperren, um unbefugten Terminalzugriff auf die Pods zu verhindern. |