DEV Community: Diogo Maske

Segurança em nuvem na prática: o que aprendi sobre misconfiguration com Datadog

Diogo Maske — Mon, 27 Apr 2026 22:57:25 +0000

🇧🇷 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.

Monitorando AWS com Datadog: o que aprendi partindo do zero

Diogo Maske — Thu, 16 Apr 2026 14:07:47 +0000

🇧🇷O artigo está em PT-BR, fique à vontade para traduzir.
🇺🇲The article is in PT-BR, feel free to translate it.

☁️☁️☁️

Acabei de concluir o laboratório Introduction to Monitoring AWS with Datadog e quero compartilhar o que aprendi, porque foi bem mais interessante do que eu esperava. E também porque tive algumas dúvidas que acho que muita gente iniciante também teria.

Antes de começar, vou ser honesto: eu sei o que a AWS soluciona e entrega e tinha uma noção vaga do que era o Datadog ("aquela ferramenta de monitoramento cara"). Mas não entendia como os dois se conectavam na prática, nem por que isso seria importante no dia a dia de um time de DevOps.

O curso usa um app fictício chamado TechStories, uma plataforma de notícias e mídia social hospedada inteiramente na AWS, como base para os exercícios. Isso ajudou muito, porque deu um contexto real pra tudo.

O problema que o curso resolve

Imagine que seu time mantém uma aplicação rodando em EC2, com containers no ECS Fargate, banco de dados no RDS, funções Lambda e tabelas no DynamoDB. Como você sabe se está tudo funcionando bem? Você fica alternando entre console da AWS, CloudWatch, logs espalhados, é muito caótico.

O Datadog entra como uma camada única de observabilidade: você coleta métricas, logs e traces de tudo isso em um só lugar. O lab simulou exatamente esse cenário.

Como a integração AWS funciona por baixo dos panos

A primeira coisa que o curso explica é que existem basicamente dois jeitos de coletar dados da AWS no Datadog:

Via polling do CloudWatch — o Datadog consulta a API da AWS de tempos em tempos pra pegar as métricas. É a forma mais simples de configurar, mas tem um delay de alguns minutos.
Via Metric Streams — você configura a AWS pra empurrar as métricas pro Datadog em tempo quase real. Latência bem menor, ideal pra alertas críticos.

Na prática, pra começar você instala a integração AWS no Datadog, cria uma role IAM na sua conta com as permissões corretas, e aponta o Datadog pra essa role. Depois disso ele já começa a descobrir os recursos automaticamente.

O Datadog Forwarder e o negócio dos logs

Uma das partes que mais me fez parar e reler foi o fluxo de logs. Na AWS, os logs dos serviços gerenciados (Lambda, RDS, etc.) vão pro CloudWatch Logs. Mas o Datadog não lê o CloudWatch Logs diretamente, você precisa de um intermediário.

Esse intermediário é o Datadog Forwarder: uma função Lambda que você instala via CloudFormation e que fica "ouvindo" os CloudWatch Log Groups. Quando chega um log novo, ela encaminha pro Datadog. É bonito quando está pronto, mas exige configurar subscriptions pra cada log group que você quer monitorar.

No lab, depois de configurar isso, consegui ver os logs da Lambda keyword-insights-processor direto no Log Explorer do Datadog, com todos os campos estruturados, tags automáticas de ambiente, serviço, ARN da função, etc. Bem diferente de ficar vasculhando no CloudWatch.

Datadog Agent: quando os serviços gerenciados não são suficientes

Pra EC2 e containers, o Datadog tem o próprio agente, um processo que roda dentro da máquina/container e coleta métricas muito mais granulares do que o CloudWatch oferece: memória por processo, latência de disco, métricas customizadas, traces...

No caso do ECS Fargate, você sobe o Agent como um sidecar container na mesma task definition do seu serviço. Quando vi isso me pareceu muito trabalhoso, mas no lab eles mostram que dá pra fazer via CloudFormation, e as tags ficam todas consistentes por causa de um padrão de key:value definido nos recursos:

App:TechStories / Env:monitoring-aws-lab / Service:<nome-do-serviço>

Isso é fundamental. Sem tags consistentes, você não consegue filtrar nada no Datadog depois.

O que dá pra ver depois que tudo está integrado

O Resource Catalog mostrou tudo que foi descoberto na conta: 343 databases, 70 containers, 22 serverless functions, 1 host EC2... tudo categorizado, com região, ambiente e serviço associado. Dá pra clicar em qualquer recurso e ver as métricas diretamente.

Na seção de Metrics, busquei por aws.dynamodb e apareceram 22 métricas diferentes — capacidade de leitura/escrita, número de itens, tamanho das tabelas. Coisas que antes eu teria que montar dashboards manualmente no CloudWatch.

O AWS Overview Dashboard, que vem pronto como OOTB (out-of-the-box) no Datadog, já trouxe um panorama geral: 1 instância EC2 rodando, 4 monitores de status todos OK, 491 invocações Lambda na última hora, taxa de erro 0%, duração média de 988ms. Também dá pra ver traces das requisições HTTP diretamente no host EC2: cada request com host, serviço, recurso e latência.

O que ficou de lição 🧠

Mais do que as ferramentas em si, o lab reforçou uma coisa: observabilidade não é sobre acumular dados. É sobre ter os dados certos, com contexto suficiente (tags!) pra você conseguir responder perguntas quando algo dá errado.

A integração AWS + Datadog, quando bem configurada, te dá isso: um lugar só pra métricas, logs e traces, com correlação entre eles. Você vê que o tempo de resposta subiu, clica no trace, chega no log do Lambda, entende o que aconteceu.

Ainda tenho muito a aprender (APM, alertas, SLOs...), mas foi uma ótima base. Recomendo o Learning Center do Datadog pra quem quiser começar, os labs são práticos e o ambiente já vem configurado, então você foca no aprendizado em vez de ficar lutando com IAM.

Se quiser trocar ideia sobre isso ou acompanhar minha jornada, me encontra aqui no LinkedIn ✌️