En agosto de 2026, más de 150 organizaciones —Anthropic, Microsoft, Google, AWS, Cisco, bancos, gobiernos y empresas de ciberseguridad de todo el mundo, incluido nuestro propio equipo en Faraday — firmado una carta abierta impulsada por OpenAI pide a cada organización algo que parece simple pero que, en la práctica, es donde mueren la mayoría de los proyectos de seguridad:
“Actualizar o reemplazar sistemas para incorporar el principio de menor privilegio, controles de acceso sólidos y defensa en profundidad.”
El problema no es entender el concepto. Es que implementarlo mal rompe flujos de trabajo, genera resistencia de los equipos de producto, y termina en un rollback silencioso seis meses después. Esta guía es sobre cómo hacerlo sin que eso pase.
El error más común: least privilege como proyecto de "big bang"
Intentar migrar toda la organización a permisos mínimos en un solo esfuerzo casi siempre falla. Genera tickets rotos, accesos de emergencia mal documentados, y un equipo de seguridad que termina revirtiendo cambios bajo presión. El enfoque que funciona es incremental y basado en datos de uso real, no en lo que "debería" necesitar cada rol.
Paso 1: Mide antes de restringir
Antes de sacarle permisos a nadie, instrumentá qué se usa realmente:
- Logs de acceso a APIs, bases de datos y sistemas de archivos durante al menos 30 días.
- Herramientas de "access analysis" (AWS Access Analyzer, GCP Policy Analyzer, o equivalentes on-prem) para detectar permisos otorgados pero nunca ejercidos.
- Identificar accesos "heredados" de roles anteriores que la persona ya no ocupa.
Regla práctica: si un permiso no se usó en 90 días, es candidato a remoción — no a alerta, a remoción directa con proceso de solicitud rápida si se necesita después.
Paso 2: Migrar por capas, no por sistema completo
En vez de "vamos a aplicar least privilege a todo el sistema de pagos", dividí por tipo de acceso:
- Acceso de lectura — casi siempre se puede restringir primero, bajo riesgo de romper flujos productivos.
- Acceso de lectura y escritura — requiere ventana de prueba con rollback fácil.
- Acceso administrativo/de eliminación — el más sensible, migrar al final y con aprobación explícita por cambio.
Esto te da wins rápidos (la mayoría del riesgo suele estar concentrado en el 10-20% de accesos de escritura/admin) sin bloquear operación diaria desde el día uno.
Paso 3: Defense in depth: capas que realmente se refuerzan entre sí
Defense in depth mal implementado es simplemente "poner varios firewalls". Bien implementado, cada capa cubre el fallo de la anterior:
| Capa | Lo que cubre | Ejemplo concreto |
|---|---|---|
| Red | Segmentación, zero trust networking | Microsegmentación entre servicios internos, no solo perímetro |
| Identidad | Autenticación fuerte, verificación continua | MFA + step-up authentication en acciones sensibles |
| Aplicación | Validación de input, control de sesión | Rate limiting, WAF con reglas específicas del negocio (no solo genéricas) |
| Datos | Cifrado, tokenización, DLP | Cifrado en reposo Y en tránsito, con rotación de llaves auditada |
| Supervisión | Detección de anomalías | Alertas sobre uso de permisos fuera de patrón habitual |
La clave: cada capa debe asumir la anterior ya fallo. Si tu WAF es tu única defensa de aplicación, no tenés defense in depth, tenés un solo punto de falla con nombre elegante.
Paso 4: Sistemas legacy: el caso especial
La carta reconoce explícitamente los sistemas que “no se pueden parchear sin interrumpir servicios esenciales” —hospitales, infraestructura eléctrica, sistemas industriales—. Para estos casos, aplicá:
- Segmentación agresivaaislar el sistema legacy en su propia red, sin acceso directo desde internet ni desde sistemas modernos sin proxy intermediario.
- Controles compensatorios en lugar de modificar el sistema en sí (ver el post dedicado a este tema).
- Monitereo reforzado específicamente en ese segmento, ya que no podés confiar en que el sistema se defienda solo.
Paso 5: Comunicar el cambio como mejora, no como fricción
La resistencia a least privilege casi siempre viene de equipos que temen quedar bloqueados en un momento crítico. Mitigalo con:
- Proceso de "acceso de emergencia" documentado y con aprobación en minutos (no días), auditado después.
- Dashboards de qué se restringió y por qué, visibles para los equipos afectados.
- Involucrar a los leads de producto en la priorización de qué migrar primero.
Checklist de implementación
- ☐ Instrumentar logs de uso real de permisos (mínimo 30 días)
- ☐ Identificar permisos no usados en 90+ días
- ☐ Migrar accesos de lectura primero, admin al final
- ☐ Mapear las 5 capas de defense in depth y detectar cuáles faltan
- ☐ Aislar sistemas legacy no parcheables en segmentos propios
- ☐ Definir proceso de acceso de emergencia auditado
- ☐ Medir impacto en velocidad de equipos antes/después del cambio
Parte de una serie sobre cómo poner en práctica los principios de Carta abierta de OpenAI sobre la defensa colectiva en ciberseguridad (Agosto de 2026). Volver a la guía completa.
