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 los flujos de trabajo, genera resistencia por parte de los equipos de producto y termina en una retirada silenciosa seis meses después. Esta guía trata sobre cómo hacerlo sin que eso ocurra.
El error más común: el principio de mínimo privilegio como un proyecto “big bang”
Intentar migrar a toda la organización a permisos mínimos en un solo despliegue casi siempre falla. Genera tickets interrumpidos, acceso de emergencia mal documentado y un equipo de seguridad que termina revirtiendo los cambios bajo presión. El enfoque que funciona es incremental y basado en datos de uso real, no en lo que cada rol “debería” necesitar en teoría.
Paso 1 — Mide antes de restringir
Antes de retirar los permisos de alguien, instrumenta lo que realmente se está utilizando:
- Registros de acceso para API, bases de datos y sistemas de archivos durante al menos 30 días.
- Acceda a herramientas de análisis de acceso (AWS Access Analyzer, GCP Policy Analyzer o equivalentes locales) para detectar permisos concedidos pero nunca utilizados.
- Identificar el acceso “heredado” de roles anteriores que la persona ya no posee.
Regla general: si un permiso no se ha utilizado en 90 días, es candidato para su eliminación —no para una alerta, para su eliminación directa, con un proceso de solicitud vía rápida si se necesita más tarde.
Paso 2: Migrar por capas, no por todo el sistema
En lugar de “apliquemos el mínimo privilegio a todo el sistema de pagos”, divídelo por tipo de acceso:
- Acceso de lectura — casi siempre es seguro restringir primero, con bajo riesgo de interrumpir los flujos de producción.
- Acceso de lectura y escritura — necesita una ventana de prueba con fácil reversión.
- Acceso administrativo/de eliminación — los más sensibles; se migran al final y requieren aprobación explícita por cambio.
Esto te permite obtener resultados inmediatos (la mayor parte del riesgo suele concentrarse en el 10-20% de acceso de escritura/administrador) sin obstaculizar las operaciones diarias desde el primer día.
Paso 3: Defensa en profundidad: capas que realmente se refuerzan mutuamente
Una defensa en profundidad mal implementada se reduce a “apilar un par de cortafuegos”. Bien hecha, cada capa cubre el fallo de la anterior:
| Capa | Lo que cubre | Ejemplo concreto |
|---|---|---|
| Red | Segmentación, redes de confianza cero | Microsegmentación entre servicios internos, no solo en el perímetro |
| Identidad | Autenticación fuerte, verificación continua | MFA y autenticación reforzada en acciones sensibles |
| Aplicación | Validación de entradas, control de sesiones | Limitación de tasa, WAF con reglas específicas del negocio (no solo genéricas) |
| Datos | Cifrado, tokenización, Prevención de Pérdida de Datos | Cifrado en reposo y en tránsito, con rotación de claves auditada |
| Supervisión | Detección de anomalías | Alertas sobre el uso de permisos fuera del patrón normal |
La clave: cada capa debe asumir la anterior ya ha fracasado. Si su WAF es su única defensa en la capa de aplicación, no tiene una defensa en profundidad; tiene un punto único de falla con un nombre elegante.
Paso 4: Sistemas heredados: 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, aplíquese:
- Segmentación agresivaaísle el sistema heredado en su propia red, sin acceso directo desde internet o desde sistemas modernos sin un proxy intermediario.
- Controles compensatorios en lugar de modificar el propio sistema (consulte la publicación dedicada a este tema).
- Supervisión reforzada específicamente en ese segmento, ya que no puedes confiar en que el sistema se defienda a sí mismo.
Paso 5 — Comunique el cambio como una mejora, no como fricción
La resistencia al principio de privilegios mínimos casi siempre proviene de equipos que temen quedarse sin acceso en un momento crítico. Mitígala con:
- Un proceso documentado de “acceso de emergencia” aprobado en minutos (no en días), auditado posteriormente.
- Paneles que muestran qué se restringió y por qué, visibles para los equipos afectados.
- Involucrar a los líderes de producto en la priorización de lo que se migra primero.
Lista de verificación de implementación
- ☐ Instrumentar registros de uso real de permisos (mínimo 30 días)
- ☐ Identificar los permisos no utilizados durante más de 90 días
- ☐ Migrar el acceso de lectura primero, el acceso de administrador al final
- ☐ Mapear las 5 capas de defensa en profundidad e identificar cuáles faltan
- ☐ Aislar los sistemas heredados no susceptibles de parcheo en sus propios segmentos
- ☐ Definir un proceso de acceso de emergencia auditado
- ☐ Medir el impacto en la velocidad del equipo antes y 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 cibernética colectiva (Agosto de 2026). Volver a la guía completa.
