Modelos de control de acceso

Objetivos: Al terminar este tema, podrás…

Diseñar sistemas de control de acceso apropiados para diferentes contextos

Implementar los modelos DAC, MAC y RBAC según requisitos de seguridad

Aplicar el principio de privilegio mínimo en arquitecturas de software

Identificar y mitigar riesgos de configuración de permisos

Apertura: el sistema que dejó ver los datos de dieciocho millones de personas

En marzo de 2026, un portal especializado en ciberseguridad reportó que alguien ofrecía en venta, en un foro clandestino, un archivo de 16 gigabytes con datos personales de 18 millones de colombianos: nombres completos, números de identificación, correos electrónicos y teléfonos. La fuente señalada fue el sistema de agendamiento de citas de la DIAN, la entidad que administra los impuestos en Colombia. La DIAN desactivó ese sistema mientras investigaba y denunció además un intento de extorsión relacionado. Según las primeras versiones conocidas, una falla en el sistema habría permitido acceder a información que no debía estar disponible de esa forma, aunque el mecanismo técnico exacto todavía no se conoce con certeza.

Fuente verificada: Vulnerabilidad habría causado una filtración de más de 18 millones de datos de la DIAN, ENTER.CO; cobertura adicional en El Tiempo.

Un sistema de agendamiento de citas existe para que un ciudadano reserve su propio turno, no para que cualquiera vea el turno, la cédula o el teléfono de otras dieciocho millones de personas. Que eso haya ocurrido significa que, en algún punto, el sistema dejó de distinguir entre esas dos cosas.

Explicación: modelos de control de acceso y privilegio mínimo

Lo que falló en el caso de la DIAN tiene un nombre técnico: control de acceso. Todo sistema que maneja información de más de una persona necesita responder tres preguntas antes de entregar cualquier dato o permitir cualquier acción. La primera es identificación: quién dice ser quien pide algo. La segunda es autenticación: cómo demuestra que es quien dice ser. Ya viste en la clase 02 que la autenticación es uno de los principios CIAAN, y aquí se retoma como algo ya resuelto, no como algo que hay que volver a explicar: cuando alguien inicia sesión con su contraseña o su segundo factor, el sistema ya sabe quién es. La tercera es autorización, y es el tema de hoy: una vez que el sistema sabe quién eres, qué te deja hacer. El control de acceso es el conjunto de mecanismos que responde exactamente esa tercera pregunta.

Antes de ver los modelos que existen para responderla, conviene fijar un principio que los atraviesa a todos: el privilegio mínimo. Dice que cada persona, proceso o sistema debe tener únicamente los permisos que su función exige, ni uno más. Un funcionario de atención al ciudadano necesita ver las citas que atiende; no necesita, para hacer su trabajo, poder ver los datos fiscales completos de dieciocho millones de contribuyentes. Cuando un sistema no respeta ese principio, cualquier cuenta comprometida (o cualquier error de programación, como el que aparentemente ocurrió en el caso de apertura) tiene mucho más alcance del que debería tener. El detalle de cómo aplicar este principio, con ejemplos por tipo de rol, está en la lectura disponible «Modelos de control de acceso en detalle».

Hay tres formas principales de decidir, dentro de un sistema, quién tiene cada permiso. La primera es el control de acceso discrecional, DAC: el dueño de cada recurso decide, caso por caso, quién puede acceder a él. Es el modelo detrás de compartir un archivo en Google Drive o Dropbox, donde tú decides con quién compartes tu documento y puedes cambiar esa decisión cuando quieras. Es flexible e intuitivo, pero por lo mismo es difícil de auditar a escala: cuando miles de usuarios deciden cada uno por su cuenta, nadie tiene una visión centralizada de quién puede ver qué, y los errores (compartir con la persona equivocada, olvidar revocar un acceso) se acumulan sin que nadie los note.

La segunda es el control de acceso obligatorio, MAC: en vez de que cada dueño decida, es el sistema el que impone las reglas, y ni siquiera el dueño del recurso puede cambiarlas. Los sistemas operativos modernos (Windows, Linux, iOS, Android) usan MAC para aislar aplicaciones entre sí: una aplicación de linterna en tu teléfono no puede leer tus mensajes de texto, así seas tú, el dueño del teléfono, quien instaló ambas aplicaciones. Esa regla no depende de que tú la actives ni de que la aplicación la pida con buenos modales, porque el sistema operativo la impone sin excepción. MAC es el modelo más rígido y el más difícil de configurar, pero también el más fácil de auditar, porque las reglas están centralizadas y nadie puede saltárselas por decisión propia.

La tercera es el control de acceso basado en roles, RBAC: en vez de asignar permisos a cada persona una por una, como en DAC, o de imponer una jerarquía fija de clasificación, como en MAC, los permisos se asignan a roles, y cada usuario hereda los permisos del rol o los roles que tiene asignados. Es el modelo más común en sistemas empresariales: en una universidad, el rol “profesor” trae consigo la capacidad de modificar las notas de sus propios cursos, y esa capacidad no hay que dársela a cada profesor individualmente ni imponerla como una regla de clasificación. Cuando alguien cambia de función, basta con cambiarle el rol asignado y todos sus permisos se actualizan de una vez. El detalle de los tres modelos (arquitectura, ejemplos adicionales, vulnerabilidades típicas de cada uno) está también en esa misma lectura disponible; lo que sigue ahora es ponerlos a prueba contra un caso real.

Demostración: modelar el primer caso

Diseñar control de acceso no es memorizar tres modelos y elegir uno de una lista: es hacerse, para cada tipo de usuario, la pregunta de qué necesita ver o hacer esa persona para cumplir su función, y qué pasaría si tuviera más permiso del necesario. Aplicada al sistema de citas de la apertura, esa pregunta tiene al menos tres respuestas distintas, una por cada tipo de usuario que el sistema necesita reconocer: el ciudadano que agenda su propia cita, el funcionario que atiende las citas de su oficina y el administrador que mantiene el sistema completo. El ciudadano no necesita ver los datos de otro ciudadano, así que ese acceso debería quedar cerrado por defecto. El funcionario solo necesita ver los datos de las citas que atiende, no las de todo el país. El administrador sí necesita ver todos los registros para hacer mantenimiento del sistema, y ese permiso tan amplio es precisamente la superficie de riesgo que hay que vigilar con más cuidado.

Aplicación grupal: diseña el control de acceso de un sistema real

La clase se organiza en 5 grupos y cada uno recibe un sistema real distinto para diseñar su control de acceso desde cero: un sistema de agendamiento de una entidad pública, una historia clínica electrónica, una plataforma académica, una aplicación de banca móvil y una plataforma de comercio electrónico. La variedad es intencional: cinco sistemas distintos producen cinco decisiones de diseño distintas, y esa diferencia es el material de la puesta en común. Cada grupo decide qué roles necesita su sistema, qué modelo (DAC, MAC, RBAC o una combinación) usaría y por qué, construye una matriz de permisos que respete el privilegio mínimo y piensa, al final, como atacante: si alguien comprometiera la cuenta de uno de sus roles, ¿qué podría hacer y cómo se mitigaría? El proceso completo de diseño, en siete pasos, con el detalle de cada decisión que exige, está desarrollado en la lectura disponible «Diseñar y auditar un sistema de control de acceso»; hoy se aplica una versión abreviada de ese proceso.

Revisión entre pares

Un diseño de control de acceso que se ve completo para quien lo hizo puede tener huecos evidentes para alguien externo, igual que ocurre en una auditoría de seguridad real, porque quien diseñó el sistema ya no ve sus propios puntos ciegos. Por eso cada grupo entrega su diseño a otro grupo, que lo revisa con una rúbrica breve antes de la puesta en común.

Debrief y cierre

Los tres modelos no compiten por ser el mejor en abstracto: compiten por ajustarse mejor a sistemas distintos, y la elección correcta depende de qué se está protegiendo y de quién. Esa es la idea que cierra la sesión, retomando tanto las cinco decisiones de diseño del taller como el caso de apertura. El sistema de la DIAN necesitaba, como mínimo, distinguir con claridad entre un ciudadano que consulta su propia cita y cualquier otro tipo de usuario, y aplicar esa distinción sin excepción en cada solicitud, no solo en la pantalla que el usuario ve. Ese último matiz, verificar el permiso en el servidor y no confiar en que la interfaz oculte lo que no debería verse, es igual de importante que elegir bien el modelo, y se desarrolla con un caso real en la lectura disponible «Cuando el control de acceso falla en el mundo real».

Preguntas de reflexión

Entra a la configuración para compartir archivos de un servicio que uses de verdad (Google Drive, OneDrive, Dropbox o similar) y revisa con quién has compartido algo en el pasado. Nombra el servicio específico y describe qué modelo de control de acceso implementa esa función de compartir: ¿el dueño decide caso por caso, como en DAC, o el servicio te obliga a elegir entre roles predefinidos? ¿Encontraste algún archivo compartido con más personas de las que recordabas?
Piensa en una plataforma de trabajo colaborativo que uses de verdad (Google Workspace, Microsoft 365, Notion, Slack o similar). Nombra el servicio específico e identifica una función donde el modelo se parece más a DAC (cada usuario decide con quién comparte lo suyo) y otra función donde se parece más a RBAC (el acceso depende de un rol fijo que un administrador define). Argumenta cuál de las dos deberían cambiar de modelo, y formula el argumento más fuerte que alguien podría usar en tu contra.
Busca una noticia colombiana o latinoamericana de 2025 o 2026, distinta al caso de la DIAN visto en clase, sobre una filtración de datos, y que incluya el enlace verificable a la fuente. A partir de lo que la noticia reporta, explica si el problema parece haber sido de autenticación (probar quién eres), de autorización (qué puedes hacer una vez identificado) o de ambas, y por qué.
Piensa en un edificio, archivo físico o proceso administrativo que conozcas (una biblioteca, una portería, un archivo de historias clínicas en papel, una caja fuerte compartida). Describe cómo funciona hoy el control de acceso ahí y rediseña sus permisos aplicando el privilegio mínimo: ¿quién tiene acceso de más, y qué le quitarías?
El principio de privilegio mínimo dice que cada quien debe tener solo los permisos que su función exige. Describe una situación de emergencia (real o plausible) en la que aplicar ese principio de forma estricta podría, paradójicamente, poner en riesgo la disponibilidad de un sistema o la seguridad de una persona. ¿Cómo diseñarías una excepción controlada sin volver el sistema tan abierto como si el principio no existiera?

Laboratorio práctico: Diseño de sistema RBAC

Tiempo estimado: 90 minutos (trabajo individual fuera de la sesión) Requisitos: Navegador web

Objetivo

Diseñar, en detalle y de forma individual, el control de acceso completo de uno de los sistemas trabajados en la Aplicación grupal de esta clase: el mismo tipo de decisiones que tomó tu grupo en equipo (roles, modelo, matriz de permisos, escenario de ataque), pero ahora sobre un sistema que no diseñaste tú.

Antes de empezar: elige tu sistema

No analices el sistema que le tocó a tu propio grupo en la Aplicación grupal: ya tienes ese trabajo hecho en equipo, y repetirlo aquí no te exige nada nuevo. Analiza en cambio el sistema del grupo que revisaste durante la Revisión entre pares, el que te tocó en la rotación 1→2, 2→3, 3→4, 4→5, 5→1. Ya lo viste con cierto detalle durante esos minutos, pero nunca lo resolviste tú mismo desde cero, así que este laboratorio te exige construir tu propia versión completa, no copiar la del grupo que lo diseñó originalmente.

Recuerda los cinco sistemas y sus recursos mínimos, con la tabla completa en la Aplicación grupal: agendamiento de citas de una entidad pública, historia clínica electrónica, plataforma académica universitaria, banca móvil y comercio electrónico.

Parte 1: Diagrama de jerarquía de roles

Define entre 4 y 6 roles para tu sistema. Puedes partir de los que tu grupo asignó a ese sistema durante la revisión entre pares, pero desarróllalos con más detalle del que hubo tiempo de discutir en clase.

Ejercicio 1.1: Dibuja un diagrama de jerarquía de roles que muestre:

Los roles organizados de menor a mayor privilegio.
Flechas de herencia (qué rol hereda de cuál).
Al menos un rol de solo lectura o de supervisión, equivalente al rol “Auditor” de la lectura disponible. Indica si ese rol hereda de algún otro o es independiente, y justifica tu decisión.

Tip: Puedes dibujar el diagrama a mano, usar una herramienta como draw.io, o representarlo como texto con indentación.

Ejercicio 1.2: Responde: ¿por qué un rol de supervisión o auditoría no debería heredar del rol de mayor privilegio de tu sistema, aunque ambos puedan “ver todo”?

Parte 2: Matriz de permisos

Ejercicio 2.1: Construye una matriz de permisos para tu sistema (roles en columnas, recursos en filas, notación CRUD; usa - si un rol no tiene ningún acceso a ese recurso), siguiendo el mismo formato de matriz que viste en la lectura disponible sobre el caso de la universidad.

Ejercicio 2.2: Recorre tu matriz columna por columna, de menor a mayor privilegio. ¿Qué patrón observas en la progresión de operaciones disponibles?

Ejercicio 2.3: Elige dos de tus roles y describe qué pasaría si un mismo usuario tuviera ambos roles asignados simultáneamente. ¿Qué operaciones acumularía sobre cada recurso? ¿Hay alguna combinación de roles que debería estar prohibida (separación de funciones) aunque técnicamente sea posible asignarla?

Parte 3: Análisis de decisiones de acceso

Inventa 3 usuarios de tu sistema, cada uno con uno o dos roles asignados de los que definiste en la Parte 1.

Ejercicio 3.1: Para cada uno de tus 3 usuarios, escribe 2 solicitudes de acceso distintas (6 en total) y determina si se permiten o se deniegan, justificando con qué rol otorga o niega el permiso necesario. Usa una tabla con estas columnas: usuario, acción, recurso, ¿permitido?, justificación.

Ejercicio 3.2: Elige una de tus 6 solicitudes y traza paso a paso el proceso de autorización completo: ¿el usuario está identificado y autenticado?, ¿qué roles tiene?, ¿qué permiso exige la acción solicitada?, ¿alguno de sus roles lo incluye?, ¿se permite o deniega?

Parte 4: Análisis de seguridad

Ejercicio 4.1: Un caso real de control de acceso roto

Busca una noticia o reporte real, con URL verificable, sobre un incidente donde alguien accedió a datos o funciones que no le correspondían por una falla de control de acceso, en cualquier industria. Busca un caso distinto a los dos que viste en la lectura disponible de esta clase (el de la DIAN y el de First American Financial).

Con ese caso real como referencia, explica con tus palabras qué fue lo que falló y compáralo con estos tres escenarios de ataque contra tu propio sistema:

Escenario de ataque	¿Funciona contra tu diseño?	¿Por qué?	Mitigación propuesta
Un usuario cambia, desde su propia sesión, el valor de su rol antes de que la solicitud llegue al servidor
Un usuario cambia, en una solicitud que su propia aplicación envía, un identificador propio (por ejemplo el de su cuenta o su pedido) por el de otra persona
Alguien crea varias cuentas nuevas para acumular, entre todas, más permisos de los que un solo usuario debería tener

¿A cuál de estos tres escenarios se parece más el caso real que encontraste? Justifica tu respuesta.

Ejercicio 4.2: Separación de funciones

En un sistema financiero, o en cualquier sistema donde una acción crítica tenga consecuencias graves, es importante que ninguna persona pueda completar sola una operación crítica.

En tu sistema, identifica una operación crítica que, siguiendo esa lógica, no debería poder crear y aprobar la misma persona. ¿Cuál es, y por qué es crítica?
Diseña dos roles para esa operación, uno que la solicita y otro que la aprueba, con sus permisos respectivos. ¿Qué restricción adicional necesitas más allá de los permisos para que la separación funcione de verdad? (Piensa en tu respuesta al Ejercicio 2.3.)
Describe con tus palabras qué es la acumulación de permisos y explica cómo la prevendrías en tu sistema.

Ejercicio 4.3: Privilegio mínimo

Revisa la matriz de permisos que construiste en la Parte 2. ¿Hay algún rol con más permisos de los estrictamente necesarios? Si es así, propón un ajuste concreto.

Parte 5: Registro de auditoría

Toda decisión de acceso debe quedar registrada, para cumplimiento y para detectar incidentes. Este es un ejemplo ya resuelto de cómo se ve un registro de auditoría, con dos entradas de muestra:

[2026-03-10T09:15:00Z] user=carlos action=DELETE resource=usuario_42 decision=denied
[2026-03-10T09:15:03Z] user=diana action=DELETE resource=usuario_42 decision=granted

Cada entrada incluye, como mínimo, cuándo ocurrió, quién lo pidió, qué acción sobre qué recurso, y si se permitió o se negó.

Ejercicio 5.1: Un analista de seguridad revisa el siguiente fragmento de registro de tu sistema:

[2026-03-10T10:00:00Z] user=ana action=GET resource=pedido_1 decision=granted
[2026-03-10T10:00:01Z] user=ana action=GET resource=pedido_2 decision=denied
[2026-03-10T10:00:01Z] user=ana action=GET resource=pedido_3 decision=denied
[2026-03-10T10:00:02Z] user=ana action=GET resource=pedido_4 decision=denied
[2026-03-10T10:00:02Z] user=ana action=GET resource=pedido_5 decision=denied
...
[2026-03-10T10:00:10Z] user=ana action=GET resource=pedido_100 decision=denied

(Sustituye “pedido” por el nombre del recurso equivalente en tu sistema si es distinto.)

¿Qué está intentando hacer Ana?
¿Qué tipo de comportamiento sospechoso revela este patrón?
¿Qué alerta automática diseñarías para detectarlo?

Entregable

Entrega un documento (PDF o Word) que incluya:

Nombre del sistema que analizaste y de qué grupo lo revisaste en la Revisión entre pares.
Diagrama de jerarquía de roles con justificación de la posición del rol de supervisión o auditoría.
Matriz de permisos completa y el análisis del patrón observado.
Tabla de decisiones de acceso con justificaciones y la traza del proceso de autorización.
Análisis de seguridad: el caso real encontrado (con URL), su comparación con los tres escenarios de ataque, la separación de funciones y el privilegio mínimo.
Análisis del registro de auditoría (Ejercicio 5.1).

Criterios de evaluación

Criterio	Puntos
Diagrama de jerarquía de roles correcto y justificado	15
Matriz de permisos completa y consistente con la jerarquía	20
Análisis de decisiones de acceso correcto y bien justificado	20
Análisis de seguridad: caso real, escenarios de ataque, separación de funciones y privilegio mínimo	30
Análisis del registro de auditoría	15

Lectura disponible — Modelos de control de acceso en detalle

Esta lectura retoma, con más detalle del que hubo tiempo de dar en la sesión, el privilegio mínimo y los tres modelos que viste en la Explicación.

Privilegio mínimo en la práctica

El principio es simple de enunciar y difícil de sostener en el tiempo, porque los sistemas reales tienden a acumular permisos en vez de perderlos. La tabla siguiente muestra cómo se aplica en distintos contextos:

Contexto	Aplicación del principio
Empleado nuevo	Acceso mínimo al iniciar; se amplía solo cuando aparece una necesidad real y demostrada
Recepcionista	Puede ver la agenda, pero no acceder a expedientes de recursos humanos
Técnico de soporte	Puede reiniciar servicios, pero no modificar la configuración crítica
Programa de software	Solo accede a los archivos que necesita para funcionar, no a todo el disco
Cuenta de correo	Acceso solo a su propia bandeja, no a la de otros usuarios

Aplicarlo bien trae varios beneficios concretos. Si una cuenta se compromete, el daño queda limitado a lo que esa cuenta podía hacer, no a todo el sistema: es la diferencia entre que un atacante robe la llave de un cajón y que robe la llave maestra del edificio completo. Menos permisos por cuenta también significa menos formas distintas en que un atacante puede entrar, porque cada permiso de más es una puerta adicional que alguien tiene que vigilar. Y cuando los permisos son específicos en vez de genéricos, es más fácil rastrear después quién hizo qué, porque una acción solo pudo venir de las pocas cuentas que tenían el permiso necesario.

DAC en detalle

En DAC, el propietario de un recurso define quién más puede acceder a él mediante una lista de control de acceso, o ACL. Esta es la forma típica de una ACL para un archivo:

{
  "resource": "/documentos/proyecto-final.pdf",
  "owner": "maria@empresa.com",
  "acl": [
    {"principal": "juan@empresa.com", "permissions": ["read"]},
    {"principal": "pedro@empresa.com", "permissions": ["read", "write"]},
    {"principal": "grupo:desarrollo", "permissions": ["read"]}
  ]
}

María es la dueña del archivo. Ella decidió que Juan solo puede leerlo, que Pedro puede leerlo y modificarlo, y que todo el grupo de desarrollo puede leerlo. Nadie más que ella necesita aprobar esos cambios, y ella puede revocarlos en cualquier momento. DAC es el modelo de los sistemas de archivos tradicionales (los permisos POSIX de Linux, los permisos NTFS de Windows), del almacenamiento en la nube (Google Drive, Dropbox, S3) y de los wikis y documentos colaborativos.

Su flexibilidad es también su debilidad. Con el tiempo, en un sistema DAC grande aparecen tres vulnerabilidades que se repiten: la acumulación de permisos, cuando un usuario cambia de rol dentro de la organización y va sumando accesos del rol anterior sin que nadie se los retire; el exceso al compartir, cuando alguien marca un documento como “cualquiera con el enlace puede ver” cuando en realidad solo una persona debía verlo; y los permisos olvidados, cuando un ex empleado conserva acceso porque nadie se acordó de revocarlo al momento de su salida. Ninguna de las tres requiere un atacante sofisticado: todas son fallas de mantenimiento, no de diseño del modelo.

MAC en detalle

MAC invierte la lógica de DAC: en vez de que el propietario decida, una política central clasifica tanto a los usuarios como a los recursos, y una regla fija (que nadie, ni siquiera el dueño del dato, puede modificar) determina qué combinaciones de clasificación se permiten. El ejemplo del teléfono que viste en la Explicación es MAC en su forma más cotidiana: el sistema operativo aísla cada aplicación en su propio espacio y decide, según permisos que declaraste una sola vez al instalarla (o que el sistema niega por defecto), a qué partes del teléfono puede llegar. Una aplicación de linterna no tiene ninguna razón para leer tus mensajes, así que el sistema operativo simplemente no le da esa puerta, sin importar cuánto lo intente ni qué tan bien programada esté.

Ese mismo principio, llevado a un contexto de clasificación de información por niveles de sensibilidad (público, confidencial, secreto), es el que usan los sistemas militares y gubernamentales, y por la misma razón: nadie quiere que una persona con autorización para ver información confidencial pueda, por una decisión suya, filtrarla hacia un nivel de clasificación inferior donde más gente tendría acceso. MAC es más difícil de configurar que DAC porque exige definir de antemano toda la política de clasificación, pero es mucho más fácil de auditar, porque las reglas están en un solo lugar y ninguna persona individual puede saltárselas.

RBAC en detalle

RBAC organiza el control de acceso alrededor de cuatro componentes: los usuarios, que son quienes solicitan acceso; los roles, que son conjuntos de permisos que representan una función dentro de la organización; los permisos, que son las operaciones concretas permitidas sobre un recurso; y las sesiones, que son la activación de uno o más roles cuando un usuario efectivamente usa el sistema.

Ese último componente suele pasar desapercibido, pero es el que hace posible aplicar separación de funciones sin crear una cuenta nueva por cada tarea. Que un usuario tenga asignado un rol no significa que ese rol esté activo todo el tiempo. RBAC distingue entre la asignación de un rol, que un administrador decide una vez y que cambia poco, y la activación de una sesión con ese rol, que ocurre cada vez que el usuario inicia sesión y que puede limitarse. A un empleado de compras se le puede asignar el rol de aprobador además del rol de solicitante, pero el sistema puede impedir que active el rol de aprobador en la misma sesión donde también solicitó la compra que está a punto de aprobar. El permiso existe, pero la sesión que lo activaría en el momento equivocado, no.

Los roles además pueden organizarse en una jerarquía, donde un rol superior hereda automáticamente los permisos de los roles que tiene debajo:

                    [Admin]
                       ↓
            [Manager]     [Auditor]
               ↓
    [Editor]    [Viewer]
       ↓
  [Contributor]

Esta jerarquía muestra un detalle importante: el Auditor no cuelga de Admin ni de Manager, sino que es independiente. Aunque un auditor necesita poder ver casi todo lo que ve un Admin, no debería heredar también la capacidad de modificar o eliminar, porque su función es revisar, no actuar. Diseñar bien una jerarquía de roles significa preguntarse, para cada rol, no solo “qué necesita ver” sino “qué NO debería poder hacer, aunque en teoría lo necesitara para ver todo lo demás”.

Como ilustración de cómo se ve una matriz de permisos completa, esta es la que resultaría de aplicar RBAC a un sistema empresarial genérico con cinco roles y cinco tipos de recursos:

Rol / Recurso	Usuarios	Productos	Pedidos	Reportes	Configuración
Admin	CRUD	CRUD	CRUD	CRUD	CRUD
Manager	R	CRUD	CRUD	CR	R
Vendedor	-	R	CR	-	-
Cliente	R (propio)	R	CR (propio)	-	-
Auditor	R	R	R	R	R

C = Crear, R = Leer, U = Actualizar, D = Eliminar

Cuando un usuario intenta realizar una acción, el sistema sigue siempre el mismo procedimiento: obtiene los roles activos del usuario en esa sesión, consulta qué permisos tiene cada uno de esos roles, verifica si alguno de esos permisos cubre la acción solicitada y, si ninguno la cubre, rechaza la acción y registra el intento. Ese último paso, registrar incluso los intentos rechazados, es el que hace posible detectar después un patrón de ataque, como verás en la lectura «Diseñar y auditar un sistema de control de acceso».

Comparación de los tres modelos

Característica	DAC	MAC	RBAC
¿Quién decide el acceso?	El dueño del recurso	El sistema, con reglas fijas	El administrador, mediante roles
Flexibilidad	Alta	Baja	Media
¿Escala bien con muchos usuarios?	No	Sí	Sí
Complejidad	Baja	Alta	Media
Fácil de auditar	No	Sí	Sí
Uso típico	Archivos personales, Google Drive	Sistemas militares, apps móviles	Sistemas empresariales

Conceptos clave

Término	Definición
\|Control de acceso	Mecanismos que determinan quién puede acceder a qué recursos
\|DAC	Modelo donde el propietario del recurso define el acceso
\|MAC	Modelo donde el sistema impone reglas de clasificación que nadie puede cambiar
\|RBAC	Modelo donde los permisos se asignan a roles, no a usuarios
\|ABAC	Variante avanzada que combina múltiples atributos del usuario, el recurso y el contexto para tomar decisiones; esta clase no la desarrolla, pero puedes explorarla en el glosario si te interesa
\|Privilegio mínimo	Principio de otorgar solo los permisos necesarios
\|ACL	Lista de permisos asociada a un recurso

Lectura disponible — Diseñar y auditar un sistema de control de acceso

Diseñar el control de acceso de un sistema no es elegir un modelo de una lista: es recorrer un proceso de decisiones, cada una con su propia forma de salir mal. Esta lectura desarrolla ese proceso paso a paso y lo aplica a un caso completo.

El proceso de diseño, paso a paso

Identificar los recursos que hay que proteger. Antes de pensar en roles o en modelos, hay que tener una lista concreta de qué existe en el sistema y qué pasaría si alguien no autorizado llegara a cada elemento de esa lista. Saltarse este paso es la causa más común de un control de acceso incompleto: un recurso que nadie identificó como sensible tampoco tiene ninguna regla que lo proteja.

Definir las operaciones posibles sobre cada recurso. No basta con decir “los pedidos” como recurso: hay que distinguir entre verlos, crearlos, modificarlos y cancelarlos, porque un rol puede necesitar una operación sin necesitar las demás. Un cliente necesita crear y cancelar sus propios pedidos, pero no necesita nunca modificar el pedido de otra persona.

Identificar los actores. No solo usuarios humanos: también sistemas automatizados, servicios internos y procesos programados que acceden a los mismos recursos. Un proceso de facturación automática que corre cada noche es un actor tan real como un empleado, y necesita su propio conjunto de permisos, ni más ni menos amplio de lo que su función exige.

Mapear funciones a roles, cuando el modelo elegido es RBAC. Este es el paso donde con más frecuencia se cuela el exceso de privilegio: es tentador crear un solo rol “empleado” con acceso amplio para no tener que pensar en cada función por separado, pero eso es exactamente lo contrario del privilegio mínimo.

Definir las políticas de acceso: para cada combinación de rol (o usuario, en DAC) y recurso, decidir explícitamente qué se permite. La forma correcta de plantear la política es “nadie puede, excepto los roles que necesiten esto específicamente”, no “todos pueden, excepto quien decidamos excluir”: la primera versión es explícita y auditable, y un error en ella dejaría a alguien sin acceso que necesita, algo molesto pero visible. La segunda versión es implícita y un error en ella deja a alguien con acceso que no debería tener, algo que puede pasar meses sin que nadie lo note.

Implementar el enforcement en todos los puntos de entrada. La verificación de permisos tiene que ocurrir en el servidor, nunca solo en la interfaz que ve el usuario. Si el control de acceso solo consiste en ocultar botones en la pantalla, cualquiera con conocimientos básicos puede saltárselo enviando la solicitud directamente al servidor sin pasar por esa pantalla:

[Usuario] → [Interfaz (solo muestra las opciones válidas)]
                         ↓
            [Servidor (verifica permisos SIEMPRE)]
                         ↓
               Decisión + Registro de auditoría

Diseñar la auditoría de las decisiones de acceso. Cada intento, permitido o denegado, debería quedar registrado, con quién lo pidió, cuándo, sobre qué recurso y con qué resultado. Sin ese registro, un ataque en curso solo se nota cuando el daño ya está hecho.

Anti-patrones que se repiten

Anti-patrón	Problema	Solución
Verificar permisos solo en la interfaz	Cualquiera puede saltarse la pantalla y acceder directamente	Verificar siempre en el servidor
Una sola cuenta compartida entre varias personas	Si algo sale mal, no se sabe quién lo hizo	Una cuenta por persona, con su propio rol
Permisos por exclusión (“todos pueden, excepto…“)	Difícil de mantener; un error incluye a quien no debía	Permisos explícitos (“nadie puede, excepto…“)
No revisar los permisos periódicamente	Personas con acceso que ya no necesitan, o que ya no trabajan en la organización	Revisión periódica y revocación al cambiar de rol o al salir

El primer anti-patrón de la tabla no es una advertencia hipotética. En mayo de 2019, la aseguradora estadounidense First American Financial dejó expuestos más de 800 millones de documentos con datos bancarios, números de seguro social y copias de licencias de conducir. El fallo no fue una contraseña débil ni un ataque sofisticado: cualquiera que tuviera el enlace a un documento podía cambiar un número en la dirección web y ver el documento siguiente, sin que el sistema verificara si esa persona tenía derecho a verlo. Esto se conoce como referencia directa insegura a un objeto (IDOR), y es, en el fondo, el mismo anti-patrón de esta tabla: la aplicación confiaba en que nadie adivinaría o cambiaría ese número, en vez de comprobar en el servidor, en cada solicitud, si el usuario tenía permiso sobre ese documento específico. Fuente: Krebs on Security, mayo de 2019.

Aplicando el proceso completo: una universidad colombiana

Para ver el proceso completo en acción, imagina una universidad colombiana con una escala parecida a la de las más grandes del país: 50.000 estudiantes, 2.000 profesores, 500 administrativos, y varios sistemas que comparten información (notas, matrícula, biblioteca, correo). (Caso ilustrativo, sin corresponder a ninguna institución en particular.)

Siguiendo los primeros cuatro pasos del proceso, el resultado es una jerarquía de roles como esta:

Roles base:
├── Estudiante
│   ├── Puede: ver propias notas, inscribir materias, acceder biblioteca
│   └── No puede: modificar notas, ver datos de otros estudiantes
├── Profesor
│   ├── Hereda: permisos de Estudiante
│   ├── Puede: modificar notas de sus cursos, ver lista de estudiantes
│   └── No puede: modificar notas de otros cursos
├── Director_Programa
│   ├── Hereda: permisos de Profesor
│   └── Puede: ver estadísticas de programa, aprobar excepciones
├── Administrativo_Registro
│   ├── Puede: gestionar matrículas, generar reportes
│   └── No puede: modificar notas
└── Admin_Sistema
    └── Puede: gestionar usuarios, configurar sistema

La decisión de que un Profesor herede de Estudiante, en vez de partir de cero, ahorra tener que redefinir permisos que cualquier miembro de la comunidad universitaria necesita de todas formas (ver su propio horario, acceder a la biblioteca). La decisión de que Director_Programa herede de Profesor, y no directamente de Estudiante, refleja que un director sigue siendo profesor de sus propios cursos, además de tener funciones administrativas nuevas.

El quinto paso, las políticas de acceso, produce la matriz de recursos:

Recurso	Estudiante	Profesor	Admin_Registro	Admin_Sistema
Notas propias	R	R	R	R
Notas de curso	-	RU (sus cursos)	R	R
Inscripción propia	CRU	R	CRUD	CRUD
Inscripción de otros	-	-	CRUD	R
Usuarios	-	-	R	CRUD

El sexto paso, el enforcement, es el que garantiza que esta tabla no sea solo un documento de referencia: cada uno de los cuatro sistemas mencionados (notas, matrícula, biblioteca, correo) tiene que verificar esta misma política en su propio servidor, cada vez, sin excepción. Y el séptimo paso, la auditoría, es lo que permitiría detectar, por ejemplo, si la cuenta de un estudiante empieza a intentar acciones que su rol no permite, la señal más común de que una cuenta fue comprometida o de que alguien intenta escalar sus propios privilegios.

Lectura disponible — Cuando el control de acceso falla en el mundo real

Los dos casos reales de esta clase, el de la DIAN y el de First American Financial, separan diecinueve años y dos países, pero comparten una misma pregunta sin responder a tiempo: ¿quién verificó, en el servidor, que la persona que pedía ese dato tenía derecho a pedirlo? Cuando la respuesta es que nadie lo verificó y el sistema asumió que si alguien llegaba hasta ahí es porque debía estar ahí, el resultado es el mismo sin importar si el sistema lo construyó una aseguradora de California o una entidad pública de Bogotá.

El caso de la DIAN (2026)

En marzo de 2026 se reportó la venta, en un foro clandestino, de un archivo de 16 gigabytes con datos personales de 18 millones de colombianos, presuntamente extraídos del sistema de agendamiento de citas de la DIAN. La entidad desactivó el sistema mientras investigaba y denunció un intento de extorsión relacionado. Fuentes: ENTER.CO y El Tiempo.

Vale la pena ser honesto sobre lo que todavía no se sabe. Las fuentes públicas describen el resultado (18 millones de registros expuestos) y el origen señalado (una falla en el sistema de citas), pero al momento de escribir esta lectura no confirman si el mecanismo técnico exacto fue una referencia directa insegura a un objeto, como en el caso de First American, o una falla distinta. Esa distinción importa para cualquier ingeniero que quiera aprender del incidente, y reconocer que no está resuelta todavía es parte de leer estas noticias con el criterio que un profesional de ciberseguridad necesita: no todo lo que se reporta en las primeras horas después de un incidente termina siendo exactamente lo que pasó.

El caso de First American Financial (2019)

En mayo de 2019, esta aseguradora estadounidense de títulos de propiedad dejó expuestos más de 800 millones de documentos con datos bancarios, números de seguro social y copias de licencias de conducir. Cualquiera con el enlace a un documento podía cambiar un número en la dirección web y ver el documento siguiente, sin que el sistema comprobara si esa persona tenía permiso sobre él. Fuente: Krebs on Security.

A diferencia del caso de la DIAN, aquí el mecanismo sí está bien documentado: fue una referencia directa insegura a un objeto, la misma falla de fondo que puedes revisar en la lectura «Diseñar y auditar un sistema de control de acceso». Comparar los dos casos deja una lección incómoda: pasaron diecinueve años entre uno y otro, con todo lo que la industria de la ciberseguridad aprendió y publicó en ese tiempo sobre este tipo de falla, y el patrón se repite igual.

Navegación: ← Anterior | Inicio | Siguiente: Panorama tecnológico →

ICIB

Explorador

06 - Control de acceso