Tanggung jawab bersama AlloyDB Omni

Pilih versi dokumentasi:

Halaman ini menjelaskan hal yang menjadi tanggung jawab Anda sebagai pelanggan AlloyDB Omni dan hal yang menjadi tanggung jawab Google.

Sebagai pelanggan AlloyDB Omni, Anda bertanggung jawab untuk mengonfigurasi dan mengoperasikan AlloyDB Omni guna memastikan workload Anda mendapatkan nilai maksimal dari layanan.

Lapisan Tanggung jawab Google Tanggung jawab pelanggan
Hardware dan host Infrastruktur fisik Memberikan persyaratan minimum dan yang direkomendasikan jika berlaku Menyediakan server fisik, VM, atau perangkat edge seperti daya, pendinginan, dan hardware.
Sistem operasi (OS) host Memberikan persyaratan minimum dan yang direkomendasikan jika berlaku Mengelola kernel Linux, menerapkan patch keamanan OS, dan memperkuat node host.
Kubernetes Pengelolaan cluster Memberikan persyaratan minimum dan yang direkomendasikan jika berlaku Mengelola cluster setiap hari—termasuk upgrade—dengan mengikuti praktik terbaik standar industri.
Penyimpanan (CSI/PV) Memberikan persyaratan minimum dan yang direkomendasikan jika berlaku Menyediakan class penyimpanan dan mengelola appliance yang mendasarinya. AlloyDB Omni memerlukan perangkat blok, jadi pastikan untuk memilih class perangkat blok.
Jaringan (CNI) Memberikan persyaratan minimum dan yang direkomendasikan jika berlaku Menyediakan dan mengelola lapisan jaringan—misalnya, jaringan pod, pengontrol ingress, load balancer, dan aturan firewall antar-node.
Kontrol akses berbasis peran (RBAC) Menyediakan akun layanan, peran, dan pengikatan peran yang diperlukan untuk operator AlloyDB Omni Kubernetes. Menerapkan aturan kontrol akses berbasis peran (RBAC) ini ke cluster dan memastikan aturan tersebut selaras dengan kebijakan keamanan internal. Untuk mengakses resource AlloyDB Omni, buat peran RBAC dan pengikatan peran tambahan.
Pengelolaan secret Membaca Secret Kubernetes standar untuk menyediakan resource, seperti pengguna postgres awal. Membuat, mengamankan, dan merotasi Secret Kubernetes di cluster.
Pengelolaan sertifikat Mengandalkan Secret Kubernetes standar dan cert-manager untuk integrasi sertifikat. Menginstal, mengonfigurasi, dan mengelola siklus proses cert-manager.
Software operator Pengembangan dan rilis Mengembangkan logika dan CRD operator AlloyDB Omni serta memublikasikan image container, diagram Helm, dan paket OLM. Tidak ada. Anda dapat menggunakan artefak yang disimpan di Artifact Registry untuk deployment Anda.
Penginstalan dan siklus proses Menyediakan dokumentasi dan artefak upgrade.
  • Verifikasi tabel kompatibilitas sebelum Anda menginstal atau mengupgrade operator AlloyDB Omni.
  • Ikuti petunjuk untuk menginstal atau mengupgrade komponen AlloyDB Omni.
Database engine Biner database Menyediakan image container AlloyDB Omni dengan pengoptimalan eksklusif seperti columnar engine dan akselerasi AI. Tidak ada.
Sedang memberikan patch Merilis patch keamanan dan update versi minor dan utama untuk engine. Memberikan petunjuk upgrade. Menjadwalkan upgrade sesegera mungkin, bergantung pada tingkat keparahan setiap rilis.
Pengelolaan pengguna
  • Menyediakan pengguna terkait operator AlloyDB Omni operator awal.
  • Menyediakan pengguna super postgres yang menghadap pengguna menggunakan sandi yang disediakan pengguna dari Secret Kubernetes.
  • Memberikan petunjuk untuk berintegrasi dengan Microsoft Active Directory.
  • Memberikan sandi untuk pengguna super awal menggunakan Secret Kubernetes.
  • Membuat dan mengelola semua peran dan pengguna lainnya.
Pengelolaan data Cadangan Menyediakan CRD dan logika `BackupPlan` dan `Backup` untuk mengelola cadangan, yang dikelola menggunakan pgBackrest dengan integrasi yang kompatibel dengan S3. Mengonfigurasi jadwal dan retensi cadangan, serta menyediakan bucket penyimpanan target lokal, S3, atau Cloud Storage.
Ketersediaan tinggi (HA) Menyediakan logika failover otomatis dan mekanisme pemulihan. Menyediakan node dan zona yang memadai untuk menyediakan target standby guna mendukung failover.
Enkripsi (dalam penyimpanan) Menyediakan dukungan untuk Enkripsi Data Transparan (TDE). Mengelola enkripsi lapisan penyimpanan untuk memastikan enkripsi tersebut memenuhi persyaratan Anda.
Enkripsi (dalam pengiriman) Menyediakan mTLS untuk komponen operator internal dan untuk mengonfigurasi TLS sisi server untuk koneksi pengguna ke database. Menghubungkan ke database menggunakan klien TLS yang aman dan mengelola infrastruktur sertifikat yang mendasarinya.
Kemampuan observasi Metrik Mengekspos metrik database internal menggunakan endpoint yang kompatibel dengan Prometheus. Men-deploy dan mengelola scraper menggunakan Prometheus, Open Telemetry, atau solusi kompatibel lainnya dan tumpukan penyimpanannya. Memantau kondisi sistem secara keseluruhan.
Logging Menulis log PostgreSQL dan audit ke file di disk dalam container, dan merotasinya. Men-deploy kolektor log—misalnya, Fluentd dan Fluent Bit—untuk mengirimkan log ke backend penyimpanan (seperti Splunk atau ELK). Pastikan kolektor log dikonfigurasi untuk menyimpan log selama minimal satu bulan yang direkomendasikan.
Visualisasi Menyediakan dasbor metrik dan log contoh untuk memantau workload standar. Men-deploy dan memantau kondisi alat visualisasi, seperti Grafana. Membuat dasbor dan menggabungkannya dalam tugas operasional harian Anda.
Pemberitahuan Tidak ada Mengelola pipeline pemberitahuan—misalnya, integrasi PagerDuty.
Dukungan Pemecahan masalah Memberikan dukungan untuk bug software dan error engine. Untuk mendapatkan dukungan ini, Anda memerlukan langganan lisensi. Memberikan dukungan awal melalui dokumentasi dan pusat pengetahuan. Men-debug masalah terkait infrastruktur.

Kepatuhan terhadap keamanan dan FIPS

Untuk mengamankan data Anda, AlloyDB Omni menggunakan modul kriptografi yang divalidasi Federal Information Processing Standards (FIPS) 140-2 atau 140-3. Kepatuhan terhadap FIPS adalah tanggung jawab bersama antara Google dan pelanggan.

Diagram berikut menunjukkan cara tanggung jawab untuk kepatuhan terhadap FIPS dibagi antara Google dan pelanggan di seluruh lapisan arsitektur AlloyDB Omni.

Diagram yang menunjukkan batas tanggung jawab kepatuhan FIPS, yang membagi tanggung jawab antara Google, pelanggan, dan area bersama.

Tabel berikut menjelaskan batas dan tanggung jawab FIPS untuk AlloyDB Omni:

Lapisan batas FIPS Tanggung jawab Deskripsi
Hardware yang mematuhi FIPS Pelanggan Komponen hardware fisik dan kriptografi harus disertifikasi NIST dan dikonfigurasi dalam status yang disetujui FIPS.
OS node Kubernetes Pelanggan Sistem operasi host worker node—misalnya, RHEL—harus berjalan dalam mode FIPS. Status FIPS harus diverifikasi (cat /proc/sys/crypto/fips_enabled menampilkan 1).
Bidang kontrol Kubernetes Pelanggan Komponen bidang kontrol seperti kubelet dan plugin jaringan serta penyimpanan harus menggunakan modul kriptografi yang divalidasi FIPS—misalnya, dibuat dengan Go-BoringCrypto.
Pengontrol operator AlloyDB Omni Google Dikembangkan oleh Google, dibangun di image dasar yang mematuhi FIPS (Red Hat UBI), dengan kepatuhan terhadap FIPS diaktifkan di container tempat database berjalan.
Image container AlloyDB Omni Google Menggunakan library kriptografi yang mematuhi FIPS seperti BoringSSL dan menerapkan algoritma yang disetujui FIPS untuk hashing sandi (scram-sha-256) dan cipher suite TLS.
Sertifikat dari CA kustom Dibagikan Sertifikat digital harus memenuhi standar FIPS untuk kekuatan kunci dan algoritma tanda tangan. Rantai sertifikat harus dapat dilacak kembali ke CA Root yang mematuhi FIPS.

Tanggung jawab bersama STIG

Defense Information Systems Agency (DISA) memublikasikan Security Technical Implementation Guides (STIG) untuk menetapkan standar keamanan siber dan persyaratan penguatan untuk software, sistem operasi, dan database. Panduan ini menentukan parameter keamanan tertentu untuk melindungi sistem dari kerentanan dan ancaman siber.

Untuk daftar lengkap aturan STIG, lihat Kepatuhan STIG AlloyDB Omni.

Memperkuat lingkungan Anda sesuai dengan persyaratan STIG sangat penting untuk mendapatkan Authorization to Operate (ATO) di sektor pemerintah atau yang sangat aman. Meskipun AlloyDB Omni menerapkan banyak kontrol keamanan tingkat database secara default, mencapai kepatuhan STIG penuh adalah tanggung jawab bersama yang mengharuskan pelanggan mengonfigurasi dan memverifikasi setelan tingkat infrastruktur.

Tabel berikut mencantumkan semua ID kerentanan STIG yang memerlukan tindakan, validasi, atau konfigurasi oleh pelanggan. Untuk informasi lengkap, lihat checklist kepatuhan Security Technical Implementation Guide (STIG) PostgreSQL 9.x di Red Hat Enterprise Linux.

ID STIG atau SRG Deskripsi kontrol keamanan Perilaku default platform dan operator Tindakan atau konfigurasi pelanggan yang diperlukan
V-233535 Segera beri tahu staf dukungan jika terjadi kegagalan log audit. Diagnostik error standar ditulis ke stdout dan stderr container. Pelanggan harus mengonfigurasi metrik SIEM atau penerus log—misalnya, pemberitahuan Splunk/Elastic—untuk memicu saat penyerapan menurun.
V-233599 Beri tahu staf dukungan saat penyimpanan audit mencapai kapasitas 75%. Metrik sistem file diekspos melalui endpoint Prometheus standar. Pelanggan harus menyiapkan aturan pemberitahuan di Prometheus dan Grafana untuk memberi tahu dukungan jika ruang disk /obs/ melebihi 75%.
V-233610 Lepaskan data audit ke fasilitas log berkelanjutan yang terpisah. Log audit ditulis secara persisten ke volume /obs/diagnostic/. Pelanggan harus mengonfigurasi penerus log—misalnya, FluentBit dan Vector—untuk melakukan streaming file log secara berkelanjutan ke SIEM pusat.
V-233603 Hanya percayai sertifikat entitas akhir yang diterbitkan oleh infrastruktur kunci publik (PKI) atau Certificate Authority (CA) yang disetujui. Operator menggunakan cert-manager untuk mengonfigurasi konfigurasi TLS lokal. Pelanggan harus memberikan sertifikat CA Root dan Menengah PKI kepada operator untuk membuat rantai kepercayaan.
V-233520 Terapkan otorisasi akses logis yang disetujui. Menolak sandi teks biasa dan algoritma Message-Digest 5 (MD5). Mengizinkan scram-sha-256 melalui SSL. Pelanggan harus mengonfigurasi klien untuk menggunakan SCRAM-SHA-256 dengan sslmode=verify-full dalam string koneksinya.
V-233522 Batasi nilai minimum sesi serentak per pengguna. Peran database default memiliki batas tak terbatas yang dibatasi oleh max_connections. Pelanggan harus mengubah batas koneksi secara eksplisit (ALTER ROLE ... CONNECTION LIMIT) untuk peran aplikasi kustom.
V-233584 Gunakan kriptografi yang disetujui NSA untuk informasi rahasia dalam penyimpanan. Container database menggunakan lapisan dasar UBI9 yang aman dan diperkuat. Pelanggan harus memverifikasi bahwa kernel host Kubernetes yang mendasarinya telah mengaktifkan mode FIPS 140.
V-233515 Berintegrasi dengan mekanisme autentikasi tingkat organisasi Active Directory (AD) dan Lightweight Directory Access Protocol (LDAP). Operator mendukung konfigurasi autentikasi kustom. Pelanggan harus memetakan identitas AD dan LDAP ke dalam konfigurasi cluster database.
V-233583 Gunakan modul kriptografi yang divalidasi FIPS untuk hash. Container mengandalkan modul FIPS OpenSSL host untuk fungsi hashing. Pelanggan harus mengaktifkan mode FIPS di node VM host.
V-233585 Gunakan kripto yang divalidasi FIPS untuk melindungi informasi yang tidak diklasifikasikan. Mengenkripsi komunikasi dan penyimpanan menggunakan cipher yang mendukung FIPS. Pelanggan harus memverifikasi bahwa node host divalidasi FIPS.
V-233619 Gunakan modul kripto yang divalidasi FIPS untuk semua operasi. Menerapkan biner image container UBI9 yang siap digunakan untuk FIPS. Pelanggan harus mengaktifkan mode FIPS di kernel host.
V-233623 Pastikan DBMS berjalan di host dengan OpenSSL FIPS bersertifikasi. Pod database mengandalkan konfigurasi FIPS OpenSSL host. Pelanggan harus memverifikasi bahwa OpenSSL host cocok dengan daftar FIPS bersertifikasi NIST.
V-233615 Petakan identitas yang diautentikasi PKI ke akun pengguna terkait. Operator menggunakan autentikasi sandi SCRAM-SHA-256 yang aman untuk identitas. Pelanggan harus memetakan peran direktori organisasi eksternal ke peran database jika tidak menggunakan login sandi langsung.
V-233540 Batasi akun penginstalan database hanya untuk pengguna yang diotorisasi. Container membatasi izin file dan eksekusi ke pengguna postgres. Pelanggan harus mengunci akses node host (SSH/Kubectl) untuk mencegah akses terminal yang tidak sah ke pod.