5 riesgos de seguridad de contenedores que enfrenta cada empresa

En el transcurso de los últimos 10 años, la metodología tradicional de desarrollo de aplicaciones (waterfall) ha dado paso a las metodologías más ágiles centradas en DevOps centradas en la entrega continua y la implementación continua. Esta tendencia se aceleró en 2013 cuando los contenedores Docker entraron en escena y marcaron el comienzo del proverbial cruce del abismo en la adopción de contenedores. Un estudio reciente de HCiberSegurityreveló que el 87 % de las organizaciones encuestadas tenían contenedores desplegados en producción. El mismo estudio reveló que el 60% de las organizaciones habían sufrido un incidente de seguridad de contenedores en 2018.

Ya sea que esté utilizando contenedores para crear su aplicación desde cero o transfiriendo sus aplicaciones monolíticas existentes a un entorno en contenedores, debe darse cuenta de que los entornos de contenedores presentan un conjunto único de desafíos de seguridad que debe estar preparado para abordar desde el primer día como comienza a extraer sus imágenes base para construir sus contenedores hasta que se implementan y se ejecutan en entornos de producción. No es sorprendente que Gartner haya incluido la seguridad de los contenedores en su lista de Los 10 mejores proyectos de seguridad de 2019.

Lo que sigue son cinco de los riesgos de seguridad de contenedores más comunes que debe tener en cuenta junto con recomendaciones prácticas para ayudarlo a mejorar su postura de seguridad.

1. Usar imágenes inseguras

Los contenedores se construyen utilizando una imagen principal o base. Las imágenes son útiles para crear contenedores porque puede reutilizar los distintos componentes de una imagen en lugar de crear una imagen de contenedor desde cero. Sin embargo, como cualquier pieza de código, las imágenes o sus dependencias pueden contener vulnerabilidades.

Recomendación:

La seguridad de la imagen comienza con la aplicación de prácticas estrictas de exploración de vulnerabilidades y políticas de procedencia de la imagen. Considere usar una política que rechace el uso de imágenes si no se han escaneado en los últimos 60 días o si provienen de un registro de imágenes que no está en la lista blanca.

2. Contenedores que se ejecutan con la bandera privilegiada

Cualquiera que tenga un conocimiento modesto de los contenedores puede saber qué es un contenedor privilegiado. Los contenedores que se ejecutan con el indicador privilegiado pueden hacer casi cualquier cosa que pueda hacer un host, ejecutarse con todas las capacidades y obtener acceso a los dispositivos del host. Esto significa que si un atacante viola un contenedor que se ejecuta con el indicador privilegiado, puede causar estragos.

Recomendación:

Como práctica recomendada, no ejecute contenedores con esta marca. En su lugar, use CAP ADD y CAP DROP para proporcionar capacidades más detalladas a sus contenedores.

3. Comunicación sin restricciones entre contenedores

Los contenedores necesitan comunicarse entre sí para lograr sus objetivos. Pero debido a la cantidad de contenedores y microservicios que puede estar ejecutando y la naturaleza efímera de los contenedores en general, implementar reglas de redes/cortafuegos que cumplan con el principio de privilegios mínimos puede ser un desafío. No obstante, su objetivo debe ser permitir que los contenedores se comuniquen solo con aquellos contenedores que sean absolutamente necesarios para minimizar su superficie de ataque.

Recomendación:

Las herramientas de orquestación y administración de contenedores, como Kubernetes, son una excelente manera de implementar controles de red. Kubernetes, por ejemplo, empaqueta contenedores en pods y permite que los equipos de DevOps implementen políticas de red que pueden restringir la comunicación de pod a pod a lo que se requiere. Puede hacer esto observando primero el comportamiento de la aplicación para determinar qué rutas de comunicación son necesarias para que la aplicación funcione y luego crear políticas de red que son esencialmente listas blancas para esas rutas de red.

4. Contenedores que ejecutan procesos no autorizados o maliciosos

En un entorno en expansión con un contenedor que tiene una vida útil promedio de horas o incluso minutos, monitorear los procesos de contenedores en ejecución puede ser particularmente desafiante. En otras palabras, la rápida rotación de contenedores hace que sea casi imposible para los simples mortales monitorear qué procesos de contenedor se están ejecutando en un momento dado, y mucho menos identificar procesos innecesarios o maliciosos.

Recomendación:

En lugar de esperar a que una infracción exitosa le notifique que un proceso malicioso se estaba ejecutando en un contenedor y que afectaba la seguridad del contenedor, limite la cantidad y los tipos de procesos que se pueden ejecutar. Hay dos formas de mitigar este riesgo. Puede usar la función CAP ADD de Docker para agregar solo las capacidades de Linux necesarias para que un contenedor se ejecute correctamente y logre su objetivo, y use CAP DROP para eliminar todas las capacidades innecesarias.

Como un paso de mitigación adicional, también puede establecer límites de PID de modo que limite su contenedor para ejecutar solo una cantidad determinada de procesos que se ajusten a lo que se requiere para que el contenedor logre su objetivo. Esto no solo evitará las bombas de bifurcación, sino que también garantizará que se impida la ejecución de procesos maliciosos, como shells inversos e inyecciones remotas de código.

5. Contenedores que no están debidamente aislados del huésped

Es un arma de doble filo cuando se trata de la seguridad de los contenedores. Su naturaleza inmutable, combinada con su corta vida útil y funcionalidad limitada, ofrece varios beneficios de seguridad. Sin embargo, los contenedores también pueden ser un vector para atacar al host subyacente. Mencionamos anteriormente que los contenedores que ejecutan la bandera privilegiada presentan este riesgo. Hay muchas otras configuraciones incorrectas que pueden poner en riesgo el host subyacente.

Recomendación:

Hay varios pasos que puede seguir para aislar aún más los contenedores del host. A continuación se muestran sólo dos ejemplos:

• No comparta el espacio de nombres de red del host. Si lo hace, podría correr el riesgo de que un contenedor apague el host de Docker.
• No comparta los espacios de nombres de proceso del host. Si lo hace, permitiría que un contenedor vea todos los procesos que se ejecutan en un sistema host, lo que deja los procesos en el host en riesgo de ser manipulados o cerrados.

Los contenedores han dado lugar a microservicios y prácticas DevOps, lo que ha llevado a ciclos de desarrollo y lanzamiento más rápidos. Han aumentado la colaboración entre los desarrolladores y los equipos de seguridad. Asegurar adecuadamente los contenedores se reduce a los siguientes mejores practicas de seguridad y garantizar que la seguridad esté integrada en el ciclo de vida del contenedor en lugar de ser tratada como una ocurrencia tardía