🇧🇷 O artigo está em PT-BR, fique à vontade para traduzir.
🇺🇲 The article is in PT-BR, feel free to translate it.
☁️☁️☁️
Acabei de terminar o lab Find and Remediate Vulnerable Cloud Resources with Cloud Security Misconfigurations do Datadog Learning Center. E dessa vez o assunto foi segurança, um tema que eu sempre achei meio abstrato até colocar a mão na massa.
Antes de começar, quero deixar claro que não sou especialista em segurança. Então esse curso foi um dos meus primeiros contatos reais com o lado de Cloud Security. Vou contar o que entendi, com a cabeça de quem estava aprendendo do zero.
O problema que o curso apresenta
Imagine que sua empresa roda centenas de recursos na AWS, buckets S3, instâncias EC2, funções Lambda, roles IAM, políticas de rede... Como você garante que todos estão configurados corretamente do ponto de vista de segurança?
A resposta honesta é: manualmente você não garante. É inviável. Uma role IAM com permissões a mais, um bucket S3 com acesso público habilitado, cada um desses parece pequeno isoladamente, mas qualquer um pode ser o ponto de entrada de um ataque.
O lab usou um app fictício com arquitetura multi-cloud (parte na AWS, parte no Google Cloud) justamente pra simular esse cenário caótico de verdade. Tinha bucket de imagens, pipeline de CI/CD, DynamoDB com backup... uma bagunça organizada, como é na vida real.
O que é uma misconfiguration, afinal?
Uma misconfiguration é basicamente uma configuração que está tecnicamente funcionando, mas que abre uma brecha de segurança. Não é um bug no código, é uma escolha de configuração errada ou esquecida.
Alguns exemplos que apareceram no lab:
- Um bucket S3 sem versionamento habilitado. Isso significa que se alguém apagar ou sobrescrever um arquivo por acidente — ou de propósito — não tem como recuperar.
- Uma policy IAM no GCP que permitia acesso anônimo a um bucket de storage. Qualquer pessoa na internet poderia acessar o conteúdo sem autenticação.
- MFA não habilitado na conta root da AWS. A conta com mais permissões de todas, sem segunda camada de autenticação.
Cada um desses tem severidade diferente. O bucket público era HIGH. O S3 sem versionamento era LOW. E o Datadog já vem com centenas de regras prontas pra detectar esses casos automaticamente, sem você precisar escrever nada.
Como o Datadog organiza tudo isso
A primeira coisa que me chamou atenção foi o dashboard de Misconfigurations. Num único lugar você vê: 364 recursos escaneados, 169 com alguma misconfiguration, 6 com severidade Critical ou High. Tem até um treemap mostrando a distribuição por tipo de recurso, dava pra ver de cara que aws_kms_alias tinha 137 ocorrências e aws_iam_role tinha 52.
Em vez de ficar caçando problema por problema, você tem uma visão de inventário: onde estão os riscos maiores, quais recursos são novos, o que mudou no último mês.
O Misconfigurations Explorer é onde você investiga cada item. Você filtra por severidade, cloud provider, tipo de recurso, status de triage. Quando abre uma misconfiguration específica, ela mostra: o que aconteceu, desde quando está falhando, em qual recurso exatamente, e o que eu achei mais útil, um botão de Remediation Steps com o passo a passo pra corrigir.
Tem ainda o Security Inbox, que funciona como uma fila priorizada das coisas mais urgentes pra resolver. Pensa como um backlog de segurança, onde o Datadog já fez a triagem inicial pra você. Bizarro haha
Detection Rules: onde mora a inteligência
Por baixo de tudo isso estão as Detection Rules,as regras que definem o que é considerado uma misconfiguration. O Datadog já vem com mais de 1.000 regras prontas, mantidas pela equipe deles. No lab, explorei as regras específicas pra S3 e vi que tinha desde uma regra CRITICAL ("bucket S3 publicamente acessível com dados sensíveis") até regras HIGH cobrindo wildcard principals, acesso entre contas, escrita pública.
O interessante é que você também pode criar regras customizadas. Se sua empresa tem uma política interna específica, tipo "todo bucket de produção precisa ter tag de owner" você pode escrever isso como uma regra e o Datadog passa a monitorar automaticamente.
O que ficou de lição
Segurança em nuvem sempre pareceu pra mim uma área separada, de especialistas. Depois desse lab, minha visão mudou um pouco. Não porque ficou fácil, mas porque ficou mais concreto.
Misconfiguration não é um problema abstrato. É o acúmulo de pequenas decisões que, juntas, criam uma oportunidade de ataque real.
O que o Datadog faz é tornar esse acúmulo visível e dar um caminho claro pra resolver. Pra quem está começando na área de DevOps ou SRE, entender que segurança também é responsabilidade do time de infraestrutura (e não só do time de segurança) foi a maior virada de chave desse lab.
