Cree microservicios seguros y resilientes con microsegmentación

Este artículo apareció originalmente en La nueva pila.

Hace aproximadamente 10 a 12 años, el mundo del software experimentó un cambio en los aspectos arquitectónicos de las aplicaciones empresariales. Los arquitectos y constructores de software comenzaron a alejarse de las gigantescas aplicaciones monolíticas, estrechamente acopladas y desplegadas en los centros de datos privados a una arquitectura más orientada a microservicios alojada en una infraestructura de nube pública. La naturaleza distribuida inherente de los microservicios es un nuevo desafío de seguridad en la nube pública. Durante la última década, a pesar de la creciente adopción de una arquitectura orientada a microservicios para construir aplicaciones empresariales escalables, autónomas y robustas, las organizaciones a menudo tienen dificultades para protegerse contra esta nueva superficie de ataque en la nube en comparación con los data centers tradicionales. Incluye preocupaciones en torno a la multitenencia y la falta de visibilidad y control sobre la infraestructura, así como el entorno operativo. Este cambio en la arquitectura dificulta el cumplimiento de los objetivos de seguridad, especialmente con el énfasis primordial puesto en implementaciones más rápidas basadas en contenedores.

El propósito de este artículo es entender qué es la microsegmentación y cómo puede empoderar a los arquitectos de software, ingenieros de DevOps y arquitectos de seguridad de TI para construir microservicios seguros y resilientes. Específicamente, discutiré el seguridad de red desafíos asociados con el popular mecanismo de orquestación de contenedores Kubernetes, e ilustraré el valor de la microsegmentación para evitar el movimiento lateral cuando se produce una brecha.

Desafíos de seguridad con implementaciones de microservicios

La arquitectura orientada a microservicios requiere dividir las aplicaciones en servicios más pequeños y poco acoplados. Debido a la naturaleza distribuida de estos servicios, a menudo terminan teniendo sus propios almacenes de datos. Cada uno de estos servicios se implementa de forma independiente mediante un contenedor, que ofrece un mecanismo para que una aplicación empaqueta todo, desde código objeto, bibliotecas de terceros, sistemas operativos, herramientas y otras dependencias. Una vez empaquetadas todas las necesidades, los contenedores proporcionan el entorno de ejecución para ejecutarlas sin problemas. Estos contenedores se administran mediante orquestadores como Kubernetes.

Según la noción popular, el ecosistema de contenedores está diseñado para hacer cumplir la seguridad a través del aislamiento. Sin embargo, el aislamiento entre contenedores no necesariamente proporciona los límites de seguridad requeridos. Kubernetes ofrece varias características de seguridad como autenticación, autorización, política de red y estándar de seguridad de pod, etc. Pero desafortunadamente, ni los contenedores ni Kubernetes ofrecen seguridad por defecto. Las implementaciones de Kubernetes priorizan la funcionalidad sobre la seguridad en su configuración predeterminada. Por lo tanto, es posible que un desarrollador o un ingeniero de confiabilidad que sea responsable de crear, mover y destruir estos contenedores no siempre sepa cómo garantizar la seguridad de las implementaciones. Echemos un vistazo más de cerca a algunos de los aspectos importantes de Kubernetes desde la perspectiva de redes y seguridad:

1. Espacio de nombres: En Kubernetes, un espacio de nombres es una forma lógica de dividir los recursos del clúster en espacio virtual entre varios usuarios. A diferencia de Linux, no impone ninguna segmentación de red. Tenga en cuenta que un espacio de nombres no es un límite de seguridad y, por lo tanto, los servicios de un espacio de nombres pueden acceder a los servicios de otro espacio de nombres.
2. Política de red: La política de red de Kubernetes es una construcción específica de la aplicación que permite la comunicación de capa 3 y capa 4 entre espacios de nombres, pods y bloques de direcciones IP. Cuando Kubernetes está instalado, la directiva de red no está disponible de forma predeterminada. Es necesario instalar y configurar complementos de red para hacer cumplir las políticas de red antes de crear los pods. Además, vale la pena señalar que las políticas de red no se pueden aplicar a nivel de servicio. Esta es una deficiencia significativa desde el punto de vista de la seguridad, ya que el control de acceso no se puede extender para los servicios.
3. Estándar de seguridad del pod: En un cluster, los pods admiten múltiples contenedores que comparten la misma máquina física o virtual. Permiten el intercambio de datos y la comunicación entre los contenedores dentro del pod. Un estándar de seguridad de pod permite a un administrador controlar los recursos y sus permisos mediante un modelo de autorización detallado. Este control de seguridad requiere un controlador de admisión, que no está habilitado de forma predeterminada. Un pod privilegiado ofrece acceso administrativo a todos los contenedores. Como resultado, el atacante que obtiene acceso a contenedores privilegiados puede obtener acceso administrativo a los recursos del host.
4. Almacenamiento secreto: Kubernetes almacena información sensible y confidencial como contraseñas, tokens OAuth y claves SSH como secretos en forma codificada base 64, que se considera como texto plano. La directiva de autorización, que se utiliza para restringir el acceso a los secretos, no está configurada de forma predeterminada. Estos se comparten a través de variables ambientales o archivos manifiestos, que también se consideran una práctica insegura para el manejo de secretos. En ausencia de cifrado predeterminado de secretos en reposo y la falta de una gestión sólida de secretos, los secretos se convierten en un objetivo atractivo para el movimiento lateral.

El movimiento lateral y la información privilegiada maliciosa

La naturaleza distribuida de los microservicios hace que la conectividad sea sumamente importante. Específicamente, los contenedores y los pods deben poder comunicarse entre sí a través de los espacios de nombres. Sin embargo, las políticas de red predeterminadas en la capa de cluster no necesariamente implementan principio de privilegio mínimo fuera de la caja. Por lo tanto, no importa cómo proteja su código, no se puede prohibir el acceso implícito no autorizado a los recursos compartidos. Como resultado, la aplicación puede volverse susceptible a movimientos laterales dentro del clúster. La microsegmentación permite implementar un control de acceso granular, creando zonas seguras alrededor de cada microservicio a nivel de contenedor, pod y cluster, lo que reduce significativamente el radio de explosión y aumenta la resiliencia para recuperarse de un ataque exitoso.

La segunda amenaza prominente que presenta el modelo de seguridad del marco Kubernetes existente con respecto a los microservicios es un insider malicioso. Desde la perspectiva de un atacante, cuando la seguridad no está disponible de forma predeterminada, son posibles varias configuraciones erróneas. En ausencia de políticas sólidas de control de acceso o autorización, ataques como la falsificación de solicitudes del lado del servidor (SSRF) permiten que el atacante aproveche un acceso autenticado a un pod para obtener acceso no autorizado a los recursos dentro de otro pod.

Como se mencionó anteriormente, vimos que los controles de seguridad adecuados no están disponibles para proteger los secretos de forma predeterminada. No cifrar y rotar secretos, así como no restringir el acceso a los secretos, son de hecho problemas no relacionados, pero en ausencia de un control de seguridad (en este caso, falta de cifrado), el segundo control de seguridad (es decir, restringir el acceso a las tiendas secretas) se vuelve crucial para evitar la explotación por parte de un insider malicioso (por ejemplo, un administrador descontento).

Presentamos la resiliencia cibernética con microsegmentación

En el contexto de la seguridad, la resiliencia es la capacidad de recuperarse rápidamente de una falla simple debido a ataques o eventos catastróficos como brechas. El primer paso para construir microservicios resilientes es entender qué es lo que nos gustaría proteger del atacante, y si el activo o recurso se ve comprometido, cómo podemos limitar el impacto. La microsegmentación nos ayuda a determinar los recursos que albergan datos esenciales o sistemas críticos tolerantes a fallas, y también proporciona un mecanismo para bloquear el acceso sobre la base del menor privilegio. De esta manera, incluso si un recurso crítico se ve comprometido, los demás no se ven afectados.

El ciclo de vida de desarrollo de software moderno de hoy pone especial énfasis en la entrega rápida de funciones. Estas características se implementan en producción a través de contenedores aún más rápido, principalmente por los mismos desarrolladores o DevOps. Si consideramos todos los tipos de vulnerabilidades a las que el código de microservicios, bibliotecas de terceros y otras dependencias, contenedor o cluster son susceptibles, ¿cómo podemos identificar y prevenir todos estos ataques? La respuesta es bloquear el acceso a los recursos críticos y permitir solo en una “base de necesidad de saber” mediante microsegmentación.

Comenzar con la microsegmentación

No existe una estrategia única para todos al comenzar con la microsegmentación, pero las siguientes son algunas de las mejores prácticas al lanzar un proyecto de microsegmentación para microservicios:

1. Conocer los patrones de diseño de microservicios y usar una plantilla de microsegmentación

Conocer los patrones de diseño facilita una comprensión más profunda de los componentes arquitectónicos, el flujo de datos y los activos que contienen datos críticos. Basándose en estos patrones de diseño de uso frecuente, se pueden crear plantillas de microsegmentación correspondientes. Una vez que el equipo de seguridad y redes haya examinado estas plantillas, serán fáciles de reutilizar y escalar a un ritmo más rápido.

A diferencia de las gigantescas aplicaciones monolitas estrechamente acopladas, las aplicaciones basadas en arquitectura orientada a microservicios siguen uno o más patrones de diseño determinados. Estos patrones de diseño pueden ser uno de los siguientes:

• Los patrones de descomposición implican descomponer las aplicaciones en subdominios o transacciones en función de las capacidades del negocio.
• Los patrones de integración implican patrones de diseño de integración de servicios como gateway de API, agregador, microservicios encadenados, etc.
• Los patrones de bases de datos se centran en la posición de las bases de datos en la arquitectura general de las aplicaciones. Los ejemplos incluyen base de datos por servicio, base de datos compartida, abastecimiento de eventos, etc.
• Los patrones de observabilidad consisten en patrones de diseño que se enfocan en la auditoría, registro y monitoreo, como agregación de registros, rastreo distribuido, verificación de estado, etc.
• Los patrones de preocupaciones transversales ayudan a administrar la funcionalidad a nivel de aplicación, como la seguridad, la tolerancia a fallas, la comunicación de servicio a servicio y la administración de la configuración en una ubicación centralizada. Los ejemplos incluyen disyuntor, descubrimiento de servicio, etc.

(Para obtener más información sobre varios patrones de diseño de microservicios, consulte aquí.)

2. Selección del enfoque de microsegmentación adecuado

Actualmente, existen varios proveedores de microsegmentación con diferentes enfoques de soluciones disponibles en el mercado. En términos generales, las técnicas de microsegmentación se dividen en dos categorías:

1. Las soluciones de microsegmentación independientes de la tecnología se basan en agentes o firewalls de próxima generación.
2. Las soluciones de microsegmentación que dependen de la tecnología se basan en el hipervisor o en las telas de red.

Los microservicios utilizan una pila de tecnología variable, y la implementación más rápida exige la capacidad de escalar rápidamente. Por lo tanto, una solución de microsegmentación independiente de la tecnología, pero una diseñada específicamente para un ecosistema de contenedores capaz de segmentar clústeres, pods, contenedores y servicios, sería una opción óptima.

3. Visibilidad de la red

La capacidad de visualizar aplicaciones segmentadas y el flujo de tráfico es una parte integral de las soluciones de microsegmentación. La visibilidad ofrece una vista integral de toda la red para el administrador, los arquitectos de seguridad y el Chief Security Officer (CSO).

4. Control centralizado fácil de usar

La redacción de una política para cada aplicación puede ser una tarea desalentadora inicialmente. Requiere una serie de conversaciones con los arquitectos de TI, redes y seguridad. Tener un control centralizado para facilitar la creación y aplicación de políticas ayuda a acelerar el proceso. Aprovechar las plantillas de segmentación, que se personalizan según el patrón de diseño del microservicio, también puede ayudar.

5. El performance no debería ser el cuello de botella

La aplicación de políticas de microsegmentación requiere analizar el tráfico e implementar políticas de manera efectiva en tiempo real. El atacante puede aprovechar los retrasos en el performance para manifestar aún más el ataque. Por lo tanto, es extremadamente importante probar el performance, especialmente para microservicios sensibles a la latencia.

Conclusión

En esta entrada de blog, analicé algunas de las preocupaciones de seguridad que presentan los mecanismos de implementación basados en contenedores y Kubernetes utilizados por los microservicios. La palabra “resiliencia” comienza a salir cuando implementamos los microservicios en producción de manera continua a lo largo del ciclo de vida de CI/CD a un ritmo más rápido sin mucha consideración sobre la limitación del acceso a los recursos críticos. La microsegmentación ofrece un sólido mecanismo de control de acceso que minimiza el impacto de las brechas. También fomenta la resiliencia en las aplicaciones empresariales mediante la implementación de microzonas seguras.

La microsegmentación, cuando se planifica y se realiza correctamente, seguramente crea una barrera robusta contra los movimientos laterales en el mundo de los microservicios. Es difícil asegurar los microservicios mientras se mueve rápido, pero es importante detenerse y pensar en implementar seguridad y resiliencia a escala y planificarla de manera proactiva con todas las partes interesadas.