Terraform es excelente para declarar y reproducir infraestructura. El problema empieza cuando se le atribuye una propiedad que no tiene: capacidad de control de seguridad en tiempo real. En la práctica corporativa, el control se rompe cuando alguien “toca la consola” (o hace un cambio con CLI) y ese cambio no queda gobernado por el flujo de IaC.
El resultado no suele ser un incidente inmediato, sino algo más peligroso: exposición silenciosa, evidencias inconsistentes y una falsa sensación de cumplimiento porque “en el repo está bien”. Eso es drift real: la realidad en cloud diverge del código y, por extensión, de lo que el equipo cree que está desplegado.
Qué salió mal: el día que el cambio urgente dejó una puerta abierta
Un patrón recurrente: hay una caída parcial o una degradación de servicio, alguien con permisos amplios entra a la consola para “desbloquear” rápido, y modifica una regla de seguridad, un rol IAM o una ruta de red. A veces es con buena intención (restaurar conectividad), otras por presión de negocio (habilitar acceso desde un proveedor). El cambio se hace “temporal”… y se queda.
El problema no es el ajuste en sí: es que se hizo fuera de Terraform, sin revisión, sin trazabilidad en el repo y sin un mecanismo automático que lo detecte o lo revierta. Semanas después, el equipo ejecuta un terraform apply por otro motivo y, dependiendo de cómo esté modelado el recurso, ocurre una de dos cosas: Terraform no ve el cambio (porque no gestiona ese atributo, o porque el recurso fue cambiado/creado fuera) o intenta “corregirlo” y provoca una interrupción inesperada.
En auditorías internas esto se ve como inconsistencias: el control exige una postura (por ejemplo, “sin puertos administrativos abiertos a Internet”), pero el entorno tiene excepciones sin ticket, sin justificación y sin caducidad. El punto crítico es cultural y operativo: la consola se convierte en un canal de cambio sin gobierno.
El drift no es un detalle: rompe tfstate, evidencias y expectativas de control
tfstate no es una fuente de verdad de seguridad; es un registro del último estado conocido por Terraform. Si alguien cambia una regla en un Security Group, un NSG o un firewall gestionado fuera del ciclo de IaC, el tfstate queda “bien” mientras la nube queda “distinta”. En una investigación, esa diferencia se traduce en horas de pérdida para entender qué está realmente aplicado.
El caso típico en empresa es el drift en reglas de seguridad: abrir temporalmente un puerto de administración, ampliar un rango CIDR “para probar”, o añadir una excepción porque un tercero “no llega”. Cuando esto no vuelve al código, el equipo pierde la capacidad de asegurar de forma consistente los entornos (prod vs preprod) porque la consola crea configuraciones únicas e irrepetibles.
Otro clásico: drift en IAM. Se añade una policy inline “de emergencia”, se adjunta un permiso administrado demasiado amplio o se cambia una trust policy para destrabar un assume-role. El efecto es peor que en red: la exposición puede ser lateral (otros servicios, otros datos) y es más difícil de detectar a simple vista. Y en networking ocurre igual: rutas, peering, reglas de egress o parámetros de un WAF que se tocan para “bajar falsos positivos”, sin dejar rastro en el pipeline.
Señales operativas que suelen aparecer cuando el drift ya está haciendo daño:
- “Terraform quiere cambiar cosas que nadie tocó”.
Esto suele salir en PRs o planes con cambios inesperados. En la práctica, es la primera pista de que la consola está siendo usada como canal de cambio y Terraform está intentando volver al mundo declarado, a veces en componentes críticos.
- “En el repo está cerrado, pero el escáner ve puertos abiertos”.
Cuando seguridad valida postura con herramientas externas (scanner, revisión de configuración, hallazgos de Config/Policy), aparecen discrepancias. Es el momento en que se descubre que el control real nunca estuvo en Terraform, sino en la disciplina y los guardrails.
Cómo se detecta cuando ya ocurrió: auditoría continua, no “esperar al próximo apply”
La detección efectiva de drift de seguridad requiere señales fuera de Terraform. En AWS, AWS Config permite evaluar configuraciones contra reglas (managed o custom) y disparar alertas cuando se viola una condición, por ejemplo, “Security Groups no deben exponer 0.0.0.0/0 en puertos administrativos” o “S3 debe bloquear acceso público”. En Azure, el rol equivalente lo ocupa Azure Policy, con evaluación y remediación para recursos que se desvían. En GCP, Org Policy y auditoría de cambios complementan ese control.
La clave no es “tener Config/Policy activado”, sino operarlo con intención: qué se considera drift relevante, quién recibe alertas, y qué SLA tiene la corrección. En empresas, un hallazgo sin dueño termina siendo ruido; un hallazgo con dueño y una ventana de corrección definida termina siendo control.
Cómo hacerlo en la práctica en un entorno AWS (orientado a ejecución, no a teoría):
- Activar AWS Config en cuentas y regiones relevantes y agregarlo a nivel organización.
Si Config solo está en una cuenta o en una región, el drift migra a donde no se mira. Operativamente, esto se traduce en “controles que funcionan en prod, pero no en cuentas satélite”. Asegura cobertura donde realmente se crean recursos.
- Configurar reglas que reflejen tus no-negociables de seguridad (por ejemplo, no permitir puertos 22/3389 desde Internet, exigir cifrado, prohibir recursos públicos).
No intentes modelar toda tu postura en el primer día. Empieza por lo que más se rompe con cambios urgentes en consola: reglas de entrada/salida y exposición pública. Es donde el drift genera impacto inmediato y suele aparecer en incidentes.
- Integrar las no conformidades con tu operación: ticket automático, canal de alertas y ruta de escalado.
Un hallazgo de Config sin flujo de trabajo no corrige nada. Lo que funciona en empresas es: alerta → ticket con contexto (recurso, cambio, actor) → verificación de negocio → revertir o formalizar la excepción en código con caducidad.
Validación práctica: en AWS revisa el Timeline de AWS Config del recurso afectado para confirmar cuándo cambió, qué atributo cambió y si hubo remediación. Además, correlaciona con CloudTrail para identificar el principal (usuario/rol) que ejecutó el cambio. Esa correlación es lo que convierte una sospecha en evidencia operable.
Cuando alguien toca la consola: escenarios típicos que degradan seguridad sin que nadie lo note
En la vida real, la mayoría de los cambios “manuales” no son maliciosos: son atajos bajo presión. Por eso son tan peligrosos: se normalizan. Un ejemplo recurrente es abrir un puerto a un rango amplio “para que funcione ya”, con la intención de acotarlo después. Ese “después” compite con roadmap, guardias y proyectos, y rara vez llega.
En IAM, el escenario típico es el permiso temporal que se vuelve permanente. Se adjunta una policy administrada amplia a un rol de aplicación para destrabar un despliegue; luego el permiso queda y nadie lo retira porque “si lo toco rompo algo”. Esa deuda se acumula y, cuando hay un compromiso de credenciales o un abuso interno, el radio de impacto es mayor de lo esperado.
En networking, cambios de rutas, gateways, peering o reglas de egress se hacen para recuperar conectividad con terceros o con un entorno on-prem. Si ese cambio no pasa por el modelo declarativo, el equipo pierde reproducibilidad: el mismo módulo Terraform aplicado en otra cuenta no genera el mismo comportamiento, lo que rompe pruebas, DR y escalado controlado.
Un anti-patrón muy corporativo (y caro) es permitir “break-glass” sin límites operativos reales. Se crea un rol súper privilegiado para emergencias, pero se usa para tareas diarias porque “es más rápido”. Sin límites, ese rol se convierte en la vía habitual de drift: no solo cambia recursos, también cambia las condiciones para que otros puedan cambiar recursos.
Recomendaciones para entornos corporativos
Terraform no garantiza control de seguridad si existe un canal paralelo de cambios sin gobierno. El drift entre lo declarado y lo ejecutado aparece especialmente en reglas de seguridad, IAM y networking, y suele descubrirse por efectos colaterales (hallazgos, planes inesperados, auditorías) más que por un “fallo visible”.
La respuesta práctica en empresa combina guardrails (para impedir o limitar cambios inseguros desde consola) con auditoría continua (para detectar y gestionar desviaciones cuando ocurren). Configura detección (AWS Config / Azure Policy y auditoría de eventos), integra alertas con operación (tickets, responsables, SLA) y valida con evidencia (CloudTrail y timelines de configuración) para que el control no dependa de “a ver si el próximo apply lo arregla”.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.