Prácticas recomendadas de seguridad de Cloud Service Mesh

En este documento se describen las prácticas recomendadas para establecer y gestionar una configuración segura de Cloud Service Mesh en Google Kubernetes Engine (GKE). La guía de este documento va más allá de los ajustes que se usan para configurar e instalar Cloud Service Mesh, y describe cómo puedes usar Cloud Service Mesh con otros productos y funciones de Google Cloud para protegerte frente a las amenazas de seguridad a las que se pueden enfrentar las aplicaciones de una malla.

Este documento está dirigido a los administradores que gestionan políticas en una malla de servicios de Cloud y a los usuarios que ejecutan servicios en una malla de servicios de Cloud. Las medidas de seguridad que se describen aquí también son útiles para las organizaciones que necesitan mejorar la seguridad de sus mallas de servicios para cumplir los requisitos.

El documento se organiza de la siguiente manera:

Introducción

Cloud Service Mesh ofrece funciones y herramientas que te ayudan a observar, gestionar y proteger servicios de forma unificada. Adopta un enfoque centrado en las aplicaciones y usa identidades de aplicaciones de confianza en lugar de un enfoque centrado en la IP de la red. Puede implementar una malla de servicios de forma transparente sin necesidad de modificar el código de aplicación. Cloud Service Mesh proporciona un control declarativo sobre el comportamiento de la red, lo que ayuda a separar el trabajo de los equipos responsables de ofrecer y lanzar funciones de aplicaciones de las responsabilidades de los administradores encargados de la seguridad y la red.

Cloud Service Mesh se basa en la malla de servicios Istio de código abierto, que permite configuraciones y topologías sofisticadas. En función de la estructura de tu organización, uno o varios equipos o roles pueden ser responsables de instalar y configurar una malla. La configuración predeterminada de Cloud Service Mesh se elige para proteger las aplicaciones, pero, en algunos casos, es posible que necesites configuraciones personalizadas o conceder excepciones excluyendo determinadas aplicaciones, puertos o direcciones IP de la participación en una malla. Es importante contar con controles para gestionar las configuraciones de la malla y las excepciones de seguridad.

Vectores de ataque y riesgos de seguridad

Vectores de ataque

La seguridad de Cloud Service Mesh sigue el modelo de seguridad de confianza cero, que presupone que las amenazas de seguridad proceden tanto del interior como del exterior del perímetro de seguridad de una organización. Estos son algunos ejemplos de tipos de ataques de seguridad que pueden amenazar las aplicaciones de una malla de servicios:

  • Ataques de filtración externa de datos. Por ejemplo, ataques que espían datos sensibles o credenciales del tráfico de servicio a servicio.
  • Ataques de intermediario. Por ejemplo, un servicio malicioso que se hace pasar por un servicio legítimo para obtener o modificar la comunicación entre servicios.
  • Ataques de apropiación de privilegios. Por ejemplo, ataques que usan el acceso ilícito a privilegios elevados para llevar a cabo operaciones en una red.
  • Ataques de denegación de servicio (DoS).
  • Ataques de botnets que intentan poner en peligro y manipular servicios para lanzar ataques contra otros servicios.

Los ataques también se pueden clasificar en función de los objetivos:

  • Protege la red interna frente a ataques. Ataques dirigidos a manipular, espiar o suplantar la comunicación interna entre servicios o entre servicios y el plano de control de la malla.
  • Ataques al plano de control. Ataques dirigidos a provocar un fallo en el plano de control (como un ataque DoS) o a extraer datos sensibles del plano de control.
  • Ataques de borde de malla. Ataques dirigidos a manipular, espiar o suplantar la comunicación en la entrada o salida de la malla.
  • Ataques de operaciones de malla. Ataques dirigidos a las operaciones de la malla. Los atacantes pueden intentar obtener privilegios elevados para llevar a cabo operaciones maliciosas en una malla, como modificar sus políticas de seguridad e imágenes de cargas de trabajo.

Riesgos de seguridad

Además de los ataques de seguridad, una malla también se enfrenta a otros riesgos de seguridad. En la siguiente lista se describen algunos posibles riesgos de seguridad:

  • Protección de seguridad incompleta. No se ha configurado una malla de servicios con políticas de autenticación y autorización para proteger su seguridad. Por ejemplo, no se han definido políticas de autenticación ni de autorización para los servicios de una malla.
  • Excepciones de la política de seguridad. Para adaptarse a sus casos prácticos específicos, los usuarios pueden crear excepciones de políticas de seguridad para que determinado tráfico (interno o externo) se excluya de las políticas de seguridad de Cloud Service Mesh. Para gestionar estos casos de forma segura, consulta la sección Gestionar de forma segura las excepciones a las políticas.
  • No se actualizan las imágenes. Es posible que se descubran vulnerabilidades en las imágenes usadas en una malla. Debe mantener actualizados el componente de malla y las imágenes de carga de trabajo con las correcciones de vulnerabilidades más recientes.
  • Falta de mantenimiento (no se dispone de experiencia ni recursos). El software de la malla y las configuraciones de las políticas necesitan un mantenimiento periódico para aprovechar los mecanismos de protección de seguridad más recientes.
  • Falta de visibilidad. Las configuraciones incorrectas o no seguras de las políticas de malla y el tráfico o las operaciones de malla anómalos no se comunican a los administradores de la malla.
  • Desviación de la configuración. La configuración de las políticas de una malla se desvía de la fuente de información veraz.

Medidas para proteger una malla de servicios

En esta sección se presenta un manual de operaciones para proteger las mallas de servicios.

Arquitectura de seguridad

La seguridad de una malla de servicios depende de la seguridad de los componentes de las diferentes capas del sistema de malla y sus aplicaciones. El objetivo general de la postura de seguridad de Cloud Service Mesh propuesta es proteger una malla de servicios mediante la integración de varios mecanismos de seguridad en diferentes capas, que en conjunto logran la seguridad general del sistema en el modelo de seguridad de confianza cero. En el siguiente diagrama se muestra la postura de seguridad propuesta de Cloud Service Mesh.

Postura de seguridad de Cloud Service Mesh

Cloud Service Mesh ofrece seguridad en varias capas, entre las que se incluyen las siguientes:

  • Seguridad de los extremos de la malla
    • La seguridad de entrada de Cloud Service Mesh proporciona control de acceso para el tráfico externo y protege el acceso externo a las APIs expuestas por los servicios de la malla.
    • La seguridad de salida de Cloud Service Mesh regula el tráfico saliente de las cargas de trabajo internas.
    • Autenticación de usuarios de Cloud Service Mesh se integra con la infraestructura de Google para autenticar las llamadas externas de navegadores web a los servicios que ejecutan aplicaciones web.
    • La gestión de certificados de la puerta de enlace de Cloud Service Mesh protege y rota las claves privadas y los certificados X.509 que usan las puertas de enlace de entrada y salida de Cloud Service Mesh mediante el servicio de autoridad de certificación.
    • Cloud Armor puede protegerte frente a ataques de denegación de servicio distribuido (DDoS) externos y de capa 7. Actúa como cortafuegos de aplicación web (WAF) para proteger la malla frente a ataques de red. Por ejemplo, ataques de inyección y de ejecución remota de código.
    • VPC y Controles de Servicio de VPC protegen el perímetro de la malla mediante controles de acceso a la red privada.
  • Seguridad del clúster
    • La autenticación TLS mutua (mTLS) de Cloud Service Mesh cifra y autentica el tráfico entre cargas de trabajo.
    • Las AC gestionadas, como la autoridad de certificación de Cloud Service Mesh y el servicio de autoridades de certificación, aprovisionan y gestionan de forma segura los certificados que usan las cargas de trabajo.
    • La autorización de Cloud Service Mesh aplica el control de acceso a los servicios de la malla en función de sus identidades y otros atributos.
    • El panel de control de seguridad de GKE Enterprise ofrece una monitorización de las configuraciones de las políticas de seguridad y de las políticas de red de Kubernetes para las cargas de trabajo.
    • La política de red de Kubernetes aplica el control de acceso de los pods en función de las direcciones IP, las etiquetas de los pods, los espacios de nombres y más.
    • La seguridad del plano de control protege frente a los ataques al plano de control. Esta protección evita que los atacantes modifiquen, exploten o filtren datos de configuración de servicios y de la malla.
  • Seguridad de las cargas de trabajo
    • Mantente al día de las versiones de seguridad de Cloud Service Mesh para asegurarte de que los archivos binarios de Cloud Service Mesh que se ejecutan en tu malla no tengan vulnerabilidades conocidas públicamente.
    • Workload Identity Federation para GKE permite que las cargas de trabajo obtengan credenciales para llamar de forma segura a los servicios de Google.
    • La CNI (interfaz de red de contenedores) de Kubernetes evita los ataques de escalada de privilegios al eliminar la necesidad de un contenedor de inicialización de Cloud Service Mesh con privilegios.
  • Seguridad del operador
    • El control de acceso basado en roles (RBAC) de Kubernetes restringe el acceso a los recursos de Kubernetes y limita los permisos de los operadores para mitigar los ataques procedentes de operadores maliciosos o de suplantación de identidad.
    • Policy Controller de GKE Enterprise valida y audita las configuraciones de políticas en la malla para evitar errores de configuración.
    • Google Cloud Autorización binaria garantiza que las imágenes de carga de trabajo de la malla sean las autorizadas por los administradores.
    • Google Cloud El registro de auditoría audita las operaciones de la malla.

En el diagrama siguiente se muestran los flujos de comunicación y configuración con las soluciones de seguridad integradas en Cloud Service Mesh.

Diagrama de seguridad del flujo de tráfico

Seguridad del clúster

Habilitar TLS mutuo estricto

Un ataque de intermediario (MitM) intenta insertar una entidad maliciosa entre dos partes que se comunican para espiar o manipular la comunicación. Cloud Service Mesh se protege frente a ataques de intermediario y de filtración externa de datos aplicando la autenticación y el cifrado con mTLS a todas las partes que se comunican. El modo permisivo usa mTLS cuando ambas partes lo admiten, pero permite conexiones sin mTLS. Por el contrario, mTLS estricto requiere que el tráfico se cifre y autentique con mTLS, y no permite el tráfico de texto sin formato.

Cloud Service Mesh te permite configurar la versión mínima de TLS para las conexiones TLS entre tus cargas de trabajo, de modo que se cumplan tus requisitos de seguridad y cumplimiento.

Para obtener más información, consulta Cloud Service Mesh mediante ejemplo: mTLS | Aplicar mTLS en toda la malla.

Habilitar controles de acceso

Las políticas de seguridad de Cloud Service Mesh (como las políticas de autenticación y autorización) se deben aplicar a todo el tráfico que entra y sale de la malla, a menos que haya motivos de peso para excluir un servicio o un pod de las políticas de seguridad de Cloud Service Mesh. En algunos casos, los usuarios pueden tener motivos legítimos para saltarse las políticas de seguridad de Cloud Service Mesh en algunos puertos y rangos de IPs. Por ejemplo, para establecer conexiones nativas con servicios que no gestiona Cloud Service Mesh. Para proteger Cloud Service Mesh en estos casos prácticos, consulta el artículo Gestionar de forma segura las excepciones de las políticas de Cloud Service Mesh.

El control de acceso a los servicios es fundamental para evitar el acceso no autorizado a los servicios. La aplicación de mTLS cifra y autentica una solicitud, pero una malla sigue necesitando políticas de autorización de Cloud Service Mesh para aplicar el control de acceso a los servicios. Por ejemplo, rechazar una solicitud no autorizada procedente de un cliente autenticado.

Las políticas de autorización de Cloud Service Mesh ofrecen una forma flexible de configurar los controles de acceso para proteger tus servicios frente a accesos no autorizados. Las políticas de autorización de Cloud Service Mesh deben aplicarse en función de las identidades autenticadas derivadas de los resultados de la autenticación. Las autenticaciones basadas en mTLS o en tokens web JSON (JWT) deben usarse conjuntamente como parte de las políticas de autorización de Cloud Service Mesh.

Implementar obligatoriamente las políticas de autenticación de Cloud Service Mesh

JSON Web Token (JWT)

Además de la autenticación mTLS, los administradores de la malla pueden requerir que un servicio autentique y autorice las solicitudes basadas en JWT. Cloud Service Mesh no actúa como proveedor de JWT, sino que autentica los JWTs en función de los endpoints del conjunto de claves web de JSON (JWKS) configurados. La autenticación JWT se puede aplicar a las pasarelas de entrada para el tráfico externo o a los servicios internos para el tráfico de la malla. La autenticación JWT se puede combinar con la autenticación mTLS cuando se usa un JWT como credencial para representar al llamante final y el servicio solicitado requiere una prueba de que se le está llamando en nombre del llamante final. Al aplicar la autenticación JWT, se evitan los ataques que acceden a un servicio sin credenciales válidas y en nombre de un usuario final real.

Autenticación de usuarios de Cloud Service Mesh

La autenticación de usuarios de Cloud Service Mesh es una solución integrada para la autenticación de usuarios finales basada en navegador y el control de acceso a tus cargas de trabajo. Integra una malla de servicios con proveedores de identidades (IdP) para implementar un flujo de inicio de sesión y consentimiento estándar basado en web de OpenID Connect (OIDC) y usa políticas de autorización de Cloud Service Mesh para el control de acceso.

Aplicar políticas de autorización

Las políticas de autorización de Cloud Service Mesh controlan lo siguiente:

  • Quién o qué puede acceder a un servicio.
  • A qué recursos se puede acceder.
  • Qué operaciones se pueden realizar en los recursos permitidos.

Las políticas de autorización son una forma versátil de configurar el control de acceso en función de las identidades reales con las que se ejecutan los servicios, las propiedades de la capa de aplicación (capa 7) del tráfico (por ejemplo, los encabezados de solicitud) y las propiedades de la capa de red (capas 3 y 4), como los intervalos de IP y los puertos.

Las políticas de autorización de Cloud Service Mesh deben aplicarse en función de las identidades autenticadas derivadas de los resultados de la autenticación para protegerse contra el acceso no autorizado a servicios o datos.

De forma predeterminada, el acceso a un servicio debe denegarse a menos que se defina explícitamente una política de autorización para permitir el acceso al servicio. Consulta las prácticas recomendadas de la política de autorización para ver ejemplos de políticas de autorización que deniegan solicitudes de acceso.

Las políticas de autorización deben restringir la confianza tanto como sea posible. Por ejemplo, se puede definir el acceso a un servicio en función de las rutas de URL individuales expuestas por un servicio, de forma que solo el servicio A pueda acceder a la ruta /admin del servicio B.

Las políticas de autorización se pueden usar junto con las políticas de red de Kubernetes, que solo operan en la capa de red (capas 3 y 4) y controlan el acceso a la red de las direcciones IP y los puertos de los pods y los espacios de nombres de Kubernetes.

Forzar el intercambio de tokens para acceder a los servicios de la malla

Para protegerse frente a ataques de repetición de tokens, en los que se roban tokens y se reutilizan para acceder a servicios de la malla, un token de una solicitud procedente de fuera de la malla se debe intercambiar por un token interno de la malla de corta duración en el perímetro de la malla.

Una solicitud desde fuera de la malla para acceder a un servicio de la malla debe incluir un token, como un JWT o una cookie, para que el servicio de la malla la autentique y autorice. Un token de fuera de la malla puede tener una larga duración. Para protegerse frente a los ataques de repetición de tokens, un token de fuera de la malla se debe intercambiar por un token interno de la malla de corta duración con un ámbito limitado en la entrada de la malla. El servicio de malla autentica un token interno de la malla y autoriza la solicitud de acceso en función del token interno de la malla.

Siguientes pasos