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 cuando usas la opción de implementación del organizador RPM.

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

Matriz de responsabilidad compartida

En la siguiente tabla, se resumen las responsabilidades de Google y del cliente en cada capa de una implementación del organizador RPM de AlloyDB Omni:

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, incluidos la energía, el enfriamiento y el hardware.
Sistema operativo (SO) 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 host (como RHEL 9 o Rocky Linux 9).
Componentes de infraestructura y SO Almacenamiento Proporciona los requisitos mínimos y recomendados cuando corresponda. Aprovisiona discos locales o volúmenes de SAN. AlloyDB Omni requiere un dispositivo de almacenamiento en bloques configurado con un sistema de archivos compatible, como XFS o ext4.
Redes Proporciona los requisitos mínimos y recomendados cuando corresponda. Aprovisiona y administra la capa de red, como el enrutamiento de IP, los balanceadores de cargas y las reglas de firewall con firewalld o iptables, para abrir los puertos necesarios, como 5432 para PostgreSQL y 2379 y 2380 para etcd.
Control de acceso del host Proporciona las cuentas de servicio y los roles necesarios para los componentes del organizador de AlloyDB Omni. Administra el acceso SSH, los privilegios sudo, las políticas de SELinux y las cuentas de usuario de Linux para que se alineen con tus políticas de seguridad internas.
Administración de secretos Lee las variables estándar y los archivos de inventario para aprovisionar recursos, como el usuario postgres inicial. Almacena de forma segura las contraseñas, las claves SSH y los tokens que se usan para la organización de Ansible y el acceso a la base de datos.
Administración de certificados Proporciona opciones de configuración para la integración de certificados. Genera, distribuye y administra el ciclo de vida de los certificados de seguridad de la capa de transporte (TLS) y SSL en las máquinas host.
Software del organizador Desarrollo y lanzamiento Desarrolla el organizador de AlloyDB Omni, incluidas las colecciones de CLI y Ansible, y publica paquetes RPM. Ninguno Puedes usar artefactos del repositorio Yum proporcionado para tus implementaciones.
Instalación y ciclo de vida Proporciona documentación, artefactos RPM y plantillas de inventario de implementación.

Verifica la compatibilidad antes de la instalación.

Sigue las instrucciones para instalar o actualizar AlloyDB Omni con la CLI del organizador alloydbctl o los playbooks de Ansible.
Motor de base de datos Objeto binario de la base de datos Proporciona los paquetes RPM 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 principales y secundarias 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 administradores iniciales.

Aprovisiona el superusuario postgres para el usuario.

Proporciona instrucciones para la integración del Protocolo ligero de acceso a directorios (LDAP) y Active Directory (AD).

Proporciona la contraseña para el superusuario inicial.

Crea y administra todos los demás roles y usuarios.
Administración de datos Copias de seguridad Proporciona la automatización para administrar copias de seguridad con pgBackRest con integración compatible con S3. Configura los programas y la retención de copias de seguridad, y aprovisiona el bucket 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 con etcd y el gestor de clúster. Aprovisiona nodos suficientes, como un nodo de control, nodos etcd y nodos de base de datos principal y en espera, para admitir arquitecturas de conmutación por error y alta disponibilidad.
Encriptación en reposo Admite implementaciones en volúmenes encriptados a nivel de bloque. Administra la encriptación de la capa de almacenamiento, como la configuración de claves unificadas de Linux (LUKS) y dm-crypt, para cumplir con tus requisitos de seguridad.
Encriptación en tránsito Configura TLS del servidor para las conexiones de usuario a la base de datos y las comunicaciones internas del clúster. Conéctate a la base de datos con clientes TLS seguros y administra la infraestructura de certificados subyacente.
Observabilidad Métricas Expone las métricas internas de la base de datos con un extremo compatible con Prometheus. Implementa y administra el scraper con Prometheus, OpenTelemetry 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 y administra la rotación. Implementa recopiladores de registros, como Fluent Bit o Vector, para enviar registros a un backend de almacenamiento, como Splunk o la pila de ELK. Conserva los registros durante un mínimo recomendado de un mes.
Visualización Proporciona métricas y paneles de muestra para supervisar las cargas de trabajo estándar. Implementa y supervisa el estado de una herramienta de visualización, como Grafana. Crea paneles y los incorpora en tus tareas operativas diarias.
Alertas Ninguno Administra la canalización de alertas, por ejemplo, con una integración de PagerDuty.
Asistencia Soluciona problemas Proporciona asistencia para errores de software y del motor. Para obtener esta asistencia, necesitas una suscripción. Proporciona asistencia inicial a través de la documentación y la base de conocimiento. Depura 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 Información (FIPS) 140-2 o 140-3. El cumplimiento de FIPS es una responsabilidad compartida entre Google y el cliente, como se describe en la siguiente tabla:

Capa límite de FIPS Responsabilidad Descripción
Hardware compatible con FIPS Cliente El hardware físico y los componentes criptográficos deben estar certificados por el NIST y configurados en un estado aprobado por FIPS.
SO host Cliente El sistema operativo de la VM o del host sin sistema operativo (como RHEL 9) debe ejecutarse en modo FIPS. Verifica que el comando cat /proc/sys/crypto/fips_enabled muestre 1.
Plano de control del organizador Cliente El nodo de control que ejecuta el organizador de Ansible o la CLI debe usar una configuración de SO validada por FIPS.
Componentes del organizador Google Desarrollado por Google, distribuido como RPM compatibles con un SO base habilitado para FIPS, que administra de forma segura las operaciones del clúster.
Objetos binarios de la base de datos Google Vincula los módulos criptográficos OpenSSL del host validados por FIPS 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 la AC personalizada Compartido Los certificados digitales deben cumplir con los estándares FIPS para la solidez de la clave y los algoritmos de firma. La cadena de certificados debe rastrearse hasta una AC 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 (STIGs) para establecer estándares de ciberseguridad y requisitos de protección para software, sistemas operativos y bases de datos.

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 los IDs de vulnerabilidad de STIG que requieren 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 obligatoria 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. El cliente debe configurar las métricas de SIEM o del reenvío de registros 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 alerta en Prometheus y Grafana para notificar al equipo de asistencia cuando el espacio en el disco de registro 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 directorio de registro local. El cliente debe configurar un reenvío de registros 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 (AC) aprobadas. El organizador usa configuraciones TLS locales. El cliente debe proporcionar sus certificados de PKI raíz y de AC intermedia 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 de resumen de mensajes 5 (MD5). Permite SCRAM-SHA-256 a través de SSL. El cliente debe configurar los clientes para usar 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 con 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. Los paquetes RPM se basan en bibliotecas de RHEL 9 seguras y protegidas. El cliente debe verificar que el kernel de Linux del host subyacente tenga habilitado el modo FIPS 140.
V-233515 Realiza la integración con los mecanismos de autenticación de AD y LDAP a nivel de la organización. La base de datos 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. Los RPM se basan en los módulos FIPS de OpenSSL del host para las funciones hash. El cliente debe activar el modo FIPS en el SO 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 las máquinas host estén validadas por FIPS.
V-233619 Usa módulos criptográficos validados por FIPS para todas las operaciones. Aplica objetos binarios RPM listos para FIPS. El cliente debe habilitar el modo FIPS en el kernel del host.
V-233623 Ejecuta el DBMS en un host con un módulo FIPS de OpenSSL certificado. La base de datos se basa en las configuraciones FIPS de OpenSSL del host. El cliente debe verificar que el módulo OpenSSL del host coincida con la lista de FIPS certificada por el NIST.
V-233615 Asigna identidades autenticadas por PKI a las cuentas de usuario asociadas. La base de datos 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. RPM restringe los permisos de archivo y la ejecución al usuario postgres. El cliente debe bloquear el acceso al nodo host, por ejemplo, con restricciones de SSH, para evitar el acceso no autorizado a la terminal de las VMs.