Boletim de segurança

Selecione uma versão da documentação:

Para avaliar a postura de segurança das implantações do orquestrador de RPM do AlloyDB Omni no Red Hat Enterprise Linux (RHEL) e no Rocky Linux e planejar upgrades, consulte as políticas de segurança, o escopo de vulnerabilidade e as práticas de divulgação de vulnerabilidades e exposições comuns (CVE, na sigla em inglês) 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.

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.
  • 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, AlloyDB Omni version 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 todos os pacotes RPM do orquestrador e do banco de dados do AlloyDB Omni publicados em relação aos bancos de dados de vulnerabilidades do NVD, do Red Hat Security Data 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 um pacote RPM anterior do orquestrador ou do banco de dados do AlloyDB Omni são mitigadas em uma versão secundária ou de patch posterior. O Google aplica patches de segurança à versão secundária mais recente da versão principal 18 do PostgreSQL compatível e à versão mais recente do orquestrador de RPM do AlloyDB Omni compatível.
  • Pacotes do SO host para implantações de RPM: quando você implanta o AlloyDB Omni usando o orquestrador de RPM, o AlloyDB Omni fornece o kernel do banco de dados PostgreSQL e os pacotes de extensão incluídos. A distribuição do Linux do host gerencia bibliotecas do sistema, como openssl-libs, glibc, libevent, systemd e o kernel do Linux. Aplique atualizações de segurança do SO do host regularmente executando sudo dnf update --security nos hosts do RHEL ou do Rocky Linux.

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 o FIPS ativado, como o 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. O orquestrador de RPM do AlloyDB Omni e os pacotes de RPM do banco de dados estão prontos 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.
Para implantações do orquestrador de RPM no RHEL ou no Rocky Linux, o pacote de banco de dados alloydbomni18 é vinculado dinamicamente às bibliotecas OpenSSL 3 do SO host no pacote RPM openssl-libs e usa o provedor FIPS OpenSSL do RHEL 9 do host quando o modo FIPS está ativado no kernel do host. A aplicação de atualizações de segurança openssl-libs no SO host corrige vulnerabilidades de TLS e X.509 da camada externa, preservando o limite do provedor FIPS do OpenSSL certificado.

A seguir