Llegamos a ustedes gracias a:



Reportajes y análisis

5 cosas que DevOps necesita hacer para proteger los contenedores

Para los departamentos de seguridad, la adopción de la 'contenerización' presenta un desafío multifacético.

[24/02/2017] ¿La adopción y el despliegue más amplio de tecnologías de contenedores (tipo Docker, CoreOS y otras) amenazan con convertirse en la última escaramuza entre operaciones, desarrolladores y seguridad de la información? Ciertamente, existe la posibilidad de ampliar la brecha, pero de hecho hay mucho más terreno común de lo que inicialmente se sugeriría. La 'contenerización' introduce una nueva infraestructura que opera de forma dinámica y está abierta por naturaleza, con más potencial para la actividad de contenedores cruzados. La contenerización presenta una oportunidad casi sin precedentes para integrar la seguridad en la tubería de entrega de software -en lugar de injertar chequeos de seguridad, monitorear los contenedores y políticas para controles de acceso como una idea posterior.

El CTO de Aqua, Amir Jerbi sugiere algunas cosas clave que DevOps debe saber sobre seguridad en aplicaciones en contenedores.

Gestión de vulnerabilidades en imágenes de contenedores

El amplio uso de imágenes de contenedores aumenta las apuestas para la gestión de la vulnerabilidad y obliga a las organizaciones a tomar una nueva mirada a su enfoque actual. Las imágenes son los componentes básicos de los contenedores y son fácilmente eliminadas por los desarrolladores de un registro centralizado para ejecutar contenedores en un proceso altamente automatizado y flexible.

Desde una perspectiva de seguridad y gobernabilidad, confiar en la imagen del contenedor es una preocupación fundamental durante todo el ciclo de vida del desarrollo del software. Garantizar que las imágenes están firmadas y originadas en un registro de confianza son buenas prácticas de seguridad. Sin embargo, el mantenimiento de esas prácticas no resuelve el desafío principal: ¿cómo puedo vetar y validar el código que las imágenes encapsulan?

Evaluación continua

En entornos de contenedores, las imágenes se agregan constantemente al registro central o concentrador, y los contenedores que ejecutan las imágenes se giran y se toman hacia abajo. Amplificar la escala del problema es la relativa facilidad con la que las imágenes basadas en compilaciones de código abierto pueden generarse a partir de Dockerfiles, por ejemplo, y especialmente a medida que más "capas" son incorporadas en la imagen. Cuantas más capas se incorporen en la imagen para acelerar el despliegue, mayor será el riesgo de que un componente de software, incluidos los componentes de código abierto, encuentren su camino en la producción sin ser escaneados, validados y parcheados si es necesario.

A menos que el proceso de escaneo de las imágenes antes de que se carguen en registros sea administrado de forma estricta, en oposición al enfoque tradicional de las exploraciones periódicas, la puerta se abre a la propagación de vulnerabilidades.

Reducción de la superficie de ataque del contenedor

La 'contenerización' tiene algunas peculiaridades estructurales y operacionales específicas que suben la apuesta para reducir la superficie de ataque. Aunque existe preocupación por la arquitectura de contenedor compartida subyacente de los contenedores, la atención se ha desplazado más allá de garantizar que el host garantice configuraciones estándar y perfiles de contenedores.

A diferencia de los entornos virtualizados, donde un hipervisor sirve como un punto de control, cualquier usuario o servicio con acceso a la cuenta raíz del kernel puede ver y acceder a todos los contenedores que comparten el kernel de Linux. Los equipos de seguridad pueden confiar en enfoques probados para endurecer núcleos y hosts, pero tienen enfoques mucho menos maduros y repetibles para asegurar procesos que son específicos para el entorno de contenedores.

Más de Docker

Otro ejemplo es la capacidad de enlazar el daemon Docker al grupo de acceso Unix Docker o al puerto TCP, que permite a los contenedores hablar entre sí, pero también tiene el efecto de proporcionar a todos los usuarios acceso root. El acceso abierto a la raíz reduce la fricción operacional, pero es probable que los departamentos de seguridad hagan hincapié en las violaciones del principio de acceso al acceso menos privilegiado.

Para resolver esta tensión inherente entre el aislamiento y la necesidad de comunicación, operaciones y desarrollo del contenedor deberían tomar medidas tanto para controlar la medida en que los recipientes interactúan entre sí internamente, como para limitar el número de contenedores.

Apriete el control de acceso de usuario

Hasta hace poco, el acceso root al host Docker era, por defecto, una proposición de todo o nada. Aunque restringir el acceso a la cuenta raíz del host del contenedor ha consumido la mayor atención -y ha impulsado la inversión por Docker en las nuevas características para eliminar sistemáticamente el acceso privilegiado- la mayor preocupación por la seguridad es reforzar los controles de acceso a las cuentas privilegiadas y las operaciones de la tubería de despliegue. Existen claros beneficios para la organización en general para controles de acceso pragmáticos y efectivos: rendición de cuentas y consistencia operativa. La rendición de cuentas conlleva cierta capacidad para identificar quién hizo cambios en las configuraciones o configuraciones de contenedores, descargó una imagen o comenzó un contenedor en producción.

Aunque el acceso root puede ser la forma más fácil para los desarrolladores, también puede significar que tienen demasiado acceso. Además, un atacante que obtiene acceso a la cuenta root tendrá acceso completo al contenedor, incluidos sus datos y programas.

Gestión central

La aplicación de restricciones gestionadas centralmente a los cambios o comandos que un usuario puede ejecutar en función de su función, en lugar de su capacidad para acceder a la cuenta raíz, permite a las organizaciones definir y hacer cumplir los procesos estándar. La implementación de la separación de obligaciones y privilegios de acceso y limitaciones de comandos basadas en el rol de usuario, es una base para la garantía a través del ciclo de vida de desarrollo de software.

Sin un enfoque centralizado, es difícil determinar si los diferentes privilegios definidos para diferentes usuarios para cada contenedor son de hecho apropiados y consistentes con su función funcional, y con un alcance en términos de acceso de privilegios mínimos.

Endurecimiento del host: Aislamiento de seguridad

Uno de los beneficios clave de la contenedorización es que aísla una aplicación y sus dependencias en una unidad autónoma que puede ejecutarse en cualquier lugar. Una implicación crítica es que hay herramientas establecidas para restringir a lo que la unidad autónoma puede y no puede acceder y consumir. Los grupos de control y los espacios de nombres son los componentes claves de aislamiento del contenedor: los grupos de control definen cuánto del núcleo compartido y los recursos del sistema puede consumir un contenedor, mientras que los espacios de nombres definen lo que un contenedor puede ver o los recursos a los que está autorizado. Los objetivos de diseño para estos componentes son claros: en los que se desea ejecutar varios servicios en un servidor, es esencial para la seguridad y la estabilidad que los servicios estén tan aislados entre sí como sea posible.

Lo malo de los detalles, sin embargo, es asegurar que los grupos de control y los espacios de nombres se configuren apropiadamente y consistentemente, y que las configuraciones sean congruentes con las políticas de seguridad.

¿Deslizándose por las grietas?

Si bien el aislamiento puede ser una manera efectiva de limitar el potencial de un contenedor que gana acceso a los recursos del kernel, no es tan efectivo para aislar la ruta de ejecución del contenedor. El aislamiento de recursos tampoco es efectivo para detectar o prevenir ataques de escalada que abusen de los privilegios o salgan del contenedor "sandbox".

En ausencia de un enfoque en capas con controles efectivos (y pragmáticos) y visibilidad para la defensa en tiempo de ejecución y la creación de perfiles de contenedores, hay muchas maneras en que los contenedores pueden deslizarse a través de las pistas a través de la configuración errónea. Por ejemplo, un ataque de denegación de servicio en un entorno de contenedor no es tan disímil de un contenedor "pícaro" que consume más recursos del núcleo y evita otros procesos.

Automatización del proceso de seguridad del contenedor

Nada haría más feliz a todo el mundo que la posibilidad de que la seguridad se pueda cocinar en contenedores como parte de la forma en que se construyen, se envían y se ejecutan -y esta es también la mejor manera de minimizar la fricción entre las motivaciones de DevOps y las de seguridad de TI. Dado que los equipos de seguridad a menudo desconocen los procesos que culminan en los contenedores que se ejecutan en producción, es importante que participen en la definición de flujos de trabajo y faciliten la transferencia de conocimientos, para asegurarse de que están en condiciones de proveer los controles y prácticas que requieren para cumplir con los estándares de seguridad y pasar auditorías de cumplimiento.

¿Qué debería hacer devops?

DevOps, por otro lado, debe hacer lo que mejor hace -la automatización. El uso de herramientas existentes de CI/CD y herramientas de orquestación para integrar el escaneo de imágenes, controles de configuración, monitoreo y otras medidas de seguridad en el ciclo de vida del contenedor -desde el desarrollo hasta la producción- haría que el proceso de seguridad sea transparente y relativamente indoloro. Aunque siempre habrá una necesidad de capas de seguridad adicionales y supervisión, pero la automatización puede llevar la línea de base hasta un nivel donde el esfuerzo adicional se reduciría al mínimo, reduciendo así el riesgo de que la seguridad actúe como una barrera para el despliegue.