Aws

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) ...

1. Segurança em container Antes de mergulharmos especificamente em ECS ou EKS, é importante reforçar as boas práticas comuns de segurança em container: Imagens confiáveis Utilize registries (repositórios de imagens) confiáveis, como o Amazon ECR (Elastic Container Registry). Faça image scanning para detectar vulnerabilidades e manter as imagens sempre atualizadas com patches de segurança. Princípio do mínimo privilégio Evite executar container como usuário root. Garanta que as permissões (filesystem, rede, etc.) estejam restritas ao mínimo necessário. Segregação de responsabilidades ...

1. Detecção de Intrusões (IDS/IPS) 1.1 Wazuh (OSSEC Fork) O que é: O Wazuh é uma plataforma de segurança que surgiu como um fork do OSSEC, fornecendo detecção de intrusões em hosts (HIDS), análise de logs e verificação de integridade de arquivos (FIM). Por que usar na AWS: Pode ser integrado a instâncias EC2, containers ou mesmo VMs on-premises em um ambiente híbrido, consolidando todos os logs no Wazuh Manager. Utiliza agentes que monitoram atividades suspeitas como elevação de privilégio, alterações de arquivos críticos, tentativas de login fora do padrão etc. Integrações: ...