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 valor del servicio.
| Capa | Responsabilidad de Google | Responsabilidad del cliente | |
|---|---|---|---|
| Hardware y host | Infraestructura física | Proporciona los requisitos mínimos y recomendados, según corresponda. | Aprovisionar servidores físicos, VMs o dispositivos perimetrales, como energía, refrigeración y hardware |
| Sistema operativo (SO) del host | Proporciona los requisitos mínimos y recomendados, según corresponda. | Administrar el kernel de Linux, aplicar parches de seguridad del SO y endurecer los nodos host | |
| Kubernetes | Administración de clústeres | Proporciona los requisitos mínimos y recomendados, según corresponda. | Administrar el clúster a diario, incluidas las actualizaciones, según las prácticas recomendadas estándar de la industria |
| Almacenamiento (CSI/PV) | Proporciona los requisitos mínimos y recomendados, según corresponda. | Aprovisionar la clase de almacenamiento y administrar 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. | |
| Herramientas de redes (CNI) | Proporciona los requisitos mínimos y recomendados, según corresponda. | Aprovisionar y administrar la capa de red, por ejemplo, las herramientas de redes de Pods, los controladores de Ingress, 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 que se requieren 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 de RBAC y vinculaciones de roles adicionales. | |
| Administración de Secrets | Lee los Secrets de Kubernetes estándar para aprovisionar recursos, como el
usuario inicial de postgres. |
Crear, proteger y rotar Secrets de Kubernetes en el clúster | |
| Administración de certificados | Confía en los Secrets de Kubernetes estándar 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 | Desarrollar la lógica del operador de AlloyDB Omni y los CRD, y publicar 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. |
|
|
| Motor de base de datos | Objeto binario de la base de datos | Proporcionar 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 | Lanzar parches de seguridad y actualizaciones de versiones secundarias y principales para el motor Proporciona instrucciones para actualizar. | Programa las actualizaciones lo antes posible, según la importancia de cada versión. | |
| Administración de usuarios |
|
|
|
| Administración de datos | Copias de seguridad | Proporciona los CRD `BackupPlan` y `Backup`, y la lógica para administrar las copias de seguridad,
que se administran con pgBackrest con integración
compatible con S3. |
Configura los programas de copia de seguridad y la retención, y aprovisiona el bucket de almacenamiento de destino local, de S3 o de Cloud Storage. |
| Alta disponibilidad (HA) | Proporcionar la lógica de conmutación por error automática y los mecanismos de reparación | Aprovisiona suficientes nodos y zonas para proporcionar un destino en espera que admita 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 configura TLS del servidor para las conexiones de usuario a base de datos. | Conectarte a la base de datos con clientes TLS seguros y administrar la infraestructura de certificados subyacente | |
| Observabilidad | Métricas | Exponer las métricas de la base de datos interna con un extremo compatible con Prometheus | Implementa y administra el recopilador con Prometheus, Open Telemetry o con otras soluciones compatibles y su pila de almacenamiento. Supervisar el estado general del sistema |
| Logging | Escribe registros de PostgreSQL y de auditoría en archivos en el disco del contenedor y rótalos. | Implementar recopiladores de registros, como 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 | Proporcionar 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. Crear paneles y, luego, incorporarlos en tus tareas operativas diarias | |
| Alertas | Ninguno | Administrar la canalización de alertas, por ejemplo, la integración de PagerDuty | |
| Asistencia | Soluciona problemas | Proporcionar asistencia para errores de software y del motor Para obtener esta asistencia, necesitas una suscripción de licencia. | Proporcionar asistencia inicial a través de la documentación y la base de conocimiento Depurar problemas relacionados con la infraestructura |
Seguridad y cumplimiento de los FIPS
Para proteger tus datos, AlloyDB Omni usa módulos criptográficos validados según los Estándares Federales de Procesamiento de Información (FIPS) 140-2 o 140-3. El cumplimiento de los 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 los FIPS entre Google y el cliente en las capas de la arquitectura de AlloyDB Omni.
En la siguiente tabla, se describen los límites y las responsabilidades de los FIPS para AlloyDB Omni:
| Capa de límites de FIPS | Responsabilidad | Descripción |
|---|---|---|
| Hardware que cumple con los FIPS | Cliente | Los componentes criptográficos y de hardware físico deben contar con la certificación del NIST y estar configurados en un estado aprobado por los 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 devuelve 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 | Desarrollada por Google, compilada en una imagen base que cumple con los FIPS (Red Hat UBI), con el cumplimiento de los FIPS habilitado en el contenedor en el que se ejecuta la base de datos. | |
| Imagen de contenedor de AlloyDB Omni | Usa bibliotecas criptográficas que cumplen con los FIPS, como BoringSSL, y aplica algoritmos aprobados por los FIPS para el hash de contraseñas (scram-sha-256) y los conjuntos de algoritmos de cifrado de TLS. |
|
| Certificados de una CA personalizada | Compartido | Los certificados digitales deben cumplir con los estándares de los FIPS para la seguridad de las claves y los algoritmos de firma. La cadena de certificados debe remontarse a una AC raíz que cumpla con los estándares FIPS. |
Responsabilidad compartida de STIG
La Agencia de Sistemas de Información de Defensa (DISA) publica guías técnicas de implementación de seguridad (STIG) para establecer estándares de ciberseguridad y requisitos de endurecimiento para software, sistemas operativos y bases de datos. En estas guías, se definen parámetros de seguridad específicos para proteger los sistemas de las vulnerabilidades y las ciberamenazas.
Para obtener una lista completa de las reglas de STIG, consulta Cumplimiento de STIG de AlloyDB Omni.
La protección de 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 la STIG es una responsabilidad compartida que requiere que el cliente configure y verifique los parámetros de configuración a nivel de la infraestructura.
En la siguiente tabla, se enumeran todos 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 de 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 | Alertar de inmediato al personal de asistencia sobre las fallas en los registros de auditoría | Los diagnósticos de errores estándar se escriben en los contenedores stdout y stderr. |
El cliente debe configurar las métricas de SIEM o del agente de reenvío de registros, por ejemplo, las alertas de Splunk o Elastic, para que se activen cuando disminuya la transferencia. |
| V-233599 | Alertar 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 el disco de /obs/ supere el 75%. |
| V-233610 | Descarga los datos de auditoría en 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 reenviador 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 certificadoras (CA) aprobadas. | El operador usa cert-manager para establecer la configuración de TLS local. |
El cliente debe proporcionar sus certificados de la AC raíz e intermedia de PKI al operador para establecer la cadena de confianza. |
| V-233520 | Aplicar 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 sesiones simultáneas por usuario. | Los roles de base de datos predeterminados tienen límites infinitos limitados 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 de UBI9 seguras y reforzadas. | El cliente debe verificar que el kernel del host de Kubernetes subyacente tenga habilitado el modo FIPS 140. |
| V-233515 | 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 parámetros de configuración de autenticación personalizados. | El Cliente debe asignar las identidades de AD y LDAP a la configuración del clúster de la base de datos. |
| V-233583 | Usa módulos criptográficos validados por FIPS para los hashes. | El contenedor se basa en los módulos de FIPS de OpenSSL del host para las funciones hash. | El cliente debe activar el modo FIPS en los nodos de VM host. |
| V-233585 | Usar 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 host estén validados por FIPS. |
| V-233619 | Usa módulos criptográficos validados por FIPS para todas las operaciones. | Aplica objetos binarios de imagen de contenedor compatibles con FIPS de UBI9. | 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 OpenSSL FIPS certificado. | Los Pods de bases 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 certificados por el NIST. |
| V-233615 | Asigna identidades autenticadas con PKI a las cuentas de usuario asociadas. | El operador usa la autenticación segura con contraseña de SCRAM-SHA-256 para las identidades. |
El cliente debe asignar los roles del directorio de la organización externa a los roles de la 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 host (SSH/Kubectl) para evitar el acceso no autorizado de la terminal a los Pods. |