Guia

Iniciando uma transformação Zero Trust a partir de um modelo de perímetro tradicional.

→Priorizar o princípio de "Verificar explicitamente". Autenticar e autorizar cada solicitação de acesso com base em todos os pontos de dados disponíveis (identidade, dispositivo, localização, serviço, dados, anomalias).

Por quê: A verificação explícita é o pilar fundamental do Zero Trust. Todos os outros controles (privilégio mínimo, assumir violação) se baseiam neste princípio central de nunca confiar e sempre verificar.

Referência↗

Projetando uma defesa abrangente contra toda a cadeia de ataque de ransomware.

→Combinar Workstations de Acesso Privilegiado (PAWs) para prevenir o roubo de credenciais e o movimento lateral, com uma arquitetura de backup imutável (cofres imutáveis do Azure Backup, MUA) para recuperação resiliente.

Por quê: Isso aborda tanto a prevenção (PAWs interrompem o ataque) quanto a recuperação (backups imutáveis garantem a continuidade dos negócios se a prevenção falhar), proporcionando verdadeira resiliência.

Integrando a modelagem de ameaças em um ciclo de vida de desenvolvimento ágil com sprints curtos.

→Implementar a modelagem de ameaças incremental usando a metodologia STRIDE. Integrá-la ao planejamento de sprint, atualizando o modelo à medida que a arquitetura evolui e usando-o como um portão para revisões de segurança.

Por quê: A modelagem de ameaças deve ser contínua, não um evento único, para ser eficaz em ambientes ágeis. As atualizações incrementais mantêm a segurança alinhada com a velocidade de desenvolvimento.

Implementando Zero Trust com uma abordagem faseada para ganhos rápidos.

→Seguir a priorização do Plano de Modernização Rápida (RaMP) do Zero Trust: 1. Gerenciamento de Identidade e Acesso, 2. Endpoints e Dispositivos, 3. Aplicações, 4. Rede e Infraestrutura.

Por quê: Proteger a identidade proporciona a redução de risco imediata mais significativa e forma o plano de controle para todos os outros pilares do Zero Trust.

Priorizando a remediação de vulnerabilidades com base no impacto nos negócios, não apenas nas pontuações CVSS.

→Usar o Microsoft Security Exposure Management para realizar análises de caminho de ataque contra ativos críticos identificados. Priorizar a remediação de vulnerabilidades que fornecem caminhos de ataque viáveis para alvos de alto valor.

Por quê: A análise de caminho de ataque contextualiza as vulnerabilidades com o risco de negócios, garantindo que os esforços de remediação sejam focados nas ameaças que representam o maior perigo para a organização.

Aplicando uma linha de base de segurança consistente em uma grande empresa com muitas assinaturas Azure.

→Implementar iniciativas do Azure Policy alinhadas com o MCSB no grupo de gerenciamento raiz. Usar o Microsoft Defender for Cloud para monitoramento contínuo de conformidade em todas as assinaturas herdadas.

Por quê: A atribuição de políticas em nível de grupo de gerenciamento oferece proteções escaláveis e herdadas para todas as assinaturas atuais e futuras, garantindo uma linha de base de segurança consistente por padrão.

Projetando um Centro de Operações de Segurança (SOC) para uma empresa global com requisitos de residência de dados regionais.

→Implantar uma arquitetura Microsoft Sentinel de múltiplos workspaces. Manter os dados em workspaces regionais do Log Analytics para atender às necessidades de residência. Usar o Azure Lighthouse para gerenciamento centralizado e consultas entre workspaces para caça unificada a ameaças.

Por quê: Este modelo equilibra operações de segurança centralizadas e visibilidade global com conformidade de residência de dados local, evitando violações de transferência de dados.

Referência↗

Otimizando as operações do SOC usando tanto o Microsoft Defender XDR quanto o Microsoft Sentinel.

→Habilitar o conector do Microsoft Defender XDR no Sentinel para sincronização bidirecional de incidentes. Usar o Defender XDR para investigação profunda e automatizada de incidentes do M365/endpoint. Usar o Sentinel para correlação entre domínios com fontes de terceiros e caça avançada.

Por quê: Esta abordagem "melhor juntos" aproveita os pontos fortes de ambas as plataformas: XDR para resposta integrada e automatizada dentro do ecossistema Microsoft e SIEM para visibilidade e correlação amplas entre plataformas.

Implementando automação de resposta a incidentes sem introduzir risco excessivo de falsos positivos.

→Projetar uma estratégia de automação em camadas no Sentinel. Automatizar completamente ações de baixo risco (enriquecimento, notificações). Usar fluxos de trabalho de aprovação com intervenção humana para ações de risco médio (bloqueio de IPs). Reservar ações de alto impacto (desativação de contas) para execução manual.

Por quê: A automação em camadas equilibra a velocidade de resposta com a supervisão apropriada, maximizando a eficiência do SOC para tarefas comuns, enquanto impede que ações automatizadas causem grandes interrupções operacionais.

Estabelecendo um plano de monitoramento de segurança unificado em ambientes on-premises, Azure, AWS e GCP.

→Usar o Microsoft Sentinel como SIEM central. Integrar servidores on-premises/multicloud via Azure Arc. Usar conectores de dados nativos do Sentinel para serviços AWS e GCP. Habilitar o Microsoft Defender for Cloud em todos os ambientes.

Por quê: O Azure Arc estende o plano de controle do Azure para qualquer infraestrutura, fornecendo um painel único para gerenciamento de segurança (Defender for Cloud) e monitoramento (Sentinel) em ambientes híbridos e multicloud.

Garantindo retenção de longo prazo e à prova de adulteração de logs de auditoria administrativa para conformidade.

→Configurar as definições de diagnóstico para exportar os Logs de Atividade do Azure para um workspace dedicado do Log Analytics e para uma conta de Armazenamento do Azure imutável. Colocar esses recursos em uma assinatura de segurança/gerenciamento separada e bloqueada.

Por quê: O armazenamento imutável (WORM) impede a adulteração de logs. Uma assinatura de gerenciamento separada isola os logs dos administradores de cargas de trabalho, impedindo que um administrador comprometido apague seus rastros.

Priorizando investimentos em controle de segurança com base em padrões de ataque prováveis.

→Mapear os controles de segurança existentes para o framework MITRE ATT&CK. Analisar a inteligência de ameaças relevante para a indústria para identificar TTPs comuns usados por prováveis adversários. Priorizar o fechamento de lacunas de detecção/prevenção para esses TTPs específicos.

Por quê: Esta abordagem informada sobre ameaças garante que os investimentos em segurança estejam diretamente abordando os vetores de ataque mais prováveis e impactantes, maximizando a redução de riscos.

Gerenciando permissões excessivas (espalhamento de permissões) para identidades em Azure, AWS e GCP.

→Implantar o Microsoft Entra Permissions Management (CIEM). Usá-lo para descoberta contínua de permissões, avaliação de risco (Índice de Permissão Crescente) e geração de recomendações para dimensionar corretamente as permissões para impor o privilégio mínimo.

Por quê: CIEM é uma solução especializada para abordar a complexidade das permissões multicloud, fornecendo visibilidade e análise automatizada que não é viável apenas com ferramentas nativas de IAM da nuvem.

Projetando um programa para detectar exfiltração de dados ou sabotagem por funcionários internos.

→Implementar o Microsoft Purview Insider Risk Management. Integrar com sistemas de RH para acionar políticas com base em eventos de emprego (por exemplo, demissão). Configurar políticas com base em indicadores de risco e usar pseudonimização para proteger a privacidade durante a análise inicial.

Por quê: O gerenciamento eficaz de riscos internos requer a correlação de sinais técnicos (por exemplo, download em massa) com o contexto de RH (por exemplo, data de rescisão do funcionário), o que o Purview é projetado para fazer, respeitando a privacidade.

Projetando segurança de rede para uma topologia Azure hub-and-spoke padrão.

→Implantar o Azure Firewall Premium na VNet do hub para inspeção centralizada de tráfego (incluindo IDPS e inspeção TLS). Usar Rotas Definidas pelo Usuário (UDRs) para forçar o tunelamento de tráfego dos spokes. Usar NSGs para microssegmentação dentro dos spokes. Habilitar o Azure DDoS Protection no hub.

Por quê: Esta arquitetura em camadas fornece defesa em profundidade: proteção centralizada contra ameaças no hub, microssegmentação nos spokes e proteção contra ataques volumétricos na borda.

Referência↗

Arquitetando para evitar que um invasor se mova de uma workstation comprometida para servidores críticos (Tier 0).

→Implementar o modelo de administração em camadas. Usar contas separadas e dedicadas e Workstations de Acesso Privilegiado (PAWs) para diferentes camadas de administração (Tier 0, 1, 2). Impor que as credenciais do Tier 0 nunca sejam usadas em sistemas de camada inferior.

Por quê: Isso cria limites de isolamento de credenciais, tornando impossível que o roubo de credenciais em um ativo de camada inferior (como uma workstation de usuário) leve ao comprometimento de um ativo de camada superior (como um controlador de domínio).

Protegendo um ambiente de Tecnologia Operacional (OT) com dispositivos legados que não podem executar agentes de segurança.

→Implantar o Microsoft Defender for IoT usando sensores de rede passivos e sem agente. Implementar a segmentação de rede baseada no modelo Purdue para criar uma DMZ entre TI e OT. Integrar alertas do Defender for IoT no Microsoft Sentinel.

Por quê: O monitoramento passivo de rede oferece visibilidade sobre protocolos e ameaças específicas de OT sem impactar sistemas industriais legados e sensíveis. A segmentação contém ameaças e controla os fluxos de dados de TI/OT.

Projetando segurança em profundidade para cargas de trabalho do Azure Kubernetes Service (AKS).

→Combinar o Microsoft Defender for Containers (verificação de registro, detecção de ameaças em tempo de execução) com o Azure Policy para AKS (controle de admissão para impor padrões de segurança como nenhum contêiner privilegiado) e políticas de rede (para microssegmentação pod-a-pod).

Por quê: A segurança de contêineres requer uma abordagem multicamadas: "shift-left" no registro, guardrails preventivos na implantação (controle de admissão), isolamento de rede em tempo de execução e detecção de ameaças em tempo de execução.

Referência↗

Projetando conectividade altamente segura e performática entre datacenters on-premises e Azure.

→Usar ExpressRoute com peering privado como conexão principal, com uma VPN site-a-site como backup de failover. Habilitar criptografia MACsec ou IPsec sobre ExpressRoute. Usar Private Endpoints para acessar serviços Azure PaaS.

Por quê: O ExpressRoute fornece uma conexão privada e dedicada, ignorando a internet pública. Os Private Endpoints garantem que o tráfego PaaS também permaneça fora da internet. A criptografia sobre ExpressRoute oferece defesa em profundidade.

Projetando segurança máxima para uma conta de Armazenamento do Azure contendo dados sensíveis.

→Desabilitar o acesso público e anônimo. Usar Private Endpoints para acesso à rede. Usar identidades gerenciadas para autenticação de aplicativos. Impor criptografia com chaves gerenciadas pelo cliente (CMK). Habilitar o Microsoft Defender for Storage para detecção de ameaças.

Por quê: Esta abordagem em camadas aborda todos os principais vetores de segurança: exposição da rede (Private Endpoints), gerenciamento de credenciais (identidades gerenciadas), controle de criptografia (CMK) e ameaças em tempo de execução (Defender for Storage).

Aplicando gerenciamento de segurança e governança consistentes a servidores on-premises e multicloud.

→Integrar os servidores ao Azure Arc. Isso estende o plano de controle do Azure, permitindo o gerenciamento via Microsoft Defender for Cloud (CSPM/CWP), aplicação do Azure Policy (incluindo configuração de convidado) e uso de serviços como o Update Management.

Por quê: O Azure Arc é a tecnologia fundamental para criar um único plano de gerenciamento e segurança em um ambiente de servidores híbrido e multicloud.

Referência↗

Protegendo o acesso de trabalhadores remotos tanto a aplicativos de internet/SaaS quanto a aplicativos corporativos privados.

→Implementar o Global Secure Access da Microsoft. Usar o Microsoft Entra Internet Access como um Secure Web Gateway (SWG) para tráfego SaaS/internet. Usar o Microsoft Entra Private Access como uma solução Zero Trust Network Access (ZTNA) para substituir VPNs tradicionais.

Por quê: Isso fornece uma solução SSE unificada e centrada na identidade que aplica políticas de segurança consistentes, independentemente da localização do usuário ou do tipo de recurso, alinhando-se aos princípios modernos do Zero Trust.

Projetando proteção abrangente para máquinas virtuais do Azure.

→Habilitar o Microsoft Defender for Servers Plano 2, que inclui o Defender for Endpoint (EDR). Usar o acesso Just-in-Time (JIT) à VM para fechar as portas de gerenciamento por padrão. Usar o Azure Bastion para acesso administrativo seguro e baseado em intermediário, sem IPs públicos.

Por quê: Isso fornece defesa em camadas: JIT e Bastion reduzem a superfície de ataque, enquanto o Defender for Servers oferece detecção e resposta avançadas a ameaças (EDR) para a própria carga de trabalho.

Protegendo dados altamente sensíveis enquanto estão sendo processados (dados em uso) contra acesso privilegiado, incluindo administradores de nuvem.

→Usar VMs do Azure Confidential Computing (por exemplo, baseadas em AMD SEV-SNP) ou contêineres confidenciais no AKS. Isso cria um Ambiente de Execução Confiável (TEE) baseado em hardware, onde dados e código são criptografados e isolados durante a execução.

Por quê: A computação confidencial aborda o estado final dos dados (em uso) não coberto por criptografia em repouso ou em trânsito, fornecendo proteção mesmo contra o hipervisor e o sistema operacional do host.

Fortalecendo um ambiente complexo de Active Directory on-premises contra ataques direcionados.

→Priorizar a implementação do modelo de administração em camadas para prevenir o movimento lateral. Implantar o grupo de segurança Usuários Protegidos e silos de política de autenticação para proteger contas privilegiadas contra ataques de roubo de credenciais (por exemplo, Pass-the-Hash).

Por quê: Esses controles abordam os vetores de ataque AD mais comuns e impactantes: movimento lateral e roubo de credenciais. Eles são mais críticos do que medidas gerais de fortalecimento como a assinatura LDAP.

Implementando acesso privilegiado Zero Trust para administradores do Azure e Microsoft Entra ID.

→Implantar o Microsoft Entra Privileged Identity Management (PIM). Converter todas as atribuições privilegiadas permanentes para "elegíveis". Configurar ativação limitada por tempo, fluxos de trabalho de aprovação para funções críticas e revisões de acesso obrigatórias.

Por quê: O PIM é o serviço principal da Microsoft para implementar o acesso Just-in-Time (JIT) e o privilégio mínimo para funções do Azure/Entra, eliminando o risco significativo do acesso privilegiado permanente.

Referência↗

Projetando uma estrutura de política de Acesso Condicional escalável e gerenciável.

→Implementar uma estrutura em camadas com políticas de linha de base para todos os usuários, políticas aprimoradas para aplicativos sensíveis e políticas rigorosas para acesso privilegiado. Usar sinais como localizações nomeadas e conformidade de dispositivos para reduzir o atrito em cenários confiáveis.

Por quê: Uma política única e monolítica é inviável. Uma abordagem em camadas ajusta a força do controle ao nível de risco, proporcionando segurança robusta onde necessário sem criar atrito indevido para tarefas diárias.

Automatizando e governando o ciclo de vida completo da identidade (entrada, movimentação, saída).

→Usar o Microsoft Entra ID Governance. Implementar provisionamento impulsionado por RH, Fluxos de Trabalho de Ciclo de Vida do Entra ID para automação, Gerenciamento de Direitos para pacotes de acesso (agrupando permissões para funções) e Revisões de Acesso regulares para atestação.

Por quê: Isso fornece uma solução de governança automatizada e completa que garante que o acesso seja concedido corretamente, modificado com mudanças de função e revogado prontamente após o desligamento, abordando o risco de contas inativas e escalada de privilégios.

Gerenciando acesso seguro para diferentes tipos de usuários externos (parceiros, clientes).

→Usar a colaboração Microsoft Entra B2B para parceiros e contratados, governada por políticas de acesso entre tenants. Usar o Microsoft Entra B2C para aplicações voltadas para clientes, fornecendo um diretório separado e escalável com jornadas de usuário personalizáveis.

Por quê: B2B e B2C são construídos especificamente para diferentes cenários de identidade externa. Usar a ferramenta certa evita problemas de segurança e escalabilidade que surgem ao tratar todos os usuários externos da mesma forma (por exemplo, criar contas internas para eles).

Protegendo dados sensíveis de forma consistente em Microsoft 365 e Azure.

→Implantar o Microsoft Purview Information Protection. Usar classificação automatizada (tipos de informações sensíveis, classificadores treináveis) para aplicar rótulos de sensibilidade. Configurar rótulos para impor proteção (criptografia, restrições de acesso) aos dados onde quer que eles residam.

Por quê: A proteção centrada em dados segue os próprios dados. A classificação automatizada em escala é a única maneira viável de garantir rotulagem e proteção consistentes em um grande patrimônio de dados.

Protegendo APIs internas e externas contra ameaças comuns.

→Implantar o Azure API Management como um gateway unificado. Impor autenticação forte com OAuth 2.0. Configurar políticas para limitação de taxa e validação de solicitação. Habilitar o Microsoft Defender for APIs para detecção de ameaças em tempo de execução.

Por quê: A segurança de API requer um gateway para atuar como um ponto de aplicação de política. A combinação de controles preventivos (políticas APIM) com controles de detecção (Defender for APIs) oferece defesa em profundidade contra ataques específicos de API.

Integrando segurança em um pipeline de CI/CD para encontrar vulnerabilidades cedo ("shift-left").

→Implementar o GitHub Advanced Security (ou Defender for DevOps). Integrar SAST automatizado (verificação de código), verificação de dependências (SCA) e verificação de segredos diretamente no pipeline de CI e no processo de pull request. Usar gates de segurança para bloquear builds com vulnerabilidades críticas.

Por quê: A varredura automatizada dentro do fluxo de trabalho do desenvolvedor fornece feedback rápido, permitindo que as vulnerabilidades sejam corrigidas cedo, quando é mais barato fazê-lo, sem criar um gargalo em uma revisão de segurança pré-produção.

Projetando uma solução segura e gerenciável para segredos, chaves e certificados de aplicações.

→Usar o Azure Key Vault. Isolar cofres por aplicação ou limite de segurança. Usar identidades gerenciadas para recursos do Azure para acessar o cofre (sem credenciais armazenadas). Habilitar soft-delete e proteção contra purga. Monitorar com o Defender for Key Vault.

Por quê: O Key Vault fornece um armazenamento de segredos centralizado, com suporte de hardware e auditável. O uso de identidades gerenciadas é o componente crítico que elimina o problema do "segredo zero" de como proteger as credenciais usadas para acessar o próprio cofre.

Implementando segurança em camadas para um banco de dados Azure SQL sensível.

→Combinar Transparent Data Encryption (TDE) com chaves gerenciadas pelo cliente (CMK), Always Encrypted para colunas sensíveis específicas, mascaramento dinâmico de dados para usuários não privilegiados, Microsoft Defender for SQL para detecção de ameaças e autenticação apenas do Azure AD.

Por quê: Nenhum controle único é suficiente. Esta abordagem em camadas protege dados em repouso (TDE), em uso (Always Encrypted), de visualização não autorizada (mascaramento), de ameaças (Defender) e garante autenticação forte (Azure AD).

Prevenindo a perda de dados em e-mail, Teams, SharePoint e dispositivos endpoint.

→Implantar o Microsoft Purview DLP. Criar políticas unificadas que se aplicam a serviços M365 e endpoints. Alinhar regras DLP com rótulos de sensibilidade. Usar o Endpoint DLP para controlar ações em dispositivos gerenciados (por exemplo, bloquear cópia para USB).

Por quê: Um motor de política unificado garante a aplicação consistente em todos os canais de dados. O Endpoint DLP é fundamental para estender a proteção além da nuvem para o próprio dispositivo do usuário.

Preparando o ambiente de dados de uma organização para a implantação segura do Copilot para Microsoft 365.

→Antes da implantação, focar na governança da informação. Usar ferramentas como SharePoint Advanced Management para encontrar e remediar sites e arquivos compartilhados em excesso. Garantir que uma estratégia robusta de classificação de dados e rotulagem de sensibilidade esteja em vigor e aplicada.

Por quê: O Copilot respeita as permissões existentes. Sua capacidade de apresentar informações rapidamente torna os problemas preexistentes de compartilhamento excessivo um risco crítico. "Organizar sua casa de dados" é um pré-requisito para a implantação segura de IA.

Projetando segurança abrangente para uma aplicação web crítica para os negócios.

→Usar o Azure Application Gateway com Web Application Firewall (WAF) em modo de prevenção. Integrar a varredura SAST/DAST no pipeline de CI/CD. Habilitar o Microsoft Defender for App Service para monitoramento em tempo de execução. Colocar o App Service em um Private Endpoint.

Por quê: Isso oferece proteção em múltiplas camadas: na borda (WAF), no código (SAST/DAST), na plataforma (Defender) e na rede (Private Endpoint), abordando uma ampla gama de ameaças a aplicações web.

Projetando autenticação para microsserviços no AKS acessarem uns aos outros e serviços Azure PaaS sem credenciais armazenadas.

→Implementar o Azure AD Workload Identity para permitir que pods do Kubernetes adquiram tokens do Azure AD. Usar uma malha de serviço (por exemplo, Istio, Linkerd) para impor TLS mútuo (mTLS) para toda a comunicação serviço-a-serviço dentro do cluster.

Por quê: Este padrão elimina completamente segredos de longa duração (senhas, chaves) do ambiente da aplicação, melhorando significativamente a postura de segurança. O Workload Identity lida com a autenticação norte-sul para o Azure, enquanto o mTLS lida com a autenticação leste-oeste dentro do cluster.

Atendendo a requisitos de conformidade rigorosos (por exemplo, FIPS 140-2 Nível 3) para armazenamento de chaves criptográficas.

→Usar o Azure Key Vault Managed HSM. Isso fornece um HSM dedicado, de locatário único e validado FIPS 140-2 Nível 3 que é totalmente gerenciado pela Microsoft, mas dá ao cliente controle total sobre o domínio de segurança.

Por quê: Para o mais alto nível de conformidade e controle de chaves, o Managed HSM é necessário em vez das camadas padrão/premium do Key Vault, que usam HSMs compartilhados e multi-tenant (FIPS 140-2 Nível 2).

Protegendo o processo de desenvolvimento de aplicações contra ameaças como dependências comprometidas ou injeção de código malicioso.

→Projetar um pipeline seguro usando registros de pacotes privados (por exemplo, Azure Artifacts), varredura de dependências (SCA), geração de Software Bill of Materials (SBOM), assinatura de artefatos e verificação de proveniência.

Por quê: Isso aborda múltiplas etapas da cadeia de suprimentos: controle de entradas (registro privado), validação de componentes (SCA, SBOM) e garantia da integridade das saídas (assinatura, proveniência).