Tema 10

10. Principio de mínimo privilegio, segregación de funciones y acceso just-in-time

Definir quién puede hacer qué no alcanza. También hay que preguntarse cuánto acceso necesita realmente, durante cuánto tiempo y qué combinaciones de permisos resultan peligrosas. El diseño moderno de autorización no busca solo habilitar tareas, sino reducir superficie de abuso y limitar el impacto de errores o compromisos.

Objetivo Reducir privilegios excesivos y riesgos operativos
Enfoque Conceptual, operativo y orientado a gobierno de acceso
Resultado Aplicar privilegio mínimo, SoD y JIT con criterio

10.1 Introducción

Muchos incidentes graves no ocurren porque un atacante obtuvo “todos” los permisos desde el inicio, sino porque encontró una cuenta con más privilegios de los necesarios o pudo combinar accesos que nunca debieron convivir en una misma identidad. Eso convierte al diseño de privilegios en un problema central de seguridad.

En este tema veremos tres principios estrechamente relacionados:

  • Mínimo privilegio: otorgar solo lo necesario.
  • Segregación de funciones: evitar combinaciones riesgosas de poder.
  • Just-in-time access: conceder acceso elevado solo cuando realmente se necesita y por tiempo limitado.

Estos principios no son meras recomendaciones abstractas. Son herramientas concretas para reducir impacto si una cuenta se compromete, si un usuario comete un error o si un proceso de negocio se diseña sin controles cruzados suficientes.

10.2 Qué es el principio de mínimo privilegio

El principio de mínimo privilegio establece que una identidad debería recibir únicamente los permisos necesarios para cumplir su función y nada más. Esa necesidad debe evaluarse en alcance, tipo de acción y tiempo de uso.

En otras palabras, no basta con preguntar “¿puede trabajar?”. También hay que preguntar:

  • ¿Realmente necesita este permiso?
  • ¿Lo necesita siempre o solo en ciertos casos?
  • ¿Lo necesita sobre todos los recursos o solo sobre algunos?
  • ¿Lo necesita con capacidad total o con alcance parcial?

El privilegio mínimo busca que la respuesta a estas preguntas sea lo más restringida posible sin impedir la operación legítima.

10.3 Por qué los privilegios excesivos son tan peligrosos

Un permiso amplio puede parecer cómodo en el corto plazo porque reduce fricción administrativa, pero aumenta mucho el riesgo acumulado. Si una cuenta es comprometida, el atacante hereda ese exceso de capacidad. Si el usuario se equivoca, el daño posible también crece.

Los privilegios excesivos suelen amplificar:

  • Movimiento lateral.
  • Exfiltración de datos.
  • Cambios no autorizados.
  • Escalada de privilegios indirecta.
  • Riesgo interno malicioso o negligente.
El problema no es solo quién tiene acceso, sino cuánto daño puede causar ese acceso si algo sale mal.

10.4 Mínimo privilegio en usuarios humanos

Aplicado a usuarios humanos, este principio implica evitar cuentas con más capacidades de las necesarias para su puesto real. Algunos ejemplos prácticos:

  • Un analista puede consultar reportes, pero no administrar usuarios.
  • Un operador puede reiniciar servicios, pero no cambiar políticas globales.
  • Un responsable regional puede ver solo recursos de su región.
  • Un revisor puede aprobar, pero no crear ni modificar el objeto que aprueba.

Esto parece evidente, pero en la práctica muchas organizaciones entregan roles amplios “por las dudas”, para evitar tickets futuros. Ese hábito es uno de los principales enemigos del control de acceso sano.

10.5 Mínimo privilegio en cuentas técnicas y servicios

Las cuentas no humanas merecen atención especial. Servicios, pipelines, bots, jobs y microservicios suelen operar sin supervisión humana directa y a veces con privilegios muy altos. Si una credencial de este tipo se expone, el impacto puede ser enorme.

Aplicar privilegio mínimo aquí implica:

  • Limitar scopes y acciones permitidas.
  • Restringir acceso a recursos concretos.
  • Evitar credenciales compartidas entre múltiples componentes.
  • Reducir duración y reutilización de secretos.
  • Registrar ownership claro de cada identidad técnica.

10.6 Privilegio mínimo no significa bloquear la operación

Uno de los errores más frecuentes es interpretar mínimo privilegio como sinónimo de incomodidad o rigidez extrema. El objetivo no es entorpecer el trabajo, sino conceder acceso de forma precisa.

Un diseño maduro busca equilibrio: suficiente acceso para operar con eficiencia, pero no tanto como para transformar cada identidad en un punto de alto impacto. Este equilibrio exige conocimiento del negocio y revisión continua, no solo políticas genéricas.

10.7 Qué es la segregación de funciones

La segregación de funciones, o Separation of Duties (SoD), consiste en evitar que una misma identidad concentre capacidades que, combinadas, generan un riesgo excesivo. La idea es introducir controles cruzados para que una acción sensible no dependa de una sola persona o cuenta con poder total.

Este principio es clave en finanzas, administración de sistemas, gobierno corporativo y procesos regulados, pero también aplica en productos digitales comunes.

10.8 Ejemplos de conflictos de segregación

Algunos ejemplos típicos de combinaciones problemáticas son:

  • Crear proveedores y aprobar pagos a esos mismos proveedores.
  • Desarrollar cambios y aprobar su despliegue en producción sin revisión independiente.
  • Crear usuarios y asignarles privilegios máximos sin control adicional.
  • Emitir una transacción y aprobarla con la misma identidad.
  • Administrar logs y, al mismo tiempo, borrar trazas de auditoría sensibles.

La clave no está solo en cada permiso aislado, sino en la combinación de permisos dentro del mismo sujeto.

10.9 SoD estática y SoD dinámica

La segregación de funciones puede implementarse de al menos dos maneras:

  • SoD estática: ciertas combinaciones de roles o permisos nunca pueden coexistir en la misma identidad.
  • SoD dinámica: la misma identidad podría tener distintos permisos, pero no puede usarlos simultáneamente dentro del mismo flujo o caso.

La SoD estática es más fácil de entender y auditar. La dinámica puede ser más flexible, pero exige mayor control contextual y mejor trazabilidad.

10.10 Mínimo privilegio y SoD no son lo mismo

Ambos principios están relacionados, pero no son equivalentes. El privilegio mínimo busca reducir amplitud de acceso. La segregación de funciones busca evitar combinaciones peligrosas de poder.

Una cuenta podría tener pocos permisos en cantidad y aun así concentrar una combinación riesgosa. Del mismo modo, una cuenta podría no violar SoD formal, pero seguir teniendo demasiado alcance general. Por eso ambos principios se complementan.

10.11 Qué es el acceso just-in-time (JIT)

El acceso just-in-time consiste en conceder privilegios elevados solo cuando realmente se necesitan y durante una ventana temporal acotada. En lugar de dejar permisos críticos activos de forma permanente, se habilitan bajo demanda y con expiración explícita.

Este enfoque resulta especialmente útil para accesos administrativos, tareas excepcionales y operación privilegiada de infraestructura.

La lógica es simple: si una identidad no necesita privilegios altos el 95% del tiempo, no tiene sentido dejarlos disponibles el 100% del tiempo.

10.12 Por qué JIT reduce riesgo

JIT reduce riesgo por varios motivos:

  • Disminuye la ventana temporal en que un atacante puede abusar de privilegios altos.
  • Reduce exposición de cuentas privilegiadas permanentes.
  • Favorece trazabilidad porque las elevaciones suelen registrarse explícitamente.
  • Obliga a justificar o contextualizar accesos excepcionales.

Además, al combinarse con aprobación o step-up authentication, JIT introduce una capa adicional de control sobre operaciones críticas.

10.13 Ejemplos prácticos de JIT

  • Un administrador solicita privilegios de base de datos por una hora para una tarea de mantenimiento.
  • Un operador obtiene acceso temporal a logs sensibles para investigar un incidente.
  • Un equipo de soporte eleva permisos solo durante un ticket activo.
  • Un pipeline recibe credenciales efímeras para desplegar, en lugar de secretos permanentes.

Estos casos muestran que JIT no es solo una idea de gobernanza; también es una práctica técnica concreta para reducir credenciales privilegiadas persistentes.

10.14 JIT y credenciales efímeras

El acceso just-in-time suele apoyarse en credenciales efímeras: tokens, certificados o permisos temporales con vencimiento corto. Esto es especialmente útil en cloud, infraestructura y automatización.

En lugar de secretos permanentes almacenados durante meses, se emiten capacidades de corta vida y alcance controlado. Si se exponen, la ventana de explotación es mucho menor. Esta idea conecta directamente con los principios de Zero Trust y modernización del acceso privilegiado.

10.15 Aprobación, justificación y auditoría

En muchos contextos, JIT funciona mejor cuando la elevación de privilegio no es totalmente silenciosa. Puede requerir:

  • Justificación del motivo.
  • Aprobación de un superior o responsable.
  • Registro de duración y alcance concedido.
  • Trazabilidad de acciones realizadas durante la ventana privilegiada.

No todos los sistemas necesitan esta formalidad, pero en entornos sensibles ayuda a conectar seguridad técnica con gobernanza operativa.

10.16 Riesgos de implementar mal estos principios

Aplicar mal privilegio mínimo, SoD o JIT también genera problemas. Algunos ejemplos:

  • Reducir permisos sin entender el flujo real de trabajo y bloquear operación crítica.
  • Diseñar reglas tan complejas que nadie pueda administrarlas.
  • Crear excepciones permanentes que destruyen el objetivo del control.
  • Implementar JIT sin expiración real o sin trazabilidad suficiente.
  • Delegar aprobaciones sin criterios claros y convertir el proceso en un trámite automático.

Estos principios agregan valor cuando se integran al modo real de trabajo, no cuando se quedan en un documento idealizado.

10.17 Señales de que un sistema tiene exceso de privilegios

  • Muchas cuentas tienen permisos de administrador “por si acaso”.
  • Existen roles amplios con poca diferenciación funcional.
  • Nadie puede explicar con claridad por qué ciertos accesos siguen activos.
  • Los usuarios cambian de puesto, pero conservan permisos históricos.
  • Las cuentas técnicas tienen acceso a más recursos de los necesarios.
  • Las revisiones de acceso casi nunca eliminan privilegios.

Estas señales suelen indicar deuda de gobierno de acceso, incluso si el sistema “funciona” desde el punto de vista operativo.

10.18 Relación con cumplimiento, auditoría y riesgo

Privilegio mínimo y segregación de funciones aparecen con frecuencia en marcos de cumplimiento porque ayudan a demostrar control interno razonable. Pero su valor no depende solo de auditores o regulaciones.

Desde el punto de vista de riesgo, estos principios reducen:

  • Fraude interno.
  • Errores críticos no detectados.
  • Abuso de cuentas comprometidas.
  • Superficies de impacto innecesarias.

Por eso conviene verlos como parte de la arquitectura de seguridad, no solo como requisitos de compliance.

10.19 Qué debes recordar de este tema

  • El mínimo privilegio busca dar solo el acceso necesario y durante el tiempo necesario.
  • La segregación de funciones evita combinaciones peligrosas de poder en una sola identidad.
  • El acceso just-in-time reduce privilegios permanentes y exposición temporal.
  • Estos principios aplican tanto a usuarios humanos como a cuentas técnicas.
  • El exceso de privilegios amplifica el impacto de errores, abuso interno y compromisos externos.
  • Aplicarlos bien exige entender el negocio y revisar continuamente los accesos reales.

10.20 Conclusión

Una buena autorización no consiste solo en permitir o denegar. También consiste en limitar, separar y acotar el poder que cada identidad acumula a lo largo del tiempo. Mínimo privilegio, segregación de funciones y acceso just-in-time son herramientas esenciales para lograrlo y para convertir el control de acceso en una verdadera reducción de riesgo.

En el próximo tema entraremos en IAM: aprovisionamiento, desprovisionamiento y ciclo de vida de identidades, porque muchos problemas de privilegios nacen y persisten por fallas en cómo se crean, cambian y retiran accesos.