Guia

Uma instância EC2 potencialmente comprometida em um grupo Auto Scaling requer investigação com interrupção mínima.

→Desregistrar do grupo de destino do ELB, remover do grupo Auto Scaling e aplicar um grupo de segurança "forense" restritivo que nega todo o tráfego, exceto o acesso da estação de trabalho forense.

Por quê: Isso isola a instância da rede, preservando seu estado volátil (memória, processos em execução) para análise forense. Terminar imediatamente destrói as evidências.

Automatizar um fluxo de trabalho de resposta a incidentes de várias etapas (ex: snapshot, isolar, notificar) acionado por uma descoberta do GuardDuty.

→Use uma regra do EventBridge para capturar a descoberta específica e acionar uma máquina de estado do AWS Step Functions. A máquina de estado orquestra a sequência de ações com tratamento de erros e lógica de repetição.

Por quê: O Step Functions oferece orquestração robusta para fluxos de trabalho de várias etapas, garantindo confiabilidade e gerenciamento de estado, o que é superior a uma única função Lambda monolítica.

Detectar ameaças em tempo de execução (ex: cryptomining, escalonamento de privilégios) em contêineres ECS Fargate ou EC2 em execução sem implantar agentes sidecar.

→Habilitar o Amazon GuardDuty ECS Runtime Monitoring. Para EC2, implante o agente de segurança do GuardDuty como um DaemonSet. Para Fargate, use a configuração de agente automatizada.

Por quê: Isso oferece detecção de ameaças em tempo de execução sem agente (para Fargate) ou gerenciada centralmente (para EC2), capturando o comportamento dentro do contêiner sem modificar as tarefas da aplicação.

Referência↗

Remediar automaticamente uma descoberta específica do AWS Security Hub, como um bucket S3 acessível publicamente.

→Crie uma regra do EventBridge que corresponda ao tipo de descoberta específico (ex: `S3.1`) e acione uma função Lambda ou documento de Automação SSM para realizar a remediação.

Por quê: Este é o padrão nativo e orientado a eventos para resposta automatizada do Security Hub, fornecendo remediação direcionada e quase em tempo real.

Uma chave de acesso IAM foi exposta publicamente. Conter o incidente e avaliar o raio de impacto.

→1. Desativar a chave de acesso exposta. 2. Anexar uma política inline de negação total ao usuário/função para invalidar sessões STS ativas. 3. Revisar os logs do CloudTrail para todas as chamadas de API feitas com a chave. 4. Erradicar quaisquer recursos não autorizados ou principais IAM criados pelo invasor.

Por quê: A desativação da chave impede o uso futuro. A política de negação total é crítica para revogar sessões ativas criadas *antes* da desativação da chave. O CloudTrail fornece o rastro de auditoria para avaliação de danos.

Aprimorar a detecção de ameaças do GuardDuty com feeds de inteligência de ameaças específicos da empresa ou do setor.

→Carregue um arquivo de texto simples de endereços IP/CIDRs maliciosos para o S3. Crie e ative um novo conjunto de inteligência de ameaças no GuardDuty, apontando para o arquivo S3.

Por quê: Isso permite que você aumente a inteligência de ameaças gerenciada do GuardDuty com IOCs personalizados, gerando descobertas quando seus recursos se comunicam com esses IPs especificados.

Identificar instâncias EC2 com caminhos de rede abertos para a internet em portas específicas, considerando todas as configurações de rede.

→Habilitar o Amazon Inspector e revisar suas descobertas de alcançabilidade de rede.

Por quê: O Inspector realiza uma análise completa do caminho de rede de IGWs para instâncias, avaliando grupos de segurança, NACLs e tabelas de rota para determinar a alcançabilidade real. Isso é mais preciso do que apenas verificar regras individuais de grupos de segurança.

Investigar o escopo completo de uma descoberta de segurança, visualizando todas as entidades relacionadas e o comportamento histórico.

→Use o Amazon Detective. Navegue até o perfil da entidade (ex: para uma instância EC2 ou função IAM) para visualizar o gráfico de comportamento e a linha do tempo de chamadas de API relacionadas, conexões de rede e descobertas do GuardDuty.

Por quê: O Detective correlaciona automaticamente logs do CloudTrail, VPC Flow Logs e GuardDuty, fornecendo análise contextual que acelera significativamente a investigação da causa raiz em comparação com a correlação manual de logs.

Armazenar logs de auditoria (ex: CloudTrail, VPC Flow Logs) para retenção de longo prazo de forma à prova de violação e consultável para atender à conformidade.

→Entregar logs para um bucket S3 com S3 Object Lock no Modo de Conformidade habilitado. Use o Amazon Athena para consultas.

Por quê: O Object Lock no Modo de Conformidade impede a exclusão ou modificação por qualquer pessoa, incluindo o usuário root, garantindo a imutabilidade do log. O Athena oferece recursos de consulta SQL ad-hoc nos logs armazenados.

Referência↗

Coletar centralmente todos os eventos de gerenciamento e dados para uma AWS Organization inteira.

→Na conta de gerenciamento, crie um CloudTrail Organization Trail. Para capturar dados em nível de objeto, use seletores de eventos avançados para registrar tipos de eventos específicos (ex: S3 PutObject, Lambda Invoke) para recursos de alto valor.

Por quê: Um trail de organização registra automaticamente eventos para todas as contas de membros. Os seletores de eventos avançados são críticos para registrar de forma econômica eventos de dados de alto volume, visando apenas os recursos necessários.

Realizar análise complexa, baseada em SQL, em eventos do CloudTrail de toda a organização ao longo de vários anos.

→Habilite o AWS CloudTrail Lake e crie um armazenamento de dados de eventos em nível de organização com o período de retenção necessário (até 7 anos). Use o editor de consultas SQL integrado para análise.

Por quê: O CloudTrail Lake fornece um armazenamento de dados gerenciado e imutável, e um motor de consulta construído especificamente para eventos do CloudTrail, eliminando a necessidade de gerenciar S3, Glue e Athena para análise de logs.

Monitorar todas as consultas DNS feitas por recursos dentro de uma VPC para caça a ameaças ou solução de problemas.

→Habilite o Route 53 Resolver DNS Query Logging e configure-o para enviar logs para o CloudWatch Logs, S3 ou Kinesis Data Firehose.

Por quê: Isso oferece visibilidade detalhada sobre a atividade de resolução de DNS em suas VPCs, capturando o domínio consultado, a instância de origem e a resposta, o que é crucial para detectar ameaças baseadas em DNS.

Centralizar e normalizar logs de segurança de várias fontes AWS e de terceiros em um data lake usando um esquema padrão.

→Implante o Amazon Security Lake. Ele coleta e normaliza automaticamente os dados no Open Cybersecurity Schema Framework (OCSF) e os armazena em formato Parquet no S3.

Por quê: O Security Lake automatiza a criação e o gerenciamento de um data lake de segurança, reduzindo a sobrecarga operacional de construir pipelines ETL personalizados para normalização.

Automatizar a coleta de evidências para auditorias de conformidade contra frameworks como SOC 2, PCI DSS ou HIPAA.

→Use o AWS Audit Manager. Selecione um framework pré-construído, que coleta automaticamente evidências de serviços AWS (CloudTrail, Config, Security Hub) e as mapeia para controles de conformidade específicos.

Por quê: O Audit Manager automatiza e centraliza o processo de coleta de evidências, reduzindo significativamente o esforço manual necessário para preparar e conduzir auditorias de conformidade.

Descobrir e classificar automaticamente dados sensíveis (PII, PHI, financeiros) em todos os buckets S3.

→Habilite o Amazon Macie e configure trabalhos automatizados de descoberta de dados sensíveis. Use identificadores de dados gerenciados para tipos de dados comuns e crie identificadores de dados personalizados para formatos proprietários.

Por quê: O Macie oferece uma solução gerenciada e escalável para classificação de dados S3. Para suprimir descobertas de dados não sensíveis conhecidos (ex: dados de teste), use as listas de permissão do Macie.

Aplicar múltiplos controles de segurança em um bucket S3, como exigir SSE-KMS com uma chave específica e negar requisições HTTP.

→Use uma política de bucket com múltiplas declarações `Deny` e chaves de condição: `aws:SecureTransport: false`, `s3:x-amz-server-side-encryption: "aws:kms"` e `s3:x-amz-server-side-encryption-aws-kms-key-id: "key-arn"`.

Por quê: As políticas de bucket fornecem controle granular em nível de recurso. Usar múltiplas chaves de condição em declarações Deny é a maneira padrão de aplicar uma postura de segurança em camadas em um bucket.

Garantir que todos os novos volumes EBS sejam criptografados com uma chave KMS gerenciada pelo cliente específica, em toda a organização.

→Habilite a criptografia EBS por padrão nas configurações da conta para cada Região, especificando a CMK. Aplique uma SCP que negue `ec2:CreateVolume` se o parâmetro `encrypted` for `false` como uma salvaguarda preventiva.

Por quê: A configuração padrão oferece conveniência, enquanto a SCP fornece uma salvaguarda de aplicação rígida, criando uma abordagem de defesa em profundidade para criptografia de dados em repouso para EBS.

Criptografar grandes objetos de dados (> 4KB) usando AWS KMS.

→Use a criptografia de envelope. Chame `KMS:GenerateDataKey` para obter uma chave de dados em texto simples e uma chave de dados criptografada. Use a chave em texto simples para criptografar o objeto grande localmente. Armazene o objeto criptografado e a chave de dados criptografada juntos. Descarte a chave em texto simples.

Por quê: A API KMS Encrypt tem um limite de 4KB. A criptografia de envelope permite criptografar dados de qualquer tamanho enquanto a pequena chave de dados é protegida pelo KMS, reduzindo custos e latência em comparação com a transmissão de dados via KMS.

Referência↗

Usar a mesma chave de criptografia em múltiplas Regiões AWS para DR ou consistência global de aplicações.

→Crie uma chave primária KMS multi-região em uma Região e crie chaves de réplica em outras Regiões. Dados criptografados com uma chave em uma Região podem ser descriptografados com a réplica em outra.

Por quê: As chaves multi-região compartilham o mesmo material de chave e ID de chave, permitindo a portabilidade de dados entre regiões sem chamadas de API entre regiões para descriptografia.

Armazenar e rotacionar automaticamente credenciais de forma segura (ex: senhas de banco de dados, chaves de API) usadas por aplicações.

→Armazene as credenciais no AWS Secrets Manager. Configure a rotação automática usando uma função Lambda de rotação personalizada ou fornecida pela AWS. As aplicações recuperam os segredos em tempo de execução via uma função IAM.

Por quê: O Secrets Manager é um serviço construído especificamente para todo o ciclo de vida dos segredos, incluindo armazenamento seguro, controle de acesso, auditoria e rotação automatizada, reduzindo o risco de credenciais codificadas ou obsoletas.

Gerenciar certificados TLS públicos para websites e certificados privados para comunicação interna de microsserviços (mTLS).

→Use o AWS Certificate Manager (ACM) para certificados públicos gratuitos integrados com ELB/CloudFront. Crie uma autoridade de certificação privada usando o ACM Private CA para emitir e gerenciar certificados privados para serviços internos.

Por quê: Isso separa a PKI pública e privada, usando a ferramenta apropriada para cada caso de uso. O ACM gerencia o ciclo de vida dos certificados públicos, enquanto o ACM Private CA fornece uma hierarquia PKI privada totalmente gerenciada.

Armazenar dados imutavelmente por um período de retenção fixo, onde nem mesmo o usuário root pode excluí-los.

→Habilite o S3 Object Lock no bucket. Coloque os objetos sob um período de retenção com o Modo de Conformidade.

Por quê: O Modo de Conformidade é o controle WORM (Write-Once-Read-Many) mais forte, impedindo a exclusão por qualquer usuário. O Modo de Governança pode ser contornado por principais autorizados.

Proteger backups contra exclusão (ex: devido a ransomware ou credenciais comprometidas) por um período de retenção obrigatório.

→Habilite o AWS Backup Vault Lock no Modo de Conformidade com um período de retenção mínimo.

Por quê: O Vault Lock no Modo de Conformidade torna o cofre de backup compatível com WORM, impedindo que qualquer usuário, incluindo o root, exclua pontos de recuperação antes que o período de retenção expire.

Processar dados altamente sensíveis onde os dados nunca devem ser expostos ao sistema operacional, hypervisor ou operadores AWS.

→Use AWS Nitro Enclaves para criar um ambiente de computação criptograficamente isolado. Use a atestação KMS para garantir que apenas enclaves verificados possam descriptografar dados.

Por quê: O Nitro Enclaves oferece o nível mais forte de proteção de dados em uso na AWS, utilizando atestação em nível de hardware para criar um ambiente de execução confiável.

Usar serviços AWS com chaves de criptografia que são fisicamente armazenadas e gerenciadas em um HSM on-premises, fora da AWS.

→Configure um KMS External Key Store (XKS) que atua como proxy para operações criptográficas do KMS para um gerenciador de chaves externo.

Por quê: O XKS permite que os clientes mantenham o controle de seu material de chave fora da AWS para atender a requisitos de soberania ou conformidade, enquanto ainda se integram a serviços AWS que são compatíveis com KMS.

Aplicar uma política rigorosa de "sem buckets S3 públicos" em toda a organização com controles preventivos e detectivos.

→Habilite o S3 Block Public Access em nível de organização a partir da conta de gerenciamento. Complemente com uma SCP que negue ações como `s3:PutBucketPolicy` se a política permitir acesso público. Use o AWS Config para detectar desvios.

Por quê: Esta abordagem em camadas oferece um bloqueio padrão (configuração da organização), uma salvaguarda preventiva que impede configurações incorretas (SCP) e um controle detectivo para monitoramento contínuo (Config).

Inspecionar todo o tráfego inter-VPC e com destino à internet usando um appliance de segurança centralizado (ex: AWS Network Firewall).

→Crie uma VPC de inspeção dedicada. Use um Transit Gateway para conectar todas as VPCs. Configure as tabelas de rota do TGW para enviar todo o tráfego através da VPC de inspeção. Habilite o modo de appliance no anexo do TGW para roteamento simétrico.

Por quê: Este é o modelo hub-and-spoke padrão para inspeção de tráfego centralizada, oferecendo escalabilidade e aplicação consistente de políticas sem malhas complexas de VPC peering.

Proteger uma aplicação web (no CloudFront/ALB) contra OWASP Top 10, bots e ataques de aquisição de contas.

→Anexe o AWS WAF com AWS Managed Rules (ex: `AWSManagedRulesCommonRuleSet`), o grupo de regras gerenciadas Bot Control e o grupo de regras gerenciadas Account Takeover Prevention (ATP).

Por quê: Esta abordagem em camadas utiliza múltiplos grupos de regras gerenciadas para ampla proteção (Common), detecção automatizada de tráfego (Bot Control) e segurança especializada de endpoints de login (ATP).

Fornecer acesso seguro e privado a um serviço de API SaaS a partir de VPCs de clientes sem expor o serviço à internet.

→Crie um serviço de endpoint AWS PrivateLink apoiado por um Network Load Balancer (NLB). Os clientes criam endpoints de interface VPC em suas VPCs para acessar o serviço.

Por quê: O PrivateLink mantém o tráfego na backbone privada da AWS, evitando a internet pública e eliminando a necessidade de VPC peering complexo, VPNs ou whitelisting de IPs. É o padrão escalável para conectividade SaaS privada.

Restringir o acesso ao bucket S3 para que o conteúdo seja acessível apenas através de uma distribuição CloudFront.

→Use o CloudFront Origin Access Control (OAC). Atualize a política do bucket S3 para permitir acesso apenas do principal de serviço da distribuição CloudFront, condicionado ao ARN da distribuição específica.

Por quê: O OAC é o método atualmente recomendado, superior ao legado Origin Access Identity (OAI). Ele suporta todos os recursos do S3, incluindo SSE-KMS, e segue as melhores práticas de segurança.

Fornecer acesso shell seguro e auditável a instâncias EC2 em subnets privadas sem abrir portas SSH/RDP ou gerenciar hosts bastion.

→Instale o Agente SSM nas instâncias EC2. Use o AWS Systems Manager Session Manager para acesso. As políticas IAM controlam quem pode iniciar sessões. A atividade da sessão pode ser registrada no CloudWatch Logs e no S3.

Por quê: O Session Manager oferece acesso seguro, baseado em navegador ou CLI, através de um túnel criptografado, eliminando a necessidade de portas de entrada, hosts bastion e chaves SSH, ao mesmo tempo em que fornece auditoria completa.

Implementar filtragem em nível de DNS para impedir que recursos da VPC resolvam domínios maliciosos conhecidos.

→Configure o Route 53 Resolver DNS Firewall com listas de domínio gerenciadas (para malware, C2) e listas de bloqueio personalizadas. Associe o grupo de regras do firewall às VPCs.

Por quê: Isso oferece um serviço de filtragem DNS centralizado e gerenciado no nível da VPC, bloqueando atividades maliciosas no ponto mais inicial (resolução de DNS) sem exigir agentes baseados em host.

Implementar controles de rede de privilégio mínimo para uma aplicação web de três camadas.

→Crie grupos de segurança separados para cada camada. O SG do ALB permite entrada na porta 443 de `0.0.0.0/0`. O SG do App permite tráfego de entrada apenas do SG do ALB. O SG do DB permite tráfego de entrada apenas do SG do App na porta do banco de dados.

Por quê: Usar referências de grupos de segurança como fontes proporciona microsegmentação dinâmica e agnóstica de IP, garantindo que cada camada só possa ser acessada por sua camada adjacente e autorizada.

Conceder permissões AWS granulares, em nível de pod, para aplicações executadas no EKS, evitando o uso de funções IAM de nó compartilhadas.

→Habilite o IAM Roles for Service Accounts (IRSA) no cluster EKS. Crie uma função IAM com permissões específicas para a aplicação. Anote a conta de serviço Kubernetes da aplicação com o ARN da função IAM.

Por quê: O IRSA fornece credenciais temporárias diretamente aos pods com base em sua conta de serviço, implementando o privilégio mínimo no nível do pod e eliminando o risco de segurança de funções de nó excessivamente permissivas.

Fornecer acesso sem VPN a aplicações web internas com base na identidade do usuário e na postura de segurança do dispositivo.

→Implante o AWS Verified Access. Integre com o IdP corporativo como provedor de confiança do usuário e uma solução de gerenciamento de dispositivos como provedor de confiança do dispositivo. Crie políticas de acesso por aplicação.

Por quê: O Verified Access é construído especificamente para acesso zero-trust, avaliando cada solicitação contra políticas que consideram tanto o contexto do usuário quanto do dispositivo, eliminando a dependência da segurança do perímetro da rede.

Permitir que os desenvolvedores criem funções IAM, mas impedi-los de criar funções que possam escalar seus próprios privilégios.

→Crie uma política de limites de permissões que defina as permissões máximas permitidas. Na política IAM dos desenvolvedores, condicione a permissão `iam:CreateRole` para exigir a anexação deste limite específico via a chave de condição `iam:PermissionsBoundary`.

Por quê: Os limites de permissões definem as permissões máximas que uma entidade IAM pode ter. Isso impede o escalonamento de privilégios, garantindo que qualquer função que um desenvolvedor crie seja limitada pelo limite, independentemente da política de identidade que ele anexe.

Referência↗

Impedir que qualquer usuário em qualquer conta membro (incluindo administradores) execute ações de alto risco, como desabilitar o CloudTrail ou excluir um bucket S3 comum.

→Aplique uma Service Control Policy (SCP) à raiz ou à OU relevante que contenha uma declaração `Deny` para as ações restritas (ex: `cloudtrail:StopLogging`, `s3:DeleteBucket`).

Por quê: As SCPs são a salvaguarda máxima nas AWS Organizations. Elas definem as permissões máximas para todos os principais em uma conta, e uma negação explícita em uma SCP não pode ser substituída por nenhuma política IAM dentro da conta.

Fornecer acesso seguro e auditável entre contas para uma aplicação ou usuário.

→Na conta de destino, crie uma função IAM com uma política de confiança que especifique o ARN do principal da conta de origem. Na conta de origem, conceda ao principal a permissão `sts:AssumeRole` na função de destino. A aplicação usa STS AssumeRole para obter credenciais temporárias.

Por quê: Este é o padrão para acesso entre contas. Ele usa credenciais temporárias de curta duração e é totalmente auditável em ambas as contas via CloudTrail.

Integrar o IAM Identity Center com um IdP externo (ex: Okta, Azure AD) e automatizar o provisionamento de usuários/grupos.

→Configure o IdP externo como a fonte de identidade no IAM Identity Center. Habilite o provisionamento automático via SCIM para sincronizar usuários e grupos. Atribua conjuntos de permissões aos grupos sincronizados.

Por quê: O SCIM (System for Cross-domain Identity Management) fornece sincronização automatizada e quase em tempo real de identidades, eliminando o gerenciamento manual de usuários e garantindo que o acesso à AWS seja impulsionado pelo IdP.

Conceder acesso a recursos (ex: EC2) com base em tags, onde os principais só podem gerenciar recursos marcados com o nome de sua própria equipe/departamento.

→Marque tanto os principais IAM (usuários/funções) quanto os recursos (instâncias EC2) com uma chave comum (ex: `Team`). Crie uma única política IAM que permita ações com uma condição comparando `aws:PrincipalTag/Team` com `aws:ResourceTag/Team`.

Por quê: O Controle de Acesso Baseado em Atributos (ABAC) fornece um modelo de permissões escalável que não exige atualizações de política quando novos recursos ou equipes são adicionados. As permissões são determinadas dinamicamente com base em tags.

Um principal na Conta B precisa ler um objeto S3 na Conta A que está criptografado com uma chave KMS também na Conta A.

→São necessárias três permissões: 1) A política do bucket S3 na Conta A deve permitir o principal da Conta B. 2) A política da chave KMS na Conta A deve permitir o principal da Conta B para `kms:Decrypt`. 3) O principal na Conta B precisa de uma política IAM permitindo `s3:GetObject` e `kms:Decrypt`.

Por quê: O acesso a dados criptografados com KMS exige permissões tanto do serviço de dados (S3) quanto do serviço de criptografia (KMS). A política da chave KMS é uma política de recurso e é crítica para conceder acesso entre contas.

Compreender o resultado final da permissão quando múltiplas políticas (IAM, Recurso, SCP, Limite) se aplicam.

→A lógica de avaliação é: Uma negação explícita em qualquer política sempre anula qualquer permissão. Se não houver negação, uma permissão explícita em qualquer política aplicável concede acesso. As permissões efetivas são a interseção de todas as políticas aplicáveis.

Por quê: Este é um conceito fundamental do IAM. Uma negação explícita é a declaração mais poderosa e serve como um "não" categórico. Compreender isso é fundamental para solucionar problemas de acesso.

Impedir que um usuário ou função IAM passe uma função altamente privilegiada para um serviço AWS (ex: EC2), o que escalaria seus privilégios.

→Delimite a permissão `iam:PassRole` na política IAM do usuário/função. Restrinja o elemento `Resource` apenas aos ARNs de funções específicas e com privilégio mínimo que a entidade está autorizada a passar.

Por quê: `iam:PassRole` com um curinga (`"Resource": "*"`) é um grande risco de escalonamento de privilégios. Delimitá-lo a funções específicas e menos privilegiadas é um controle de segurança crítico.

Desafiar usuários com MFA apenas quando uma tentativa de login for considerada arriscada (ex: novo dispositivo, localização incomum).

→Habilite os recursos de Segurança Avançada no Cognito User Pool e configure a autenticação adaptativa com aplicação de MFA baseada em risco.

Por quê: Isso oferece uma melhor experiência do usuário do que exigir MFA para cada login, ao mesmo tempo em que aprimora a segurança aplicando desafios apenas a tentativas de login anômalas.

Permitir que servidores on-premises usando uma PKI privada acessem serviços AWS sem credenciais AWS de longo prazo.

→Configure o IAM Roles Anywhere. Crie uma âncora de confiança usando o certificado CA privado. Crie perfis mapeando certificados para funções IAM. Os servidores usam seus certificados para obter credenciais AWS temporárias.

Por quê: Isso estende as funções IAM a workloads externos, aproveitando a PKI existente, eliminando a necessidade de gerenciar chaves de acesso AWS on-premises.

Impedir a implantação de recursos não conformes definidos em modelos CloudFormation *antes* de serem provisionados.

→Habilite os controles proativos do AWS Control Tower. Eles usam hooks do CloudFormation para validar configurações de recursos contra políticas (escritas em cfn-guard) antes do provisionamento.

Por quê: Este é um controle "shift-left" que impede configurações incorretas na origem, o que é mais eficaz do que detectá-las e corrigi-las após a implantação.