O gerenciamento de configuração é a prática de saber como cada sistema da sua infraestrutura deveria estar e mantê-lo assim. Abrange o inventário de ativos e suas dependências, os parâmetros aprovados com que cada um opera e o processo que governa como esses parâmetros mudam.
Em 1º de agosto de 2012, a Knight Capital implantou código novo de forma incorreta. Nos primeiros 45 minutos de mercado, seu router enviou mais de 4 milhões de ordens para cobrir 212 ordens de clientes. A firma perdeu mais de 460 milhões de dólares e a SEC lhe aplicou depois uma multa de 12 milhões. Não houve atacante. Uma mudança chegou à produção em um estado que ninguém havia aprovado.
Esta página cobre o que é o gerenciamento de configuração, em que ele se diferencia do gerenciamento de mudanças e do gerenciamento de configuração de segurança, os seis passos do ciclo, as ferramentas que o automatizam e o que nossos dados de 2025 dizem sobre onde as falhas de configuração realmente aparecem.
O que é gerenciamento de configuração?
O gerenciamento de configuração é um processo de TI que rastreia, controla e documenta as mudanças na configuração, nos recursos e nos serviços de um sistema. Registra cada componente, parâmetro e dependência, e como eles se relacionam. Um bom gerenciamento de configuração responde a uma só pergunta a qualquer momento: este sistema está executando o que aprovamos?
A disciplina é mais antiga que o software. O Departamento de Defesa dos Estados Unidos a formalizou para sistemas militares em sua série 480 de padrões, o controle de versões a trouxe ao desenvolvimento de software, e o DevOps a tornou prática diária quando as equipes passaram a implantar infraestrutura com a mesma frequência que o código.
A segurança acrescenta uma segunda camada. O NIST a chama de gerenciamento de configuração focado em segurança, ou SecCM, e define seu objetivo como gerenciar e monitorar as configurações dos sistemas para “alcançar segurança adequada e minimizar o risco organizacional sem deixar de apoiar a funcionalidade de negócio desejada” (NIST SP 800-128, atualizado em 2019). Vale a pena manter a distinção: o gerenciamento de configuração comum pergunta se um sistema corresponde ao seu estado aprovado, enquanto o gerenciamento de configuração focado em segurança pergunta se esse estado aprovado é seguro em primeiro lugar. Um parque de sistemas pode ser perfeitamente consistente e uniformemente inseguro.
Por que o gerenciamento de configuração é importante?
O gerenciamento de configuração importa porque os parâmetros hoje carregam tanto risco quanto o código. Uma permissão, uma regra de firewall ou uma política de armazenamento decidem até onde um atacante chega depois de entrar, e essas decisões vivem em arquivos que mudam muito mais vezes que a lógica da aplicação. Foi isso que transformou o gerenciamento de configuração de um assunto de operações em um controle de segurança.
A configuração insegura já é a segunda classe de fraqueza mais comum
A análise da Fluid Attacks sobre o OWASP Top 10 2025 encontrou que a configuração insegura subiu do quinto lugar em 2021 para o segundo em 2025, e que hoje abrange 16 CWE e está presente em 3 % das aplicações avaliadas. No mesmo período, mais comportamento das aplicações saiu do código compilado para arquivos de configuração, permissões de nuvem e modelos de infraestrutura.
A maioria das falhas de configuração é barata, e algumas poucas não
Das 1.119.396 vulnerabilidades que reportamos nos sistemas dos nossos clientes em 2025, a configuração insegura de serviços no EC2 sozinha respondeu por 44.667 achados com 149.840,91 unidades CVSSF de exposição ao risco (State of Attacks 2026). O acesso não autorizado a arquivos em serviços de armazenamento em nuvem somou 13.499 achados e 500.832,48 CVSSF.
Depois vem o outro tipo. A informação confidencial não criptografada no Azure apareceu em apenas 4,8 % dos sistemas e 1.789 achados, mas carregou 809.671,94 CVSSF: mais risco que os achados de EC2 e armazenamento somados, a partir de 3 % do volume deles. Volume e risco não são a mesma coisa, e um programa de gerenciamento de configuração que trate cada desvio como igualmente urgente vai gastar seu tempo nos errados.
É o que torna um ambiente reproduzível
Sem um estado desejado registrado, nenhum ambiente se reconstrói com confiança, nenhum incidente se rastreia até a mudança que o causou e a nenhum auditor se pode mostrar como o sistema estava no trimestre passado. A reprodutibilidade é o benefício silencioso do gerenciamento de configuração, percebido só quando já não existe.
Uma equipe com um estado desejado versionado restaura a partir dele; uma sem ele reconstrói de memória.
Gerenciamento de configuração, gerenciamento de mudanças e gerenciamento de configuração de segurança não são a mesma coisa
Os três termos se sobrepõem e são trocados com frequência. Respondem a perguntas diferentes, e confundi-los é como uma equipe termina com um registro de mudanças impecável sobre uma infraestrutura insegura.
Prática | Pergunta que responde | O que controla | O que falha sem ela |
|---|---|---|---|
Gerenciamento de configuração | Como este sistema deveria estar, e está? | Inventário, dependências, parâmetros aprovados, desvio | Os ambientes deixam de ser reproduzíveis; os incidentes não se rastreiam |
Controle de mudanças | Quem aprovou esta mudança, e quando? | A solicitação, a revisão, a aprovação e o caminho de reversão | Mudanças sem revisão chegam à produção, como na Knight Capital |
Gerenciamento de configuração de segurança | O estado aprovado é seguro em si mesmo? | Linhas de base endurecidas, menor privilégio, criptografia | A infraestrutura fica consistente e uniformemente exposta |
Uma regra prática: o controle de mudanças diz que um parâmetro se moveu, o gerenciamento de configuração diz de onde e para onde ele se moveu, e só o gerenciamento de configuração de segurança diz se o destino era aonde você queria chegar.
Gerenciamento de configuração na Fluid Attacks
Não vendemos uma plataforma de gerenciamento de configuração. Avaliamos as configurações que uma plataforma dessas produz: nos modelos antes de serem implantados, na conta de nuvem depois disso e na aplicação em execução, com DAST e testes manuais, onde aparecem suas consequências. Nosso papel dentro de um programa de gerenciamento de configuração é restrito: dizemos quais parâmetros aprovados não são seguros.
O que avaliamos, e sob quais regras
Cada avaliação corre contra um escopo definido e um critério escrito. Para os achados de gerenciamento de configuração, o requisito que governa é o número 062 do nosso catálogo aberto, que estabelece que “o sistema deve seguir as configurações padrão da indústria que previnem todas as vulnerabilidades conhecidas”. Esse requisito mapeia para os CIS Controls 4.1 e 4.2, para o controle 8.9 da ISO/IEC 27001, para o PCI DSS 2.2.6 e para o NIST SP 800-171 3.4.2, de modo que um achado contra ele já vem expresso na linguagem que um auditor usa.
Como isso se vê na prática
Onde a configuração vive | Como a avaliamos | Critérios de exemplo |
|---|---|---|
IaC e arquivos de configuração: Terraform, CloudFormation, Kubernetes, Helm, Docker Compose, ARM | SAST sobre o repositório | Terraform excessive attach privileges; Terraform publicly accessible true |
A conta AWS implantada | AWS permissive role policies; AWS admin policy attached; AWS unrestricted security groups | |
Identidades e funções, onde quer que sejam definidas | SAST, CSPM e revisão manual | Excessive privileges - AWS: “a aplicação, um usuário ou uma função têm mais privilégios do que precisam” |
O que a configuração habilita em produção | PTaaS e testes manuais | Unrestricted access between network segments - AWS; Insecure service configuration - ELB; Improper authorization control for web services - RDS |
A mudança, antes de ser integrada | CI Gate no pipeline | Política sobre achados não remediados conforme a severidade |
Nosso requisito 062 e os controles para os quais ele mapeia, conforme publicados em nosso catálogo aberto de critérios.
O que os testes manuais encontram e os escâneres não
Um escâner lê um parâmetro. Um pentester deduz o que esse parâmetro permite fazer. A distância entre as duas coisas aparece com clareza nos nossos próprios números.
Medida | Ferramentas automatizadas | Pentesters |
|---|---|---|
Percentual de vulnerabilidades reportadas em 2025 | 88,4 % | 11,6 % |
Percentual de exposição ao risco reportada em 2025 | 55,8 % | 44,2 % |
Percentual de vulnerabilidades críticas | 13 % | 87 % |
Exposição média ao risco por achado (CVSSF) | 15,5 | 93,2 |
As ferramentas automatizadas reportam mais achados; os pentesters reportam mais risco. Fonte: State of Attacks 2026.
A mesma divisão aparece em condições controladas. No benchmark da Fluid Attacks de 36 ferramentas AppSec de terceiros contra uma aplicação semeada com 1.201 vulnerabilidades em 105 categorias CWE, um pentester alcançou 89,6 % de recall com 100 % de precisão, e cobriu 86,8 % da exposição total ao risco. O escâner automatizado de melhor desempenho foi o nosso, com 99 % de precisão mas 22,7 % de recall e 8,8 % da exposição ao risco. Essas avaliações manuais são executadas por profissionais de segurança ofensiva certificados.
O que nosso CSPM cobre
Nosso escâner de cloud security posture management analisa ambientes AWS em busca de configurações vulneráveis. É um escopo deliberado, e vale a pena dizê-lo sem rodeios em vez de insinuar uma cobertura mais ampla.
Também não é de onde sai cada achado de configuração na nuvem. A fraqueza de configuração mais cara nos nossos dados de 2025, a informação confidencial não criptografada com 809.671,94 CVSSF, estava no Azure. As configurações de Azure e GCP chegam até nós pelos modelos de IaC que o SAST lê e pelo pentesting manual, e por isso os modelos do seu repositório importam tanto quanto a conta em que eles são implantados. Para a maioria das equipes, a cobertura de gerenciamento de configuração começa no repositório e não no console.
Revise os pull requests de infraestrutura como código de pagamentos
A prática que decide quão bem o resto funciona é simples e quase sempre é pulada. Nossa revisão do incidente da Binance de 2026 coloca o ponto de forma direta: quando um repositório define infraestrutura em Terraform, manifestos de Kubernetes ou arquivos de Docker Compose, uma falha de configuração é uma falha de código, e um pull request que muda um role binding ou uma regra de firewall merece a mesma revisão que uma mudança na lógica de pagamentos.
Os dados sustentam o hábito. Entre os sistemas que avaliamos em 2025, os que rodavam nosso CI Gate no pipeline alcançaram uma taxa de remediação de 72,2 % contra 58 % sem ele, e uma mediana de remediação de 22 dias contra 30: 26,7 % mais rápido. Colocar o portão no pipeline é o que torna o gerenciamento de configuração exigível, e não apenas recomendado.
Como funciona o gerenciamento de configuração
O gerenciamento de configuração opera como um ciclo de seis passos, não como um projeto com data de término. Cada passo produz um artefato do qual o seguinte depende.
1. Identificar os ativos
Inventarie cada sistema, serviço, dependência e responsável. Um ativo que ninguém possui é um ativo que ninguém corrige. Muitas equipes guardam esse inventário em um banco de dados de gerenciamento de configuração, que armazena esses componentes e suas relações.
2. Definir linhas de base seguras
Uma linha de base de configuração é o estado aprovado: os parâmetros com que se espera que um sistema opere, escritos e versionados. O CIS Control 4 (Controls v8.1) pede às organizações que “estabeleçam e mantenham a configuração segura dos ativos empresariais” (equipamentos de usuário, dispositivos de rede, IoT e servidores) “e do software”. Os valores padrão dos fabricantes são pensados para a instalação, não para a segurança, então a linha de base é onde o endurecimento se especifica, não se presume. O que a Fluid Attacks escreveu sobre produtos seguros por padrão sustenta que os fabricantes deveriam entregar configurações suficientemente seguras para que os clientes não fiquem fazendo esse trabalho sozinhos.
3. Controlar as mudanças
Todo desvio da linha de base passa por revisão, aprovação e um caminho de reversão registrado. As permissões merecem a versão mais estrita disso. O princípio de menor privilégio é o único parâmetro da linha de base que limita o dano de qualquer outro erro, e nosso analista de segurança Jonathan Armas expôs sem rodeios o custo de ignorá-lo em 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?”
(Uma porta aberta é uma janela para a sua infraestrutura que amplia a superfície de ataque que nós, pentesters, podemos explorar; então por que abri-la ao mundo?)
No mesmo artigo ele observa que a maioria das chaves AWS que comprometeu estava configurada com permissões excessivas.
4. Automatizar com infraestrutura como código
Terraform e AWS CloudFormation permitem escrever as definições de infraestrutura como código, guardá-las em um repositório e implantá-las por meio de um pipeline. Isso transforma uma configuração em um artefato revisável, versionado e reproduzível, e em algo que um escâner pode ler antes que chegue a uma conta de nuvem. Aqui também é onde o DevSecOps prova seu valor: o que escrevemos sobre proteger as implantações em nuvem identifica a configuração incorreta de serviços de nuvem como uma das principais causas de desastre, e defende detectá-la em arquivos de IaC e imagens de contêiner, não em produção. Implementar DevSecOps é mais fácil de começar por aqui, porque os artefatos já estão em controle de versões.
5. Monitorar o desvio de configuração
O desvio é a distância entre a linha de base aprovada e o que de fato está rodando: uma regra ampliada durante um incidente, um flag ativado para um teste, um recurso criado fora do pipeline. O desvio é normal; o problema é o desvio não detectado, porque ele se acumula até que algo o aproveite. Detectá-lo significa comparar continuamente os recursos implantados com a linha de base de configuração e alertar sobre a diferença.
6. Remediar e documentar
Feche o desvio, registre o que foi mudado e por quê, e atualize a linha de base se o novo estado for o que você realmente quer. Pular essa última parte é como as equipes terminam redetectando a mesma exceção aceita todo mês, e como um programa de gerenciamento de configuração perde a confiança dos engenheiros que atendem seus alertas.
Ferramentas de gerenciamento de configuração
As ferramentas de gerenciamento de configuração automatizam a aplicação de um estado desejado. Diferem em como chegam lá, e nenhuma julga se esse estado é seguro.
Ferramenta | Modelo | O que faz |
|---|---|---|
Ansible | Sem agente, playbooks em YAML | Aplica configurações por SSH sem instalar agentes |
Puppet | Com agente, declarativa | Aplica um estado declarado em infraestruturas grandes e complexas |
Chef | Com agente, DSL em Ruby | Define configurações em código com ampla integração de terceiros |
SaltStack | Orientada a eventos, DSL em Python | Lida com implantações em grande escala com execução remota rápida |
CFEngine | Com agente, declarativa | Automatiza a configuração em sistemas heterogêneos |
Terraform, CloudFormation | IaC declarativa | Provisiona e versiona infraestrutura de nuvem a partir de código |
Banco de dados de gerenciamento de configuração (CMDB) | Repositório | Armazena ativos, configurações e suas relações para consulta e auditoria |
A lacuna é consistente em toda a categoria: as ferramentas de gerenciamento de configuração tornam um estado reproduzível, não seguro. Os testes de segurança sobre esses mesmos modelos a fecham.
O que dá errado sem gerenciamento de configuração
Três modos de falha explicam quase tudo o que vemos quando o gerenciamento de configuração está ausente ou é informal. As quedas vêm de mudanças não controladas, como mostram os 45 minutos que acabaram com a Knight Capital. As falhas de auditoria vêm da ausência de registros, não da ausência de controles: o trabalho muitas vezes foi feito, mas ninguém consegue provar. E as violações vêm de parâmetros que nunca foram revisados: o segmento de rede permissivo, o balanceador de carga com uma política padrão, a instância RDS alcançável pela internet. Esses três são entradas vivas do nosso catálogo de fraquezas porque continuamos encontrando-os.
A resolução de problemas também se degrada: sem um estado conhecido como bom, cada incidente começa reconstruindo como o sistema deveria estar. O custo de pular o gerenciamento de configuração raramente é um único evento dramático. É o acúmulo de pequenas decisões não registradas até que ninguém consiga dizer o que o ambiente é.
Conclusões
O gerenciamento de configuração já não é um assunto de operações que a segurança herda tarde. Os parâmetros se mudaram para o repositório, e com eles as decisões que determinam o raio de impacto: quem pode assumir qual função, o que um grupo de segurança aceita, se o armazenamento está criptografado. Tratar esses arquivos como código, revisados, versionados e escaneados antes da integração, é toda a prática em uma frase.
Há dois números que vale a pena levar desta página. As ferramentas automatizadas encontraram 88,4 % das vulnerabilidades que reportamos em 2025, mas só 55,8 % do risco, e 87 % dos achados críticos vieram de pentesters. As ferramentas dizem que um parâmetro se desviou. Alguém ainda precisa deduzir o que esse desvio permite. É aí que o gerenciamento de configuração deixa de ser um exercício de inventário e passa a ser trabalho de segurança.
Perguntas frequentes
Qual é a diferença entre gerenciamento de configuração e gerenciamento de configuração de segurança?
O gerenciamento de configuração mantém os sistemas iguais ao seu estado aprovado; o gerenciamento de configuração de segurança pergunta se esse estado aprovado é seguro. O primeiro trata de consistência e reprodutibilidade, o segundo de endurecimento e exposição. O NIST SP 800-128 chama o segundo de SecCM e o trata como uma camada sobre o primeiro. Uma infraestrutura pode passar em uma auditoria de configuração e continuar uniformemente insegura.
O que é desvio de configuração e como detectá-lo?
O desvio de configuração é a distância entre a linha de base aprovada e o que de fato está rodando. Ele aparece quando uma regra é ampliada durante um incidente, um flag é ativado para um teste ou um recurso é criado fora do pipeline. Detectá-lo significa comparar continuamente os recursos implantados com a linha de base registrada e alertar sobre a diferença, em vez de depender de alguém reportar a mudança.
A infraestrutura como código basta para manter as configurações seguras?
Não. A infraestrutura como código torna uma configuração reproduzível, não segura. Um modelo com uma função permissiva demais ou um grupo de segurança aberto implanta essa falha de forma idêntica toda vez, com toda a confiabilidade. O que ela acrescenta a um programa de gerenciamento de configuração é um lugar para pegar o problema: o modelo é um arquivo em um repositório, revisável e escaneável antes de provisionar qualquer coisa.
Quanto risco de configuração escapa dos escâneres automatizados?
Mais do que a maioria das equipes supõe. No benchmark da Fluid Attacks de 36 ferramentas AppSec de terceiros contra uma aplicação semeada com 1.201 vulnerabilidades em 105 categorias CWE, um pentester alcançou 89,6 % de recall com 100 % de precisão e cobriu 86,8 % da exposição total ao risco. O melhor escâner automatizado, o nosso, chegou a 22,7 % de recall e a 8,8 % da exposição ao risco.
A Fluid Attacks avalia configurações?
Sim, em três pontos. O SAST lê os modelos de IaC no repositório, o cloud security posture management analisa ambientes AWS em busca de configurações vulneráveis, e os pentesters testam o que essas configurações habilitam na aplicação em execução. Os achados são reportados contra nossos critérios abertos, incluindo o requisito 062 sobre configurações padrão, que mapeia para CIS Controls, ISO/IEC 27001 e PCI DSS.
Avalie suas configurações antes que elas cheguem à produção
Nossos escâneres leem seus modelos de infraestrutura e nossos pentesters testam o que esses parâmetros de fato permitem, para que seu programa de gerenciamento de configuração pegue uma configuração incorreta na revisão e não em um incidente. A varredura está no plano Essential; o pentesting, no Advanced. Teste gratuito · Fale conosco.
Comece a usar a solução ASPM da Fluid Attacks agora mesmo
