Boletim de segurança

Selecione uma versão da documentação:

Para avaliar a postura de segurança das implantações do AlloyDB Omni no Kubernetes e planejar upgrades do plano de controle e do cluster de banco de dados, consulte as políticas de segurança, a arquitetura do operador, o controle de acesso baseado em papéis (RBAC) e os contextos de segurança, além das práticas de divulgação de vulnerabilidades e exposições comuns (CVE) nesta página.

Para receber as notas da versão e as atualizações de segurança mais recentes do AlloyDB Omni no seu leitor de feed, inscreva-se no feed de notas da versão do AlloyDB Omni.

Arquitetura do operador e contextos de segurança

O AlloyDB Omni no Kubernetes separa o plano de controle do Kubernetes dos pods do mecanismo de banco de dados que processam as consultas do aplicativo:

  • Componentes do plano de controle e do operador: cada versão do operador do AlloyDB Omni compreende 10 imagens de contêiner criadas na Red Hat Universal Base Image 9 (UBI 9):
    • operator/fleet-operator: controlador do Kubernetes no nível da frota que reconcilia DBCluster e recursos personalizados da frota.
    • operator/local-operator: controlador do Kubernetes no nível da instância que gerencia os ciclos de vida dos pods do banco de dados local e se comunica apenas com o servidor de API Kubernetes interno do cluster confiável.
    • alloydbomni-operator-catalog e alloydbomni-operator-olm-bundle: índice de catálogo do Red Hat OpenShift Operator Lifecycle Manager (OLM) e imagens de metadados de pacote declarativo
    • operator/dbinit e operator/backupinit: contêineres de inicialização temporários para fluxos de trabalho de inicialização, backup e restauração de banco de dados
    • operator/alloydbomni-monitor (substitui monitoring-agent), operator/g-pgbouncer, operator/logrotate e operator/node-manager: contêineres de gerenciamento de nós e sidecar complementar para sondagem de integridade, pool de conexões, rotação de registros e gerenciamento de armazenamento
  • RBAC e contextos de segurança: o operador do AlloyDB Omni usa permissões com escopo do Kubernetes Role e ClusterRole para reconciliar recursos personalizados em namespaces de destino e executa cargas de trabalho do plano de controle e do sidecar com contextos de segurança de contêiner restritos.
  • Pods do mecanismo de banco de dados: as instâncias de banco de dados gerenciadas pelo operador executam as imagens de contêiner do kernel do banco de dados independente do AlloyDB Omni. Para verificar quais versões do kernel do banco de dados são compatíveis com a versão do operador, consulte Escolher versões compatíveis do operador do Kubernetes e do cluster de banco de dados.

Filtragem de escopo e gravidade

Para focar os fluxos de trabalho de correção em avisos de segurança acionáveis e reduzir o ruído do scanner, os resumos de vulnerabilidade do AlloyDB Omni e os registros detalhados de CVE seguem estas políticas de relatórios:

  • Filtragem rigorosa de gravidade crítica e alta: as tabelas de resumo de vulnerabilidades e os registros detalhados de CVEs relatam exclusivamente CVEs de gravidade crítica e alta com base no National Vulnerability Database (NVD) e nas classificações de gravidade do fornecedor upstream. Os avisos de gravidade baixa e média são excluídos das contagens de resumo e dos registros detalhados.
  • Relatórios de kernel de banco de dados e plano de controle desacoplados: os boletins do plano de controle no AlloyDB Omni no Kubernetes relatam vulnerabilidades específicas das 10 imagens de contêiner secundário e do operador do AlloyDB Omni.
  • Isolamento específico da versão: os registros detalhados de CVEs são organizados em subpáginas dedicadas por versão de lançamento usando um esquema padronizado de quatro colunas (CVE ID, Severity, Impacted images e Mitigated in). Em cada registro de lançamento, as vulnerabilidades corrigidas em uma versão posterior mostram a versão de lançamento de mitigação na coluna Mitigated in.

Política de avaliação e atualização de vulnerabilidades

O Google verifica regularmente todas as imagens de contêiner publicadas do AlloyDB Omni em relação aos bancos de dados de vulnerabilidades do NVD, do Red Hat Security Data, do Debian Security Tracker e do Go. O Google atualiza os boletins de segurança do AlloyDB Omni quando novas versões são publicadas:

  • CVEs corrigidas: as vulnerabilidades que estavam presentes em uma imagem de contêiner do plano de controle do operador do AlloyDB Omni anterior são mitigadas em uma versão posterior do operador. O Google aplica patches de segurança à versão mais recente do operador do AlloyDB Omni e à versão secundária mais recente das versões principais 18, 17, 16 e 15 do PostgreSQL.
  • Imagens de contêiner substituídas: quando uma nova versão do operador do AlloyDB Omni mitiga CVEs de uma versão anterior, o Google marca os resumos de imagens de contêiner substituídas como obsoletos. Sempre implante imagens de agente do operador e do plano de controle que correspondam à versão mais recente com suporte.

Conformidade com o FIPS 140-3 e aplicação de patches de CVE

Para manter a conformidade com o Federal Information Processing Standards (FIPS) 140-3 enquanto corrige continuamente vulnerabilidades de segurança em versões secundárias e de patch, o AlloyDB Omni separa os módulos criptográficos internos validados pelo FIPS das bibliotecas criptográficas e de protocolo externas:

  • Validação do FIPS para módulos criptográficos: o Programa de Validação de Módulos Criptográficos (CMVP, na sigla em inglês) do Instituto Nacional de Padrões e Tecnologia (NIST, na sigla em inglês) certifica um módulo ou provedor criptográfico interno congelado e emite um número de certificado. A modificação de qualquer instrução dentro desse limite validado altera o checksum de integridade do código de autenticação de mensagem baseado em hash (HMAC, na sigla em inglês) incorporado e invalida o certificado.
  • Conformidade com o FIPS para implantações: uma implantação do AlloyDB Omni opera em um modo compatível com o FIPS 140-3 quando é executada em um SO host com FIPS ativado, como o Red Hat Enterprise Linux (RHEL) 9 com o arquivo /proc/sys/crypto/fips_enabled definido como 1. Nesse modo, a implantação encaminha todas as operações criptográficas relevantes para a segurança por um módulo validado pelo FIPS com testes de resposta conhecida (KATs, na sigla em inglês) de inicialização e verificações de integridade HMAC ativadas. Ele também aplica versões aprovadas do Transport Layer Security (TLS) do TLS 1.2 ou posterior, conjuntos de criptografia aprovados e o método de autenticação de senha scram-sha-256. As imagens de contêiner do operador do AlloyDB Omni e as imagens de contêiner do banco de dados Red Hat UBI 9 (-ubi9) estão prontas para o FIPS, e sua organização é responsável por ativar e verificar o modo FIPS no SO host. Para mais informações, consulte Segurança e conformidade com o FIPS.
  • Aplicação de patches de CVE fora do limite do FIPS: as bibliotecas de análise de protocolo e de rede, como máquinas de estado TLS, análise de certificados X.509 e ASN.1, HTTP/2 e E/S de rede, residem na camada externa fora do limite do módulo FIPS congelado. Como esses componentes estão fora do limite validado, o Google corrige as CVEs da camada externa em versões secundárias e de patch sem modificar o módulo criptográfico interno ou invalidar a certificação CMVP do NIST. Somente uma vulnerabilidade dentro da implementação primitiva criptográfica de baixo nível requer uma atualização para o módulo FIPS interno.
A tabela a seguir descreve as pilhas criptográficas no plano de controle do operador do AlloyDB Omni e nas imagens de contêiner secundário, incluindo o limite interno congelado do FIPS e a camada criptográfica e de protocolo externa que é corrigida em todas as versões:

Pilha criptográfica Imagens de contêiner do plano de controle Binários Módulo ou provedor interno validado pelo FIPS Camada externa de criptografia e protocolo
FIPS integrado do Go com a configuração de build GOFIPS140=v1.0.0 operator/fleet-operator
operator/local-operator
operator/logrotate
operator/node-manager
operator/dbinit
operator/backupinit 		/operator
/local
/logrotate
/nodemgr
dbinit
dbdaemon
credfetcher
backupinit
backupdaemon 		Módulo criptográfico Go v1.0.0, certificado CMVP do NIST nº 5247 Pacotes de biblioteca padrão do Go crypto/tls, crypto/x509 e net/http, pacotes externos do Go, como golang.org/x/crypto, e o ambiente de execução e o compilador do Go
OpenSSL 3 operator/g-pgbouncer /usr/bin/pgbouncer Provedor FIPS do OpenSSL do RHEL 9 /lib64/libssl.so.3 e /lib64/libcrypto.so.3 no pacote RPM openssl-libs e o binário C pgbouncer
BoringSSL e BoringCrypto operator/alloydbomni-monitor /monitoring_agent Binário do Go criado com boringcrypto Módulo BoringCrypto do Google (BCM) Pacotes Go crypto/tls, crypto/x509 e net/http para monitoring_agent

A seguir