Información general sobre la seguridad de Cloud Service Mesh

La seguridad de las APIs de Istio de Cloud Service Mesh te ayuda a mitigar las amenazas internas y a 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 por el servicio y contextualizada por la solicitud que es independiente de la seguridad de la red subyacente. Por este motivo, Cloud Service Mesh te permite adoptar una estrategia de defensa en profundidad que sea coherente con los principios de seguridad de confianza cero. Esto se consigue mediante políticas declarativas y sin modificar el código de las aplicaciones.

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, 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.

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 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 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 de la malla.

  • 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, si se vulneran las credenciales de un cliente, un atacante pueda acceder a todos los datos de los usuarios.

  • 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 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 esté en un clúster o una red de nube privada virtual (VPC) diferentes.

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 mTLS de las cargas de trabajo de la malla 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 de 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. 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 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 empresarial 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 coste del Servicio de Autoridades de Certificación no está incluido en el precio base de Cloud Service Mesh y se cobra por separado. Además, Servicio de Autoridades de Certificación incluye un SLA explícito, mientras que 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. Solo se admiten las comunicaciones entre clústeres del mismo proyecto. 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 desde determinados clientes solo si existe una reclamación de solicitud o 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, usa 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.

Cumple los requisitos de FIPS

El componente del plano de datos usa módulos de cifrado validados por el estándar FIPS 140-2.

Limitaciones

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 permitido. 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