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 serviço 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 Forneça requisitos mínimos e recomendados, quando aplicável Provisione servidores físicos, VMs ou dispositivos de borda, como energia, resfriamento e hardware.
Sistema operacional (SO) do host Forneça 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 Forneça requisitos mínimos e recomendados, quando aplicável Gerencie o cluster diariamente, incluindo upgrades, seguindo as práticas recomendadas padrão do setor.
Armazenamento (CSI/PV) Forneça requisitos mínimos e recomendados, quando aplicável Provisione a classe de armazenamento e gerencie os dispositivos. O AlloyDB Omni exige um dispositivo de transferência por blocos. Portanto, escolha uma classe de dispositivo de transferência por blocos.
Rede (CNI) Forneça requisitos mínimos e recomendados, quando aplicável Provisione e gerencie 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) Forneça as contas de serviço, os papéis e as vinculações de papéis necessários para o operador do Kubernetes do AlloyDB Omni. 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 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 inicial postgres. Crie, proteja e gire secrets do Kubernetes no cluster.
Gerenciamento de certificados Use segredos padrão do Kubernetes e 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 do operador e os CRDs 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 seus implantações.
Instalação e ciclo de vida Forneça 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 do banco de dados Binário de 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 Lançar patches de segurança e atualizações de versões secundárias e principais para o mecanismo. Forneça instruções de upgrade. Programe upgrades assim que possível, dependendo da importância de cada lançamento.
Gerenciamento de usuários
  • Provisione os usuários iniciais relacionados ao operador do AlloyDB Omni.
  • Provisione o superusuário postgres voltado para o usuário usando uma senha fornecida pelo usuário de um secret do Kubernetes.
  • Forneça instruções para integrar com o Microsoft Active Directory.
  • Forneça a senha do superusuário inicial usando um secret do Kubernetes.
  • Criar e gerenciar todas as outras funções e usuários.
Gerenciamento de dados Backups Forneça 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, do 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 correção. Provisione nós e zonas suficientes para fornecer um destino de espera e suportar o 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) Forneça mTLS para componentes internos do operador e configure 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 certificados subjacente.
Observabilidade Métricas Exponha 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 do PostgreSQL e de auditoria em arquivos no disco do contêiner e faça a rotação deles. Implante coletores de registros, como o Fluentd e o Fluent Bit, para enviar registros a um back-end de armazenamento (como o Splunk ou o 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 com o PagerDuty.
Suporte Solução de problemas Oferecer suporte para bugs de software e erros de mecanismo. Para receber esse suporte, você precisa de uma assinatura de licença. Fornecer suporte inicial por meio de documentação e base de conhecimento. Depure problemas relacionados à infraestrutura.

Segurança e compliance 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 mostrando os limites de responsabilidade da conformidade com a 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 limite do FIPS Responsabilidade Descrição
Hardware em conformidade 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 dos nós do Kubernetes Cliente O sistema operacional host do nó de trabalho, por exemplo, 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 Go-BoringCrypto.
Controladores do operador do AlloyDB Omni Google Desenvolvido pelo Google, criado em uma imagem de base compatível com FIPS (Red Hat UBI) e com a conformidade com FIPS ativada no contêiner em que o banco de dados está sendo executado.
Imagem do contêiner do AlloyDB Omni Google Usa bibliotecas criptográficas compatíveis com FIPS, como o BoringSSL, e aplica algoritmos aprovados pelo FIPS para hash de senhas (scram-sha-256) e pacotes de criptografia TLS.
Certificados de CA personalizada Compartilhado Os certificados digitais precisam atender aos padrões FIPS de nível de chave e algoritmos de assinatura. A cadeia de certificados precisa rastrear uma CA raiz compatível com FIPS.

Responsabilidade compartilhada do STIG

A Agência de Sistemas de Informação de Defesa (DISA, na sigla em inglês) publica 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 específicos de segurança para proteger os sistemas contra vulnerabilidades e ameaças cibernéticas.

Para uma lista completa de regras da STIG, consulte Conformidade com a STIG do AlloyDB Omni.

O reforço da proteção do ambiente de acordo com os requisitos do STIG é essencial para obter uma autorização de operação (ATO, na sigla em inglês) em setores altamente seguros ou governamentais. Embora o AlloyDB Omni implemente muitos controles de segurança no nível do banco de dados por padrão, 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 da 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 técnico de implementação de segurança (STIG) do PostgreSQL 9.x no Red Hat Enterprise Linux.

ID do STIG ou do 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 imediatamente a equipe de suporte sobre falhas no registro de auditoria. Os diagnósticos de erro padrão são gravados nos contêineres stdout e stderr. O cliente precisa configurar métricas de SIEM ou encaminhador de registros, como alertas do Splunk/Elastic, para serem acionadas quando a ingestão diminuir.
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 /obs/ exceder 75%.
V-233610 Descarregue os dados de auditoria em uma instalação de registro contínuo separada. Os registros de auditoria são gravados de forma permanente no volume /obs/diagnostic/. O cliente precisa configurar um encaminhador de registros, como o FluentBit e o Vector, para transmitir arquivos de registros continuamente para um SIEM central.
V-233603 Confie apenas em certificados de entidade final emitidos por infraestrutura de chave pública (ICP) ou autoridades de certificação (CA) aprovadas. O operador usa cert-manager para configurar configurações TLS locais. O cliente precisa fornecer os certificados de CA raiz e intermediários da PKI ao operador 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 por 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ões simultâneas por usuário. As funções de banco de dados padrão têm limites infinitos vinculados 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 classificadas em repouso. O contêiner de banco de dados usa camadas de base UBI9 seguras e reforçadas. O cliente precisa verificar se o kernel do host Kubernetes subjacente tem o modo FIPS 140 ativado.
V-233515 Integração com 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 é compatível com configurações de autenticação personalizadas. O cliente precisa mapear as identidades do AD e do 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 host.
V-233585 Use criptografia validada pelo FIPS para proteger informações não classificadas. Criptografa a comunicação e o armazenamento usando algoritmos compatíveis com FIPS. O cliente precisa verificar se os nós de host são validados pelo FIPS.
V-233619 Use módulos criptográficos validados pelo FIPS em todas as operações. Impõe binários de imagem de contêiner prontos para FIPS do UBI9. O cliente precisa ativar o modo FIPS no kernel do host.
V-233623 Verifique se o SGBD está sendo executado em um host com 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 FIPS certificada pelo NIST.
V-233615 Mapear identidades autenticadas por PKI para contas de usuários associadas. O operador usa a autenticação de senha SCRAM-SHA-256 segura para identidades. O cliente precisa mapear as funções do diretório organizacional externo para as funções do 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 de 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.