Las mejores prácticas de seguridad para proteger los contenedores de DOCKER de TU aplicaciones
Un Problema de ciberseguridad puede causar un daño a la organizacion, por ejmplo la imagen de la empresa, la informacion de sus clientes y hasta se puede ver comprometida la economia de la compañia y de sus clientes, en resumen la ciberseguridad es IMPORTANTE y se debe prestar atencion a ella desde el inicio de la creacion del software y considerar hasta el mas pequeño de los objetos.
como dato importante se me es oportuno nombre lo siguiente:
cada año se pierde dinero por ataques, hay informes que hablan de millones de dolares en promedio anaual, y hay tres cosas que de no prestar atencion pueden potenciar que tu software sea vulnerable.
Falta de habilidades y capacitación en herramientas y prácticas de seguridad.
Falta de visibilidad y vulnerabilidades
Seguimiento continuo del estado actual de la seguridad
otro dato importante del cual se han escrito rios de tintas (o rios de bits) y es unos de los motivos de la creacion de este post:
Recientes encuestas dicen que las organizaciones usan plataformas en la nube y aproximadamente el 45% de sus computo esta en contenedores y/o CaaS (contendores como servicios) esto quiere decir que el uso de contenedores esta en aumento y por lo tanto, de no fomentar las buenas practicas en ellos se estaria aumentando las vulnerabilidades.
Los principales problemas identificados como una amenaza son:
Exposición de datos y malware
Vulnerabilidades de la aplicación
Autenticación débil o rota
Configuraciones incorrectas
Acceso incorrecto o con exceso de permisos
Amenazas internas
Fuga de credenciales
Puntos finales inseguros
En este artículo, repasaremos algunas de las mejores prácticas de seguridad de contenedores que podemos seguir e implementar para reducir los riesgos de seguridad en las cargas de trabajo en contenedores.
Las mejores prácticas de seguridad para proteger los contenedores de aplicaciones
Cuando creamos una imagen de contenedor, a menudo confiamos en la imagen semilla obtenida de registros públicos o privados populares. Tenga en cuenta que en la cadena de suministro de la producción de imágenes, alguien puede penetrar y arrojar un código malicioso que podría abrir las puertas a los atacantes.
Al crear la imagen del contenedor, utilice una fuente de imagen base reforzada de un editor de confianza conocido.
Elija aquellas imágenes que se publican con frecuencia con las últimas correcciones y parches de seguridad.
Use imágenes firmadas y etiquetadas (firme con notario o herramientas similares) y verifique la autenticidad de la imagen durante la extracción para detener los ataques de intermediarios.
igual que el punto anterior, los paquetes instalados también deben provenir de fuentes verificadas y confiables por la misma razón.
Lo que quiero decir con área de superficie es la cantidad de paquetes y bibliotecas instaladas en la imagen. El sentido común es que si la cantidad de objetos es menor, las posibilidades de tener vulnerabilidad también se reducen. Mantenga el tamaño de la imagen al mínimo para satisfacer los requisitos de la aplicación. Preferiblemente, tenga una sola aplicación en un contenedor de aplicaciones.
Elimine herramientas y software innecesarios como administradores de paquetes (por ejemplo, yum, apt), herramientas y clientes de red, shells de la imagen, netcat (se puede usar para crear shell inverso).
Utilice los Dockerfiles de varias etapas para eliminar los componentes de creación de software de las imágenes de producción.
No exponga puertos de red ni sockets innecesarios ni ejecute servicios no deseados (p. ej., demonio SSH) en el contenedor para reducir las amenazas.
Elija imágenes alpinas o imágenes temporales o un sistema operativo optimizado para contenedores en comparación con las imágenes completas del sistema operativo para la imagen base.
Tambien evita subir cosas como carpetas de dependencias que no se usen, es muy comun hacer una especie de build donde en modo produccion las dependenecias son transformadas y adjuntada al codigo pero existen carpetas donde aun quedas las fuentes como node_module, no las subas usa el doble stage de docker para hacer build en un sitio y correr en otro.
Todos los secretos deben mantenerse fuera de la imagen y del Dockerfile. Los secretos incluyen certificados SSL, contraseñas, tokens, claves API, etc., deben mantenerse fuera y deben montarse de forma segura a través del motor de orquestación de contenedores o el administrador de secretos externo. Herramientas como Hashicorp Vault, servicios de administración de secretos proporcionados por la nube como AWS Secrets Manager, secretos de Kubernetes, administración de secretos de Docker, CyberArk, etc. pueden mejorar la postura de seguridad.
A menudo, las empresas tienen sus propias imágenes “base” con software propietario y bibliotecas que no quieren distribuir en público. Asegúrese de que la imagen esté alojada en un registro seguro y confiable para evitar el acceso no autorizado.
Esta es la configuración incorrecta más común en la carga de trabajo en contenedores. Teniendo en cuenta los principios de los privilegios mínimos, cree un usuario de la aplicación y utilícelo para ejecutar el proceso de la aplicación dentro del contenedor.
¿Por qué no rootear?
La razón es que un proceso que se ejecuta en un contenedor es similar al proceso que se ejecuta en el sistema operativo host, excepto por el hecho de que tiene metadatos adicionales para identificar que es parte de un contenedor. Con UID y GID del usuario root en un contenedor, puede acceder y modificar los archivos escritos por root en la máquina host.
Nota importante: si no define ningún USUARIO en el Dockerfile, generalmente significa que el Contenedor se ejecutará con el usuario root.
Al diseñar CI/CD para la construcción y entrega de contenedores, incluya una solución de escaneo de imágenes para identificar vulnerabilidades (CVE) y no implemente imágenes explotables sin remediación. Se pueden utilizar herramientas como Clair, Synk, Anchore, AquaSec, Twistlock. Algunos de los registros de contenedores como AWS ECR, Quay.io están equipados con soluciones de escaneo, utilícelas.
AppArmor es un módulo de seguridad de Linux para proteger el sistema operativo y sus aplicaciones de las amenazas de seguridad. Docker proporciona un perfil predeterminado para permitir que el programa acceda a un conjunto limitado de recursos, como acceso a la red, capacidades del kernel y permisos de archivo, etc. Reduce la superficie de ataque potencial y proporciona una gran defensa en profundidad.
Por lo general, los contenedores registran todo en STDOUT, y estos registros se pierden una vez que se terminan, es importante transmitir de forma segura los registros a un sistema centralizado para auditoría y análisis forense futuros. También debemos asegurarnos de que este sistema de registro esté protegido y que no haya fugas de datos de los registros.
Incluso si implementa soluciones de escaneo de vulnerabilidades basadas en datos del repositorio y toma todas las precauciones necesarias, aún existe la posibilidad de ser víctima. Es importante monitorear y registrar continuamente el comportamiento de la aplicación para prevenir y detectar actividades maliciosas.
"No existe una solución milagrosa con la seguridad cibernética, una defensa en capas es la única defensa viable". – Investigación ICIT
Al implementar las mejores prácticas anteriores, puede dificultar que el atacante encuentre formas de explotar su sistema. Señalo algunas herramientas y referencias que se pueden usar para auditar y proteger los contenedores. La seguridad es un tema amplio.
Comentarios
Publicar un comentario