Bollettino sulla sicurezza

Seleziona una versione della documentazione:

Per valutare la security posture dei deployment dell'orchestratore RPM di AlloyDB Omni su Red Hat Enterprise Linux (RHEL) e Rocky Linux e pianificare gli upgrade, consulta le policy di sicurezza, l'ambito delle vulnerabilità e le pratiche di divulgazione delle vulnerabilità ed esposizioni comuni (CVE) in questa pagina.

Per ricevere le note di rilascio e gli aggiornamenti della sicurezza più recenti di AlloyDB Omni nel tuo lettore di feed, iscriviti al feed delle note di rilascio di AlloyDB Omni.

Filtro per ambito e gravità

Per concentrare i workflow di correzione su avvisi di sicurezza utili e ridurre il rumore dello scanner, i riepiloghi delle vulnerabilità di AlloyDB Omni e i log CVE dettagliati seguono queste policy di reporting:

  • Filtro rigoroso per gravità critica e alta: le tabelle di riepilogo delle vulnerabilità e i log CVE dettagliati segnalano esclusivamente le CVE con gravità critica e alta in base alle valutazioni di gravità del National Vulnerability Database (NVD) e del vendor upstream. I suggerimenti con gravità bassa e media sono esclusi dai conteggi di riepilogo e dai log dettagliati.
  • Isolamento specifico per versione: i log CVE dettagliati sono organizzati in sottopagine dedicate per versione di release utilizzando uno schema standardizzato a 4 colonne (CVE ID, Severity, AlloyDB Omni version e Mitigated in). All'interno di ogni log di release, le vulnerabilità corrette in una release successiva mostrano la versione di release di mitigazione nella colonna Mitigated in.

Criterio di valutazione e aggiornamento delle vulnerabilità

Google analizza regolarmente tutti i pacchetti RPM dell'orchestratore RPM e del database AlloyDB Omni pubblicati rispetto ai database delle vulnerabilità NVD, Red Hat Security Data e Go. Google aggiorna i bollettini sulla sicurezza di AlloyDB Omni quando vengono pubblicate nuove release:

  • CVE corretti: le vulnerabilità presenti in un pacchetto RPM dell'orchestratore RPM o del database AlloyDB Omni precedente vengono mitigate in una release secondaria o patch successiva. Google applica patch di sicurezza all'ultima versione secondaria della versione principale 18 di PostgreSQL supportata e all'ultima release dell'orchestratore RPM di AlloyDB Omni supportata.
  • Pacchetti del sistema operativo host per i deployment RPM: quando esegui il deployment di AlloyDB Omni utilizzando l'orchestratore RPM, AlloyDB Omni fornisce il kernel del database PostgreSQL e i pacchetti di estensioni in bundle. La distribuzione Linux host gestisce le librerie di sistema come openssl-libs, glibc, libevent, systemd e il kernel Linux. Applica regolarmente gli aggiornamenti della sicurezza del sistema operativo host eseguendo sudo dnf update --security sui tuoi host RHEL o Rocky Linux.

Conformità a FIPS 140-3 e applicazione di patch CVE

Per mantenere la conformità con i Federal Information Processing Standard (FIPS) 140-3 e applicare continuamente patch alle vulnerabilità di sicurezza nelle release minori e nelle patch, AlloyDB Omni disaccoppia i moduli crittografici interni convalidati FIPS dalle librerie crittografiche e di protocollo esterne:

  • Convalida FIPS per i moduli di crittografia: il Cryptographic Module Validation Program (CMVP) del National Institute of Standards and Technology (NIST) certifica un modulo o un provider di crittografia interno bloccato ed emette un numero di certificato. La modifica di qualsiasi istruzione all'interno di questo confine convalidato altera il checksum di integrità HMAC (Hash-based Message Authentication Code) incorporato e invalida il certificato.
  • Conformità FIPS per i deployment: un deployment AlloyDB Omni opera in modalità conforme a FIPS 140-3 quando viene eseguito su un sistema operativo host abilitato per FIPS, come RHEL 9 con il file /proc/sys/crypto/fips_enabled impostato su 1. In questa modalità, il deployment instrada tutte le operazioni di crittografia relative alla sicurezza tramite un modulo convalidato FIPS con test di risposta nota (KAT) all'accensione e controlli di integrità HMAC abilitati. Inoltre, applica le versioni approvate di Transport Layer Security (TLS) 1.2 o successive, le suite di crittografia approvate e il metodo di autenticazione con password scram-sha-256. I pacchetti RPM dell'orchestratore RPM e del database di AlloyDB Omni sono compatibili con FIPS e la tua organizzazione è responsabile dell'attivazione e della verifica della modalità FIPS sul sistema operativo host sottostante. Per saperne di più, consulta Sicurezza e conformità FIPS.
  • Applicazione di patch CVE al di fuori del confine FIPS: le librerie di analisi dei protocolli e di networking, come le macchine di stato TLS, l'analisi dei certificati X.509 e ASN.1, HTTP/2 e l'I/O di rete, risiedono nel livello esterno al di fuori del confine del modulo FIPS bloccato. Poiché questi componenti si trovano al di fuori del confine convalidato, Google applica patch alle CVE del livello esterno nelle release secondarie e nelle patch senza modificare il modulo crittografico interno o invalidare la certificazione NIST CMVP. Solo una vulnerabilità all'interno dell'implementazione della primitiva crittografica di basso livello richiede un aggiornamento del modulo FIPS interno.
Per i deployment dell'orchestratore RPM su RHEL o Rocky Linux, il pacchetto del database alloydbomni18 si collega dinamicamente alle librerie OpenSSL 3 del sistema operativo host nel pacchetto RPM openssl-libs e utilizza il provider FIPS OpenSSL RHEL 9 dell'host quando la modalità FIPS è abilitata sul kernel host. L'applicazione degli aggiornamenti della sicurezza di openssl-libs sul sistema operativo host corregge le vulnerabilità TLS e X.509 del livello esterno, preservando al contempo il confine del provider FIPS OpenSSL certificato.

Passaggi successivi