Contratar um teste de intrusão em ambiente Azure costuma esbarrar em uma dúvida que nenhum scanner resolve: o que exatamente pode ser atacado quando boa parte da infraestrutura pertence à Microsoft? Times de segurança e compliance que já entendem a necessidade do pentest travam na hora de montar o escopo, porque as regras de engajamento da própria Microsoft definem limites que não existem em um datacenter tradicional — e uma atividade executada sem esse cuidado pode ser interpretada como ataque real.
Este guia percorre o caminho operacional que costuma faltar nas discussões sobre o tema: como preparar o ambiente antes do teste, com identidades dedicadas e permissões temporárias, o que a Microsoft permite, exige aprovação ou proíbe, e como conduzir avaliações em cargas específicas do Azure sem sair do perímetro autorizado. Também trata do que fazer quando um teste legítimo é sinalizado pelo sistema de detecção da plataforma.
Para organizações que lidam com dados sensíveis e transações financeiras, o pentest não termina no relatório. Por isso, o texto avança sobre mapeamento de achados, critérios de priorização de remediação e adequação a exigências regulatórias — temas que separam uma avaliação pontual de um processo contínuo de redução de risco.
O que é um teste de intrusão em ambiente Azure e por que ele difere de um pentest tradicional
Um teste de intrusão em ambiente Azure é uma avaliação autorizada que simula ataques reais contra cargas de trabalho hospedadas na nuvem da Microsoft — máquinas virtuais, clusters AKS, aplicações web, identidades e redes virtuais — para identificar falhas exploráveis antes que um agente malicioso o faça. Diferente do pentest tradicional em infraestrutura on-premises, onde a organização controla fisicamente servidores, switches e firewalls, no Azure parte da superfície de ataque pertence à Microsoft e está fora do alcance do teste. Isso muda profundamente o desenho do escopo, as ferramentas utilizadas e o formato do relatório final.
A diferença central está no modelo de responsabilidade compartilhada. Em um pentest de datacenter próprio, o testador pode avaliar a rede física, o hipervisor e os controles de acesso ao rack. No Azure, esses componentes são responsabilidade da Microsoft e não podem ser atacados. O pentest em nuvem concentra-se nas camadas que o cliente controla: configuração de identidade, políticas de acesso, segredos, código de aplicação, regras de rede e permissões de recursos. Segundo a Microsoft, atividades contra a infraestrutura subjacente do Azure configuram violação dos termos de uso, mesmo quando executadas por profissionais contratados.
Outra diferença prática envolve o ritmo e a superfície de exposição. Ambientes Azure mudam constantemente — recursos são provisionados via IaC, permissões são delegadas, contas de serviço proliferam. Um pentest pontual captura um instantâneo que pode ficar obsoleto em semanas. Por isso, equipes maduras combinam o teste de intrusão com revisão contínua de postura, algo que um scanner de vulnerabilidade não substitui, mas complementa quando integrado a processos de remediação.
O que a Microsoft permite e proíbe no Azure: regras de engajamento atualizadas
As regras de engajamento para pentest no Azure estão documentadas nas Microsoft Cloud Unified Penetration Testing Rules of Engagement, que definem quais atividades dispensam autorização prévia e quais são terminantemente vedadas. O princípio geral: o cliente pode testar seus próprios recursos de nuvem, mas não pode atacar a plataforma, serviços de terceiros alheios ao teste ou a infraestrutura compartilhada da Microsoft. Violações podem resultar em suspensão da assinatura, notificação ao provedor de internet e, em casos extremos, ação legal.
Antes de iniciar qualquer atividade, o time de segurança deve mapear exatamente quais assinaturas, resource groups e serviços entram no escopo. Testes acidentais contra recursos fora do perímetro autorizado — como um endpoint público de outro locatário — são tratados como ataque real. A recomendação é documentar o escopo em contrato e compartilhá-lo com todos os testadores envolvidos, incluindo subcontratados.
Atividades de teste autorizadas
Testes de intrusão contra os recursos que o cliente possui e opera integralmente incluem máquinas virtuais, aplicações web em App Service, Azure Functions, clusters AKS, bancos de dados gerenciados, contas de armazenamento e redes virtuais configuradas pelo cliente. O testador pode explorar vulnerabilidades de aplicação, escalar privilégios dentro do tenant, tentar comprometer identidades e testar configurações de rede — desde que o alvo pertença à organização contratante.
- Testes de aplicação web em App Service e Functions
- Exploração de VMs e containers sob controle do cliente
- Escalação de privilégio em identidades do próprio tenant
- Testes de regras de NSG, rotas e exposição de portas
- Avaliação de configuração em Key Vault, Storage e bancos gerenciados
Também são permitidos testes contra APIs próprias publicadas no Azure API Management e contra integrações via Logic Apps, desde que o fluxo completo permaneça dentro dos recursos do cliente. A chave é a propriedade: se o recurso aparece na assinatura do contratante e não é um serviço de plataforma gerenciado pela Microsoft, o teste é autorizado por padrão.
Testes que exigem aprovação ou são proibidos
Algumas atividades exigem aprovação prévia da Microsoft ou são proibidas em qualquer circunstância. Testes contra serviços de plataforma — como o plano de controle do Azure Resource Manager, o portal Azure, o Microsoft Entra ID (na camada de serviço global) e a infraestrutura de data centers — são vedados. O testador não pode tentar sair de uma VM para o hipervisor, atacar o host subjacente ou explorar vulnerabilidades do próprio tecido do Azure.
- Ataques ao plano de controle, portal ou APIs globais da Microsoft
- Exploração de vulnerabilidades em serviços de plataforma compartilhados
- Phishing ou engenharia social contra funcionários da Microsoft
- Acesso não autorizado a dados de outros clientes ou locatários
- Testes de negação de serviço volumétrica contra qualquer recurso
Atividades de Red Team que envolvam táticas de phishing contra o próprio time do cliente são permitidas, mas o alvo deve ser exclusivamente a organização contratante. Qualquer coleta de credenciais que dependa de domínios, números de telefone ou infraestrutura de terceiros exige consentimento desses terceiros. O limite é claro: o teste termina onde começa a propriedade de outra parte.
Simulação de DDoS e o que fazer se seu teste for sinalizado
Simulações de DDoS volumétrico são proibidas no Azure, mesmo contra recursos próprios. A Microsoft opera proteção anti-DDoS na borda da plataforma e testes de volume podem degradar o serviço de outros clientes que compartilham a infraestrutura. Para avaliar resiliência a DDoS, o caminho correto é contratar o Azure DDoS Protection e conduzir testes em coordenação com o suporte Microsoft, que possui processo específico para exercícios controlados.
Se um teste legítimo for sinalizado pelo sistema de detecção da Microsoft, a organização recebe um aviso de abuso no portal Azure. O procedimento é responder dentro do prazo indicado, explicando que se trata de pentest autorizado, anexando o contrato e o escopo aprovado. A Microsoft pode solicitar evidências adicionais antes de liberar a assinatura. Manter documentação de autorização acessível evita que uma atividade planejada seja confundida com comprometimento real — e se houver dúvida sobre resposta a incidentes, vale revisar resposta a incidentes, pois o fluxo de comunicação é semelhante.
Escopo e modelo de responsabilidade compartilhada: o que você pode testar e o que é da Microsoft
No modelo de responsabilidade compartilhada, a Microsoft garante a segurança da nuvem — data centers, rede física, hipervisores e serviços de plataforma — enquanto o cliente responde pela segurança na nuvem: identidades, dados, aplicações, configurações de rede e controles de acesso. O pentest em Azure atua exclusivamente na segunda camada. Isso não reduz a importância do teste: a maioria das violações em nuvem decorre de configuração incorreta do cliente, não de falha na plataforma.
- Microsoft: infraestrutura física, hipervisor, rede de backbone, serviços gerenciados
- Cliente: identidades, permissões, dados, código, configuração de rede e workloads
- Compartilhado: patches de SO em VMs (cliente aplica), conformidade de serviços SaaS (configuração do cliente)
Na prática, um pentest bem desenhado começa com um inventário de recursos e a classificação de cada um conforme a responsabilidade. Um banco Azure SQL Database, por exemplo, tem o sistema operacional e o engine gerenciados pela Microsoft — o testador não tenta explorar o serviço em si, mas sim a configuração de firewall, as credenciais expostas e as permissões de acesso delegadas. Já uma VM Windows é quase integralmente responsabilidade do cliente: patch de SO, antivírus, configuração de disco e credenciais locais são todos testáveis.
Essa distinção também define o que entra no relatório. Achados relacionados à plataforma Microsoft devem ser reportados à Microsoft, não listados como vulnerabilidade do cliente. O relatório final deve separar claramente: falhas de configuração do cliente, vulnerabilidades de aplicação e observações sobre controles que dependem de ação da Microsoft. Para decisores de TI, essa clareza é essencial na hora de priorizar investimentos.
Preparação do ambiente: identidades, permissões e isolamento para o pentest
Executar um pentest em Azure sem preparação adequada gera três riscos: impacto acidental em produção, sinalização de abuso pela Microsoft e achados que não refletem o ambiente real. A preparação começa pela definição de um tenant ou assinatura de teste, contas dedicadas e isolamento de rede. Em ambientes financeiros ou que processam transações via Pix, o isolamento é ainda mais crítico — um teste mal planejado pode derrubar um serviço de pagamento e gerar prejuízo imediato.
O ideal é conduzir o pentest em um ambiente espelho que replique fielmente as configurações de produção: mesmas políticas de RBAC, mesmas regras de NSG, mesmas identidades gerenciadas e os mesmos segredos (preferencialmente em versão de teste). Isso permite testar cenários de ataque sem expor dados reais de clientes ou interromper transações. Quando o teste em produção for inevitável, ele deve ser limitado a janelas de baixa atividade e a atividades de baixo impacto, como enumeração de configuração.
Uso de contas dedicadas, RBAC e PIM durante o teste
Os testadores devem operar com contas dedicadas, separadas das contas administrativas do dia a dia. Essas contas recebem permissões mínimas via RBAC — por exemplo, Reader para enumeração inicial e Contributor apenas nos recursos do escopo.
O Privileged Identity Management (PIM) deve ser configurado para que qualquer elevação de privilégio durante o teste seja just-in-time, com aprovação e registro de auditoria. Isso garante que o testador não mantenha acesso administrativo permanente e que todas as ações fiquem rastreadas no log do Microsoft Entra ID. A trilha de auditoria gerada pelo PIM também serve como evidência de que o teste foi controlado, útil tanto para o relatório quanto para eventual questionamento da Microsoft.
- Contas dedicadas com nomes identificáveis (ex.: pentest-01)
- RBAC mínimo por fase do teste, ampliado apenas quando necessário
- PIM com elevação just-in-time e aprovação registrada
- Logs do Entra ID exportados para workspace de auditoria separado
Como evitar impacto em produção e configurar ambientes espelho
Ambientes espelho podem ser criados com IaC — Terraform, Bicep ou ARM templates — replicando a topologia de produção em uma assinatura isolada. O custo é proporcional aos recursos replicados, mas em cenários de alto risco, como processamento de Pix, o investimento se justifica. Uma alternativa intermediária é testar em staging, desde que o staging seja fiel o suficiente para gerar achados válidos.
Quando o espelho não for viável, o teste em produção deve seguir regras rígidas: proibição de exploração destrutiva, limitação de força bruta contra contas reais e exclusão de cargas de trabalho críticas do escopo ativo. O contrato de pentest deve especificar quais recursos são intocáveis e quais ações exigem aprovação verbal ou escrita antes da execução. Essa disciplina reduz a chance de um teste de intrusão se transformar em incidente de produção.
Ferramentas e abordagens para testar cargas de trabalho no Azure
O arsenal de pentest em Azure combina ferramentas tradicionais de segurança ofensiva com utilitários nativos da nuvem. Ferramentas como Nmap, Burp Suite, BloodHound e pacotes de exploração de Kubernetes são usadas em conjunto com o Azure CLI, o Microsoft Graph PowerShell e scanners de configuração como Prowler ou Scout Suite. A diferença está no alvo: em vez de atacar um servidor, o testador frequentemente ataca uma API, uma identidade ou uma política mal configurada.
A abordagem recomendada segue a cadeia de ataque em nuvem: enumeração de superfície exposta, descoberta de identidades e permissões, movimento lateral via credenciais ou funções, e exfiltração simulada de dados. Cada etapa gera evidências que serão mapeadas para frameworks como MITRE ATT&CK for Cloud no relatório final. Essa estrutura permite que o decisor de TI entenda não apenas o que falhou, mas como um atacante real exploraria a falha em sequência.
Testes em VMs, AKS, App Service e Functions
Em VMs, o teste cobre o sistema operacional, aplicações instaladas, credenciais locais, discos e configuração de rede. O testador verifica se as VMs estão expostas à internet sem necessidade, se os discos estão criptografados, se há patches ausentes e se as credenciais administrativas são fracas ou reutilizadas. A exploração segue o padrão de pentest tradicional, mas o contexto de nuvem adiciona vetores como metadados de instância e identidades gerenciadas atribuídas à VM.
No AKS, o foco muda para a segurança do cluster: permissões do RBAC do Kubernetes, configuração de pods, segredos em ConfigMaps, exposição do API server e integração com o Entra ID. Um erro comum é conceder permissões excessivas a contas de serviço, permitindo que um pod comprometido acesse recursos fora do namespace. Já em App Service e Functions, os testes concentram-se em autenticação e autorização da aplicação, configuração de CORS, segredos em variáveis de ambiente e integração com identidades gerenciadas — vetores que frequentemente passam despercebidos em revisões manuais.
Testes em Entra ID, identidades gerenciadas e chaves do Key Vault
O Microsoft Entra ID é o coração da segurança no Azure, e testá-lo exige cuidado redobrado. O testador pode avaliar políticas de acesso condicional, força de senhas, permissões de aplicações registradas, convites de guest users e configuração de MFA — mas não pode atacar o serviço global do Entra ID. A distinção é sutil: testar se uma política de acesso condicional pode ser contornada é permitido; tentar explorar uma vulnerabilidade do serviço de autenticação da Microsoft não é.
Identidades gerenciadas são um vetor crítico: se uma VM ou Function possui identidade gerenciada com permissões amplas, o comprometimento daquele recurso concede acesso direto a outros serviços sem necessidade de credencial. O testador deve mapear todas as identidades gerenciadas e verificar se o princípio de privilégio mínimo é respeitado. No Key Vault, o foco está nas políticas de acesso, na exposição de segredos em logs ou código e na configuração de soft delete e purge protection — controles que impedem destruição acidental ou maliciosa de chaves.
Testes em redes virtuais, NSGs, Private Endpoints e exposição pública
A camada de rede no Azure é testada por meio de enumeração de VNets, sub-redes, Network Security Groups (NSGs), rotas e endpoints públicos. O testador verifica se há portas administrativas (RDP, SSH, WinRM) abertas para a internet, se os NSGs possuem regras excessivamente permissivas e se recursos internos estão expostos indevidamente. Private Endpoints e Private Link são avaliados quanto à configuração correta e à possibilidade de bypass.
- Enumeração de IPs públicos e portas abertas em todas as assinaturas
- Revisão de regras de NSG com prioridade inadequada ou origem ampla
- Verificação de Private Endpoints e integração com DNS privado
- Análise de exposição de Storage Accounts, bancos e APIs
- Teste de segmentação entre sub-redes e ambientes
Um achado recorrente em pentests Azure é o Storage Account com acesso público habilitado por padrão ou chave de acesso exposta em repositório de código. Outro é a ausência de Private Endpoint em bancos de dados que contêm dados sensíveis, forçando tráfego pela rede pública. Esses problemas são detectáveis em minutos, mas podem expor dados financeiros ou pessoais — cenário especialmente grave para empresas que processam Pix e estão sujeitas à LGPD e às normas do BACEN.
Metodologias e frameworks aplicáveis: PTES, OWASP e MITRE ATT&CK for Cloud
O Penetration Testing Execution Standard (PTES) fornece a espinha dorsal do pentest em Azure: definição de escopo, coleta de inteligência, modelagem de ameaças, exploração, pós-exploração e relatório. Cada fase do PTES ganha contornos específicos na nuvem — a coleta de inteligência, por exemplo, inclui enumeração via Azure CLI e Graph API, enquanto a pós-exploração foca em movimento lateral entre recursos e assinaturas.
O OWASP Testing Guide e o OWASP Cloud-Native Application Security Top 10 complementam o PTES na camada de aplicação. Para aplicações em App Service, Functions ou APIs, os testes seguem os critérios clássicos do OWASP — injeção, autenticação quebrada, exposição de dados sensíveis, controle de acesso falho — adaptados ao contexto de nuvem, onde configurações de CORS, identidades gerenciadas e políticas de API ganham peso. A relação entre ethical hacking e proteção empresarial passa exatamente por essa combinação de metodologia e contexto.
O MITRE ATT&CK for Cloud organiza os achados em táticas e técnicas específicas de nuvem: Cloud Accounts, Cloud Infrastructure Discovery, Steal Application Access Token, Cloud Service Dashboard e dezenas de outras. Mapear cada vulnerabilidade encontrada para uma técnica ATT&CK permite que o time de defesa entenda a cadeia de ataque completa e priorize detecções. Para quem opera Red Team e Blue Team, esse mapeamento é a ponte entre o teste ofensivo e a melhoria contínua da defesa.
Do relatório à remediação: priorização de achados e evidências para auditoria
Um relatório de pentest em Azure eficaz não é uma lista de vulnerabilidades, mas um documento de decisão. Cada achado deve conter: descrição técnica, recurso afetado, técnica MITRE ATT&CK correspondente, evidência reproduzível (comando executado, captura de tela, resposta da API), impacto no negócio e recomendação de remediação com passos concretos. A priorização deve considerar o risco real no contexto do cliente — uma porta SSH aberta em VM de desenvolvimento tem peso diferente de uma identidade gerenciada com permissão de escrita em banco de produção.
Para ambientes regulados, o relatório também precisa servir como evidência de auditoria. Isso significa registrar data e hora de cada atividade, contas utilizadas, escopo aprovado e limitações do teste. Auditores do BACEN e da LGPD frequentemente solicitam não apenas o resultado, mas a demonstração de que o teste foi conduzido de forma controlada e autorizada. A ausência dessa documentação pode transformar um pentest bem executado em não conformidade.
- Classificação por severidade com critério explícito (CVSS + impacto no negócio)
- Evidências reproduzíveis com comandos e respostas registradas
- Mapeamento para MITRE ATT&CK e, quando aplicável, OWASP
- Recomendações acionáveis com prioridade e esforço estimado
- Registro de atividades para auditoria e conformidade regulatória
A remediação deve seguir um ciclo curto: correção imediata para achados críticos, validação de que a correção foi eficaz e reteste direcionado. Em ambientes Azure, muitas correções são feitas via mudança de configuração — fechar uma porta, restringir uma política de acesso, rotacionar uma chave — o que permite resposta rápida. Achados estruturais, como redesign de segmentação de rede ou revisão do modelo de identidades, entram em um roadmap de médio prazo.
Conformidade e contexto brasileiro: LGPD, BACEN e requisitos regulatórios
No Brasil, o teste de intrusão em Azure está inserido em um arcabouço regulatório que vai além das regras da Microsoft. A LGPD exige que o controlador adote medidas técnicas para proteger dados pessoais, e o pentest é uma evidência concreta de diligência. Um programa de testes periódicos demonstra que a organização leva essa obrigação a sério. Para empresas que lidam com dados sensíveis, a ausência de pentest pode ser interpretada como falha de governança em caso de incidente.
No setor financeiro, normas do Banco Central estabelecem requisitos de segurança cibernética para instituições autorizadas a funcionar. Essas normas exigem a implementação de política de segurança cibernética, avaliação de riscos e testes de segurança, incluindo testes de intrusão em sistemas críticos. O pentest em Azure torna-se parte da demonstração de conformidade.
Vale destacar que a ISO 27001 também orienta a realização de testes de segurança como controle de avaliação de vulnerabilidades técnicas. O controle A.8.8 da versão 2022 da norma trata especificamente de gerenciamento de vulnerabilidades técnicas, e o A.8.16 aborda atividades de monitoramento. Um pentest documentado e recorrente atende a ambos, além de fortalecer a posição da empresa em auditorias de certificação.
Erros comuns ao contratar ou executar um pentest no Azure
O erro mais frequente é contratar um pentest genérico sem experiência em nuvem. Testadores acostumados a infraestrutura on-premises tendem a buscar vulnerabilidades em servidores e redes tradicionais, ignorando os vetores específicos do Azure: identidades gerenciadas, RBAC excessivo, configuração de Key Vault, exposição de Storage Accounts e permissões de aplicações no Entra ID. O resultado é um relatório que passa uma falsa sensação de segurança.
Outro erro comum é não definir escopo com precisão. Testes que extrapolam os recursos do cliente — por exemplo, tentando acessar serviços de plataforma ou outros locatários — violam as regras da Microsoft e podem gerar sinalização de abuso. Da mesma forma, escopos excessivamente restritos deixam de fora justamente as áreas de maior risco, como identidades e configuração de rede. O equilíbrio exige um inventário prévio e alinhamento entre o time de segurança e o fornecedor do teste.
- Contratar pentest sem experiência comprovada em Azure e Entra ID
- Não documentar escopo, contas e autorização antes de iniciar
- Executar teste em produção sem isolamento ou janela controlada
- Ignorar identidades gerenciadas e permissões de aplicações
- Tratar o relatório como fim do processo, sem reteste ou remediação
- Não mapear achados para MITRE ATT&CK ou requisitos regulatórios
Um terceiro erro é subestimar a preparação do ambiente. Executar pentest em produção sem contas dedicadas, sem PIM e sem isolamento de rede pode causar indisponibilidade e confundir logs de auditoria. Em empresas que processam Pix, esse erro pode ter consequências financeiras diretas. A preparação adequada — ambiente espelho, contas mínimas, janela de teste e plano de contingência — é tão importante quanto a qualidade técnica do testador.
Por fim, há o erro de tratar o pentest como evento isolado. Ambientes Azure mudam rapidamente, e um teste realizado em janeiro pode não refletir a configuração de junho. A prática madura combina pentests periódicos com monitoramento contínuo de postura, revisão de identidades e integração com processos de migração e governança. Para mais detalhes sobre como um teste de invasão se aplica ao ecossistema Microsoft, vale consultar como funciona um teste de invasão em Microsoft 365 e Azure.
Perguntas frequentes sobre teste de intrusão em ambiente Azure
Preciso notificar a Microsoft antes de realizar um pentest no Azure?
Para a maioria dos testes contra recursos próprios do cliente, não. A Microsoft dispensa notificação prévia para testes de aplicações, VMs, containers e configuração de rede de propriedade do cliente. A exceção são testes que envolvam simulação de DDoS ou atividades que possam afetar a plataforma — nesses casos, é obrigatório coordenar com o suporte Microsoft.
Quanto custa um pentest em ambiente Azure?
O valor varia conforme escopo, profundidade e experiência do fornecedor. O custo deve ser avaliado em relação ao risco do negócio e aos requisitos regulatórios aplicáveis.
Um pentest em Azure substitui a necessidade de monitoramento contínuo?
Não. O pentest é uma avaliação pontual que captura o estado do ambiente em um momento específico. Monitoramento contínuo de configuração, alertas de segurança e revisão periódica de identidades são complementares. Juntos, eles formam um programa de segurança que reduz risco de forma sustentada.
Posso testar meu tenant do Microsoft 365 junto com o Azure?
Sim, e a combinação é recomendada, já que as identidades do Entra ID são compartilhadas entre os dois ambientes. O teste do Microsoft 365 segue regras semelhantes: é permitido testar configurações do cliente, como políticas de acesso condicional e permissões de aplicações, mas não atacar o serviço global da Microsoft. Para entender os limites, consulte como estruturar resposta a incidentes no Microsoft 365 e como bloquear acesso externo no Microsoft 365, que abordam controles frequentemente testados.
Com que frequência devo realizar pentest no Azure?
A frequência depende do perfil de risco e das exigências regulatórias. Instituições financeiras sob as normas do BACEN costumam adotar ciclo anual para testes completos, com testes focados após mudanças significativas de arquitetura. Empresas em setores menos regulados podem adotar ciclo bienal, desde que complementado por monitoramento contínuo e gestão de vulnerabilidades.
O que fazer se o pentest encontrar uma vulnerabilidade na plataforma Microsoft?
Vulnerabilidades na plataforma devem ser reportadas à Microsoft por meio do programa de recompensas ou do suporte, não incluídas no relatório como achado do cliente. A Microsoft mantém canais específicos para divulgação responsável, e a comunicação adequada protege tanto o cliente quanto a comunidade de usuários do Azure.
