Automatización on Adur

Lecciones aprendidas en DevSecOps

Mon, 20 Oct 2025 00:00:00 +0000

DevSecOps se usa mucho en ofertas de trabajo y charlas. Pero detrás del buzzword hay lecciones reales que solo vienen de hacer el trabajo. De construir pipelines que se rompen cuando añades seguridad, de ver equipos ignorar herramientas que pasaste meses desplegando, hasta finalmente encontrar qué funciona.

Estas son lecciones que aprendimos a base de golpes. Son opiniones fundamentadas, prácticas, moldeadas por experiencia real.

La seguridad es responsabilidad de todos

Suena a póster, pero es la lección más importante. Si la seguridad es solo del equipo de seguridad, ya perdiste.

Los desarrolladores toman decisiones de seguridad cada vez que escriben código, lo sepan o no. Cómo validan entrada. Cómo manejan secretos. Cómo configuran acceso de red. Cada PR es un evento de seguridad.

Lo que funciona: haz seguridad parte del flujo de desarrollo normal, no una puerta al final. Los desarrolladores aprenden cuando reciben feedback rápido sobre problemas de seguridad en su PR. Lo resientan cuando se enteran tres semanas después de un auditor.

Lo hemos visto repetidamente: equipos que tratan seguridad como responsabilidad compartida encuentran menos vulnerabilidades críticas. Los que la aíslan las encuentran en las noticias.

Automatiza todo lo que puedas

Los procesos de seguridad manuales no escalan. Punto. Si tu revisión de seguridad es un humano leyendo una checklist, se saltará bajo presión de plazos, se aplicará de forma inconsistente y será odiada por todos los involucrados.

Automatiza las cosas que se pueden automatizar:

Escaneo de dependencias en cada build de CI (Dependabot, Snyk, Trivy)
Análisis estático en cada pull request (Semgrep, SonarQube)
Detección de secretos como pre-commit hook y check de CI (gitleaks, detect-secrets)
Escaneo de imágenes de contenedores antes del despliegue (Trivy, Grype)
Escaneo de Infrastructure as Code (tfsec, Checkov, KICS)
Compliance as Code para cumplimiento de políticas en runtime (OPA, Kyverno)

El objetivo no es capturarlo todo automáticamente. El objetivo es capturar lo fácil automáticamente para que los revisores humanos puedan centrarse en lo difícil: fallos en la lógica de negocio, problemas de seguridad a nivel de diseño, modelado de amenazas.

Empieza pequeño

Uno de los mayores errores que hemos cometido es intentar asegurar todo de golpe. Despliegas SAST, DAST, SCA, escaneo de contenedores, escaneo de IaC y protección en runtime en un trimestre. El resultado: fatiga de alertas, rebelión de los desarrolladores y un muro de hallazgos sin resolver que nadie mira.

Empieza con una herramienta, un pipeline, un equipo. Haz que funcione bien. Que los desarrolladores se sientan cómodos con ello. Resuelve los falsos positivos. Ajusta las reglas. Después expande.

Una progresión práctica:

Mes 1: Detección de secretos en pre-commit hooks y CI. Esto es poco controvertido y captura problemas reales.
Mes 2: Escaneo de dependencias con creación automatizada de PRs para actualizaciones. Los desarrolladores ven el valor inmediatamente.
Mes 3: Escaneo de imágenes de contenedores bloqueando despliegues con vulnerabilidades críticas/altas.
Mes 4+: Análisis estático, expandiendo conjuntos de reglas gradualmente.

Cada paso debe ser estable antes de pasar al siguiente. Ir con prisas crea ruido, y el ruido enseña a la gente a ignorar alertas.

La cultura blameless importa

Cuando ocurre un incidente de seguridad porque alguien subió un secreto a un repo público, o porque una vulnerabilidad no se parcheó a tiempo, la respuesta importa más que el propio incidente.

Si se culpa a la gente, ocultan cosas. No reportan casi-incidentes. Tapan errores. Y el siguiente incidente será peor porque nadie compartió las lecciones del anterior.

Las postmortems blameless no consisten en librar a la gente de responsabilidad. Consisten en entender fallos sistémicos. Por qué fue posible subir un secreto? Por qué no había escaneo? Por qué el proceso de parcheo era lento? Arregla el sistema, no a la persona.

Hemos comprobado que los equipos con culturas genuinamente blameless tienen posturas de seguridad significativamente mejores. La gente reporta cosas sospechosas. Piden ayuda pronto. Señalan riesgos antes de que se conviertan en incidentes.

Las herramientas no bastan sin cambio cultural

Una vez desplegamos un pipeline de escaneo de seguridad completo con dashboards bonitos, notificaciones de Slack, creación de tickets en Jira, todo el paquete. Seis meses después, había 3.000 hallazgos sin resolver y el canal de Slack estaba silenciado por todos los desarrolladores.

Las herramientas estaban bien. La cultura no estaba preparada.

Antes de desplegar herramientas, invierte en:

Formación: Los desarrolladores necesitan entender por qué existe la herramienta y cómo actuar sobre sus hallazgos.
Ownership: Alguien necesita ser dueño del backlog de hallazgos y hacer triaje. Si nadie es dueño, nadie lo hace.
SLAs: Define plazos claros para remediar hallazgos por severidad. Críticos en 48 horas. Altos en una semana. Medios en un sprint. Bajos en un trimestre.
Bucles de feedback: Cuando una herramienta produce un falso positivo, debe haber una forma fácil de reportarlo y que se ajuste la regla. De lo contrario, los desarrolladores aprenden a ignorar todo.

Invierte en la experiencia de desarrollador de las herramientas de seguridad

Si tu herramienta de seguridad hace la vida de los desarrolladores más difícil, encontrarán la forma de esquivarla. Esto no es un defecto de carácter. Es naturaleza humana y buen instinto de ingeniería: eliminar obstáculos para entregar.

Las herramientas de seguridad que se adoptan son las que:

Ejecutan rápido: Un escaneo SAST que tarda 20 minutos será esquivado. Uno que tarda 30 segundos será tolerado.
Se integran nativamente: Muestra resultados en la PR, no en un portal separado. Nadie quiere hacer login en otro dashboard.
Tienen baja tasa de falsos positivos: Cada falso positivo erosiona la confianza. Invierte tiempo en el ajuste.
Proporcionan guía accionable: “Vulnerabilidad de SQL injection en la línea 42” es inútil sin “así es como se arregla.”
Fallan de forma elegante: Si el escáner está caído, el pipeline debe avisar, no bloquear. La disponibilidad del pipeline de desarrollo no es negociable.

Lo pensamos así: si un desarrollador tiene que cambiar su flujo de trabajo para acomodar una herramienta de seguridad, la herramienta ha fallado. Las mejores herramientas de seguridad son invisibles.

Monitorización y observabilidad no son negociables

No puedes asegurar lo que no puedes ver. La monitorización de seguridad no es opcional, y no es algo que se añade después.

Qué significa esto en la práctica:

Logging centralizado: Todos los logs de aplicación, infraestructura y herramientas de seguridad en un solo lugar. Si tienes que hacer SSH a una máquina para leer logs, ya vas por detrás.
Audit trails: Quién hizo qué, cuándo y desde dónde. Cada despliegue, cada cambio de configuración, cada solicitud de acceso.
Alertas sobre anomalías: No solo “está el servicio arriba?” sino “es este patrón de acceso normal?” Volúmenes inusuales de llamadas a API, accesos desde nuevas ubicaciones, escalaciones de privilegios.
Seguridad en runtime: Herramientas como Falco para monitorización de runtime de contenedores. Saber cuándo algo inesperado ocurre en producción.

La monitorización también es cómo demuestras a auditores y clientes que tus controles de seguridad funcionan. “Confía en nosotros” no es una estrategia de cumplimiento.

El open source es tu aliado

Algunas de las mejores herramientas de seguridad disponibles son open source. Trivy, Falco, OPA, Semgrep, gitleaks, cosign, KICS, Checkov. El ecosistema es rico y madura rápidamente.

Beneficios de las herramientas de seguridad open source:

Transparencia: Puedes leer las reglas y entender exactamente qué se está comprobando.
Comunidad: Miles de contribuidores encontrando casos límite y añadiendo reglas de detección.
Sin vendor lock-in: Puedes cambiar de herramienta sin renegociar un contrato.
Coste: Empieza gratis, escala según necesites.

Esto no significa que las herramientas comerciales no tengan su lugar. Algunas proporcionan agregación, gestión y soporte valiosos. Pero puedes construir un pipeline de seguridad muy sólido solo con herramientas open source, y creemos que todos los equipos deberían empezar por ahí.

El aprendizaje continuo es esencial

El panorama de amenazas cambia constantemente. Las herramientas cambian. Las mejores prácticas evolucionan. Lo que se consideraba seguro hace dos años puede tener un CVE hoy.

Lo que hacemos para mantenernos al día:

Dedicar tiempo al aprendizaje: Al menos unas horas por sprint para que el equipo lea sobre nuevas vulnerabilidades, herramientas y técnicas. Esto no es un nice-to-have. Es un requisito profesional.
Organizar CTFs internos y ejercicios de mesa: Nada enseña seguridad como intentar romper cosas. Los ejercicios regulares mantienen las habilidades afiladas y revelan brechas en tus defensas.
Participar en la comunidad: Asistir a meetups, contribuir a open source, leer advisories. La comunidad de seguridad es generosa con el conocimiento. Aprovéchalo.
Revisar y actualizar: Revisiones trimestrales de tu tooling de seguridad, políticas y procedimientos de respuesta a incidentes. Lo que funcionó el trimestre pasado puede no funcionar el próximo.

Reflexiones finales

DevSecOps no es un destino. No hay un punto donde digas “terminamos, somos seguros.” Es una práctica continua de reducir riesgo, mejorar visibilidad, construir una cultura donde seguridad sea tan natural como escribir tests.

La lección más importante: lo perfecto es enemigo de lo bueno. Un pipeline básico que los desarrolladores usan de verdad vale infinitamente más que uno completo que esquivan. Empieza donde estás, mejora iterativamente, nunca pares.

LLMOps: integrando LLMs en flujos de trabajo DevOps

Sun, 15 Jun 2025 00:00:00 +0000

Los LLMs han ido más allá de chatbots. Ahora se integran en flujos de trabajo de ingeniería donde automatizan tareas tediosas, aceleran respuesta a incidentes y potencian productividad. Pero desplegar un LLM en un pipeline de DevOps en producción es fundamentalmente diferente a usar ChatGPT en un navegador.

Esta guía cubre qué significa LLMOps en la práctica, dónde encajan los LLMs en DevOps, patrones de arquitectura que funcionan y trampas que debes evitar.

Qué es LLMOps

LLMOps es el conjunto de prácticas, herramientas e infraestructura necesarios para operacionalizar LLMs. Extiende MLOps pero aborda desafíos únicos de los modelos de lenguaje:

Selección de modelo vs. entrenamiento de modelo: La mayoría de equipos consumen modelos pre-entrenados (mediante APIs o inferencia auto-alojada) en lugar de entrenar desde cero. El foco operacional se desplaza hacia prompt engineering, fine-tuning y generación aumentada por recuperación (RAG).
Gestión de costes: La inferencia con LLMs es cara. La tarificación por tokens significa que los costes escalan con el uso de formas más difíciles de predecir que el cómputo tradicional.
No determinismo: Los LLMs producen salidas variables para la misma entrada, lo que complica las pruebas, la validación y la reproducibilidad.
Latencia: Tiempos de respuesta de segundos (no milisegundos) requieren patrones arquitectónicos diferentes a los microservicios tradicionales.

LLMOps no es una disciplina separada. Es una extensión de tus prácticas existentes de DevOps y MLOps, adaptada a las características operacionales específicas de los modelos de lenguaje.

Casos de uso prácticos en DevOps

Aquí es donde los LLMs están aportando valor real en flujos de trabajo DevOps hoy en día:

Revisión automatizada de código

Los LLMs pueden proporcionar una primera pasada de revisión de pull requests, detectando problemas comunes como manejo de errores ausente, anti-patrones de seguridad, nomenclatura inconsistente o tests faltantes. No reemplazan a los revisores humanos, pero reducen la carga del feedback repetitivo.

Resumen de incidentes

Cuando un incidente salta a las 3 de la mañana, la persona de guardia necesita contexto rápido. Un LLM puede ingerir datos de alertas, logs de despliegues recientes, runbooks relacionados e informes de incidentes anteriores para producir un resumen conciso de lo que probablemente está fallando y qué se hizo la última vez.

Análisis de logs

Los LLMs son sorprendentemente efectivos en el reconocimiento de patrones en datos de logs no estructurados. Aliméntalos con un bloque de logs de error y pueden identificar la causa raíz más rápido que sesiones manuales de grep, especialmente para sistemas con los que no estás familiarizado.

Generación de documentación

Generar borradores de documentación a partir de código, esquemas de API o módulos de Terraform. El resultado necesita revisión humana, pero elimina el problema de la página en blanco y mantiene la documentación más cercana al estado actual.

Generación de Infrastructure as Code

Dada una descripción en lenguaje natural de la infraestructura deseada, los LLMs pueden generar manifiestos de Terraform, Ansible o Kubernetes como punto de partida. Útil para scaffolding, no para código listo para producción sin revisión.

Patrones de arquitectura para integración de LLMs

Patrón 1: API gateway a LLM externo

El enfoque más simple. Tu aplicación llama a una API de LLM externa (OpenAI, Anthropic, etc.) a través de un gateway centralizado que gestiona autenticación, rate limiting, logging y seguimiento de costes.

1
2
3
4
5


[Pipeline CI/CD] --> [API Gateway] --> [API LLM Externa]
 |
 [Logging y Métricas]
 |
 [Seguimiento de Costes]

Pros: Sin infraestructura que gestionar, acceso a los modelos más capaces, rápido de implementar. Contras: Los datos salen de tu red, dependencia del proveedor, latencia variable, costes continuos de API.

Patrón 2: Inferencia auto-alojada

Ejecutar modelos de pesos abiertos (Llama, Mistral, etc.) en tu propia infraestructura usando servidores de inferencia como vLLM u Ollama.

1
2
3


[Pipeline CI/CD] --> [Load Balancer] --> [Instancia(s) vLLM / Ollama]
 |
 [Pool de Nodos GPU]

Pros: Los datos permanecen internos, costes predecibles a escala, sin dependencia de proveedor, control total sobre versiones del modelo. Contras: Requiere infraestructura GPU, sobrecarga operacional, modelos más pequeños pueden ser menos capaces.

Patrón 3: Pipeline mejorado con RAG

Combinar un LLM con un sistema de recuperación que proporciona contexto relevante de tu propia base de conocimiento (runbooks, documentación, incidentes pasados). Esto mejora drásticamente la calidad de las respuestas para tareas específicas del dominio.

1
2
3
4


[Consulta] --> [Modelo Embedding] --> [Búsqueda Vector DB] --> [Contexto + Consulta] --> [LLM] --> [Respuesta]
 |
 [Tu Base de Conocimiento]
 (runbooks, docs, etc.)

Este patrón es particularmente potente para respuesta a incidentes y tareas de documentación donde el LLM necesita el contexto específico de tu organización.

Consideraciones clave

Coste

Los costes de API de LLMs pueden sorprender. Un pipeline de revisión de código que procesa 50 PRs al día con diffs grandes puede fácilmente alcanzar cientos de dólares al mes. Estrategias para controlar costes:

Establecer límites de tokens por petición
Cachear consultas y respuestas comunes
Usar modelos más pequeños para tareas simples (triaje con un modelo pequeño, escalar a uno mayor)
Monitorizar el uso de tokens por pipeline y configurar alertas

Latencia

Las respuestas de LLMs tardan segundos, no milisegundos. Diseña tus integraciones como procesos asíncronos:

Publicar comentarios de revisión de código después del hecho, no bloquear la PR
Procesar datos de incidentes en segundo plano, enviar resultados a un canal de Slack
Usar streaming de respuestas donde sea posible para mejorar el rendimiento percibido

Alucinaciones

Los LLMs generarán con confianza información que suena plausible pero es incorrecta. Esta es una preocupación crítica para tareas de DevOps donde un mal consejo puede causar caídas.

Mitigaciones:

Siempre presentar la salida del LLM como sugerencias, nunca como acciones autoritativas
Requerir aprobación humana antes de aplicar cualquier cambio generado por LLM
Usar RAG para anclar las respuestas en documentación verificada
Implementar validación de salida (por ejemplo, lint del IaC generado antes de presentarlo)

Seguridad

Exposición de datos: Cualquier cosa que envíes a una API de LLM externa puede ser usada para entrenamiento o almacenada. Nunca envíes secretos, credenciales o datos sensibles de clientes.
Prompt injection: Contenido malicioso en código, logs o entrada de usuario puede manipular el comportamiento del LLM. Sanitiza las entradas y valida las salidas.
Cadena de suministro: El código generado por LLM puede introducir vulnerabilidades. Pasa todo el código generado por tu pipeline de escaneo de seguridad existente.

Herramientas y plataformas

LangChain

Un framework para construir aplicaciones potenciadas por LLMs. Útil para orquestar cadenas de múltiples pasos (por ejemplo, recuperar contexto, formatear prompt, llamar al LLM, parsear la salida). Soporta muchos proveedores de LLMs y tiene buen tooling para pipelines RAG.

1
2
3
4
5
6
7
8


from langchain.chat_models import ChatOpenAI
from langchain.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_template(
 "Review this code diff for security issues and suggest fixes:\n\n{diff}"
)
chain = prompt | ChatOpenAI(model="gpt-4o", temperature=0)
result = chain.invoke({"diff": code_diff})

vLLM

Un motor de inferencia de alto rendimiento para modelos auto-alojados. Soporta PagedAttention para gestión eficiente de memoria y continuous batching para alto throughput.

1
2
3
4


# Iniciar un servidor vLLM
python -m vllm.entrypoints.openai.api_server \
 --model mistralai/Mistral-7B-Instruct-v0.2 \
 --port 8000

Expone una API compatible con OpenAI, así que puedes cambiar entre APIs auto-alojadas y externas con cambios mínimos de código.

Ollama

La forma más fácil de ejecutar LLMs localmente para desarrollo y pruebas. Ideal para prototipar pipelines antes de comprometerte con infraestructura.

1
2
3
4
5
6
7


# Descargar y ejecutar un modelo
ollama pull llama3
ollama run llama3 "Summarize this error log: [paste log]"

# Servir como API
ollama serve
# Luego llamar a http://localhost:11434/api/generate

Ejemplo: Pipeline de revisión automatizada de PRs

Aquí tienes un pipeline conceptual para revisión automatizada de PRs usando un LLM:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


# .github/workflows/llm-review.yml
name: LLM Code Review

on:
 pull_request:
 types: [opened, synchronize]

jobs:
 llm-review:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@v4
 with:
 fetch-depth: 0

 - name: Get diff
 id: diff
 run: |
 git diff origin/${{ github.base_ref }}...HEAD > diff.txt

 - name: Run LLM review
 env:
 LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
 run: |
 python scripts/llm_review.py \
 --diff diff.txt \
 --model gpt-4o \
 --max-tokens 2000 \
 --output review.json

 - name: Post review comments
 uses: actions/github-script@v7
 with:
 script: |
 const review = require('./review.json');
 await github.rest.pulls.createReview({
 owner: context.repo.owner,
 repo: context.repo.repo,
 pull_number: context.issue.number,
 body: review.summary,
 event: 'COMMENT',
 comments: review.line_comments
 });

El script de revisión:

Lee el diff
Divide diffs grandes en fragmentos que quepan en la ventana de contexto del modelo
Para cada fragmento, construye un prompt pidiendo problemas de seguridad, bugs y problemas de estilo
Agrega resultados y formatea como comentarios de revisión de GitHub
Incluye puntuaciones de confianza y siempre marca la salida como generada por IA

Guardrails y uso responsable

Etiqueta claramente toda la salida del LLM como generada por IA. Los ingenieros deben saber cuándo están leyendo salida de una máquina.
Nunca auto-mergees ni auto-apliques sugerencias del LLM. Mantén un humano en el bucle para todos los cambios.
Registra todos los prompts y respuestas para depuración y auditoría.
Establece límites de gasto y alertas sobre el uso de API de LLMs.
Revisa las plantillas de prompts regularmente para asegurarte de que no filtran información sensible.
Prueba sesgos y errores con muestras representativas antes de desplegar en flujos de trabajo de producción.

Recomendaciones para empezar

Elige un caso de uso - No intentes habilitar LLMs en todo. Empieza bajo riesgo: borradores, sugerencias de commits.
Empieza con API externa - No inviertas en GPU hasta validar el caso. Usa OpenAI o Anthropic para prototipar.
Mide todo - Registra coste por invocación, latencia, satisfacción, tasas de error desde el primer día.
Construye un framework - Crea un suite de tests con entradas y salidas conocidas. Ejecútalo contra cada cambio de prompt o modelo.
Planifica tu estrategia de datos - Decide qué datos enviarás a APIs externas. Documéntalo.
Itera en prompts - El prompt engineering es iterativo. Versiona prompts, trátalos como código.

Los LLMs son una herramienta potente para DevOps, pero son exactamente eso: una herramienta. Funcionan mejor cuando se integran de forma reflexiva en flujos existentes, con límites claros sobre qué pueden y no pueden hacer autonomamente.

Modelo de madurez de DevSecOps

Sun, 08 Oct 2023 10:00:00 +0100

Por qué un modelo de madurez ayuda

La mayoría de los equipos saben que deberían “desplazar la seguridad a la izquierda”, pero saber por dónde empezar es la parte difícil. Un modelo de madurez proporciona una forma estructurada de evaluar el estado actual, identificar brechas y planificar una hoja de ruta realista para mejorar.

Sin un modelo, las mejoras de seguridad tienden a ser reactivas (desencadenadas por incidentes o hallazgos de auditoría en lugar de por una planificación deliberada). Un modelo de madurez convierte la seguridad de un simulacro de incendio en una disciplina de ingeniería con progreso medible.

El modelo descrito aquí tiene cinco niveles. El objetivo no es correr al nivel más alto, sino hacer un progreso constante y sostenible. Cada nivel se construye sobre el anterior.

Los cinco niveles de madurez

Nivel 1: Ad-Hoc

En este nivel, la seguridad es algo secundario. No existen procesos formales y las actividades de seguridad ocurren de forma esporádica, si es que ocurren.

Cómo se ve:

Sin pruebas de seguridad en los pipelines de CI/CD.
Las vulnerabilidades se descubren en producción o por terceros.
Sin herramientas de seguridad dedicadas.
Los desarrolladores tienen poca o ninguna formación en seguridad.
La respuesta a incidentes es improvisada.
El cumplimiento normativo se aborda manualmente antes de las auditorías.

Herramientas típicas: Ninguna específica de seguridad. Quizás un firewall y un antivirus.

Nivel 2: Reactivo

La seguridad se reconoce como importante, pero el enfoque es reactivo. El equipo responde a vulnerabilidades e incidentes pero no los previene de manera proactiva.

Cómo se ve:

El análisis estático básico (SAST) se ejecuta ocasionalmente, pero los hallazgos no siempre se abordan.
El escaneo de dependencias se hace de forma manual o ad-hoc.
Hay documentación de seguridad, pero está desactualizada.
La respuesta a incidentes existe como un proceso documentado, aunque se practica raramente.
Las revisiones de seguridad ocurren tarde en el ciclo de desarrollo (justo antes del lanzamiento).

Herramientas típicas: SonarQube (reglas básicas), OWASP Dependency-Check, pruebas de penetración manuales.

Nivel 3: Proactivo

La seguridad está integrada en el flujo de trabajo de desarrollo. El equipo busca activamente prevenir vulnerabilidades en lugar de solo reaccionar ante ellas.

Cómo se ve:

SAST y DAST se ejecutan automáticamente en los pipelines de CI/CD.
Escaneo de dependencias con alertas automáticas para vulnerabilidades conocidas.
Escaneo de imágenes de contenedores antes del despliegue (Trivy, Grype).
La Infrastructure as Code se escanea en busca de configuraciones incorrectas (Checkov, tfsec).
Se realiza threat modeling para nuevas funcionalidades y cambios de arquitectura.
Existen security champions dentro de los equipos de desarrollo.
Se realizan postmortems sin culpa después de incidentes de seguridad.
Formación regular en seguridad para desarrolladores.

Herramientas típicas: Semgrep, Trivy, Checkov, OWASP ZAP, HashiCorp Vault, Falco.

Nivel 4: Optimizado

La seguridad está profundamente integrada en cada etapa del ciclo de vida del software. Las métricas guían las decisiones y el equipo mejora continuamente basándose en datos.

Cómo se ve:

Puertas de seguridad en los pipelines que bloquean el despliegue si se encuentran problemas críticos.
El tiempo medio de remediación (MTTR) se rastrea y se reduce continuamente.
Se genera un Software Bill of Materials (SBOM) para cada release.
Artefactos firmados y cadena de suministro verificada.
Comprobaciones de cumplimiento automatizadas mapeadas a frameworks (SOC2, ISO 27001, PCI-DSS).
Monitorización de seguridad en runtime con respuesta automatizada (Falco + reglas personalizadas).
Ejercicios regulares de red team y chaos engineering para seguridad.
Las métricas de seguridad forman parte de los dashboards de ingeniería.

Herramientas típicas: Sigstore/cosign, OPA/Gatekeeper, Kyverno, integración con SIEM, plataformas de cumplimiento automatizado.

Nivel 5: Innovador

La seguridad es una ventaja competitiva. El equipo contribuye a la comunidad de seguridad en general y empuja el estado del arte.

Cómo se ve:

Programas de bug bounty gestionados activamente.
Herramientas de seguridad personalizadas desarrolladas para riesgos específicos de la organización.
Machine learning aplicado a detección de anomalías y threat hunting.
La seguridad es una característica que se vende a los clientes (certificaciones, informes de transparencia).
Participación activa en proyectos de seguridad open-source.
Arquitectura zero-trust completamente implementada.
Policy as code gobierna toda la seguridad de infraestructura y aplicaciones.

Herramientas típicas: Plataformas construidas a medida, herramientas de seguridad basadas en eBPF, SIEM avanzado con ML, service mesh zero-trust.

Dimensiones clave

Un modelo de madurez no es unidimensional. Evalúa tu organización en estas dimensiones, ya que el progreso rara vez es parejo:

Seguridad del código

Nivel	Prácticas
Ad-Hoc	Sin escaneo de código
Reactivo	SAST ocasional, revisiones de código manuales orientadas a seguridad
Proactivo	SAST/DAST automatizado en CI, directrices de revisión de código enfocadas en seguridad
Optimizado	Reglas personalizadas para patrones específicos de la organización, MTTR rastreado
Innovador	Revisión de código asistida por IA, sugerencias automáticas de corrección

Seguridad de la infraestructura

Nivel	Prácticas
Ad-Hoc	Configuración manual de servidores, sin estándares de hardening
Reactivo	Checklists básicas de hardening, auditorías ocasionales
Proactivo	Escaneo de IaC, hardening automatizado, CIS benchmarks
Optimizado	Policy as code (OPA), detección de drift, remediación automatizada
Innovador	Infraestructura auto-reparable, redes zero-trust

Monitorización y detección

Nivel	Prácticas
Ad-Hoc	Sin monitorización de seguridad
Reactivo	Recopilación básica de logs, revisión manual después de incidentes
Proactivo	Logging centralizado, alertas sobre patrones conocidos, monitorización en runtime
Optimizado	SIEM con reglas de correlación, playbooks de respuesta automatizada
Innovador	Detección de anomalías basada en ML, programas de threat hunting

Respuesta a incidentes

Nivel	Prácticas
Ad-Hoc	Sin proceso, respuesta improvisada
Reactivo	Runbooks documentados, raramente probados
Proactivo	Ejercicios regulares de simulación, postmortems sin culpa, rotación de guardia
Optimizado	Clasificación automatizada de incidentes, tiempos de respuesta basados en SLA
Innovador	Chaos engineering para seguridad, contención automatizada

Cumplimiento normativo

Nivel	Prácticas
Ad-Hoc	Recopilación manual de evidencias antes de auditorías
Reactivo	Seguimiento en hojas de cálculo, revisiones periódicas
Proactivo	Recopilación automatizada de evidencias, monitorización continua
Optimizado	Compliance as code, dashboards en tiempo real, informes automatizados
Innovador	Certificación continua, informes públicos de transparencia

Checklist de autoevaluación

Califica tu organización en cada punto (Sí / Parcial / No):

Fase de build:

SAST se ejecuta automáticamente en cada pull request.
El escaneo de dependencias alerta sobre CVEs conocidos.
Las imágenes de contenedores se escanean antes de publicarse en un registry.
Las plantillas de IaC se escanean en busca de configuraciones incorrectas.
La detección de secretos impide que se hagan commit de credenciales.

Fase de despliegue:

Las puertas de seguridad pueden bloquear el despliegue por hallazgos críticos.
Los artefactos están firmados y las firmas se verifican.
Se genera un SBOM para cada release.
Los cambios de infraestructura pasan por validación de policy-as-code.

Fase de ejecución:

La monitorización de seguridad en runtime está activa (Falco, Sysdig, etc.).
Logging centralizado con alertas relevantes para seguridad.
La segmentación de red limita el radio de impacto.
Los secretos se gestionan a través de un vault dedicado.

Cultura y procesos:

Los desarrolladores reciben formación regular en seguridad.
Hay security champions integrados en los equipos de desarrollo.
Se realizan postmortems sin culpa después de los incidentes.
El threat modeling es parte del proceso de diseño de nuevas funcionalidades.
Las métricas de seguridad se rastrean y revisan regularmente.

Hoja de ruta para la progresión

Subir de nivel de madurez no ocurre de la noche a la mañana. Aquí tienes una hoja de ruta práctica:

De Ad-Hoc a Reactivo (3-6 meses)

Añade una herramienta SAST a tu pipeline de CI (empieza con Semgrep, tiene buenos valores por defecto y es rápido).
Habilita el escaneo de dependencias (GitHub Dependabot, o trivy fs en CI).
Documenta tu proceso de respuesta a incidentes, aunque sea básico.
Realiza una sesión de formación en seguridad para el equipo.

De Reactivo a Proactivo (6-12 meses)

Añade escaneo de imágenes de contenedores y escaneo de IaC a los pipelines.
Implementa detección de secretos en pre-commit hooks (gitleaks, detect-secrets).
Nombra security champions en cada equipo.
Comienza a hacer threat modeling para funcionalidades importantes.
Realiza tu primer postmortem sin culpa después de un incidente.
Despliega monitorización en runtime (Falco).

De Proactivo a Optimizado (12-18 meses)

Implementa puertas de seguridad que puedan bloquear despliegues.
Rastrea el MTTR y establece objetivos de reducción.
Genera SBOMs y firma los artefactos.
Implementa policy-as-code para infraestructura (OPA/Gatekeeper).
Mapea las comprobaciones automatizadas a frameworks de cumplimiento.
Integra las métricas de seguridad en los dashboards de ingeniería.

De Optimizado a Innovador (18+ meses)

Lanza un programa de bug bounty.
Construye herramientas de seguridad personalizadas para riesgos específicos de la organización.
Implementa arquitectura zero-trust.
Realiza ejercicios regulares de red team.
Contribuye a proyectos de seguridad open-source.

Aspectos culturales

Las herramientas y los procesos son necesarios pero insuficientes. La cultura determina si las prácticas de seguridad realmente se mantienen.

Postmortems sin culpa

Cuando ocurre un incidente de seguridad, el instinto suele ser buscar a alguien a quien culpar. Esto lleva a la gente a ocultar errores y encubrir casi-incidentes. Los postmortems sin culpa le dan la vuelta a esto: se centran en los fallos sistémicos y las mejoras de procesos en lugar de la responsabilidad individual. La pregunta cambia de “quién cometió este error” a “qué permitió que este error ocurriera y cómo lo prevenimos”.

Security Champions

Un security champion es un desarrollador que asume responsabilidad adicional en materia de seguridad dentro de su equipo. No son ingenieros de seguridad a tiempo completo — son desarrolladores que actúan como puente entre el equipo de seguridad y el equipo de desarrollo. Su papel incluye:

Revisar pull requests relevantes para seguridad.
Mantenerse al día en temas de seguridad y compartir conocimiento.
Participar en sesiones de threat modeling.
Ser el primer punto de contacto para preguntas de seguridad.

Este modelo escala mucho mejor que tener un equipo central de seguridad revisando todo.

Hacer la seguridad fácil

Si las prácticas de seguridad son dolorosas, la gente buscará atajos. El objetivo es hacer que la seguridad sea el camino más fácil:

Proporciona plantillas seguras y proyectos de inicio.
Automatiza tanto como sea posible para que los desarrolladores no tengan que recordar pasos manuales.
Da feedback rápido. Un escaneo SAST que tarda 30 minutos será ignorado; uno que tarda 30 segundos será utilizado.
Celebra las mejoras de seguridad igual que celebras la entrega de funcionalidades.

Conclusión

Un modelo de madurez DevSecOps es una brújula, no un destino. El valor viene de una autoevaluación honesta, establecer objetivos realistas y hacer un progreso constante. Empieza donde estás, elige la dimensión donde la mejora tendrá mayor impacto y construye a partir de ahí. La seguridad es un deporte de equipo. Las mejores culturas de seguridad se construyen de forma incremental, una práctica a la vez.

Introducción a AIOps: operaciones de TI inteligentes

Mon, 05 Dec 2022 00:00:00 +0000

¿Qué es AIOps?

AIOps (Artificial Intelligence for IT Operations) aplica machine learning y analítica de datos a los datos operativos (logs, métricas, eventos, trazas) para automatizar y mejorar flujos de trabajo. Gartner acuñó el término en 2017, pero la idea es simple: usar algoritmos para gestionar el volumen y la complejidad que los humanos no pueden manejar manualmente.

En términos prácticos, las plataformas AIOps ingieren datos de herramientas de monitorización, sistemas APM, agregadores de logs y fuentes de eventos. Aplican modelos de ML para detectar anomalías, correlacionar eventos, identificar causas raíz y, en algunos casos, desencadenar remediación automatizada. El objetivo es reducir el tiempo medio de detección (MTTD) y el tiempo medio de resolución (MTTR) mientras se libera a los equipos de operaciones de la fatiga por alertas.

Por qué la monitorización tradicional se queda corta

La monitorización funcionaba bien cuando los sistemas eran simples. Tenías pocos servidores, unas pocas apps y un número limitado de métricas. Un umbral estático de CPU o un regex en logs era suficiente.

La infraestructura moderna rompió ese modelo:

Escala: Un clúster de Kubernetes genera millones de métricas y logs por minuto. No puedes vigilar dashboards a esa escala.
Complejidad: Los microservicios crean dependencias enredadas. Una petición puede atravesar docenas de servicios. Encontrar qué causó una latencia significa correlacionar datos entre todos.
Entornos dinámicos: Auto-scaling, contenedores efímeros, serverless. Las baselines cambian constantemente y los umbrales estáticos explotan con falsos positivos.
Fatiga por alertas: Los equipos se hunden en alertas. Cuando el 90% es ruido, ese crítico 10% desaparece. Los ingenieros empiezan a ignorar todo.

AIOps no reemplaza la monitorización. Se sitúa encima de lo que ya tienes y lo hace más inteligente.

Capacidades clave

1. Detección de anomalías

En lugar de umbrales estáticos, AIOps usa modelos de ML (frecuentemente análisis de series temporales, clustering o autoencoders) para aprender qué aspecto tiene lo “normal” para cada métrica y servicio. Cuando el comportamiento se desvía significativamente de la línea base aprendida, se marca una anomalía.

Esto maneja el problema de la línea base dinámica. Si tu aplicación normalmente ve un pico de tráfico cada lunes a las 9 de la mañana, el modelo aprende ese patrón y no alerta por ello. Pero un pico inesperado a las 3 de la madrugada de un miércoles sí se marca.

2. Correlación de eventos

Un único problema de infraestructura puede generar cientos o miles de alertas relacionadas en diferentes herramientas de monitorización. AIOps correlaciona estos eventos — agrupándolos por tiempo, topología y relaciones causales — para presentar un único incidente en lugar de un muro de alertas.

Por ejemplo, un fallo en un switch de red podría disparar alertas en: el propio switch, todos los servidores conectados (conectividad perdida), todas las aplicaciones en esos servidores (fallos en health checks), y servicios downstream (errores de timeout). Una plataforma AIOps correlaciona todos estos en un incidente: “Switch de red X ha fallado.”

3. Análisis de causa raíz

Más allá de la correlación, AIOps intenta identificar la causa raíz de un incidente. Al comprender la topología de tu infraestructura y la cadena causal de eventos, puede sugerir que el fallo del switch de red es la causa raíz, en lugar de presentar el timeout de la aplicación como un problema independiente.

Aquí es donde el valor se vuelve tangible. En lugar de que un ingeniero de guardia pase 30 minutos rastreando a través de dashboards y logs, la plataforma muestra la causa raíz probable inmediatamente.

4. Auto-remediación

Las implementaciones más maduras de AIOps cierran el ciclo disparando acciones de remediación automatizadas. Si se detecta un patrón conocido (disco llenándose, un pod en CrashLoopBackOff, un proceso descontrolado consumiendo memoria), la plataforma puede ejecutar runbooks predefinidos automáticamente.

Ejemplos:

Reiniciar un pod o servicio caído.
Escalar un deployment cuando se detecta carga anómala.
Limpiar un directorio de logs cuando el uso de disco supera un umbral dinámico.
Disparar un failover cuando una base de datos primaria deja de responder.

La auto-remediación requiere un diseño cuidadoso. Empieza con acciones de bajo riesgo y amplía conforme crece la confianza.

Plataformas y herramientas comunes

El panorama de AIOps incluye tanto plataformas comerciales como bloques de construcción open-source:

Plataformas comerciales

Plataforma	Fortalezas
Dynatrace	Auto-descubrimiento robusto, motor de IA (Davis), observabilidad full-stack
Datadog	Monitorización unificada + alertas con ML, detección de anomalías Watchdog
Splunk ITSI	Analítica de logs potente + toolkit de ML, bueno para correlación de eventos
Moogsoft	Pionero en el espacio AIOps, fuerte correlación de eventos y reducción de ruido
BigPanda	Enfocado en correlación de eventos y automatización, se integra con herramientas existentes
PagerDuty	Gestión de incidentes con reducción de ruido por ML y agrupación inteligente

Bloques de construcción open-source

Puedes ensamblar un stack similar a AIOps con componentes open-source:

Recolección de datos: Prometheus, Grafana Agent, OpenTelemetry Collector, Fluentd/Fluent Bit.
Almacenamiento de datos: Prometheus (métricas), Elasticsearch/OpenSearch (logs), Jaeger/Tempo (trazas).
Detección de anomalías: Facebook Prophet, Isolation Forest (scikit-learn), luminol, Grafana ML.
Correlación de eventos: Lógica personalizada sobre streams de eventos, o StackStorm para automatización dirigida por eventos.
Alertas y automatización: Alertmanager, Grafana OnCall, StackStorm, Rundeck.

Construir un stack AIOps personalizado es significativamente más trabajo que usar una plataforma comercial, pero te da control total y evita el vendor lock-in. Un punto medio razonable es usar una plataforma comercial para las capacidades core de AIOps mientras mantienes tu pipeline de datos en open-source.

Casos de uso prácticos

Reducción de ruido en gestión de alertas

Un equipo que recibe más de 500 alertas al día implementa correlación de eventos AIOps. Las alertas relacionadas se agrupan en incidentes, los duplicados se suprimen y las alertas fluctuantes se silencian. El volumen de alertas baja un 80%, y el ingeniero de guardia puede enfocarse en incidentes reales.

Planificación proactiva de capacidad

Los modelos AIOps analizan tendencias históricas de uso de recursos y predicen cuándo se alcanzarán los límites de capacidad. En lugar de reaccionar a una alerta de disco lleno a las 2 de la madrugada, la plataforma predice el problema con dos semanas de antelación y crea un ticket para que el equipo lo aborde en horario laboral.

Respuesta a incidentes más rápida

Durante una caída de producción, la plataforma AIOps correlaciona alertas de todo el stack de monitorización, identifica la causa raíz (un despliegue reciente que introdujo una fuga de memoria) y muestra el commit del despliegue relevante. El MTTR baja de 45 minutos a 10 minutos.

Escalado automático

La plataforma detecta patrones de tráfico anómalos que se desvían de la línea base aprendida. En lugar de esperar a que la CPU alcance el 80% (el umbral estático), dispara una acción de scale-up basada en la tasa de cambio, asegurando que la capacidad está lista antes de que los usuarios experimenten degradación.

Cómo encaja AIOps en los flujos de trabajo DevOps

AIOps no es un reemplazo de las prácticas DevOps. Es una capa de mejora:

1
2
3
4
5


Código ──> CI/CD Pipeline ──> Deploy ──> Observar ──> Capa AIOps ──> Actuar
 │ │
 Monitoring Stack Modelos ML
 (métricas, logs, (detección de anomalías,
 trazas, eventos) correlación, RCA)

Los desarrolladores se benefician de una identificación más rápida de la causa raíz cuando su código causa problemas en producción.
Los equipos de operaciones se benefician de la reducción de ruido, remediación automatizada y alertas proactivas.
Los equipos SRE se benefician del seguimiento de SLOs basado en datos y el análisis de tasa de consumo del error budget.

AIOps funciona mejor cuando tu base de observabilidad es sólida. Si no estás recolectando buenos datos (logs estructurados, métricas significativas, trazas distribuidas), los modelos de ML no producirán insights significativos. Arregla primero tu observabilidad, luego añade AIOps encima.

Primeros pasos: Un camino pragmático

Si estás considerando AIOps, aquí tienes un enfoque práctico:

Audita tu stack de observabilidad actual. ¿Qué datos estás recolectando? ¿Los logs están estructurados? ¿Las métricas están etiquetadas de forma consistente? ¿Las trazas se propagan entre servicios? AIOps es tan bueno como los datos que ingiere.
Empieza con la reducción de ruido. Esta es la fruta que cuelga más baja. Implementa agrupación y deduplicación de alertas. Incluso una correlación básica basada en reglas (antes de cualquier ML) reducirá la fatiga por alertas significativamente.
Añade detección de anomalías a métricas clave. Elige 3-5 métricas críticas de negocio e infraestructura. Aplica un modelo de detección de anomalías de series temporales. Facebook Prophet o recording rules de Prometheus con ajustes estacionales son buenos puntos de partida.
Implementa remediación automatizada para problemas conocidos. Identifica los 5 incidentes recurrentes principales. Escribe runbooks para ellos. Automatiza los runbooks usando StackStorm, Rundeck o el motor de automatización de tu plataforma.
Evalúa una plataforma comercial cuando la complejidad lo requiera. Si tienes cientos de servicios, múltiples herramientas de monitorización y un equipo de operaciones creciente, la inversión en una plataforma AIOps comercial puede justificarse solo por la reducción en MTTR.
Mide el impacto. Sigue MTTD, MTTR, ratio alerta-a-incidente y tasa de falsos positivos. Sin métricas, no puedes probar que AIOps vale la pena.

AIOps no es magia. Es un conjunto de técnicas que, aplicadas a buenos datos operativos, pueden reducir la carga sobre los equipos y mejorar la fiabilidad. Empieza pequeño, mide todo, y escala lo que funcione.

Infraestructura como código con Terraform: guía práctica

Sat, 10 Sep 2022 00:00:00 +0000

Por qué importa la infraestructura como código

Gestionar infraestructura manualmente a través de consolas web o scripts ad-hoc crea problemas que se acumulan con el tiempo: entornos inconsistentes, cambios sin documentar, rollbacks imposibles y el clásico “funciona en mi máquina” extendido a servidores enteros.

La Infraestructura como Código (IaC) resuelve esto tratando la infraestructura como el código de aplicación: se escribe, versiona, revisa, prueba y aplica mediante flujos de trabajo automatizados. Los beneficios llegan rápidamente:

Reproducibilidad: Levanta entornos idénticos en minutos, no en días.
Control de versiones: Cada cambio de infraestructura pasa por un PR con revisión de código.
Documentación por defecto: El código es la documentación de cómo es tu infraestructura.
Recuperación ante desastres: Reconstruye todo desde código si una región cae.
Visibilidad de costes: Revisa los cambios de infraestructura antes de aplicarlos (y antes de que empiecen a costar dinero).

Terraform vs otras herramientas

Existen varias herramientas de IaC. Así es como Terraform se compara con las principales alternativas:

Característica	Terraform	Pulumi	CloudFormation	Ansible
Lenguaje	HCL (declarativo)	Python, TypeScript, Go, etc.	JSON/YAML	YAML (procedural)
Soporte cloud	Multi-cloud	Multi-cloud	Solo AWS	Multi-cloud (vía módulos)
Gestión de estado	Fichero de estado explícito	Gestionado por servicio Pulumi	Gestionado por AWS	Sin estado
Curva de aprendizaje	Moderada	Varía según lenguaje	Moderada	Baja
Ecosistema	Enorme ecosistema de providers	En crecimiento	Solo AWS pero profundo	Enorme ecosistema de roles
Ideal para	Infra multi-cloud	Equipos que prefieren lenguajes de propósito general	Entornos solo AWS	Gestión de configuración

El punto fuerte de Terraform es el aprovisionamiento de infraestructura multi-cloud con un enfoque declarativo. Si estás solo en AWS y quieres integración estrecha, CloudFormation es razonable. Si tu equipo prefiere escribir Python en lugar de HCL, Pulumi merece una mirada. Pero para la mayoría de equipos que gestionan infraestructura entre distintos proveedores, Terraform es la elección pragmática.

Conceptos fundamentales

Providers

Los providers son plugins que permiten a Terraform interactuar con APIs — AWS, Azure, GCP, Kubernetes, GitHub, Cloudflare y cientos más.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


terraform {
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~> 5.0"
 }
 }
}

provider "aws" {
 region = "eu-west-1"
}

Resources

Los resources son los bloques de construcción fundamentales. Cada bloque resource describe un objeto de infraestructura.

1
2
3
4
5
6
7
8


resource "aws_instance" "web" {
 ami = "ami-0c55b159cbfafe1f0"
 instance_type = "t3.micro"

 tags = {
 Name = "web-server"
 }
}

State

Terraform mantiene un fichero de estado que mapea tu configuración a recursos del mundo real. Así es como Terraform sabe qué existe, qué necesita cambiar y qué destruir. El fichero de estado es crítico. Perderlo significa que Terraform pierde la pista de tu infraestructura.

Modules

Los modules son paquetes reutilizables de configuración Terraform. Piensa en ellos como funciones: reciben entradas (variables), crean recursos y producen salidas.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


module "vpc" {
 source = "terraform-aws-modules/vpc/aws"
 version = "5.1.0"

 name = "my-vpc"
 cidr = "10.0.0.0/16"

 azs = ["eu-west-1a", "eu-west-1b"]
 private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
 public_subnets = ["10.0.101.0/24", "10.0.102.0/24"]

 enable_nat_gateway = true
}

Ejemplo práctico: VPC + EC2

Aquí hay un ejemplo completo que aprovisiona una VPC con una subred pública y una instancia EC2:

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114


terraform {
 required_version = ">= 1.5.0"
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~> 5.0"
 }
 }
}

provider "aws" {
 region = "eu-west-1"
}

# --- Networking ---

resource "aws_vpc" "main" {
 cidr_block = "10.0.0.0/16"
 enable_dns_support = true
 enable_dns_hostnames = true

 tags = {
 Name = "main-vpc"
 }
}

resource "aws_subnet" "public" {
 vpc_id = aws_vpc.main.id
 cidr_block = "10.0.1.0/24"
 availability_zone = "eu-west-1a"
 map_public_ip_on_launch = true

 tags = {
 Name = "public-subnet"
 }
}

resource "aws_internet_gateway" "gw" {
 vpc_id = aws_vpc.main.id

 tags = {
 Name = "main-igw"
 }
}

resource "aws_route_table" "public" {
 vpc_id = aws_vpc.main.id

 route {
 cidr_block = "0.0.0.0/0"
 gateway_id = aws_internet_gateway.gw.id
 }

 tags = {
 Name = "public-rt"
 }
}

resource "aws_route_table_association" "public" {
 subnet_id = aws_subnet.public.id
 route_table_id = aws_route_table.public.id
}

# --- Security Group ---

resource "aws_security_group" "web" {
 name = "web-sg"
 description = "Allow HTTP and SSH"
 vpc_id = aws_vpc.main.id

 ingress {
 from_port = 80
 to_port = 80
 protocol = "tcp"
 cidr_blocks = ["0.0.0.0/0"]
 }

 ingress {
 from_port = 22
 to_port = 22
 protocol = "tcp"
 cidr_blocks = ["YOUR_IP/32"] # Restringir a tu IP
 }

 egress {
 from_port = 0
 to_port = 0
 protocol = "-1"
 cidr_blocks = ["0.0.0.0/0"]
 }
}

# --- EC2 Instance ---

resource "aws_instance" "web" {
 ami = "ami-0c55b159cbfafe1f0"
 instance_type = "t3.micro"
 subnet_id = aws_subnet.public.id
 vpc_security_group_ids = [aws_security_group.web.id]

 tags = {
 Name = "web-server"
 }
}

# --- Outputs ---

output "instance_public_ip" {
 value = aws_instance.web.public_ip
}

output "vpc_id" {
 value = aws_vpc.main.id
}

El flujo plan/apply

Terraform sigue un flujo de trabajo predecible:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. Inicializar - descargar providers y modules
terraform init

# 2. Formatear - asegurar estilo de código consistente
terraform fmt

# 3. Validar - comprobar sintaxis y configuración
terraform validate

# 4. Plan - previsualizar qué cambiará (¡paso crítico!)
terraform plan -out=tfplan

# 5. Apply - ejecutar el plan
terraform apply tfplan

# 6. Destroy - destruir todos los recursos (cuando sea necesario)
terraform destroy

El paso terraform plan es el más importante. Nunca te lo saltes. Siempre revisa la salida del plan antes de aplicar, especialmente en producción. El plan te muestra exactamente qué se creará, modificará o destruirá.

1
2


# Ejemplo de salida del plan
Plan: 6 to add, 0 to change, 0 to destroy.

En pipelines CI/CD, guarda el plan en un fichero (-out=tfplan) y aplica ese plan exacto. Esto previene condiciones de carrera donde la infraestructura cambia entre el plan y el paso de apply.

Buenas prácticas de gestión de estado

La gestión de estado es donde se originan la mayoría de problemas con Terraform. Sigue estas prácticas:

Usa un backend remoto

Nunca almacenes el estado localmente o en Git. Usa un backend remoto con cifrado y bloqueo:

1
2
3
4
5
6
7
8
9


terraform {
 backend "s3" {
 bucket = "my-terraform-state"
 key = "prod/networking/terraform.tfstate"
 region = "eu-west-1"
 encrypt = true
 dynamodb_table = "terraform-locks"
 }
}

La tabla DynamoDB proporciona bloqueo de estado. Esto previene que dos personas o pipelines modifiquen la misma infraestructura al mismo tiempo.

Organiza el estado por componente

No pongas toda tu infraestructura en un solo fichero de estado. Divídela por componente o equipo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


environments/
├── prod/
│ ├── networking/ # VPC, subnets, routes
│ ├── compute/ # EC2, ASGs, load balancers
│ ├── database/ # Instancias RDS
│ └── monitoring/ # CloudWatch, alertas
└── staging/
 ├── networking/
 ├── compute/
 └── database/

Ficheros de estado más pequeños significan planes más rápidos, menor radio de explosión y menos equipos compitiendo por los bloqueos.

Usa `terraform_remote_state` con moderación

Puedes referenciar outputs de otros ficheros de estado, pero úsalo con cuidado. El uso excesivo de remote state crea acoplamiento fuerte entre componentes. Prefiere pasar valores a través de variables o un parameter store.

Consejos para uso en producción

Fija las versiones de los providers. Usa restricciones ~> para permitir actualizaciones de parche pero prevenir cambios incompatibles: version = "~> 5.0".
Usa workspaces con cuidado. Los workspaces son útiles para separación simple de entornos pero se vuelven confusos a escala. Directorios separados por entorno suele ser más claro.
Implementa un pipeline CI/CD para Terraform. Ejecuta terraform plan en PRs y publica la salida como comentario en el PR. Ejecuta terraform apply solo después del merge y la aprobación.
Usa prevent_destroy para recursos críticos. Esta regla de lifecycle evita la destrucción accidental de bases de datos o almacenamiento persistente:
1 2 3 4 5 6

resource "aws_db_instance" "main" { # ... lifecycle { prevent_destroy = true } }
Etiqueta todo. Usa un bloque default_tags en el provider para asegurar que cada recurso recibe tags estándar (entorno, equipo, proyecto).
Usa tflint y checkov. Haz lint de tu código Terraform y escanea en busca de configuraciones inseguras antes de aplicar.
1 2 3

tflint --init tflint checkov -d .
Importa recursos existentes. Si tienes infraestructura creada manualmente, usa terraform import para traerla bajo gestión en lugar de recrearla.
Revisa el diff del plan cuidadosamente. Un recurso que muestra “destroy and recreate” puede causar tiempo de inactividad. Entiende qué cambios son in-place versus destructivos.

Terraform es una de esas herramientas que recompensa la disciplina. Cuanto más consistentemente sigas estas prácticas, con más confianza gestionará tu equipo la infraestructura a escala.