Por qué DevSecOps es crítico para los contenedores y Kubernetes



DevSecOps es un cambio grande y a veces difícil para las organizaciones. ¿La clave para el éxito? Da pequeños pasos.

DevOps ha permitido a las organizaciones aprovechar la automatización y la velocidad de implementación que proporcionan las tecnologías nativas de la nube, como los contenedores y Kubernetes. Sin embargo, si la seguridad no está estrechamente integrada en DevOps, la capacidad de las organizaciones para aprovechar al máximo el modelo nativo de la nube se ve severamente disminuida. Si esto le suena familiar, en el mejor de los casos, su empresa está obteniendo menos beneficios por su inversión en la nube y, en el peor de los casos, pone en riesgo al negocio y a los clientes.

De hecho, los ciclos de desarrollo rápidos y frecuentes de hoy exigen que la seguridad sea una parte integral y compartida del ciclo de vida completo de la aplicación: DevSecOps. Por ejemplo, se recomienda no parchear un contenedor en ejecución, sino reconstruir y volver a implementar siempre. Para hacerlo bien y a toda velocidad, las organizaciones deben utilizar pruebas de unidad y funcionales automatizadas, y deben integrar puertas de seguridad automatizadas.

De hecho, realmente no puede hacer el cambio a un verdadero modelo DevSecOps sin invertir en la automatización a lo largo de la infraestructura y el ciclo de vida de la aplicación. Por ejemplo, soluciones como los operadores Ansible y Kubernetes han permitido a las organizaciones agregar automatización a Kubernetes. ArgoCD es otra solución que está obteniendo cierta tracción actual al aplicar el modelo GitOps a las configuraciones de clúster de Kubernetes. (Después de todo, es tan importante administrar las configuraciones para su plataforma de aplicaciones como lo es para las propias aplicaciones).

No todas las herramientas de seguridad que las empresas están acostumbradas a usar funcionarán bien en este nuevo modelo. Los contenedores y Kubernetes han creado desafíos para las herramientas de seguridad tradicionales que no pueden adaptarse al grado de automatización y la velocidad de implementación que ofrecen estas y otras tecnologías nativas de la nube. Afortunadamente, existe un amplio ecosistema de soluciones nativas de contenedor / Kube disponibles, que van desde herramientas de análisis que se integran con la canalización de CI / CD hasta el tiempo de ejecución del contenedor y la seguridad de la purple de Kubernetes. En el futuro, los sistemas operativos optimizados para contenedores cambiarán la forma en que pensamos sobre la administración y seguridad del sistema operativo host.

Cultura y proceso
Pero DevSecOps no se trata solo de herramientas También se trata de cultura y proceso.

En muchas empresas, el papel de la seguridad todavía está aislado de un equipo específico en la etapa remaining de desarrollo. Este modelo es completamente contrario al modelo de desarrollo nativo de la nube, en el que existe una responsabilidad compartida por la seguridad (y todo lo demás). Si los equipos no pueden ver los beneficios de la colaboración y, en cambio, se adhieren a sus propios silos, puede indicar una falta de comunicación que seguramente conducirá a una tubería de desarrollo de aplicaciones debilitada, lo que puede conducir a una incapacidad para competir a medida que los clientes se van a otro lado por las aplicaciones y servicios que demandan.

Dicho esto, DevSecOps es un cambio grande y a veces difícil para las organizaciones. Los miembros del equipo deben comprender que esta dirección es respaldada por su administración y que será valioso para ellos y sus organizaciones colaborar y actualizar sus conjuntos de habilidades para las tecnologías que respaldan y permiten un desarrollo más dinámico y una tubería de implementación.

La clave para llegar allí es dar pequeños pasos. Es útil comenzar con un proyecto piloto: identifique un proyecto y un equipo interfuncional (desarrollo de aplicaciones, operaciones, seguridad) para implementar un proceso y una tubería DevSecOps. Identifique objetivos y casos de uso, y prepárese para iterar. Una vez que el equipo esté funcionando bien, documente la implementación y los resultados, incluido el valor comercial (como un tiempo de comercialización más rápido o la capacidad de abordar los problemas de seguridad por adelantado). En los laboratorios de innovación abierta de Crimson Hat, hemos visto organizaciones que han adoptado DevSecOps mejorar su tiempo de comercialización en un 81% (pasando de un ciclo de implementación de 38 semanas a un ciclo de 7 semanas), y una mejora del 97% en la confirmación de la funcionalidad es completo (de 4 semanas a 4.5 horas).

Una vez que el proyecto se haya completado con éxito, reclute colaboradores clave y entusiastas y patrocinadores ejecutivos en los equipos de aplicaciones, operaciones y seguridad para evangelizar y ayudar a expandir el modelo a otras partes de la organización. Pero, nuevamente, continúe planeando adaptarse. En la medida de lo posible, proporcione a los equipos la agencia para cumplir los objetivos de la manera que mejor funcione para ellos, al tiempo que proporciona orientación sobre las mejores prácticas y apoya la coherencia.

Si DevSecOps se pone en marcha de manera efectiva, cada equipo tendrá mucho que promover, especialmente su capacidad para permitir que la organización aproveche al máximo el poder de los modelos nativos de la nube en basic y los contenedores y Kubernetes específicamente.

Contenido relacionado:

Kirsten trabaja en estrecha colaboración con los muchos profesionales de seguridad de Crimson Hat en toda la cartera de ofertas de código abierto listas para empresas de Purple Hat. Kirsten es un profesional de gestión de program diversificado con más de 15 años de experiencia en el desarrollo de aplicaciones y … Ver biografía completa

Lectura recomendada:

Más suggestions





Enlace a la noticia first