Un cambio de infraestructura como código necesita una cadena de evidencia desde la propuesta hasta el estado desplegado. La aprobación de una solicitud de cambio demuestra una decisión sobre una versión concreta; no demuestra por sí sola que esa misma versión se aplicó ni que los recursos resultantes mantuvieron la configuración prevista.
El entregable de esta guía es un registro de cambio con diferencia planificada, decisión del revisor, excepciones y verificación posterior. Se utiliza Terraform como ejemplo documentado de planificación, sin convertir sus comandos en un procedimiento universal para todas las herramientas. La documentación de terraform plan se comprobó de nuevo el 27 de septiembre de 2026.
Definir la identidad del cambio
Asigne un identificador estable al cambio y relaciónelo con repositorio, revisión, entorno y recurso o conjunto de recursos afectados. Un enlace a la rama principal no basta porque su contenido puede cambiar. La evidencia debe permitir recuperar la versión revisada y distinguirla de modificaciones posteriores.
Incluya versiones de herramientas y proveedores cuando sean relevantes para reproducir el comportamiento. Una misma configuración puede producir diferencias al actualizar un proveedor o modificar variables. No es necesario almacenar todos los detalles en una sola ficha: puede enlazar evidencias mantenidas en sistemas con acceso y conservación adecuados.
La metodología de auditoría RGPD ofrece un contexto de trazabilidad cuando la infraestructura trata datos personales. El registro de cambios también debe cubrir recursos sensibles que no se limiten a ese ámbito.
Separar propuesta, plan y aplicación
El código propuesto describe una intención. El plan muestra las acciones calculadas en un contexto determinado. La aplicación intenta ejecutar esas acciones y puede fallar o quedar parcialmente completada. La comprobación posterior observa el estado relevante del entorno. Son evidencias relacionadas, pero diferentes.
En Terraform es posible guardar un plan para su posterior aplicación según el procedimiento documentado. La elección y protección de ese artefacto deben formar parte del proceso interno. Los planes pueden contener información sensible; no deben publicarse indiscriminadamente como adjuntos de una revisión.
Evite afirmar que un plan aprobado conserva su validez para siempre. Si cambia el contexto, la configuración o el estado relevante, determine si hace falta volver a planificar y revisar. El criterio debe ser explícito, sobre todo para cambios que alteran acceso, exposición de red o protección de datos.
Construir el expediente mínimo
| Campo | Información necesaria | Evidencia asociada |
|---|---|---|
| Cambio | Motivo y resultado esperado | Solicitud y responsable del servicio |
| Versión | Revisión exacta y configuración de ejecución | Referencias inmutables |
| Diferencia | Creación, modificación o destrucción prevista | Plan y explicación de efectos sensibles |
| Revisión | Persona, decisión y condiciones | Registro de aprobación |
| Excepción | Regla afectada y riesgo aceptado | Decisión con alcance y finalización |
| Ejecución | Operador, entorno y resultado | Registro de despliegue |
| Verificación | Recursos y condiciones comprobadas | Lectura posterior o prueba autorizada |
| Cierre | Resultado, desviaciones y tareas pendientes | Decisión final del responsable |
El expediente debe permitir enlazar estos elementos sin copiar secretos. Si un registro de ejecución contiene credenciales o datos sensibles, limite su acceso y corrija el origen de esa exposición. La necesidad de evidencia no justifica crear un archivo de secretos innecesario.
Revisar las consecuencias de seguridad
El revisor debe explicar qué cambia en las posibilidades del sistema: quién puede acceder, desde dónde, a qué datos y con qué capacidad de modificación. Una diferencia pequeña en el código puede ampliar mucho una política de acceso; una diferencia grande puede consistir en una reorganización sin efecto equivalente.
Examine permisos, exposición pública, cifrado, registros, copias y eliminación de recursos según el cambio. No reduzca la revisión a que el formato sea válido o que una herramienta estática no produzca alertas. La comprobación automática tiene un alcance que debe conocerse.
NIST SP 800-53A, comprobado de nuevo el 27 de septiembre de 2026, distingue métodos de evaluación que ayudan a combinar examen de registros y pruebas. El marco de ISO 27001 y RGPD puede orientar la conexión con riesgos y responsabilidades internos.
Ejemplo: una regla de red más amplia de lo solicitado
Una empresa ficticia necesita permitir que una aplicación acceda a una base de datos. El cambio propuesto incluye una regla de red y una actualización del grupo de seguridad. El plan revela que la regla permite conexiones desde una red más amplia que la de la aplicación.
El revisor rechaza esa parte y pide limitar el origen. Se genera una nueva versión y un nuevo plan. La aprobación referencia ambos, de forma que la primera propuesta no pueda confundirse con la aceptada. Durante la ejecución, una modificación manual previa provoca una diferencia adicional que requiere análisis.
El equipo detiene la aplicación según su procedimiento y determina qué estado debe conservarse. Tras resolverlo, revisa el plan actualizado. La comprobación posterior confirma el acceso necesario y la ausencia del acceso ampliado que se pretendía evitar. El expediente registra también la modificación manual como una causa que debe tratarse.
El cambio se cierra por el resultado observado, no por el hecho de que una tarea automatizada aparezca en verde. Si parte de la comprobación queda pendiente, el estado final debe mostrar esa limitación y quién la resolverá.
Documentar excepciones sin desactivar la regla general
Una política puede impedir una configuración necesaria de manera temporal. La excepción identifica la regla, el recurso, el motivo, la duración y la persona autorizada para aceptar el riesgo. Debe describir una medida compensatoria concreta cuando corresponda.
Evite introducir una exclusión global para resolver un único caso. Compruebe que la excepción se aplica al recurso previsto y que su finalización genera una acción verificable. Una fecha escrita en una solicitud no modifica automáticamente el código ni el entorno.
La gestión de riesgos con escenarios ayuda a explicar el riesgo aceptado. La excepción no debe justificarse con una frase genérica como «necesidad del negocio» si no se entiende qué consecuencia se está admitiendo.
Decidir cuándo un plan necesita otra revisión
Un plan aprobado está ligado a las entradas con las que se calculó: revisión del código, variables, estado conocido y entorno. Antes de ejecutar, compare esas referencias con las disponibles en el momento de la aplicación. Si alguien modificó un recurso manualmente, cambió una variable o actualizó un proveedor, el revisor necesita saber si la diferencia altera el efecto de seguridad aprobado. La referencia de terraform plan explica los modos de planificación y advierte sobre las consecuencias de omitir la actualización del estado remoto.
Una regla práctica es volver a planificar y pedir otra decisión cuando cambia el alcance de permisos, la exposición pública, la eliminación de recursos o el tratamiento de datos. Para una variación inocua puede bastar una justificación documentada según el procedimiento de la organización. Defina quién toma esa decisión; no la deje implícita en un botón de ejecución. El criterio es el efecto del cambio, no el número de líneas modificadas.
Si se guarda un plan para aplicarlo después, vincule su identificador al cambio aprobado y compruebe que la ejecución utiliza ese artefacto. El archivo merece controles de acceso y conservación: la documentación de HashiCorp sobre datos sensibles señala que los archivos de estado y plan pueden contener valores sensibles. Un resumen redactado para revisión puede ser más fácil de compartir, siempre que la versión completa permanezca protegida y sea recuperable por quienes deben comprobar el cambio.
Tratar cambios urgentes y modificaciones manuales
Un incidente puede exigir una acción rápida fuera del flujo habitual. Defina quién puede autorizarla, cómo se registra y cómo se incorpora después a la configuración declarada. La urgencia puede cambiar el orden de algunas revisiones, pero no debe borrar la evidencia de lo que ocurrió.
Concilie el estado real con el código después de la intervención. Una corrección manual no incorporada puede desaparecer en el siguiente despliegue o producir diferencias inesperadas. El expediente debe indicar si el cambio manual se conserva, se sustituye o se revierte.
El procedimiento de brechas de seguridad puede compartir hechos cuando exista una afectación de datos personales. Mantenga separadas la decisión técnica de cambio y las evaluaciones de incidente o notificación que correspondan.
Distinguir deriva, emergencia y estado deseado
Cuando aparece una diferencia entre código y recurso real, no presuponga que el código representa siempre la decisión correcta. Un cambio manual puede ser un error, una intervención urgente todavía no incorporada o una configuración impuesta por otro equipo. Investigue quién lo hizo, por qué y desde cuándo. La guía de HashiCorp sobre deriva muestra que una planificación de solo actualización puede revelar cambios externos; aceptar esa actualización del estado no corrige por sí sola la configuración declarada.
Documente la resolución entre tres opciones: incorporar la modificación al código, devolver el recurso a la configuración aprobada o mantener una excepción limitada mientras se decide. En cada caso identifique al dueño de la decisión, el efecto sobre el servicio y la comprobación esperada. Una intervención urgente sobre una regla de red, por ejemplo, puede haber reducido exposición durante un incidente. Revertirla automáticamente en el siguiente despliegue reabriría el acceso que se intentó cerrar.
Si el recurso está compartido por varios equipos, la conciliación requiere hablar con sus propietarios antes de modificarlo. Registre también las dependencias que quedaron fuera del plan inicial. Un expediente que explique la deriva permite evitar dos errores frecuentes: normalizar modificaciones no autorizadas sin revisarlas y forzar una reversión que interrumpe una medida legítima. La diferencia visible es una señal para investigar, no una decisión ya tomada.
Verificar recursos y servicio
Planifique la verificación antes de aplicar: convierta las condiciones de aprobación en preguntas verificables. Para una base de datos privada: ¿permite acceso desde la aplicación prevista?, ¿rechaza el origen que motivó la revisión?, ¿sigue habilitado el registro necesario? Indique qué lectura de configuración o prueba autorizada responde cada pregunta y quién la ejecuta. De este modo la verificación posterior no depende de recordar qué preocupó al revisor.
La prueba funcional y la de seguridad pueden dar resultados distintos. Un servicio puede atender solicitudes y, a la vez, exponer un puerto a una red más amplia de lo previsto. También puede tener una política correcta pero fallar porque una dependencia no quedó configurada. Registre ambos resultados y no cierre el cambio mientras una condición material siga sin comprobarse. Para una eliminación, compruebe el tratamiento previsto de datos, dependencias y copias. Conserve el resultado de las pruebas y los límites del entorno utilizado; si solo se verificó una región o una cuenta, nombre explícitamente las restantes.
Evite presentar un resultado de herramienta como garantía absoluta. El plan describe acciones calculadas para recursos gestionados; una comprobación posterior debe observar el recurso y las condiciones relevantes del servicio. La publicación NIST SP 800-53A ofrece métodos de examen, entrevista y prueba para valorar controles. Aquí se utiliza como orientación para combinar tipos de evidencia, sin afirmar que este expediente equivale a una evaluación integral de ese marco.
El ENS aporta un contexto adicional cuando resulte aplicable. No describa una cadena de despliegue o un registro de cambios como prueba suficiente de cumplimiento integral de ese esquema.
Preparar un traspaso que soporte auditoría y operación
Un operador que no participó en la revisión debe poder responder cuatro preguntas: qué se pretendía cambiar, quién aprobó los efectos sensibles, qué se ejecutó realmente y qué quedó abierto. Reúna referencias estables a la solicitud, revisión, plan protegido, registro de ejecución y verificación. No es necesario duplicar archivos en varios sistemas si las referencias tienen permisos y periodos de conservación adecuados.
Cuando una ejecución falla a mitad de camino, consigne qué recursos cambiaron y cuáles no. Determine si puede reintentarse con seguridad, si hace falta un nuevo plan o si procede una reversión. El resultado parcial es un nuevo estado que merece evaluación; etiquetar la tarea como «fallida» no devuelve automáticamente el entorno a su condición anterior. El responsable del servicio debe conocer las funciones afectadas mientras se resuelve.
Al cierre, entregue al equipo de operación las excepciones vigentes, las alertas que conviene vigilar y la próxima acción prevista. Si se retiró una protección de forma temporal, indique quién comprobará su restitución. Este traspaso convierte la trazabilidad en una herramienta para el siguiente cambio, no solo en una carpeta de evidencias retrospectivas. También deja claro qué aprobación deberá renovarse si la situación excepcional persiste.
Cerrar y reutilizar el aprendizaje
El cierre identifica resultado, desviaciones, excepciones abiertas y medidas de seguimiento. Conserve la versión revisada, la realmente aplicada y la prueba de estado, aunque coincidan. Esa coincidencia es precisamente una parte de lo que debe poder demostrarse.
Revise los casos en que la planificación omitió una dependencia o la ejecución requirió una intervención inesperada. Ajuste el proceso de revisión con ejemplos concretos. Un expediente útil permite a otra persona reconstruir por qué se autorizó el cambio y qué evidencia confirmó que el entorno terminó en el estado esperado.