Responsabilidad compartida de AlloyDB Omni

Selecciona una versión de la documentación:

En esta página, se describen tus responsabilidades como cliente de AlloyDB Omni y las responsabilidades de Google.

Como cliente de AlloyDB Omni, eres responsable de configurar y operar AlloyDB Omni para asegurarte de que tus cargas de trabajo obtengan el máximo provecho del valor del servicio.

Capa Responsabilidad de Google Responsabilidad del cliente
Hardware y host Infraestructura física Proporciona los requisitos mínimos y recomendados cuando corresponda Aprovisiona servidores físicos, VMs o dispositivos perimetrales, como energía, enfriamiento y hardware.
Sistema operativo (SO) del host Proporciona los requisitos mínimos y recomendados cuando corresponda Administra el kernel de Linux, aplica parches de seguridad del SO y protege los nodos del host.
Kubernetes Administración de clústeres Proporciona los requisitos mínimos y recomendados cuando corresponda Administra el clúster a diario, incluidas las actualizaciones, siguiendo las prácticas recomendadas estándar de la industria.
Almacenamiento (CSI/PV) Proporciona los requisitos mínimos y recomendados cuando corresponda Aprovisiona la clase de almacenamiento y administra los dispositivos subyacentes. AlloyDB Omni requiere un dispositivo de almacenamiento en bloques, así que asegúrate de elegir una clase de dispositivo de almacenamiento en bloques.
Redes (CNI) Proporciona los requisitos mínimos y recomendados cuando corresponda Aprovisiona y administra la capa de red, por ejemplo, las redes de pods, los controladores de entrada, los balanceadores de cargas y las reglas de firewall entre nodos.
Control de acceso basado en roles (RBAC) Proporciona las cuentas de servicio, los roles y las vinculaciones de roles necesarios para el operador de Kubernetes de AlloyDB Omni. Aplica estas reglas de control de acceso basado en roles (RBAC) al clúster y asegúrate de que se alineen con las políticas de seguridad internas. Para acceder a los recursos de AlloyDB Omni, crea roles y vinculaciones de roles de RBAC adicionales.
Administración de secretos Lee los secretos estándar de Kubernetes para aprovisionar recursos, como el usuario postgres inicial. Crea, protege y rota los secretos de Kubernetes en el clúster.
Administración de certificados Confía en los secretos estándar de Kubernetes y en cert-manager para la integración de certificados. Instala, configura y administra el ciclo de vida de cert-manager.
Software del operador Desarrollo y lanzamiento Desarrolla la lógica y los CRD del operador de AlloyDB Omni, y publica imágenes de contenedor, gráficos de Helm y paquetes de OLM. Ninguno Puedes usar artefactos almacenados en Artifact Registry para tus implementaciones.
Instalación y ciclo de vida Proporciona documentación y artefactos de actualización.
  • Verifica la tabla de compatibilidad antes de instalar o actualizar el operador de AlloyDB Omni.
  • Sigue las instrucciones para instalar o actualizar los componentes de AlloyDB Omni.
Motor de base de datos Objeto binario de la base de datos Proporciona las imágenes de contenedor de AlloyDB Omni con optimizaciones patentadas, como el motor de columnas y la aceleración de IA. Ninguno
Aplicación de parches Lanza parches de seguridad y actualizaciones de versiones secundarias y principales para el motor. Proporciona instrucciones de actualización. Programa las actualizaciones lo antes posible, según la importancia de cada lanzamiento.
Administración de usuarios
  • Aprovisiona los usuarios iniciales relacionados con el operador de AlloyDB Omni.
  • Aprovisiona el superusuario postgres orientado al usuario con una contraseña proporcionada por el usuario desde un secreto de Kubernetes.
  • Proporciona instrucciones para la integración con Microsoft Active Directory.
  • Proporciona la contraseña del superusuario inicial con un secreto de Kubernetes.
  • Crea y administra todos los demás roles y usuarios.
Administración de datos Copias de seguridad Proporciona los CRD y la lógica de `BackupPlan` y `Backup` para administrar las copias de seguridad, que se administran con pgBackrest con integración compatible con S3. Configura los programas y la retención de copias de seguridad, y aprovisiona el bucket de almacenamiento de destino local, de S3 o de Cloud Storage.
Alta disponibilidad (HA) Proporciona la lógica de conmutación por error automática y los mecanismos de recuperación. Aprovisiona suficientes nodos y zonas para proporcionar un destino de espera para admitir la conmutación por error.
Encriptación (en reposo) Proporciona compatibilidad con la encriptación de datos transparente (TDE). Administra la encriptación de la capa de almacenamiento para asegurarte de que cumpla con tus requisitos.
Encriptación (en tránsito) Proporciona mTLS para los componentes internos del operador y para configurar TLS del servidor para las conexiones de usuario a la base de datos. Conéctate a la base de datos con clientes TLS seguros y administra la infraestructura de certificados subyacente.
Observabilidad Métricas Expón las métricas internas de la base de datos con un extremo compatible con Prometheus. Implementa y administra el recopilador con Prometheus, Open Telemetry o cualquier otra solución compatible y su pila de almacenamiento. Supervisa el estado general del sistema.
Logging Escribe registros de auditoría y de PostgreSQL en archivos en el disco del contenedor y rótalos. Implementa recopiladores de registros, por ejemplo, Fluentd y Fluent Bit, para enviar registros a un backend de almacenamiento (como Splunk o ELK). Asegúrate de que los recopiladores de registros estén configurados para conservar los registros durante un mínimo recomendado de un mes.
Visualización Proporciona métricas de muestra y paneles de registros para supervisar las cargas de trabajo estándar. Implementa y supervisa el estado de la herramienta de visualización, como Grafana. Crea paneles y úsalos en tus tareas operativas diarias.
Alertas Ninguno Administra la canalización de alertas, por ejemplo, la integración de PagerDuty.
Asistencia Soluciona problemas Proporciona asistencia para errores de software y del motor. Para obtener esta asistencia, necesitas una suscripción de licencia. Proporciona asistencia inicial a través de la documentación y la base de conocimiento. Depura los problemas relacionados con la infraestructura.

Seguridad y cumplimiento de FIPS

Para proteger tus datos, AlloyDB Omni usa módulos criptográficos validados por los Estándares federales de procesamiento de la información (FIPS) 140-2 o 140-3. El cumplimiento de FIPS es una responsabilidad compartida entre Google y el cliente.

En el siguiente diagrama, se muestra cómo se divide la responsabilidad del cumplimiento de FIPS entre Google y el cliente en las capas de arquitectura de AlloyDB Omni.

Diagrama que muestra los límites de responsabilidad del cumplimiento de FIPS, dividiendo las responsabilidades entre Google, el cliente y las áreas compartidas.

En la siguiente tabla, se describen los límites y las responsabilidades de FIPS para AlloyDB Omni:

Capa límite de FIPS Responsabilidad Descripción
Hardware compatible con FIPS Cliente Los componentes criptográficos y de hardware físico deben estar certificados por NIST y configurados en un estado aprobado por FIPS.
SO de los nodos de Kubernetes Cliente El sistema operativo host del nodo trabajador, por ejemplo, RHEL, debe ejecutarse en modo FIPS. Se debe verificar el estado de FIPS (cat /proc/sys/crypto/fips_enabled muestra 1).
Plano de control de Kubernetes Cliente Los componentes del plano de control, como kubelet y los complementos de redes y almacenamiento, deben usar módulos criptográficos validados por FIPS, por ejemplo, compilados con Go-BoringCrypto.
Controladores del operador de AlloyDB Omni Google Desarrollado por Google, compilado en una imagen base compatible con FIPS (Red Hat UBI), con el cumplimiento de FIPS habilitado en el contenedor en el que se ejecuta la base de datos.
Imagen de contenedor de AlloyDB Omni Google Usa bibliotecas criptográficas compatibles con FIPS, como BoringSSL, y aplica algoritmos aprobados por FIPS para el hash de contraseñas (scram-sha-256) y los conjuntos de algoritmos de cifrado TLS.
Certificados de CA personalizados Compartido Los certificados digitales deben cumplir con los estándares de FIPS para la intensidad de la clave y los algoritmos de firma. La cadena de certificados debe rastrearse hasta una CA raíz compatible con FIPS.

Responsabilidad compartida de STIG

La Agencia de Sistemas de Información de Defensa (DISA) publica las Guías de implementación técnica de seguridad (STIG) para establecer estándares de ciberseguridad y requisitos de endurecimiento para software, sistemas operativos y bases de datos. Estas guías definen parámetros de seguridad específicos para proteger los sistemas de vulnerabilidades y amenazas cibernéticas.

Para obtener una lista completa de las reglas de STIG, consulta Cumplimiento de STIG de AlloyDB Omni.

Proteger tu entorno según los requisitos de STIG es esencial para obtener una autorización para operar (ATO) en sectores gubernamentales o de alta seguridad. Si bien AlloyDB Omni implementa muchos controles de seguridad a nivel de la base de datos de forma predeterminada, lograr el cumplimiento total de STIG es una responsabilidad compartida que requiere que el cliente configure y verifique la configuración a nivel de la infraestructura.

En la siguiente tabla, se enumeran todos los IDs de vulnerabilidad de STIG que requieren una acción, validación o configuración por parte del cliente. Para obtener información completa, consulta la lista de tareas para el cumplimiento de la Guía de implementación técnica de seguridad (STIG) de PostgreSQL 9.x en Red Hat Enterprise Linux.

ID de STIG o SRG Descripción del control de seguridad Comportamiento predeterminado de la plataforma y el operador Acción o configuración requerida del cliente
V-233535 Alerta de inmediato al personal de asistencia sobre las fallas del registro de auditoría. Los diagnósticos de errores estándar se escriben en stdout y stderr del contenedor. El cliente debe configurar las métricas de SIEM o del reenvío de registros, por ejemplo, las alertas de Splunk/Elastic, para que se activen cuando disminuya la transferencia.
V-233599 Alerta al personal de asistencia cuando el almacenamiento de auditoría alcance el 75% de su capacidad. Las métricas del sistema de archivos se exponen a través de extremos estándar de Prometheus. El cliente debe configurar reglas de alertas en Prometheus y Grafana para notificar al equipo de asistencia cuando el espacio en disco de /obs/ supere el 75%.
V-233610 Descarga los datos de auditoría a una instalación de registro continuo independiente. Los registros de auditoría se escriben de forma persistente en el volumen /obs/diagnostic/. El cliente debe configurar un reenvío de registros, por ejemplo, FluentBit y Vector, para transmitir archivos de registro de forma continua a un SIEM central.
V-233603 Solo confía en los certificados de entidad final emitidos por la infraestructura de clave pública (PKI) o las autoridades certificadas (CA) aprobadas. El operador usa cert-manager para configurar las configuraciones de TLS locales. El cliente debe proporcionar sus certificados de CA raíz e intermedia de PKI al operador para establecer la cadena de confianza.
V-233520 Aplica autorizaciones de acceso lógico aprobadas. Rechaza las contraseñas de texto sin formato y el algoritmo Message-Digest 5 (MD5). Permite scram-sha-256 a través de SSL. El cliente debe configurar los clientes para que usen SCRAM-SHA-256 con sslmode=verify-full en sus cadenas de conexión.
V-233522 Limita los umbrales de sesión simultánea por usuario. Los roles de base de datos predeterminados tienen límites infinitos delimitados por max_connections. El cliente debe modificar de forma explícita los límites de conexión (ALTER ROLE ... CONNECTION LIMIT) para los roles de aplicación personalizados.
V-233584 Usa criptografía aprobada por la NSA para la información clasificada en reposo. El contenedor de la base de datos usa capas base UBI9 seguras y protegidas. El cliente debe verificar que el kernel del host de Kubernetes subyacente tenga habilitado el modo FIPS 140.
V-233515 Realiza la integración con los mecanismos de autenticación a nivel de la organización de Active Directory (AD) y el Protocolo ligero de acceso a directorios (LDAP). El operador admite configuraciones de autenticación personalizadas. El cliente debe asignar identidades de AD y LDAP a la configuración del clúster de base de datos.
V-233583 Usa módulos criptográficos validados por FIPS para los hashes. El contenedor depende de los módulos FIPS de OpenSSL del host para las funciones de hash. El cliente debe activar el modo FIPS en los nodos de VM del host.
V-233585 Usa criptografía validada por FIPS para proteger la información no clasificada. Encripta la comunicación y el almacenamiento con algoritmos de cifrado compatibles con FIPS. El cliente debe verificar que los nodos del host estén validados por FIPS.
V-233619 Usa módulos criptográficos validados por FIPS para todas las operaciones. Aplica los objetos binarios de la imagen de contenedor UBI9 listos para FIPS. El cliente debe habilitar el modo FIPS en el kernel del host.
V-233623 Asegúrate de que el DBMS se ejecute en un host con FIPS de OpenSSL certificado. Los pods de la base de datos dependen de las configuraciones de FIPS de OpenSSL del host. El cliente debe verificar que el OpenSSL del host coincida con la lista de FIPS certificada por NIST.
V-233615 Asigna identidades autenticadas por PKI a las cuentas de usuario asociadas. El operador usa la autenticación segura de contraseñas SCRAM-SHA-256 para las identidades. El cliente debe asignar roles de directorio organizacional externos a roles de base de datos si no usa el acceso directo con contraseña.
V-233540 Restringe la cuenta de instalación de la base de datos solo a los usuarios autorizados. El contenedor restringe los permisos de archivo y la ejecución al usuario postgres. El cliente debe bloquear el acceso al nodo del host (SSH/Kubectl) para evitar el acceso no autorizado a la terminal de los pods.