RBAC

Role-Based Access Control (RBAC) is a security model that restricts system access based on the roles of individual users within an organization.

Role-Based Access Control (RBAC) es un modelo de seguridad que restringe el acceso al sistema basándose en los roles de los usuarios individuales dentro de una organización. En lugar de asignar permisos directamente a los usuarios, los permisos se asignan a roles, y los usuarios se asignan luego a esos roles. Este enfoque jerárquico simplifica la gestión de acceso, especialmente en entornos grandes o complejos. Los componentes centrales de RBAC incluyen Users, Roles, Permissions y, a veces, Objects/Resources. Users son los individuos que interactúan con el sistema. Permissions definen las acciones específicas que un usuario puede realizar sobre un resource (por ejemplo, 'read', 'write', 'delete'). Roles son colecciones de permissions que representan funciones o responsabilidades laborales (por ejemplo, 'Administrator', 'Editor', 'Viewer'). El principio central es que un user adquiere los permissions asociados con todos los roles a los que se le asigna. Este modelo promueve el principio de least privilege, asegurando que los users solo tengan el acceso necesario para sus funciones laborales, reduciendo así la attack surface y el riesgo de modificación o eliminación accidental o maliciosa de datos. RBAC es altamente scalable y adaptable, permitiendo la incorporación y eliminación eficiente de users y la fácil modificación de access policies a medida que cambian las estructuras organizacionales.

        graph LR
  Center["RBAC"]:::main
  Rel_identity_and_access_management_iam["identity-and-access-management-iam"]:::related -.-> Center
  click Rel_identity_and_access_management_iam "/terms/identity-and-access-management-iam"
  Rel_access_control_mechanisms["access-control-mechanisms"]:::related -.-> Center
  click Rel_access_control_mechanisms "/terms/access-control-mechanisms"
  Rel_authorization["authorization"]:::related -.-> Center
  click Rel_authorization "/terms/authorization"
  classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
  classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
  classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
  classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
  linkStyle default stroke:#4b5563,stroke-width:2px;

      

🧒 Explícalo como si tuviera 5 años

Es como dar diferentes llaves a diferentes personas en un edificio. El conserje recibe llaves para los armarios de limpieza, el gerente recibe llaves para las oficinas y todos reciben una llave para la entrada principal, pero no para los lugares a los que no necesitan ir.

🤓 Expert Deep Dive

RBAC models can be implemented with varying degrees of complexity, from flat role assignments to hierarchical or matrix-based structures. Hierarchical RBAC (HRBAC) allows roles to inherit permissions from other roles, enabling more granular control and reducing redundancy. For instance, a 'Senior Editor' role might inherit all permissions of an 'Editor' role plus additional publishing capabilities. The separation of duties is a critical security benefit, as it prevents a single user from having excessive control. Challenges in RBAC implementation include role explosion (too many roles), role engineering (defining appropriate roles and permissions), and managing role activation/deactivation, especially in dynamic environments. Formal verification methods can be employed to analyze the security properties of RBAC policies, ensuring consistency and preventing unintended privilege escalation. The integration of RBAC with identity and access management (IAM) systems is crucial for centralized control and auditing.

📚 Fuentes