Aplicar os princípios do Zero Trust a uma rede virtual spoke com os Serviços PaaS do Azure
Este artigo ajuda você a aplicar os princípios do modelo de segurança Zero Trust a uma carga de trabalho PaaS usando redes virtuais (VNets) do Azure e pontos de extremidade privados das seguintes maneiras:
| Princípio Zero Trust | Definição | Cumprido por |
|---|---|---|
| Verificar explicitamente | Sempre autentique e autorize com base em todos os pontos de dados disponíveis. | Use a deteção de ameaças no Firewall do Azure e no Gateway de Aplicativo do Azure para validar o tráfego e verificar se o tráfego é aceitável. |
| Use o acesso menos privilegiado | Limite o acesso do usuário com Just-In-Time e Just-Enough-Access (JIT/JEA), políticas adaptativas baseadas em risco e proteção de dados. | Reduza a entrada e saída dos serviços do Azure para a sua rede privada. Use grupos de segurança de rede para permitir apenas a entrada específica da sua rede virtual. Use uma instância central do Firewall do Azure para conceder acesso de tráfego não VNet ao serviço do Azure. |
| Assuma a violação | Minimize o raio de jateamento e o acesso ao segmento. Verifique a criptografia de ponta a ponta e use análises para obter visibilidade, impulsionar a deteção de ameaças e melhorar as defesas. | Limite a comunicação desnecessária entre recursos. Certifique-se de que está a iniciar sessão a partir de grupos de segurança de rede e de que tem visibilidade adequada do tráfego anómalo. Controlar alterações em grupos de segurança de rede. |
Para obter mais informações sobre como aplicar os princípios de Zero Trust em um ambiente de IaaS do Azure, consulte a Visão geral de Aplicar princípios de Zero Trust ao Azure IaaS.
Rede autônoma ou spoke Zero Trust para serviços PaaS do Azure
Muitos serviços PaaS contêm sua própria funcionalidade de controle de entrada e saída nativa do serviço. Você pode usar esses controles para proteger o acesso à rede aos recursos de serviço PaaS sem a necessidade de infraestrutura, como redes virtuais. Por exemplo:
- O Banco de Dados SQL do Azure tem seu próprio firewall que pode ser usado para permitir endereços IP de clientes específicos que precisam acessar o servidor de banco de dados.
- As contas de armazenamento do Azure têm uma opção de configuração para permitir conexões de uma VNet específica ou bloquear o acesso à rede pública.
- O Serviço de Aplicativo do Azure dá suporte a restrições de acesso para definir uma lista de permissão/negação ordenada por prioridade que controla o acesso à rede ao seu aplicativo.
No entanto, para implementações guiadas pelo Zero Trust, esses controles de acesso nativos do serviço geralmente ficam aquém de serem suficientes. Isso cria uma difusão de controles de acesso e registro em log que pode aumentar o gerenciamento e diminuir a visibilidade.
Além disso, os serviços PaaS podem usar FQDN (nomes de domínio totalmente qualificados) que são resolvidos para um endereço IP público atribuído dinamicamente que é alocado a partir de um pool de endereços IP públicos em uma região específica para um tipo de serviço. Por isso, você não poderá permitir o tráfego de ou para um serviço PaaS específico usando seu endereço IP público, que pode mudar.
A Microsoft recomenda que você use pontos de extremidade privados. Um ponto de extremidade privado é uma interface VNet que usa um endereço IP privado da sua rede virtual. Esta interface de rede liga-o a um serviço de forma privada e segura com a tecnologia do Azure Private Link. Ao habilitar um ponto de extremidade privado, você traz o serviço para sua rede virtual.
Dependendo do cenário da solução, você ainda pode precisar de acesso público de entrada aos seus serviços de PaaS. Mas, a menos que o faça, a Microsoft recomenda que todo o tráfego permaneça privado para eliminar potenciais riscos de segurança.
Este guia fornece instruções para uma arquitetura de referência específica, mas os princípios e métodos podem ser aplicados a outras arquiteturas, conforme necessário.
Arquitetura de referência
O diagrama a seguir mostra uma arquitetura de referência comum para cargas de trabalho baseadas em PaaS.
No diagrama:
- Uma VNet spoke inclui componentes para suportar um aplicativo PaaS.
- O aplicativo PaaS é um aplicativo de duas camadas que aproveita os Serviços de Aplicativo do Azure para um aplicativo Web/front-end e um Banco de Dados SQL do Azure para bancos de dados relacionais.
- Cada camada está contida em uma sub-rede dedicada para entrada com um grupo de segurança de rede dedicado.
- A camada da Web contém uma sub-rede dedicada para saída.
- O acesso ao aplicativo é fornecido por meio de um Application Gateway contido em sua própria sub-rede.
O diagrama a seguir mostra a arquitetura lógica desses componentes em uma assinatura do Azure.
No diagrama, todos os componentes da VNet spoke estão contidos em um grupo de recursos dedicado:
- Uma VNet
- Um Gateway de Aplicativo do Azure (GW de Aplicativo), incluindo um Firewall de Aplicativo Web (WAF)
- Três grupos de segurança de rede (nomeados com "NSG" no diagrama) para as camadas de banco de dados, aplicativo e front-end
- Dois grupos de segurança de aplicativos (nomeados com "ASG" no diagrama)
- Dois pontos finais privados
Além disso, os recursos para a VNet do hub são implantados na assinatura de conectividade apropriada.
O que contém este artigo
Os princípios de Zero Trust são aplicados em toda a arquitetura, desde o nível de locatário e diretório até a atribuição de VMs a grupos de segurança de aplicativos. A tabela a seguir descreve as recomendações para proteger essa arquitetura.
| Passo | Tarefa |
|---|---|
| 1 | Aproveite o Microsoft Entra RBAC ou configure funções personalizadas para recursos de rede. |
| 2 | Isole a infraestrutura em seu próprio grupo de recursos. |
| 3 | Crie um grupo de segurança de rede para cada sub-rede. |
| 4 | Proteja o tráfego e os recursos dentro da rede virtual:
|
| 5 | Entrada e saída seguras para serviços PaaS do Azure. |
| 6 | Acesso seguro à rede virtual e ao aplicativo. |
| 7 | Habilite a deteção, alerta e proteção avançados de ameaças. |
Este guia pressupõe que você já tenha um Serviço de Aplicativo do Azure e o Banco de Dados SQL do Azure implantados em seus próprios grupos de recursos.
Etapa 1: Aproveitar o Microsoft Entra RBAC ou configurar funções personalizadas para recursos de rede
Você pode aproveitar as funções internas do Microsoft Entra RBAC para colaboradores de rede. No entanto, outra abordagem é aproveitar funções personalizadas. Os gerentes de rede Spoke VNet não precisam de acesso total aos recursos de rede concedidos pela função de Colaborador de Rede RBAC do Microsoft Entra, mas precisam de mais permissões do que outras funções comuns. Uma função personalizada pode ser usada para definir o escopo de acesso apenas ao que é necessário.
Uma maneira fácil de implementar isso é implantar as funções personalizadas encontradas na Arquitetura de Referência da Zona de Aterrissagem do Azure.
A função específica que pode ser usada é a função personalizada Gerenciamento de Rede, que tem as seguintes permissões:
- Leia tudo no âmbito
- Quaisquer ações com o provedor de rede
- Quaisquer ações com o provedor de suporte
- Quaisquer ações com o provedor de recursos
Essa função pode ser criada usando os scripts no repositório GitHub da Arquitetura de Referência da Zona de Aterrissagem do Azure ou pode ser criada por meio da ID do Microsoft Entra com funções personalizadas do Azure.
Etapa 2: Isolar a infraestrutura em seu próprio grupo de recursos
Ao isolar recursos de rede de recursos de computação, dados ou armazenamento, você reduz a probabilidade de sangria de permissões. Além disso, ao garantir que todos os recursos relacionados estejam em um grupo de recursos, você pode fazer uma atribuição de segurança e gerenciar melhor o registro em log e o monitoramento desses recursos.
Em vez de ter os recursos de rede spoke disponíveis em vários contextos em um grupo de recursos compartilhados, crie um grupo de recursos dedicado. O diagrama de arquitetura a seguir mostra essa configuração.
No diagrama, os recursos e componentes em toda a arquitetura de referência são divididos em grupos de recursos dedicados para serviços de aplicativos, bancos de dados SQL do Azure, contas de armazenamento, recursos de VNet de hub e recursos de VNet falado.
Com um grupo de recursos dedicado, você pode atribuir uma função personalizada usando o tutorial Conceder a um usuário acesso aos recursos do Azure usando o tutorial do portal do Azure.
Recomendações adicionais:
- Faça referência a um grupo de segurança para a função em vez de indivíduos nomeados.
- Gerencie o acesso ao grupo de segurança por meio de suas práticas de gerenciamento de identidade corporativa.
Se você não estiver usando políticas que imponham o encaminhamento de log em grupos de recursos, configure isso no log de atividades para o grupo de recursos:
- Encontre o grupo de recursos no portal do Azure.
- Navegue até Registro de atividades -> Exportar registros de atividades e selecione + Adicionar configuração de diagnóstico.
- Na tela Configuração de diagnóstico , selecione todas as categorias de log (especialmente Segurança) e envie-as para as fontes de log apropriadas, como um espaço de trabalho do Log Analytics para observabilidade ou uma conta de armazenamento para armazenamento de longo prazo. Eis um exemplo:
Consulte Configurações de diagnóstico para entender como revisar esses logs e alertá-los.
Democratização da subscrição
Embora não esteja diretamente relacionado à rede, você deve planejar sua assinatura RBAC de maneira semelhante. Além de isolar recursos logicamente por grupo de recursos, você também deve isolar a assinatura com base em áreas de negócios e proprietários de portfólio. A subscrição enquanto unidade de gestão deve ter um âmbito restrito.
Consulte os princípios de design da zona de aterrissagem do Azure para obter mais informações.
Etapa 3: Criar um grupo de segurança de rede para cada sub-rede
Os grupos de segurança de rede do Azure são usados para filtrar o tráfego de rede entre recursos do Azure em uma VNet do Azure. Recomenda-se aplicar um grupo de segurança de rede a cada sub-rede. Isso é imposto por padrão por meio da política do Azure ao implantar as Zonas de Aterrissagem do Azure. Os grupos de segurança de rede contêm regras de segurança que permitem ou negam o tráfego de entrada ou de saída de e para vários tipos de recursos do Azure. Para cada regra, você pode especificar endereços IP de origem e destino, um protocolo (como TCP ou UDP) e uma porta.
Para aplicativos de várias camadas, a recomendação é criar um grupo de segurança de rede dedicado ("NSG" no diagrama a seguir) para cada sub-rede que hospeda um componente de rede.
No diagrama:
- Cada camada do aplicativo tem uma sub-rede de entrada dedicada, como uma para a camada da Web e outra para a camada de dados.
- Os Serviços de Aplicativo do Azure têm uma sub-rede de saída dedicada para um serviço de aplicativo específico.
- Um grupo de segurança de rede é configurado para cada uma dessas sub-redes.
Configurar grupos de segurança de rede de uma maneira diferente do que no diagrama pode resultar na configuração incorreta de alguns ou todos os grupos de segurança de rede e pode criar problemas na solução de problemas. Também pode dificultar a monitorização e o registo.
Consulte Criar, alterar ou excluir um grupo de segurança de rede do Azure para gerenciar as configurações de seus grupos de segurança de rede.
Leia mais sobre Grupos de segurança de rede para entender como eles podem ser usados para proteger seus ambientes.
Etapa 4: Proteger o tráfego e os recursos dentro da rede virtual
Esta seção descreve as seguintes recomendações:
- Implantar regras de negação de linha de base para grupos de segurança de rede
- Implantar regras específicas do aplicativo
- Planejar o gerenciamento de tráfego na rede virtual
- Implantar o log de fluxo do grupo de segurança de rede
Implantar regras de negação de linha de base para grupos de segurança de rede
Um elemento-chave do Zero Trust é usar o menor nível de acesso necessário. Por padrão, os grupos de segurança de rede têm regras de permissão . Ao adicionar uma linha de base de regras de negação , você pode impor o menor nível de acesso. Uma vez provisionado, crie uma regra negar tudo em cada uma das regras de entrada e saída com uma prioridade de 4096. Esta é a última prioridade personalizada disponível, o que significa que você ainda tem o escopo restante para configurar as ações de permissão.
Para fazer isso, no grupo de segurança de rede, vá para Regras de Segurança de Saída e selecione Adicionar. Preencha o seguinte:
- Fonte: Qualquer
- Intervalo de portas de origem: *
- Destino: Qualquer
- Serviço: Personalizado
- Intervalos de portas de destino: *
- Protocolo: qualquer
- Ação: Negar
- Prioridade: 4096
- Nome: DenyAllOutbound
- Descrição: Nega todo o tráfego de saída, a menos que especificamente permitido.
Eis um exemplo.
Repita este processo com regras de entrada, ajustando o nome e a descrição conforme apropriado.
A guia Regras de segurança de entrada exibe o sinal de aviso na regra. Eis um exemplo.
Clique na regra e role até a parte inferior para ver mais detalhes. Eis um exemplo:
Esta mensagem dá os seguintes dois avisos:
- Os Balanceadores de Carga do Azure não poderão, por padrão, acessar recursos usando esse grupo de segurança de rede.
- Outros recursos nesta rede virtual não poderão, por padrão, acessar recursos usando esse grupo de segurança de rede.
Para o nosso propósito no Zero Trust, é assim que deve ser. Isso significa que só porque algo está nessa VNet, não significa que ela terá acesso imediato aos seus recursos. Para cada padrão de tráfego, crie uma regra que permita explicitamente e você deve fazê-lo com a menor quantidade de permissões.
Se você tiver conexões de saída específicas para gerenciamento, como controladores de domínio dos Serviços de Domínio Ative Directory (AD DS), VMs DNS privadas ou sites externos específicos, elas precisarão ser controladas aqui.
Regras alternativas de negação
Nota
As recomendações nesta secção aplicam-se apenas à sub-rede de saída da Web.
Se você estiver usando o Firewall do Azure para gerenciar suas conexões de saída, em vez de executar um deny-outbound-all, poderá criar regras alternativas para conexões de saída. Como parte da implementação do Firewall do Azure, você configura uma tabela de rotas que envia tráfego de rota padrão (0.0.0.0/0) para o firewall. Isso lidará com o tráfego fora da rede virtual.
Em seguida, você pode criar uma regra de saída negar todas as VNet ou uma regra permitir todas as saídas, mas proteger os itens com suas regras de entrada.
Consulte Firewall do Azure e Tabelas de Rotas para entender como elas podem ser usadas para aumentar ainda mais a segurança do ambiente.
Implantar regras específicas do aplicativo
Defina padrões de tráfego com a menor quantidade de permissões e seguindo apenas caminhos explicitamente permitidos. Usando sub-redes como fontes, defina padrões de rede nos grupos de segurança de rede. Eis um exemplo.
Use o processo Gerenciar grupos de segurança de rede: crie um processo de regra de segurança para adicionar regras aos seus grupos de segurança de rede.
Para proteger esse cenário, adicione as seguintes regras:
| Grupo de segurança de rede para Sub-rede | Direção | Origem | Detalhes da origem | Porta de origem | Destino | Detalhes do destino | Serviço | Nome do grupo de segurança de rede | Descrição do grupo de segurança de rede |
|---|---|---|---|---|---|---|---|---|---|
| Sub-rede do Serviço de Aplicativo | Interna | Endereços IP | Intervalo de endereços IP privados da sub-rede do Application Gateway | 443 | Endereços IP | O endereço IP explícito do ponto de extremidade privado do Serviço de Aplicativo | MS SQL | AllowGWtoAppInbound | Permite acesso de entrada ao Serviço de Aplicativo a partir do Gateway de Aplicativo. |
| Sub-rede de integração do Serviço de Aplicativo | De Saída | Endereços IP | Intervalo de endereços IP da sub-rede de integração do serviço de aplicativo | 1433 | Endereços IP | O endereço IP explícito do ponto de extremidade privado do seu banco de dados SQL | MS SQL | AllowApptoSQLDBOutbound | Permite o acesso de saída ao ponto de extremidade privado SQL a partir da sub-rede de Integração do Serviço de Aplicativo. |
| Sub-rede SQL do Azure | Interna | Endereços IP | Intervalo de endereços IP da sub-rede de integração do serviço de aplicativo | 1433 | Endereços IP | O endereço IP explícito do ponto de extremidade privado do seu banco de dados SQL | MS SQL | AllowApptoSQLDBInbound | Permite acesso de entrada ao ponto de extremidade privado SQL a partir da sub-rede de Integração do Serviço de Aplicativo. |
Nota
Às vezes, o tráfego de origem pode vir de portas diferentes e, se esse padrão ocorrer, você pode adicionar intervalos de portas de origem a "*" para permitir qualquer porta de origem. A porta de destino é mais significativa, e algumas recomendações são sempre usar "*" para a porta de origem.
Nota
Para prioridade, use um valor entre 100 e 4000. Você pode começar em 105.
Isso é adicional às regras do grupo de segurança de rede em sua sub-rede do Application Gateway.
Com essas regras, você definiu o padrão de conectividade Zero Trust para uma única camada de aplicativo. Você pode repetir esse processo conforme necessário para fluxos adicionais.
Planejar o gerenciamento de tráfego na rede virtual
Além do tráfego específico do aplicativo, planeje o gerenciamento de tráfego. No entanto, como o tráfego de gerenciamento normalmente se origina fora da VNet falada, mais regras são necessárias. Primeiro, entenda os portos e as fontes específicas de onde virá o tráfego de gerenciamento. Normalmente, todo o tráfego de gerenciamento deve fluir de um firewall ou outro dispositivo virtual de rede (NVA) localizado na rede de hub para o spoke.
Consulte Visão geral de Aplicar princípios de Zero Confiança à IaaS do Azure para obter a arquitetura de referência completa.
Sua configuração variará de acordo com suas necessidades específicas de gerenciamento. No entanto, você deve usar regras em dispositivos de firewall e regras no grupo de segurança de rede para permitir explicitamente conexões no lado da rede da plataforma e da rede de carga de trabalho.
Planejando implantações
Como seus serviços de aplicativo e bancos de dados agora estão usando rede privada, planeje como as implantações de código e dados para esses recursos operam. Adicione regras para permitir que seus servidores de compilação privados acessem esses pontos de extremidade.
Implantar o log de fluxo do grupo de segurança de rede
Mesmo que seu grupo de segurança de rede esteja bloqueando tráfego desnecessário, isso não significa que suas metas sejam atingidas. Para detetar um ataque, você ainda precisa observar o tráfego que está ocorrendo fora de seus padrões explícitos.
O tráfego para os pontos de extremidade privados não é registrado, mas se outros serviços forem implantados nas sub-redes posteriormente, esse log ajudará a detetar as atividades.
Para habilitar o registro em log do fluxo do grupo de segurança de rede, siga o Tutorial: Registrar o fluxo de tráfego de rede de e para uma máquina virtual para o grupo de segurança de rede existente para os pontos de extremidade privados.
Nota
Tenha estas recomendações em mente:
Você deve restringir o acesso aos logs conforme necessário.
Os logs devem fluir para o Log Analytics e o Microsoft Sentinel conforme necessário.
Etapa 5: Proteger a entrada e saída para serviços PaaS do Azure
Esta seção contém duas etapas necessárias para garantir a entrada e saída de seus Serviços de PaaS:
- Implante pontos de extremidade privados para entrada em seus serviços.
- Implante a integração de VNet para permitir que seu Serviço de Aplicativo converse com sua VNet.
Além disso, você também deve considerar sua configuração de DNS para permitir a resolução de nomes.
Implantar pontos de extremidade privados para entrada
Embora muitos serviços permitam que você crie pontos de extremidade privados a partir da folha específica do recurso no portal do Azure, uma experiência mais consistente é criar um ponto de extremidade privado a partir de sua própria criação de recursos. Para isso, os recursos já devem estar mobilizados. Uma vez implantado, você pode criar o ponto de extremidade privado.
Ao implantar os pontos de extremidade privados, configure-os da seguinte maneira:
- Coloque-os no grupo de recursos específico que abriga os recursos pai para manter os recursos com um ciclo de vida semelhante juntos e fornecer acesso central.
- Coloque-os na sub-rede apropriada na VNet com base em sua função.
- Para o Serviço de Aplicativo do Azure, você pode configurar pontos de extremidade privados para seu frontend normal e seu ponto de extremidade SCM, que é usado para implantações e gerenciamento.
Além disso, como parte dessa implantação, você deve garantir que o firewall específico do serviço esteja definido para negar o tráfego de entrada. Isso negará qualquer tentativa de entrada pública.
Para o banco de dados SQL do Azure, gerencie suas regras de firewall IP no nível do servidor. Verifique se o acesso à rede pública está definido como Desabilitar no painel de rede no portal do Azure.
Para o Serviço de Aplicativo do Azure, adicionar o ponto de extremidade privado define seu firewall de nível de serviço para bloquear o acesso de entrada por padrão. Para obter mais informações, consulte Usando pontos de extremidade privados para aplicativos do Serviço de Aplicativo.
Implantar a integração de VNet para saída
Além dos pontos de extremidade privados para entrada, habilite a integração de VNet. Cada Plano do Serviço de Aplicativo pode ter a integração de VNet habilitada e, ao fazer isso, aloca uma sub-rede inteira para o Serviço de Aplicativo. Para obter mais informações, consulte Integrar seu aplicativo com uma VNet do Azure.
Para configurar seu Serviço de Aplicativo, consulte Habilitar a integração de VNet no Serviço de Aplicativo do Azure. Certifique-se de que o está a colocar na sua sub-rede designada para saída.
Considerações sobre DNS
Como parte do uso de pontos de extremidade privados, habilite a resolução DNS dos FQDNs dos recursos para seus novos endereços IP privados. Para obter instruções sobre como implementar isso de várias maneiras, consulte Configuração de DNS de ponto de extremidade privado.
Nota
A resolução DNS tem de ser aplicada a todo o tráfego. Os recursos na mesma rede virtual não poderão ser resolvidos a menos que estejam usando as zonas DNS corretas.
Etapa 6: Proteger o acesso à rede virtual e ao aplicativo
A proteção do acesso à rede virtual e aos aplicativos inclui:
- Protegendo o tráfego dentro do ambiente do Azure para o aplicativo
- Usando autenticação multifator (MFA) e políticas de acesso condicional para acesso do usuário a aplicativos.
O diagrama a seguir mostra ambos os modos de acesso na arquitetura de referência.
Proteja o tráfego no ambiente do Azure para a rede virtual e o aplicativo
Grande parte do trabalho de tráfego de segurança no ambiente do Azure já está concluído. Consulte Aplicar princípios de Zero Confiança ao armazenamento do Azure para configurar conexões seguras entre recursos de armazenamento e as VMs.
Consulte Aplicar princípios de Confiança Zero a uma VNet de hub no Azure para proteger o acesso de recursos de hub à VNet.
Usando políticas de MFA e Acesso Condicional para acesso do usuário a aplicativos
O artigo Aplicar princípios de confiança zero a máquinas virtuais recomenda como proteger solicitações de acesso diretamente a VMs com MFA e acesso condicional. Essas solicitações são provavelmente de administradores e desenvolvedores. A próxima etapa é proteger o acesso a aplicativos com MFA e Acesso Condicional. Isso se aplica a todos os usuários que acessam o aplicativo.
Primeiro, se o aplicativo ainda não estiver integrado ao Microsoft Entra ID, consulte Tipos de aplicativo para a plataforma de identidade da Microsoft.
Em seguida, adicione o aplicativo ao escopo de suas políticas de identidade e acesso ao dispositivo.
Ao configurar o MFA com Acesso Condicional e políticas relacionadas, use o conjunto de políticas recomendado para Confiança Zero como guia. Isso inclui políticas de ponto de partida que não exigem gerenciamento de dispositivos. Idealmente, os dispositivos que acessam suas VMs são gerenciados e você pode implementar o nível Enterprise , que é recomendado para Zero Trust. Para obter mais informações, consulte Common Zero Trust identity and device access policies.
O diagrama a seguir mostra as políticas recomendadas para Zero Trust.
Etapa 7: Habilitar a deteção e a proteção avançadas contra ameaças
Sua VNet spoke criada no Azure pode ser protegida pelo Microsoft Defender for Cloud, pois outros recursos do seu ambiente de negócios de TI em execução no Azure ou no local também podem ser protegidos.
Como mencionado nos outros artigos desta série, o Defender for Cloud é uma ferramenta de Gerenciamento de Postura de Segurança na Nuvem (CSPM) e Proteção de Carga de Trabalho na Nuvem (CWP) que oferece recomendações de segurança, alertas e recursos avançados, como proteção de rede adaptável para ajudá-lo à medida que você progride em sua jornada de segurança na nuvem.
Este artigo não descreve o Defender for Cloud em detalhes, mas é importante entender que o Defender for Cloud funciona com base em políticas e logs do Azure ingeridos em um espaço de trabalho do Log Analytics. Uma vez ativado nas subscrições com a sua VNet spoke e recursos associados, pode ver recomendações para melhorar a sua postura de segurança. Você pode filtrar essas recomendações ainda mais por tática MITRE, Grupo de Recursos e outros. Considere priorizar para resolver recomendações que tenham um impacto maior no Secure Score da sua organização. Eis um exemplo.
Existem planos do Defender for Cloud que oferecem proteções avançadas de carga de trabalho que incluem recomendações de proteção de rede adaptável para melhorar as regras de grupo de segurança de rede existentes. Eis um exemplo.
Você pode aceitar a recomendação selecionando Enforce, que criará uma nova regra de grupo de segurança de rede ou modificará uma existente.
Formação recomendada
- Proteja seus recursos do Azure com o controle de acesso baseado em função do Azure (Azure RBAC)
- Configurar e gerenciar o Azure Monitor
- Configurar grupos de segurança de rede
- Projetar e implementar segurança de rede
- Projetar e implementar acesso privado aos Serviços do Azure
Passos Seguintes
Consulte estes artigos adicionais para aplicar os princípios de Zero Trust ao Azure:
- Para IaaS do Azure:
- Área de Trabalho Virtual do Azure
- WAN Virtual do Azure
- Aplicativos IaaS na Amazon Web Services
- Microsoft Sentinel e Microsoft Defender XDR
Referências
- Adote a segurança proativa com o Zero Trust
- Proteja as redes com Zero Trust
- Rede de confiança zero para aplicações Web com a Firewall do Azure e o Gateway de Aplicações
- Políticas da Zona de Aterrissagem do Azure
- Identidade e dispositivo comuns do Zero Trust entre políticas
- O que é um ponto final privado?
- Configuração de DNS de ponto de extremidade privado
- Integrar seu aplicativo com uma VNet do Azure
- Usando pontos de extremidade privados para aplicativos do Serviço de Aplicativo
- Conectar-se a um servidor SQL do Azure usando um ponto de extremidade privado do Azure
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários