Principio de mínimo privilegio

Qué significa mínimo privilegio

El NIST define mínimo privilegio como restringir los privilegios de acceso al mínimo necesario para realizar tareas asignadas. La idea parece sencilla, pero exige responder cuatro preguntas: quién actúa, sobre qué recurso, qué operación necesita y durante cuánto tiempo.

Autenticar confirma una identidad; autorizar decide qué puede hacer esa identidad en ese momento. Iniciar sesión no concede acceso general. Cada solicitud relevante debe evaluarse contra una política del lado confiable del sistema, con denegación por defecto cuando no existe permiso explícito.

El objetivo no es dificultar el trabajo. Es limitar el radio de impacto: una cuenta equivocada, un error de automatización o una credencial comprometida no debería poder leer o modificar todo el entorno.

Personas, servicios y procesos

El principio aplica a usuarios finales, administradores, aplicaciones, integraciones, tareas programadas y herramientas de soporte. Una persona de ventas quizá consulte clientes de su región sin administrar usuarios. Un exportador puede leer vistas específicas y escribir únicamente en su destino. Un proceso de respaldo necesita leer datos y crear copias, no modificar registros operativos.

Las cuentas compartidas borran responsabilidad. Las credenciales individuales o identidades de servicio permiten revocar, rotar y atribuir acciones. Las tareas automáticas no deben ejecutar permanentemente como administrador sólo porque sea más rápido configurarlas.

Permisos sobre datos y funciones

Los permisos se diseñan en varias capas: recurso, operación, registro, campo y contexto. Acceso a una aplicación no implica acceso a todas sus funciones; permiso para consultar una tabla no implica exportarla completa. Cuando existe información sensible, se limita tanto la fuente como la presentación y descarga.

Los roles simplifican administración, pero un rol demasiado amplio sólo oculta privilegios. Se construyen desde tareas reales y se revisan contra excepciones. Las reglas por atributos —como región, unidad o clasificación— pueden complementar roles cuando el contexto varía.

La interfaz ayuda a comunicar capacidades, pero ocultar un botón no es autorización. El servidor, servicio o base de datos que protege el recurso debe verificar cada operación. Las rutas alternativas y API reciben la misma política.

Duración, elevación y emergencias

Un permiso necesario hoy puede ser excesivo mañana. Accesos temporales, elevación justificada y vencimiento automático reducen acumulación. Para tareas administrativas, una identidad cotidiana permanece limitada y el privilegio se activa sólo durante una ventana registrada.

Los accesos de emergencia necesitan un procedimiento: motivo, autorización, duración, monitoreo y revisión posterior. “Por si acaso” no es una política. Si una cuenta de contingencia nunca se prueba o revoca, se convierte en una puerta permanente.

Altas, cambios de puesto, proveedores y bajas deben actualizar permisos como parte del proceso, no mediante recordatorios informales. La identidad sin dueño o el servicio abandonado son deuda operativa y riesgo de seguridad.

Revisión y evidencia

Una matriz de acceso relaciona identidades o roles con recursos y operaciones. Su valor aparece cuando refleja el sistema real. La revisión periódica pregunta si el acceso sigue siendo necesario, si el dueño lo reconoce y si existen combinaciones incompatibles.

Los logs registran decisiones relevantes: identidad, recurso, operación, resultado y contexto suficiente. Deben protegerse contra modificación y evitar secretos. Alertas sobre elevaciones, denegaciones repetidas o uso inusual ayudan a detectar errores y abuso, pero no sustituyen una política correcta.

Las métricas útiles incluyen cuentas sin dueño, permisos vencidos pendientes, credenciales no rotadas, roles con crecimiento injustificado y tiempo para revocar una baja. Contar usuarios no demuestra control.

Errores frecuentes

• Conceder administrador para evitar diagnosticar un permiso faltante.
• Validar acceso sólo en la interfaz y confiar en identificadores enviados por el cliente.
• Reutilizar una misma credencial en ambientes o servicios distintos.
• Permitir que una integración lea tablas completas cuando necesita un subconjunto estable.
• Crear excepciones permanentes sin dueño ni vencimiento.
• Suponer que la red interna hace confiable a cualquier solicitud.

Cómo implementarlo

1. Inventariar identidades humanas y técnicas, recursos y operaciones críticas.
2. Definir tareas y permisos mínimos con denegación por defecto.
3. Separar cuentas, ambientes y funciones incompatibles.
4. Usar permisos temporales y credenciales administradas cuando sea posible.
5. Probar tanto accesos permitidos como denegados y rutas alternativas.
6. Registrar decisiones, revisar periódicamente y revocar por proceso.

El mínimo privilegio no es una configuración única. Es una disciplina de arquitectura y operación que acompaña cada alta, integración, automatización y cambio de sistema.