07 - Control de acceso

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

---

Control de acceso como disciplina de ingeniería

El control de acceso responde a tres preguntas fundamentales:

1. Identificación: ¿Quién eres? (username, certificado)
2. Autenticación: ¿Cómo lo pruebas? (contraseña, MFA)
3. Autorización: ¿Qué puedes hacer? (permisos, roles)

Como ingeniero, diseñarás sistemas que implementen estas decisiones de manera:

• Consistente: Las mismas reglas se aplican en todos los puntos de entrada
• Auditable: Cada decisión de acceso queda registrada
• Escalable: El modelo funciona con miles de usuarios y recursos
• Mantenible: Los cambios de permisos son predecibles

---

El principio de privilegio mínimo

Definición: Cada entidad (usuario, proceso, sistema) debe tener únicamente los permisos estrictamente necesarios para realizar su función.

Implementación práctica

Contexto	Aplicación del principio
Empleado nuevo	Acceso mínimo al iniciar; se amplía según necesidades reales demostradas
Recepcionista	Puede ver la agenda, pero no acceder a expedientes de RRHH
Técnico de soporte	Puede reiniciar servicios, pero no modificar 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

Beneficios de seguridad

1. Contención de brechas: Cuenta comprometida = daño limitado
2. Reducción de superficie de ataque: Menos permisos = menos vectores
3. Facilita auditoría: Permisos específicos = acciones trazables
4. Previene errores: Menos capacidad de hacer daño accidental

---

Modelos de control de acceso

1. DAC (Discretionary Access Control)

Principio: El propietario del recurso decide quién accede.

Arquitectura:

Usuario propietario → Define ACL → Recurso
                          ↓
                    Otros usuarios

Implementación típica: Access Control Lists (ACL)

{
  "resource": "/documents/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"]}
  ]
}

Casos de uso:

• Sistemas de archivos (POSIX permissions, NTFS)
• Almacenamiento en nube (Google Drive, Dropbox, S3)
• Wikis y documentos colaborativos

Consideraciones de diseño:

Ventaja	Desventaja
Flexible para usuarios	Difícil de auditar a escala
Intuitivo	Propenso a over-sharing
Descentralizado	No hay política central

Vulnerabilidades comunes:

• Acumulación de permisos: Usuarios que cambian de rol van acumulando accesos del rol anterior sin que nadie los retire
• Compartir de más: Compartir un documento con “cualquiera que tenga el enlace” cuando solo debería verlo una persona
• Permisos olvidados: Un ex-empleado sigue teniendo acceso porque nadie revocó sus permisos al salir

---

2. MAC (Mandatory Access Control)

Principio: El sistema impone reglas de acceso basadas en clasificación. Nadie puede cambiar estas reglas.

Arquitectura:

Política central → Clasifica → Sujetos (usuarios)
        ↓                          ↓
   Define reglas              Etiquetas de seguridad
        ↓                          ↓
   Clasifica → Objetos (recursos) → Comparación → Decisión

Modelo Bell-LaPadula (Confidencialidad)

Regla	Descripción	Ejemplo
No Read Up	No leer datos de nivel superior	Confidencial no lee Top Secret
No Write Down	No escribir a nivel inferior	Top Secret no escribe a Público

Modelo Biba (Integridad)

Regla	Descripción	Propósito
No Read Down	No leer de nivel inferior	Evitar contaminación
No Write Up	No escribir a nivel superior	Evitar corrupción

Implementaciones:

• Sistemas operativos modernos (Windows, Linux, iOS, Android) aplican MAC internamente para aislar aplicaciones entre sí
• Los teléfonos usan MAC para que una app de linterna no pueda leer tus mensajes, aunque el propietario del teléfono sea el mismo

Casos de uso:

• Sistemas militares y gubernamentales
• Entornos regulados (salud, finanzas)
• Aplicaciones móviles (cada app está aislada de las demás)

---

3. RBAC (Role-Based Access Control)

Principio: Los permisos se asignan a roles, no a usuarios. Los usuarios heredan permisos del rol asignado.

Arquitectura:

Usuario → asignado a → Rol → tiene → Permisos → sobre → Recursos

Componentes:

1. Usuarios: Entidades que solicitan acceso
2. Roles: Conjuntos de permisos que representan funciones
3. Permisos: Operaciones permitidas sobre recursos
4. Sesiones: Activación de roles por usuario

Jerarquía de roles:

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

Los roles superiores heredan permisos de los inferiores.

Diseño de matriz de permisos:

Rol / Recurso	Usuarios	Productos	Pedidos	Reportes	Config
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=Create, R=Read, U=Update, D=Delete

Cómo funciona la verificación de acceso:

Cuando un usuario intenta realizar una acción:
  1. El sistema obtiene los roles del usuario
  2. Para cada rol, consulta qué permisos tiene
  3. Verifica si alguno de esos permisos cubre la acción solicitada
  4. Si sí → permite la acción
     Si no → rechaza y registra el intento

---

4. ABAC (Attribute-Based Access Control)

Principio: Las decisiones se toman combinando múltiples características del usuario, el recurso y el contexto — no solo el rol.

Ejemplo: Un médico puede ver un historial clínico solo si es su paciente asignado, si está en el hospital, y si es horario laboral. El mismo médico, desde su casa a medianoche, sería bloqueado aunque tenga el rol “Médico”.

ABAC permite políticas muy precisas pero también es mucho más complejo de diseñar y mantener. Se usa en sistemas avanzados; los modelos DAC, MAC y RBAC cubren la mayoría de los casos prácticos.

---

Comparación de 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

---

Diseño de sistemas de control de acceso

Proceso de diseño

1. Identificar recursos a proteger
2. Definir operaciones posibles sobre cada recurso
3. Identificar actores (usuarios, sistemas, servicios)
4. Mapear funciones a roles (para RBAC)
5. Definir políticas de acceso
6. Implementar enforcement en todos los puntos de entrada
7. Diseñar auditoría de decisiones de acceso

Principio de centralización

La verificación de permisos debe ocurrir en el servidor, no en la interfaz de usuario. Si solo se controla en la pantalla (ocultando botones), cualquiera con conocimientos básicos puede saltarse ese control enviando la solicitud directamente al servidor.

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

Anti-patrones a evitar

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
Un solo usuario con todos los permisos compartido entre varios	Si algo sale mal, no se sabe quién lo hizo	Cada persona con su propia cuenta y 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 permisos periódicamente	Personas con acceso que ya no necesitan o ya no trabajan allí	Revisión periódica y revocar al cambiar de rol o salir

---

Caso de estudio: Diseño para sistema universitario

Requisitos:

• 50,000 estudiantes
• 2,000 profesores
• 500 administrativos
• Múltiples sistemas: notas, matrícula, biblioteca, correo

Diseño RBAC:

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

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 otros	-	-	CRUD	R
Usuarios	-	-	R	CRUD

---

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
RBAC	Modelo donde permisos se asignan a roles, no a usuarios
ABAC	Variante avanzada que combina múltiples atributos del usuario, recurso y contexto para tomar decisiones
Privilegio mínimo	Principio de otorgar solo permisos necesarios
ACL	Lista de permisos asociada a un recurso

---

Ponte a prueba

1. Análisis de riesgos: En el sistema universitario descrito, ¿qué pasaría si un estudiante lograra obtener el rol de profesor? Identifica al menos 3 riesgos y propón controles.

2. Selección de modelo: Para cada escenario, indica qué modelo (DAC, MAC, RBAC, ABAC) sería más apropiado:

   • Sistema de archivos de una agencia de inteligencia
   • Plataforma de colaboración de documentos (tipo Google Docs)
   • Hospital con acceso a historiales según departamento, turno y emergencia
   • Aplicación empresarial con 20 departamentos diferentes

---

Laboratorio práctico: Diseño de sistema RBAC

Tiempo estimado: 120 minutos Requisitos: Navegador web

Objetivo

Diseñar un sistema de control de acceso basado en roles (RBAC) completo para un sistema de e-commerce, incluyendo jerarquía de roles, matriz de permisos, análisis de decisiones de acceso, y diseño de auditoría.

Parte 1: Diagrama de jerarquía de roles (20 min)

Un sistema de e-commerce necesita los siguientes roles:

• Invitado: Puede navegar el catálogo sin autenticarse
• Cliente: Puede ver productos, crear pedidos, ver y cancelar sus propios pedidos
• Vendedor: Todo lo de Cliente, más crear/editar productos y ver todos los pedidos
• Administrador: Todo lo de Vendedor, más gestionar usuarios, eliminar productos, y ver reportes
• Auditor: Puede ver todos los recursos y reportes, pero no puede modificar nada

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

• Los 5 roles organizados de menor a mayor privilegio
• Flechas de herencia (qué rol hereda de cuál)
• Para el rol Auditor, indica si hereda de algún rol o es independiente. 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é el rol Auditor no debería heredar de Administrador, aunque ambos pueden “ver todo”?

Parte 2: Matriz de permisos (25 min)

Los recursos del sistema y sus operaciones posibles son:

Recurso	Operaciones
Usuarios	Crear, Leer, Actualizar, Eliminar
Productos	Crear, Leer, Actualizar, Eliminar
Pedidos (propios)	Crear, Leer, Cancelar
Pedidos (todos)	Leer, Actualizar
Reportes	Ver ventas, Ver usuarios

Ejercicio 2.1: Completa la siguiente matriz de permisos siguiendo el mismo diseño del caso de estudio de la clase. Para cada celda, indica qué operaciones puede realizar el rol sobre ese recurso usando la notación CRUD; usa - si no tiene ningún acceso:

Recurso	Invitado	Cliente	Vendedor	Administrador	Auditor
Usuarios
Productos
Pedidos (propios)
Pedidos (todos)
Reportes

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

Ejercicio 2.2: Recorre la matriz columna por columna. ¿Qué patrón observas en la progresión de operaciones disponibles de izquierda (Invitado) a derecha (Administrador)?

Ejercicio 2.3: Si un usuario tiene los roles Cliente y Auditor simultáneamente, ¿qué operaciones acumula sobre cada recurso? Representa el resultado combinado usando la misma notación CRUD.

Parte 3: Análisis de decisiones de acceso (30 min)

El sistema tiene los siguientes usuarios:

Usuario	Roles
Ana	Cliente
Carlos	Vendedor
Diana	Administrador
Eduardo	Auditor
Fernanda	Cliente, Auditor

Ejercicio 3.1: Para cada solicitud de acceso, determina si se permite o deniega. Justifica tu respuesta indicando qué rol otorga (o no) el permiso necesario:

#	Usuario	Acción	Recurso	¿Permitido?	Justificación
1	Ana	Crear	Pedido propio
2	Ana	Leer	Pedido de Carlos
3	Carlos	Actualizar	Producto #42
4	Carlos	Eliminar	Producto #42
5	Eduardo	Leer	Reporte de ventas
6	Eduardo	Eliminar	Usuario Ana
7	Fernanda	Leer	Todos los pedidos
8	Fernanda	Crear	Producto nuevo
9	Diana	Eliminar	Usuario Carlos
10	Ana	Ver	Reporte de usuarios

Ejercicio 3.2: Carlos intenta crear un producto nuevo en el sistema. Traza paso a paso el proceso de autorización:

1. ¿Carlos está registrado e identificado en el sistema?
2. ¿Qué roles tiene Carlos?
3. ¿Qué permiso se necesita para crear un producto?
4. ¿Alguno de sus roles (directos o heredados) incluye ese permiso?
5. ¿Se permite o deniega la acción?

Parte 4: Análisis de seguridad (25 min)

Ejercicio 4.1: Escalamiento de privilegios

Un atacante ha comprometido la cuenta de Ana (Cliente). Analiza cada escenario:

Escenario de ataque	¿Funciona?	¿Por qué?	Mitigación propuesta
Cambiar su propio rol de Cliente a Administrador en el frontend
Llamar directamente a DELETE /api/users/1
Modificar el campo carrito_id en la URL para ver carritos de otros usuarios
Crear múltiples cuentas para acumular permisos

Ejercicio 4.2: Separación de funciones (Separation of Duties)

En un sistema financiero, es importante que ninguna persona pueda completar una transacción crítica sola. Analiza:

1. ¿Debería el mismo rol poder crear y aprobar una orden de compra? ¿Por qué?
2. Diseña dos roles (purchase_requester y purchase_approver) con sus permisos. ¿Qué restricción adicional necesitas más allá de los permisos?
3. ¿Qué es el “permission creep” (acumulación de permisos)? ¿Cómo lo prevendrías?

Ejercicio 4.3: Principio de menor privilegio

Revisa la matriz de permisos que creaste en la Parte 2. ¿Hay algún rol que tenga más permisos de los estrictamente necesarios? Si es así, propón ajustes.

Parte 5: Diseño de auditoría (20 min)

Cada decisión de acceso debe registrarse para cumplimiento y detección de incidentes.

Ejercicio 5.1: Diseña el formato de una entrada de log de auditoría. Completa la tabla con los campos que consideres necesarios:

Campo	Tipo	Ejemplo	¿Por qué es necesario?
timestamp	fecha/hora	2025-01-15T10:30:00Z
user_id	texto	usr_123
username	texto	ana@empresa.com
action	texto	POST
resource	texto	/api/products
decision	texto	denied

Agrega al menos 3 campos adicionales que consideres importantes para una investigación de seguridad.

Ejercicio 5.2: Genera entradas de log de ejemplo para estas situaciones:

1. Diana (Administrador) elimina exitosamente al usuario Eduardo
2. Ana (Cliente) intenta acceder al reporte de ventas y es denegada
3. Carlos (Vendedor) crea un producto nuevo exitosamente

Ejercicio 5.3: Un analista de seguridad revisa los logs y encuentra lo siguiente:

[2025-01-15T10:00:00Z] user=ana action=GET resource=/api/orders/1 decision=granted
[2025-01-15T10:00:01Z] user=ana action=GET resource=/api/orders/2 decision=denied
[2025-01-15T10:00:01Z] user=ana action=GET resource=/api/orders/3 decision=denied
[2025-01-15T10:00:02Z] user=ana action=GET resource=/api/orders/4 decision=denied
[2025-01-15T10:00:02Z] user=ana action=GET resource=/api/orders/5 decision=denied
...
[2025-01-15T10:00:10Z] user=ana action=GET resource=/api/orders/100 decision=denied

• ¿Qué está intentando hacer Ana?
• ¿Qué tipo de ataque es este?
• ¿Qué alerta automática diseñarías para detectar este patrón?

Entregable

Entrega un documento (PDF o Word) que incluya:

1. Diagrama de jerarquía de roles con justificación de la posición del Auditor
2. Matriz de permisos completa (recursos × roles con notación CRUD) y análisis del patrón observado
3. Tabla de decisiones de acceso con justificaciones y traza del proceso de autorización
4. Análisis de seguridad: escenarios de escalamiento, separación de funciones, y menor privilegio
5. Diseño de auditoría: formato de log, entradas de ejemplo, y análisis del patrón sospechoso

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	25
Análisis de escenarios de seguridad	20
Diseño de auditoría completo	20

Reflexión

Después de completar el laboratorio:

• ¿Por qué es importante verificar permisos en el servidor y no solo en el frontend?
• ¿Cómo manejarías una situación donde necesitas revocar inmediatamente los permisos de un usuario?
• ¿Qué pasaría si un atacante logra modificar la tabla de roles en la base de datos?

---

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