Por que falar de GuardDuty ETD agora Segurança em nuvem não é só “alerta na tela”. O que separa maturidade de tentativa é entender o encadeamento de eventos e responder automaticamente. O Amazon GuardDuty Extended Threat Detection (ETD) correlaciona múltiplos sinais (APIs, logs, achados) para identificar sequências de ataque (attack sequences) e gerar um finding único e crítico que representa a história completa do ataque. O que é o ETD, em 30 segundos Detecta ataques multiestágio (ex.: credenciais comprometidas → mudança de políticas → exfiltração S3). Correlaciona sinais entre fontes fundamentais (CloudTrail, VPC Flow Logs, DNS) e planos de proteção (S3, EKS, Runtime), quando habilitados. Gera achados “AttackSequence:*” (ex.: AttackSequence:S3/CompromisedData, AttackSequence:IAM/CompromisedCredentials, AttackSequence:EKS/CompromisedCluster) todos com criticidade “Critical”. Importante: ao habilitar o GuardDuty em uma Região, o ETD já vem habilitado por padrão e sem custo adicional; habilitar S3/EKS/Runtime amplia a cobertura ao adicionar mais sinais. ...

Neste post, vamos abordar: 📜 Policies-as-Code com CloudFormation Guard e Open Policy Agent 🔍 SAST com Amazon Inspector Code e ferramentas externas 👀 Observabilidade com CloudWatch, X-Ray e integração com Security Hub 🛠️ Exemplos de fluxo prático para aplicar esses conceitos 1. Policies-as-Code: segurança como código Definir políticas de segurança como código é um pilar do DevSecOps moderno. Isso garante que: Todo recurso criado esteja conforme os padrões definidos A validação ocorra antes do deploy Possamos versionar e auditar as regras aplicadas Ferramentas comuns: AWS Config + Config Rules – Audita automaticamente o estado da infraestrutura. CloudFormation Guard – Valida templates CloudFormation antes de aplicar. OPA (Open Policy Agent) – Permite aplicar políticas a múltiplas fontes (Terraform, Kubernetes, etc.). Terraform Sentinel – Para quem usa Terraform Enterprise. Exemplo prático: validando que buckets S3 devem estar com blockPublicAccess habilitado com Cfn-Guard [rule.s3_block_public_access] let bucket = Resources.*[ Type == "AWS::S3::Bucket" ] bucket.Properties.PublicAccessBlockConfiguration.BlockPublicAcls == true bucket.Properties.PublicAccessBlockConfiguration.BlockPublicPolicy == true 2. SAST: detecção de vulnerabilidades no código-fonte O que é SAST? SAST (Static Application Security Testing) analisa o código sem executar a aplicação, em busca de padrões inseguros, credenciais hardcoded, uso de libs vulneráveis e outras falhas. ...

O que é análise de código (SAST)? Quando falamos em SAST (Static Application Security Testing), estamos falando de análise de código sem execução. Ou seja, ele lê seu código e aponta potenciais falhas como: Uso de funções ou bibliotecas com CVEs conhecidas. Falta de validação de entrada (o clássico caminho para injeção SQL/XSS). Exposição de dados sensíveis como senhas hardcoded. Más práticas de autenticação/autorização. Má configuração de infraestrutura como código (IAM Policies mal feitas, buckets S3 públicos, etc.). O que o Amazon Inspector faz de diferente? Antes ele já era conhecido por escanear EC2, containers, Lambda, mas agora ele entra no começo do ciclo de desenvolvimento. ...

(ex.: “Rules File Backdoor”, que afeta Copilot/Cursor) Ferramentas de geração assistida de código — Copilot, Cursor, Amazon Q, agentes LLM customizados, etc. — aumentam a produtividade, mas introduzem uma nova superfície de ataque: o próprio agente pode ser “conduzido” para inserir backdoors ou executar comandos indesejados. Em março de 2025, pesquisadores mostraram o Rules File Backdoor: bastou um arquivo “.rules” (com caracteres Unicode invisíveis) no repositório para induzir Copilot/Cursor a gerar código malicioso e, em certos IDEs, até executá-lo automaticamente. ...

1. Entendendo o Risco de Ransomware em Ambientes AWS Muitas empresas consideram a nuvem mais segura do que o data center tradicional, mas ela não é 100% segura. Há alguns cenários que tornam a AWS suscetível a ataques de ransomware: Instâncias EC2 executando sistemas operacionais ou aplicativos vulneráveis (por exemplo, sem patch). Credenciais IAM comprometidas que podem permitir a exclusão ou criptografia de dados em buckets S3, EBS volumes e bancos de dados. Falta de backups imutáveis ou replicados — se o criminoso conseguir criptografar ou excluir backups, a restauração torna-se inviável. 2. Prevenção e Redução de Superfície de Ataque 2.1 Atualização e Correção de Sistemas Patching regular: Mantenha instâncias EC2, containers e sistemas de banco de dados atualizados. AWS Systems Manager Patch Manager: Automatize a distribuição de patches em instâncias Windows e Linux. Segurança de imagens: Use scanners de vulnerabilidade em containers (Trivy, Amazon Inspector para ECR etc.) e aplique correções antes de implantar em produção. 2.2 Proteção de Credenciais e Princípio do Menor Privilégio Evite o uso do root account em operações diárias. Habilite MFA para essa conta e mantenha as credenciais em local seguro. IAM Roles em vez de chaves de acesso estáticas. Roles definem permissões e evitam exposição indevida de credenciais. Menor privilégio (least privilege): Conceda a cada usuário, serviço ou sistema apenas as permissões necessárias para executar suas tarefas. 2.3 Isolamento de Rede Security Groups e Network ACLs: Restringir acesso nas portas e protocolos estritamente necessários. VPC Segregadas: Mantenha workloads críticos em subnets privadas, conectadas a subnets públicas via Load Balancers ou NAT Gateways. Inspeção de tráfego: Ferramentas como IDS/IPS (Suricata, Snort), com VPC Traffic Mirroring, podem ajudar a detectar comportamentos suspeitos (movimento lateral ou criptografia anormal). 2.4 Políticas de Backup e Armazenamento Imutável Amazon S3 Object Lock: Configurar modo “Compliance” para que nem mesmo o administrador possa excluir ou sobrescrever objetos antes do fim do período de retenção. Versionamento em buckets S3: Se um objeto for alterado ou removido, há uma versão anterior para recuperação. Backups fora da conta principal: Tenha um processo que replique dados críticos para outra conta ou região da AWS, reduzindo o risco de o invasor comprometer todos os ambientes. AWS Backup: Serviço gerenciado para orquestrar e automatizar backups de vários serviços (EBS, RDS, DynamoDB etc.) com gerenciamento de retenção e cópias entre regiões/contas. 3. Detecção e Monitoramento Contínuos 3.1 Logs e Auditoria AWS CloudTrail: Registra ações de API em toda a conta (criação de instâncias, alterações em IAM, exclusões de snapshots etc.). CloudTrail Data Events em S3, EFS e Lambda para detectar padrões de exfiltração ou modificações súbitas. VPC Flow Logs: Acompanhe tráfego de rede para identificar conexões suspeitas. Amazon CloudWatch e AWS Config: Alerte sobre alterações repentinas em configurações críticas, como políticas de bucket ou segurança de instâncias. 3.2 Amazon GuardDuty Monitora atividades maliciosas ou comportamentos anormais em nível de conta e rede, apontando possíveis ataques. Pode detectar varreduras de porta, conexões de IPs maliciosos, acessos suspeitos a buckets S3, entre outros. 3.3 AWS Security Hub Centraliza findings do GuardDuty, Inspector, Macie e ferramentas de parceiros. Permite criar regras de automação via Amazon EventBridge para resposta imediata (por exemplo, isolar instância comprometida). 3.4 Ferramentas Adicionais Amazon Macie: Identifica e classifica dados confidenciais (PII, cartões de crédito, etc.), ajudando a priorizar a proteção de repositórios críticos. SIEM Externo: Soluções como Splunk, Datadog ou ELK Stack para correlacionar e aprofundar análises de logs em larga escala. 4. Resposta Rápida e Estrutura de Remediação 4.1 Planos de Incidente Playbooks de Resposta: Documente o passo a passo ao detectar uma intrusão (contatar o time X, bloquear via security group, snapshots de evidências etc.). Testes Regulares (Game Days): Simule ataques de ransomware ou falhas, testando a eficácia dos planos de resposta e a restauração de backups. 4.2 Automação de Resposta Lambda & EventBridge: Ao detectar um evento crítico (p. ex. remoção de snapshots ou grande volume de objetos S3 being deleted/overwritten), desencadeie scripts que: Revoguem temporariamente permissões IAM suspeitas. Criem snapshots de volumes EBS para análise forense. Notifiquem via Slack, e-mail ou SMS os times responsáveis. AWS Systems Manager Incident Manager: Coordena a resposta a incidentes, gerenciando alertas, registros de eventos e procedimentos. 4.3 Isolamento e Recuperação Instâncias Infectadas: Desconecte a instância infectada ou suspeita da rede, mantendo um snapshot para análise posterior. Restaurar de Backups: Se houver a criptografia de volumes ou exclusão de dados, restaure rapidamente dos backups (ou “point-in-time recovery” em RDS ou DynamoDB). Verificação e Reforço: Após restaurar, verifique integridade dos dados e corrija a falha original de segurança. 5. Boas Práticas Finais MFA Everywhere: Use Multi-Factor Authentication para contas IAM, usuários e principalmente para as contas root. Revisão de Acesso: Periodicamente revogue permissões ociosas e rotacione credenciais. Segmentação de Ambientes: Separe contas para produção, desenvolvimento e teste, reduzindo o impacto se algum ambiente for comprometido. Testes de Desastre: Execute “drills” de restauração para garantir que backups realmente funcionem no tempo esperado. Cultura de Segurança: Treine as equipes sobre phishing, engenharia social e práticas seguras de manipulação de dados. Conclusão Ataques de ransomware podem impactar seriamente a disponibilidade e integridade dos dados, gerando prejuízos financeiros e danos à reputação. Mitigar esses ataques na AWS requer um ecossistema de boas práticas: desde a implementação de um modelo robusto de IAM e backups imutáveis, até a detecção em tempo real de atividades suspeitas e uma resposta automática e estruturada. ...

Nesse post estarei utilizando apenas serviços AWS, em um próximo vou falar sobre ferramentas OpenSource que podem apoiar também. 1. Entendendo o risco de exfiltration no S3 Uma exfiltration de consiste em extrair ou transferir informações de forma não autorizada para fora da organização. Falando de S3, isso pode ocorrer se: Há permissões excessivas em bucket policies ou ACLs, permitindo acesso público ou de usuários mal-intencionados. Não há monitoramento e logs de atividades, dificultando a detecção de downloads ou cópias suspeitas de dados. Falta de criptografia e mecanismos de auditoria, tornando mais fácil para um atacante ler e exportar dados sensíveis. 2. Acesso mínimo e governança de identidades Princípio do Menor Privilégio (Least Privilege) ...

1. Visão Geral do Amazon Inspector 1.1 O que é e para que serve? O Amazon Inspector automatiza análises de segurança em recursos computacionais (EC2, ECR, Lambda) para identificar vulnerabilidades e configurações inseguras. Cria achados (findings) que detalham o tipo de vulnerabilidade (por exemplo, CVEs conhecidas, pacotes desatualizados, problemas de configuração) e a severidade (Crítico, Alto, Médio, etc.). Centraliza relatórios para priorização, correção e acompanhamento, permitindo que as equipes respondam rapidamente a ameaças. 1.2 Diferença entre o Amazon Inspector e outras ferramentas Amazon Inspector x GuardDuty ...

1. Visão Geral do AWS IAM Identity Center 1.1 O que é? O IAM Identity Center é um serviço gerenciado da AWS que permite: Single Sign-On (SSO): Usuários fazem login por um único portal e têm acesso a múltiplas contas e aplicações (AWS e SaaS). Gerenciamento Centralizado de Identidades: Criação e gestão de usuários e grupos em um diretório interno ou com integração a um provedor de identidade (IdP) externo, como Azure AD, Okta, etc. Atribuição de Permissões: Associa perfis de permissão (IAM Roles e políticas) a usuários ou grupos, controlando exatamente o que cada pessoa pode fazer em cada conta AWS. 1.2 Diferenciação de Outros Serviços IAM IAM (Identity and Access Management) é o serviço-base para gerenciamento de políticas, roles, usuários e grupos na conta AWS. IAM Identity Center expande essa funcionalidade, oferecendo SSO entre múltiplas contas AWS e aplicativos, com uma experiência de autenticação simplificada. Ele também permite configurações de federação com IdPs externos e uso de padrões como SAML 2.0 e SCIM (para provisionamento automatizado de usuários e grupos). 1.3 Casos de Uso Ambientes Multi-conta: Muitas empresas utilizam AWS Organizations para gerenciar diversas contas. O IAM Identity Center permite gerenciar, de forma centralizada, quem acessa cada conta e com quais permissões. Integração com Diretórios Corporativos: Empresas que já possuem diretório de usuários (ex.: Active Directory, Okta, Azure AD) podem sincronizar identidades e grupos para conceder ou revogar acesso de forma centralizada. Acesso Simplificado a Aplicações SaaS: Além de contas AWS, o IAM Identity Center pode dar acesso a serviços de terceiros (Salesforce, Office 365, etc.) usando SAML ou OpenID Connect (OIDC). 2. Configurações Básicas 2.1 Ativando o IAM Identity Center Acesse o AWS Management Console. Vá em IAM Identity Center (pode estar listado como “AWS Single Sign-On” em algumas regiões antigas). Se for a primeira vez, clique em Enable IAM Identity Center. Escolha o modo de diretório: IAM Identity Center directory (padrão) – gerencia usuários/grupos dentro do próprio serviço. External identity provider – integra a um IdP existente via SAML 2.0 ou via AWS Directory Service (para Active Directory on-premises, por exemplo). 2.2 Criando Usuários e Grupos (modo interno) Usuários: insira nome, e-mail, configuração de MFA (se desejado), etc. Grupos: defina grupos como “DevOps”, “Financeiro”, “Segurança” e adicione usuários. Provisionamento Manual: se você não tiver um IdP externo, pode criar usuários diretamente no IAM Identity Center. 2.3 Atribuindo Acesso a Contas AWS Vá em AWS Accounts no IAM Identity Center. Selecione a conta que deseja configurar. Clique em Assign Users or Groups. Selecione o usuário ou grupo e escolha uma role (ou crie uma nova) para determinar as permissões. Exemplo: “PowerUserAccess” para times de DevOps; “ReadOnlyAccess” para auditoria, etc. 2.4 Portal de Acesso Após configurar, cada usuário passa a usar um Portal SSO (por exemplo, https://<yourcompany>.awsapps.com/start) para fazer login. Nesse portal, o usuário vê as contas AWS e aplicativos disponíveis. Com um clique, acessa os consoles sem precisar reinserir credenciais ou chaves. 3. Integração com Provedores de Identidade (IdP) 3.1 Benefícios Provisionamento Automatizado (SCIM): quando um novo colaborador entra na organização (criado no IdP), ele é propagado automaticamente para o IAM Identity Center, evitando retrabalho manual. Single Sign-On com MFA Central: A autenticação forte ocorre no IdP (por exemplo, Azure AD com MFA). Os usuários não precisam ter senhas separadas para o IAM Identity Center. Revogação Imediata: Se o usuário for removido do IdP (ex.: demissão), seu acesso na AWS também é revogado. 3.2 Métodos de Integração SAML 2.0: A maioria dos IdPs, como Okta, Ping, Azure AD, ADFS, suportam SAML. SCIM: Para provisionamento automático de usuários e grupos. Azure AD: Integração nativa permite configurar o single sign-on e o provisionamento sem scripts adicionais, seguindo tutoriais oficiais da AWS e Microsoft. Okta: Parecido com Azure AD, com guias oficiais para SAML + SCIM. 3.3 Passo a Passo Simplificado (Exemplo Azure AD) No AWS IAM Identity Center, escolha “External identity provider” e selecione SAML 2.0. No Azure AD, configure uma aplicação corporativa SAML apontando para o endpoint do IAM Identity Center. Exporte o metadata e importe no IAM Identity Center. Habilite SCIM para provisionamento automático, copiando o token de provisão do IAM Identity Center para o Azure AD. Teste com um usuário de teste no Azure AD, e verifique se ele aparece no IAM Identity Center. 4. Funcionalidades Avançadas 4.1 Customização de Atribuição de Permissões Permission Sets: São coleções de políticas IAM que definem permissões. Você as associa a usuários/grupos para determinadas contas. Ex.: “DevOpsProdPermissionSet” com capacidade de criação e gerenciamento de recursos, mas sem poder deletar logs. Políticas Avançadas: Combine políticas gerenciadas pela AWS com políticas personalizadas para granularidade extra (ex.: restringir acesso a buckets específicos no S3). 4.2 Configuração de MFA Reforçada MFA no IdP Externo: Se estiver usando Okta ou Azure AD, a solução MFA do IdP gerencia a autenticidade. MFA Interno: Se você estiver usando o diretório interno do IAM Identity Center, pode configurar MFA com base em aplicativos de autenticação (Google Authenticator, Authy, etc.). Adaptive/Contextual MFA: Alguns IdPs suportam MFA adaptativo — solicitar MFA apenas se o usuário estiver fora da rede corporativa ou em locais suspeitos. 4.3 Auditoria e Logs AWS CloudTrail: Registra eventos relacionados ao IAM Identity Center, como criação de permission sets, atribuição de grupos, tentativas de login, etc. AWS CloudWatch Metrics/Logs: Podem ser utilizados para monitorar atividades e criar alarmes, por exemplo, se ocorrer falha de login repetidamente. IdP Logs: Em integrações SAML, parte da auditoria também ocorre no IdP, registrando quem acessou quais aplicativos. 4.4 Rotação e Gerenciamento de Credenciais Credenciais Temporárias: Quando um usuário acessa uma conta via IAM Identity Center, são usadas roles IAM com credenciais temporárias (STS). Políticas de Sessão: É possível limitar a duração da sessão, forçando reautenticação após um período. Chaves de Acesso: O IAM Identity Center também pode fornecer acesso programático (CLI) gerando credenciais temporárias para usuários, garantindo que não sejam necessárias credenciais de longa duração. 4.5 Provisionamento e Desprovisionamento (SCIM) Se a sua organização usa um IdP compatível com SCIM 2.0, você pode automatizar: Criação de Usuário: Sempre que um usuário for criado no IdP, ele é inserido no IAM Identity Center. Atribuição a Grupos: Se o usuário for adicionado a um grupo “DevOps” no IdP, ele ganha acesso correspondente na AWS automaticamente. Remoção: Se sair da empresa ou do grupo, o acesso é revogado. 5. Melhores Práticas Menor Privilégio: Crie permission sets específicos para cada função de trabalho, evitando conceder “AdministratorAccess” indiscriminadamente. Separação de Ambientes: Use diferentes permission sets para desenvolvimento, homologação e produção, garantindo que acesso irrestrito não vaze para produção. Forçar MFA: Se o IdP não estiver usando MFA, habilite MFA ao menos no IAM Identity Center para contas sensíveis. Política de Rotina de Acesso: Periodicamente revise quem tem acesso a quais contas/permission sets e remova privilégios obsoletos. Automação de Provisionamento: Sempre que possível, use SCIM para sincronizar usuários, reduzindo erros manuais. Governança Multi-conta: Se estiver usando AWS Organizations, habilite a delegação para que o IAM Identity Center gerencie todas as contas membro. 6. Conclusão O AWS IAM Identity Center é uma peça-chave para empresas que desejam unificar a autenticação e autorização em múltiplas contas AWS e, muitas vezes, em dezenas de aplicativos SaaS. Ele simplifica o fluxo de login de usuários, reduz a complexidade de gerenciamento de credenciais e, ao mesmo tempo, fortalece a segurança graças a políticas de MFA e federação com provedores de identidade. ...

1. Visão Geral do Prowler Open Source Multi-nuvem: Embora o Prowler tenha surgido com foco em AWS, a versão atual também suporta Azure, GCP e Oracle Cloud. No contexto de AWS, isso é especialmente útil para organizações que gerenciam ambientes híbridos ou multi-cloud. Checks extensivos: Conta com mais de 300 verificações (checks) que cobrem diferentes áreas de segurança e conformidade (identidade, rede, criptografia, logging, monitoramento etc.). Frameworks integrados: Vem com suporte embutido a benchmarks como CIS (Center for Internet Security), PCI-DSS, HIPAA, ISO 27001, SOC 2, GDPR, entre outros. Você pode escolher rodar auditorias específicas ou mesclar várias. 2. Instalação e Configuração 2.1 Métodos de Instalação Clone do Repositório (GitHub) ...