Los contenedores revolucionaron el proceso de desarrollo, actuando como piedra angular para las iniciativas DevOps, pero los contenedores conllevan riesgos de seguridad complejos que no siempre son obvios. Las organizaciones que no mitigan estos riesgos son vulnerables a los ataques. <\/p>\n
En este art\u00edculo, describimos c\u00f3mo los contenedores contribuyeron al desarrollo \u00e1gil, qu\u00e9 riesgos de seguridad \u00fanicos aportan los contenedores y qu\u00e9 pueden hacer las organizaciones para proteger las cargas de trabajo en contenedores, yendo m\u00e1s all\u00e1 de DevOps para lograr DevSecOps<\/em>.<\/p>\n Los contenedores son, en muchos sentidos, la evoluci\u00f3n de la virtualizaci\u00f3n. El objetivo era acelerar el proceso de desarrollo, creando una ruta m\u00e1s \u00e1gil desde el desarrollo hasta la prueba y la implementaci\u00f3n; de todos modos, un m\u00e9todo que es m\u00e1s liviano que el uso de m\u00e1quinas virtuales completas.<\/p>\n El n\u00facleo de este problema es la compatibilidad de las aplicaciones, ya que las aplicaciones requieren ciertas versiones de bibliotecas, lo que podr\u00eda entrar en conflicto con los requisitos de otras aplicaciones. Los contenedores solucionaron este problema y se vincularon bien con los procesos de desarrollo y la infraestructura de administraci\u00f3n que impulsa estos procesos.<\/p>\n Los contenedores hacen su trabajo al llevar la virtualizaci\u00f3n al siguiente nivel. La virtualizaci\u00f3n abstrae la capa de hardware, mientras que los contenedores abstraen la capa del sistema operativo, esencialmente virtualizando el rol del sistema operativo. La creaci\u00f3n de contenedores funciona al empaquetar aplicaciones en “contenedores” que incluyen todas las bibliotecas necesarias para que una aplicaci\u00f3n funcione, mientras mantiene las aplicaciones sin conocimiento entre s\u00ed, ya que cada aplicaci\u00f3n cree que tiene el sistema operativo para s\u00ed misma.<\/p>\n Funcionalmente, los contenedores son bastante simples: un contenedor es solo un archivo de texto con una descripci\u00f3n que describe qu\u00e9 componentes deben incluirse en una instancia. Esta simplicidad y la naturaleza m\u00e1s liviana de un contenedor facilitan el uso de herramientas de automatizaci\u00f3n (orquestaci\u00f3n) para la implementaci\u00f3n a lo largo del ciclo de vida del desarrollo.<\/p>\n Los contenedores tienen el poder de aumentar significativamente la eficiencia del desarrollo, actuando como las claves que desbloquean DevOps. Esa es probablemente una de las principales razones por las que los contenedores se han popularizado tanto, y Gartner estima que para 2023, El 70% de las organizaciones ejecutar\u00e1n cargas de trabajo en contenedores<\/a>. <\/p>\n El proceso de desarrollo, prueba e implementaci\u00f3n de aplicaciones sol\u00eda estar lleno de obst\u00e1culos, con un ir y venir constante entre los desarrolladores y los equipos que cuidan la infraestructura. Hoy, gracias a los contenedores, los desarrolladores pueden crear y probar en un entorno que funciona y simplemente enviar el c\u00f3digo terminado junto con una especificaci\u00f3n que define ese entorno.<\/p>\n En el lado operativo, los equipos simplemente ejecutan esta especificaci\u00f3n para crear un entorno coincidente que est\u00e9 listo para usar. “S\u00ed, pero funciona en mi m\u00e1quina…” nunca ayud\u00f3 a solucionar el problema, pero hoy, esa es una expresi\u00f3n que los desarrolladores ya no necesitan usar porque no hay problemas ambientales para depurar.<\/p>\n Entonces, s\u00ed, DevOps significa desarrollo r\u00e1pido. Pero falta un componente: la seguridad. Esta es la raz\u00f3n por la que escuchamos cada vez m\u00e1s acerca de DevSecOps a medida que evoluciona de DevOps porque los desarrolladores han notado que el modelo DevOps por s\u00ed solo no aborda suficientemente las preocupaciones de seguridad.<\/p>\n Los contenedores simplifican el proceso de desarrollo pero introducen complejidad en la imagen de seguridad. Cuando empaqueta un entorno operativo completo en un contenedor solo para distribuirlo ampliamente, tambi\u00e9n aumenta la superficie de ataque y abre la puerta a diferentes vectores de ataque. Cualquier biblioteca vulnerable empaquetada con el contenedor distribuir\u00e1 estas vulnerabilidades en innumerables cargas de trabajo.<\/p>\n Hay varios riesgos. Uno es un “ataque de la cadena de suministro” en el que un actor mal\u00e9volo monta un ataque no interfiriendo con su aplicaci\u00f3n, sino modificando uno de los paquetes o componentes que se suministran con su aplicaci\u00f3n. Por lo tanto, los equipos que se ocupan de los esfuerzos de desarrollo deben evaluar la aplicaci\u00f3n que est\u00e1n desarrollando y cada biblioteca incorporada como una dependencia por la configuraci\u00f3n del contenedor.<\/p>\n Los riesgos para la seguridad de los contenedores tambi\u00e9n involucran las herramientas que habilitan los contenedores, desde Dockers hasta herramientas de orquestaci\u00f3n como Kubernetes, ya que estas herramientas necesitan ser monitoreadas y protegidas. Por ejemplo, no debe permitir que los administradores de sistemas ejecuten contenedores Docker como ra\u00edz. Del mismo modo, debe vigilar de cerca los registros de sus contenedores para asegurarse de que no se vean comprometidos.<\/p>\n Algunos de los riesgos de seguridad relacionados con los contenedores son menos visibles que otros. Cada contenedor necesita acceso a un kernel; despu\u00e9s de todo, los contenedores son solo un tipo de aislamiento de proceso avanzado. Pero es f\u00e1cil pasar por alto el hecho de que todos los contenedores se basan en el mismo kernel; no importa que las aplicaciones dentro de los contenedores est\u00e9n separadas entre s\u00ed. <\/p>\n El kernel que ven las aplicaciones en un contenedor es el mismo que el kernel en el que se basa el host para operar. Trae un par de problemas. Si el n\u00facleo del host que admite el contenedor es vulnerable a un exploit, esta vulnerabilidad puede aprovecharse iniciando un ataque desde una aplicaci\u00f3n dentro de un contenedor.<\/p>\n Por lo tanto, el hecho de que todos los contenedores del host compartan el kernel significa que un kernel defectuoso debe parchearse r\u00e1pidamente, o todos los contenedores pueden verse afectados r\u00e1pidamente por la vulnerabilidad.<\/p>\n Mantener actualizado el kernel del host es, por lo tanto, un paso importante para garantizar operaciones de contenedores seguras. Y no es solo el kernel el que necesita parches, los parches deben aplicarse a las bibliotecas extra\u00eddas por un contenedor. Pero, como sabemos, parchear constantemente es m\u00e1s f\u00e1cil decirlo que hacerlo. Probablemente por eso un estudio encontr\u00f3 que el 75% de los contenedores analizados conten\u00edan una vulnerabilidad<\/a> que se clasifica como cr\u00edtico o de alto riesgo.<\/p>\n Estas vulnerabilidades pueden provocar, por ejemplo, ataques de ruptura en los que un atacante conf\u00eda en una biblioteca defectuosa dentro de un contenedor para poder ejecutar c\u00f3digo fuera del contenedor. Al violar un contenedor, el atacante puede eventualmente llegar a su objetivo previsto, ya sea el sistema host o una aplicaci\u00f3n en otro contenedor.<\/p>\n En el contexto de los contenedores, mantener bibliotecas seguras puede ser un verdadero dolor de cabeza: alguien necesita rastrear nuevas vulnerabilidades, as\u00ed como lo que se ha parcheado y lo que no. El proceso es laborioso, pero tambi\u00e9n requiere habilidades especializadas, algo que su organizaci\u00f3n necesitar\u00eda adquirir si a\u00fan no las tiene.<\/p>\n Dado el valor de la aplicaci\u00f3n regular y consistente de parches, esas razones no deber\u00edan ser suficientes para causar el tipo de rutinas de parcheo impredecibles que vemos, pero, particularmente cuando se piensa en el kernel del sistema operativo, la interrupci\u00f3n de los reinicios necesarios y el asociado. la necesidad de mantener ventanas de tiempo de inactividad puede retrasar significativamente la aplicaci\u00f3n de parches. Parches de kernel en vivo<\/a> ayuda a mitigar este problema, pero a\u00fan no lo implementan todas las organizaciones.<\/p>\n Es com\u00fan que la tecnolog\u00eda de punta introduzca nuevas complicaciones en lo que respecta a la seguridad de la informaci\u00f3n. Las nuevas herramientas com\u00fanmente conducen a exploits nuevos y novedosos. Eso tambi\u00e9n es cierto para los contenedores y, si bien no socava el valor general del uso de contenedores en sus cargas de trabajo, s\u00ed significa que debe estar atento a los riesgos que plantean los contenedores.<\/p>\n Educar a sus desarrolladores y administradores de sistemas sobre las fallas comunes en la seguridad de los contenedores y las mejores pr\u00e1cticas que mitigan estas fallas es un comienzo. Parchar<\/a> es otro aspecto importante. Como siempre, implementar los pasos correctos para mitigar las fallas de seguridad cibern\u00e9tica ayudar\u00e1 a proteger su organizaci\u00f3n y permitir\u00e1 que su equipo se beneficie de esa tecnolog\u00eda de vanguardia sin sufrir noches de insomnio.<\/p>\n <\/p>\n<\/div>\n\u00bfPor qu\u00e9 los contenedores se hicieron populares tan r\u00e1pido?<\/h2>\n
DevOps para ganar… pero la seguridad tambi\u00e9n importa<\/h2>\n
Los contenedores introducen varios riesgos de seguridad<\/h2>\n
La seguridad del kernel en el centro de la seguridad de los contenedores<\/h2>\n
Una vez m\u00e1s, se trata de parchear<\/h2>\n
Incluya siempre objetivos de seguridad en sus operaciones de contenedores<\/h2>\n