Integración de la seguridad en DevOps: los principios fundamentales son cruciales
Las demandas cambiantes de los consumidores plantearon un serio desafío para la industria de TI; impulsó a las empresas a intercambiar ideas sobre la entrega rápida de productos.
Esta demanda eventualmente dio lugar a la demanda de colaboración entre los equipos de Desarrollo (Dev) y Operaciones (Ops), dando la bienvenida a la tendencia DevOps.
Como resultado, todo comenzó a progresar con mayor desarrollo, colaboración mejorada, pruebas avanzadas, alta productividad y tiempo de comercialización minimizado.
Sin embargo, el aspecto de «seguridad» siguió siendo un desafío para lograr el éxito de DevOps. De hecho, un mecanismo de entrega acelerado planteó la cuestión de si “la seguridad se estaba quedando atrás”.
Ahí es donde la integración de la seguridad se convirtió en el punto de discusión con preguntas como:
- ¿Dónde integran la seguridad en la cadena de procesos? Los modelos de TI tradicionales colocaban la seguridad al final, separándola del resto de la cadena de procesos. Esto se convirtió en una tarea tediosa cuando se detectó cualquier problema en el control de seguridad y los equipos de desarrollo o prueba tuvieron que volver a verificarlo. El proceso consumió tiempo y recursos, lo que finalmente repercutió en el tiempo de lanzamiento o comercialización.
- ¿Quién asumirá la responsabilidad? ¿Desarrolladores, operaciones, DevSecOps o cualquier otro equipo de seguridad dedicado? Preocupadas por los retrasos derivados de los modelos tradicionales de seguridad de TI, las empresas decidieron que la seguridad fuera una parte integral de toda la cadena de procesos.
- ¿Hay alguna herramienta para eso? El siguiente en orden fue la búsqueda de herramientas dedicadas o de apoyo al mecanismo de seguridad en la cadena de procesos.
- Por encima de todo, ¿quién es el actor clave? ¿Personas o tecnología? Veinticuatro por ciento de los líderes empresariales de TI encuestados bajo el Informe de adopción de contenedores de 2019 digamos que la seguridad de las aplicaciones es responsabilidad de los equipos asociados o incluidos en DevSecOps. Mientras que el 47 por ciento de ellos siente que esta es responsabilidad exclusiva de los equipos de DevSecOps, el 57 por ciento de ellos en roles de seguridad cree que los equipos centrales de ‘Seguridad’ son las partes interesadas responsables.
Más allá de estas preguntas que tienen respuestas, la implementación de la seguridad en DevOps carece de una comprensión básica.
Aquí hay ocho requisitos previos clave y puntos de la lista de verificación que son clave para una integración de seguridad exitosa en el proceso DevOps:
1. La seguridad debe estar centrada en la aplicación.
Esto es crucial cuando se trata de la nube, especialmente la ‘nube híbrida’, donde la capa de red se abstrae y le da el control de seguridad de la infraestructura al proveedor de servicios. Recuerde que las aplicaciones son algo que representa y ejecuta sus operaciones orientadas a clientes y socios. Por lo tanto, la creación de un mecanismo de seguridad centrado en la aplicación es muy importante teniendo en cuenta el volumen creciente de aplicaciones, la frecuencia de actualizaciones/cambios en las aplicaciones existentes, una mayor conectividad que involucra a múltiples socios en toda la empresa y más.
2. La seguridad debe ser precisa.
Es posible que no tenga tiempo para volver a verificar cuando publique miles de códigos de forma regular. Una vez hecho esto, no debería exigir una nueva verificación. Esto se logra al cultivar la conciencia de seguridad en toda la cadena de procesos y en cada acción que toman los equipos. Todos los equipos involucrados deben ser conscientes de las posibles amenazas a la seguridad. Haga cumplir políticas estrictas para una implementación efectiva si es necesario, pero asegúrese de no aumentar las complejidades.
3. La seguridad debe quedar registrada.
Esto ayuda a comprender o realizar un seguimiento de los gastos de la organización en infraestructura de seguridad, en su conjunto o en función de la versión. Un plan de gestión de programas perfecto ayuda a lograr este objetivo al garantizar que la seguridad esté en su lugar y que todas las especificaciones requeridas estén perfectamente documentadas y cumplidas.
4. La seguridad debe ser personalizable o personalizada.
Cada microservicio o aplicación no puede ser igual y tiene su propio conjunto de características. Los equipos deben comprender claramente las excepciones y las medidas necesarias que se deben tomar. Trate de mantenerlo simple, directo y orientado al proceso.
5. La seguridad debe ser de alta velocidad.
Sin embargo, no debe estar en condiciones de hacerse cargo o ralentizar el proceso de front-end en una cadena de procesos de DevOps.
6. La seguridad debe ser escalable.
La ‘seguridad como código’ funciona bien para impulsar la innovación. Debe ser lo suficientemente escalable para hacer frente a errores inesperados/repentinos que pueden surgir del proceso de desarrollo acelerado. La ‘seguridad como código’ funciona bien para impulsar la innovación.
7. La seguridad no debería ser un obstáculo para los desarrolladores.
De hecho, debería respaldar los esfuerzos de desarrollo a medida que los equipos de desarrollo avanzan en la cadena de procesos.
8. La seguridad debe ser un factor bien equilibrado.
No puede ser todo o nada y ni siquiera debería ser un problema para la cadena de procesos existente. El trabajo central de la seguridad es la gestión eficaz de los riesgos. Es por eso que los equipos de seguridad deben integrarse en el proceso DevOps.
Soluciones como DevSecOps allanaron el camino para la seguridad de DevOps al ofrecer el alcance debido para la integración de extremo a extremo. Sin embargo, los requisitos previos anteriores son clave para diseñar una estrategia de seguridad basada en DevOps exitosa: una estrategia de seguridad efectiva respaldada por fundamentos sólidos siempre es favorable.