Sicherheitsbulletin

Wählen Sie eine Dokumentationsversion aus:

Wenn Sie den Sicherheitsstatus Ihrer AlloyDB Omni-RPM-Orchestrator-Bereitstellungen 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 alle veröffentlichten AlloyDB Omni-RPM-Orchestrator- und Datenbank-RPM-Pakete regelmäßig anhand der NVD-, Red Hat Security Data- 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-RPM-Orchestrator- oder Datenbank-RPM-Paket vorhanden waren, werden in einem nachfolgenden Neben- oder Patch-Release behoben. Google wendet Sicherheitspatches auf die neueste Nebenversion der unterstützten PostgreSQL-Hauptversion 18 und auf die neueste unterstützte AlloyDB Omni-RPM-Orchestrator-Version an.
  • Host-Betriebssystempakete für RPM-Bereitstellungen: Wenn Sie AlloyDB Omni mit dem RPM-Orchestrator 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. Die RPM-Pakete für den AlloyDB Omni-RPM-Orchestrator und die Datenbank 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.
Bei RPM-Orchestrator-Bereitstellungen unter RHEL oder Rocky Linux wird das Datenbankpaket alloydbomni18 dynamisch mit den OpenSSL 3-Bibliotheken des Host-Betriebssystems im RPM-Paket openssl-libs verknüpft und verwendet den OpenSSL-FIPS-Anbieter des Host-RHEL 9, wenn der FIPS-Modus im Host-Kernel 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