Prácticas recomendadas de seguridad de Cloud Service Mesh

En este documento, se describen prácticas recomendadas para establecer y administrar una configuración segura de Cloud Service Mesh que se ejecuta en Google Kubernetes Engine (GKE). En la orientación del documento, se va más allá de los parámetros de configuración y la instalación de Cloud Service Mesh, y se describe cómo puedes usar Cloud Service Mesh con otros productos y funciones de Google Cloud para protegerte de las amenazas de seguridad que las aplicaciones en una malla pueden enfrentar.

El público objetivo de este documento incluye administradores que controlan políticas en Cloud Service Mesh y usuarios que ejecutan servicios en Cloud Service Mesh. 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 con los requisitos de cumplimiento.

El documento está organizado de la siguiente manera:

Introducción

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

Cloud Service Mesh se basa en la malla de servicios de Istio de código abierto, la cual habilita configuraciones y topologías más sofisticadas. Según la estructura de la organización, uno o más equipos o roles pueden ser responsables de instalar y configurar una malla. Los parámetros de configuración predeterminados de Cloud Service Mesh se eligen para proteger las aplicaciones, pero, en algunos casos, es posible que necesites configuraciones personalizadas o que otorgues excepciones si excluyes ciertos puertos, apps o direcciones IP de participar en una malla. Es importante tener controles para administrar las configuraciones de 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 supone que las amenazas de seguridad se originan dentro y fuera del perímetro de seguridad de una organización. Los siguientes son algunos ejemplos de tipos de ataques de seguridad que pueden afectar a las aplicaciones en una malla de servicios:

  • Ataques de robo 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 enmascara como un servicio legítimo para obtener o modificar la comunicación entre servicios.
  • Ataques de elevación de privilegios. Por ejemplo, ataques que usan acceso ilícito a privilegios elevados para realizar operaciones en una red.
  • Ataques de denegación del servicio (DoS).
  • Ataques de botnet que intentan comprometer y manipular servicios para iniciar ataques en otros servicios.

Los ataques también se pueden clasificar según los objetivos de los ataques:

  • Ataques de red interna de malla. Ataques dirigidos a la manipulación, el espionaje o la falsificación de identidad de la comunicación interna de servicio a servicio o de servicio a plano de control de la malla.
  • Ataques del plano de control. Ataques cuyo objetivo sea hacer que el plano de control no funcione (como un ataque de DoS) o robar datos sensibles del plano de control.
  • Ataques perimetrales de la malla. Ataques dirigidos a la manipulación, el espionaje o la falsificación de identidad de la comunicación en la entrada o la salida de la malla.
  • Ataques a las operaciones de la malla. Ataques dirigidos a las operaciones de la malla. Los atacantes pueden intentar obtener privilegios elevados para realizar operaciones maliciosas en una malla, como modificar sus políticas de seguridad y las imágenes de carga 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 riesgos de seguridad posibles:

  • Protección de seguridad incompleta. Una malla de servicios no se configuró con políticas de autenticación y autorización para proteger su seguridad. Por ejemplo, no se definieron políticas de autenticación o autorización para los servicios en una malla.
  • Excepciones de la política de seguridad. Para adaptarse a sus casos de uso específicos, los usuarios pueden crear excepciones a la política de seguridad para que cierto tráfico (interno o externo) se excluya de las políticas de seguridad de Cloud Service Mesh. Para manejar estos casos de forma segura, consulta la sección Maneja las excepciones a las políticas de forma segura.
  • No actualizar imágenes. Es posible que se detecten vulnerabilidades en las imágenes que se usan en una malla. Debes 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 (sin experiencia ni recursos). El software de la malla y la configuración de políticas necesitan un mantenimiento regular para aprovechar los mecanismos de protección de seguridad más recientes.
  • Falta de visibilidad. La configuración incorrecta o insegura de las políticas de malla y el tráfico o las operaciones anormales de la malla no tienen la atención de los administradores de la malla.
  • Desvío de configuración. La configuración de políticas en una malla se desvía de la fuente de información.

Medidas para proteger una malla de servicios

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

Arquitectura de seguridad

La seguridad de una malla de servicios depende de la seguridad de los componentes en diferentes capas del sistema de malla y sus aplicaciones. La intención de alto nivel 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, los que en conjunto logran la seguridad general del sistema bajo 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 proporciona seguridad en varias capas, incluidas las siguientes:

  • Seguridad perimetral 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 en la malla.
    • La seguridad de salida de Cloud Service Mesh regula el tráfico saliente de las cargas de trabajo internas.
    • La autenticación de usuarios de Cloud Service Mesh se integra en la infraestructura de Google para autenticar las llamadas externas de los navegadores web a los servicios que ejecutan aplicaciones web.
    • La administració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 Certificate Authority Service.
    • Cloud Armor puede protegerte contra ataques externos de denegación de servicio distribuido (DSD) y de capa 7. Actúa como un firewall de aplicación web (WAF) para proteger la malla contra ataques de red. Por ejemplo, ataques de inyección y ejecución de código remoto.
    • La VPC y los Controles del servicio de VPC protegen el perímetro de la malla a través de los controles de acceso a la red privada.
  • Seguridad del clúster
    • La TLS mutua (mTLS) de Cloud Service Mesh aplica la encriptación y la autenticación del tráfico de carga de trabajo a carga de trabajo.
    • La AC administrada, como la autoridad certificadora de Cloud Service Mesh y Certificate Authority Service, aprovisiona y administra de forma segura los certificados que usan las cargas de trabajo.
    • La autorización de Cloud Service Mesh aplica el control de acceso para los servicios de malla según sus identidades y otros atributos.
    • El panel de seguridad de GKE Enterprise proporciona la supervisión de los parámetros de configuración 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 a los Pods según las direcciones IP, las etiquetas de Pod, los espacios de nombres y otros.
    • La seguridad del plano de control protege contra los ataques en el plano de control. Esta protección evita que los atacantes modifiquen, exploten o filtren datos de configuración de servicios y mallas.
  • Seguridad de las cargas de trabajo
    • Mantente al día con las actualizaciones de seguridad de Cloud Service Mesh para garantizar que los objetos binarios de Cloud Service Mesh que se ejecutan en tu malla estén libres de vulnerabilidades conocidas públicamente.
    • La federación de identidades para cargas de trabajo para GKE permite que las cargas de trabajo obtengan credenciales para llamar de forma segura a los servicios de Google.
    • CNI (interfaz de red de contenedor) de Kubernetes evita los ataques de elevación de privilegios mediante la eliminación de la necesidad de un contenedor init 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 del operador para mitigar los ataques que se originan en los operadores maliciosos o en el robo de identidad de operadores.
    • Policy Controller de GKE Enterprise valida y audita las configuraciones de políticas en la malla para evitar configuraciones incorrectas.
    • La autorización binaria de Google Cloud garantiza que las imágenes de carga de trabajo en la malla sean las que autorizan los administradores.
    • Google Cloud Audit Logging audita las operaciones de malla.

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

flujo de tráfico del diagrama de seguridad

Seguridad del clúster

Habilita TLS mutua estricta

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 contra los ataques de robo de datos y MitM mediante la aplicación de autenticación y encriptación de mTLS para todas las partes comunicativas. El modo permisivo usa mTLS cuando ambas partes la admiten, pero permite conexiones sin mTLS. Por el contrario, la mTLS estricta requiere que el tráfico se encripte y se 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 a fin de cumplir con los requisitos de seguridad y cumplimiento.

Para obtener más información, consulta Anthos Service Mesh mediante un ejemplo: mTLS | Aplicación de mTLS en toda la malla.

Habilita los controles de acceso

Las políticas de seguridad de Cloud Service Mesh (como las de autenticación y autorización) deben aplicarse a todo el tráfico dentro y fuera de la malla, a menos que haya justificaciones sólidas 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 omitir las políticas de seguridad de Cloud Service Mesh en algunos puertos y rangos de IP. Por ejemplo, para establecer conexiones nativas con servicios no administrados por Cloud Service Mesh. Para proteger Cloud Service Mesh en esos casos de uso, consulta Administra de forma segura las excepciones de políticas de Cloud Service Mesh.

El control de acceso del servicio es fundamental para evitar el acceso no autorizado a los servicios. La aplicación de mTLS encripta y autentica una solicitud, pero una malla aún necesita 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 proveniente de un cliente autenticado.

Las políticas de autorización de Cloud Service Mesh proporcionan una manera flexible de configurar los controles de acceso para defender los servicios contra el acceso no autorizado. Las políticas de autorización de Cloud Service Mesh se deben aplicar en función de las identidades autenticadas derivadas de los resultados de autenticación: las autenticaciones basadas en mTLS o en un token web JSON (JWT) deben usarse juntas como parte de las políticas de autorización de Cloud Service Mesh.

Aplica políticas de autenticación de Cloud Service Mesh

Token web JSON (JWT)

Además de la autenticación mTLS, los administradores de malla pueden exigir que un servicio autentique y autorice solicitudes basadas en JWT. Cloud Service Mesh no actúa como un proveedor de JWT, sino que autentica JWT según los extremos configurados del conjunto de claves web JSON (JWKS). La autenticación de JWT se puede aplicar a las puertas de enlace de entrada para el tráfico externo o a los servicios internos para el tráfico en la malla. La autenticación de JWT se puede combinar con la autenticación de mTLS cuando un JWT se usa como una credencial para representar al emisor final y el servicio solicitado requiere una prueba de que se lo llama en nombre del emisor final. La aplicación de la autenticación de JWT protege contra 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 el navegador y el control de acceso a tus cargas de trabajo. Integra una malla de servicios en los proveedores de identidad (IdP) existentes para implementar un flujo de consentimiento y acceso estándar de OpenID Connect (OIDC) basado en la Web y usa políticas de autorización de Cloud Service Mesh para el control de acceso.

Aplica políticas de autorización

Control de las políticas de autorización de Cloud Service Mesh:

  • Quién o qué tiene permiso para 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 según las identidades reales que ejecutan los servicios, las propiedades de la capa de aplicación (capa 7) de tráfico (por ejemplo, los encabezados de solicitudes) y las propiedades de la capa de red (capa 3 y capa 4), como rangos de IP y 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 autenticación para defenderse del acceso no autorizado a los servicios o datos.

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

Las políticas de autorización deben restringir la confianza tanto como sea posible. Por ejemplo, el acceso a un servicio se puede definir según las rutas de URL individuales expuestas por un servicio, de modo que solo un servicio A pueda acceder a la ruta /admin de un 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 (capa 3 y capa 4) y controlan el acceso a la red para puertos y direcciones IP en Pods de Kubernetes y espacios de nombres de Kubernetes.

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

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

Una solicitud desde fuera de la malla para acceder a un servicio de malla debe incluir un token, como JWT o cookie, a fin de que el servicio de malla lo autentique y autorice. Un token desde fuera de la malla puede ser de larga duración. A fin de protegerse de los ataques de repetición de tokens, se debe intercambiar un token de fuera de la malla por un token de corta duración interno de la malla con un permiso limitado en la entrada de la malla. El servicio de malla autentica un token interno de la malla y autoriza la solicitud de acceso según el token interno de la malla.

¿Qué sigue?