Laboratorio de acceso RBAC / ABAC
Asigna roles de mínimo privilegio, detecta las combinaciones tóxicas de segregación de funciones y decide entre RBAC y ABAC. Se puntúa la detección frente a los falsos positivos.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
El exceso de acceso rara vez es una concesión dramática: es un rol un nivel demasiado amplio, una segunda función que nunca debería ir con la primera, un permiso que nadie revocó tras un traslado o una regla que solo un atributo de contexto puede imponer. En este laboratorio de revisión de accesos en el navegador trabajas una cola de unas 18 solicitudes de permisos y decides en cada una: aprobarla como mínimo privilegio o nombrar el hallazgo de IAM concreto. Los hallazgos repartidos por la cola: roles con privilegios excesivos (Owner/Administrator/*:* cuando basta un rol acotado), combinaciones tóxicas de segregación de funciones (maestro de proveedores + aprobador de pagos, autor + único aprobador del despliegue, administrador de IAM + administrador de los registros de auditoría), acumulación de privilegios (permisos obsoletos que quedan tras un traslado o un ascenso) y requisitos que de verdad necesitan ABAC (horario, ubicación, propietario del recurso, clasificación de los datos). Se te califica por la tasa de detección frente a los falsos positivos: bloquear una concesión limpia de mínimo privilegio conlleva una penalización adicional, porque una revisión de accesos que deniega el trabajo legítimo empuja a los equipos hacia el shadow IT. Los niveles de dificultad añaden concesiones más sutiles y trampas deliberadas: un administrativo de cuentas a pagar sin ninguna función en conflicto, un rol estático de solo lectura que NO necesita ABAC y un rol de emergencia (break-glass) de alto privilegio ya protegido por una elevación just-in-time (PIM). Cada concesión es estática y determinista, y tras la calificación cada una muestra por qué la decisión correcta lo es. Es un laboratorio Pro: con una cuenta gratuita tienes 3 usos y después necesitas Pro.
- Lee cada solicitud: quién es el sujeto, qué necesita el puesto, el rol o permiso solicitado, el recurso y su alcance, lo que ya tiene y la condición de acceso indicada.
- Apruébala como mínimo privilegio o marca el hallazgo: privilegios excesivos, infracción de segregación de funciones, acumulación de privilegios o necesita ABAC.
- Evita bloquear las concesiones limpias: cada falso positivo penaliza.
- Revisa la calificación y el razonamiento de cada solicitud.
Preguntas frecuentes
¿Qué es el laboratorio de acceso RBAC / ABAC?
Un ejercicio en el navegador en el que trabajas una cola de solicitudes de concesión de acceso (quién es el sujeto, qué necesita el puesto, el rol o permiso solicitado, el recurso y su alcance, lo que el sujeto ya tiene y la condición de acceso indicada) y das a cada una un veredicto: aprobar (mínimo privilegio), privilegios excesivos, infracción de segregación de funciones, acumulación de privilegios o necesita ABAC. Se te puntúa por cuántas concesiones arriesgadas detectas con el hallazgo exacto frente a cuántas concesiones limpias de mínimo privilegio bloqueas por error.
¿Qué diferencia hay aquí entre RBAC y ABAC?
El control de acceso basado en roles (RBAC) concede permisos mediante roles estáticos: es lo adecuado cuando el acceso depende solo de la función laboral y de un recurso fijo. El control de acceso basado en atributos (ABAC) decide cada petición a partir de atributos del sujeto, del recurso, de la acción y del entorno: la hora del día, la ubicación, el estado del dispositivo, la clasificación de los datos o si el sujeto es el propietario del recurso o forma parte de su equipo asistencial. El laboratorio enseña cuándo un requisito necesita de verdad ABAC (una condición por petición que un rol no puede expresar, en la que RBAC obligaría a una explosión de roles) y cuándo recurrir a ABAC solo añade un motor de políticas para nada.
¿Qué es una infracción de segregación de funciones (SoD)?
Una combinación tóxica: una persona que tiene dos funciones que deben separarse para que ninguna identidad pueda cometer y ocultar una acción dañina. Los pares clásicos son mantener el maestro de proveedores y aprobar sus pagos, escribir código y ser el único aprobador que además puede desplegarlo en producción, y administrar las identidades a la vez que los registros de auditoría. La solución es repartir las funciones entre personas o añadir un paso de aprobación independiente, no simplemente reducir el rol.
¿Para quién es?
Para ingenieros de IAM, de plataforma y de seguridad que conceden y revisan permisos, equipos de GRC y auditoría que hacen la recertificación de accesos y cualquiera que prepare una entrevista de seguridad o de nube y quiera entender de verdad por qué un Owner de proyecto para un solo bucket, AdministratorAccess en una cuenta de servicio, quien prepara y además aprueba, el acceso a producción sin revocar de alguien que se fue o una regla de región y horario metida a la fuerza en un rol estático son hallazgos, y por qué un administrativo de cuentas a pagar sin funciones en conflicto o un rol de emergencia protegido por JIT no lo son.
¿Es gratis?
No, es un laboratorio Pro. Con una cuenta gratuita tienes 3 usos de prueba; después necesitas Pro.