La gestión de configuración es la práctica de saber cómo debe verse cada sistema de tu infraestructura y mantenerlo así. Abarca el inventario de activos y sus dependencias, los parámetros aprobados con los que opera cada uno y el proceso que gobierna cómo cambian esos parámetros.
El 1 de agosto de 2012, Knight Capital desplegó código nuevo de forma incorrecta. En los primeros 45 minutos de mercado, su router envió más de 4 millones de órdenes para cubrir 212 órdenes de clientes. La firma perdió más de 460 millones de dólares y la SEC le impuso después una multa de 12 millones. No hubo atacante. Un cambio llegó a producción en un estado que nadie había aprobado.
Esta página cubre qué es la gestión de configuración, en qué se diferencia de la gestión de cambios y de la gestión de configuración de seguridad, los seis pasos del ciclo, las herramientas que lo automatizan y qué dicen nuestros datos de 2025 sobre dónde aparecen realmente los fallos de configuración.
¿Qué es la gestión de configuración?
La gestión de configuración es un proceso de TI que rastrea, controla y documenta los cambios en la configuración, los recursos y los servicios de un sistema. Registra cada componente, parámetro y dependencia, y cómo se relacionan entre sí. Una buena gestión de configuración responde una sola pregunta en cualquier momento: ¿este sistema está ejecutando lo que aprobamos?
La disciplina es más antigua que el software. El Departamento de Defensa de Estados Unidos la formalizó para sistemas militares en su serie 480 de estándares, el control de versiones la trajo al desarrollo de software, y DevOps la convirtió en práctica diaria cuando los equipos empezaron a desplegar infraestructura con la misma frecuencia que el código.
La seguridad añade una segunda capa. El NIST la llama gestión de configuración enfocada en seguridad, o SecCM, y fija su objetivo como gestionar y supervisar las configuraciones de los sistemas para “lograr una seguridad adecuada y minimizar el riesgo organizacional sin dejar de dar soporte a la funcionalidad de negocio requerida” (NIST SP 800-128, actualizado en 2019). Vale la pena conservar la distinción: la gestión de configuración común pregunta si un sistema coincide con su estado aprobado, mientras que la gestión de configuración enfocada en seguridad pregunta si ese estado aprobado es seguro en primer lugar. Un parque de sistemas puede ser perfectamente consistente y uniformemente inseguro.
¿Por qué es importante la gestión de configuración?
La gestión de configuración importa porque los parámetros hoy cargan tanto riesgo como el código. Un permiso, una regla de firewall o una política de almacenamiento deciden a qué llega un atacante una vez adentro, y esas decisiones viven en archivos que cambian mucho más seguido que la lógica de la aplicación. Eso convirtió la gestión de configuración de un asunto de operaciones en un control de seguridad.
La configuración insegura ya es la segunda clase de debilidad más común
El análisis de Fluid Attacks del OWASP Top 10 2025 encontró que la configuración insegura subió del quinto puesto en 2021 al segundo en 2025, y que hoy abarca 16 CWE y está presente en el 3 % de las aplicaciones evaluadas. En ese mismo periodo, más comportamiento de las aplicaciones salió del código compilado hacia archivos de configuración, permisos de nube y plantillas de infraestructura.
La mayoría de los fallos de configuración son baratos, y unos pocos no
De las 1.119.396 vulnerabilidades que reportamos en los sistemas de nuestros clientes en 2025, la configuración insegura de servicios en EC2 por sí sola representó 44.667 hallazgos con 149.840,91 unidades CVSSF de exposición al riesgo (State of Attacks 2026). El acceso no autorizado a archivos en servicios de almacenamiento en la nube sumó 13.499 hallazgos y 500.832,48 CVSSF.
Luego está el otro tipo. La información confidencial sin cifrar en Azure apareció en apenas el 4,8 % de los sistemas y 1.789 hallazgos, pero cargó 809.671,94 CVSSF: más riesgo que los hallazgos de EC2 y almacenamiento juntos, desde el 3 % de su volumen. Volumen y riesgo no son lo mismo, y un programa de gestión de configuración que trate cada desviación como igual de urgente gastará su tiempo en las equivocadas.
Es lo que hace reproducible un entorno
Sin un estado deseado registrado, ningún entorno se reconstruye con confianza, ningún incidente se rastrea hasta el cambio que lo causó y a ningún auditor se le puede mostrar cómo se veía el sistema el trimestre pasado. La reproducibilidad es el beneficio silencioso de la gestión de configuración, y solo se nota cuando ya no está.
Un equipo con un estado deseado versionado restaura desde él; uno sin él reconstruye de memoria.
Gestión de configuración, gestión de cambios y gestión de configuración de seguridad no son lo mismo
Los tres términos se traslapan y se intercambian con frecuencia. Responden preguntas distintas, y confundirlos es como un equipo termina con un registro de cambios impecable sobre una infraestructura insegura.
Práctica | Pregunta que responde | Qué controla | Qué falla sin ella |
|---|---|---|---|
Gestión de configuración | ¿Cómo debería verse este sistema, y se ve así? | Inventario, dependencias, parámetros aprobados, desviación | Los entornos dejan de ser reproducibles; los incidentes no se rastrean |
Control de cambios | ¿Quién aprobó este cambio, y cuándo? | La solicitud, la revisión, la aprobación y la ruta de reversión | Cambios sin revisar llegan a producción, como en Knight Capital |
Gestión de configuración de seguridad | ¿El estado aprobado es seguro en sí mismo? | Líneas base endurecidas, mínimo privilegio, cifrado | La infraestructura queda consistente y uniformemente expuesta |
Una regla práctica: el control de cambios te dice que un parámetro se movió, la gestión de configuración te dice de dónde y hacia dónde se movió, y solo la gestión de configuración de seguridad te dice si el destino era adonde querías llegar.
Gestión de configuración en Fluid Attacks
No vendemos una plataforma de gestión de configuración. Evaluamos las configuraciones que una produce: en las plantillas antes de desplegarse, en la cuenta de nube después de hacerlo y en la aplicación en ejecución, con DAST y pruebas manuales, donde aparecen sus consecuencias. Nuestro papel dentro de un programa de gestión de configuración es acotado: te decimos qué parámetros aprobados no son seguros.
Qué evaluamos, y bajo qué reglas
Cada evaluación corre contra un alcance definido y un criterio escrito. Para los hallazgos de gestión de configuración, el requisito que gobierna es el número 062 de nuestro catálogo abierto, que establece que “el sistema debe seguir las configuraciones estándar de la industria que previenen todas las vulnerabilidades conocidas”. Ese requisito mapea a los CIS Controls 4.1 y 4.2, al control 8.9 de ISO/IEC 27001, a PCI DSS 2.2.6 y a NIST SP 800-171 3.4.2, así que un hallazgo contra él ya viene expresado en el lenguaje que usa un auditor.
Cómo se ve en la práctica
Dónde vive la configuración | Cómo la evaluamos | Criterios de ejemplo |
|---|---|---|
IaC y archivos de configuración: Terraform, CloudFormation, Kubernetes, Helm, Docker Compose, ARM | SAST sobre el repositorio | Terraform excessive attach privileges; Terraform publicly accessible true |
La cuenta de AWS desplegada | AWS permissive role policies; AWS admin policy attached; AWS unrestricted security groups | |
Identidades y roles, donde sea que se definan | SAST, CSPM y revisión manual | Excessive privileges - AWS: “la aplicación, un usuario o un rol tienen más privilegios de los que requieren” |
Lo que la configuración habilita en producción | PTaaS y pruebas manuales | Unrestricted access between network segments - AWS; Insecure service configuration - ELB; Improper authorization control for web services - RDS |
El cambio, antes de integrarse | CI Gate en el pipeline | Política sobre hallazgos sin remediar según su severidad |
Nuestro requisito 062 y los controles a los que mapea, tal como se publican en nuestro catálogo abierto de criterios.
Qué encuentran las pruebas manuales que los escáneres no
Un escáner lee un parámetro. Un pentester deduce qué le permite hacer ese parámetro. La brecha entre esas dos cosas se ve con claridad en nuestros propios números.
Medida | Herramientas automatizadas | Pentesters |
|---|---|---|
Porcentaje de vulnerabilidades reportadas en 2025 | 88,4 % | 11,6 % |
Porcentaje de exposición al riesgo reportada en 2025 | 55,8 % | 44,2 % |
Porcentaje de vulnerabilidades críticas | 13 % | 87 % |
Exposición media al riesgo por hallazgo (CVSSF) | 15,5 | 93,2 |
Las herramientas automatizadas reportan más hallazgos; los pentesters reportan más riesgo. Fuente: State of Attacks 2026.
La misma división aparece en condiciones controladas. En el benchmark de Fluid Attacks de 36 herramientas AppSec de terceros contra una aplicación sembrada con 1.201 vulnerabilidades en 105 categorías CWE, un pentester alcanzó un 89,6 % de recall con un 100 % de precisión, y cubrió el 86,8 % de la exposición total al riesgo. El escáner automatizado con mejor desempeño fue el nuestro, con un 99 % de precisión pero un 22,7 % de recall y un 8,8 % de la exposición al riesgo. Esas evaluaciones manuales las ejecutan profesionales de seguridad ofensiva certificados.
Qué cubre nuestro CSPM
Nuestro escáner de Cloud Security Posture Management analiza entornos AWS en busca de configuraciones vulnerables. Es un alcance deliberado, y vale la pena decirlo sin rodeos en vez de insinuar una cobertura más amplia.
Tampoco es de donde sale cada hallazgo de configuración en la nube. La debilidad de configuración más costosa en nuestros datos de 2025, la información confidencial sin cifrar con 809.671,94 CVSSF, estaba en Azure. Las configuraciones de Azure y GCP nos llegan a través de las plantillas de IaC que lee SAST y del pentesting manual, y por eso las plantillas de tu repositorio importan tanto como la cuenta en la que se despliegan. Para la mayoría de los equipos, la cobertura de gestión de configuración empieza en el repositorio y no en la consola.
Revisa los pull requests de infraestructura como si fueran código de pagos
La práctica que decide qué tan bien funciona todo lo demás es simple y casi siempre se omite. Nuestra revisión del incidente de Binance de 2026 lo plantea de frente: cuando un repositorio define infraestructura en Terraform, manifiestos de Kubernetes o archivos de Docker Compose, un fallo de configuración es un fallo de código, y un pull request que cambia un role binding o una regla de firewall merece la misma revisión que un cambio en la lógica de pagos.
Los datos respaldan el hábito. Entre los sistemas que evaluamos en 2025, los que corrían nuestro CI Gate en el pipeline alcanzaron una tasa de remediación del 72,2 % frente al 58 % sin él, y una mediana de remediación de 22 días frente a 30: un 26,7 % más rápido. Poner la compuerta en el pipeline es lo que vuelve exigible, y no meramente sugerida, la gestión de configuración.
Cómo funciona la gestión de configuración
La gestión de configuración opera como un ciclo de seis pasos, no como un proyecto con fecha de cierre. Cada paso produce un artefacto del que depende el siguiente.
1. Identificar los activos
Inventaría cada sistema, servicio, dependencia y responsable. Un activo que nadie posee es un activo que nadie parcha. Muchos equipos guardan ese inventario en una base de datos de gestión de configuración, que almacena esos componentes y sus relaciones.
2. Definir líneas base seguras
Una línea base de configuración es el estado aprobado: los parámetros con los que se espera que opere un sistema, escritos y versionados. El CIS Control 4 (Controls v8.1) pide a las organizaciones “establecer y mantener la configuración segura de los activos empresariales” (equipos de usuario, dispositivos de red, IoT y servidores) “y del software”. Los valores por defecto de los fabricantes están pensados para la instalación, no para la seguridad, así que la línea base es donde el endurecimiento se especifica, no se asume. Lo que Fluid Attacks ha escrito sobre productos seguros por defecto sostiene que los fabricantes deberían entregar configuraciones suficientemente seguras para que los clientes no queden haciendo ese trabajo solos.
3. Controlar los cambios
Toda desviación de la línea base pasa por revisión, aprobación y una ruta de reversión registrada. Los permisos merecen la versión más estricta de esto. El principio de mínimo privilegio es el único parámetro de la línea base que limita el daño de cualquier otro error, y nuestro analista de seguridad Jonathan Armas expuso sin rodeos el costo de ignorarlo en Secure cloud as code:
“An open port is a window to your infrastructure increasing the attack surface that we as pentesters can exploit, so why open it to the world?”
(Un puerto abierto es una ventana a tu infraestructura que amplía la superficie de ataque que los pentesters podemos explotar, ¿para qué abrirlo al mundo?)
En el mismo artículo señala que la mayoría de las llaves de AWS que ha comprometido estaban configuradas con permisos excesivos.
4. Automatizar con infraestructura como código
Terraform y AWS CloudFormation permiten escribir las definiciones de infraestructura como código, guardarlas en un repositorio y desplegarlas a través de un pipeline. Eso convierte una configuración en un artefacto revisable, versionado y reproducible, y en algo que un escáner puede leer antes de que llegue a una cuenta de nube. Aquí también es donde DevSecOps se gana su lugar: lo que hemos escrito sobre asegurar los despliegues en la nube identifica la configuración incorrecta de servicios de nube como una de las principales causas de desastre, y defiende detectarla en archivos de IaC e imágenes de contenedor, no en producción. Implementar DevSecOps es más fácil de empezar por aquí, porque los artefactos ya están en control de versiones.
5. Supervisar la desviación de configuración
La desviación es la brecha entre la línea base aprobada y lo que de verdad está corriendo: una regla ampliada durante un incidente, un flag activado para una prueba, un recurso creado fuera del pipeline. La desviación es normal; el problema es la desviación no detectada, porque se acumula hasta que algo la aprovecha. Detectarla significa comparar de forma continua los recursos desplegados contra la línea base de configuración y alertar sobre la diferencia.
6. Remediar y documentar
Cierra la desviación, registra qué se cambió y por qué, y actualiza la línea base si el nuevo estado es el que realmente quieres. Saltarse esa última parte es como los equipos terminan redetectando la misma excepción aceptada cada mes, y como un programa de gestión de configuración pierde la confianza de los ingenieros que atienden sus alertas.
Herramientas de gestión de configuración
Las herramientas de gestión de configuración automatizan la aplicación de un estado deseado. Difieren en cómo llegan ahí, y ninguna juzga si ese estado es seguro.
Herramienta | Modelo | Qué hace |
|---|---|---|
Ansible | Sin agente, playbooks en YAML | Aplica configuraciones por SSH sin instalar agentes |
Puppet | Con agente, declarativa | Aplica un estado declarado en infraestructuras grandes y complejas |
Chef | Con agente, DSL en Ruby | Define configuraciones en código con amplia integración de terceros |
SaltStack | Orientada a eventos, DSL en Python | Maneja despliegues a gran escala con ejecución remota rápida |
CFEngine | Con agente, declarativa | Automatiza la configuración en sistemas heterogéneos |
Terraform, CloudFormation | IaC declarativa | Aprovisiona y versiona infraestructura de nube desde código |
Base de datos de gestión de configuración (CMDB) | Repositorio | Almacena activos, configuraciones y sus relaciones para consulta y auditoría |
La brecha es consistente en toda la categoría: las herramientas de gestión de configuración hacen que un estado sea reproducible, no seguro. Las pruebas de seguridad sobre esas mismas plantillas la cierran.
Qué sale mal sin gestión de configuración
Tres modos de falla explican casi todo lo que vemos cuando la gestión de configuración está ausente o es informal. Las caídas vienen de cambios no controlados, como muestran los 45 minutos que acabaron con Knight Capital. Las fallas de auditoría vienen de la ausencia de registros, no de la ausencia de controles: el trabajo muchas veces se hizo, pero nadie puede probarlo. Y las brechas vienen de parámetros que nunca se revisaron: el segmento de red permisivo, el balanceador de carga con una política por defecto, la instancia RDS alcanzable desde internet. Esos tres son entradas vivas de nuestro catálogo de debilidades porque los seguimos encontrando.
La resolución de problemas también se degrada: sin un estado conocido como bueno, cada incidente empieza por reconstruir cómo se suponía que era el sistema. El costo de saltarse la gestión de configuración rara vez es un solo evento dramático. Es la acumulación de pequeñas decisiones no registradas hasta que nadie puede decir qué es el entorno.
Conclusiones
La gestión de configuración ya no es un asunto de operaciones que seguridad hereda tarde. Los parámetros se mudaron al repositorio, y con ellos las decisiones que determinan el radio de impacto: quién puede asumir qué rol, qué acepta un grupo de seguridad, si el almacenamiento está cifrado. Tratar esos archivos como código, revisados, versionados y escaneados antes de integrarse, es toda la práctica en una frase.
Hay dos números que vale la pena llevarse de esta página. Las herramientas automatizadas encontraron el 88,4 % de las vulnerabilidades que reportamos en 2025, pero solo el 55,8 % del riesgo, y el 87 % de los hallazgos críticos vino de pentesters. Las herramientas te dicen que un parámetro se desvió. Alguien todavía tiene que deducir qué permite esa desviación. Ahí es donde la gestión de configuración deja de ser un ejercicio de inventario y empieza a ser trabajo de seguridad.
Preguntas frecuentes
¿Cuál es la diferencia entre gestión de configuración y gestión de configuración de seguridad?
La gestión de configuración mantiene los sistemas iguales a su estado aprobado; la gestión de configuración de seguridad pregunta si ese estado aprobado es seguro. La primera trata de consistencia y reproducibilidad, la segunda de endurecimiento y exposición. NIST SP 800-128 llama SecCM a la segunda y la trata como una capa sobre la primera. Una infraestructura puede pasar una auditoría de configuración y seguir siendo uniformemente insegura.
¿Qué es la desviación de configuración y cómo se detecta?
La desviación de configuración es la brecha entre la línea base aprobada y lo que de verdad está corriendo. Aparece cuando una regla se amplía durante un incidente, un flag se activa para una prueba o un recurso se crea fuera del pipeline. Detectarla significa comparar de forma continua los recursos desplegados contra la línea base registrada y alertar sobre la diferencia, en vez de depender de que alguien reporte el cambio.
¿Basta la infraestructura como código para mantener seguras las configuraciones?
No. La infraestructura como código hace que una configuración sea reproducible, no segura. Una plantilla con un rol demasiado permisivo o un grupo de seguridad abierto despliega ese fallo de forma idéntica cada vez, con toda fiabilidad. Lo que le aporta a un programa de gestión de configuración es un lugar donde atrapar el problema: la plantilla es un archivo en un repositorio, revisable y escaneable antes de aprovisionar nada.
¿Cuánto riesgo de configuración se les escapa a los escáneres automatizados?
Más de lo que la mayoría de los equipos supone. En el benchmark de Fluid Attacks de 36 herramientas AppSec de terceros contra una aplicación sembrada con 1.201 vulnerabilidades en 105 categorías CWE, un pentester alcanzó un 89,6 % de recall con un 100 % de precisión y cubrió el 86,8 % de la exposición total al riesgo. El mejor escáner automatizado, el nuestro, llegó a un 22,7 % de recall y al 8,8 % de la exposición al riesgo.
¿Fluid Attacks evalúa configuraciones?
Sí, en tres puntos. SAST lee las plantillas de IaC en el repositorio, el cloud security posture management analiza entornos AWS en busca de configuraciones vulnerables, y los pentesters prueban qué habilitan esas configuraciones en la aplicación en ejecución. Los hallazgos se reportan contra nuestros criterios abiertos, incluido el requisito 062 sobre configuraciones estándar, que mapea a CIS Controls, ISO/IEC 27001 y PCI DSS.
Evalúa tus configuraciones antes de que lleguen a producción
Nuestros escáneres leen tus plantillas de infraestructura y nuestros pentesters prueban qué permiten de verdad esos parámetros, para que tu programa de gestión de configuración atrape una configuración incorrecta en la revisión y no en un incidente. El escaneo está en el plan Essential; el pentesting, en Advanced. Prueba gratuita · Contáctanos.
Empieza ya con la solución de ASPM de Fluid Attacks
