Imagina que has instalado la mejor cerradura electrónica del mundo en la puerta de tu empresa. Tienes biometría, tarjetas NFC y una cámara con IA que reconoce a cada empleado. Eso es autenticación: saber que Juan es, efectivamente, Juan.
Pero, una vez que Juan cruza la puerta, ¿puede entrar en el despacho del CEO? ¿Puede abrir el armario de los servidores? ¿Puede ver las nóminas en la red local? Eso es autorización (o control de acceso).
En ciberseguridad, solemos dedicar el 90% del tiempo a asegurar la entrada, pero dejamos el interior de la casa en un caos de permisos heredados y «carpetas para todos». En esta guía vamos a desglosar los modelos de autorización que separan una red profesional de un desastre esperando a ocurrir.
Índice de contenidos
DAC: Discretionary Access Control (Control de Acceso Discrecional)
El modelo DAC es el «hijo de la libertad» en la informática. Aquí, el acceso se basa en la identidad del usuario y, lo más importante, en la discreción del propietario del recurso.
Si tú creas un archivo en tu ordenador o una carpeta en Dropbox, tú eres el owner. Como dueño, tienes el poder de decidir quién más puede leerlo o editarlo. El sistema te da la potestad de delegar esos permisos.
El caso de uso típico: Colaboración en PYMES
Es el modelo por defecto en sistemas operativos como Windows, macOS y Linux (permisos de usuario/grupo/otros), y en herramientas cloud como Google Drive.
- Ejemplo práctico: Un diseñador crea una carpeta «Logos_Finales» y le da permiso de lectura al equipo de marketing. Si mañana el diseñador decide darle permiso de escritura a un becario externo, el sistema lo permite sin consultar a un administrador central.
La opinión de rutaciber.com
El DAC es excelente para la agilidad, pero es una pesadilla para la seguridad corporativa. Su mayor pecado es la proliferación de permisos (permission creep).
No hay un control centralizado real; la seguridad de la empresa acaba dependiendo de si el usuario «Pepe» es cuidadoso o si decide darle permisos de «Todos» a una carpeta crítica porque «tenía prisa».
Error común: El famoso
chmod 777en servidores Linux. Es el ejemplo máximo de DAC mal ejecutado: un usuario decide que, para que una web funcione, cualquiera en el mundo puede leer, escribir y ejecutar en ese directorio.
MAC: Mandatory Access Control (Control de Acceso Obligatorio)
Si el DAC es la libertad, el MAC es la disciplina militar. En este modelo, ni el creador del archivo ni el usuario pueden cambiar los permisos. Todo está definido por una política central administrada por el sistema.
El acceso se basa en dos ejes:
- Etiquetas de sensibilidad del recurso (Público, Interno, Secreto, Top Secret).
- Nivel de confianza (clearance) del sujeto.
Caso de uso: Seguridad Nacional y SELinux
El MAC nació en el ámbito gubernamental y militar (modelos como Bell-LaPadula). En el mundo IT generalista, lo vemos en el uso de SELinux (Security-Enhanced Linux) o AppArmor.
- Ejemplo práctico: Un servidor web (sujeto) está etiquetado para que solo pueda leer archivos en
/var/www/html. Aunque un atacante logre explotar una vulnerabilidad en el servidor web y gane privilegios de usuario, el modelo MAC impedirá que ese proceso lea/etc/shadow, porque el sistema operativo impone la regla de que «proceso web» no tiene la etiqueta necesaria para «archivos del sistema».
¿Cuándo merece la pena?
Solo cuando el riesgo es extremo. Gestionar MAC es costoso y rígido. Si etiquetas algo mal, nada funciona y depurarlo requiere un conocimiento técnico muy profundo. No es para una oficina de contabilidad; es para la infraestructura que sostiene los datos de tus clientes más críticos. Muy usado en el mundo militar.
RBAC: Role-Based Access Control (Control de Acceso Basado en Roles)
El RBAC es el estándar de la industria moderna. En lugar de asignar permisos a «Juan», los asignamos al rol de «Contable». Luego, decimos que «Juan» tiene el rol de «Contable».
Caso de uso: El ERP y el Directorio Activo
Es el modelo ideal para organizaciones con una estructura clara.
- Ejemplo práctico: En un hospital, el rol «Enfermero» tiene permiso para ver fichas de pacientes, pero no para modificarlas. El rol «Médico» tiene permiso de modificación. Si un enfermero es ascendido, simplemente se le cambia el rol. No hay que revisar carpeta por carpeta qué permisos tenía.
El peligro: La explosión de roles (Role Explosion)
El error técnico aquí es crear roles demasiado específicos: «Contable_Que_Usa_SAP_El_Viernes». Si acabas teniendo más roles que empleados, has vuelto al caos del DAC pero con un nombre más elegante.
Para que el RBAC funcione, los roles deben ser funcionales de negocio, no técnicos. Un administrador de IT no debería inventar roles; debería implementarlos basándose en el organigrama de la empresa.
Rule-BAC: Rule-Based Access Control (Control de Acceso Basado en Reglas)
A menudo confundido con el RBAC, el Rule-BAC no se fija tanto en quién eres tú, sino en si se cumple una condición lógica definida por el administrador.
Caso de uso: Firewalls y horarios de acceso
Es un modelo muy común en la capa de red y en la seguridad perimetral.
- Ejemplo práctico: «Nadie puede acceder al servidor de producción por SSH fuera del horario de 9:00 a 18:00″. No importa si eres el CEO o el SysAdmin; la regla manda.
- Otro ejemplo: Un portal cautivo de Wi-Fi que solo te permite navegar si has aceptado los términos de uso. La «regla» es el disparador del acceso.
Diferencia clave
Mientras que el RBAC es sobre pertenencia (soy del grupo X), el Rule-BAC es sobre contexto estático (es martes, vengo de esta IP, uso este protocolo).
ABAC: Attribute-Based Access Control (Control de Acceso Basado en Atributos)
El ABAC es el modelo más avanzado y el futuro (o presente) de la seguridad Zero Trust. Es extremadamente granular porque utiliza una combinación de atributos de cuatro tipos:
- Sujeto: Su rol, departamento, formación, años de antigüedad.
- Recurso: Tipo de archivo, fecha de creación, nivel de sensibilidad.
- Acción: Leer, editar, borrar, imprimir.
- Entorno: Ubicación (IP/GPS), hora, dispositivo (¿es corporativo o personal?), estado del antivirus.
Caso de uso: Entornos Cloud y alta sensibilidad
AWS (IAM Policies) y Microsoft Azure utilizan modelos muy cercanos al ABAC.
- Ejemplo práctico (La «Super Política»):«Permitir que el usuario del departamento de Finanzas (Sujeto) pueda Editar (Acción) el archivo ‘Presupuesto_2024.xlsx’ (Recurso), siempre que esté conectado desde la IP de la oficina (Entorno), sea en horario laboral (Entorno) y su portátil tenga el cifrado de disco activado (Entorno).»
El reto del ABAC
Su potencia es su debilidad: la complejidad. Configurar un motor de políticas ABAC requiere una planificación exhaustiva. Si te equivocas en un atributo, bloqueas el trabajo de todo un departamento.
Comparativa de Modelos: De un vistazo
| Modelo | Enfoque Principal | Flexibilidad | Dificultad | Ideal para… |
| DAC | Identidad + Dueño | Máxima | Muy Baja | Equipos pequeños, documentos personales. |
| MAC | Etiquetas de sistema | Mínima | Muy Alta | Sistemas operativos críticos, Defensa. |
| RBAC | Función laboral (Rol) | Media | Media | El 80% de las empresas (Estructura base). |
| Rule-BAC | Reglas lógicas | Baja | Media | Firewalls, restricciones horarias/IP. |
| ABAC | Contexto y Atributos | Alta | Alta | Cloud, Zero Trust, protección de datos sensibles. |
¿Cuál deberías usar tú?
No elijas solo uno. La realidad de la ciberseguridad profesional es híbrida.
- Usa RBAC para la base: Define roles claros en tu Directorio Activo o tu gestor de identidades. Es lo más fácil de auditar.
- Añade capas de Rule-BAC y ABAC: No permitas que el rol «Admin» entre desde una IP de otro país a las 3 de la mañana sin un contexto que lo justifique (Acceso Condicional).
- Elimina el DAC de tus activos críticos: El servidor de archivos donde están los datos de los clientes no puede estar bajo control discrecional de los usuarios. El administrador debe imponer la estructura.
Errores que vemos constantemente en auditorías:
- Grupos de «Shadow IT«: Usuarios que, al tener control DAC, crean sus propias estructuras de permisos para saltarse las restricciones de IT.
- Abuso de herencia: Carpetas que heredan permisos de la raíz que nadie ha revisado en 5 años. (Como ejemplo, la pesadilla del SharePoint).
- Confundir Grupos con Roles: Crear un grupo llamado «Ventas» y meter a gente es fácil. Crear un Rol de «Ventas» que defina exactamente qué permisos necesita ese perfil para trabajar es hacer ciberseguridad.
Conclusión
La autorización es el mecanismo que evita que un error de un usuario se convierta en un desastre para la empresa. Si sigues confiando en un modelo puramente discrecional (DAC), estás a un clic de distancia de una fuga de datos.
Moverse hacia modelos más robustos como el RBAC, reforzados con las reglas dinámicas del ABAC, es la única forma de escalar una infraestructura de forma segura. Recuerda: en seguridad, lo que no está explícitamente permitido, debería estar prohibido.
