Chips VS amenazas a la tecnología de contenedorización

El uso de contenedores para el desarrollo y despliegue de software se ha convertido durante mucho tiempo en una práctica estándar. Muchos desarrolladores apreciaron la capacidad de proporcionar fácilmente al programa un entorno estándar independiente del host en el que se ejecuta, cambiar rápidamente la configuración, agregar o cambiar algunos componentes en el contenedor. Pero esto es solo una pequeña parte de todos los chips que ofrece la tecnología de contenedorización.



Como siempre, el desarrollo de la tecnología y el crecimiento de su popularidad van acompañados de la identificación de varios métodos de uso no estándar, incluido el malware. En este artículo, también veremos los riesgos de seguridad del proceso de desarrollo asociado con el uso de contenedores, y hablaremos sobre por qué los procesos DevOps deberían transformarse en DevSecOps.

Para empezar, por qué los contenedores ganan la simpatía de los desarrolladores y cómo el uso de la contenedorización cambia el desarrollo en su conjunto.

Papas fritas

Ligereza

En comparación con las máquinas virtuales y los servidores "de hierro", los contenedores son completamente poco exigentes con los recursos. Esto le permite ejecutar significativamente más contenedores en una sola máquina que las máquinas virtuales. El desarrollador puede incluso ejecutar componentes de la aplicación en su computadora en forma de microservicios en contenedores y no tiene que quedarse dormido esperando la respuesta del sistema. Debido al hecho de que los contenedores comparten el núcleo del sistema, su inicio y detención son mucho más rápidos que reiniciar la máquina virtual.

Aislamiento

A pesar de compartir el núcleo, la aplicación en el contenedor se ejecuta aisladamente de otras partes del sistema y las aplicaciones. Esto significa que un error en la aplicación afectará solo a un contenedor específico.

El uso de contenedores durante el desarrollo le permite alejarse del conflicto eterno de los desarrolladores y administradores de sistemas por los privilegios. El contenedor separa de forma segura la aplicación del sistema, por lo que el programador puede permitirse cualquier experimento sin temor a destruir el sistema operativo.

Portabilidad

Cada aplicación se ejecuta en su propia instancia de contenedor con sus propios archivos de configuración. Esto elimina el dolor de cabeza asociado con el movimiento de la aplicación entre hosts: todo lo necesario para el trabajo se almacena dentro del contenedor y se transfiere junto con el resto de los componentes de la aplicación.

Repositorios de contenedores

El advenimiento del estándar Open Container Initiative ha permitido crear bibliotecas públicas de imágenes de contenedores y crear un poderoso ecosistema que combina motores de contenedores, plataformas en la nube y herramientas para administrar contenedores, controles de seguridad y otras tareas.

Automatización

El uso de contenedores le permite construir cadenas completamente automatizadas de integración continua-implementación de aplicaciones (CI / CD), en las cuales la parte "manual" será principalmente la escritura de código. Las pruebas, la verificación de la calidad del código, el empaque de la aplicación en una imagen Docker, la colocación de la imagen en Docker Hub y su implementación en el host para su ejecución se pueden realizar sin intervención humana.

Amenazas de contenedores

Por supuesto, con todas sus ventajas, los contenedores tienen varias desventajas. Por ejemplo, estos son problemas con el rendimiento de las aplicaciones de uso intensivo de recursos y la portabilidad limitada de las imágenes creadas para diversas arquitecturas. Pero además de los problemas tecnológicos, los contenedores tienen problemas de seguridad.


Kernel Sharing

Como siempre, las desventajas son la otra cara de las ventajas. El uso compartido del kernel reduce la redundancia de contenedores en comparación con las máquinas virtuales, pero el mayor número de llamadas al sistema permitidas hace que la barrera de seguridad sea más delgada y la explotación de las vulnerabilidades del kernel permite atacar todos los contenedores a la vez. ¿Cómo no recordar los sensacionales ataques de Spectre y Meltdown , que le permiten leer la memoria de otro proceso o núcleo desde el espacio del usuario?

Repositorios públicos

La presencia de registros públicos con imágenes proporciona una amplia selección de "envoltorios" para contenedores, pero crea amenazas adicionales, porque de forma predeterminada el servidor de registro es de confianza. Si los atacantes logran modificar las imágenes base con bibliotecas maliciosas, los cambios se distribuirán automáticamente a todos los servidores que almacenan en caché esta imagen base, y todos los contenedores que utilicen la biblioteca adquirirán automáticamente funciones maliciosas.

Ejemplos

• En junio de 2018, se eliminaron 17 contenedores con código malicioso del portal Docker Hub , pero antes de eso, en el transcurso de varios meses, lograron descargarse más de un millón de veces.
• En septiembre de 2018, se publicó un ejemplo de un ataque a los paquetes de instalación de Python en GitHub , durante el cual el archivo setup.py se modificó para ejecutar código malicioso al instalar el paquete. Como, por regla general, este archivo se usa solo para agregar un módulo, pocas personas verifican su contenido .
• En octubre de 2018, se publicó información sobre 12 bibliotecas maliciosas cargadas en el directorio PyPi . Las bibliotecas contenían código para recopilar datos, mantener la presencia en el host infectado, lanzar un shell inverso y reemplazar las direcciones de billetera de Bitcoin con la dirección de un atacante .
• En noviembre de 2018, una de las dependencias de la biblioteca Event-Stream utilizada en muchos proyectos grandes detectó código malicioso diseñado para robar criptomonedas y realizar ataques a servicios relacionados con herramientas virtuales. Event-Stream es una biblioteca popular con aproximadamente 2 millones de descargas diarias desde el repositorio de NPM.
• En enero de 2019, se informó una vulnerabilidad crítica en el módulo pickle de la popular biblioteca NumPy Python , con la que puede obtener la capacidad de ejecutar código de forma remota.

Por lo tanto, una biblioteca maliciosa es suficiente para comprometer la aplicación. Por supuesto, las vulnerabilidades y las funciones maliciosas en las bibliotecas populares no son un problema de los contenedores como tales, sino una tecnología que garantiza la rápida propagación de los cambios en las imágenes.

Recomendaciones

Obviamente, el proceso de desarrollo moderno requiere un nuevo enfoque, un enfoque en el que la seguridad se integrará en la cadena CI / CD, convirtiendo DevOps en DevSecOps.



Según Gartner, en 2019

• Más del 70% de los procesos de desarrollo corporativo incluirán monitoreo automatizado de vulnerabilidad y configuración de componentes de código abierto y paquetes comerciales.
• más del 50% de los procesos de CI / CD contendrán controles obligatorios de seguridad de código incorporado;
• Más del 60% de las empresas utilizarán el control de versiones y los controles de automatización de infraestructura en su desarrollo.

Considere algunos de los componentes que deben estar presentes en el proceso para que la palabra "Sec" en su nombre no sea una frase vacía.

Integración de controles en todos los procesos.

Debe haber una verificación de seguridad en todas las etapas del proceso de desarrollo, desde la creación del código hasta su contenedorización e implementación.

Automatización de Auditoría de Seguridad

Es necesario por dos razones:

1. Esto reducirá los errores de administración y la configuración incorrecta.
2. Los profesionales de seguridad no tendrán que verificar manualmente el código y cambiar la configuración.

API para funciones de seguridad

La implementación de dicha funcionalidad requiere que el sistema de seguridad proporcione una API para acceder a todas las funciones. Por lo tanto, los desarrolladores no solo pueden usar el sistema para la verificación, sino también implementar las llamadas apropiadas en el código.

Control de acceso basado en roles

Los diferentes profesionales de seguridad necesitan diferentes niveles de acceso a los mecanismos de verificación, dependiendo de su función, ya que es necesario que los desarrolladores no puedan cambiar la configuración de seguridad, pero no sean responsables de las amenazas penetradas.

Docker Registry API Compatibility

Idealmente, la protección debería permitir el escaneo de imágenes Docker en cualquier registro que admita la API Docker Registry V2 para garantizar la compatibilidad con todos los registros populares.

Protección migratoria

Para los usuarios corporativos, un momento peligroso es la transición de una arquitectura monolítica a una de microservicios. Es importante que las funciones de seguridad estén integradas en los procesos de integración, proporcionando protección en modo automático.

Un ejemplo de una solución protectora es el Deep Security Smart Check de Trend Micro, que escanea continuamente imágenes automáticamente, identifica vulnerabilidades y malware. Smart Check es compatible con Docker Trusted Registry, Amazon Elastic Container Registry, Azure Container Registry y las plataformas de contenedores de Google Container Registry. Además, Trend Micro se integra con los principales sistemas SIEM y herramientas de orquestación como Jenkins, Kubernetes, SumoLogic, Splunk.

Una característica importante de Smart Check es su cumplimiento con todos los requisitos reglamentarios en términos de verificación de vulnerabilidad crítica y registro de eventos.

La implementación de la seguridad de contenedores en los procesos DevOps en las primeras etapas de desarrollo antes de lanzar aplicaciones permitirá el desarrollo de software más confiable y productivo, así como

• Detecta malware y bibliotecas.
• Identificar vulnerabilidades.
• Corrija los errores antes de que las imágenes se transfieran a las herramientas de orquestación (por ejemplo, Kubernetes).
• Evite que el código malicioso ejecute e implemente software vulnerable.