In qualità di cliente AlloyDB Omni, sei responsabile della configurazione e del funzionamento di AlloyDB Omni per assicurarti che i tuoi carichi di lavoro ottengano il massimo valore dal servizio.
| incorporato | a cura 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 come alimentazione, raffreddamento e hardware. |
| Sistema operativo 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. | |
| Kubernetes | Gestione dei cluster | Fornisci i requisiti minimi e consigliati, ove applicabile | Gestisci il cluster quotidianamente, inclusi gli upgrade, seguendo le best practice standard del settore. |
| Spazio di archiviazione (CSI/PV) | Fornisci i requisiti minimi e consigliati, ove applicabile | Esegui il provisioning della classe di archiviazione e gestisci le appliance sottostanti. AlloyDB Omni richiede un dispositivo a blocchi, quindi assicurati di scegliere una classe di dispositivi a blocchi. | |
| Networking (CNI) | Fornisci i requisiti minimi e consigliati, ove applicabile | Esegui il provisioning e gestisci il livello di rete, ad esempio il networking dei pod, i controller Ingress, i bilanciatori del carico e le regole firewall tra i nodi. | |
| Controllo dell'accesso basato su ruoli (RBAC) | Fornisci i service account, i ruoli e le associazioni di ruoli richiesti per l'operatore AlloyDB Omni Kubernetes. | Applica queste regole di controllo dell'accesso basato su ruoli (RBAC) al cluster e assicurati che siano in linea con le norme di sicurezza interne. Per accedere alle risorse AlloyDB Omni, crea ruoli RBAC e associazioni di ruoli aggiuntivi. | |
| Gestione di secret | Leggi i secret Kubernetes standard per eseguire il provisioning delle risorse, ad esempio l'utente postgres iniziale. |
Crea, proteggi e ruota i secret Kubernetes nel cluster. | |
| Gestione dei certificati | Utilizza i secret Kubernetes standard e cert-manager per l'integrazione dei certificati. |
Installa, configura e gestisci il ciclo di vita di cert-manager. |
|
| Software operatore | Sviluppo e rilascio | Sviluppa la logica dell'operatore AlloyDB Omni e i CRD e pubblica le immagini container, i grafici Helm e i bundle OLM. | Nessuno. Puoi utilizzare gli artefatti archiviati in Artifact Registry per i deployment. |
| Installazione e ciclo di vita | Fornisci la documentazione e gli artefatti di upgrade. |
|
|
| Motore del database | File binario del database | Fornisci le immagini container AlloyDB Omni con ottimizzazioni proprietarie come il motore colonnare e l'accelerazione AI. | Nessuno. |
| Applicazione patch in corso… | Rilascia le patch di sicurezza e gli aggiornamenti delle versioni secondarie e principali del motore. Fornisci le istruzioni per l'upgrade. | Pianifica gli upgrade il prima possibile, a seconda della criticità di ogni release. | |
| Gestione utenti |
|
|
|
| Gestione dei dati | Backup | Fornisci i CRD e la logica `BackupPlan` e `Backup` per gestire i backup,
che vengono gestiti utilizzando pgBackrest con l'integrazione compatibile con S3. |
Configura le pianificazioni e la conservazione dei backup ed esegui il provisioning del bucket di archiviazione di destinazione locale, S3 o Cloud Storage. |
| Alta affidabilità (HA) | Fornisci la logica di failover automatico e i meccanismi di ripristino. | Esegui il provisioning di nodi e zone sufficienti per fornire una destinazione di standby a supporto del failover. | |
| Crittografia (at-rest) | Fornisce il supporto per la crittografia TDE (Transparent Data Encryption). | Gestisci la crittografia del livello di archiviazione per assicurarti che soddisfi i tuoi requisiti. | |
| Crittografia (in transito) | Fornisci mTLS per i componenti dell'operatore interno e per configurare TLS lato server per le connessioni da utente a database. | Connettiti al database utilizzando client TLS sicuri e gestisci l'infrastruttura di certificati sottostante. | |
| Osservabilità | Metriche | Espone le metriche del database interno utilizzando un endpoint compatibile con Prometheus. | Esegui il deployment e gestisci lo scraper utilizzando Prometheus, Open Telemetry o altre soluzioni compatibili e il relativo stack di archiviazione. Monitora lo stato di integrità complessivo del sistema. |
| Logging | Scrivi i log di PostgreSQL e di audit nei file su disco nel container e ruotali. | Esegui il deployment dei raccoglitori di log, ad esempio Fluentd e Fluent Bit, per inviare i log a un backend di archiviazione (come Splunk o ELK). Assicurati che i raccoglitori di log siano configurati per conservare i log per un minimo consigliato di un mese. | |
| Visualizzazione | Fornisci metriche di esempio e dashboard di log per monitorare i carichi di lavoro standard. | Esegui il deployment e monitora lo stato di integrità dello strumento di visualizzazione, ad esempio Grafana. Crea dashboard e incorporale nelle attività operative quotidiane. | |
| Avvisi | Nessuno | Gestisci la pipeline di avvisi, ad esempio l'integrazione PagerDuty. | |
| Assistenza | Risoluzione dei problemi | Fornisci assistenza per i bug del software e gli errori del motore. Per ottenere questa assistenza, devi avere un abbonamento con licenza. | Fornisci assistenza iniziale tramite documentazione e knowledge base. Esegui il debug dei problemi relativi all'infrastruttura. |
Sicurezza e conformità FIPS
Per proteggere i dati, AlloyDB Omni utilizza moduli di crittografia convalidati tramite FIPS (Federal Information Processing Standards) 140-2 o 140-3. La conformità FIPS è una responsabilità condivisa tra Google e il cliente.
Il seguente diagramma mostra come la responsabilità della conformità FIPS è suddivisa tra Google e il cliente nei livelli architetturali di AlloyDB Omni.
La tabella seguente descrive i limiti e le responsabilità FIPS per AlloyDB Omni:
| Livello del limite FIPS | Responsabilità | Descrizione |
|---|---|---|
| Hardware conforme a FIPS | Cliente | L'hardware fisico e i componenti di crittografia devono essere certificati NIST e configurati in uno stato approvato da FIPS. |
| Sistema operativo dei nodi Kubernetes | Cliente | Il sistema operativo host del nodo worker, ad esempio RHEL, deve essere eseguito in modalità FIPS. Lo stato FIPS deve essere verificato (cat /proc/sys/crypto/fips_enabled restituisce 1). |
| Control plane Kubernetes | Cliente | I componenti del control plane come kubelet e i plug-in di networking e archiviazione devono utilizzare moduli di crittografia convalidati da FIPS, ad esempio creati con Go-BoringCrypto. |
| Controller dell'operatore AlloyDB Omni | Sviluppato da Google, basato su un'immagine di base conforme a FIPS (Red Hat UBI), con la conformità FIPS abilitata nel container su cui è in esecuzione il database. | |
| Immagine container AlloyDB Omni | Utilizza librerie di crittografia conformi a FIPS come BoringSSL e applica algoritmi approvati da FIPS per l'hashing delle password (scram-sha-256) e le suite di cifratura TLS. |
|
| Certificati emessi dalla CA personalizzata | Condiviso | I certificati digitali devono soddisfare gli standard FIPS per la sicurezza delle chiavi 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 Guide (STIG) per stabilire standard di cybersecurity e requisiti di protezione per software, sistemi operativi e database. Queste guide definiscono parametri di sicurezza specifici per proteggere i sistemi da vulnerabilità e minacce informatiche.
Per un elenco completo delle regole STIG, vedi Conformità STIG di AlloyDB Omni.
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 conformità STIG completa è una responsabilità condivisa che richiede al cliente di configurare e verificare le impostazioni a livello di infrastruttura.
La tabella seguente elenca tutti gli ID di vulnerabilità STIG che richiedono un'azione, una convalida o una configurazione da parte del cliente. Per informazioni complete, vedi 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 dal cliente |
|---|---|---|---|
| V-233535 | Avvisa immediatamente il personale di assistenza in caso di errori nei log di audit. | La diagnostica degli errori standard viene scritta in stdout e stderr del container. |
Il cliente deve configurare le metriche SIEM o di inoltro dei log, ad esempio gli avvisi Splunk/Elastic, in modo che si attivino quando l'importazione diminuisce. |
| V-233599 | Avvisa il personale di assistenza quando lo spazio di archiviazione di 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 /obs/ supera il 75%. |
| V-233610 | Scarica i dati di audit in una struttura di log continua separata. | I log di audit vengono scritti in modo permanente nel volume /obs/diagnostic/. |
Il cliente deve configurare un log forwarder, ad esempio FluentBit e Vector, per trasmettere in streaming continuo i file di log a un SIEM centrale. |
| V-233603 | Affidati solo ai certificati dell'entità finale emessi dall'infrastruttura a chiave pubblica (PKI) o dalle autorità di certificazione (CA) approvate. | L'operatore utilizza cert-manager per configurare le configurazioni TLS locali. |
Il cliente deve fornire i certificati della CA radice e della CA intermedia della PKI all'operatore 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 di 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 (ALTER ROLE ... CONNECTION LIMIT) per i ruoli dell'applicazione personalizzata. |
| V-233584 | Utilizza la crittografia approvata dalla NSA per le informazioni classificate a riposo. | Il container del database utilizza livelli di base UBI9 sicuri e protetti. | Il cliente deve verificare che il kernel host Kubernetes sottostante abbia la modalità FIPS 140 abilitata. |
| V-233515 | Integra i meccanismi di autenticazione a livello di organizzazione Active Directory (AD) e LDAP (Lightweight Directory Access Protocol). | L'operatore supporta le configurazioni di autenticazione personalizzate. | Il cliente deve mappare le identità AD e LDAP nella configurazione del cluster di database. |
| V-233583 | Utilizza moduli di crittografia convalidati da FIPS per gli hash. | Il container si basa sui moduli FIPS OpenSSL host per le funzioni di hashing. | Il cliente deve attivare la modalità FIPS sui nodi VM host. |
| V-233585 | Utilizza la crittografia convalidata da FIPS per proteggere le informazioni non classificate. | Cripta la comunicazione e l'archiviazione utilizzando cifrari compatibili con FIPS. | Il cliente deve verificare che i nodi host siano convalidati da FIPS. |
| V-233619 | Utilizza moduli di crittografia convalidati da FIPS per tutte le operazioni. | Applica i file binari delle immagini container UBI9 pronte per FIPS. | Il cliente deve abilitare la modalità FIPS sul kernel host. |
| V-233623 | Assicurati che il DBMS sia in esecuzione su un host con OpenSSL FIPS certificato. | I pod del database si basano sulle configurazioni FIPS OpenSSL host. | Il cliente deve verificare che OpenSSL host corrisponda all'elenco FIPS certificato NIST. |
| V-233615 | Mappa le identità autenticate tramite PKI agli account utente associati. | L'operatore utilizza l'autenticazione con password SCRAM-SHA-256 sicura per le identità. |
Se non utilizzano l'accesso diretto con password, i clienti devono mappare i ruoli della directory dell'organizzazione esterna ai ruoli del database. |
| V-233540 | Limita l'account di installazione del database solo agli utenti autorizzati. | Il container limita le autorizzazioni di file e l'esecuzione all'utente postgres. |
Il cliente deve bloccare l'accesso ai nodi host (SSH/Kubectl) per impedire l'accesso non autorizzato al terminale ai pod. |