Google Distributed Cloud (GDC) aislado ayuda a proteger los bastidores de hardware, los sistemas operativos host, los límites de múltiples usuarios, las cadenas de suministro de software y el tráfico de red implementado en instalaciones de centros de datos acreditadas.
Seguridad de las instalaciones
El hardware de GDC se implementa dentro de instalaciones de centros de datos acreditadas que controlas tú o el operador de instalaciones que designes. Tu organización y el operador de infraestructura son responsables de aplicar los controles de acceso físico, las protecciones ambientales y los procedimientos de manejo de medios para la instalación que aloja los bastidores de GDC.
Los controles de seguridad física recomendados incluyen los siguientes:
- Controles de acceso perimetral y de bastidores: Restringen la entrada física al centro de datos y a los bastidores de GDC con lectores de tarjetas de identificación, autenticación biométrica, registros de acompañantes de visitantes, patrullas de guardias de seguridad las 24 horas, todos los días, y puertas de bastidores cerradas.
- Vigilancia y detección de manipulación: Supervisa los pasillos de los bastidores con un circuito cerrado de televisión (CCTV) continuo y alarmas de intrusión física.
- Aislamiento de energía, enfriamiento y cableado: Proporciona fuentes de alimentación redundantes, supervisión ambiental y rutas de cableado protegidas que cumplan con tus requisitos normativos y de acreditación (como ISO/IEC 27001 o ICD 705).
Seguridad del hardware
GDC se ejecuta en bastidores de hardware modulares y preintegrados fabricados con componentes comerciales listos para usar (COTS) de fabricantes de equipos originales (OEM) verificados. Las instalaciones regionales certificadas con personal que pasó por una verificación de antecedentes integran los bastidores de hardware. Los componentes de hardware y firmware de alto riesgo también se someten a revisiones de seguridad dedicadas contra las amenazas de la cadena de suministro y de manipulación física.
Entre los controles clave de seguridad del hardware, se incluyen los siguientes:
- Servidores de procesamiento: Los servidores de equipos físicos usan raíces de confianza de hardware, módulos de plataforma de confianza (TPM 2.0) y firmware de controlador de administración de placa base (BMC) firmado para verificar la integridad del hardware y del inicio antes de cargar el sistema operativo.
- Switches de red y firewalls perimetrales: Los switches de administración y de la parte superior del bastidor aplican controles de acceso a nivel de puerto y encriptación MACsec. Los firewalls perimetrales redundantes proporcionan inspección con estado de velocidad de línea y prevención de intrusiones en el límite de la zona.
- Dispositivos de almacenamiento: Los dispositivos de almacenamiento de bloques, archivos y almacén de objetos empresariales aplican la encriptación en reposo AES-256 acelerada por hardware en unidades de encriptación automática (SED) y aislamiento lógico de usuarios con máquinas virtuales de almacenamiento (SVM) dedicadas.
- Módulos de seguridad de hardware (HSM): Los dispositivos HSM dedicados conectados a la red (validados con el nivel 3 de FIPS 140-2 y FIPS 140-3) generan, almacenan y protegen las claves criptográficas raíz en hardware con detección de intrusiones.
Para obtener más información, consulta la siguiente documentación:
| Tema | Documentación y guías de configuración |
|---|---|
| Administración de hardware y HSM | Controla las claves de HSM y Máquinas de nodos del clúster |
Seguridad de hosts y nodos
Cada host de equipos físicos y nodo de clúster de Kubernetes en GDC ejecuta una imagen de sistema operativo endurecida configurada para minimizar la superficie de ataque y evitar la elevación de privilegios no autorizada.
- Sistema operativo reforzado con STIG: Los nodos ejecutan Linux reforzado con las guías de implementación técnica de seguridad (STIG) de la Agencia de Sistemas de Información de Defensa (DISA) y las comparativas del Centro para la Seguridad en Internet (CIS). Los paquetes, compiladores y servicios de red innecesarios se quitan de la imagen base.
- Arranque seguro de UEFI: Tanto los hosts de equipos físicos como las máquinas virtuales (VMs) de usuario admiten el arranque seguro de UEFI para verificar que solo se ejecuten bootloaders y las imágenes de kernel con firma criptográfica durante el inicio.
- Controles de acceso obligatorio y del kernel: Los nodos aplican SELinux en modo de aplicación forzosa, filtrado de llamadas al sistema seccomp, espacios de nombres de Linux y límites de recursos de cgroups para aislar los contenedores del kernel del host subyacente.
- Integridad del host y protección de extremos: La supervisión de la integridad de los archivos (FIM) verifica los archivos críticos del sistema en busca de cambios no autorizados, y los controles de detección y respuesta de extremos (EDR) y antimalware supervisan la ejecución de procesos y la telemetría del host.
Para obtener más información, consulta la siguiente documentación:
| Tema | Documentación y guías de configuración |
|---|---|
| Aislamiento y comparativas de nodos | Descripción general del aislamiento de nodos y Comparativas de CIS para Kubernetes |
| Arranque seguro de VMs y administración del SO | Inicia una VM de forma segura y Administra paquetes de SO |
Usuario
GDC proporciona instancias múltiples jerárquicas con aislamiento físico y de red estricto entre organizaciones y aislamiento de espacio de nombres lógico entre proyectos dentro de una organización.
Aislamiento lógico entre organizaciones, clústeres y proyectos
En el siguiente diagrama, se muestra cómo el clúster de administración raíz, los clústeres de infraestructura de la organización y los clústeres de cargas de trabajo están aislados en los límites de administración y de usuario:
- Clúster de administración raíz: Se dedica a iniciar organizaciones, administrar el inventario de hardware y ejecutar servicios de seguridad y observabilidad de la infraestructura.
- Organización: Es el límite del usuario de nivel superior. Cada organización tiene su propio clúster de infraestructura de organización dedicado, configuración del proveedor de identidad, jerarquía del sistema de administración de claves (KMS) y una instancia de enrutamiento y reenvío virtual (VRF).
- Clústeres de Kubernetes: Puedes aprovisionar clústeres compartidos con alcance de organización (que alojan varios proyectos) o clústeres estándar con alcance de proyecto (dedicados a un solo proyecto para una separación de cargas de trabajo más sólida).
- Proyecto: Es una unidad de usuario lógica dentro de una organización en la que implementas VMs, contenedores, bases de datos y recursos de almacenamiento. Los proyectos aplican la igualdad de espacios de nombres de Kubernetes, los límites del control de acceso basado en roles (RBAC) y las políticas de red del proyecto en todos los clústeres.
Aislamiento físico y de VRF en los bastidores
En los bastidores físicos de 42U, GDC aísla a las organizaciones en servidores de procesamiento, máquinas virtuales de almacenamiento (SVM) y VRF de red independientes, por lo que no se comparten servidores de procesamiento físicos entre las organizaciones:
Para obtener más información, consulta la siguiente documentación:
| Tema | Documentación y guías de configuración |
|---|---|
| Jerarquía de recursos y proyectos | Jerarquía de recursos y Administra proyectos |
| Clústeres de Kubernetes | Clústeres de Kubernetes en GDC y Configuraciones de clústeres |
| Diseño de límites y cargas de trabajo | Diseña límites de acceso y Diseña la separación de cargas de trabajo |
Seguridad para aplicaciones
GDC protege tanto el software de la plataforma que se entrega a través del aislamiento físico como las aplicaciones de los clientes que se implementan dentro de tu organización.
Cadena de suministro de software y validación de SLSA
Todos los componentes de la plataforma de GDC, los servicios propios y los servicios de terceros administrados se compilan en entornos de compilación aislados y herméticos, y se analizan en busca de vulnerabilidades. Los artefactos se firman en el lado conectado ("lado bajo") de conformidad con los requisitos de los niveles de la cadena de suministro para artefactos de software (SLSA) antes de la transferencia a través del aislamiento físico ("lado alto").
Cada versión incluye una lista de materiales de software (SBOM) que detalla los componentes, las dependencias y las bibliotecas de software, y los artefactos se verifican con firmas criptográficas y sumas de comprobación SHA-256 antes de la implementación.
Artifact Registry y aplicación de políticas
GDC aplica controles de políticas y de imágenes de contenedor antes de la implementación:
- Artifact Registry local (Harbor): Las imágenes de contenedor y los gráficos de Helm se almacenan en un registro de Harbor local dentro del entorno aislado, lo que admite la firma de imágenes y el análisis de vulnerabilidades sin acceso a Internet externo.
- Control de admisión y políticas de la organización: Open Policy Agent (OPA) Gatekeeper aplica las políticas de la organización en los clústeres de Kubernetes, lo que evita que los Pods se ejecuten con elevación de privilegios, acceso a la red del host o imágenes de contenedor no confiables.
Para obtener más información, consulta la siguiente documentación:
| Tema | Documentación y guías de configuración |
|---|---|
| Políticas y Artifact Registry | Configura políticas de la organización y Crea y administra recursos de Harbor |
| Cargas de trabajo y servicios | Cargas de trabajo de contenedores en GDC y Implementa servicios de Marketplace |
Seguridad de red
GDC aplica la segmentación de red de varias capas desde los puertos de conmutadores físicos hasta las políticas de malla de servicios de la capa 7.
Segmentación de VRF y VXLAN del plano de datos
La estructura del plano de datos usa la VPN de Ethernet (EVPN) de BGP de protocolo múltiple (MP-BGP) con la encapsulación de LAN virtual extensible (VXLAN) para aislar el tráfico entre el clúster de administración raíz y cada organización de usuario.
- Red de administración fuera de banda (OOB): Las interfaces de administración de hardware operan en una red de administración separada físicamente y aislada del tráfico de los usuarios y a la que solo se puede acceder desde el clúster de administración raíz.
- Aislamiento de VRF y VXLAN: A cada organización se le asignan identificadores de red virtual (VNI) de capa 3, VRF internos y externos, y máquinas virtuales de almacenamiento (SVM) aisladas para que el tráfico de los usuarios no pueda cruzar los límites de la organización sin un recorrido explícito del firewall.
- Firewall de última generación, IDPS y protección contra denegación del servicio (DoS): Los firewalls perimetrales y los sistemas de detección y prevención de intrusiones (IDPS) aplican una postura de denegación predeterminada, inspeccionan el tráfico entrante y saliente en busca de firmas de amenazas y trabajan con balanceadores de cargas para limitar las inundaciones de sesiones. Los registros de firewall y de IDPS se integran en la pila de observabilidad de la organización y en la supervisión de seguridad de la infraestructura.
- Políticas de red de proyectos y Kubernetes: Dentro de una organización, puedes
aplicar la microsegmentación de denegación predeterminada entre proyectos y Pods con
los recursos
NetworkPolicyde Kubernetes respaldados por Cilium,ProjectNetworkPolicyyOrganizationNetworkPolicy.
Para obtener más información, consulta la siguiente documentación:
| Tema | Documentación y guías de configuración |
|---|---|
| Prevención de amenazas y perimetral | Descripción general de las herramientas de redes, Prevención de amenazas de solicitudes y Control de salida |
| Políticas de red y registros de flujo | Políticas de red de la organización, políticas de red del proyecto, configuración de políticas de red de Kubernetes y administración de registros de flujo |
| Conectividad externa | Configura la VPN de GDC y Establece la conectividad con interconexiones |