Mínimo Privilegio y Zero Trust
Need-to-know, least privilege y arquitectura Zero Trust: "nunca confíes, siempre verifica"
Principio de Mínimo Privilegio
Cada sujeto (usuario, proceso, servicio) debe tener acceso solo a los recursos que necesita para cumplir su función, y nada más. Es uno de los principios de diseño seguro más fundamentales.
¿Por qué importa?
Si un proceso comprometido solo tiene acceso a la base de datos de usuarios de una funcionalidad, el atacante no puede acceder a los datos de pagos. El daño queda contenido.
❌ Violación del principio
- • App de comentarios con acceso a toda la BD
- • Dev con permisos de producción permanentes
- • Lambda con rol AdministratorAccess
- • Usuario de solo lectura con permisos de escritura
✅ Aplicación correcta
- • App de comentarios: solo tabla comments (SELECT, INSERT)
- • Dev: acceso a producción JIT, solo durante incidentes
- • Lambda: rol con solo los permisos S3 del bucket específico
- • Roles separados para lectura y escritura
Need-to-Know
Variante del mínimo privilegio aplicada a información clasificada: el acceso se otorga solo si la persona necesita ese dato específico para su rol actual. Tener el clearance no basta; también se requiere necesidad operacional.
Ejemplo:
Un analista de inteligencia con clearance SECRET puede acceder al informe A pero no al B, aunque ambos sean SECRET, si el informe B no es necesario para su tarea actual.
Arquitectura Zero Trust
El modelo perimetral tradicional asume que todo dentro de la red corporativa es de confianza. Zero Trust (John Kindervag, Forrester, 2010) invierte esto: "nunca confíes, siempre verifica" independientemente de la ubicación de red.
Los 3 principios de Zero Trust (NIST SP 800-207):
Verificar explícitamente
Autenticar y autorizar siempre, basándose en todos los datos disponibles: identidad, ubicación, dispositivo, servicio, carga de trabajo, anomalías.
Usar mínimo privilegio
Limitar el acceso con políticas adaptativas just-in-time (JIT) y just-enough-access (JEA). Reducir superficie de ataque lateral.
Asumir la brecha
Diseñar como si el atacante ya estuviera dentro. Minimizar el radio de explosión, segmentar, cifrar, monitorear todo.
Componentes de una arquitectura ZT
Identity Provider (IdP)
Okta, Azure AD, Auth0. Base de toda decisión de acceso. MFA obligatorio.
Policy Engine + Policy Administrator
Motor que evalúa la solicitud de acceso contra las políticas definidas.
Microsegmentación
Dividir la red en zonas mínimas. Si una VM cae, el lateral movement queda bloqueado.
Device Trust
Solo dispositivos gestionados y conformes (MDM, EDR) pueden acceder a recursos sensibles.
Software-Defined Perimeter (SDP)
Túneles dinámicos por recurso/usuario. Cloudflare Access, Zscaler ZPA, BeyondCorp.
Continuous Monitoring
SIEM, UEBA: detectar desviaciones del comportamiento normal en tiempo real.
Implementación Práctica
# AWS: IAM policy de mínimo privilegio
# MAL: AdministratorAccess en una función Lambda
# BIEN: Solo los permisos necesarios
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/uploads/*"
}
Revisar y auditar permisos trimestralmente — eliminar accesos no usados en 90 días.
Implementar JIT access para cuentas privilegiadas (AWS SSO, CyberArk, BeyondTrust).
Aplicar microsegmentación en la red con Network Policies en Kubernetes.
Separar entornos: desarrollo, staging y producción con cuentas/subscriptions distintas.
MFA obligatorio para todos los accesos privilegiados y de gestión.
Auditar y registrar todos los accesos a datos sensibles (SIEM).
Siguiente Paso
Profundiza en los modelos de control de acceso: DAC, MAC, RBAC y ABAC
Modelos de Control de Acceso →