Boletín de seguridad

Para evaluar la postura de seguridad de tus implementaciones independientes de AlloyDB Omni y planificar las actualizaciones de la base de datos, revisa las políticas de seguridad, el alcance de las vulnerabilidades, las prácticas de divulgación y los límites del módulo criptográfico de los Estándares Federales de Procesamiento de la Información (FIPS) 140-3 en esta página:

Para recibir las notas de la versión y las actualizaciones de seguridad más recientes de AlloyDB Omni en tu lector de feeds, suscríbete al feed de notas de la versión de AlloyDB Omni.

Filtrado por alcance y gravedad

Para enfocar los flujos de trabajo de solución en avisos de seguridad prácticos y reducir el ruido del análisis, los resúmenes de vulnerabilidades de AlloyDB Omni y los registros detallados de CVE siguen estas políticas de informes:

  • Filtrado estricto de gravedad alta y crítica: Las tablas de resumen de vulnerabilidades y los registros detallados de CVE informan exclusivamente las CVE de gravedad alta y crítica según las calificaciones de gravedad de la Base de datos nacional de vulnerabilidades (NVD) y del proveedor upstream. Los avisos de gravedad baja y media se excluyen de los recuentos de resumen y los registros detallados.
  • Informes independientes del kernel de la base de datos y del plano de control: Los boletines de seguridad independientes de AlloyDB Omni informan vulnerabilidades específicas de las imágenes de contenedor del kernel de la base de datos (18.x, 17.x, 16.x y 15.x). Los avisos del operador de Kubernetes y del contenedor de sidecar se registran por separado en elBoletín de seguridad de AlloyDB Omni en Kubernetes.
  • Aislamiento específico de la versión: Los registros detallados de CVE se organizan en subpáginas dedicadas por versión de actualización con un esquema estandarizado de 4 columnas (CVE ID, Severity, Impacted images y Mitigated in). Dentro de cada registro de actualización, las vulnerabilidades corregidas en una actualización posterior muestran la versión de actualización de mitigación en la columna Mitigated in.

Evaluación de vulnerabilidades y política de actualización

Google analiza con regularidad todas las imágenes de contenedor de AlloyDB Omni publicadas en las bases de datos de vulnerabilidades de NVD, Red Hat Security Data, Debian Security Tracker y Go. Google actualiza los boletines de seguridad de AlloyDB Omni cuando se publican versiones nuevas:

  • CVE corregidos: Las vulnerabilidades que estaban presentes en una imagen de contenedor del kernel de la base de datos de AlloyDB Omni anterior se mitigan en una versión secundaria o de parche posterior. Google aplica parches de seguridad a la versión secundaria más reciente de las versiones principales de PostgreSQL 18, 17, 16 y 15.
  • Imágenes de contenedor reemplazadas: Cuando una nueva versión de AlloyDB Omni mitiga las CVE de una versión anterior, Google marca los resúmenes de imágenes de contenedor reemplazados como obsoletos. Extrae siempre las imágenes del kernel de la base de datos que correspondan a la versión compatible más reciente.

Cumplimiento de FIPS 140-3 y aplicación de parches de CVE

Para mantener el cumplimiento de los Estándares federales de procesamiento de la información (FIPS) 140-3 mientras se corrigen de forma continua las vulnerabilidades de seguridad en las versiones secundarias y de parches, AlloyDB Omni separa sus módulos criptográficos internos validados por FIPS de sus bibliotecas criptográficas y de protocolos externas:

  • Validación de FIPS para módulos criptográficos: El Programa de validación de módulos criptográficos (CMVP) del Instituto Nacional de Estándares y Tecnología (NIST) certifica un módulo o proveedor criptográfico interno inmovilizado y emite un número de certificado. Si se modifica cualquier instrucción dentro de ese límite validado, se altera la suma de comprobación de integridad del código de autenticación de mensajes basado en hash (HMAC) incorporado y se invalida el certificado.
  • Cumplimiento de FIPS para implementaciones: Una implementación de AlloyDB Omni funciona en un modo que cumple con la norma FIPS 140-3 cuando se ejecuta en un SO host habilitado para FIPS, como Red Hat Enterprise Linux (RHEL) 9 con el archivo /proc/sys/crypto/fips_enabled configurado como 1. En este modo, la implementación enruta todas las operaciones criptográficas relevantes para la seguridad a través de un módulo validado por FIPS con pruebas de respuesta conocida (KAT) de encendido y verificaciones de integridad de HMAC habilitadas. También aplica las versiones aprobadas de seguridad de la capa de transporte (TLS) de TLS 1.2 o posterior, los conjuntos de algoritmos de cifrado aprobados y el método de autenticación de contraseña de scram-sha-256. Las imágenes de contenedor del kernel de la base de datos de Red Hat Universal Base Image 9 (UBI 9) (-ubi9) están listas para FIPS, y tu organización es responsable de habilitar y verificar el modo FIPS en el SO del host subyacente.
  • Aplicación de parches de CVE fuera del límite de FIPS: Las bibliotecas de análisis de protocolos y de redes, como las máquinas de estado de TLS, el análisis de certificados X.509 y ASN.1, HTTP/2 y las E/S de red, residen en la capa externa fuera del límite del módulo de FIPS inmovilizado. Debido a que estos componentes se encuentran fuera del límite validado, Google aplica parches para las CVE de la capa externa en las versiones secundarias y de parches sin modificar el módulo criptográfico interno ni invalidar su certificación CMVP del NIST. Solo una vulnerabilidad dentro de la implementación de la primitiva criptográfica de bajo nivel requiere una actualización del módulo de FIPS interno.
En la siguiente tabla, se describen las pilas criptográficas en las imágenes de contenedor del kernel de la base de datos de AlloyDB Omni Red Hat UBI 9 (-ubi9), incluidos el límite interno de FIPS inmovilizado y la capa criptográfica y de protocolo externa que se parcha en las versiones:

Pila criptográfica Imagen de contenedor del kernel de la base de datos Objetos binarios Módulo o proveedor interno validado por FIPS Capa criptográfica y de protocolo externa
BoringSSL y BoringCrypto alloydbomni (-ubi9) Objetos binarios de C para postgres y pgbackrest Módulo BoringCrypto de Google (BCM) Paquetes x509, asn1, pem y bio de BoringSSL libssl y libcrypto que no son de BCM para postgres y pgbackrest
OpenSSL 3 Capa del SO base de Red Hat UBI 9 de alloydbomni (-ubi9) Bibliotecas y utilidades compartidas del SO base Proveedor de FIPS de OpenSSL de RHEL 9 /lib64/libssl.so.3 y /lib64/libcrypto.so.3 en el paquete RPM de openssl-libs

¿Qué sigue?