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 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 requer um dispositivo de transferência por blocos. Por isso, 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) Forneça as contas de serviço, os papéis e as vinculações de papéis necessários para o operador do AlloyDB Omni para Kubernetes. Aplique essas regras de controle de acesso baseado em papéis (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 de RBAC e vinculações de papéis.
Gerenciamento de secrets Ler os Secrets padrão do Kubernetes para provisionar recursos, como o usuário inicial do postgres. Criar, proteger e alternar secrets do Kubernetes no cluster.
Gerenciamento de certificados Confie nos Secrets padrão do Kubernetes e no 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 Desenvolver a lógica do operador do AlloyDB Omni e as CRDs e publicar 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 Forneça documentação e faça upgrade dos artefatos.
  • 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 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 o mais rápido possível, dependendo da importância de cada versão.
Gerenciamento de usuários
  • Provisione os usuários iniciais relacionados ao operador do AlloyDB Omni.
  • Provisione o superusuário postgres voltado ao usuário usando uma senha fornecida pelo usuário de um secret do Kubernetes.
  • Forneça instruções para integração 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 de `BackupPlan` e `Backup` para gerenciar backups, que são gerenciados usando pgBackrest com integração compatível com S3. Configure as programações de backup e retenção 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 recuperação. Provisione nós e zonas suficientes para fornecer um destino de espera que ofereça suporte ao failover.
Criptografia (em repouso) Oferece suporte à criptografia transparente de dados (TDE, na sigla em inglês). 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 para banco de dados. Conectar-se ao banco de dados usando clientes TLS seguros e gerenciar a infraestrutura de certificados subjacente.
Observabilidade Métricas Expor métricas de banco de dados interno usando um endpoint compatível com o Prometheus. Implantar e gerenciar o scraper usando o Prometheus, o Open Telemetry ou outras soluções compatíveis e a pilha de armazenamento delas. Monitorar a integridade geral do sistema.
Logging Gravar registros de auditoria e do PostgreSQL em arquivos no disco no contêiner e fazer a rotação deles. Implantar coletores de registros, como 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 período mínimo recomendado de um mês.
Visualização Fornecer métricas de amostra e painéis de registro para monitorar cargas de trabalho padrão. Implantar e monitorar a integridade da ferramenta de visualização, como o Grafana. Crie painéis e os incorpore à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. Oferecer suporte inicial por meio de documentação e 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 pelos padrões federais de processamento de informações (FIPS, na sigla em inglês) 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 em conformidade 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 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 o 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), com a conformidade com 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 BoringSSL, e aplica algoritmos aprovados pelo FIPS para hash de senha (scram-sha-256) e pacotes de criptografia TLS.
Certificados de CA personalizada Compartilhado Os certificados digitais precisam atender aos padrões FIPS para força de chave e algoritmos de assinatura. A cadeia de certificados precisa ser rastreada até 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 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 os sistemas contra vulnerabilidades e ameaças cibernéticas.

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

A proteção do ambiente de acordo com os requisitos do STIG é essencial para obter uma Autorização para Operar (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, 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 por parte do cliente. Para informações abrangentes, consulte a lista de verificação de conformidade do PostgreSQL 9.x no Guia de Implementação Técnica de Segurança (STIG, na sigla em inglês) do 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 no registro de auditoria. Os diagnósticos de erro padrão são gravados no contêiner stdout e stderr. O cliente precisa configurar as métricas do SIEM ou do encaminhador de registros (por exemplo, alertas do Splunk/Elastic) 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 do /obs/ exceder 75%.
V-233610 Descarregue os dados de auditoria em um recurso de registro contínuo separado. Os registros de auditoria são gravados de forma persistente no volume /obs/diagnostic/. O cliente precisa configurar um encaminhador de registros, como o FluentBit e o Vector, para transmitir arquivos de registro continuamente para um SIEM central.
V-233603 Confie apenas em certificados de entidade final emitidos por infraestrutura de chave pública (ICP) ou autoridades certificadoras (AC) aprovadas. O operador usa cert-manager para definir as configurações de TLS locais. O cliente precisa fornecer os certificados de CA raiz e intermediária 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. 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 aplicativos personalizados.
V-233584 Use criptografia aprovada pela NSA para informações confidenciais em repouso. O contêiner do banco de dados usa camadas de base UBI9 seguras e reforçadas. O Cliente precisa verificar se o kernel do host do Kubernetes tem o modo FIPS 140 ativado.
V-233515 Integração com os mecanismos de autenticação no nível da organização do Active Directory (AD) e do protocolo 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 do 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 hash. O Cliente precisa ativar o modo FIPS nos nós da VM host.
V-233585 Usar criptografia validada pelo FIPS para proteger informações não classificadas. Criptografa a comunicação e o armazenamento usando criptografias compatíveis com FIPS. O cliente precisa verificar se os nós do host têm validação FIPS.
V-233619 Use módulos de criptografia validados pelo FIPS para 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 DBMS é executado no host com o OpenSSL FIPS certificado. Os pods de banco de dados dependem das configurações de 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 segura SCRAM-SHA-256 para identidades. O Cliente precisa mapear os papéis do diretório organizacional externo para os papéis 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 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 do terminal aos pods.