Responsabilidade compartilhada do AlloyDB Omni

Selecione uma versão da documentação:

Nesta página, descrevemos pelo que você, como cliente do AlloyDB Omni, é responsável e pelo que o Google é responsável ao usar a opção de implantação do orquestrador RPM.

Como cliente do AlloyDB Omni, você é responsável por configurar e operar o AlloyDB Omni para que suas cargas de trabalho aproveitem ao máximo o serviço.

Matriz de responsabilidade compartilhada

A tabela a seguir resume as responsabilidades do Google e do cliente em cada camada de uma implantação do orquestrador RPM do AlloyDB Omni:

Camada Responsabilidade do Google Responsabilidade do cliente
Hardware e host Infraestrutura física Fornecer requisitos mínimos e recomendados, quando aplicável. Provisionar servidores físicos, VMs ou dispositivos de borda, incluindo energia, resfriamento e hardware.
Sistema operacional (SO) do host Fornecer requisitos mínimos e recomendados, quando aplicável. Gerenciar o kernel do Linux, aplicar patches de segurança do SO e proteger os nós do host (como RHEL 9 ou Rocky Linux 9).
Componentes de infraestrutura e SO Armazenamento Fornecer requisitos mínimos e recomendados, quando aplicável. Provisionar discos locais ou volumes SAN. O AlloyDB Omni exige um dispositivo de transferência por blocos configurado com um sistema de arquivos compatível, como XFS ou ext4.
Rede Fornecer requisitos mínimos e recomendados, quando aplicável. Provisionar e gerenciar a camada de rede, como roteamento de IP, balanceadores de carga e regras de firewall usando firewalld ou iptables, para abrir portas necessárias, como 5432 para PostgreSQL e 2379 e 2380 para etcd.
Controle de acesso do host Fornecer as contas de serviço e os papéis necessários para os componentes do orquestrador do AlloyDB Omni. Gerenciar o acesso SSH, os privilégios sudo, as políticas do SELinux e as contas de usuário do Linux para se alinhar às suas políticas de segurança internas.
Gerenciamento de secrets Ler variáveis padrão e arquivos de inventário para provisionar recursos, como o usuário postgres inicial. Armazenar com segurança senhas, chaves SSH e tokens usados para orquestração do Ansible e acesso ao banco de dados.
Gerenciamento de certificados Fornecer opções de configuração para integração de certificados. Gerar, distribuir e gerenciar o ciclo de vida dos certificados de Transport Layer Security (TLS) e SSL nas máquinas host.
Software do orquestrador Desenvolvimento e lançamento Desenvolver o orquestrador do AlloyDB Omni, incluindo coleções de CLI e Ansible, e publicar pacotes RPM. Nenhuma. É possível usar artefatos do repositório Yum fornecido para suas implantações.
Instalação e ciclo de vida Fornecer documentação, artefatos RPM e modelos de inventário de implantação.

Verificar a compatibilidade antes da instalação.

Siga as instruções para instalar ou fazer upgrade do AlloyDB Omni usando a CLI do orquestrador alloydbctl ou os playbooks do Ansible.
Mecanismo de banco de dados Binário do banco de dados Fornecer os pacotes RPM do AlloyDB Omni com otimizações proprietárias, como o mecanismo colunar e a aceleração de IA. Nenhuma.
Aplicação de patches Lançar patches de segurança e atualizações de versões secundárias e principais para o mecanismo. Fornecer instruções de upgrade. Agendar upgrades o mais rápido possível, dependendo da criticidade de cada versão.
Gerenciamento de usuários

Provisionar os usuários administrativos iniciais.

Provisionar o superusuário postgres voltado ao usuário.

Fornecer instruções para integração do Protocolo leve de acesso a diretórios (LDAP) e do Active Directory (AD).

Fornecer a senha do superusuário inicial.

Criar e gerenciar todos os outros papéis e usuários.
Gerenciamento de dados Backups Fornecer a automação para gerenciar backups usando pgBackRest com integração compatível com S3. Configurar programações e retenção de backup e provisionar o bucket de destino local, S3 ou do Cloud Storage.
Alta disponibilidade (HA, na sigla em inglês) Fornecer a lógica de failover automático e mecanismos de recuperação usando etcd e o gerenciador de clusters. Provisionar nós suficientes, como um nó de controle, nós etcd e nós de banco de dados primários e de espera, para oferecer suporte a arquiteturas de failover e alta disponibilidade.
Criptografia em repouso Oferecer suporte a implantações em volumes criptografados no nível de bloco. Gerenciar a criptografia da camada de armazenamento, como o Linux Unified Key Setup (LUKS) e dm-crypt, para atender aos requisitos de segurança.
Criptografia em trânsito Configurar o TLS do lado do servidor para conexões de usuário para banco de dados e comunicações internas do cluster. Conectar-se ao banco de dados usando clientes TLS seguros e gerenciar a infraestrutura de certificado subjacente.
Observabilidade Métricas Expor métricas internas do banco de dados usando um endpoint compatível com o Prometheus. Implantar e gerenciar o coletor usando o Prometheus, o OpenTelemetry ou outras soluções compatíveis e a pilha de armazenamento. Monitorar a integridade geral do sistema.
Logging Gravar registros de auditoria e do PostgreSQL em arquivos no disco e gerenciar a rotação. Implantar coletores de registros, como o Fluent Bit ou o Vector, para enviar registros a um back-end de armazenamento, como o Splunk ou a pilha ELK. Preservar registros por um mínimo recomendado de um mês.
Visualização Fornecer métricas e painéis de amostra para monitorar cargas de trabalho padrão. Implantar e monitorar a integridade de uma ferramenta de visualização, como o Grafana. Criar painéis e incorporá-los às tarefas operacionais diárias.
Alertas Nenhuma. Gerenciar o pipeline de alertas, por exemplo, usando uma integração do PagerDuty.
Suporte Solução de problemas Oferecer suporte a bugs de software e erros de mecanismo. Para receber esse suporte, você precisa de uma assinatura. Fornecer suporte inicial por meio da documentação e da base de conhecimento. Depurar problemas relacionados à infraestrutura.

Segurança e conformidade com o FIPS

Para proteger seus dados, o AlloyDB Omni usa módulos criptográficos validados pelo Padrão Federal de Processamento de Informações (FIPS) 140-2 ou 140-3. A conformidade com o FIPS é uma responsabilidade compartilhada entre o Google e o cliente, conforme descrito na tabela a seguir:

Camada de limite do FIPS Responsabilidade Descrição
Hardware compatível com o FIPS Cliente O hardware físico e os componentes criptográficos precisam ser certificados pelo NIST e configurados em um estado aprovado pelo FIPS.
SO do host Cliente O sistema operacional da VM ou do host bare-metal (como o RHEL 9) precisa ser executado no modo FIPS. Verifique se o comando cat /proc/sys/crypto/fips_enabled retorna 1.
Plano de controle do orquestrador Cliente O nó de controle que executa o orquestrador ou a CLI do Ansible precisa usar uma configuração de SO validada pelo FIPS.
Componentes do orquestrador Google Desenvolvido pelo Google, distribuído como RPMs compatíveis com um SO de base ativado pelo FIPS, gerenciando operações de cluster com segurança.
Binários de banco de dados Google Vincular a módulos criptográficos OpenSSL do host validados pelo FIPS e aplicar algoritmos aprovados pelo FIPS para hash de senha (SCRAM-SHA-256) e conjuntos de criptografia TLS.
Certificados de AC personalizada Compartilhado Os certificados digitais precisam atender aos padrões do FIPS para força de chave e algoritmos de assinatura. A cadeia de certificados precisa ser rastreada até uma AC raiz compatível com o FIPS.

Responsabilidade compartilhada do STIG

A Agência de Sistemas de Informação de Defesa (DISA, na sigla em inglês) publica os Guias de implementação técnica de segurança (STIGs, na sigla em inglês) para estabelecer padrões de cibersegurança e requisitos de reforço da proteção para software, sistemas operacionais e bancos de dados.

A proteção do ambiente de acordo com os requisitos do STIG é essencial para receber uma Autorização para operar (ATO, na sigla em inglês) em setores governamentais ou altamente seguros. Embora o AlloyDB Omni implemente muitos controles de segurança no nível do banco de dados por padrão, alcançar a conformidade total com o STIG é uma responsabilidade compartilhada que exige que o cliente configure e verifique as configurações no nível da infraestrutura.

A tabela a seguir lista os IDs de vulnerabilidade do STIG que exigem ação, validação ou configuração pelo cliente. Para informações abrangentes, consulte a lista de verificação de conformidade do Guia de implementação técnica de segurança (STIG) do PostgreSQL 9.x no Red Hat Enterprise Linux.

ID do STIG ou SRG Descrição do controle de segurança Comportamento padrão da plataforma e do operador Ação ou configuração necessária do cliente
V-233535 Alertar a equipe de suporte imediatamente sobre falhas de registro de auditoria. Os diagnósticos de erro padrão são gravados em stdout e stderr. O cliente precisa configurar as métricas do SIEM ou do encaminhador de registros para serem acionadas quando a ingestão cair.
V-233599 Alertar a equipe de suporte quando o armazenamento de auditoria atingir 75% da capacidade. As métricas do sistema de arquivos são expostas por endpoints padrão do Prometheus. O cliente precisa configurar regras de alerta no Prometheus e no Grafana para notificar o suporte quando o espaço em disco de registro exceder 75%.
V-233610 Descarregar dados de auditoria para uma instalação de registro contínuo separada. Os registros de auditoria são gravados de forma persistente no diretório de registro local. O cliente precisa configurar um encaminhador de registros para transmitir arquivos de registro continuamente para um SIEM central.
V-233603 Confie apenas em certificados de entidade final emitidos pela infraestrutura de chave pública (PKI) ou por autoridades certificadoras (ACs) aprovadas. O orquestrador usa configurações TLS locais. O cliente precisa fornecer os certificados de AC raiz e intermediária da PKI para estabelecer a cadeia de confiança.
V-233520 Aplicar autorizações de acesso lógico aprovadas. Rejeita senhas de texto simples e o algoritmo Message-Digest 5 (MD5). Permite SCRAM-SHA-256 em SSL. O cliente precisa configurar os clientes para usar SCRAM-SHA-256 com sslmode=verify-full nas strings de conexão.
V-233522 Limitar os limites de sessão simultânea por usuário. Os papéis de banco de dados padrão têm limites infinitos vinculados por max_connections. O cliente precisa alterar explicitamente os limites de conexão usando ALTER ROLE ... CONNECTION LIMIT para papéis de aplicativo personalizados.
V-233584 Usar criptografia aprovada pela NSA para informações confidenciais em repouso. Os pacotes RPM dependem de bibliotecas RHEL 9 seguras e protegidas. O cliente precisa verificar se o kernel do Linux do host subjacente tem o modo FIPS 140 ativado.
V-233515 Integrar com mecanismos de autenticação no nível da organização do AD e do LDAP. O banco de dados oferece suporte a configurações de autenticação personalizadas. O cliente precisa mapear identidades do AD e do LDAP na configuração do cluster de banco de dados.
V-233583 Usar módulos criptográficos validados pelo FIPS para hashes. Os RPMs dependem de módulos FIPS OpenSSL do host para funções de hash. O cliente precisa ativar o modo FIPS no SO do host.
V-233585 Usar criptografia validada pelo FIPS para proteger informações não classificadas. Criptografa a comunicação e o armazenamento usando cifras compatíveis com o FIPS. O cliente precisa verificar se as máquinas host são validadas pelo FIPS.
V-233619 Usar módulos criptográficos validados pelo FIPS para todas as operações. Aplica binários RPM prontos para o FIPS. O cliente precisa ativar o modo FIPS no kernel do host.
V-233623 Executar o SGBD em um host com um módulo FIPS OpenSSL certificado. O banco de dados depende das configurações FIPS OpenSSL do host. O cliente precisa verificar se o módulo OpenSSL do host corresponde à lista FIPS certificada pelo NIST.
V-233615 Mapear identidades autenticadas por PKI para contas de usuário associadas. O banco de dados usa a autenticação de senha SCRAM-SHA-256 segura para identidades. O cliente precisa mapear os papéis de diretório organizacional externo para papéis de banco de dados se não usar o login direto com senha.
V-233540 Restringir a conta de instalação do banco de dados apenas a usuários autorizados. O RPM restringe as permissões do arquivo e a execução ao usuário postgres. O cliente precisa bloquear o acesso ao nó do host, como com restrições de SSH, para evitar o acesso não autorizado ao terminal das VMs.