Aplicar princípios de Confiança Zero 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 Confiança Zero a uma carga de trabalho de PaaS usando redes virtuais (VNets) do Azure e pontos de extremidade privados das seguintes maneiras:
| Princípio de Confiança Zero | Definição | Atendido por |
|---|---|---|
| Verificação explícita | Sempre autenticar e autorizar com base em todos os pontos de dados disponíveis. | Use a detecçã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. |
| Usar o acesso de privilégio mínimo | Limite o acesso do usuário com JIT/JEA (Just-In-Time e Just-Enough-Access), políticas adaptáveis baseadas em risco e proteção de dados. | Reduza o Ingress e o Egress dos serviços do Azure para sua rede privada. Use grupos de segurança de rede para permitir apenas o Ingress específico da VNet. Use uma instância central do Firewall do Azure para conceder acesso de tráfego não VNet ao serviço do Azure. |
| Pressupor a violação | Minimize o raio de alcance e segmente o acesso. Verifique a criptografia de ponta a ponta e use a análise para obter visibilidade, promover a detecção de ameaças e melhorar as defesas. | Limite a comunicação desnecessária entre recursos. Verifique se você está registrando em log de grupos de segurança de rede e se tem a visibilidade adequada do tráfego anormal. Acompanhar alterações em grupos de segurança de rede. |
Para obter mais informações sobre como aplicar os princípios de Confiança Zero em um ambiente de IaaS do Azure, veja Aplicar princípios de Confiança Zero à visão geral da IaaS do Azure.
Rede autônoma ou spoke de Confiança Zero para serviços de PaaS do Azure
Muitos serviços PaaS contêm sua própria funcionalidade de controle de Ingress e Egress nativo 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 VNets. 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 que permite conexões de uma VNet específica ou bloqueia o acesso à rede pública.
- O Serviço de Aplicativo do Azure é compatível com restrições de acesso para definir uma lista de permissão/negação ordenada com prioridade que controla o acesso de rede ao aplicativo.
No entanto, para implementações guiadas por Confiança Zero, esses controles de acesso nativos de serviço geralmente não são 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 resolvem para um endereço IP público atribuído dinamicamente que é alocado de uma subfase de endereços IP públicos em uma região específica para um tipo de serviço. Devido a isso, você não poderá permitir o tráfego de ou para um serviço PaaS específico usando o endereço IP público, que pode ser alterado.
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 VNet. Essa interface de rede conecta você de forma privada e segura a um serviço da plataforma do Link Privado do Azure. Ao ativar um ponto de extremidade privado, você traz o serviço para a VNet.
Dependendo do cenário da solução, talvez você ainda precise de acesso público de entrada aos serviços PaaS. Mas, a menos que você o faça, a Microsoft recomenda que todo o tráfego permaneça privado para eliminar possíveis 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 compatíveis com 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 Ingress com um grupo de segurança de rede dedicado.
- As camadas da Web contêm uma sub-rede dedicada para Egress.
- O acesso ao aplicativo é fornecido por meio de um Gateway de Aplicativo contido na 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 App GW (Gateway de Aplicativo do Azure), incluindo um WAF (Firewall de Aplicativo Web)
- 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 de extremidade privados
Além disso, os recursos para a VNet de hub são implantados na assinatura de conectividade apropriada.
O que você encontrará neste artigo
Os princípios de Confiança Zero são aplicados em toda a arquitetura, desde o nível do locatário e do 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.
| Etapa | Tarefa |
|---|---|
| 1 | Aproveite o Microsoft Entra RBAC ou configure funções personalizadas para recursos de rede. |
| 2 | Isole a infraestrutura em grupo de recursos próprio. |
| 3 | Crie um grupo de segurança de rede em cada sub-rede. |
| 4 | Proteja o tráfego e os recursos na VNet:
|
| 5 | Ingress e Egress seguros para serviços PaaS do Azure. |
| 6 | Acesso seguro a VNet e aplicativos. |
| 7 | Habilite a detecção, o alerta e a 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 grupos de recursos próprios.
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 gerenciadores de rede VNet spoke não precisam de acesso completo aos recursos de rede concedidos pela função Colaborador do Microsoft Entra RBAC, mas precisam de mais permissões do que outras funções comuns. Uma função personalizada pode ser usada para definir o escopo do 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 destino 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 escopo
- 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 destino do Azure ou por meio do Microsoft Entra ID com funções personalizadas do Azure.
Etapa 2: isolar a infraestrutura em grupo de recursos próprio
Ao isolar os recursos de rede dos recursos de computação, dados ou armazenamento, você reduz a probabilidade de vazamento de permissões. Além disso, garantindo 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 múltiplos contextos em um grupo de recursos compartilhados, crie um grupo de recursos dedicados. O diagrama de arquitetura a seguir mostra essa configuração.
No diagrama, os recursos e componentes na 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 spoke.
Com um grupo de recursos dedicados, você pode atribuir uma função personalizada usando o tutorial Conceder acesso de usuário a recursos do Azure usando o 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 identidades corporativas.
Se você não estiver usando políticas que impõem o encaminhamento de log em grupos de recursos, configure-o no log de atividades para o grupo de recursos:
- Procure o grupo de recursos no portal do Azure.
- Navegue até Registrar em log — >Exportar logs 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. Veja um exemplo:
Consulte Configurações de diagnóstico para entender as instruções de revisão desses logs e alertá-los.
Democratização da assinatura
Embora não esteja diretamente relacionado à rede, você deve planejar sua assinatura RBAC de maneira semelhante. Além de isolar os 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 assinatura como unidade de gestão deve ter um escopo restrito.
Para obter mais informações, confira Princípios de design da zona de destino do Azure.
Etapa 3: criar um grupo de segurança de rede em cada sub-rede
Os grupos de segurança de rede do Azure são usados para filtrar o tráfego de rede entre os recursos do Azure em uma VNet do Azure. É recomendável aplicar um grupo de segurança de rede a cada sub-rede. Isso é imposto por meio da política do Azure por padrão ao implantar as zonas de destino do Azure. Um grupo de segurança de rede contém regras de segurança que permitem ou negam o tráfego de rede de entrada ou de saída em relação a 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 Ingress 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 Egress 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 diagrama pode resultar em 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 o monitoramento e o registro em log.
Veja 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 reconhecer como eles podem ser usados para proteger seus ambientes.
Etapa 4: proteger o tráfego e os recursos na VNet
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 tráfego de gerenciamento na VNet
- Implantar o registro em 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 da Confiança Zero é 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. Depois de provisionado, crie uma regra para negar tudo em cada uma das regras de entrada e saída com uma prioridade de 4096. Essa é a última prioridade personalizada disponível, o que significa que você ainda tem o escopo restante para configurar 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:
- Origem: Qualquer
- Intervalos 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.
Veja um exemplo.
Repita esse processo com regras de entrada, ajustando o nome e a descrição conforme apropriado.
A Tab Regras de segurança de entrada exibe o sinal de aviso na regra. Veja um exemplo.
Clique na regra e role até a parte inferior para ver mais detalhes. Veja um exemplo:
Esta mensagem fornece os seguintes dois avisos:
- Os Azure Load Balancers do Azure não poderão, por padrão, acessar recursos usando esse grupo de segurança de rede.
- Outros recursos nessa VNet não poderão, por padrão, acessar recursos usando esse grupo de segurança de rede.
Para o nosso propósito de Confiança Zero, é assim que deve ser. Isso significa que só porque algo está nesta VNet, não significa que ele terá acesso imediato aos recursos. Para cada padrão de tráfego, crie uma regra que o permita explicitamente e você deve fazê-lo com o menor valor de permissões.
Se você tiver conexões de saída específicas para gerenciamento, como controladores de domínio dos AD DS (Active Directory Domain Services), VMs DNS privadas ou sites externos específicos, elas precisarão ser controladas aqui.
Regras alternativas de negação
Observação
As recomendações nesta seção se aplicam apenas à sub-rede de Egress da Web.
Se você estiver usando o Firewall do Azure para gerenciar suas conexões de saída, em vez de executar uma negação de todas as saídas, 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 manipula o tráfego fora da VNet.
Em seguida, você pode criar uma regra de saída para negar todas as VNet ou uma regra para permitir todas as saídas, mas proteger itens com regras de entrada.
Veja Firewall do Azure e Tabelas de rotas para reconhecer como eles podem ser usados 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. Veja um exemplo.
Use o processo Gerenciar grupos de segurança de rede: criar uma regra de segurança para adicionar regras aos 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 | Fonte | 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 | Entrada | Endereços IP | Intervalo de endereço IP privado da sub-rede do gateway de aplicativo | 443 | Endereços IP | O endereço IP de conteúdo adulto 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 | 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 de conteúdo adulto do ponto de extremidade privado de BD do SQL | MS SQL | AllowApptoSQLDBOutbound | Permite acesso de saída ao ponto de extremidade privado do SQL da sub-rede de integração do Serviço de Aplicativo. |
| Sub-rede do SQL do Azure | Entrada | 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 de conteúdo adulto do ponto de extremidade privado de BD do SQL | MS SQL | AllowApptoSQLDBInbound | Permite acesso de entrada ao ponto de extremidade privado do SQL da sub-rede de integração do Serviço de Aplicativo. |
Observação
À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 sempre usam "*" para a porta de origem.
Observação
Como prioridade, use um valor entre 100 e 4.000. Você pode iniciar em 105.
Isso é além das regras do grupo de segurança de rede na sub-rede do Gateway de Aplicativo.
Com essas regras, você definiu o padrão de conectividade Confiança Zero para uma única camada de aplicativo. Você pode repetir esse processo conforme necessário para fluxos adicionais.
Planejar o tráfego de gerenciamento na VNet
Além do tráfego específico do aplicativo, planeje o tráfego de gerenciamento. No entanto, como o tráfego de gerenciamento geralmente se origina fora da VNet spoke, mais regras são necessárias. Primeiro, reconheça as portas e fontes específicas de onde virá o tráfego de gerenciamento. Normalmente, todo o tráfego de gerenciamento deve fluir de um firewall ou outra solução de virtualização de rede (NVA) localizada na rede de hub para o spoke.
Veja Aplicar princípios de Confiança Zero à visão geral da IaaS do Azure para obter a arquitetura de referência completa.
Sua configuração vai variar com base em 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 nos lados de rede de plataforma e de rede de carga de trabalho.
Planejamento da implantações
Como seus serviços de aplicativos e bancos de dados agora estão usando rede privada, planeje como as implantações de código e dados nesses recursos operam. Adicione regras para permitir que os servidores de compilação privados acessem esses pontos de extremidade.
Implantar o registro em 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 as metas foram atingidas. Para detectar uma invasão, você ainda precisa observar o tráfego que está ocorrendo fora de padrões para conteúdo adulto.
O tráfego para os pontos de extremidade privados não está registrado, mas se outros serviços forem implantados nas sub-redes posteriormente, esse log ajudará a detectar as atividades.
Para habilitar o log de 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.
Observação
Observe estas recomendações:
Você deve restringir o acesso aos logs conforme necessário.
Os registros devem fluir para o Log Analytics e o Microsoft Sentinel, conforme necessário.
Etapa 5: Ingress e Egress seguros para serviços PaaS do Azure
Esta seção contém duas etapas necessárias para proteger o Ingress e Egress dos serviços PaaS:
- Implante pontos de extremidade privados para entrada em serviços.
- Implante a integração de VNet para permitir que o Serviço de Aplicativo converse com a 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 ingress
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 ser implantados. Depois de 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 hospeda os recursos pai para manter os recursos com um ciclo de vida similar juntos e fornecer acesso central.
- Coloque-os na sub-rede apropriada na VNet com base na função.
- Para o Serviço de Aplicativo do Azure, você pode configurar pontos de extremidade privados para o front-end normal e o 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 ingress pública.
Para o banco de dados SQL do Azure, gerencie as regra de firewall de 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, veja Uso de pontos de extremidade privados para os aplicativos de Serviço de aplicativo.
Implantar integração VNet para Egress
Além dos pontos de extremidade privados para ingress, habilite a integração de VNet. Cada Plano do serviço de aplicativo pode ter a integração VNet habilitada e, fazendo isso, aloca uma sub-rede inteira para o Serviço de Aplicativos. Para mais informações, veja Integrar o aplicativo a uma VNet do Azure.
Para configurar o Serviço de Aplicativo, veja Habilitar a integração VNet no Serviço de Aplicativo do Azure. Verifique se você está colocando-o em 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 novos endereços IP privados. Para obter instruções para implementar isso de várias maneiras, consulte Configuração de DNS de ponto de extremidade privado.
Observação
A resolução DNS precisa ser aplicada a todo o tráfego. Os recursos na mesma VNet não poderão ser resolvidos, a menos que estejam usando as zonas DNS corretas.
Etapa 6: proteger o acesso à VNet e ao aplicativo
Proteger o acesso à VNet e aos aplicativos inclui:
- Proteção do tráfego no ambiente do Azure para o aplicativo
- Usando a MFA (autenticação multifator) e as políticas de acesso condicional para acesso do usuário a aplicativos.
O diagrama a seguir mostra os dois modos de acesso na arquitetura de referência.
Tráfego seguro no ambiente do Azure para a VNet e o aplicativo
Grande parte do trabalho de tráfego de segurança no ambiente do Azure já está concluído. Veja Aplicar princípios de Confiança Zero ao armazenamento do Azure para configurar conexões seguras entre os recursos de armazenamento e as VMs.
Veja Aplicar princípios de Confiança Zero a uma VNet de hub no Azure para proteger o acesso dos recursos de hub à VNet.
Usando políticas de MFA e acesso condicional para acesso de 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 provavelmente são 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, veja Tipos de aplicativo para a plataforma de identidade da Microsoft.
Em seguida, adicione o aplicativo ao escopo das políticas de identidade e acesso ao dispositivo.
Ao configurar a 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 o gerenciamento de dispositivos. Idealmente, os dispositivos que acessam suas VMs são gerenciados e você pode implementar o nível Enterprise , que é recomendado para Confiança Zero. Para mais informações, confira Políticas de acesso de dispositivo e identidade comuns de Confiança Zero.
O diagrama a seguir mostra as políticas recomendadas para confiança zero.
Etapa 7: habilitar a detecção e a proteção avançadas de ameaças
Sua VNet spoke criada no Azure pode ser protegida pelo Microsoft Defender para Nuvem, 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 para Nuvem é uma ferramenta de CSPM (Gerenciamento da Postura de Segurança na Nuvem) e CWP (Proteção de Carga de Trabalho para Nuvem) 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 no percurso de segurança na nuvem.
Este artigo não descreve o Defender para Nuvem em detalhes, mas é importante entender que o Defender para Nuvem funciona com base em políticas e logs do Azure ingeridos em um workspace do Log Analytics. Uma vez habilitado nas assinaturas com sua VNet spoke e recursos associados, você pode ver recomendações para melhorar sua postura de segurança. Você pode filtrar ainda mais essas recomendações pela tática MITRE, grupo de recursos e outros. Considere priorizar para resolver recomendações que têm um impacto maior na classificação de segurança da organização. Veja um exemplo.
Há planos do Defender para Nuvem que oferecem proteções avançadas de carga de trabalho que incluem recomendações de proteção de rede adaptável para aprimorar suas regras de grupo de segurança de rede existentes. Veja um exemplo.
Você pode aceitar a recomendação selecionando Impor, que criará uma nova regra de grupo de segurança de rede ou modificará uma existente.
Treinamento recomendado
- Proteger seus recursos do Azure com o controle de acesso baseado em função do Azure (RBAC do Azure)
- Configurar e gerenciar o Azure Monitor
- Configurar grupos de segurança de rede
- Projetar e implementar a segurança de rede
- Projetar e implementar o acesso privado aos Serviços do Azure
Próximas etapas
Consulte estes artigos adicionais para aplicar os princípios de confiança zero ao Azure:
- Para IaaS do Azure:
- Área de Trabalho Virtual do Azure
- WAN Virtual do Azure
- Aplicativos IaaS no Amazon Web Services
- Microsoft Sentinel e Microsoft Defender XDR
Referências
- Adotar a segurança proativa com Confiança Zero
- Proteger redes com a Confiança Zero
- Rede de confiança zero para aplicativos Web com o Firewall do Azure e o Gateway de Aplicativo
- Políticas de zona de destino do Azure
- Identidade e dispositivo comuns com abordagem Confiança Zero em todas as políticas
- O que é um ponto de extremidade privado?
- Configuração de DNS de ponto de extremidade privado
- Integrar seu aplicativo a uma VNet do Azure
- Como usar 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