De DevOps a DevSecOps
La responsabilidad de que el producto final desplegado funcione correctamente se comparte entre el departamento de desarrollo y el de operaciones, esta es la filosofía que define la filosofía DevOps. DevSecOps sólo añade una capa más a la ecuación, la de la seguridad. La gran diferencia reside en que la comprobación de seguridad del código de la aplicación, o cualquier otro componente de la aplicación (paquetes, librerías, etc) se realiza desde el inicio de todo el proceso de despliegue, no una vez completado este. Es un elemento más de todo workflow del ciclo de vida de la aplicación, integrado junto con otros tests automatizados, no un elemento externo que se ejecuta bajo demanda de vez en cuando. 
Integrar tests de seguridad en tu CI/CD
Para integrar la capa de seguridad en ese workflow de despliegue desde el inicio tenemos que realizarlo en el la herramienta de CI/CD que estemos utilizando, en este caso usaremos de ejemplo la nativa de GCP, Cloud Build. Hay dos etapas del esquema anterior en las que podemos aplicar tests de seguridad dentro del pipeline de despliegues automáticos, de verificación de código (con herramientas como SonarQube) antes de que ejecute el trigger de creación del contenedor o a la hora de crear los artefactos que se van a desplegar, en este caso contenedores. En esta última etapa es donde entra en juego el Container Analysis de GCP. Esta herramienta, que se puede utilizar bajo demanda o integrar directamente en tu pipeline de CI/CD, analiza el contenedor creado y guardado en Container Registry en busca de vulnerabilidades sacando un listado de ellas categorizado por gravedad. 
En el caso de la integración con el pipeline de CI/CD habría que configurar un attestation para que el servicio de Binary Authorization de Google marque la build como fallida en caso de descubrirse una vulnerabilidad que no cumpla las policy definida en ese attestation, evitando así su despliegue y sirviendo como alerta para obligar a parchear esas vulnerabilidades cuanto antes. Container Analysis también posee una API para que podamos sacar toda la información sobre las vulnerabilidades en las diferentes imágenes de nuestro registry para integrar esta información con otras herramientas o aplicaciones caseras. También se puede utilizar Pub/Sub para recibir alertas en el caso de que se descubra una nueva vulnerabilidad en alguno de los contenedores que teníamos en el registry.
Visibilidad
Otro aspecto muy importante para que la seguridad sea una preocupación compartida por todos los departamentos técnicos es que tengan acceso sin ningún tipo de trabas las herramientas de monitorización y logs. La visibilidad de las trazas y métricas son vitales a la hora de dar una pista sobre un posible mal funcionamiento de la aplicación o de un ataque. Los logs son el primer recurso que nos puede ayudar a detectar que alguien le está buscando las cosquillas a nuestra aplicación. Configurar correctamente los logs y los permisos (Logs Viewer en IAM) para que los diferentes departamentos puedan revisarlos y explotarlos agiliza enormemente la resolución de problemas y ayuda a tomar medidas preventivas ante posibles ataques. Las métricas de monitorización son otro indicador de un posible mal funcionamiento de la aplicación o incluso otros ataques como DDOS. Evidentemente los logs del CI/CD, deben de ser consultables en tiempo real por los diferentes departamentos implicados para seguir en directo el desarrollo del pipeline y corregir los fallos detectados en los diferentes tests integrados en la mayor brevedad posible. En definitiva, que ningún departamento tenga que pedir por ticket o mail las trazas o métricas de un fallo de aplicación o comportamiento sospechoso, que sean independientes y por ello más eficientes.
No olvidar lo esencial
Todas estas medidas, automatizaciones y trazas no deben hacer que olvidemos las buenas prácticas de seguridad aplicables a todas las capas de nuestro entorno, desde las infraestructuras, pasando por las redes, la autenticación y permisos. Siempre usar el modelo del mínimo privilegio posible y reducir la superficie de ataque en la medida de lo posible.
Conclusión
Hemos hablado de varias herramientas para implementar una filosofía DevSecOps en GCP, pero realmente las tecnologías o providers que se usen son lo de menos, lo importante es el cambio de mentalidad y el deseo de mejorar e integrar la seguridad de nuestras aplicaciones desde el inicio de su ciclo de vida, haciendo así de la seguridad una parte integral de la aplicación, no un chequeo que se hace “cuando esté funcionando y haya tiempo”. Las herramientas mencionadas, y todas las alternativas que hay en el mercado, han simplificado mucho esta integración, con lo que ya no tenemos excusa para no implementar un pipeline de despliegue que garantice que las aplicaciones que desplegamos no sean seguras.
Configuración de cookies