Sicherheitsbulletin

Wenn Sie den Sicherheitsstatus Ihrer eigenständigen AlloyDB Omni-Bereitstellungen bewerten und Datenbankupgrades planen möchten, lesen Sie die Sicherheitsrichtlinien, den Umfang der Sicherheitslücken, die Offenlegungspraktiken und die Grenzen des kryptografischen Moduls gemäß Federal Information Processing Standards (FIPS) 140-3 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.

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 Datenbankkernel und Steuerungsebene: In eigenständigen AlloyDB Omni-Sicherheitsbulletins werden Sicherheitslücken gemeldet, die für die Container-Images des Datenbankkernels (18.x, 17.x, 16.x und 15.x) spezifisch sind. Hinweise zu Kubernetes-Operatoren und Sidecar-Containern werden separat in derAlloyDB Omni on Kubernetes-Sicherheitsbulletinerfasst.
  • 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 AlloyDB Omni-Datenbankkernel-Container-Image vorhanden waren, werden in einem nachfolgenden Neben- oder Patch-Release behoben. Google wendet Sicherheitspatches auf die neueste Nebenversion der unterstützten PostgreSQL-Hauptversionen 18, 17, 16 und 15 an.
  • Ersetzte Container-Images: Wenn in einer neuen AlloyDB Omni-Version CVEs aus einer früheren Version behoben werden, markiert Google die Digests der ersetzten Container-Images als verworfen. Rufen Sie immer Datenbankkernel-Images ab, 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. Die Datenbankkernel-Container-Images (-ubi9) von Red Hat Universal Base Image 9 (UBI 9) sind FIPS-fähig. Ihre Organisation ist dafür verantwortlich, den FIPS-Modus auf dem zugrunde liegenden Hostbetriebssystem zu aktivieren und zu prüfen.
  • 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 in den AlloyDB Omni Red Hat UBI 9-Datenbankkernel-Container-Images (-ubi9) 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-Image des Datenbankkernels Binärprogramme Inneres FIPS-validiertes Modul oder innerer FIPS-validierter Anbieter Äußere kryptografische und Protokollebene
BoringSSL und BoringCrypto alloydbomni (-ubi9) postgres- und pgbackrest-C-Binärdateien Google BoringCrypto Module (BCM) BoringSSL-libssl- und Nicht-BCM-libcrypto-Pakete x509, asn1, pem und bio für postgres und pgbackrest
OpenSSL 3 Red Hat UBI 9-Basisbetriebssystem-Ebene von alloydbomni (-ubi9) Gemeinsam genutzte Bibliotheken und Dienstprogramme des Basisbetriebssystems RHEL 9 OpenSSL FIPS-Anbieter /lib64/libssl.so.3 und /lib64/libcrypto.so.3 im RPM-Paket openssl-libs

Nächste Schritte