Postura de segurança como um sistema observável
Transforme varreduras mensais de segurança na nuvem em métricas dimensionais, sinais de atualidade e um dashboard de triagem útil.
A visibilidade em lote inclui dimensões de risco e a atualidade da varredura; ela não é detecção de ameaças em tempo real.
Contribuição em resumo
- Minha responsabilidade
- Exporter de resultados de segurança, enriquecimento de métricas, construção de dashboards e controles de secrets com escopo definido.
- Escopo
- Visibilidade de varreduras em lote, além de mudanças no scanner e na gestão de secrets validadas separadamente.
- Colaboração & limites
- Eu construí a visibilidade da infraestrutura e controles reversíveis; este trabalho não é uma afirmação de detecção de ameaças em tempo real nem de cobertura completa de vulnerabilidades.
- Resultado
- O risco e a atualidade das varreduras tornaram-se observáveis. Trabalhos relacionados verificaram a alcançabilidade das sondagens e controles reversíveis de versões de secrets dentro dos escopos registrados.
O problema
Relatórios periódicos de segurança na nuvem exigiam triagem manual. Um relatório pontual tornava difícil comparar os achados entre projetos e serviços ou perceber se a varredura subjacente havia ficado desatualizada.
Minha contribuição
Conectei os resultados das varreduras mensais de 14 projetos na nuvem a um pipeline de métricas e a um dashboard do Grafana. O trabalho incluiu enriquecimento de CSV, um pequeno exporter, a implantação de um Pushgateway, a configuração do Prometheus e visualizações de dashboard por projeto, serviço e risco.
As decisões
O scanner é um processo em lote, não um serviço de longa duração. Fazer push dos resultados para um gateway permite que o Prometheus os colete após o encerramento do job. As métricas exportadas distinguem tipos de achado, recursos afetados e o horário da última varredura; esses dados representam perguntas diferentes e não devem ser reduzidos a uma única contagem.
Mantive o exporter sem dependências para que ele pudesse rodar na imagem de scanner existente e preservei os labels necessários para o drill-down por projeto/serviço/risco. O timestamp da varredura é essencial: um dashboard que ainda exibe os resultados do mês anterior não pode dar a impressão de uma varredura recente.
Resultados e medição
O registro de entrega inclui um dry run cobrindo todos os 14 projetos, um push end-to-end bem-sucedido, a confirmação de que o Prometheus armazenou a métrica e um dashboard preenchido com resultados ao vivo.
A cadência das varreduras é mensal. A visibilidade no dashboard entre as execuções não transforma isso em detecção de vulnerabilidades em tempo real. Não se faz aqui nenhuma afirmação sobre uma redução verificada de forma independente de incidentes ou achados de segurança.
Tornar a varredura repetível e útil
Em uma modernização anterior do pipeline, movi as dependências do scanner para uma imagem versionada, paralelizei varreduras e uploads, corrigi o tratamento de saída e reduzi o ruído relacionado a permissões. A execução end-to-end registrada caiu de cerca de 50 minutos para 15 minutos para aquele conjunto de projetos. O rollout posterior do dashboard cobriu 14 projetos; os dois escopos de validação não devem ser combinados em um único benchmark.
Um verificador separado de políticas de bucket foi refatorado com workers limitados, resultados tipados e mensagens de relatório acionáveis. Ele registrou 80 testes unitários e 93,62% de cobertura. Uma saída correta ainda mostrava falhas reais de política; consertar o verificador não significou que todo bucket passou a estar em conformidade.
Provar que o scanner alcançou seus alvos
Consertei um scanner de exposição de configuração para que um host inalcançável não pudesse ser confundido com uma resposta limpa. A execução final registrada recebeu respostas HTTP para 5.681 sondagens em 299 hosts e 19 variantes de caminho, com zero falhas de conexão. Seu runtime foi de cerca de 0,9 minuto, em comparação com cerca de nove minutos anteriormente.
Nenhum arquivo de configuração exposto foi identificado nessa execução. Esse é um resultado para os caminhos e respostas testados, não uma afirmação de que todos os serviços estavam livres de vulnerabilidades.
Levar a mesma disciplina aos secrets
Pilotei o External Secrets Operator com o Secret Manager em três repositórios, incluindo 16 ExternalSecrets e atualizações em 12 aplicações do ArgoCD. Desenvolvimento, staging e sandbox usaram workload identity; o caminho legado de produção manteve uma exceção com chave de service account.
Também alterei um workflow destrutivo de atualização de secrets para preservar os campos existentes. Uma validação em desenvolvimento adicionou um campo mantendo os 183 originais, depois removeu o campo de teste e restaurou a contagem original. Uma normalização posterior desabilitou de forma reversível 133 versões mais antigas em 97 secrets de quatro projetos, mantendo a versão habilitada mais recente em vez de destruir as opções de recuperação.
Esses são controles com escopo definido e registros de validação. Eles não comprovam que toda credencial foi rotacionada, que toda aplicação usou uma identidade dedicada, ou que o Vitor certificou a organização de forma independente.
O que eu aprendi
O relatório de segurança se torna uma capacidade operacional quando suas dimensões, atualidade e responsabilidade estão claras. Apenas uma contagem total não consegue dizer a um time onde agir nem se a fonte ainda está atualizada.
Decisões e próximos passos
Uma visão retrospectiva da abordagem e dos seus limites. A próxima melhoria é uma proposta, não um resultado já entregue.
Alternativa e justificativa
Manter apenas relatórios estáticos é barato, mas torna a atualidade e as tendências difíceis de inspecionar. Métricas exportadas adicionam visibilidade compartilhada e responsabilidade de manutenção.
Trade-off
Dados desatualizados podem parecer tranquilizadores; a alcançabilidade da varredura e os timestamps precisam permanecer separados do número de achados.
O que eu melhoraria a seguir
Próxima melhoria: testar alertas de varredura desatualizada e documentar a responsabilidade pela triagem e a expiração de exceções para cada controle.