Sicherheitsbulletin

Wählen Sie eine Dokumentationsversion aus:

Wenn Sie den Sicherheitsstatus Ihrer AlloyDB Omni Kubernetes-Bereitstellungen bewerten und Upgrades für die Steuerungsebene und den Datenbankcluster planen möchten, lesen Sie die Sicherheitsrichtlinien, die Operator-Architektur, die rollenbasierte Zugriffssteuerung (RBAC) und die Sicherheitskontexte sowie die Praktiken zur Offenlegung von Common Vulnerabilities and Exposures (CVE) auf dieser Seite.

Wenn Sie die neuesten Versionshinweise und Sicherheitsupdates zu AlloyDB Omni in Ihrem Feedreader erhalten möchten, abonnieren Sie den Feed mit den Versionshinweisen zu AlloyDB Omni.

Operatorarchitektur und Sicherheitskontexte

AlloyDB Omni in Kubernetes entkoppelt die Kubernetes-Steuerungsebene von den Datenbank-Engine-Pods, die Anwendungsabfragen verarbeiten:

  • Komponenten der Steuerungsebene und des Operators: Jede AlloyDB Omni-Operator-Version umfasst 10 Container-Images, die auf Red Hat Universal Base Image 9 (UBI 9) basieren:
    • operator/fleet-operator: Kubernetes-Controller auf Flottenebene, der DBCluster und benutzerdefinierte Flottenressourcen abgleicht
    • operator/local-operator: Kubernetes-Controller auf Instanzebene, der die Lebenszyklen lokaler Datenbank-Pods verwaltet und nur mit dem vertrauenswürdigen clusterinternen Kubernetes API-Server kommuniziert
    • alloydbomni-operator-catalog und alloydbomni-operator-olm-bundle: Red Hat OpenShift Operator Lifecycle Manager (OLM)-Katalogindex und deklarative Bundle-Metadaten-Images
    • operator/dbinit und operator/backupinit: Flüchtige Initialisierungscontainer für Datenbank-Bootstrapping, Sicherung und Wiederherstellung von Workflows
    • operator/alloydbomni-monitor (ersetzt monitoring-agent), operator/g-pgbouncer, operator/logrotate und operator/node-manager: Companion-Sidecar- und Knotenmanager-Container für Systemdiagnosen, Verbindungspooling, Protokollwechsel und Speicherverwaltung
  • RBAC und Sicherheitskontexte: Der AlloyDB Omni-Operator verwendet bereichsbezogene Kubernetes-Berechtigungen (Role und ClusterRole), um benutzerdefinierte Ressourcen in Ziel-Namespaces abzugleichen, und führt Steuerungsebenen- und Sidecar-Arbeitslasten mit eingeschränkten Container-Sicherheitskontexten aus.
  • Datenbank-Engine-Pods: Datenbankinstanzen, die vom Operator verwaltet werden, führen die eigenständigen AlloyDB Omni-Datenbankkernel-Container-Images aus. Informationen dazu, welche Datenbank-Kernel-Versionen für Ihre Operator-Version unterstützt werden, finden Sie unter Kompatible Kubernetes-Operator- und Datenbankcluster-Versionen auswählen.

Filterung nach Bereich und Schweregrad

Damit sich die Workflows zur Behebung auf umsetzbare Sicherheitshinweise konzentrieren und das Scannerrauschen reduziert wird, folgen die AlloyDB Omni-Zusammenfassungen von Sicherheitslücken und die detaillierten CVE-Logs den folgenden Berichtsrichtlinien:

  • Strikte Filterung nach kritischem und hohem Schweregrad: In den Zusammenfassungstabellen zu Sicherheitslücken und in den detaillierten CVE-Logs werden ausschließlich CVEs mit kritischem und hohem Schweregrad aufgeführt, basierend auf den Schweregradbewertungen der National Vulnerability Database (NVD) und der Upstream-Anbieter. Empfehlungen mit niedrigem und mittlerem Schweregrad sind nicht in den Zusammenfassungen und detaillierten Logs enthalten.
  • Entkoppelte Berichte zu Steuerungsebene und Datenbankkernel: In den Bulletins zur Steuerungsebene unter AlloyDB Omni on Kubernetes werden Sicherheitslücken gemeldet, die speziell die 10 Container-Images des AlloyDB Omni-Operators und des Sidecar-Containers betreffen.
  • Versionsspezifische Isolation: Detaillierte CVE-Logs sind in dedizierten Unterseiten pro Release-Version organisiert und verwenden ein standardisiertes 4-Spalten-Schema (CVE ID, Severity, Impacted images und Mitigated in). In jedem Release-Log werden Sicherheitslücken, die in einem nachfolgenden Release behoben wurden, werden mit der entsprechenden Release-Version in der Spalte Mitigated in angezeigt.

Richtlinie zur Bewertung und Aktualisierung von Sicherheitslücken

Google scannt regelmäßig alle veröffentlichten AlloyDB Omni-Container-Images anhand der NVD-, Red Hat Security Data-, Debian Security Tracker- und Go-Sicherheitslückendatenbanken. Google aktualisiert die AlloyDB Omni-Sicherheitsbulletins, wenn neue Releases veröffentlicht werden:

  • Behobene CVEs: Sicherheitslücken, die in einem früheren Container-Image der AlloyDB Omni-Operator-Steuerungsebene vorhanden waren, werden in einem nachfolgenden Operator-Release behoben. Google wendet Sicherheitspatches auf die neueste unterstützte AlloyDB Omni-Operator-Version und auf die neueste Nebenversion der unterstützten PostgreSQL-Hauptversionen 18, 17, 16 und 15 an.
  • Ersetzte Container-Images: Wenn ein neues AlloyDB Omni-Operator-Release CVEs aus einem früheren Release behebt, markiert Google ersetzte Container-Image-Digests als verworfen. Stellen Sie immer Operator- und Steuerungsebenen-Agent-Images bereit, die dem neuesten unterstützten Release entsprechen.

FIPS 140-3-Compliance und CVE-Patching

Um die Einhaltung der Federal Information Processing Standards (FIPS) 140-3 zu gewährleisten und gleichzeitig Sicherheitslücken in Minor- und Patch-Releases kontinuierlich zu beheben, entkoppelt AlloyDB Omni seine internen FIPS-validierten kryptografischen Module von seinen externen kryptografischen und Protokollbibliotheken:

  • FIPS-Validierung für kryptografische Module: Das Cryptographic Module Validation Program (CMVP) des National Institute of Standards and Technology (NIST) zertifiziert ein eingefrorenes inneres kryptografisches Modul oder einen Anbieter und stellt eine Zertifikatsnummer aus. Wenn Sie eine Anweisung innerhalb dieser validierten Grenze ändern, wird die eingebettete HMAC-Integritätsprüfsumme (Hash-based Message Authentication Code) geändert und das Zertifikat wird ungültig.
  • FIPS-Compliance für Bereitstellungen: Eine AlloyDB Omni-Bereitstellung wird in einem FIPS 140-3-konformen Modus ausgeführt, wenn sie auf einem FIPS-fähigen Host-Betriebssystem wie Red Hat Enterprise Linux (RHEL) 9 ausgeführt wird, wobei die Datei /proc/sys/crypto/fips_enabled auf 1 gesetzt ist. In diesem Modus leitet die Bereitstellung alle sicherheitsrelevanten kryptografischen Vorgänge über ein FIPS-validiertes Modul mit aktivierten Known-Answer-Tests (KATs) und HMAC-Integritätsprüfungen weiter. Außerdem werden genehmigte TLS-Versionen (Transport Layer Security) ab TLS 1.2, genehmigte Cipher Suites und die Passwortauthentifizierungsmethode scram-sha-256 erzwungen. Container-Images für den AlloyDB Omni-Operator und Red Hat UBI 9-Datenbank-Container-Images (-ubi9) sind FIPS-fähig. Ihre Organisation ist dafür verantwortlich, den FIPS-Modus auf dem zugrunde liegenden Host-Betriebssystem zu aktivieren und zu prüfen. Weitere Informationen finden Sie unter Sicherheit und FIPS-Compliance.
  • CVE-Patching außerhalb der FIPS-Grenze: Protokollparsing- und Netzwerkbibliotheken wie TLS-Zustandsmaschinen, X.509- und ASN.1-Zertifikatparsing, HTTP/2 und Netzwerk-E/A befinden sich in der äußeren Schicht außerhalb der eingefrorenen FIPS-Modulgrenze. Da sich diese Komponenten außerhalb der validierten Grenze befinden, patcht Google CVEs der äußeren Schicht in Neben- und Patch-Releases, ohne das innere kryptografische Modul zu ändern oder seine NIST-CMVP-Zertifizierung ungültig zu machen. Nur eine Sicherheitslücke in der Implementierung des Low-Level-Kryptografie-Primitivs selbst erfordert ein Update des inneren FIPS-Moduls.
In der folgenden Tabelle werden die kryptografischen Stacks auf der Steuerungsebene des AlloyDB Omni-Operators und in den Sidecar-Container-Images beschrieben, einschließlich der eingefrorenen inneren FIPS-Grenze und der äußeren kryptografischen und Protokollschicht, die in den verschiedenen Releases gepatcht wird:

Kryptografischer Stack Container-Images der Steuerungsebene Binärprogramme Inneres FIPS-validiertes Modul oder innerer FIPS-validierter Anbieter Äußere kryptografische und Protokollebene
Integrierte FIPS mit der Build-Einstellung GOFIPS140=v1.0.0 verwenden operator/fleet-operator
operator/local-operator
operator/logrotate
operator/node-manager
operator/dbinit
operator/backupinit 		/operator
/local
/logrotate
/nodemgr
dbinit
dbdaemon
credfetcher
backupinit
backupdaemon 		Go Cryptographic Module v1.0.0, NIST CMVP-Zertifikat Nr. 5247 Go-Standardbibliothekspakete crypto/tls, crypto/x509 und net/http, externe Go-Pakete wie golang.org/x/crypto sowie die Go-Laufzeit und der Go-Compiler
OpenSSL 3 operator/g-pgbouncer /usr/bin/pgbouncer RHEL 9 OpenSSL FIPS-Anbieter /lib64/libssl.so.3 und /lib64/libcrypto.so.3 im RPM-Paket openssl-libs und das C-Binärprogramm pgbouncer
BoringSSL und BoringCrypto operator/alloydbomni-monitor /monitoring_agent Go-Binärdatei, erstellt mit boringcrypto Google BoringCrypto Module (BCM) crypto/tls-, crypto/x509- und net/http-Pakete für monitoring_agent

Nächste Schritte