Objetivo
Gestionar infraestructura con código seguro y auditable
Enfoque
Terraform, estado, módulos, revisión, drift y guardrails
Resultado
Reducir configuraciones inseguras y cambios manuales
20.1 Introducción
Infraestructura como código, o IaC, permite definir recursos cloud mediante archivos versionados. En lugar de crear redes, bases, permisos o clusters manualmente, se describen en plantillas que pueden revisarse, probarse y aplicarse de forma repetible.
Esta práctica mejora trazabilidad y consistencia, pero también concentra riesgo. Un módulo mal diseñado o una variable incorrecta puede desplegar configuraciones inseguras en muchos ambientes.
La seguridad de IaC busca que el código de infraestructura pase por los mismos estándares de revisión, pruebas, permisos y gobierno que el código de aplicación.
20.2 Beneficios de IaC para seguridad
Cuando se usa correctamente, IaC fortalece la seguridad porque hace visibles las decisiones de infraestructura.
- Permite revisión por pares antes de cambios.
- Registra historial de quién cambió qué y por qué.
- Reduce configuraciones manuales inconsistentes.
- Facilita escaneo automático de políticas.
- Permite reutilizar módulos seguros.
- Ayuda a reconstruir ambientes ante incidentes.
- Mejora auditoría y evidencia de cumplimiento.
IaC no garantiza seguridad por sí misma. Hace que la infraestructura sea revisable y automatizable; la seguridad depende de las reglas y prácticas aplicadas sobre ese código.
20.3 Riesgos de IaC
El mismo poder que permite estandarizar también puede replicar errores rápidamente.
| Riesgo |
Impacto |
Control |
| Plantilla insegura |
Recursos expuestos en múltiples ambientes |
IaC scanning y revisión obligatoria |
| Estado expuesto |
Filtración de IDs, secretos o configuración sensible |
Backend remoto cifrado y acceso mínimo |
| Permisos amplios del pipeline |
Modificación no controlada de infraestructura |
Roles por entorno y acciones limitadas |
| Módulo no confiable |
Creación de recursos o permisos no esperados |
Fuentes aprobadas y versionado |
| Drift |
Diferencia entre código y realidad |
Detección continua y corrección por IaC |
20.4 Estado remoto
Herramientas como Terraform mantienen un estado que representa recursos desplegados. Ese estado puede contener datos sensibles o metadatos críticos, por lo que debe protegerse.
Buenas prácticas:
- Usar backend remoto en lugar de archivos locales compartidos.
- Habilitar cifrado en reposo.
- Restringir acceso al estado por rol y ambiente.
- Usar bloqueo de estado para evitar cambios concurrentes.
- Activar versionado y recuperación.
- No publicar archivos de estado en repositorios.
- Auditar accesos y modificaciones al backend.
20.5 Variables sensibles
Las variables pueden contener secretos, claves, endpoints internos o datos sensibles. Marcarlas como sensibles ayuda en la salida de herramientas, pero no sustituye una gestión adecuada.
Controles recomendados:
- No guardar secretos en archivos versionados.
- Obtener secretos desde gestores especializados.
- Evitar mostrar valores sensibles en logs de pipeline.
- Separar variables por ambiente.
- Revisar si el estado guarda valores sensibles.
- Rotar secretos si aparecen en planes, logs o estado expuesto.
20.6 Revisión de planes
El plan muestra qué cambios se aplicarán antes de modificar infraestructura. Revisarlo es clave para detectar borrados, exposiciones, cambios de permisos o alteraciones no esperadas.
Una revisión debe buscar:
- Recursos que serán destruidos o reemplazados.
- Cambios en IAM, roles y políticas.
- Exposición pública de redes, buckets o bases.
- Desactivación de logs, cifrado o backups.
- Cambios en regiones o cuentas destino.
- Diferencias entre ambientes.
Aplicar infraestructura sin revisar el plan equivale a ejecutar cambios privilegiados sin entender su impacto.
20.7 Módulos seguros
Los módulos permiten reutilizar patrones. Un buen módulo reduce errores repetidos y ofrece configuraciones seguras por defecto.
Características de un módulo seguro:
- Valores por defecto restrictivos.
- Cifrado habilitado por defecto.
- Logging y etiquetas obligatorias.
- Exposición pública deshabilitada salvo parámetro explícito.
- Validación de entradas.
- Versionado semántico y changelog.
- Pruebas y ejemplos de uso seguro.
20.8 Fuentes y versiones de módulos
Consumir módulos externos sin control puede introducir recursos, permisos o cambios no esperados. Los módulos son dependencias de infraestructura.
| Práctica |
Beneficio |
Riesgo si se omite |
| Fijar versiones |
Evita cambios inesperados |
Actualización automática insegura |
| Usar fuentes aprobadas |
Reduce dependencia no confiable |
Módulos maliciosos o abandonados |
| Revisar cambios |
Detecta nuevas acciones o permisos |
Introducción silenciosa de riesgo |
| Publicar módulos internos |
Estandariza patrones seguros |
Equipos duplican soluciones inconsistentes |
20.9 IaC scanning
El escaneo de IaC analiza plantillas antes de desplegar. Debe ejecutarse en pull requests y pipelines para detectar configuraciones inseguras.
Ejemplos de reglas:
- Bloquear almacenamiento público.
- Exigir cifrado en discos, bases y buckets.
- Evitar puertos administrativos abiertos a internet.
- Exigir logs de auditoría.
- Detectar permisos IAM con comodines.
- Requerir etiquetas de dueño, ambiente y criticidad.
- Bloquear regiones no aprobadas.
20.10 Policy as code y guardrails
Policy as code define reglas que el código de infraestructura debe cumplir. Los guardrails pueden ser preventivos o detectivos.
| Tipo |
Ejemplo |
Resultado |
| Preventivo |
Bloquear creación de recursos sin cifrado |
El riesgo no llega a desplegarse |
| Detectivo |
Alertar recursos sin etiquetas |
Se corrige con ticket o workflow |
| Correctivo |
Revertir exposición pública no autorizada |
Reduce ventana de exposición |
| Compensatorio |
Permitir excepción con monitoreo adicional |
Acepta riesgo temporalmente controlado |
20.11 Permisos del pipeline IaC
El pipeline que aplica IaC suele tener permisos muy sensibles. Debe operar con roles acotados y separados por ambiente.
Controles:
- Roles distintos para plan y apply.
- Permisos separados por cuenta, proyecto y ambiente.
- Aprobación para cambios productivos.
- Credenciales temporales mediante OIDC o mecanismo equivalente.
- Auditoría de quién aprobó y qué se aplicó.
- Restricción de ramas que pueden ejecutar cambios reales.
20.12 Drift detection
Drift ocurre cuando la infraestructura real difiere del código. Puede aparecer por cambios manuales, automatizaciones externas o modificaciones del proveedor.
Riesgos del drift:
- Controles deshabilitados fuera del repositorio.
- Permisos o reglas agregadas manualmente.
- Dificultad para reproducir ambientes.
- Planes inesperados que reemplazan recursos críticos.
- Auditoría incompleta de cambios.
El drift debe detectarse regularmente y corregirse actualizando código o revirtiendo cambios no autorizados.
20.13 Organización de repositorios
La estructura de repositorios IaC influye en seguridad y operación. No hay un modelo único, pero deben separarse responsabilidades y ambientes críticos.
Criterios comunes:
- Separar módulos reutilizables de stacks concretos.
- Separar ambientes productivos de no productivos cuando el riesgo lo justifique.
- Proteger ramas que aplican cambios reales.
- Definir CODEOWNERS para módulos críticos.
- Evitar duplicación de plantillas con pequeñas diferencias no controladas.
- Documentar convenciones de nombres, etiquetas y variables.
20.14 Pruebas de IaC
El código de infraestructura también debe probarse. Las pruebas pueden validar sintaxis, formato, políticas, módulos y despliegues temporales.
- Formato y linting.
- Validación de sintaxis y proveedores.
- Escaneo de seguridad.
- Pruebas unitarias de módulos.
- Planes contra ambientes efímeros.
- Validación de outputs y recursos creados.
- Pruebas de destrucción para evitar recursos huérfanos.
20.15 Errores frecuentes
- Guardar estado local o subirlo al repositorio.
- Ejecutar apply desde laptops sin trazabilidad.
- No revisar planes antes de aplicar.
- Usar módulos externos sin fijar versión.
- Permitir variables sensibles en archivos versionados.
- No detectar drift hasta que ocurre un incidente.
- Duplicar plantillas en lugar de mantener módulos comunes.
- Dar permisos administrativos globales al pipeline IaC.
IaC seguro requiere disciplina operativa: revisión, estado protegido, permisos mínimos, módulos confiables y validación automática.
20.16 Lista de verificación
- ¿El estado remoto está cifrado, bloqueado y con acceso mínimo?
- ¿Los planes se revisan antes de aplicar cambios sensibles?
- ¿Las variables sensibles provienen de gestores de secretos?
- ¿Los módulos tienen versiones fijadas y fuentes aprobadas?
- ¿IaC scanning corre en pull requests?
- ¿Policy as code bloquea riesgos críticos?
- ¿El pipeline usa permisos separados por ambiente?
- ¿Existe detección y gestión de drift?
20.17 Qué debes recordar de este tema
- IaC mejora seguridad cuando hace los cambios revisables, repetibles y auditables.
- El estado puede contener información sensible y debe protegerse.
- Los módulos son dependencias de infraestructura y deben versionarse.
- Policy as code y guardrails reducen configuraciones inseguras antes del despliegue.
- El drift revela diferencias entre lo declarado y lo real; debe gestionarse activamente.
20.18 Conclusión
Infraestructura como código segura permite operar cloud con más control, trazabilidad y consistencia. Para lograrlo, el código de infraestructura debe revisarse, probarse, escanearse y aplicarse mediante procesos con permisos mínimos.
En el próximo tema estudiaremos observabilidad y detección: logs, métricas, trazas, SIEM, alertas y auditoría cloud.