OPINIÓN

Integrar la seguridad con las tres fases del despliegue de contenedores

26/04/2019 - Hari Srinivasan, director de Gestión de Producto de Qualys
En los últimos años, la adopción de la tecnología de contenedores se ha disparado, al igual que la preocupación por securizar las aplicaciones creadas y desplegadas por los equipos de DevOps (acrónimo de desarrollo y operaciones en inglés) que los utilizan.

La protección que proporcionan los equipos de seguridad debe aplicarse a todo el ciclo de vida del contenedor y ha de integrarse de manera transparente y no invasiva en el pipeline de DevOps. Para hacer esto, es necesario entender la tecnología de contenedores Docker y adoptar procesos y herramientas dedicados a estos entornos.

Los contenedores causan problemas específicos de seguridad y cumplimiento, muchos de los cuales están relacionados con cualidades que los desarrolladores encuentran atractivos, como por ejemplo empaquetar una aplicación y sus dependencias sin un S.O. “invitado”. Entre estos retos se incluyen el uso de software no validado proveniente de repositorios públicos –a menudo plagados de vulnerabilidades no corregidas–, o el despliegue de contenedores con configuraciones deficientes.

Además, los contenedores pueden comunicarse directamente entre sí a través de puertos de red expuestos, y son difíciles de rastrear porque son muy efímeros.

Objetivos de seguridad

Los equipos de seguridad deben tener en cuenta cuatro objetivos principales respecto a la seguridad de los contenedores, comenzando por obtener visibilidad a lo largo de los diferentes entornos para detectar y rastrear todos los desarrollos, tanto on-premises como en la nube.

Un segundo objetivo será gestionar las vulnerabilidades dentro de los contenedores para evitar intrusiones; y en tercer lugar, habrán de aprovecharse las API REST para integrar los productos DevOps con las herramientas que se van a utilizar para la seguridad.

Finalmente, el programa de seguridad para los contenedores debe replantear la respuesta ante incidentes (IR), en especial porque los contenedores vulnerables generalmente no se parchean, sino que son reemplazados por otros nuevos con una imagen actualizada. Por tanto, habrá que actualizar el programa de IR para recopilar información sobre los nuevos entornos operativos (por ejemplo la plataforma de orquestación) y planificar el modelo “extraer y reemplazar” como un elemento del IR.

Protección del ‘pipeline’

Las tres fases de la implementación de contenedores (desarrollo, envío y ejecución) deben estar protegidas, y cada una tiene requisitos específicos. Analicemos cada una de ellas en detalle:

1. Desarrollo: en esta primera fase, el objetivo primario de seguridad es bloquear las imágenes vulnerables para que no entren en los repositorios de la organización. Esto es especialmente importante en el caso de los repositorios públicos, una práctica muy común entre los desarrolladores.

Para mantener estas imágenes inseguras fuera de los repositorios es importante aprovechar las API REST o los plugins nativos de forma que las comprobaciones de seguridad puedan ejecutarse automáticamente dentro de las herramientas de CI/CD utilizadas por el equipo de DevOps. El equipo de TI (Tecnologías de la Información) debe poder contar con la flexibilidad de determinar parámetros para bloquear imágenes, como por ejemplo la presencia de vulnerabilidades con clasificación de gravedad de 3, 4 o 5; la falta de adherencia a los estándares de cumplimiento; o el uso de secretos abiertamente en las imágenes.

Esta integración también permitirá al equipo de seguridad otorgar a los desarrolladores acceso a las herramientas de seguridad. Con este acceso, los propios desarrolladores pueden realizar proactivamente ciertas funciones de seguridad desde la herramienta de CI/CD sin necesidad de depender del equipo de TI. Por ejemplo, obtendrán acceso a los datos de escaneo y podrán tomar medidas de mitigación directamente desde la interfaz de su herramienta.

2. Envío: en esta fase es clave asegurarse de que las imágenes que ya están en los repositorios son verificadas en busca de vulnerabilidades. Los registros y repositorios deben ser inventariados, y las imágenes deberán ser escaneadas a medida que son añadidas. Asimismo, se debería programar un escaneo automático diario para buscar nuevas vulnerabilidades y verificar las nuevas imágenes que se agregan a los repositorios.

También se habrá de verificar que las imágenes vienen de fuentes seguras y de confianza, así como mantenerlas actualizadas y a salvo de las vulnerabilidades. Mediante Docker Notary Service, u otros servicios similares, se pueden firmar las imágenes para asegurar que solo se utilizarán las de confianza.

3. Ejecución: con las imágenes del contenedor ya en el registro y disponibles para su uso en producción, será esencial contar con la visibilidad y monitorización continua de los entornos runtime, así como la capacidad de prevenir y responder a las brechas. Los equipos de seguridad deben detectar contenedores vulnerables o falsos (rogue), identificar dónde están y evaluar su potencial impacto en función de cuán extendidos están en el entorno.

Una clave aquí es etiquetar los contenedores que ya están funcionando en el sistema y que se están apartando del “comportamiento inmutable” de su imagen principal, lo que podría indicar una brecha. Los contenedores siguen a la imagen, por lo que será clave identificar el comportamiento de la aplicación ‘containerizada’ para detectar cualquier desviación sospechosa (por ejemplo, llamadas al sistema, procesos o comunicaciones inesperadas). Los equipos de seguridad deben determinar dónde se almacenarán estas imágenes en el entorno runtime e identificar las imágenes activas e inactivas.

Tras reconocer los contenedores fraudulentos, la herramienta de seguridad debe permitir la aplicación de medidas como el bloqueo o la cuarentena, así como profundizar en los detalles de las anomalías para comprender dónde está el problema. Esto no debería afectar a las operaciones, ya que se puede generar un nuevo contenedor desde la imagen principal para reemplazar el contenedor falso o fraudulento. Una buena opción sería poder validar automáticamente la imagen en función de las políticas de seguridad, usando herramientas propias, y se podrían aprovechar orquestadores como Kubernetes para evitar que los contenedores fraudulentos entren a través de los controladores de admisión.

Además, se habrán de seguir las prácticas prescritas para aportar a los entornos de orquestación un modelo seguro, de “menor acceso”. Si se tiene acceso al host subyacente, también aquí será necesario aplicar estas prácticas sobre seguridad y cumplimiento.

En resumen

Esperamos que este artículo le haya ayudado a entender mejor los retos particulares de seguridad para los contenedores, y cómo es necesario atender a ellos durante todo su ciclo de vida: evitar que entren en los repositorios imágenes vulnerables durante la fase de desarrollo; securizar las imágenes que llegan a los registros en la fase de envío; y el escaneo en producción durante la fase de ejecución para identificar y gestionar contenedores comprometidos.

Volver

Newsletter

¿Quieres estar informado? Ya puedes suscribirte GRATIS a nuestra newsletter mensual