Responsabilità condivisa di AlloyDB Omni

Seleziona una versione della documentazione:

Questa pagina descrive le responsabilità di Google e quelle dei clienti di AlloyDB Omni.

In qualità di cliente di AlloyDB Omni, sei responsabile della configurazione e del funzionamento di AlloyDB Omni per assicurarti che i tuoi workload ottengano il massimo valore dal servizio.

incorporato Responsabilità di Google Responsabilità del cliente
Hardware e host Infrastruttura fisica Fornisci i requisiti minimi e consigliati, se applicabili Eseguire il provisioning di server fisici, VM o dispositivi edge come alimentazione, raffreddamento e hardware.
Sistema operativo (OS) host Fornisci i requisiti minimi e consigliati, se applicabili Gestire il kernel Linux, applicare patch di sicurezza del sistema operativo e proteggere i nodi host.
Kubernetes Gestione dei cluster Fornisci i requisiti minimi e consigliati, se applicabili Gestire il cluster su base giornaliera, inclusi gli upgrade, seguendo le best practice standard di settore.
Spazio di archiviazione (CSI/PV) Fornisci i requisiti minimi e consigliati, se applicabili 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 dispositivo a blocchi.
Networking (CNI) Fornisci i requisiti minimi e consigliati, se applicabili Eseguire il provisioning e gestire 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 degli accessi basato su ruoli (RBAC) Fornisci i service account, i ruoli e le associazioni dei ruoli richiesti per l'operatore Kubernetes di AlloyDB Omni. Applica queste regole di controllo dell'accesso basato su ruoli (RBAC) al cluster e assicurati che siano in linea con le policy di sicurezza interne. Per accedere alle risorse AlloyDB Omni, crea ruoli RBAC e associazioni di ruoli aggiuntivi.
Gestione dei secret Leggere i secret Kubernetes standard per eseguire il provisioning delle risorse, ad esempio l'utente postgres iniziale. Creare, proteggere e ruotare i secret di Kubernetes nel cluster.
Gestione dei certificati Affidati ai secret Kubernetes standard e a cert-manager per l'integrazione dei certificati. Installa, configura e gestisci il ciclo di vita di cert-manager.
Software dell'operatore Sviluppo e rilascio Sviluppare la logica e i CRD dell'operatore AlloyDB Omni e pubblicare immagini container, grafici Helm e bundle OLM. Nessuno. Puoi utilizzare gli artefatti archiviati in Artifact Registry per i tuoi deployment.
Installazione e ciclo di vita Fornire la documentazione e gli artefatti di upgrade.
  • Verifica la tabella di compatibilità prima di installare o eseguire l'upgrade di AlloyDB Omni operator.
  • Segui le istruzioni per installare o eseguire l'upgrade dei componenti di AlloyDB Omni.
Motore del database File binario del database Fornire le immagini container di AlloyDB Omni con ottimizzazioni proprietarie, come il motore colonnare e l'accelerazione AI. Nessuno.
Applicazione patch in corso… Rilasciare patch di sicurezza e aggiornamenti delle versioni principali e secondarie per il motore. Fornisci le istruzioni per l'upgrade. Pianifica gli upgrade il prima possibile, a seconda della criticità di ogni release.
Gestione utenti
  • Esegui il provisioning degli utenti iniziali correlati all'operatore AlloyDB Omni.
  • Esegui il provisioning del super utente postgres rivolto agli utenti utilizzando una password fornita dall'utente da un secret di Kubernetes.
  • Fornisci istruzioni per l'integrazione con Microsoft Active Directory.
  • Fornisci la password per il super utente iniziale utilizzando un secret Kubernetes.
  • Creare e gestire tutti gli altri ruoli e utenti.
Gestione dei dati Backup Fornire 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) Fornire la logica di failover automatico e i meccanismi di riparazione. Esegui il provisioning di un numero sufficiente di nodi e zone per fornire un target di standby per supportare il failover.
Crittografia (at-rest) Fornisce 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) Fornire mTLS per i componenti interni dell'operatore e configurare TLS lato server per le connessioni utente-database. Connettiti al database utilizzando client TLS sicuri e gestisci l'infrastruttura dei certificati sottostante.
Osservabilità Metriche Esporre 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. Monitorare l'integrità complessiva del sistema.
Logging Scrivere i log di controllo e di PostgreSQL nei file su disco nel container e ruotarli. Esegui il deployment di 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 periodo minimo consigliato di un mese.
Visualizzazione Fornire dashboard di log e metriche di esempio per monitorare i workload standard. Esegui il deployment e monitora lo stato dello strumento di visualizzazione, come Grafana. Crea dashboard e incorporale nelle tue attività operative quotidiane.
Avvisi Nessuno Gestire la pipeline di avvisi, ad esempio l'integrazione di PagerDuty.
Assistenza Risoluzione dei problemi Fornire assistenza per bug del software ed errori del motore. Per ottenere questa assistenza, devi avere un abbonamento con licenza. Fornire assistenza iniziale tramite la documentazione e la knowledge base. Eseguire il debug dei problemi relativi all'infrastruttura.

Sicurezza e conformità FIPS

Per proteggere i tuoi dati, AlloyDB Omni utilizza moduli di crittografia convalidati Federal Information Processing Standards (FIPS) 140-2 o 140-3. La conformità FIPS è una responsabilità condivisa tra Google e il cliente.

Il seguente diagramma mostra come la responsabilità per la conformità a FIPS è divisa tra Google e il cliente nei livelli di architettura di AlloyDB Omni.

Diagramma che mostra i limiti di responsabilità per la conformità FIPS, suddividendo le responsabilità tra Google, il cliente e le aree condivise.

La tabella seguente descrive i limiti e le responsabilità di FIPS per AlloyDB Omni:

Livello limite FIPS Responsabilità Descrizione
Hardware conforme agli standard FIPS Cliente I componenti hardware e crittografici fisici devono essere certificati dal 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 rete e archiviazione devono utilizzare moduli di crittografia convalidati tramite FIPS, ad esempio creati con Go-BoringCrypto.
Controller dell'operatore AlloyDB Omni Google Sviluppato da Google, basato su un'immagine di base conforme a FIPS (Red Hat UBI), con la conformità FIPS abilitata sul container su cui è in esecuzione il database.
Immagine container AlloyDB Omni Google Utilizza librerie crittografiche conformi a FIPS come BoringSSL e applica algoritmi approvati da FIPS per l'hashing delle password (scram-sha-256) e le suite di cifrari TLS.
Certificati emessi da 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 guide all'implementazione tecnica della sicurezza (STIG) per stabilire standard di cybersicurezza e requisiti di protezione per software, sistemi operativi e database. Queste guide definiscono parametri di sicurezza specifici per proteggere i sistemi da vulnerabilità e cyber minacce.

Per un elenco completo delle regole STIG, consulta Conformità STIG di AlloyDB Omni.

La protezione dell'ambiente in base ai requisiti STIG è essenziale per ottenere un'autorizzazione a operare (ATO) in 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à STIG è una responsabilità condivisa che richiede al cliente di configurare e verificare le impostazioni a livello di infrastruttura.

La tabella seguente elenca tutti gli ID vulnerabilità STIG che richiedono un'azione, una convalida o una configurazione da parte del cliente. Per informazioni complete, consulta l'elenco di controllo per la conformità alla guida all'implementazione tecnica di sicurezza (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 del cliente
V-233535 Avvisa immediatamente il personale di assistenza in caso di errori degli audit log. La diagnostica degli errori standard viene scritta nei container stdout e stderr. Il cliente deve configurare le metriche SIEM o dell'agente di inoltro dei log, ad esempio gli avvisi Splunk/Elastic, in modo che vengano attivate quando l'importazione diminuisce.
V-233599 Avvisa il personale di assistenza quando lo spazio di archiviazione di controllo raggiunge il 75% della capacità. Le metriche del file system vengono esposte tramite endpoint Prometheus standard. Il Cliente deve configurare regole di avviso in Prometheus e Grafana per informare l'assistenza quando lo spazio su disco di /obs/ supera il 75%.
V-233610 Trasferisci i dati di controllo a una struttura di log continua separata. Gli audit log vengono scritti in modo permanente nel volume /obs/diagnostic/. Il cliente deve configurare un forwarder di log, ad esempio FluentBit e Vector, per trasmettere in streaming i file di log in modo continuo a un SIEM centrale.
V-233603 Considera attendibili solo i certificati delle entità finali emessi da un'infrastruttura a chiave pubblica (PKI) o da autorità di certificazione (CA) approvate. L'operatore utilizza cert-manager per configurare le configurazioni TLS locali. Il cliente deve fornire all'operatore i propri certificati CA radice e intermedi PKI per stabilire la catena di attendibilità.
V-233520 Applicare 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 predefiniti del database hanno limiti infiniti vincolati da max_connections. Il cliente deve modificare esplicitamente i limiti di connessione (ALTER ROLE ... CONNECTION LIMIT) per i ruoli applicazione personalizzati.
V-233584 Utilizza la crittografia approvata dalla NSA per le informazioni riservate at-rest. Il container del database utilizza livelli di base UBI9 sicuri e con protezione avanzata. Il cliente deve verificare che il kernel host Kubernetes sottostante abbia la modalità FIPS 140 abilitata.
V-233515 Integrazione con i meccanismi di autenticazione a livello di organizzazione di Active Directory (AD) e Lightweight Directory Access Protocol (LDAP). L'operatore 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 FIPS per gli hash. Il container si basa sui moduli OpenSSL FIPS dell'host per le funzioni di hashing. Il Cliente deve attivare la modalità FIPS sui nodi VM host.
V-233585 Utilizza la crittografia convalidata FIPS per proteggere le informazioni non classificate. Cripta le comunicazioni e lo spazio di archiviazione utilizzando cifrari compatibili con FIPS. Il cliente deve verificare che i nodi host siano convalidati FIPS.
V-233619 Utilizza moduli di crittografia convalidati FIPS per tutte le operazioni. Applica i binari delle immagini container pronti per FIPS UBI9. Il cliente deve attivare la modalità FIPS sul kernel host.
V-233623 Assicurati che il DBMS venga eseguito su un host con OpenSSL FIPS certificato. I pod del database si basano sulle configurazioni FIPS OpenSSL dell'host. Il cliente deve verificare che l'OpenSSL dell'host corrisponda all'elenco FIPS certificato dal 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à. Il cliente deve mappare i ruoli della directory organizzativa 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. Il container limita le autorizzazioni e l'esecuzione dei file all'utente postgres. Il cliente deve bloccare l'accesso al nodo host (SSH/Kubectl) per impedire l'accesso non autorizzato al terminale dei pod.