Buletin keamanan

Pilih versi dokumentasi:

Untuk mengevaluasi postur keamanan deployment AlloyDB Omni Kubernetes Anda serta merencanakan upgrade panel kontrol dan cluster database, tinjau kebijakan keamanan, arsitektur operator, kontrol akses berbasis peran (RBAC), dan konteks keamanan, serta praktik pengungkapan Common Vulnerabilities and Exposures (CVE) di halaman ini.

Untuk menerima catatan rilis dan update keamanan AlloyDB Omni terbaru di pembaca feed Anda, berlanggananlah ke feed catatan rilis AlloyDB Omni.

Arsitektur operator dan konteks keamanan

AlloyDB Omni di Kubernetes memisahkan bidang kontrol Kubernetes dari pod mesin database yang memproses kueri aplikasi:

  • Komponen bidang kontrol dan operator: Setiap rilis operator AlloyDB Omni terdiri dari 10 image container yang dibangun di Red Hat Universal Base Image 9 (UBI 9):
    • operator/fleet-operator: Pengontrol Kubernetes tingkat fleet yang merekonsiliasi DBCluster dan resource kustom fleet
    • operator/local-operator: Pengontrol Kubernetes level instance yang mengelola siklus proses pod database lokal dan hanya berkomunikasi dengan server API Kubernetes internal cluster tepercaya
    • alloydbomni-operator-catalog dan alloydbomni-operator-olm-bundle: Indeks katalog Red Hat OpenShift Operator Lifecycle Manager (OLM) dan image metadata paket deklaratif
    • operator/dbinit dan operator/backupinit: Container inisialisasi sementara untuk alur kerja bootstrap, pencadangan, dan pemulihan database
    • operator/alloydbomni-monitor (menggantikan monitoring-agent), operator/g-pgbouncer, operator/logrotate, dan operator/node-manager: Sidecar pendamping dan container pengelolaan node untuk pemeriksaan respons, penggabungan koneksi, rotasi log, dan pengelolaan penyimpanan
  • RBAC dan konteks keamanan: Operator AlloyDB Omni menggunakan izin Role dan ClusterRole Kubernetes yang tercakup untuk merekonsiliasi resource kustom dalam namespace target dan menjalankan workload bidang kontrol dan sidecar dengan konteks keamanan container yang dibatasi.
  • Pod mesin database: Instance database yang dikelola oleh operator menjalankan image container kernel database AlloyDB Omni mandiri. Untuk memverifikasi versi kernel database yang didukung untuk versi operator Anda, lihat Memilih versi operator Kubernetes dan cluster database yang kompatibel.

Pemfilteran cakupan dan tingkat keparahan

Untuk memfokuskan alur kerja perbaikan pada saran keamanan yang dapat ditindaklanjuti dan mengurangi derau pemindai, ringkasan kerentanan AlloyDB Omni dan log CVE yang mendetail mengikuti kebijakan pelaporan berikut:

  • Pemfilteran ketat untuk tingkat keparahan Kritis dan Tinggi: Tabel ringkasan kerentanan dan log CVE mendetail hanya melaporkan CVE dengan tingkat keparahan Kritis dan Tinggi berdasarkan rating tingkat keparahan dari National Vulnerability Database (NVD) dan vendor upstream. Saran dengan tingkat keparahan Rendah dan Sedang dikecualikan dari jumlah ringkasan dan log mendetail.
  • Pelaporan kernel database dan bidang kontrol yang dipisahkan: Buletin bidang kontrol di bagian AlloyDB Omni di Kubernetes melaporkan kerentanan khusus untuk 10 image container sidecar dan operator AlloyDB Omni.
  • Isolasi khusus versi: Log CVE mendetail diatur ke dalam subhalaman khusus per versi rilis menggunakan skema 4 kolom standar (CVE ID, Severity, Impacted images, dan Mitigated in). Dalam setiap log rilis, kerentanan yang diperbaiki dalam rilis berikutnya menampilkan versi rilis mitigasi di kolom Mitigated in.

Penilaian kerentanan dan kebijakan pembaruan

Google secara rutin memindai semua image container AlloyDB Omni yang dipublikasikan terhadap database kerentanan NVD, Red Hat Security Data, Debian Security Tracker, dan Go. Google memperbarui buletin keamanan AlloyDB Omni saat rilis baru dipublikasikan:

  • CVE yang diperbaiki: Kerentanan yang ada dalam image container bidang kontrol operator AlloyDB Omni sebelumnya dimitigasi dalam rilis operator berikutnya. Google menerapkan patch keamanan ke rilis operator AlloyDB Omni terbaru yang didukung dan ke versi minor terbaru dari versi utama PostgreSQL 18, 17, 16, dan 15 yang didukung.
  • Image container yang digantikan: Saat rilis operator AlloyDB Omni baru memitigasi CVE dari rilis sebelumnya, Google menandai ringkasan image container yang digantikan sebagai tidak digunakan lagi. Selalu deploy image agen bidang kontrol dan operator yang sesuai dengan rilis terbaru yang didukung.

Kepatuhan FIPS 140-3 dan patching CVE

Untuk mempertahankan kepatuhan terhadap Federal Information Processing Standards (FIPS) 140-3 sambil terus melakukan patch pada kerentanan keamanan di seluruh rilis minor dan patch, AlloyDB Omni memisahkan modul kriptografi dalam yang divalidasi FIPS dari library kriptografi dan protokol luarnya:

  • Validasi FIPS untuk modul kriptografis: Cryptographic Module Validation Program (CMVP) National Institute of Standards and Technology (NIST) menyertifikasi modul atau penyedia kriptografis internal yang dibekukan dan menerbitkan nomor sertifikat. Mengubah petunjuk apa pun di dalam batas yang divalidasi tersebut akan mengubah checksum integritas Hash-based Message Authentication Code (HMAC) yang disematkan dan membatalkan validitas sertifikat.
  • Kepatuhan FIPS untuk deployment: Deployment AlloyDB Omni beroperasi dalam mode yang mematuhi FIPS 140-3 saat berjalan di OS host yang mendukung FIPS, seperti Red Hat Enterprise Linux (RHEL) 9 dengan file /proc/sys/crypto/fips_enabled yang ditetapkan ke 1. Dalam mode ini, deployment merutekan semua operasi kriptografis yang relevan dengan keamanan melalui modul yang divalidasi FIPS dengan Known-Answer Test (KAT) yang diaktifkan dan pemeriksaan integritas HMAC diaktifkan. Proxy ini juga menerapkan versi Transport Layer Security (TLS) yang disetujui, yaitu TLS 1.2 atau yang lebih baru, cipher suite yang disetujui, dan metode autentikasi sandi scram-sha-256. Image container operator AlloyDB Omni dan image container database Red Hat UBI 9 (-ubi9) siap untuk FIPS, dan organisasi Anda bertanggung jawab untuk mengaktifkan dan memverifikasi mode FIPS pada OS host yang mendasarinya. Untuk mengetahui informasi selengkapnya, lihat Kepatuhan keamanan dan FIPS.
  • Patching CVE di luar batas FIPS: Library penguraian protokol dan jaringan, seperti mesin status TLS, penguraian sertifikat X.509 dan ASN.1, HTTP/2, dan I/O jaringan, berada di lapisan luar di luar batas modul FIPS yang dibekukan. Karena komponen ini berada di luar batas yang divalidasi, Google menerapkan patch pada CVE lapisan luar di seluruh rilis minor dan patch tanpa mengubah modul kriptografi dalam atau membatalkan sertifikasi NIST CMVP-nya. Hanya kerentanan di dalam implementasi primitif kriptografis tingkat rendah itu sendiri yang memerlukan update pada modul FIPS internal.
Tabel berikut menjelaskan stack kriptografis di seluruh bidang kontrol operator AlloyDB Omni dan image container sidecar, termasuk batas FIPS dalam yang dibekukan serta lapisan kriptografis dan protokol luar yang di-patch di seluruh rilis:

Stack kriptografis Image container bidang kontrol Biner Modul atau penyedia tervalidasi FIPS internal Lapisan kriptografi dan protokol luar
FIPS bawaan Go dengan setelan build GOFIPS140=v1.0.0 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, Sertifikat CMVP NIST #5247 Paket library standar Go crypto/tls, crypto/x509, dan net/http, paket Go eksternal seperti golang.org/x/crypto, serta runtime dan compiler Go
OpenSSL 3 operator/g-pgbouncer /usr/bin/pgbouncer Penyedia FIPS OpenSSL RHEL 9 /lib64/libssl.so.3 dan /lib64/libcrypto.so.3 dalam paket RPM openssl-libs, dan biner C pgbouncer
BoringSSL dan BoringCrypto operator/alloydbomni-monitor /monitoring_agent Biner Go yang dibuat dengan boringcrypto Google BoringCrypto Module (BCM) Paket Go crypto/tls, crypto/x509, dan net/http untuk monitoring_agent

Langkah berikutnya