Información general sobre la seguridad de Cloud Service Mesh

La seguridad de Cloud Service Mesh te ayuda a mitigar las amenazas internas y reducir el riesgo de brechas de seguridad de datos, ya que se encarga de asegurar que todas las comunicaciones entre cargas de trabajo estén cifradas, autenticadas mutuamente y autorizadas.

Tradicionalmente, la microsegmentación que usa reglas basadas en IP se ha utilizado para mitigar los riesgos internos. Sin embargo, la adopción de contenedores, servicios compartidos y entornos de producción distribuidos en varias nubes dificulta la configuración y el mantenimiento de este enfoque.

Con Cloud Service Mesh, puedes configurar una capa de seguridad de red contextualizada en el servicio y contextualizada en la solicitud que es independiente de la seguridad de la red subyacente. Por este motivo, Cloud Service Mesh te permite adoptar una postura de defensa en profundidad que se ajusta a los principios de seguridad Zero Trust. Esto le permite conseguir esta postura mediante políticas declarativas y sin modificar el código de ninguna aplicación.

TLS mutuo

Cloud Service Mesh usa TLS mutuo (mTLS) para la autenticación entre iguales. La autenticación hace referencia a la identidad: ¿quién es este servicio? ¿Quién es este usuario final? ¿Puedo confiar en que es quien dice ser?

mTLS permite que las cargas de trabajo verifiquen la identidad de las demás y se autentiquen entre sí. Puede que conozcas el protocolo TLS simple por su uso en HTTPS para permitir que los navegadores confíen en los servidores web y cifren los datos que se intercambian. Cuando se usa TLS simple, el cliente establece que se puede confiar en el servidor validando su certificado. mTLS es una implementación de TLS en la que tanto el cliente como el servidor presentan certificados entre sí y verifican sus identidades.

mTLS es el medio por el que Cloud Service Mesh implementa tanto la autenticación como el cifrado entre servicios.

En Cloud Service Mesh 1.6 y versiones posteriores, mTLS automático está habilitado de forma predeterminada. Con mTLS automático, un proxy sidecar del cliente detecta automáticamente si el servidor tiene un sidecar. El sidecar del cliente envía mTLS a las cargas de trabajo con sidecars y texto sin formato a las cargas de trabajo sin sidecars. Sin embargo, los servicios aceptan tráfico de texto sin formato y mTLS. Para proteger tu malla de servicios, te recomendamos que migres tus servicios para que solo acepten tráfico mTLS.

Para obtener más información sobre cómo aplicar solo mTLS, consulta Anthos Service Mesh mediante ejemplo: mTLS.

Configuración del conjunto de cifrado

La siguiente lista incluye los conjuntos de cifrado predeterminados y conformes con FIPS de Cloud Service Mesh:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

Para mejorar la seguridad, la versión mínima de TLS del lado del servidor admitida por las cargas de trabajo de Cloud Service Mesh es la 1.2, que admite la personalización de los conjuntos de cifrado. Ten en cuenta que Cloud Service Mesh también admite TLS v1.3, que codifica de forma rígida los conjuntos de cifrado y no permite cambiarlos.

Para obtener más información sobre los conjuntos de cifrado, consulta Configuración TLS común de Envoy y Autenticación TLS mutua de Istio.

Ventajas para la seguridad

Cloud Service Mesh ofrece las siguientes ventajas de seguridad:

  • Mitiga el riesgo de ataques de repetición o suplantación de identidad que usen credenciales robadas. Cloud Service Mesh usa certificados mTLS para autenticar a los peers, en lugar de tokens de portador, como los JSON Web Tokens (JWT). Como los certificados mTLS están vinculados al canal TLS, no es posible que una entidad de tu entorno de producción suplante a otra simplemente reproduciendo el token de autenticación sin acceso a las claves privadas.

  • Asegura el cifrado en tránsito. Usar mTLS para la autenticación también asegura que todas las comunicaciones TCP se cifren en tránsito.

  • Asegura que solo los clientes autorizados puedan acceder a un servicio con datos sensibles. Solo los clientes autorizados pueden acceder a un servicio con datos sensibles, independientemente de la ubicación de red del cliente y de las credenciales a nivel de aplicación. Puedes especificar que solo los clientes con identidades de servicio autorizadas o que estén en espacios de nombres de Kubernetes autorizados puedan acceder a un servicio. También puedes usar políticas de acceso basadas en IP para conceder acceso a clientes implementados fuera del entorno de GKE Enterprise.

  • Mitiga el riesgo de que se produzca una brecha de seguridad en los datos de los usuarios en tu red de producción. Puedes asegurarte de que los usuarios internos solo puedan acceder a datos sensibles a través de clientes autorizados. Además, puede asegurarse de que determinados clientes solo puedan acceder a los datos de usuario si presentan un token de usuario válido y de corta duración. De esta forma, se reduce el riesgo de que la vulneración de una sola credencial de cliente conceda a un atacante acceso a todos los datos de usuario.

  • Identifica qué clientes han accedido a un servicio con datos sensibles. El registro de acceso de Cloud Service Mesh registra la identidad mTLS del cliente, además de la dirección IP. De esta forma, puedes saber fácilmente qué carga de trabajo ha accedido a un servicio, aunque la carga de trabajo sea efímera y se haya desplegado de forma dinámica, y se encuentre en un clúster o una red de nube privada virtual (VPC) diferente.

Funciones

En esta sección se describen las funciones que ofrece Cloud Service Mesh para disfrutar de sus ventajas de seguridad.

Rotación automática de certificados y claves

Al usar mTLS basado en identidades de servicio, se pueden cifrar todas las comunicaciones TCP y se proporciona una credencial no repetible más segura para el control de acceso. Uno de los principales retos de usar mTLS a gran escala es gestionar las claves y los certificados de todas las cargas de trabajo de destino. Cloud Service Mesh se encarga de rotar las claves y los certificados de mTLS de las cargas de trabajo de GKE Enterprise sin interrumpir las comunicaciones. Se pueden configurar intervalos de actualización de certificados más pequeños para reducir el riesgo.

Autoridad de certificación de Cloud Service Mesh

Cloud Service Mesh incluye una autoridad de certificación privada multirregional gestionada, autoridad de certificación de Cloud Service Mesh, para emitir certificados para mTLS. La autoridad de certificación de Cloud Service Mesh es un servicio altamente fiable y escalable que se ha optimizado para cargas de trabajo escaladas dinámicamente en una plataforma en la nube. Con la autoridad de certificación de Cloud Service Mesh, Google gestiona la seguridad y la disponibilidad del backend de la AC. La autoridad de certificación de Cloud Service Mesh te permite confiar en una única raíz de confianza en todos los clústeres de GKE Enterprise. Cuando usas la autoridad de certificación de Cloud Service Mesh, puedes usar los grupos de identidades de carga de trabajo para proporcionar un aislamiento general. De forma predeterminada, la autenticación falla si el cliente y el servidor no están en el mismo grupo de identidades de carga de trabajo.

Los certificados de la autoridad de certificación de Cloud Service Mesh incluyen los siguientes datos sobre los servicios de tu aplicación:

  • El Google Cloud ID del proyecto
  • Espacio de nombres de GKE
  • Nombre de la cuenta de servicio de GKE

Servicio de Autoridades de Certificación

Como alternativa a la autoridad de certificación de Cloud Service Mesh, puedes configurar Cloud Service Mesh para que use el Servicio de Autoridades de Certificación, que es adecuado para los siguientes casos prácticos:

  • Si necesitas que diferentes autoridades de certificación firmen certificados de carga de trabajo en diferentes clústeres.
  • Si quieres usar certificados de complementos de AC personalizados de Istiod.
  • Si necesitas crear una copia de seguridad de tus claves de firma en un HSM gestionado.
  • Si trabajas en un sector muy regulado y estás sujeto a cumplimiento.
  • Si quieres encadenar tu AC de Cloud Service Mesh a un certificado raíz de empresa personalizado para firmar certificados de carga de trabajo.

El coste de la autoridad de certificación de Cloud Service Mesh está incluido en los precios de Cloud Service Mesh. El servicio de CA no está incluido en el precio base de Cloud Service Mesh y se cobra por separado. Además, el Servicio de Autoridades de Certificación incluye un SLA explícito, pero la autoridad de certificación de Cloud Service Mesh no.

En esta integración, se asignan dos roles de IAM a todas las cargas de trabajo de Cloud Service Mesh:

Políticas de control de acceso basadas en la identidad (cortafuegos)

Con Cloud Service Mesh, puedes configurar políticas de seguridad de red basadas en la identidad mTLS en lugar de en la dirección IP del peer. De esta forma, puedes crear políticas que sean independientes de la ubicación de red de la carga de trabajo. Por el momento, solo se admiten comunicaciones entre clústeres del mismo proyecto de Google Cloud .

Solicitar políticas de control de acceso (cortafuegos) que tengan en cuenta las reclamaciones

Además de la identidad de mTLS, puedes conceder acceso en función de las reclamaciones de la solicitud en el encabezado JWT de las solicitudes HTTP o gRPC. Cloud Service Mesh te permite afirmar que un JWT está firmado por una entidad de confianza. Esto significa que puedes configurar políticas que permitan el acceso de determinados clientes solo si existe una reclamación de solicitud o si coincide con un valor especificado.

Autenticación de usuarios con Identity-Aware Proxy

Para autenticar a los usuarios que acceden a cualquier servicio expuesto en una puerta de enlace de entrada de Cloud Service Mesh, utiliza Identity-Aware Proxy (IAP). IAP puede autenticar a los usuarios que inician sesión desde un navegador, integrarse con proveedores de identidades personalizados y emitir un token JWT de corta duración o un RCToken que se pueda usar para conceder acceso en la puerta de enlace de entrada o en un servicio de nivel inferior (mediante un sidecar). Para obtener más información, consulta el artículo sobre cómo integrar IAP con Cloud Service Mesh.

Autenticación de usuarios con tu proveedor de identidades

Puedes integrar tu proveedor de identidades con Cloud Service Mesh para proporcionar autenticación de usuario final basada en navegador y control de acceso a tus cargas de trabajo implementadas. Para obtener más información, consulta el artículo sobre cómo configurar la autenticación de usuarios de Cloud Service Mesh.

Registro y monitorización de accesos

Cloud Service Mesh se asegura de que los registros de acceso y las métricas estén disponibles en Google Cloud Observability y proporciona un panel de control integrado para comprender los patrones de acceso de un servicio o una carga de trabajo en función de estos datos. También puedes configurar un destino privado. La malla de servicios de Cloud te permite reducir el ruido en los registros de acceso registrando solo los accesos correctos una vez en un periodo configurable. Las solicitudes que se rechazan por una política de seguridad o que provocan un error siempre se registran. De esta forma, puedes reducir significativamente los costes asociados a la ingesta, el almacenamiento y el procesamiento de registros sin perder señales de seguridad clave.

Cumple los requisitos de FIPS

Todos los componentes del plano de control y los proxies del clúster en la arquitectura x86 usan módulos de cifrado validados por el estándar FIPS 140-2.

Limitaciones

Actualmente, la seguridad de Cloud Service Mesh tiene la siguiente limitación:

  • La autenticación de usuarios que usa IAP requiere que un servicio se publique en Internet. IAP y Cloud Service Mesh te permiten configurar políticas que pueden restringir el acceso a usuarios y clientes autorizados en un intervalo de IPs permitidas. Si decides exponer el servicio solo a los clientes de la misma red, debes configurar un motor de políticas personalizado para la autenticación de usuarios y la emisión de tokens.

Siguientes pasos