RBAC (Role-Based Access Control): los usuarios heredan permisos a través de roles predefinidos. Es simple de explicar pero se rompe cuando los roles no reflejan la organización real: aparecen 'roles comodín' que acaban con más permisos de los necesarios.
Qué es la autorización
La autorización es el proceso de decidir qué puede hacer un usuario, aplicación o dispositivo ya autenticado. No es lo mismo que autenticación: la autenticación responde a "quién eres" y la autorización a "qué puedes hacer ahora que sabemos quién eres". Se materializa en permisos granulares (qué datos ves, qué sistemas modificas, qué operaciones puedes lanzar) y se implementa con modelos como RBAC (basado en roles), ABAC (basado en atributos) y ACL (listas de acceso). Cuando la autorización es débil o está mal mantenida, el resultado típico es escalada de privilegios, exposición de datos sensibles y movimiento lateral tras un compromiso inicial.
Por qué importa
Una autorización bien diseñada es la principal línea de contención cuando una credencial cae: si los permisos están acotados, el daño está acotado. El principio de mínimo privilegio es la base de Zero Trust, segmentación de red y control de acceso, y casi siempre es el primer hallazgo grave de una auditoría: administradores de facto que ya no ejercen ese rol, cuentas de servicio con permisos heredados, accesos que sobrevivieron a cambios de equipo. El marco regulatorio lo refuerza: ISO 27001 exige segregación de funciones (SoD), NIS2 pide revisiones periódicas de acceso a información crítica y DORA obliga a gobernar el acceso privilegiado en servicios financieros esenciales. Para un CISO, esto significa dejar atrás la revisión anual en hoja de cálculo y avanzar hacia auditoría continua, segregación de funciones automatizada y autorización contextual (dispositivo confiable, ubicación, nivel de riesgo).
Puntos clave
ABAC (Attribute-Based Access Control): la decisión depende de atributos (departamento, hora, ubicación, postura del dispositivo, riesgo calculado). Es mucho más fino que RBAC pero requiere un motor de políticas y buena higiene de datos de identidad.
ReBAC y autorización relacional: modelos más recientes (usados en plataformas como OpenFGA o Zanzibar) expresan permisos como relaciones entre entidades ('Ana es editora del proyecto X'). Encaja bien en aplicaciones SaaS con jerarquías complejas de recursos compartidos.
Mínimo privilegio en la práctica: no es solo reducir el rol inicial; implica revocar accesos tras un cambio de puesto, retirar permisos a cuentas de servicio que ya no se usan y evitar que los administradores operen con cuenta privilegiada para tareas diarias.
Acceso just-in-time (JIT) y PAM: en lugar de mantener privilegios permanentes, se elevan solo durante una ventana auditada, con aprobación y expiración automática. Reduce drásticamente la ventana de exposición si la credencial se compromete.
Separación de funciones (SoD): quien crea pagos no los aprueba, quien crea cuentas no revisa los logs, quien despliega en producción no controla las reglas del SIEM. Se implementa con matrices de conflicto y controles automáticos en el IdP.
Ejemplo: Escalada de privilegios por autorización heredada
Un técnico de soporte lleva cuatro años en la empresa. Empezó en sistemas, luego pasó a soporte de usuarios, y en cada transición su cuenta fue acumulando permisos: seguía en el grupo de administradores de dominio "por si acaso", tenía acceso de lectura a la base de datos de clientes por un proyecto que duró dos semanas y mantenía credenciales del antiguo sistema de backup. Un phishing dirigido compromete su usuario; en cuestión de horas el atacante se mueve a un controlador de dominio, crea una puerta trasera con una cuenta de servicio aparentemente legítima y exfiltra tablas de clientes antes de que el EDR lo detecte como anómalo.
La respuesta no es castigar al técnico, es rediseñar el modelo. Se separan roles por función real (soporte puede resetear contraseñas pero no tocar GPOs, desarrollo accede a entornos de dev pero no a producción, administración de dominio se concede solo con MFA reforzado y ventana JIT). Se despliega un PAM que registra toda sesión privilegiada con grabación y aprobación doble para operaciones destructivas. Cada trimestre, los managers certifican que sus equipos aún necesitan los accesos que tienen, y el SIEM alerta cuando alguien ejerce un permiso que no ha usado en noventa días. En la siguiente auditoría, los permisos efectivos caen más de un tercio sin que nadie pierda capacidad de trabajar.
Errores habituales
- Asumir que un usuario comprometido solo puede hacer daño con sus privilegios visibles. Si su cuenta puede editar un script de despliegue, cambiar una GPO o leer secretos en un vault, tiene vías de escalada aunque no sea administrador formal.
- Tratar RBAC como un sistema estático: definir roles una vez al implantar el IdP y no revisarlos cuando la organización cambia. Al cabo de dos años los roles no reflejan la realidad y nadie se atreve a tocarlos por miedo a romper algo.
- No segregar funciones críticas: la misma persona que provisiona cuentas en AD puede asignarse permisos y borrar los eventos de auditoría. Sin SoD automatizado el control es un acuerdo de caballeros, no un control.
- Permisos heredados que nunca se revocan: cambios de puesto, salidas parciales, proyectos que terminan. La auditoría anual es demasiado lenta; hace falta automatización que retire accesos por inactividad y certificación continua.
- Usar cuentas de servicio como vía fácil para 'que todo funcione': permisos de administrador otorgados a integraciones que solo necesitan leer un endpoint concreto. Cuando la integración se olvida, la cuenta sigue viva con su poder intacto.
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Cuál es la diferencia entre RBAC y ABAC?
RBAC asigna permisos a través de roles fijos (admin, editor, viewer). Es rápido de implantar pero no distingue contexto: el mismo permiso se concede a las 10:00 desde la oficina o a las 03:00 desde una red desconocida. ABAC toma la decisión evaluando atributos (ubicación, hora, postura del dispositivo, nivel de riesgo) contra una política. Da control mucho más fino, pero exige invertir en un motor de políticas, gobernanza de atributos y datos de identidad limpios.
¿Por qué la segregación de funciones (SoD) es tan importante?
Porque neutraliza el riesgo de que una sola persona —ya sea por fraude o por error— complete una cadena sensible de extremo a extremo. Quien crea pagos no debe aprobarlos, quien provisiona cuentas no debe modificar los logs, quien despliega en producción no controla las reglas del SIEM. ISO 27001 lo exige y DORA lo refuerza para los servicios financieros esenciales. Sin automatización, SoD es un acuerdo; con matrices de conflicto en el IdP, es un control.
¿Cómo se audita la autorización en una empresa grande?
Con herramientas de Identity Governance: informes de permisos efectivos por usuario y rol, certificación periódica (los managers confirman que sus equipos siguen necesitando cada acceso) y detección automática de conflictos SoD. El SIEM complementa con alertas sobre accesos anómalos: permisos que llevan meses sin usarse y de repente se ejercen, cuentas de servicio que acceden a recursos fuera de su ámbito, escaladas puntuales sin justificación registrada.
¿Qué relación hay entre autorización y Zero Trust?
Zero Trust parte de "no confíes nunca, verifica siempre", y eso traducido a autorización significa que cada petición se evalúa contra la política vigente en ese momento, no contra un rol congelado. En la práctica, Zero Trust empuja a adoptar autorización contextual (ABAC o ReBAC), acceso just-in-time y revisión continua. Sin una autorización fina, Zero Trust se queda en el marketing de producto.