Cree microservicios resistentes y seguros con microsegmentación

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

Hace unos 10 o 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 alejar de las aplicaciones gigantes, estrechamente acopladas y monolíticas implementadas en los centros de datos privados a una arquitectura más orientada a los microservicios alojada en la 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 crear aplicaciones empresariales escalables, autónomas y robustas, las organizaciones a menudo luchan por proteger contra esta nueva superficie de ataque en la nube en comparación con los centros de datos tradicionales. Incluye preocupaciones sobre la tenencia múltiple y la falta de visibilidad y control sobre la infraestructura, así como el entorno operativo. Este cambio arquitectónico 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 comprender qué es la microsegmentación y cómo puede capacitar a los arquitectos de software, ingenieros de DevOps y arquitectos de seguridad de TI para crear microservicios seguros y resistentes. Específicamente, discutiré los desafíos de seguridad de red 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 infracción.

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 empaquete todo, desde código objeto, bibliotecas de terceros, sistemas operativos, herramientas y otras dependencias. Una vez que se empaquetan todas las necesidades, los contenedores proporcionan el entorno de ejecución para ejecutarlas sin problemas. Estos contenedores se gestionan 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 proporciona necesariamente los límites de seguridad necesarios. Kubernetes ofrece varias funciones de seguridad como autenticación, autorización, política de red y estándar de seguridad de pods, etc. Pero desafortunadamente, ni los contenedores ni Kubernetes ofrecen seguridad de forma predeterminada. 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 las redes y la seguridad:

1. Namespace: 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 aplica 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 directiva 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 se instala Kubernetes, 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 pods. Además, ok la pena señalar que las políticas de red no se pueden aplicar a nivel de servicio. Esta es una deficiencia significativa desde una perspectiva de seguridad, ya que el control de acceso no se puede extender para los servicios.
3. Estándar de seguridad de pods: En un clúster, los pods admiten varios 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 pods permite a un administrador controlar los recursos y sus licencias 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 con privilegios puede obtener acceso administrativo a los recursos del host.
4. Almacenamiento secreto: Kubernetes almacena información sensible y confidencial, como contraseñas, tokens de OAuth y claves SSH, como secretos en formato codificado base 64, que se considera texto sin formato. La directiva de autorización, que se usa para restringir el acceso a los secretos, no está configurada de forma predeterminada. Estos se comparten a través de variables de entorno o archivos de manifiesto, que también se consideran una práctica insegura para manejar secretos. En ausencia de cifrado predeterminado de secretos en reposo y la falta de una gestión estable de secretos, los secretos se convierten en un objetivo atractivo para el movimiento lateral.

Movimiento lateral y el insider malicioso

La naturaleza distribuida de los microservicios hace que la conectividad sea sumamente importante. En concreto, los contenedores y los pods deben poder comunicar entre sí a través de espacios de nombres. Sin embargo, las políticas de red predeterminadas en la capa de clúster no implementan necesariamente el principio de privilegios mínimos listos para usar. Por lo tanto, independientemente de 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 volver susceptible a movimientos laterales dentro del grupo. La microsegmentación permite implementar un control de acceso granular, creando zonas seguras alrededor de cada microservicio a nivel de contenedor, pod y clúster, lo que reduce significativamente el radio de explosión y aumenta la resiliencia para recuperar de un ataque exitoso.

La segunda amenaza destacada que presenta el modelo de seguridad del marco de Kubernetes existente con respecto a los microservicios es una información privilegiada maliciosa. Desde la perspectiva de un atacante, cuando la seguridad no está disponible de forma predeterminada, es posible que se produzcan varios errores de configuración. En ausencia de políticas de autorización o control de acceso estables, los ataques como la falsificación de solicitudes del lado del servidor (SSRF) permiten al atacante aprovechar un acceso autenticado a un pod para obtener acceso no autorizado a los recursos dentro de otro pod.

Como se discutió 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 problemas no relacionados, pero en ausencia de un control de seguridad (en este caso, la falta de cifrado), el segundo control de seguridad (es decir, restringir el acceso a los almacenes secretos) se vuelve crucial para evitar la explotación por parte de un infiltrado malicioso (por ejemplo, un administrador descontento).

Introducción a la resiliencia cibernética con microsegmentación

En el contexto de la seguridad, la resiliencia es la capacidad de recuperar rápidamente de una falla simple debido a ataques o eventos catastróficos como infracciones. El primer paso para crear microservicios resilientes es comprender 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 contienen datos esenciales o sistemas críticos tolerantes a fallas, y también proporciona un mecanismo para bloquear el acceso sobre la base del privilegio mínimo. De esta manera, incluso si un recurso crítico se ve comprometido, los demás no se ven afectados.

El ciclo de vida del desarrollo de software moderno de hoy en día pone especial énfasis en la entrega rápida de funciones. Estas funciones 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 son susceptibles el código de microservicios, bibliotecas de terceros y otras dependencias, contenedores o clústeres, ¿cómo podemos identificar y prevenir todos estos ataques? La respuesta es bloquear el acceso a recursos críticos y permitir solo en función de la "necesidad de saber" empleando la microsegmentación.

Introducción a 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. Sobre la base de estos patrones de diseño de uso frecuente, se pueden crear las plantillas de microsegmentación correspondientes. Una vez que estas plantillas sean examinadas por el equipo de seguridad y redes, serán fáciles de reutilizar y escalar a un ritmo más rápido.

A diferencia de las aplicaciones monolíticas gigantes y estrechamente acopladas, las aplicaciones basadas en la 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 dividir las aplicaciones en subdominios o transacciones basadas en las capacidades empresariales.
• Los patrones de integración implican patrones de diseño de integración de servicios, como puerta de enlace API, agregador, microservicios encadenados, etc.
• Los patrones de base 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 centran en la auditoría, el registro y la supervisión, como la agregación de registros, el seguimiento distribuido, la comprobación de estado, etc.
• Los patrones de preocupaciones transversales ayudan a gestionar 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 disyuntores, descubrimiento de servicios, 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, hay varios proveedores de microsegmentación con diferentes enfoques de soluciones disponibles en el mercado. A grandes rasgos, 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 dependientes de la tecnología se basan en el hipervisor o en las estructuras de red.

Los microservicios emplean 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 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 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 director de seguridad (CSO).

4. Control centralizado fácil de usar

Redactar una política para cada aplicación puede ser una tarea desalentadora inicialmente. Requiere un serial 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 de microservicios, también puede ayudar.

5. El rendimiento no debe 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 rendimiento para manifestar aún más el ataque. Por lo tanto, es extremadamente importante probar el rendimiento, especialmente para microservicios sensibles a la latencia.

Conclusion

En esta publicación de blog, analicé algunas de las preocupaciones de seguridad que presentan los mecanismos de implementación basados en contenedores y Kubernetes empleados por los microservicios. La palabra "resistencia" comienza a desaparecer cuando implementamos los microservicios en producción de forma continua a lo largo del ciclo de vida de CI/CD a un ritmo más rápido sin mucha consideración en cuanto a limitar el acceso a recursos críticos. La microsegmentación ofrece un estable mecanismo de control de acceso que minimiza el impacto de las infracciones. También fomenta la resiliencia en las aplicaciones empresariales mediante la implementación de microzonas seguras.

La microsegmentación, cuando se planea y realiza correctamente, seguramente crea una barrera estable contra los movimientos laterales en el mundo de los microservicios. Es difícil proteger los microservicios mientras se avanza rápido, pero es importante detener y pensar en implementar la seguridad y la resiliencia a escala y planearla de manera proactiva con todas las partes interesadas.