Sicherheitsbulletin

Wählen Sie eine Dokumentationsversion aus:

Wenn Sie den Sicherheitsstatus Ihrer AlloyDB Omni-RPM-Paketbereitstellungen unter Red Hat Enterprise Linux (RHEL) und Rocky Linux bewerten und Upgrades planen möchten, lesen Sie die Sicherheitsrichtlinien, den Umfang der Sicherheitslücken und die Offenlegungspraktiken für 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.

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.
  • Versionsspezifische Isolation: Detaillierte CVE-Logs sind in dedizierten Unterseiten pro Release-Version organisiert und verwenden ein standardisiertes 4-Spalten-Schema (CVE ID, Severity, AlloyDB Omni version 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-RPM-Pakete anhand der NVD- und Red Hat-Sicherheitsdaten. Google aktualisiert die AlloyDB Omni-Sicherheitsbulletins, wenn neue Releases veröffentlicht werden:

  • Behobene CVEs: Sicherheitslücken, die in einem früheren AlloyDB Omni-RPM-Paket vorhanden waren, werden in einem nachfolgenden Neben- oder Patch-Release behoben. Google wendet Sicherheitspatches auf die neueste Nebenversion der unterstützten PostgreSQL-Hauptversionen 18 und 17 an.
  • Host-Betriebssystempakete für RPM-Bereitstellungen: Wenn Sie AlloyDB Omni mit RPM-Paketen bereitstellen, liefert AlloyDB Omni den PostgreSQL-Datenbankkernel und die gebündelten Erweiterungspakete. Ihre Linux-Hostdistribution verwaltet Systembibliotheken wie openssl-libs, glibc, libevent, systemd und den Linux-Kernel. Wenden Sie regelmäßig Sicherheitsupdates für das Host-Betriebssystem an, indem Sie sudo dnf update --security auf Ihren RHEL- oder Rocky Linux-Hosts ausführen.

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 Hostbetriebssystem wie 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. AlloyDB Omni-RPM-Pakete 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.
  • 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.
Bei RPM-Bereitstellungen unter RHEL oder Rocky Linux werden die Datenbankpakete alloydbomni18 und alloydbomni17 dynamisch mit den OpenSSL 3-Bibliotheken des Hostbetriebssystems im RPM-Paket openssl-libs verknüpft und verwenden den OpenSSL FIPS-Anbieter des Host-RHEL 9, wenn der FIPS-Modus im Hostkernel aktiviert ist. Durch das Anwenden von openssl-libs-Sicherheitsupdates auf das Host-Betriebssystem werden TLS- und X.509-Sicherheitslücken auf der äußeren Ebene behoben, während die zertifizierte OpenSSL-FIPS-Anbietergrenze beibehalten wird.

Nächste Schritte