Responsabilità condivisa di AlloyDB Omni

Seleziona una versione della documentazione:

Questa pagina descrive le responsabilità dell'utente, in qualità di cliente di AlloyDB Omni, e quelle di Google quando si utilizza l'opzione di deployment dell'orchestratore RPM.

In qualità di cliente di AlloyDB Omni, hai la responsabilità di configurare e gestire AlloyDB Omni in modo che i tuoi carichi di lavoro ottengano il massimo valore dal servizio.

Matrice di responsabilità condivisa

La tabella seguente riepiloga le responsabilità di Google e del cliente in ogni livello di un deployment dell'orchestratore RPM di AlloyDB Omni:

incorporato Responsabilità di Google Responsabilità del cliente
Hardware e host Infrastruttura fisica Fornisci i requisiti minimi e consigliati, ove applicabile. Esegui il provisioning di server fisici, VM o dispositivi edge, inclusi alimentazione, raffreddamento e hardware.
Sistema operativo (OS) host Fornisci i requisiti minimi e consigliati, ove applicabile. Gestisci il kernel Linux, applica le patch di sicurezza del sistema operativo e proteggi i nodi host (ad esempio RHEL 9 o Rocky Linux 9).
Componenti dell'infrastruttura e del sistema operativo Archiviazione Fornisci i requisiti minimi e consigliati, ove applicabile. Esegui il provisioning di dischi locali o volumi SAN. AlloyDB Omni richiede un dispositivo a blocchi configurato con un file system supportato, come XFS o ext4.
Networking Fornisci i requisiti minimi e consigliati, ove applicabile. Esegui il provisioning e gestisci il livello di rete, ad esempio routing IP, bilanciatori del carico e regole firewall utilizzando firewalld o iptables, per aprire le porte richieste, ad esempio 5432 per PostgreSQL e 2379 e 2380 per etcd.
Controllo dell'accesso host Fornisci i service account e i ruoli richiesti per i componenti dell'orchestratore di AlloyDB Omni. Gestisci l'accesso SSH, i privilegi sudo, le policy SELinux e gli account utente Linux in base alle tue policy di sicurezza interne.
Gestione dei secret Leggi le variabili standard e i file di inventario per eseguire il provisioning delle risorse, ad esempio l'utente postgres iniziale. Archivia in modo sicuro password, chiavi SSH e token utilizzati per l'orchestrazione di Ansible e l'accesso al database.
Gestione dei certificati Fornisci opzioni di configurazione per l'integrazione dei certificati. Genera, distribuisci e gestisci il ciclo di vita dei certificati SSL (Transport Layer Security) e SSL sulle macchine host.
Software dell'orchestratore Sviluppo e rilascio Sviluppa l'orchestratore di AlloyDB Omni, incluse le raccolte CLI e Ansible, e pubblica i pacchetti RPM. Nessuno. Puoi utilizzare gli artefatti del repository Yum fornito per i tuoi deployment.
Installazione e ciclo di vita Fornisci documentazione, artefatti RPM e modelli di inventario di deployment.

Verifica la compatibilità prima dell'installazione.

Segui le istruzioni per installare o eseguire l'upgrade di AlloyDB Omni utilizzando la CLI dell'orchestratore alloydbctl o i playbook di Ansible.
Motore del database File binario del database Fornisci i pacchetti RPM di AlloyDB Omni con ottimizzazioni proprietarie come il motore colonnare e l'accelerazione AI. Nessuno.
Applicazione patch in corso… Rilascia patch di sicurezza e aggiornamenti delle versioni secondarie e principali per il motore. Fornisci istruzioni per l'upgrade. Pianifica gli upgrade il prima possibile, a seconda della criticità di ogni release.
Gestione utenti

Esegui il provisioning degli utenti amministratori iniziali.

Esegui il provisioning del superutente postgres rivolto all'utente.

Fornisci istruzioni per l'integrazione di LDAP (Lightweight Directory Access Protocol) e Active Directory (AD).

Fornisci la password per il superutente iniziale.

Crea e gestisci tutti gli altri ruoli e utenti.
Gestione dei dati Backup Fornisci l'automazione per gestire i backup utilizzando pgBackRest con l'integrazione compatibile con S3. Configura le pianificazioni e la conservazione dei backup ed esegui il provisioning del bucket di destinazione locale, S3 o Cloud Storage.
Alta affidabilità (HA) Fornisci la logica di failover automatico e i meccanismi di ripristino utilizzando etcd e il gestore dei cluster. Esegui il provisioning di un numero sufficiente di nodi, ad esempio un nodo di controllo, nodi etcd e nodi di database primari e di standby, per supportare le architetture di failover e alta disponibilità.
Crittografia at-rest Supporta i deployment su volumi crittografati a livello di blocco. Gestisci la crittografia del livello di archiviazione, ad esempio Linux Unified Key Setup (LUKS) e dm-crypt, per soddisfare i tuoi requisiti di sicurezza.
Crittografia dei dati in transito Configura TLS lato server per le connessioni utente-database e le comunicazioni interne del cluster. Connettiti al database utilizzando client TLS sicuri e gestisci l'infrastruttura di certificati sottostante.
Osservabilità Metriche Esponi le metriche interne del database utilizzando un endpoint compatibile con Prometheus. Esegui il deployment e gestisci lo scraper utilizzando Prometheus, OpenTelemetry o altre soluzioni compatibili e il relativo stack di archiviazione. Monitora lo stato di salute complessivo del sistema.
Logging Scrivi i log di PostgreSQL e di audit nei file su disco e gestisci la rotazione. Esegui il deployment di raccoglitori di log, come Fluent Bit o Vector, per inviare i log a un backend di archiviazione come Splunk o lo stack ELK. Conserva i log per un minimo consigliato di un mese.
Visualizzazione Fornisci metriche e dashboard di esempio per monitorare i carichi di lavoro standard. Esegui il deployment e monitora lo stato di salute di uno strumento di visualizzazione, ad esempio Grafana. Crea dashboard e incorporale nelle attività operative quotidiane.
Avvisi Nessuno. Gestisci la pipeline di avvisi, ad esempio utilizzando un'integrazione PagerDuty.
Assistenza Risoluzione dei problemi Fornisci assistenza per bug del software ed errori del motore. Per ottenere questa assistenza, devi avere un abbonamento. Fornisci assistenza iniziale tramite documentazione e knowledge base. Esegui il debug dei problemi relativi all'infrastruttura.

Sicurezza e conformità a FIPS

Per proteggere i dati, AlloyDB Omni utilizza moduli crittografici convalidati secondo gli standard FIPS (Federal Information Processing Standards) 140-2 o 140-3. La conformità a FIPS è una responsabilità condivisa tra Google e il cliente, come descritto nella tabella seguente:

Livello del limite FIPS Responsabilità Descrizione
Hardware conforme a FIPS Cliente L'hardware fisico e i componenti crittografici devono essere certificati NIST e configurati in uno stato approvato da FIPS.
Sistema operativo host Cliente Il sistema operativo host della VM o del server bare metal (ad esempio RHEL 9) deve essere eseguito in modalità FIPS. Verifica che il comando cat /proc/sys/crypto/fips_enabled restituisca 1.
Control plane dell'orchestratore Cliente Il nodo di controllo che esegue l'orchestratore Ansible o la CLI deve utilizzare una configurazione del sistema operativo convalidata da FIPS.
Componenti dell'orchestratore Google Sviluppato da Google, distribuito come RPM compatibili con un sistema operativo di base abilitato per FIPS, che gestisce in modo sicuro le operazioni del cluster.
File binari del database Google Esegui il collegamento ai moduli crittografici OpenSSL host convalidati da FIPS e applica gli algoritmi approvati da FIPS per l'hashing delle password (SCRAM-SHA-256) e le suite di cifrari TLS.
Certificati emessi dalla CA personalizzata Condiviso I certificati digitali devono soddisfare gli standard FIPS per la forza della chiave e gli algoritmi di firma. La catena di certificati deve risalire a una CA radice conforme a FIPS.

Responsabilità condivisa STIG

La Defense Information Systems Agency (DISA) pubblica le Security Technical Implementation Guides (STIG) per stabilire standard di cybersecurity e requisiti di protezione per software, sistemi operativi e database.

La protezione dell'ambiente in base ai requisiti STIG è essenziale per ottenere un'autorizzazione all'operatività (ATO) nei settori governativi o ad alta sicurezza. Sebbene AlloyDB Omni implementi per impostazione predefinita molti controlli di sicurezza a livello di database, il raggiungimento della piena conformità a STIG è una responsabilità condivisa che richiede al cliente di configurare e verificare le impostazioni a livello di infrastruttura.

La tabella seguente elenca gli ID delle vulnerabilità STIG che richiedono un'azione, una convalida o una configurazione da parte del cliente. Per informazioni complete, consulta la checklist di conformità alla Security Technical Implementation Guide (STIG) di PostgreSQL 9.x su Red Hat Enterprise Linux.

ID STIG o SRG Descrizione del controllo di sicurezza Comportamento predefinito della piattaforma e dell'operatore Azione o configurazione richiesta al cliente
V-233535 Avvisa immediatamente il personale di assistenza in caso di errori degli audit log. Le diagnostiche degli errori standard vengono scritte in stdout e stderr. Il cliente deve configurare le metriche SIEM o del log forwarder in modo che vengano attivate quando l'importazione diminuisce.
V-233599 Avvisa il personale di assistenza quando l'archiviazione degli audit raggiunge il 75% della capacità. Le metriche del file system vengono esposte tramite gli endpoint Prometheus standard. Il cliente deve configurare le regole di avviso in Prometheus e Grafana per avvisare l'assistenza quando lo spazio su disco dei log supera il 75%.
V-233610 Scarica i dati di audit in una struttura di log continua separata. Gli audit log vengono scritti in modo permanente nella directory dei log locale. Il cliente deve configurare un log forwarder per eseguire lo streaming continuo dei file di log in un SIEM centrale.
V-233603 Considera attendibili solo i certificati di entità finali emessi da un'infrastruttura a chiave pubblica (PKI) o da autorità di certificazione (CA) approvate. L'orchestratore utilizza le configurazioni TLS locali. Il cliente deve fornire i certificati della CA radice e della CA intermedia della PKI per stabilire la catena di attendibilità.
V-233520 Applica le autorizzazioni di accesso logico approvate. Rifiuta le password in testo normale e l'algoritmo Message-Digest 5 (MD5). Consente SCRAM-SHA-256 su SSL. Il cliente deve configurare i client in modo che utilizzino SCRAM-SHA-256 con sslmode=verify-full nelle stringhe di connessione.
V-233522 Limita le soglie delle sessioni simultanee per utente. I ruoli di database predefiniti hanno limiti infiniti vincolati da max_connections. Il cliente deve modificare esplicitamente i limiti di connessione utilizzando ALTER ROLE ... CONNECTION LIMIT per i ruoli delle applicazioni personalizzate.
V-233584 Utilizza la crittografia approvata dalla NSA per le informazioni classificate at-rest. I pacchetti RPM si basano su librerie RHEL 9 sicure e protette. Il cliente deve verificare che il kernel Linux host sottostante abbia la modalità FIPS 140 abilitata.
V-233515 Esegui l'integrazione con i meccanismi di autenticazione a livello di organizzazione AD e LDAP. Il database supporta configurazioni di autenticazione personalizzate. Il cliente deve mappare le identità AD e LDAP nella configurazione del cluster di database.
V-233583 Utilizza moduli crittografici convalidati da FIPS per gli hash. Gli RPM si basano sui moduli FIPS OpenSSL host per le funzioni di hashing. Il cliente deve attivare la modalità FIPS sul sistema operativo host.
V-233585 Utilizza la crittografia convalidata da FIPS per proteggere le informazioni non classificate. Crittografa la comunicazione e l'archiviazione utilizzando pacchetti di crittografia compatibili con FIPS. Il cliente deve verificare che le macchine host siano convalidate da FIPS.
V-233619 Utilizza moduli crittografici convalidati da FIPS per tutte le operazioni. Applica i file binari RPM pronti per FIPS. Il cliente deve abilitare la modalità FIPS sul kernel host.
V-233623 Esegui il DBMS su un host con un modulo FIPS OpenSSL certificato. Il database si basa sulle configurazioni FIPS OpenSSL host. Il cliente deve verificare che il modulo OpenSSL host corrisponda all'elenco FIPS certificato NIST.
V-233615 Mappa le identità autenticate tramite PKI agli account utente associati. Il database utilizza l'autenticazione delle password SCRAM-SHA-256 sicura per le identità. Il cliente deve mappare i ruoli della directory dell'organizzazione esterna ai ruoli del database se non utilizza l'accesso diretto con password.
V-233540 Limita l'account di installazione del database solo agli utenti autorizzati. RPM limita le autorizzazioni dei file e l'esecuzione all'utente postgres. Il cliente deve bloccare l'accesso al nodo host, ad esempio con le restrizioni SSH, per impedire l'accesso non autorizzato al terminale alle VM.