Modelos de Control de Acceso
DAC, MAC, RBAC y ABAC: diferencias, implementación y cuándo usar cada modelo
¿Qué es el Control de Acceso?
El control de acceso regula quién puede hacer qué sobre qué recurso. Toda autorización implica tres elementos: Sujeto (quién solicita), Objeto (el recurso) y Acción (lo que quiere hacer).
Los Cuatro Modelos Principales
DAC — Discretionary Access Control
Flexible / Bajo controlEl propietario del recurso decide quién accede. El sistema NO impone restricciones centrales. Es el modelo de sistemas de ficheros Unix/Windows tradicionales.
✅ Ventajas
- • Muy flexible; el usuario controla sus archivos
- • Fácil de implementar (chmod, ACLs)
❌ Desventajas
- • Un usuario puede redelegar acceso a otro usuario
- • Difícil de auditar y mantener a escala
- • Vulnerable a Trojan Horse (malware del usuario accede a sus archivos)
# Unix DAC: propietario asigna permisos
chmod 640 informe.pdf # rw-r-----
# Solo propietario y grupo pueden leer; otros no
MAC — Mandatory Access Control
Máxima seguridad / RígidoEl sistema impone las políticas; los usuarios no pueden cambiarlas. Usa etiquetas de seguridad (clasificación) en sujetos y objetos. Modelo del gobierno/militar.
Modelos teóricos
- Bell-LaPadula: confidencialidad — no read up, no write down
- Biba: integridad — no write up, no read down
- Clark-Wilson: integridad transaccional
Implementaciones
- • SELinux / AppArmor (Linux)
- • TrustedBSD, Mandatory Integrity Control (Windows)
- • Entornos clasificados (NSA, Pentágono)
# SELinux: proceso de nginx solo puede leer /var/www
ls -Z /var/www/html/index.html
unconfined_u:object_r:httpd_sys_content_t:s0
RBAC — Role-Based Access Control
✅ Más usado en empresasEl acceso se asigna a roles, no a usuarios individuales. Los usuarios se asignan a roles. Simplifica enormemente la gestión en organizaciones grandes.
Admin
CRUD todo
Solo 2 personas
Developer
Read + Write código
15 personas
Auditor
Read only logs
3 personas
# PostgreSQL RBAC
CREATE ROLE developer;
GRANT SELECT, INSERT ON TABLE orders TO developer;
GRANT developer TO alice, bob;
ABAC — Attribute-Based Access Control
Más granular / ComplejoEl acceso se basa en atributos del sujeto, el objeto y el entorno. Permite políticas muy granulares: "un empleado de Madrid puede ver pedidos de la región Sur solo en horario laboral".
# Política ABAC (XACML / Rego/OPA)
allow {
input.user.department == "finance"
input.resource.type == "invoice"
input.action == "read"
input.time.hour >= 8
input.time.hour <= 18
}
Implementaciones: AWS IAM conditions, Azure ABAC (preview), OPA/Rego, XACML, NIST SP 800-162.
¿Cuándo usar cada modelo?
DAC
Sistemas de archivos de usuario, NAS, comparticiones de red internas. Pequeños equipos con baja sensibilidad.
MAC
Sistemas de alta seguridad: defensa, inteligencia, infraestructura crítica. Cuando cumplimiento legal obliga a control centralizado estricto.
RBAC
La mayoría de aplicaciones empresariales: ERP, CRM, portales internos. Cuando los permisos están bien definidos por función.
ABAC
Contextos dinámicos: APIs públicas, federación de identidades, multicloud, cuando RBAC produce "role explosion" (demasiados roles).
Buenas Prácticas
Empezar con RBAC; escalar a ABAC solo cuando los roles se multiplican incontrolablemente.
Revisar y certificar los roles trimestralmente (access review / recertification).
Aplicar Separation of Duties: nadie debe poder hacer una transacción completa solo.
Registrar en SIEM todos los intentos de acceso (éxito y fallo).
Implementar alertas para accesos fuera de horario o de geolocalización inusual.
Siguiente Paso
Aprende a implementar autenticación multifactor con TOTP y FIDO2
MFA: Multifactor y FIDO2 →