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. | Physische Server, VMs oder Edge-Geräte wie Strom, Kühlung und Hardware bereitstellen. |
| Hostbetriebssystem | Geben Sie gegebenenfalls Mindestanforderungen und empfohlene Anforderungen an. | Linux-Kernel verwalten, Betriebssystem-Sicherheitspatches anwenden und Hostknoten härten. | |
| Kubernetes | Clusterverwaltung | Geben Sie gegebenenfalls Mindestanforderungen und empfohlene Anforderungen an. | Verwalten Sie den Cluster täglich, einschließlich Upgrades, gemäß den Best Practices der Branche. |
| Speicher (CSI/PV) | Geben Sie gegebenenfalls Mindestanforderungen und empfohlene Anforderungen an. | Stellen Sie die Speicherklasse bereit und verwalten Sie die zugrunde liegenden Appliances. AlloyDB Omni erfordert ein blockorientiertes Gerät. Wählen Sie daher eine Klasse für blockorientierte Geräte aus. | |
| Netzwerk (CNI) | Geben Sie gegebenenfalls Mindestanforderungen und empfohlene Anforderungen an. | Netzwerkschicht bereitstellen und verwalten, z. B. Pod-Netzwerke, Ingress-Controller, Load Balancer und Firewallregeln zwischen Knoten. | |
| Rollenbasierte Zugriffssteuerung | Stellen Sie die Dienstkonten, Rollen und Rollenbindungen bereit, die für den AlloyDB Omni Kubernetes-Operator erforderlich sind. | 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. Erstellen Sie zusätzliche RBAC-Rollen und Rollenbindungen, um auf AlloyDB Omni-Ressourcen zuzugreifen. | |
| Secret-Verwaltung | Standard-Kubernetes-Secrets lesen, um Ressourcen wie den ursprünglichen postgres-Nutzer bereitzustellen. |
Kubernetes-Secrets im Cluster erstellen, sichern und rotieren. | |
| Zertifikatsverwaltung | Verlassen Sie sich auf standardmäßige Kubernetes-Secrets und cert-manager für die Zertifikatsintegration. |
Installieren, konfigurieren und verwalten Sie den Lebenszyklus von cert-manager. |
|
| Betreibersoftware | Entwicklung und Veröffentlichung | Entwickeln Sie die AlloyDB Omni-Operatorlogik und CRDs 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 | Datenbank-Binärprogramm | Stellen Sie die AlloyDB Omni-Container-Images mit proprietären Optimierungen wie der spaltenbasierten Engine und der KI-Beschleunigung bereit. | Keine. |
| Patchen | Sicherheitspatches sowie Updates für Neben- und Hauptversionen für die Engine veröffentlichen. Stellen Sie eine Upgradeanleitung bereit. | Planen Sie Upgrades so schnell wie möglich, je nach Kritikalität 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 die Aufbewahrung und stellen Sie den lokalen, S3- oder Cloud Storage-Ziel-Bucket bereit. |
| Hochverfügbarkeit (HA) | Stellen Sie die Logik für automatisches Failover und die Reparaturmechanismen bereit. | Stellen Sie genügend Knoten und Zonen bereit, um ein Stand-by-Ziel für das Failover zu haben. | |
| Verschlüsselung (ruhender Daten) | Bietet Unterstützung für 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 über sichere TLS-Clients eine Verbindung zur Datenbank her und verwalten Sie die zugrunde liegende Zertifikatsinfrastruktur. | |
| Beobachtbarkeit | Messwerte | Interne Datenbankmesswerte über einen Prometheus-kompatiblen Endpunkt verfügbar machen. | Stellen Sie den Scraper mit Prometheus, OpenTelemetry oder anderen kompatiblen Lösungen und deren Speicher-Stack bereit und verwalten Sie ihn. Überwachen Sie den Gesamtzustand des Systems. |
| Logging | PostgreSQL- und Audit-Logs in Dateien auf dem Laufwerk im Container schreiben und rotieren. | Stellen Sie Log-Collectors wie Fluentd und Fluent Bit bereit, um Logs an ein Speicher-Backend wie Splunk oder ELK zu senden. Achten Sie darauf, dass die Log-Collectors so konfiguriert sind, dass Logs mindestens einen Monat lang aufbewahrt werden. | |
| Visualisierung | Beispiel-Messwerte und Log-Dashboards zum Überwachen von Standardarbeitslasten bereitstellen. | Stellen Sie das Visualisierungstool wie Grafana bereit und überwachen Sie dessen Zustand. Dashboards erstellen und in Ihre täglichen operativen 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. | Erste Unterstützung durch Dokumentation und Wissensdatenbank Infrastrukturprobleme beheben |
Sicherheit und FIPS-Compliance
Zum Schutz Ihrer Daten verwendet AlloyDB Omni kryptografische Module, die gemäß den Federal Information Processing Standards (FIPS) 140-2 oder 140-3 validiert sind. 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 den Architekturebenen von AlloyDB Omni aufgeteilt ist.
In der folgenden Tabelle werden die FIPS-Grenzen und ‑Zuständigkeiten 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 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, die beispielsweise mit Go-BoringCrypto erstellt wurden. |
| AlloyDB Omni-Operator-Controller | Von Google entwickelt, basierend auf einem FIPS-konformen Basis-Image (Red Hat UBI), wobei die FIPS-Konformität für den Container aktiviert ist, auf dem die Datenbank ausgeführt wird. | |
| AlloyDB Omni-Container-Image | Verwendet FIPS-konforme kryptografische Bibliotheken wie BoringSSL und erzwingt FIPS-genehmigte Algorithmen für das Passwort-Hashing (scram-sha-256) und TLS-Cipher-Suites. |
|
| Zertifikate von benutzerdefinierter Zertifizierungsstelle | Freigegeben | Digitale Zertifikate müssen den FIPS-Standards für Schlüsselstärke und Signaturalgorithmen entsprechen. Die Zertifikatskette muss auf eine FIPS-konforme Stammzertifizierungsstelle zurückgehen. |
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 Sicherheitslücken und Cyberbedrohungen zu schützen.
Eine vollständige Liste der STIG-Regeln finden Sie unter STIG-Compliance für AlloyDB Omni.
Die Härtung Ihrer Umgebung gemäß den STIG-Anforderungen ist unerlässlich, um eine Authorization to Operate (ATO) in hochsicheren oder staatlichen Sektoren 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 prüfen muss.
In der folgenden Tabelle sind alle STIG-Sicherheitslücken-IDs aufgeführt, die eine Aktion, Validierung oder Konfiguration durch den Kunden erfordern. Ausführliche Informationen finden Sie in der Compliance-Checkliste für den 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 Kundenaktion oder -konfiguration |
|---|---|---|---|
| V-233535 | Supportmitarbeiter sofort über Audit-Log-Fehler benachrichtigen. | Standardfehlerdiagnosen werden in die Container stdout und stderr geschrieben. |
Der Kunde muss SIEM- oder Logweiterleitungs-Messwerte konfigurieren, z. B. Splunk-/Elastic-Benachrichtigungen, die ausgelöst werden, wenn die Aufnahme abfällt. |
| V-233599 | Supportmitarbeiter benachrichtigen, wenn der Auditspeicher eine Kapazität von 75% erreicht. | Dateisystemmesswerte werden über Prometheus-Standardendpunkte bereitgestellt. | Der Kunde muss in Prometheus und Grafana Benachrichtigungsregeln einrichten, damit der Support benachrichtigt wird, wenn der Speicherplatz von /obs/ 75 % überschreitet. |
| V-233610 | Audit-Daten in eine separate kontinuierliche Log-Einrichtung auslagern. | Audit-Logs werden dauerhaft auf das Volume /obs/diagnostic/ geschrieben. |
Kunden müssen einen Log-Forwarder konfigurieren, z. B. FluentBit und Vector, um Logdateien kontinuierlich an ein zentrales SIEM-System zu streamen. |
| V-233603 | Vertrauen Sie nur Endentitätszertifikaten, die von einer Public-Key-Infrastruktur (PKI) oder 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-Root- und Zwischen-CA-Zertifikate zur Verfügung stellen, um die Vertrauenskette einzurichten. |
| V-233520 | Genehmigte logische Zugriffsberechtigungen erzwingen. | Lehnt Nur-Text-Passwörter und den Message-Digest-Algorithmus 5 (MD5) ab. Erlaubt 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. | Standarddatenbankrollen haben unbegrenzte Limits, die durch max_connections begrenzt sind. |
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 ruhende vertrauliche Informationen. | Der Datenbankcontainer verwendet sichere, gehärtete UBI9-Basisebenen. | Der Kunde muss prüfen, ob der FIPS 140-Modus im zugrunde liegenden Kubernetes-Hostkernel aktiviert ist. |
| V-233515 | In Active Directory (AD) und LDAP-Authentifizierungsmechanismen (Lightweight Directory Access Protocol) auf Organisationsebene einbinden. | Der Operator unterstützt benutzerdefinierte Authentifizierungskonfigurationen. | Der Kunde muss AD- und LDAP-Identitäten der Datenbankclusterkonfiguration zuordnen. |
| V-233583 | Verwenden Sie FIPS-validierte kryptografische Module für Hashes. | Der Container verwendet für Hash-Funktionen die OpenSSL-FIPS-Module des Hosts. | 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 Kommunikation und Speicher mit FIPS-fähigen Chiffren. | Der Kunde muss prüfen, ob die Hostknoten FIPS-validiert sind. |
| V-233619 | Verwenden Sie für alle Vorgänge FIPS-validierte Kryptografiemodule. | Erzwingt UBI9-FIPS-fähige Container-Image-Binärdateien. | Der Kunde muss den FIPS-Modus im Hostkernel aktivieren. |
| V-233623 | Achten Sie darauf, dass das DBMS auf einem Host mit zertifiziertem OpenSSL FIPS ausgeführt wird. | Datenbank-Pods sind auf OpenSSL-FIPS-Konfigurationen des Hosts angewiesen. | Der Kunde muss prüfen, ob die OpenSSL-Version des Hosts mit der NIST-zertifizierten FIPS-Liste übereinstimmt. |
| V-233615 | PKI-authentifizierte Identitäten den zugehörigen Nutzerkonten zuordnen. | Der Operator verwendet die sichere SCRAM-SHA-256-Passwortauthentifizierung für Identitäten. |
Der Kunde muss externe Rollen im Organisationsverzeichnis Datenbankrollen zuordnen, wenn er keine direkte Anmeldung mit Passwort verwendet. |
| V-233540 | Beschränken Sie das Konto für die Datenbankinstallation auf autorisierte Nutzer. | Der Container beschränkt die Dateiberechtigungen und die Ausführung auf den Nutzer postgres. |
Der Kunde muss den Zugriff auf den Hostknoten (SSH/Kubectl) sperren, um unbefugten Terminalzugriff auf die Pods zu verhindern. |