Las 4 fases para automatizar la gestión del cloud

El recorrido de automatización en el cloud de un profesional de seguridad

Si me encuentra en una conferencia, lo más probable es que me escuche decir que “la seguridad en el cloud comienza con la arquitectura y termina con la automatización”. Enseguida agrego lo importante que es adoptar una mentalidad cloud native, incluso cuando uno está empantanado con la realidad de una migración lift and shift poco elegante antes de que termine el contrato del centro de datos y se apaguen las luces. Aunque es una frase ingeniosa, no captura realmente cómo pasé de ser un profesional de seguridad de lo básico (firewalls y gestión de parches) a un cloud native de arquitectura y automatización. En lugar de predicar desde el púlpito, me resulta más útil describir mi recorrido personal y las conclusiones técnicas que fui obteniendo en el camino. Si usted es un profesional de seguridad, o alguien que intenta capacitar a un profesional de seguridad para el cloud, lo más probable es que termine en un camino muy similar.

Fase 1: automatización de configuraciones

Para mí todo comenzó hace unos nueve años, cuando me pidieron crear el primer programa de capacitación de la Cloud Security Alliance. Desde temprano me di cuenta de que necesitábamos laboratorios repetibles, que pudieran ejecutarse en cualquier parte del mundo, con estudiantes e instructores cuyas habilidades iban desde “desarrollador” hasta “auditor de papeleo”. En aquellos días, Amazon Web Services aún no había lanzado realmente IAM y las VPC eran solo redes privadas. Y conceptos como Infrastructure as Code apenas comenzaban a ser viables.

Así que ahí estaba yo, tratando de averiguar cómo construir un laboratorio práctico de stack de aplicaciones en el cloud para miles de estudiantes. De forma consistente, *y* pudiendo actualizarlo a medida que AWS avanzaba con su tecnología. En ese momento, crear tus propias AMI todavía era una tarea tediosa, pero entonces descubrí las maravillas de `cloud-init`. Un script simple que podía alojar en un bucket de S3, con dos pequeñas líneas que los estudiantes podían pegar en el campo User Data de sus instancias, lo que configuraba las instancias exactamente como se necesitaba al iniciarlas. Y cuando las actualizaciones de software rompían algo, solo tenía que actualizar ese script en la URL publicada, y cada nueva instancia usaría la nueva configuración: ¡magia! Si bien esto no ayudaba a parchear nada que ya estuviera en ejecución, me permitía mantener una buena experiencia de primera ejecución, de forma mucho más sencilla que actualizar y publicar nuevas AMI. Y, en un acto de absoluta imprudencia reputacional, todavía puede ver aquí en S3 una versión posterior de uno de ellos.

Mi primer paso fue `cloud-init`. Ya no es algo que utilice, pero fue revelador poder crear un script para un servidor completo y que todo funcionara, usando copiar y pegar y un único archivo alojado.

Fase 2: automatización de flujos de trabajo

Pero el siguiente paso tuvo mucho más impacto. Después de un par de años dictando capacitaciones prácticas y construyendo mis propias cargas de trabajo, empecé a jugar con la idea de Software Defined Security. Frente a mí tenía una abundancia de APIs de cloud, todas susurrándome “llámame” al oído. Empecé a buscar ejemplos y no encontré… nada. Ni siquiera Security Monkey se había publicado todavía.

Tenía una clase próxima para la conferencia de seguridad Black Hat, y decidí usarla como excusa para aprender Ruby y las APIs de AWS (a través del SDK de Ruby). Terminé escribiendo tres demostraciones:

• Una aplicación de respuesta a incidentes que ponía en cuarentena una instancia, analizaba todos sus metadatos, la bloqueaba usando AWS IAM, creaba imágenes de todo el almacenamiento y lanzaba un servidor de análisis forense listo para analizar las instantáneas adjuntas. Esto hacía en 3 segundos lo que antes me tomaba 30 minutos.
• Una pequeña aplicación que se conectaba a AWS y a Chef e identificaba todas las instancias que no ejecutaban Chef (servidores “no gestionados”). Un proceso que podía tomar semanas en un centro de datos tradicional.
• Otra aplicación que abría los grupos de seguridad a un escáner de Qualys, activaba un escaneo y cerraba el grupo de seguridad al terminar.

No había programado en Ruby antes, así que las tres tomaron unos dos meses de trabajo a tiempo parcial para ponerlas en marcha. Eran bastante simples, pero aprendí algunas lecciones valiosas.

• Gestionar las credenciales era crítico, y también dificultaba compartir el código y lograr que otros configuraran sus entornos correctamente. Extraer datos de archivos de configuración era… molesto. Especialmente para cosas como qué grupo de seguridad en qué región usar como grupo de cuarentena.
• Ruby funcionaba bien en mi sistema local, pero luego excedía los límites del servicio y tuve que insertar temporizadores de retardo cuando ejecutaba el código en una instancia en AWS. Los límites de servicio de las APIs no son sus amigos.
• Todo esto era realmente estático. Por más vistosas que fueran para las demostraciones, al final se reducía a ejecutar código manualmente desde un escritorio o una instancia. Eso no ha envejecido bien.

Empaqueté todo esto como “SecuritySquirrel”, y puede encontrar las versiones de 2014 en GitHub. Aunque no lo crea, esas ni siquiera son las originales que usé durante un par de años antes de publicarlas.

Fase 3: automatización del cloud en sí

Cuando AWS lanzó las Rules para CloudWatch, la mañana del sábado siguiente armé en unas 2 horas suficiente código Python para revertir cualquier cambio en un grupo de seguridad en un plazo de 10-15 segundos, incluidos filtros para acotar la defensa según las etiquetas, la VPC o quién solicitó el cambio. Puede descargar el código y las instrucciones, y a diferencia de mi código Ruby, este todavía funciona bastante bien para ser código de cloud de 3 años de antigüedad.

Desde esa primera demostración he construido una biblioteca de automatizaciones basadas en eventos que se ejecutan en Lambda, algunas de las cuales puede descargar. En ese paquete mi favorita es `identify_internet_facing_servers.py`, que, con fines de demostración, vinculé para que se active cuando hago clic en una versión IoT de un botón Amazon Dash. Así es, llevo en el bolsillo un botón Easy físico de verdad. Encuentra cualquier instancia con el puerto 22 abierto a Internet, y con un doble clic del botón puedo revocar las reglas, recibiendo un mensaje de texto en mi teléfono cuando todo está seguro y en orden.

Mi lección clave aquí fue inesperada. No fue que estas automatizaciones basadas en eventos reemplazaran mis flujos de trabajo basados en hosts, sino que cumplían un propósito diferente. Me di cuenta de que había pasado de construir flujos de trabajo para hacer las cosas más rápido a construir barreras de protección para mantener las cosas seguras en segundo plano. Ambos tienen un valor increíble.

Fase 4: automatizar todo

Mi trabajo más reciente se ha centrado en usar Jenkins e Infrastructure as Code (principalmente CloudFormation) para mejorar la seguridad. Esta combinación me permite automatizar la seguridad dentro de la propia infraestructura y las aplicaciones, y depender menos de herramientas externas.

Por ejemplo, publiqué un escáner de credenciales simple para ejecutar en Jenkins y encontrar cualquier clave de acceso almacenada incluso antes de iniciar la compilación. ¿Para qué esperar e intentar detectarlas más tarde? Luego escribí otros marcos de prueba que me permiten ejecutar prácticamente cualquier herramienta de evaluación que quiera en Jenkins, y hacer fallar las compilaciones cuando no superan alguna prueba de seguridad, como un escaneo de red (consejo profesional: Jenkins hará fallar una compilación si le envía cualquier código de salida distinto de 0 desde un script).

Volviendo al punto de partida, ahora dictamos la clase de capacitación usando plantillas de CloudFormation para construir todos los elementos del stack de aplicaciones, de modo que los estudiantes puedan concentrarse en agregar seguridad. Pasamos de construir servidores de capacitación consistentes a entornos de capacitación consistentes, con AMI personalizadas que podemos actualizar en minutos… a nivel global… con muy poco esfuerzo, y con todo el software preinstalado y listo para la configuración final.

Mi recorrido en el cloud comenzó hace unos nueve años y mi recorrido en automatización casi al mismo tiempo. Comencé construyendo cosas y luego intentando automatizar algunas partes, pero ahora parto del supuesto de la automatización. Mi trabajo más temprano se trataba de operaciones, pero hoy en día está casi todo enfocado en la seguridad. En disolver la carga operativa y permitir que las partes de mi mente dedicadas a la seguridad se concentren en lo que mejor hacen. En el camino también aprendí que no toda la automatización es igual; que hay lugar para las barreras de protección, los flujos de trabajo, la orquestación entre plataformas, la infraestructura como código y la automatización de pipelines. Todo esto ofrece hoy beneficios de seguridad casi inimaginables, pero todavía estamos muy al comienzo, cuando uno puede perder una semana solo por descifrar una API mal documentada.

Si usted trabaja en seguridad, es hora de mejorar su nivel de código. Si es desarrollador o trabaja en operaciones, es hora de mejorar su nivel de seguridad. Porque la lección más importante de todas es que los días de la seguridad como un paraguas terminaron, y los días de la seguridad integrada en el tejido ya están aquí.