Control de acceso basado en roles (RBAC).

El control de acceso basado en roles asigna permisos a roles abstractos (por ejemplo, "admin-facturación" o "auditor de solo lectura") y otorga acceso al añadir usuarios a esos roles. Esta indirección simplifica la administración, permite la separación de funciones y facilita las auditorías, porque los permisos se documentan por rol y no por usuario. RBAC es el modelo dominante en IAM corporativo, plataformas en la nube (AWS IAM, Azure RBAC, Kubernetes RBAC) y ERPs.

RBAC fue formalizado por David Ferraiolo y Rick Kuhn del NIST en su artículo de 1992 "Role-Based Access Controls", luego unificado con el marco de Sandhu y estandarizado como ANSI/INCITS 359-2004 (revisado como INCITS 359-2012). El estándar define cuatro componentes acumulativos: RBAC básico (usuarios–roles–permisos), RBAC jerárquico (los roles heredan de roles superiores) y dos formas de RBAC restringido —separación de funciones estática y dinámica (SSD/DSD)— que bloquean combinaciones tóxicas de permisos, como que un mismo usuario cree y apruebe un pago.

Su principal debilidad es la explosión de roles: en organizaciones grandes, codificar cada necesidad de negocio como un rol distinto genera miles de roles casi duplicados e inmanejables. Esto empuja hacia diseños híbridos ABAC/RBAC, donde los roles fijan una base gruesa y los atributos (departamento, hora, etiqueta del recurso) refinan cada decisión, el patrón detrás de las claves de condición de AWS IAM y del modelo RBAC-más-admission-webhook de Kubernetes.

flowchart LR
  U["Usuario: Alicia"] -->|asignada a| R1["Rol: admin-facturación"]
  U -->|asignada a| R2["Rol: auditor"]
  R1 -->|hereda| R3["Rol: lector-facturación"]
  R1 -->|otorga| P1["Permiso: crear factura"]
  R3 -->|otorga| P2["Permiso: leer factura"]
  R2 -->|otorga| P3["Permiso: exportar registros"]
  P1 --> RES[("Sistema de facturación")]
  P2 --> RES
  P3 --> RES
  SSD["Restricción SSD:<br/>no puede ser aprobador y creador"] -. bloquea .-> R1