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.

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

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, como 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.
Kubernetes Gerenciamento de clusters Fornecer requisitos mínimos e recomendados, quando aplicável Gerenciar o cluster diariamente, incluindo upgrades, seguindo as práticas recomendadas padrão do setor.
Armazenamento (CSI/PV) Fornecer requisitos mínimos e recomendados, quando aplicável Provisionar a classe de armazenamento e gerenciar os dispositivos subjacentes. O AlloyDB Omni exige um dispositivo de transferência por blocos. Portanto, escolha uma classe de dispositivo de transferência por blocos.
Rede (CNI) Fornecer requisitos mínimos e recomendados, quando aplicável Provisionar e gerenciar a camada de rede, por exemplo, rede de pods, controladores de entrada, balanceadores de carga e regras de firewall entre nós.
Controle de acesso baseado em função (RBAC) Fornecer as contas de serviço, os papéis e as vinculações de papéis necessários para o operador do AlloyDB Omni no Kubernetes. Aplique essas regras de controle de acesso baseado em função (RBAC) ao cluster e verifique se elas estão alinhadas às políticas de segurança internas. Para acessar os recursos do AlloyDB Omni, crie outros papéis e vinculações de papéis do RBAC.
Gerenciamento de secrets Leia os secrets padrão do Kubernetes para provisionar recursos, como o usuário postgres inicial. Crie, proteja e alterne os secrets do Kubernetes no cluster.
Gerenciamento de certificados Use os secrets padrão do Kubernetes e o cert-manager para integração de certificados. Instale, configure e gerencie o ciclo de vida do cert-manager.
Software do operador Desenvolvimento e lançamento Desenvolva a lógica e os CRDs do operador do AlloyDB Omni e publique imagens de contêiner, gráficos do Helm e pacotes do OLM. Nenhuma. É possível usar artefatos armazenados no Artifact Registry para suas implantações.
Instalação e ciclo de vida Fornecer documentação e artefatos de upgrade.
  • Verifique a tabela de compatibilidade antes de instalar ou fazer upgrade do operador do AlloyDB Omni.
  • Siga as instruções para instalar ou fazer upgrade dos componentes do AlloyDB Omni.
Mecanismo de banco de dados Binário do banco de dados Fornecer as imagens de contêiner do AlloyDB Omni com otimizações proprietárias, como o mecanismo colunar e a aceleração de IA. Nenhuma.
Aplicação de patches Liberar patches de segurança e atualizações de versões secundárias e principais para o mecanismo. Fornecer instruções de upgrade. Programe upgrades o mais rápido possível, dependendo da criticidade de cada versão.
Gerenciamento de usuários
  • Provisionar os usuários iniciais relacionados ao operador do AlloyDB Omni.
  • Provisionar o superusuário postgres voltado ao usuário usando uma senha fornecida pelo usuário de um secret do Kubernetes.
  • Fornecer instruções para integração com o Microsoft Active Directory.
  • Fornecer a senha do superusuário inicial usando um secret do Kubernetes.
  • Criar e gerenciar todos os outros papéis e usuários.
Gerenciamento de dados Backups Fornecer os CRDs e a lógica `BackupPlan` e `Backup` para gerenciar backups, que são gerenciados usando pgBackrest com integração compatível com S3. Configure programações e retenção de backup e provisione o bucket de armazenamento 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 os mecanismos de recuperação. Provisione nós e zonas suficientes para fornecer um destino de espera para oferecer suporte ao failover.
Criptografia (em repouso) Oferece suporte à Criptografia transparente de dados (TDE). Gerencie a criptografia da camada de armazenamento para garantir que ela atenda aos seus requisitos.
Criptografia (em trânsito) Fornecer mTLS para componentes internos do operador e configurar o TLS do lado do servidor para conexões de usuário com o banco de dados. Conecte-se ao banco de dados usando clientes TLS seguros e gerencie a infraestrutura de certificado subjacente.
Observabilidade Métricas Expor métricas internas do banco de dados usando um endpoint compatível com o Prometheus. Implante e gerencie o scraper usando o Prometheus, o Open Telemetry ou outras soluções compatíveis e a pilha de armazenamento delas. Monitore a integridade geral do sistema.
Logging Grave registros de auditoria e do PostgreSQL em arquivos no disco no contêiner e alterne-os. Implante coletores de registros, por exemplo, Fluentd e Fluent Bit, para enviar registros a um back-end de armazenamento (como Splunk ou ELK). Verifique se os coletores de registros estão configurados para preservar os registros por um mínimo recomendado de um mês.
Visualização Fornecer métricas de amostra e painéis de registros para monitorar cargas de trabalho padrão. Implante e monitore a integridade da ferramenta de visualização, como o Grafana. Crie painéis e incorpore-os às suas tarefas operacionais diárias.
Alertas Nenhum Gerenciar o pipeline de alertas, por exemplo, a 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 de licença. 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.

O diagrama a seguir mostra como a responsabilidade pela conformidade com o FIPS é dividida entre o Google e o cliente nas camadas arquitetônicas do AlloyDB Omni.

Diagrama que mostra os limites de responsabilidade de conformidade com o FIPS, dividindo as responsabilidades entre o Google, o cliente e as áreas compartilhadas.

A tabela a seguir descreve os limites e as responsabilidades do FIPS para o AlloyDB Omni:

Camada de limite do FIPS Responsabilidade Descrição
Hardware compatível com o FIPS Cliente Os componentes criptográficos e de hardware físico precisam ser certificados pelo NIST e configurados em um estado aprovado pelo FIPS.
SO dos nós do Kubernetes Cliente O sistema operacional do host do nó de trabalho, por exemplo, o RHEL, precisa ser executado no modo FIPS. O estado do FIPS precisa ser verificado (cat /proc/sys/crypto/fips_enabled retorna 1).
Plano de controle do Kubernetes Cliente Os componentes do plano de controle, como kubelet e plug-ins de rede e armazenamento, precisam usar módulos criptográficos validados pelo FIPS, por exemplo, criados com o Go-BoringCrypto.
Controladores do operador do AlloyDB Omni Google Desenvolvido pelo Google, criado em uma imagem de base compatível com o FIPS (Red Hat UBI), com a conformidade com o FIPS ativada no contêiner em que o banco de dados está em execução.
Imagem do contêiner do AlloyDB Omni Google Usa bibliotecas criptográficas compatíveis com o FIPS, como o BoringSSL, e aplica algoritmos aprovados pelo FIPS para hash de senhas (scram-sha-256) e conjuntos de criptografia TLS.
Certificados de AC personalizada Compartilhado Os certificados digitais precisam atender aos padrões do FIPS para algoritmos de assinatura e força de chave. 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. Esses guias definem parâmetros de segurança específicos para proteger sistemas contra vulnerabilidades e ameaças cibernéticas.

Para conferir uma lista completa de regras do STIG, consulte Conformidade do STIG do AlloyDB Omni.

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 todos os IDs de vulnerabilidade do STIG que exigem ação, validação ou configuração do 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 Alerta imediatamente a equipe de suporte sobre falhas de registro de auditoria. Os diagnósticos de erro padrão são gravados em stdout e stderr do contêiner. O cliente precisa configurar métricas de encaminhador de registros ou SIEM, por exemplo, alertas do Splunk/Elastic, para serem acionadas quando a ingestão cair.
V-233599 Alerta 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 /obs/ exceder 75%.
V-233610 Descarregue os dados de auditoria para uma instalação de registro contínuo separada. Os registros de auditoria são gravados de forma persistente no volume /obs/diagnostic/. O cliente precisa configurar um encaminhador de registros, por exemplo, FluentBit e Vector, 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, na sigla em inglês) ou por autoridades certificadoras (ACs) aprovadas. O operador usa o cert-manager para configurar configurações TLS locais. O cliente precisa fornecer os certificados de AC raiz e intermediária da PKI ao operador para estabelecer a cadeia de confiança.
V-233520 Aplique 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 Limite os limites de sessão simultânea por usuário. Os papéis de banco de dados padrão têm limites infinitos limitados por max_connections. O cliente precisa alterar explicitamente os limites de conexão (ALTER ROLE ... CONNECTION LIMIT) para papéis de aplicativo personalizados.
V-233584 Use criptografia aprovada pela NSA para informações confidenciais em repouso. O contêiner de banco de dados usa camadas de base UBI9 seguras e protegidas. O cliente precisa verificar se o kernel do host do Kubernetes subjacente tem o modo FIPS 140 ativado.
V-233515 Integre-se aos mecanismos de autenticação no nível da organização do Active Directory (AD) e do Protocolo leve de acesso a diretórios (LDAP). O operador oferece suporte a configurações de autenticação personalizadas. O cliente precisa mapear identidades de AD e LDAP na configuração do cluster de banco de dados.
V-233583 Use módulos criptográficos validados pelo FIPS para hashes. O contêiner depende dos módulos FIPS do OpenSSL do host para funções de hash. O cliente precisa ativar o modo FIPS nos nós da VM do host.
V-233585 Use criptografia validada pelo FIPS para proteger informações não classificadas. Criptografa a comunicação e o armazenamento usando criptografias compatíveis com o FIPS. O cliente precisa verificar se os nós do host são validados pelo FIPS.
V-233619 Use módulos criptográficos validados pelo FIPS para todas as operações. Aplica binários de imagem de contêiner prontos para o FIPS do UBI9. O cliente precisa ativar o modo FIPS no kernel do host.
V-233623 Verifique se o SGBD é executado no host com o OpenSSL FIPS certificado. Os pods de banco de dados dependem das configurações FIPS do OpenSSL do host. O cliente precisa verificar se o OpenSSL do host corresponde à lista de FIPS certificada pelo NIST.
V-233615 Mapeie identidades autenticadas por PKI para contas de usuário associadas. O operador usa a autenticação de senha SCRAM-SHA-256 segura para identidades. O cliente precisa mapear papéis de diretório organizacional externos para papéis de banco de dados se não usar o login direto com senha.
V-233540 Restrinja a conta de instalação do banco de dados apenas a usuários autorizados. O contêiner restringe as permissões do arquivo e a execução ao usuário postgres. O cliente precisa bloquear o acesso ao nó do host (SSH/Kubectl) para impedir o acesso não autorizado ao terminal dos pods.