A medida que Pomelo continúa creciendo, se ha vuelto crucial gestionar la seguridad de los accesos a nuestra plataforma para los equipos de tecnología. En este artículo, exploramos cómo la implementación de accesos temporales puede aumentar el nivel de seguridad y cómo hemos aplicado con éxito este enfoque en AWS, mejorando significativamente la gestión de incidentes y cambios.

Un poco de teoría para comenzar

Oportunidades de mejora o desventajas del modelo tradicional

Dada la naturaleza del área y la exponencial aparición de nuevas aplicaciones y servicios, la administración de los accesos se vuelve algo cada vez más complejo. Los permisos permanentes, que en un principio proporcionaron una solución rápida, están empezando a mostrar sus limitaciones en un entorno tan dinámico y cambiante:

• Velocidad limitada de acción: los usuarios deben esperar a que su acceso sea brindado o recurrir a un superior causando pérdida de eficiencia, especialmente durante guardias. 
• Riesgo incrementado de errores: el aprovisionamiento manual de permisos puede producir errores involuntarios por permisos excesivos, sin limitar y sin auditoría. 
• Frustración: los colaboradores pueden sentirse frustrados cuando no poseen los accesos a los recursos que quieren para realizar su trabajo, generando insatisfacción.
• Riesgos de seguridad incrementados: cuando un acceso es permanente, se incrementa el riesgo de brecha de seguridad por el compromiso de la identidad o bien en escenarios de descontento del colaborador.

¿Qué es Just In Time Access o accesos temporales?

Es una estrategia de gestión de accesos en la cual los derechos de usuario o privilegios necesarios para un trabajo específico se otorgan únicamente cuando son necesarios. Y, luego, se revocan automáticamente, una vez que la tarea se ha completado o después de un periodo de tiempo predefinido. 

Este enfoque se alinea con el principio de “mínimo privilegio necesario” (PoLP), garantizando que los usuarios tengan solo los accesos que realmente requieren para desempeñar sus funciones, y solo durante el tiempo necesario. Con una correcta administración de permisos temporales es posible tener tanto una gestión como un monitoreo proactivo de los accesos. 

Beneficios de los accesos temporales:

• Aumenta el nivel de seguridad en las cuentas más críticas de Pomelo, es decir, los ambientes productivos donde funciona el producto. 
• Brinda un mecanismo “Break the Glass” para reducir demoras a la hora de asignar permisos en situaciones de carácter urgente.
• Reduce el riesgo de cambios no autorizados, malintencionados o erróneos. 
• Posibilita una gestión de cambios más ágil y menos propensa a errores. Esto es esencial para mantener un entorno seguro y resistente frente a amenazas internas y externas con alertas al Security Operation Center.
• Reduce la cantidad de roles de AWS actuales
• Mejora el control de accesos
• Simplifica la gestión de permisos
• Se alinea con las prácticas recomendadas por la ISO 2700, NIST y Zero Trust

¿Cómo implementamos un mecanismo de accesos temporales?

La implementación no fue trivial, ya que fue necesario modificar el acceso a todas las cuentas productivas de Pomelo. Actualmente sólo les otorgamos acceso de lectura por default con la posibilidad de elevar a permisos de escritura en cualquier momento de manera temporal. A esto, lo logramos mediante un proceso automatizado a través de workflows de Slack, como se muestra en el siguiente diagrama a alto nivel:

Explicación de la automatización para solicitar permisos temporales paso a paso:

1. Slack Workflow: el flujo comienza cuando un usuario le da clic al workflow “Permisos temporales Prod” de Slack. 

Se desplegará un formulario en el cual debemos indicar el motivo de la solicitud: 

4. Jira: una vez enviado el formulario, se crea un ticket en jira que activará una regla de automatización. Esta será la encargada de validar el equipo al que pertenece la persona que solicitó los permisos. En base a esa información, invocará a una función lambda específica creada para cada equipo.
5. Lambda: crearemos una función lambda por cada uno de los equipos que tendrá acceso a estas cuentas para aislar posibles errores ante futuras modificaciones. En dichas funciones se encontrará la lógica para otorgar los accesos correspondientes a AWS a través de grupos de OPEN LDAP.
6. Directorio de Usuarios (OPEN LDAP/IGA): gracias al acceso condicional y al módulo de SingleSignOn de OPEN LDAP, actualmente administramos el acceso a AWS por medio de grupos de usuarios predefinidos. Cada uno de estos grupos representa un equipo y replica en conjunto con sus integrantes en el servicio IAM Identity Center de AWS, permitiéndonos de esta forma otorgar permisos solo para ese equipo en las cuentas que necesitemos, en este caso Production. 
7. Notificaciones vía Slack: por último, se enviará un mensaje directo vía Slack notificando la asignación de los permisos, tanto a la persona solicitante, como internamente a nuestro equipo, para los días posteriores poder realizar la auditoría correspondiente.

Cabe destacar que tenemos diferentes permisos temporales que se asignan en base a cada equipo y una matriz de accesos por detrás creada, utilizando RBAC (Role based access control) y ABAC (Attribute Based Access Control) dependiendo los accesos necesarios en cada escenario.

Puntos importantes a tener en cuenta: 

• En caso de aplicar, otorgaremos permisos de lectura en las cuentas definidas por la Matriz de Accesos.
• Los nuevos permisos de escritura estarán segregados y serán asignados en base al Team del solicitante.
• Al momento de pedir los permisos será solicitada una justificación del pedido para poder avanzar.
• Los roles con permisos de escritura serán auditados luego por nuestro equipo para validar que efectivamente se haya realizado lo indicado en la justificación del pedido. Ante cada solicitud de permisos temporales, recibiremos una alerta en las cuentas de Production con roles de SSO. De esta manera, podremos identificar si se realizó efectivamente lo solicitado y también identificar posibles nuevos desarrollos en nuestro IDP.
• Los permisos podrán ser solicitados a demanda por medio de la automatización que comentaremos a continuación.
• La vigencia de los accesos será hasta las 00:00, por lo que será necesario volver a activar el flujo luego de ese horario.

Cambios en la experiencia de usuario

Con la implementación de esta propuesta, migramos de un esquema de permisos permanentes que incluía privilegios de escritura, a uno con privilegios permanentes pero de “solo lectura”. Si se requieren permisos más elevados (escritura), solicitarlos es tan simple como hacer click en un botón desde Slack.

Conclusiones

Lo primero a destacar con esta implementación es que mitigamos los errores accidentales y la resolución de incidentes se volvió mucho más ágil. Durante este proceso, hemos tenido en cuenta todas las excepciones necesarias para garantizar un despliegue adecuado y adaptado a nuestras necesidades. 

El uso de Just in Time ha sido fundamental para fortalecer nuestra seguridad en AWS, proporcionando una capa adicional de protección contra amenazas internas y externas en conjunto con nuestro framework de Zero Trust. También ha facilitado la aplicación de políticas de cumplimiento y normativas internas, asegurando que nuestra infraestructura cumpla con los estándares de seguridad establecidos.

¡Esperamos que les haya gustado y les entusiasme aplicarlo!