Boletín de seguridad

Selecciona una versión de la documentación:

Para evaluar la postura de seguridad de tus implementaciones de paquetes RPM de AlloyDB Omni en Red Hat Enterprise Linux (RHEL) y Rocky Linux, y planificar actualizaciones, revisa las políticas de seguridad, el alcance de las vulnerabilidades y las prácticas de divulgación de vulnerabilidades y exposiciones comunes (CVE) 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.
  • 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, AlloyDB Omni version 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 periódicamente todos los paquetes de RPM de AlloyDB Omni publicados en comparación con los datos de seguridad de NVD y Red Hat. Google actualiza los boletines de seguridad de AlloyDB Omni cuando se publican versiones nuevas:

  • CVE corregidos: Las vulnerabilidades que estaban presentes en un paquete de RPM 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 18 y 17 de PostgreSQL compatibles.
  • Paquetes de SO host para implementaciones de RPM: Cuando implementas AlloyDB Omni con paquetes de RPM, AlloyDB Omni entrega el kernel de la base de datos de PostgreSQL y los paquetes de extensiones agrupados. La distribución de Linux del host administra las bibliotecas del sistema, como openssl-libs, glibc, libevent, systemd y el kernel de Linux. Aplica actualizaciones de seguridad del SO host con regularidad ejecutando sudo dnf update --security en tus hosts de RHEL o Rocky Linux.

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 opera en un modo que cumple con la norma FIPS 140-3 cuando se ejecuta en un SO de host habilitado para FIPS, como 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. Los paquetes de RPM de AlloyDB Omni están listos para FIPS, y tu organización es responsable de habilitar y verificar el modo FIPS en el SO 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.
Para las implementaciones de RPM en RHEL o Rocky Linux, los paquetes de bases de datos alloydbomni18 y alloydbomni17 se vinculan de forma dinámica con las bibliotecas de OpenSSL 3 del SO host en el paquete RPM openssl-libs y usan el proveedor de FIPS de OpenSSL de RHEL 9 del host cuando el modo FIPS está habilitado en el kernel del host. Aplicar actualizaciones de seguridad de openssl-libs en el SO host corrige las vulnerabilidades de TLS y X.509 de la capa externa, a la vez que conserva el límite del proveedor de FIPS de OpenSSL certificado.

¿Qué sigue?