Cómo persuadir a los ingenieros para que roten sus claves de acceso de AWS - Emptor

En los primeros días de Emptor, solíamos mantener múltiples usuarios de IAM para nosotros mismos, lo que eventualmente multiplicó nuestras responsabilidades para asegurar un número creciente de claves de acceso. Este es un problema común con múltiples cuentas de AWS, donde cada ingeniero tiene un usuario de IAM para cada cuenta que usa.

Mientras crecíamos nuestro negocio, también nos enfocamos en mejorar la seguridad de nuestros sistemas para garantizar la seguridad de los datos de nuestros clientes. Nuestro objetivo principal era mejorar la seguridad de nuestros entornos de producción, comenzando con una revisión exhaustiva de las mejores prácticas de seguridad de AWS. Notamos que la mayoría de los ingenieros a menudo tenían más permisos de los necesarios para su trabajo diario y que las claves de acceso a menudo no se rotaban durante muchos meses.

Hay varios riesgos asociados con no rotar las claves, incluido el posible daño a nuestros sistemas de producción si se comprometieran las claves de acceso de uno de nuestros ingenieros.

Gracias a herramientas como aws-vault, ahora podemos almacenar estas claves de forma segura en máquinas locales y garantizar la seguridad de autenticación para todos los ingenieros, pero esto nos dejó con un problema adicional: incluso cuando las claves de AWS se almacenan de forma segura, deben rotarse regularmente, y ni AWS ni aws-vault proporcionan una forma automatizada de hacer esto. Por lo tanto, se volvió importante para nosotros encontrar una manera de hacer que los ingenieros roten sus claves de AWS de manera regular. Para lograr esto, durante una de nuestras reuniones diarias, desarrollamos las siguientes reglas:

Los ingenieros deben tener solo un usuario de IAM y pueden asumir roles de IAM según sea necesario para obtener diferentes conjuntos de permisos en diferentes cuentas.
El conjunto de permisos predeterminado de los ingenieros solo debe permitirles realizar cambios en su propio usuario de IAM (cambiar la contraseña, crear nuevas claves de acceso, configurar un dispositivo MFA, etc.).
No se debe permitir que los ingenieros asuman roles de IAM a menos que configuren un dispositivo MFA.
Los ingenieros no deben tener más de un par de claves de acceso habilitadas en cualquier momento.
Los ingenieros deben rotar sus claves de acceso y la contraseña de la consola de administración de AWS cada 90 días.

Pudimos implementar la mayoría de estas condiciones con la ayuda de las funciones existentes de IAM, excepto el requisito de hacer cumplir una política de caducidad de 90 días para las claves de acceso. Como teníamos un equipo de ingeniería pequeño, nuestra primera solución para hacer cumplir esta condición en particular fue recordar a los ingenieros durante algunas reuniones cada mes. Funcionó bien durante varios meses, pero no escaló a medida que aumentaba el número de equipos y se unían más y más ingenieros a Emptor. Luego decidimos automatizar este procedimiento desarrollando una herramienta interna que llamamos AWS Monitor.

Para construir este sistema, lo primero que necesitábamos hacer era etiquetar cada usuario de IAM con datos útiles, para que AWS Monitor pudiera discernir quién o qué está usando sus credenciales y notificar al propietario sobre los próximos vencimientos de sus claves de acceso. Comenzamos con las siguientes etiquetas, que han resultado ser muy útiles:

type: Esta etiqueta nos ayudó a diferenciar entre usuarios de IAM para ingenieros (type=engineer) y máquinas (type=machine).
slack-id: Esta etiqueta nos ayudó a identificar la cuenta de Slack del ingeniero al que pertenece ese usuario de IAM, para que podamos enviarles notificaciones privadas a través de nuestro sistema.
full-name: Esta etiqueta opcional nos ayudó a mejorar la interfaz de usuario de la consola de AWS. Dado que la consola no menciona el nombre de la persona que es propietaria del usuario de IAM, agregarla a una etiqueta facilita la búsqueda de un usuario específico e identificar a los propietarios de las cuentas durante una auditoría.

Una vez que pudimos diferenciar entre los usuarios de IAM, creamos una aplicación de Slack para enviar mensajes de notificación privados a los ingenieros y construimos una aplicación sin servidor que se ejecuta todos los días para verificar la antigüedad de las claves de acceso de cada usuario de IAM en todas nuestras cuentas de AWS. Luego notifica al ingeniero relevante tres veces en Slack, usando su ID de Slack que almacenamos como etiqueta, una vez que sus claves de acceso hayan alcanzado las edades de 76 días, 81 días y 86 días. En el día 91, desactiva automáticamente sus claves de acceso.

También enviamos los mismos mensajes a un canal de Slack donde el equipo de infraestructura puede monitorear la caducidad y rotación de las claves de acceso con consistencia. Este sistema de monitoreo también notifica al equipo cuando se crea un nuevo par de claves de acceso, para que podamos verificar si estas claves de acceso fueron creadas realmente por uno de los ingenieros de Emptor o por un usuario no autorizado. ¿Genial, verdad?

Este sistema nos ha permitido monitorear todos nuestros usuarios de IAM, alentar a nuestros ingenieros a practicar la rotación frecuente de claves de acceso y auditar de manera eficiente la edad y el uso de todas nuestras claves de acceso. Es una pequeña herramienta que nos llevó solo unos días construir, pero nos ofrece información invaluable sobre el aspecto más vulnerable de AWS. Nuestro próximo objetivo es explorar el servicio AWS SSO. Creemos que puede proporcionarnos un conjunto de funciones que nos permitirán dejar de usar usuarios de IAM indefinidamente.

Si disfrutas leyendo sobre nuestras experiencias con AWS, no olvides suscribirte a nuestro blog.

¡Feliz AWS-ing!