Implantação de Engano na Nuvem com Recursos de Isca

Quando Usar

• Quando contas na nuvem (AWS/Azure/GCP) contêm dados ou infraestrutura "joia da coroa" e você precisa de um alarme que dispare no momento em que um invasor, que já obteve acesso, começar a operar.
• Quando o único engano em vigor são honeypots locais (on-prem), deixando o plano de controle da nuvem sem instrumentação.
• Ao semear credenciais falsas para capturar roubo de credenciais, vazamentos acidentais de repositórios de código ou segredos expostos em pipelines de build.
• Ao detectar reconhecimento na nuvem (enumeração de IAM, armazenamento ou segredos) e movimento lateral que usuários legítimos nunca realizariam.
• Quando você deseja detecções que sobrevivam à resposta a incidentes com alta fidelidade — um toque em um recurso de isca quase sempre significa atividade maliciosa ou não autorizada.

Este é o equivalente na nuvem às habilidades de implantação de honeypots/honeytokens/canary-tokens locais. Para estratégia de programa e como essas Atividades se mapeiam para objetivos de engajamento de adversários, use designing-adversary-engagement-with-mitre-engage.

Pré-requisitos

• Permissões de administrador/IAM na nuvem para criar principais de isca, armazenamento, segredos e configurar detecções, idealmente em uma função de implantação dedicada com privilégio mínimo.
• Logs de auditoria na nuvem já ativados: AWS CloudTrail (multi-região, com gerenciamento e eventos de dados relevantes), Azure Activity log + logs de auditoria/login do Microsoft Entra, GCP Cloud Audit Logs (Admin Activity sempre ativado; Data Access ativado onde necessário).
• Um SIEM/destino de alertas: tópico SNS, workspace do Microsoft Sentinel ou GCP Pub/Sub + Monitoring, com roteamento para o SOC.
• Uma convenção de nomenclatura e marcação que seja plausível para um invasor, mas inequívoca para os defensores internamente (por exemplo, nomes realistas, mais uma tag/rótulo interno deception=true mantido fora dos metadados visíveis para o invasor).
• Principais de isca devem ser sem permissões (negação explícita de tudo). O valor é o alerta, nunca o acesso. Uma isca que concede privilégio real é uma responsabilidade, não um controle.

Fluxo de Trabalho

1. Decida o que imitar

Escolha iscas que correspondam à forma como seus invasores operam: chaves AWS vazadas (roubo de credenciais), um bucket S3 "admin" (descoberta de dados), um segredo prod-db-password (coleta de segredos), uma conta de serviço com aparência privilegiada (movimento lateral na nuvem). Coloque iscas de credenciais onde as ferramentas de coleta procuram: arquivos de ambiente, variáveis de CI, comentários de código, um wiki interno.

2A. AWS — chaves de acesso de canário em um usuário sem permissões

Crie um usuário IAM de isca com uma política de negação explícita de tudo, em seguida, emita uma chave de acesso para plantar:

aws iam create-user --user-name svc-backup-prod --tags Key=deception,Value=true
aws iam put-user-policy --user-name svc-backup-prod \
  --policy-name deny-all \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*"}]}'
aws iam create-access-key --user-name svc-backup-prod   # plant the returned AccessKeyId/Secret

Qualquer uso desta chave aparece no CloudTrail (mesmo chamadas negadas, que ainda registram AccessDenied). Configure uma regra EventBridge no CloudTrail para alertar:

aws events put-rule --name decoy-key-used \
  --event-pattern '{"detail":{"userIdentity":{"userName":["svc-backup-prod"]}}}'
aws events put-targets --rule decoy-key-used \
  --targets "Id"="1","Arn"="arn:aws:sns:us-east-1:111111111111:soc-deception-alerts"

2B. AWS — bucket S3 de isca

Crie um bucket crível, ative eventos de dados em nível de objeto e alerte sobre qualquer leitura/lista:

aws s3api create-bucket --bucket acme-prod-db-backups-2026 --region us-east-1
aws s3api put-bucket-tagging --bucket acme-prod-db-backups-2026 \
  --tagging 'TagSet=[{Key=deception,Value=true}]'
# Ensure CloudTrail captures S3 data events for this bucket, then alert on GetObject/ListBucket
aws events put-rule --name decoy-bucket-access \
  --event-pattern '{"detail":{"eventSource":["s3.amazonaws.com"],"requestParameters":{"bucketName":["acme-prod-db-backups-2026"]}}}'

2C. AWS — segredo de isca

aws secretsmanager create-secret --name prod/db/master-password \
  --secret-string '{"username":"dbadmin","password":"DECOY-DO-NOT-USE"}' \
  --tags Key=deception,Value=true
# Alert on GetSecretValue for this secret via EventBridge -> SNS

3A. Azure — watchlist de token de isca + principal de serviço de isca

…