Guia

Fornecer acesso just-in-time (JIT) a funções privilegiadas do Azure AD, exigindo aprovação e justificativa.

→Configure o Microsoft Entra Privileged Identity Management (PIM) para a função. Defina "Exigir aprovação para ativar", especifique os aprovadores, habilite "Exigir justificativa na ativação" e defina uma duração máxima de ativação.

Por quê: O PIM é o serviço nativo do Azure para elevação de função JIT. Simplesmente tornar um usuário elegível não é suficiente; as configurações da política impõem o fluxo de trabalho de aprovação e justificativa.

Referência↗

Impor MFA e um dispositivo compatível para todos os usuários que acessam aplicativos sensíveis, mas isentar um grupo específico de help desk da regra de conformidade do dispositivo.

→Crie duas políticas de Acesso Condicional (CA). A Política 1 visa "Todos os Usuários", excluindo o grupo de help desk, exigindo MFA e um dispositivo compatível. A Política 2 visa apenas o grupo de help desk, exigindo apenas MFA.

Por quê: Uma única política com uma exclusão removeria todos os requisitos para o grupo excluído. Duas políticas direcionadas garantem que cada grupo receba o conjunto correto e distinto de controles.

Referência↗

Responder automaticamente a riscos de identidade detectados: bloquear inícios de sessão de alto risco e forçar redefinições de senha para usuários de alto risco.

→Configure duas políticas de Proteção de Identidade do Microsoft Entra. Defina a "Política de risco de entrada" para Bloquear acesso em um nível de risco Alto. Defina a "Política de risco de usuário" para Exigir alteração de senha em um nível de risco Alto.

Por quê: O risco de entrada refere-se a uma única tentativa de autenticação (em tempo real), enquanto o risco de usuário é uma pontuação cumulativa sobre a própria identidade (credenciais comprometidas). Eles exigem ações de remediação diferentes.

Permitir que usuários em um ambiente de identidade híbrida redefinam sua senha na nuvem e a sincronizem de volta com o Active Directory local.

→No Microsoft Entra Connect, habilite o recurso "Password writeback". No Azure AD, habilite e configure a Redefinição de Senha de Autoatendimento (SSPR) para os usuários alvo.

Por quê: O SSPR fornece a interface de usuário na nuvem para redefinição de senha, enquanto o Password Writeback é o componente no Entra Connect que sincroniza o novo hash de senha de volta para o AD local.

Revisar periodicamente todo o acesso de usuários convidados e remover automaticamente os convidados que não são mais aprovados ou estão inativos.

→Crie uma Revisão de Acesso no Microsoft Entra ID Governance. Direcione usuários convidados em todos os grupos, defina um agendamento recorrente (por exemplo, trimestral) e habilite "Aplicar resultados automaticamente ao recurso". Opcionalmente, revise usuários inativos.

Por quê: As Revisões de Acesso são a ferramenta de governança dedicada para a recertificação periódica do acesso. O recurso "Aplicar resultados automaticamente" é crítico para fechar o ciclo e automatizar a remoção.

Fornecer aos parceiros externos uma forma de autoatendimento para solicitar um pacote de acesso (grupos, aplicativos, sites do SharePoint) que expira automaticamente após 90 dias.

→Use o Microsoft Entra Entitlement Management. Crie uma Organização Conectada para o parceiro. Crie um Pacote de Acesso contendo os recursos. Defina uma política para o pacote que permite que usuários da organização conectada o solicitem, com uma expiração de 90 dias.

Por quê: O Entitlement Management é projetado para governar o acesso em escala, especialmente para usuários externos. Ele agrupa recursos e automatiza todo o ciclo de vida do acesso, desde a solicitação e aprovação até a expiração e remoção.

Uma aplicação de alta segurança exige que os usuários se autentiquem com um método resistente a ataques de phishing e man-in-the-middle.

→Imponha métodos de autenticação como chaves de segurança FIDO2 ou Windows Hello for Business. Esses métodos usam criptografia de chave pública e estão vinculados ao dispositivo, impedindo o roubo de credenciais.

Por quê: Métodos como SMS, chamadas de voz ou notificações push simples são suscetíveis a phishing. FIDO2 e WHfB usam desafios criptográficos que estão ligados à origem da solicitação, tornando-os resistentes a phishing.

Um serviço em segundo plano executado em uma VM precisa ler todos os perfis de usuário do Microsoft Graph sem qualquer interação do usuário.

→Registre o aplicativo no Microsoft Entra ID. Em permissões de API, conceda a ele permissões "Application" do Microsoft Graph (não "Delegated") para `User.Read.All`. Um administrador deve conceder consentimento de administrador.

Por quê: As permissões de aplicação permitem que o aplicativo atue como ele mesmo, usando sua própria identidade (ID do cliente/segredo ou certificado). As permissões delegadas exigem um contexto de usuário conectado, que não está disponível em um aplicativo daemon não interativo.

Permitir que um pod em um cluster AKS acesse com segurança o Azure Key Vault sem usar credenciais armazenadas, como segredos de cliente ou certificados.

→Use o Azure AD Workload Identity. Crie uma identidade gerenciada atribuída pelo usuário, estabeleça uma credencial de identidade federada entre a conta de serviço K8s e a identidade gerenciada, e conceda à identidade gerenciada acesso ao Key Vault.

Por quê: O Workload Identity usa federação OIDC para trocar um token Kubernetes por um token Azure AD, eliminando completamente a necessidade de armazenar, gerenciar ou rotacionar segredos no cluster.

Referência↗

Proteger um Azure Key Vault para permitir acesso apenas de VNets específicas, registrar todas as operações e proteger contra a exclusão acidental de chaves críticas.

→Configure o firewall do Key Vault para permitir acesso de "Ponto de extremidade privado e redes selecionadas". Habilite o log de diagnóstico para um espaço de trabalho do Log Analytics. Habilite tanto a Exclusão Suave (Soft Delete) quanto a Proteção contra Limpeza (Purge Protection).

Por quê: A Exclusão Suave permite a recuperação de exclusões acidentais, mas a Proteção contra Limpeza impede que mesmo um usuário privilegiado exclua permanentemente o cofre ou seu conteúdo durante o período de retenção. Esta combinação é crítica para proteger chaves TDE.

Um Azure App Service precisa autenticar-se no Banco de Dados SQL do Azure para recuperar dados, sem armazenar senhas de string de conexão na configuração.

→Habilite uma identidade gerenciada atribuída ao sistema no App Service. No Azure SQL, crie um usuário contido mapeado para o nome da identidade gerenciada do App Service e conceda-lhe as funções de banco de dados necessárias (por exemplo, db_datareader).

Por quê: A Managed Identity fornece uma identidade para o próprio recurso do Azure no Azure AD. O Azure lida com a criação e rotação de credenciais automaticamente, eliminando segredos armazenados, o que é uma prática recomendada de segurança importante.

Criptografar discos gerenciados de VM do Azure em repouso usando uma chave que sua organização controla no Azure Key Vault.

→Crie um recurso de Conjunto de Criptografia de Disco. Configure-o para usar uma chave gerenciada pelo cliente (CMK) do seu Azure Key Vault. Atribua o Conjunto de Criptografia de Disco aos discos gerenciados da VM.

Por quê: Esta é a Criptografia do Lado do Servidor (SSE) com CMK, que criptografa dados na infraestrutura de armazenamento. É mais simples que o Azure Disk Encryption (ADE), que usa BitLocker/dm-crypt para criptografar dados dentro do sistema operacional convidado e é geralmente usado para discos de SO e dados juntos.

Garantir que as imagens de contêiner armazenadas no Azure Container Registry (ACR) sejam verificadas quanto a vulnerabilidades antes de serem implantadas.

→Habilite o Microsoft Defender for Containers. Isso verificará automaticamente as imagens no ACR quando forem enviadas, quando forem puxadas e de forma contínua para novas vulnerabilidades descobertas.

Por quê: Esta prática de segurança "shift-left" identifica vulnerabilidades precocemente no pipeline de CI/CD. O Defender for Containers fornece essa capacidade de varredura nativamente dentro do ecossistema do Azure.

Detectar e receber alertas para potenciais ataques de injeção de SQL e padrões de acesso anômalos em um Banco de Dados SQL do Azure.

→Habilite o Microsoft Defender for SQL no servidor SQL lógico. Isso oferece proteção avançada contra ameaças e avaliação de vulnerabilidades.

Por quê: O Defender for SQL é o plano de proteção de carga de trabalho dedicado que usa análise comportamental e aprendizado de máquina para detectar ameaças como injeção de SQL, ataques de força bruta e acesso incomum a dados, que não são visíveis para ferramentas de nível de rede.

Restringir uma conta de armazenamento a uma VNet específica, mas ainda permitir que serviços Microsoft confiáveis como o Azure Backup a acessem.

→Nas configurações de rede da conta de armazenamento, selecione "Habilitado de redes virtuais e endereços IP selecionados". Adicione a VNet/sub-rede necessária. Em seguida, marque a caixa "Permitir que serviços Microsoft confiáveis acessem esta conta de armazenamento".

Por quê: A exceção de serviços confiáveis cria um caminho seguro para serviços Microsoft específicos ignorarem as regras do firewall da VNet. Sem ela, serviços que operam em nome do usuário (como Backup ou Portal) seriam bloqueados.

Proteger colunas de dados sensíveis específicas (por exemplo, números de cartão de crédito) em um banco de dados Azure SQL, mesmo de administradores de banco de dados (DBAs) privilegiados.

→Use Always Encrypted. O driver da aplicação cliente criptografa transparentemente os dados antes de enviá-los ao banco de dados, e as chaves de criptografia nunca são reveladas ao motor do banco de dados.

Por quê: A Criptografia Transparente de Dados (TDE) criptografa todo o banco de dados em repouso (em disco), mas um DBA com acesso ainda pode ver os dados. O Always Encrypted fornece criptografia do lado do cliente, separando aqueles que gerenciam os dados (DBAs) daqueles que podem vê-los.

Processar dados altamente sensíveis em uma VM do Azure, garantindo que permaneçam criptografados e protegidos mesmo na memória contra o hypervisor e operadores de nuvem.

→Implante uma VM Confidencial do Azure. Essas VMs usam Ambientes de Execução Confiáveis (TEEs) baseados em hardware, como AMD SEV-SNP, para criar um espaço de memória isolado e criptografado.

Por quê: A criptografia padrão de VM (como ADE ou SSE) protege os dados em repouso. A Computação Confidencial é a única tecnologia que protege os dados *em uso* na memória, fornecendo o mais alto nível de privacidade e isolamento de dados na nuvem.

Um App Service precisa usar um segredo do Key Vault como uma configuração de aplicativo, sem alterar o código do aplicativo para usar o SDK do Key Vault.

→Habilite a identidade gerenciada no App Service e conceda a ela permissões de "Obter" em segredos no Key Vault. Na configuração do App Service, crie uma configuração de aplicativo com o valor formatado como uma referência de Key Vault: `@Microsoft.KeyVault(SecretUri=...)` .

Por quê: Este recurso permite que a plataforma do App Service resolva o valor secreto em tempo de execução usando a identidade gerenciada. O código do aplicativo simplesmente lê uma variável de ambiente padrão, abstraindo a interação com o Key Vault.

Armazenar dados relacionados à conformidade no Azure Blob Storage em um estado WORM (Write-Once, Read-Many) por um período de retenção de 7 anos.

→No contêiner de armazenamento, configure uma política de imutabilidade. Use uma política de retenção baseada em tempo definida para 7 anos e bloqueie a política. Uma vez bloqueados, os dados não podem ser modificados ou excluídos por ninguém até que o período de retenção expire.

Por quê: Este recurso é especificamente projetado para atender aos requisitos de conformidade regulatória (por exemplo, SEC 17a-4). Bloquear a política é o passo crítico que a torna verdadeiramente imutável.

Em uma aplicação multi-tenant usando um único banco de dados Azure SQL, garanta que usuários de um tenant possam ver apenas dados pertencentes ao seu próprio tenant.

→Implemente a Segurança em Nível de Linha (RLS). Crie uma política de segurança com uma função predicado que filtra as linhas com base no ID do tenant do usuário, que é armazenado no contexto da sessão ou em uma tabela de pesquisa de usuário.

Por quê: A RLS impõe a lógica de acesso diretamente no motor do banco de dados. Isso é mais seguro e confiável do que implementar a filtragem na camada de aplicação, pois não pode ser contornado e é transparente para o código da aplicação.

Proteger VMs de Geração 2 contra boot kits e rootkits, garantindo a integridade de toda a cadeia de inicialização, do UEFI ao kernel do SO.

→Provisione a VM com o Trusted Launch habilitado. Isso ativa o Secure Boot, que valida a assinatura de todos os componentes de inicialização, e um Módulo de Plataforma Confiável virtual (vTPM) para inicialização medida e atestado.

Por quê: O Trusted Launch aborda malwares sofisticados de baixo nível que podem subverter os controles de segurança tradicionais no nível do SO. Ele estabelece uma raiz de confiança de hardware para a VM.

Isolar o tráfego entre as camadas de aplicação (web, app, dados) hospedadas em sub-redes separadas.

→Crie um Grupo de Segurança de Rede (NSG) dedicado para cada sub-rede. Em cada NSG, crie regras de entrada que permitam apenas o tráfego do intervalo de IP de origem da camada anterior na porta necessária. (por exemplo, NSG da camada de aplicativo permite TCP/8080 da sub-rede da camada Web).

Por quê: Aplicar um NSG exclusivo e de menor privilégio a cada sub-rede oferece defesa em profundidade e controle granular sobre os fluxos de tráfego leste-oeste, o que é mais seguro do que um único e complexo NSG para a VNet.

Em uma topologia hub-spoke, forçar todo o tráfego entre as VNets spoke a ser inspecionado por um NVA ou Azure Firewall no hub.

→Em cada sub-rede spoke, crie uma Rota Definida pelo Usuário (UDR) para os espaços de endereço das outras spokes com o tipo de próximo salto definido como "VirtualAppliance" e o IP do NVA/Firewall. Habilite o Encaminhamento de IP na NIC do NVA.

Por quê: Por padrão, o emparelhamento de VNet permite que as spokes se comuniquem diretamente. As UDRs anulam esse comportamento de roteamento padrão, forçando o tráfego para o ponto de inspeção central.

Fornecer um serviço PaaS (por exemplo, Azure SQL, Armazenamento) com um endereço IP privado dentro da sua VNet, garantindo que o tráfego nunca atravesse a internet pública.

→Crie um Private Endpoint para o serviço PaaS na sua VNet. Criticamente, nas configurações de rede do serviço PaaS, desabilite o acesso à rede pública para bloquear o endpoint público.

Por quê: Um Private Endpoint traz o serviço *para dentro* da sua VNet com um IP privado. Um Service Endpoint apenas otimiza a rota pela backbone do Azure para um IP público. Desabilitar o acesso público é necessário para impor a comunicação apenas privada.

Permitir o tráfego de saída de VMs para um conjunto dinâmico de endpoints de serviço da Microsoft, como o Windows Update, sem manter listas de IP manualmente.

→No Azure Firewall, crie uma coleção de Regras de Aplicativo. Adicione uma regra com o tipo de FQDN de destino definido como "FQDN Tag" e selecione a tag "WindowsUpdate".

Por quê: As FQDN Tags são coleções curadas de FQDNs que a Microsoft gerencia. Esta é a maneira correta de permitir o acesso a serviços PaaS cujos IPs subjacentes mudam frequentemente. As Service Tags são para regras baseadas em IP.

Um Firewall de Aplicação Web (WAF) está bloqueando o tráfego legítimo para sua aplicação devido a um falso positivo em uma regra gerenciada (por exemplo, injeção de SQL).

→Na política do WAF, mantenha o WAF no modo de Prevenção. Encontre a regra gerenciada que está bloqueando o tráfego e configure uma exclusão para o cabeçalho de requisição, cookie ou parâmetro de corpo específico que está causando o falso positivo.

Por quê: Exclusões são a maneira mais precisa de lidar com falsos positivos. Elas permitem que você mantenha a proteção da regra para todo o outro tráfego enquanto faz uma exceção específica, o que é mais seguro do que desabilitar a regra inteira.

Fornecer acesso RDP/SSH seguro a VMs do Azure sem expor portas de gerenciamento à internet ou exigir IPs públicos nas VMs.

→Implante o Azure Bastion (SKU Standard para recursos avançados) em uma sub-rede dedicada na VNet. Acesse as VMs através do portal do Azure, que se conecta pelo serviço Bastion.

Por quê: O Bastion atua como um jump box seguro, intermediando a conexão RDP/SSH. O único IP público está no próprio serviço Bastion, que é endurecido e gerenciado pela Microsoft, reduzindo drasticamente a superfície de ataque das suas VMs.

Fornecer aos desenvolvedores acesso limitado por tempo e auditado às portas de gerenciamento (RDP/SSH) em VMs de desenvolvimento.

→Habilite o Microsoft Defender for Cloud e configure o acesso Just-in-Time (JIT) à VM para as VMs. Os usuários solicitarão acesso através do Defender for Cloud, que modifica dinamicamente as regras do NSG para permitir o acesso por um tempo limitado de um IP específico.

Por quê: O JIT é um recurso central do Defender for Cloud que endurece a postura de rede das VMs, mantendo as portas de gerenciamento fechadas por padrão, abrindo-as apenas sob demanda.

Impor melhores práticas de segurança, como proibir contêineres privilegiados, em um cluster Azure Kubernetes Service (AKS) no momento da implantação.

→Habilite o complemento Azure Policy para AKS. Atribua a iniciativa de política integrada chamada "Padrões restritos de segurança de pod de cluster Kubernetes para cargas de trabalho baseadas em Linux".

Por quê: Isso aproveita o Azure Policy como um controlador de admissão centralizado e em escala para Kubernetes, impondo salvaguardas de segurança e conformidade antes mesmo que as cargas de trabalho sejam criadas no cluster.

Encaminhar todo o tráfego de saída para a internet de uma VNet do Azure de volta para um dispositivo de segurança local para inspeção antes que ele atinja a internet.

→Configure uma VPN site a site ou ExpressRoute. Crie uma Rota Definida pelo Usuário (UDR) para o prefixo de endereço 0.0.0.0/0 e defina o próximo salto como o Gateway de Rede Virtual.

Por quê: Este padrão, conhecido como tunelamento forçado, anula a rota padrão do Azure para a internet e força todo o tráfego de saída através do gateway para a rede local, garantindo que nenhuma VM possa ignorar os controles de segurança corporativos.

Inspecionar o tráfego de saída criptografado por TLS de VMs em busca de ameaças usando o Azure Firewall.

→Implante o Azure Firewall Premium. Habilite a Inspeção TLS e a Detecção de Intrusão (IDPS). Configure um certificado de CA subordinado no Firewall e implante sua chave pública nas VMs do cliente como uma CA raiz confiável.

Por quê: Para inspecionar o tráfego criptografado, o firewall deve realizar uma operação man-in-the-middle. Isso requer o SKU Premium, IDPS para detecção de ameaças e uma infraestrutura de certificado adequada para evitar erros TLS nas máquinas cliente.

Proteger todas as aplicações voltadas para o público em várias VNets e assinaturas contra ataques DDoS volumétricos de forma econômica.

→Crie um único Plano de Proteção contra DDoS do Azure. Associe este plano a todas as redes virtuais que contêm endereços IP públicos que precisam de proteção.

Por quê: Um único Plano de Proteção contra DDoS pode cobrir até 100 VNets, e você paga uma taxa mensal fixa pelo plano, não por VNet ou por IP. Este modelo centralizado é muito mais econômico do que implantar vários planos ou usar o SKU de proteção por IP.

Quando um incidente de alta gravidade é criado no Microsoft Sentinel, desabilitar automaticamente a conta de usuário envolvida no Azure AD e notificar a equipe de segurança no Teams.

→Crie uma Regra de Automação que é acionada na criação de incidentes de alta gravidade. A regra deve chamar um Playbook (Logic App). O playbook usa o conector do Azure AD para desabilitar o usuário e o conector do Teams para postar uma mensagem.

Por quê: Isso demonstra o padrão SOAR (Security Orchestration, Automation, and Response). A Regra de Automação é o motor de gatilho/condição, e o Playbook é o motor de ação/workflow.

Referência↗

Aplicar um conjunto consistente de políticas de segurança e habilitar planos do Defender for Cloud em um grande número de assinaturas do Azure.

→Organize todas as assinaturas sob um Grupo de Gerenciamento. Atribua a iniciativa de política Azure Security Benchmark e habilite os planos do Defender for Cloud necessários no nível do grupo de gerenciamento.

Por quê: Grupos de Gerenciamento são a ferramenta principal para governança em escala corporativa. As políticas e configurações aplicadas neste nível são herdadas por todas as assinaturas filhas, garantindo consistência e reduzindo a sobrecarga administrativa.

Criar uma detecção personalizada no Sentinel para um usuário que faz login de um novo país pela primeira vez.

→Crie uma regra de análise de consulta agendada. Use uma consulta KQL que une `SigninLogs` recentes com um histórico resumido de `SigninLogs` passados para identificar combinações de UserPrincipalName/País nunca vistas antes.

Por quê: Regras de consulta agendadas com KQL são a base da detecção de ameaças personalizada no Sentinel, permitindo lógica complexa e com estado que vai além da simples correspondência de eventos.

Reter logs de segurança no Sentinel por 2 anos para conformidade, mas manter apenas os 90 dias mais recentes disponíveis para consultas rápidas e interativas para gerenciar custos.

→No espaço de trabalho do Log Analytics, defina a "Retenção Interativa" para 90 dias. Defina a "Retenção Total" (Arquivo) para 730 dias (2 anos). Configure políticas de retenção por tabela, se necessário.

Por quê: Esta abordagem em camadas equilibra custo e capacidade. A camada interativa é cara, mas rápida. A camada de arquivo tem um custo muito baixo para armazenamento de longo prazo. Dados arquivados ainda podem ser consultados via Search Jobs assíncronos ou restaurados temporariamente.

Durante uma investigação de incidente, você precisa visualizar rapidamente as relações entre um usuário comprometido, o IP de onde ele fez login e os recursos que ele acessou.

→Na página de incidentes do Microsoft Sentinel, abra o Grafo de Investigação. Use o grafo para explorar visualmente entidades e suas conexões entre diferentes alertas e fontes de log.

Por quê: O Grafo de Investigação é uma ferramenta de visualização poderosa que mapeia a história do ataque, tornando muito mais fácil entender o escopo e a linha do tempo de um incidente do que correlacionar eventos manualmente em consultas de log.

Detectar um invasor que comprometeu uma conta de usuário e agora está tentando acessar recursos ou hosts incomuns dentro da rede.

→Garanta que a Análise de Comportamento de Usuários e Entidades (UEBA) esteja habilitada no Microsoft Sentinel e que as fontes de dados relevantes (logs do Azure AD, Defender for Endpoint/Eventos de Segurança) estejam conectadas. Monitore a UEBA para detecções de anomalias relacionadas a movimento lateral.

Por quê: A UEBA constrói uma linha de base de comportamento normal para cada usuário e entidade. Ela se destaca na detecção de desvios que indicam movimento lateral, como um usuário acessando um servidor pela primeira vez ou usando protocolos incomuns, que são difíceis de identificar com regras estáticas.

Reduzir os custos de ingestão do Microsoft Sentinel para logs de alto volume e verbosos que são necessários para conformidade, mas não para análise em tempo real.

→Configure o plano de tabela para esses logs como "Logs Básicos". Além disso, use Regras de Coleta de Dados (DCRs) com consultas XPath ou outras transformações para filtrar eventos ruidosos e de baixo valor antes da ingestão.

Por quê: Os Logs Básicos oferecem um custo de ingestão significativamente menor em troca de capacidades de consulta limitadas e retenção mais curta. Filtrar na origem com DCRs é a forma mais eficaz de reduzir o volume, impedindo que dados indesejados cheguem ao workspace.

Impor automaticamente uma configuração de segurança, como habilitar "Transferência segura necessária" em todas as contas de Armazenamento do Azure existentes e novas.

→Atribua uma Política do Azure com o efeito `DeployIfNotExists` ou `Modify`. Para recursos não conformes existentes, crie uma tarefa de remediação a partir do painel de conformidade da política para aplicar a alteração.

Por quê: As políticas de Auditoria e Negação apenas relatam ou bloqueiam a não conformidade. `DeployIfNotExists` e `Modify` com tarefas de remediação corrigem ativamente as configurações incorretas, tornando a política uma ferramenta poderosa para governança automatizada e endurecimento da segurança.

Detectar ameaças em tempo de execução em um cluster AKS, como execução de processo suspeita ou um contêiner conectando-se a um IP malicioso conhecido.

→Habilite o Microsoft Defender for Containers. Isso implanta um DaemonSet (agente Defender) em cada nó do cluster, que coleta sinais de segurança do host e dos contêineres para fornecer detecção de ameaças em tempo real.

Por quê: Enquanto a varredura ACR oferece segurança "shift-left", a proteção em tempo de execução é crucial para detectar ameaças que ocorrem após a implantação. O Defender for Containers oferece essa visibilidade no nível do host e da carga de trabalho dentro do cluster.