Configuração incorreta de segurança: o que é e como detectá-la quando retorna

As equipes fortalecem seus sistemas com base em um padrão, fecham as portas não usadas, ativam o registro e passam na revisão. Depois, um patch redefine uma configuração, um engenheiro abre uma regra de firewall às 2 da manhã para corrigir uma falha e nunca a fecha, e um novo servidor é criado a partir de uma imagem antiga. Alguns meses depois, o ambiente não se parece em nada com o aprovado.

Isso é uma má configuração de segurança. A OWASP classificou isso em quinto lugar em 2021 e em segundo lugar em 2025, e continua subindo porque você pode corrigir todas as vulnerabilidades conhecidas e ainda assim deixar a porta aberta com uma configuração que ninguém lembrou de alterar.

Configuração incorreta de segurança: Uma configuração errada, ausente ou deixada como padrão

A má configuração de segurança é uma vulnerabilidade causada por configurações ausentes, incorretas ou deixadas nos padrões inseguros. O software funciona conforme projetado. A forma como está configurado o expõe.

Uma vulnerabilidade é uma falha no código, e o fornecedor a corrige com um patch. Uma má configuração resulta de uma decisão, ou da falta dela, sobre como um sistema foi implantado ou alterado. A correção é uma mudança nas configurações, e é responsabilidade da sua equipe realizá-la e mantê-la.

Configurações incorretas podem estar em sistemas operacionais, bancos de dados, servidores web, plataformas em nuvem, dispositivos de rede e aplicações. Muitas vezes passam despercebidas porque nada falha e o sistema continua funcionando.

Exemplos de má configuração de segurança em servidores, na nuvem e em dispositivos de rede

Muitos desses casos se resumem a uma única linha em um arquivo de configuração. Veja como a deriva aparece em dois arquivos comuns.

      # /etc/ssh/sshd_config 

 

# Drifted 

PermitRootLogin yes 

PasswordAuthentication yes 

 

# Hardened 

PermitRootLogin no 

PasswordAuthentication no 
      

      # nginx.conf 

 

# Drifted 

autoindex on;        # directory listings exposed 

server_tokens on;    # version number in every response 

 

# Hardened 

autoindex off; 

server_tokens off; 
      

Ambas as versões desviadas funcionam bem, por isso ninguém as percebe. Change Tracker pode monitorar arquivos de configuração como estes e sinalizar o momento em que um valor muda.

A maioria desses problemas é resolvida apenas com uma alteração nas configurações. Encontrá-los em um grande ambiente é a parte lenta.

As configurações incorretas continuam voltando após o endurecimento

Erros de configuração acontecem, assim como mudanças feitas após a configuração. O termo técnico para esse segundo tipo é desvio de configuração: o movimento gradual de um sistema afastando-se de seu estado aprovado e endurecido.

Patches e atualizações alteram configurações como efeito colateral. Correções de emergência são feitas fora do processo normal porque o negócio não pode esperar. Sistemas que deveriam ser idênticos são construídos em momentos diferentes por pessoas diferentes. Quando algo muda, muitas vezes não há um registro claro de quem mudou, quando ou por quê.

Por isso, uma auditoria única não é suficiente. Ela mostra seus sistemas como estavam no dia da verificação, e a deriva pode começar no dia seguinte. Equipes que revisam trimestral ou anualmente sempre trabalham com uma captura de tela já desatualizada.

O que um sistema mal configurado lhe custa

Um sistema mal configurado facilita a entrada de um invasor e gera uma constatação para um auditor. Ambos custam tempo e dinheiro.

Configurações incorretas podem expor dados, ampliar o acesso que um invasor obtém uma vez dentro e tornar uma intrusão mais difícil de detectar porque o registro não foi configurado para capturá-la. Uma configuração ruim também pode causar uma interrupção, e rastrear a causa consome horas quando ninguém sabe o que mudou. Estruturas como PCI DSS, NIST 800-53 e HIPAA esperam que as organizações mantenham padrões seguros de configuração e mostrem evidências de que os sistemas ainda os atendem. Um sistema desviado falha nesse teste mesmo que nada ruim tenha acontecido ainda.

Encontrar e corrigir má configuração de segurança em quatro etapas

1. Comece com um padrão. Você não pode encontrar uma má configuração sem algo para comparar. A maioria das organizações começa com um benchmark do setor, como o CIS Benchmarks ou DISA STIG e o ajusta para seu ambiente. Algumas criam seu próprio padrão a partir de um sistema já fortalecido e confiável.
2. Avalie cada sistema com base nisso. Verifique servidores, bancos de dados, contas na nuvem e dispositivos de rede conforme o padrão e pontue os resultados. Você terá uma lista do que está fora do padrão, classificada pela importância.
3. Corrija o que encontrar. Comece pelo maior risco. Quando uma desvio é intencional, documente-o como uma exceção aprovada para que não volte como um falso alarme.
4. Monitore as alterações. Após a remediação, o ambiente continua mudando. O monitoramento contínuo informa quando um sistema se afasta do seu estado aprovado, para que você corrija uma configuração desviada em horas, em vez de encontrá-la na próxima auditoria.

Detecção sem contexto se transforma em ruído de alerta

Depois que as equipes adicionam monitoramento, os alertas começam a chegar. Cada patch, janela de manutenção e atualização aprovada pode gerar eventos de mudança, e em centenas de dispositivos uma equipe não consegue distinguir as mudanças rotineiras das arriscadas.

Uma alteração em um arquivo de configuração só é um problema se não deveria ter acontecido. Identificar a diferença significa comparar o que mudou com o que foi aprovado.

O controle de mudanças em circuito fechado faz essa comparação. As mudanças aprovadas são registradas como mudanças planejadas, conectando-se ao sistema de gerenciamento de serviços de TI onde os pedidos já existem ou definindo-os diretamente. Quando uma mudança aparece em um sistema, ela é verificada em relação ao plano. Uma correspondência é classificada como planejada e fica fora do caminho. Qualquer outra coisa é sinalizada como não planejada, e essa lista curta é o que a equipe investiga.

Conheça o Netwrix Change Tracker

Netwrix Change Tracker compara sistemas com um padrão conhecido, detecta desvios em tempo real e separa mudanças planejadas das não planejadas.

Para avaliação, o Change Tracker inclui relatórios de conformidade baseados nos CIS Benchmarks, e Netwrix é um fornecedor certificado pela CIS. Os relatórios abrangem Windows, Linux, Unix, bancos de dados, dispositivos de rede, VMware ESXi e plataformas em nuvem como Azure, AWS, GCP e Microsoft 365. Se sua organização possui seu próprio padrão de build, qualquer dispositivo pode servir como fonte base, para que você possa definir um build gold a partir de um sistema confiável e medir os demais com base nele.

Para monitoramento, rastreia arquivos, pastas e conteúdos de arquivos, além de processos, serviços e portas de rede abertas. No Windows, também rastreia configurações do registro, software instalado, contas locais e políticas de segurança e auditoria. A coleta funciona com ou sem agente, o que é importante em ambientes que misturam servidores, appliances e dispositivos onde não é possível instalar software. Cada alteração é registrada com o que mudou e quando, para que você crie um histórico pesquisável para quando algo der errado.

Para controle de mudanças, compara as mudanças detectadas com as planejadas. Integra-se com plataformas ITSM como ServiceNow, BMC Remedy, Cherwell, ManageEngine ServiceDesk Plus e OpenText Service Management, para que solicitações aprovadas se tornem mudanças planejadas automaticamente. Mudanças não planejadas podem gerar um incidente no ServiceNow, que coloca a investigação diante da pessoa que possui o sistema.

Você obtém uma configuração de segurança que pode verificar a qualquer momento e uma resposta clara quando alguém perguntar o que mudou.