Controles de infraestructura

• under:organizations/ORGANIZATION_ID
• under:folders/FOLDER_ID
• under:projects/PROJECT_ID
• projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

A menos que sea necesario, impide la creación de instancias de Compute Engine con direcciones IP públicas. La restricción de lista compute.vmExternalIpAccess define el conjunto de instancias de VM de Compute Engine que pueden tener direcciones IP externas.

Evita que las instancias de Compute Engine tengan direcciones IP externas para reducir drásticamente su exposición a Internet. Cualquier instancia con una dirección IP externa se puede descubrir de inmediato y se convierte en un objetivo directo para los análisis automatizados, los ataques de fuerza bruta y los intentos de aprovechar las vulnerabilidades. En cambio, exige que las instancias usen direcciones IP privadas y administra el acceso a través de rutas controladas, autenticadas y registradas, como el túnel de Identity-Aware Proxy (IAP) o un host de bastión.

Adoptar esta postura de denegación predeterminada es una práctica recomendada de seguridad fundamental que ayuda a minimizar la superficie de ataque y aplica un enfoque de confianza cero a tu red. Esta restricción no es retroactiva.

La restricción de lista compute.vmExternalIpAccess te permite restringir el acceso externo a las máquinas virtuales al no asignar direcciones IP externas. Configura esta restricción de lista para rechazar todas las direcciones IP externas a las máquinas virtuales.

Desactiva el acceso al puerto en serie configurando la restricción de la política de la organización compute.disableSerialPortAccess. Inhabilita el acceso al puerto en serie en tus VMs de Compute Engine para ayudar a eliminar un canal de acceso que omite tus reglas de firewall y otros controles de seguridad de red. La consola en serie interactiva está diseñada principalmente para la solución de problemas de emergencia, pero, si la dejas habilitada, puedes crear una puerta trasera persistente a la que los atacantes pueden apuntar.

Inhabilitar el acceso al puerto en serie ayuda a aplicar una postura de seguridad de defensa en profundidad, ya que obliga a todo el acceso de administrador a través de rutas auditadas estándar, como SSH, que puedes proteger habilitando Identity and Access Management (IAM) y Identity-Aware Proxy (IAP).

La restricción booleana cloudfunctions.requireVPCConnector requiere que los administradores especifiquen un conector de Acceso a VPC sin servidores cuando implementan una función de Cloud Run. Cuando se aplique, las funciones deberán especificar un conector.

Activa los atributos de supervisión de integridad y del módulo de plataforma segura virtual (vTPM) de la VM protegida para tus instancias. Los atributos de supervisión de integridad y del vTPM forman parte del proceso predeterminado de creación de instancias de VM. Usa los atributos de supervisión de integridad y vTPM de la VM protegida para garantizar que tus VMs solo se inicien con código de confianza sin modificar.

El vTPM proporciona un criptoprocesador virtual seguro que genera y almacena mediciones criptográficas de toda la secuencia de inicio, desde el firmware UEFI hasta los controladores del kernel. Luego, la supervisión de integridad compara continuamente estas mediciones del tiempo de ejecución con un modelo de referencia adecuado conocido que se estableció cuando se creó la VM por primera vez.

Estas funciones proporcionan una cadena de confianza verificable y te alertan automáticamente o toman medidas si detectan modificaciones maliciosas, como las de un bootkit o un rootkit. Las funciones de VM protegida ayudan a mantener la integridad de tu carga de trabajo desde el momento en que se enciende la instancia.

Si permites que los desarrolladores accedan a los recursos de Compute Engine a través de SSH, configura el Acceso al SO con la verificación en 2 pasos. Usa Acceso al SO para administrar las llaves SSH con políticas de Identity and Access Management (IAM) configurando la restricción de la política de la organización compute.requireOsLogin. El Acceso al SO centraliza el acceso a las VM, ya que vincula los permisos de SSH a la identidad de Google y a los roles de IAM de un usuario, lo que elimina la necesidad de administrar claves SSH individuales en cada máquina.

Vincular los permisos de SSH a la identidad de un usuario es fundamental para la seguridad, ya que quitar el rol de IAM de un usuario revoca instantáneamente su acceso en todas las instancias, lo que protege contra la entrada no autorizada de cuentas obsoletas. El sistema simplifica la administración de claves para ayudar a evitar la proliferación de claves y proporciona un registro de auditoría claro y centralizado para todos los eventos de acceso en los registros de auditoría de Cloud. El Acceso al SO también te permite aplicar la autenticación de dos factores, lo que agrega una capa de protección fundamental contra las credenciales y las llaves SSH robadas. Un atacante con tokens de OAuth vulnerados, pero sin una contraseña ni una llave de seguridad está bloqueado por esta función.

El acceso de protocolo de escritorio remoto (RDP) a las instancias de Windows en Compute Engine no admite el servicio de Acceso al SO, por lo que la verificación en 2 pasos no se puede aplicar de forma detallada para las sesiones de RDP. Cuando uses IAP Desktop o complementos de RDP basados en Google Chrome, configura controles generales, como la duración de la sesión para los servicios de Google y la configuración de la verificación en 2 pasos para las sesiones web del usuario. Además, inhabilita el parámetro de configuración Permitir que el usuario confíe en el dispositivo en la verificación en 2 pasos.

• Establece una política de almacenamiento de mensajes con la restricción de política de la organización Restricción de ubicación de recursos (gcp.resourceLocations).
• Configura una política de almacenamiento de mensajes cuando crees un tema. Por ejemplo:

  gcloud pubsub topics create TOPIC_ID \--message-storage-policy-allowed-regions=REGION1, REGION2

Desactiva las direcciones IP externas para las tareas administrativas y de supervisión relacionadas con los trabajos de Dataflow. En su lugar, configura el acceso a tus VMs de trabajador de Dataflow con SSH.

Habilita el Acceso privado a Google y especifica una de las siguientes opciones en tu trabajo de Dataflow:

• --usePublicIps=false y --network=NETWORK-NAME
• --subnetwork=SUBNETWORK-NAME

Aquí:

• NETWORK-NAME: Es el nombre de tu red de Compute Engine.
• SUBNETWORK-NAME: Es el nombre de tu subred de Compute Engine.

Las etiquetas de red son atributos de texto que se adjuntan a las VMs de Compute Engine, como las VMs de trabajador de Dataflow. Las etiquetas de red te permiten hacer que las reglas de firewall de la red de VPC y algunas rutas estáticas personalizadas se puedan aplicar a instancias de VM específicas. Dataflow admite la adición de etiquetas de red a todas las VMs de trabajador que ejecutan un trabajo de Dataflow en particular.

De forma predeterminada, el plano de control y los nodos del clúster de Google Kubernetes Engine (GKE) tienen direcciones enrutables de Internet a las que se puede acceder desde cualquier dirección IP. Restringe el acceso de red al plano de control con un extremo basado en DNS y creando clústeres privados. El plano de control es el centro de administración de un clúster de Kubernetes, y exponerlo a Internet lo convierte en un objetivo principal para los atacantes. Esta configuración hace que el plano de control sea privado y lo quita de Internet.

Restringir el acceso al plano de control ayuda a garantizar que solo los dispositivos de confianza dentro de la red privada de tu organización puedan administrar el clúster, lo que reduce drásticamente el riesgo de un ataque externo.

Cuando crees reglas de firewall, usa el principio de privilegio mínimo para proporcionar acceso solo para el propósito requerido. Cuando sea posible, asegúrate de que tus reglas de firewall no entren en conflicto con las reglas de firewall predeterminadas de GKE.

Usa Grupos de Google para el control de acceso basado en roles (RBAC), que también te permite integrarte en las prácticas de administración de cuentas de usuario existentes, como revocar el acceso cuando alguien abandona la organización. Los Grupos de Google para RBAC ayudan a proporcionar una administración eficiente del acceso al clúster con Identity and Access Management (IAM) y Grupos de Google, lo que es adecuado para la mayoría de las organizaciones que usan Grupos de Google.

Habilita los nodos de GKE protegidos para la verificación criptográfica de los nodos en tu clúster. Los nodos de GKE protegidos proporcionan una identidad y una integridad de nodo sólidas y verificables. Habilita los nodos de GKE protegidos cuando crees o actualices clústeres. Cuando sea posible, usa nodos de GKE protegidos con inicio seguro para autenticar también los componentes de inicio de las VMs de nodos durante el proceso de inicio. No uses el inicio seguro si necesitas módulos de kernel sin firmar de terceros.

Los nodos de GKE protegidos están habilitados de forma predeterminada cuando creas un clúster.

Usa Container-Optimized OS para implementar un SO de contenedor endurecido y administrado. Los sistemas operativos de uso general incluyen muchos programas adicionales que no son necesarios para ejecutar contenedores y, por lo tanto, crean un objetivo más grande e innecesario para los atacantes. Container-Optimized OS es un sistema operativo minimalista y bloqueado que reduce significativamente esta superficie de ataque, ya que solo incluye lo necesario. Como SO administrado, Container-Optimized OS también tiene parches de seguridad que Google aplica automáticamente, lo que ayuda a garantizar que se corrijan las vulnerabilidades críticas y reduce tu carga de trabajo operativa.

Una imagen que incluye Container-Optimized OS con containerd (cos_containerd) tiene containerd como el entorno de ejecución principal de contenedores integrado directamente en Kubernetes. containerd es el componente principal del entorno de ejecución de Docker y está diseñado para proporcionar la funcionalidad principal de contenedores para la interfaz de tiempo de ejecución de contenedores (CRI) de Kubernetes. Es significativamente menos complejo que el daemon de Docker completo y, por lo tanto, tiene una menor superficie de ataque.

Usa Workload Identity Federation for GKE para autenticarte de forma segura en las APIs de las cargas de trabajo de Google Kubernetes Engine (GKE). Cloud de Confiance by S3NS Workload Identity Federation for GKE proporciona una alternativa más simple y segura al uso de claves de cuentas de servicio.

Usa GKE Sandbox para proporcionar una capa adicional de seguridad que ayude a evitar que el código no confiable afecte el kernel del host en los nodos de tu clúster de Google Kubernetes Engine (GKE). GKE Sandbox mejora el aislamiento de las cargas de trabajo no confiables o sensibles, y proporciona una capa adicional de protección contra ataques de escape de contenedores.

Inhabilita el puerto de solo lectura de kubelet 10255 y usa el puerto más seguro 10250 en su lugar. Kubernetes no realiza ninguna verificación de autenticación ni de autorización en este puerto. Kubelet entrega los mismos extremos en el puerto 10250 autenticado y más seguro.

Solo puedes inhabilitar el puerto de solo lectura no seguro de kubelet en la versión 1.26.4-gke.500 de GKE o versiones posteriores.

Crea espacios de nombres o clústeres separados para cada equipo y entorno para implementar el acceso de privilegio mínimo a Kubernetes. Asigna centros de costos y etiquetas adecuadas a cada espacio de nombres para la rendición de cuentas y la devolución del cargo. Solo brinda a los desarrolladores el nivel de acceso a su espacio de nombres que necesitan para implementar y administrar su aplicación, sobre todo en producción. Asigna las tareas que los usuarios deben realizar en el clúster y define los permisos que requieren para realizar cada tarea.

Asigna los roles de Identity and Access Management (IAM) adecuados para Google Kubernetes Engine (GKE) a grupos y usuarios con el fin de otorgar permisos a nivel de proyecto, y usa RBAC para otorgar permisos a nivel de clúster y espacio de nombres.

De forma predeterminada, todos los pods de un clúster pueden comunicarse entre sí. Controla la comunicación de pod a pod según sea necesario para tus cargas de trabajo. Restringir el acceso de red a los servicios hace que sea mucho más difícil para los atacantes moverse de forma lateral dentro del clúster y también ofrece a los servicios cierta protección contra la denegación accidental o deliberada del servicio.

Existen dos formas de controlar el tráfico:

• Usa Cloud Service Mesh o Istio para el balanceo de cargas, la autorización de servicios, la regulación, las cuotas, las métricas y mucho más.
• Usa políticas de red de Kubernetes. Elige esta opción si buscas la funcionalidad básica de control de acceso que expone Kubernetes.

Los controladores de admisión son complementos que rigen y aplican la forma en que se usa el clúster. Habilítalos para usar algunas de las funciones de seguridad más avanzadas de Kubernetes, ya que son una parte importante del enfoque de defensa en profundidad para endurecer tu clúster. De forma predeterminada, los pods en Kubernetes pueden operar con más funciones de las necesarias. Usa controles de admisión para restringir las capacidades del Pod solo a las que se requieren para esa carga de trabajo.

GKE admite varios controles para restringir tus pods de modo que se ejecuten solo con las capacidades otorgadas de forma explícita. Por ejemplo, Policy Controller está disponible para clústeres en flotas. Kubernetes también tiene el controlador de admisión PodSecurity integrado que te permite aplicar los Estándares de seguridad de Pods en clústeres individuales. Policy Controller es una función de GKE que te permite aplicar y validar la seguridad en los clústeres de GKE a gran escala mediante políticas declarativas.

Algunas cargas de trabajo de Kubernetes, en especial las del sistema, tienen permiso para realizar modificaciones automáticas. Por ejemplo, algunas cargas de trabajo se escalan automáticamente. Si bien es conveniente, la modificación automática puede permitir que un atacante que ya haya vulnerado un nodo pueda escalar más a fondo en el clúster. Por ejemplo, un atacante podría hacer que una carga de trabajo en el nodo se modifique a sí misma para ejecutarse como una cuenta de servicio con más privilegios que exista en el mismo espacio de nombres.

No otorgues a las cargas de trabajo el permiso para modificarse a sí mismas de forma predeterminada. Cuando la modificación automática es necesaria, limita los permisos aplicando restricciones de Gatekeeper o de Policy Controller, como NoUpdateServiceAccount de la biblioteca de Gatekeeper de código abierto, que proporciona varias políticas de seguridad útiles.

Cuando implementes políticas, permite que los controladores que administran el ciclo de vida del clúster omitan las políticas. Los controladores deben realizar cambios en el clúster, como aplicar actualizaciones del clúster. Por ejemplo, si implementas la política NoUpdateServiceAccount en GKE, debes establecer los siguientes parámetros en la restricción:

Audita la configuración de tu clúster para detectar desviaciones de la configuración definida. La configuración que se incluye en estas prácticas recomendadas, así como otras configuraciones incorrectas comunes, se pueden verificar automáticamente con Security Command Center.

Usa la Autorización binaria para asegurarte de que las imágenes confiables se implementen en Google Kubernetes Engine (GKE) y Cloud Run. La Autorización Binaria ayuda a garantizar que solo se puedan implementar imágenes de contenedores verificadas y confiables en tus clústeres, lo que fortalece la seguridad de la cadena de suministro de software.

Usa clústeres de Autopilot de Google Kubernetes Engine (GKE). Los clústeres de Autopilot ofrecen medidas de seguridad sólidas, con muchas prácticas recomendadas de seguridad para contenedores o GKE habilitadas de forma predeterminada.

Usa cuentas de servicio de Identity and Access Management (IAM) con privilegios mínimos para los clústeres y nodos de Google Kubernetes Engine (GKE). El acceso al plano de control de GKE está restringido a un solo extremo basado en DNS. La implementación del principio de privilegio mínimo reduce significativamente la superficie de ataque sin necesidad de reglas de firewall adicionales ni hosts bastión.

Crea nodos privados para reducir la exposición a Internet. Los nodos privados de Google Kubernetes Engine (GKE) ayudan a reducir la exposición a Internet, ya que garantizan que los nodos de GKE no tengan una dirección IP pública.

Usa Confidential GKE Nodes para aplicar la encriptación de los datos en uso en tus nodos y cargas de trabajo. Los Confidential GKE Nodes ayudan a proteger las cargas de trabajo altamente sensibles encriptando los datos en uso a través de Confidential Computing.

Ejecuta tus propias autoridades certificadoras para administrar claves dentro de Google Kubernetes Engine (GKE). Usar tus propias autoridades certificadoras te permite tener un mayor control sobre las operaciones criptográficas. Para solicitar acceso a esta función, comunícate con tu Cloud de Confiance by S3NS equipo de cuentas.

Encripta los Secrets de Kubernetes en reposo con claves administradas por Cloud Key Management Service (Cloud KMS). Cloud KMS proporciona una capa adicional de seguridad para los datos de etcd, ya que te permite encriptar secretos de Kubernetes con una clave que posees y administras.

Usa claves de encriptación administradas por el cliente (CMEK) para encriptar los discos de arranque de nodos. CMEK te permite encriptar el disco de arranque de un nodo de Kubernetes con una clave que te pertenece y que administras.

Solo otorga roles de administrador a las cuentas de servicio que implementan y configuran nubes privadas de Google Cloud VMware Engine, y a una cantidad limitada de administradores. Por lo general, la adición o eliminación manual de clústeres y nodos es una acción que no ocurre con frecuencia y que puede tener un gran impacto en la facturación o la disponibilidad del clúster.

Asegúrate de auditar periódicamente a quién se le asignó el rol de administrador de servicios de VMware Engine, ya sea directamente en el proyecto que se usa para VMware Engine o en uno de los niveles superiores de la jerarquía de recursos. Esta auditoría debe incluir otros roles, como los roles básicos de Editor y Propietario, que incluyen permisos críticos relacionados con VMware Engine. Puedes usar servicios como el recomendador de roles de IAM para identificar roles con privilegios excesivos.

Otorga el rol de visualizador del servicio de VMware Engine a los usuarios de forma predeterminada y solo si es necesario. El rol de visualizador del servicio de VMware Engine proporciona acceso de solo lectura a Google Cloud VMware Engine en Cloud de Confiance by S3NS y está diseñado para ser suficiente para la mayoría de las tareas.

Cuando otorgues roles a nivel de VMware en vCenter Server Appliance, usa controles de acceso basados en roles (RBAC) y el principio de privilegio mínimo.

Mantén una única solución de identidad en la que puedas aprovisionar y administrar cuentas de usuario. Esta práctica recomendada te permite centralizar actividades como la administración del ciclo de vida de la identidad, la administración de grupos y la administración de contraseñas. Evita crear una estrategia de identidad fragmentada.

Cuando otorgues roles a nivel de VMware en vCenter Server Appliance, otórgales roles a los grupos que crees en tu proveedor de identidad. No crees una estrategia de identidad fragmentada.

Cuando crees grupos de usuarios en vSphere, no asignes el rol Cloud-propietario-Role. Este rol otorga control administrativo sobre el entorno de vCenter de tu nube privada y, al mismo tiempo, restringe ciertos permisos subyacentes de la infraestructura global. Los grupos de usuarios con permisos superiores a Cloud-propietario-Role se restablecen automáticamente a Cloud-propietario-Role.

Excepto en el proceso de configuración inicial y en los procedimientos de emergencia, no uses la cuenta de servicio predeterminada de vCenter (CloudOwner@gve.local) ni el administrador de la cuenta de servicio predeterminada de NSX-T (admin). Estas cuentas de servicio predeterminadas incluyen permisos potentes, como Cloud-propietario-Role y Enterprise Admin. Guarda las credenciales de estas cuentas de servicio en Secret Manager.

Para evitar y mitigar la divulgación no autorizada de las credenciales de la cuenta de servicio predeterminada de vCenter (CloudOwner@gve.local) y del administrador de la cuenta de servicio predeterminada de NSX-T (admin), rota sus contraseñas cada 90 días.

Controla el tráfico de red de norte a sur que entra y sale de tus nubes privadas con el firewall de puerta de enlace de NSX. Los firewalls de puerta de enlace de NSX son firewalls de norte a sur que ayudan a proteger los perímetros.

Controla el tráfico de red este-oeste dentro de tu nube privada con el firewall distribuido (DFW) de NSX. De forma predeterminada, todas las subredes pueden comunicarse entre sí. Usa DFW para definir el tráfico permitido entre las aplicaciones y los servicios dentro de tu aplicación.

Si ejecutas cargas de trabajo que tienen diferentes requisitos de seguridad o clasificaciones de datos, crea subredes de carga de trabajo para separarlas. Las subredes te permiten reducir el radio del impacto potencial, ya que no mezclan cargas de trabajo con diferentes requisitos y posturas de seguridad.

Usa un receptor de registros para almacenar los registros de auditoría de la API de Google Cloud VMware Engine. Puedes enrutar los registros de auditoría a diferentes destinos según sea necesario.

Para recopilar registros de la plataforma a nivel de VMware (por ejemplo, mensajes syslog de vCenter y NSX-T), configura las nubes privadas de Google Cloud VMware Engine para que reenvíen los registros syslog a un agregador de registros centralizado. Estos registros no se recopilan en los registros de auditoría de VMware Engine y se deben recopilar por separado.

Instala el agente independiente para habilitar Cloud Logging y Cloud Monitoring desde la plataforma de VMware vSphere. El agente independiente te permite recopilar registros a nivel de la carga de trabajo y enviarlos a Logging y Monitoring para su análisis y almacenamiento.

Crea nubes privadas de Google Cloud VMware Engine en regiones que coincidan con los requisitos de residencia de datos de tu organización. Las nubes privadas son recursos aprovisionados de larga duración que no son triviales de implementar y reubicar.

Implementar el servicio Backup and DR o una solución de copias de seguridad de terceros para las cargas de trabajo De forma predeterminada, Google Cloud VMware Engine solo realiza copias de seguridad automáticas de la configuración de vCenter y NSX. Backup and DR facilita la creación de copias de seguridad y la recuperación de VM.

Asegúrate de que las aplicaciones que se ejecutan en Google Cloud VMware Engine encripten su tráfico. VMware Engine no encripta el tráfico de cargas de trabajo en tránsito.

Habilita la encriptación de datos en tránsito en los clústeres de VMware vSAN para encriptar los datos, los metadatos y el tráfico del servicio de archivos.

Si tu entorno regulatorio lo requiere, configura la encriptación de datos en reposo de vSAN para que use claves de encriptación administradas por el cliente (CMEK).

Administrar el ciclo de vida de las claves de encriptación de claves (KEK) que usas para la encriptación de datos en reposo de vSAN Implementa un procedimiento de rotación de claves que se alinee con los requisitos de tu organización.