Aplicar princípios Confiança Zero a uma rede virtual spoke no Azure
Resumo: para aplicar os princípios de Confiança Zero a uma rede virtual spoke no Azure, aproveite o RBAC (controle de acesso baseado em função), isole as sub-redes e as máquinas virtuais (grupos de recursos, grupos de segurança de rede e grupos de segurança de aplicativos), proteja o tráfego e os recursos nos aplicativos de VNet e máquina virtual e habilite a detecção avançada, os alertas e a proteção contra ameaças.
Este artigo ajuda você a aplicar os princípios de confiança zero a uma rede virtual (VNet) spoke para cargas de trabalho de IaaS no Azure 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 grupos de segurança de aplicativos para verificar se as NICs individuais têm permissões para se comunicar em canais específicos. |
| 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. | Não habilite o acesso 3389/RDP por padrão em nenhum canal. Use permissões de função corretas para o contexto de spoke. |
| 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. Certifique-se de que consiga iniciar a sessão em grupos de segurança de rede e de que tenha visibilidade adequada do tráfego anômalo. Acompanhar alterações em grupos de segurança de rede. |
Este artigo faz parte de uma série de artigos que demonstram como aplicar os princípios da confiança zero em um ambiente no Azure que inclui uma VNet spoke que hospeda uma carga de trabalho baseada em máquina virtual. Para ver mais informações, consulte a Visão geral da aplicação dos princípios de confiança zero à IaaS do Azure.
Arquitetura de referência
O diagrama a seguir mostra uma arquitetura de referência comum para cargas de trabalho baseadas em IaaS.
No diagrama:
- Uma VNet spoke inclui componentes para oferecer suporte a um aplicativo de IaaS composto por máquinas virtuais.
- O aplicativo de IaaS é um aplicativo de três camadas composto por duas máquinas virtuais para cada camada: front-end, aplicativo e dados.
- Cada camada está contida em uma sub-rede dedicada com um grupo de segurança de rede dedicado.
- Cada função de máquina virtual é atribuída a um grupo de segurança de aplicativo correspondente à sua função.
- O acesso ao aplicativo é fornecido por meio de um Gateway de Aplicativo contido na própria sub-rede.
O aplicativo mostrado na arquitetura de referência segue o estilo de arquitetura de N camadas
O diagrama a seguir mostra os componentes de um grupo de recursos para uma VNet spoke em uma assinatura do Azure separada da assinatura da VNet de hub.
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, um para cada camada de aplicativo
- Três grupos de segurança de aplicativo, um para cada camada de aplicativo
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 máquinas virtuais a grupos de segurança de aplicativos. A tabela a seguir descreve as recomendações para proteger essa arquitetura.
| Etapa | Tarefa | Princípios de confiança zero aplicados |
|---|---|---|
| 1 | Usar o controle de acesso baseado em função (RBAC) do Microsoft Entra ou configurar funções personalizadas para recursos de rede. | Usar o acesso de privilégio mínimo |
| 2 | Isolar a infraestrutura em grupo de recursos próprio | Pressupor a violação |
| 3 | Criar um grupo de segurança de rede em cada sub-rede | Usar o acesso com privilégios mínimos Pressupor a violação |
| 4 | Criar um grupo de segurança de aplicativo para cada função de máquina virtual. | Verificação explícita Usar o acesso com privilégios mínimos Pressupor a violação |
| 5 | Proteger o tráfego e os recursos na VNet |
Verificação explícita Usar o acesso com privilégios mínimos Pressupor a violação |
| 6 | Acesso seguro a VNet e aplicativos. | Usar o acesso com privilégios mínimos Pressupor a violação |
| 7 | Habilitar a detecção, o alerta e a proteção avançados contra ameaças. | Pressupor a violação |
Etapa 1: usar o RBAC do Microsoft Entra ou configurar funções personalizadas para recursos de rede
Você pode usar funções internas de RBAC do Microsoft Entra para colaboradores de rede. No entanto, outra abordagem é usar funções personalizadas. Os gerentes de rede spoke não precisam de acesso completo aos recursos de rede concedidos pela função Colaborador de rede de RBAC do Microsoft Entra, mas precisam de mais permissões do que outras funções comuns. Você pode usar uma função personalizada para definir o 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 é a função personalizada Gerenciamento de rede, que tem as seguintes permissões:
- Ler 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
Você pode criar essa função usando os scripts para as funções personalizadas ou por meio do Microsoft Entra ID com o processo descrito em Funções personalizadas do Azure — RBAC 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 vários contextos em um grupo de recursos compartilhados, crie um grupo de recursos dedicados para ele. A arquitetura de referência que este artigo apoia ilustra esse conceito.
Na figura, os recursos e componentes em toda a arquitetura de referência são divididos em grupos de recursos dedicados para máquinas virtuais, 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 seguinte processo: Tutorial: conceder a um usuário acesso aos recursos do Azure usando o portal do Azure — RBAC 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 seus padrões de gerenciamento de identidades corporativas.
Se você não estiver usando políticas que imponham o encaminhamento de logs em grupos de recursos, configure isso no Log de atividades do grupo de recursos: navegue até Log de atividades > 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.
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 saber mais sobre a democratização da assinatura, consulte Princípios de design da zona de destino do Azure — Cloud Adoption Framework.
É possível configurar o diagnóstico na categoria Segurança da configuração de Diagnóstico no Azure Monitor, conforme mostrado aqui.
Consulte Configurações de diagnóstico para entender as instruções de revisão desses logs e alertá-los.
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, que é 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 origem e destino, porta e protocolo.
Para um aplicativo baseado em máquina virtual de várias camadas, a recomendação é criar um grupo de segurança de rede dedicado (NSG na imagem a seguir) para cada sub-rede que hospeda uma função de máquina virtual.
No diagrama:
- Cada camada do aplicativo é hospedada em uma sub-rede dedicada, como camada de front-end, camada de aplicativo e camada de dados.
- 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 da mostrada na figura 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.
Crie um grupo de segurança de rede usando este processo: Criar, alterar ou excluir um grupo de segurança de rede do Azure
Consulte grupos de segurança de rede para entender como você pode usá-los para proteger o ambiente.
Etapa 4: criar um grupo de segurança de aplicativo para cada função de máquina virtual
Os grupos de segurança de aplicativo permitem a você configurar a segurança de rede como uma extensão natural da estrutura de um aplicativo, permitindo o agrupamento de máquinas virtuais e a definição de políticas de segurança de rede com base nesses grupos. Você pode reutilizar sua política de segurança em escala sem precisar manter endereços IP explícitos manualmente. A plataforma lida com a complexidade de endereços IP explícitos e vários conjuntos de regras, permitindo que você se concentre na sua lógica de negócios.
Dentro de sua carga de trabalho, identifique as funções específicas da máquina virtual. Em seguida, crie um grupo de segurança de aplicativo para cada função. Na arquitetura de referência, três grupos de segurança de aplicativos são representados.
No diagrama:
- Três grupos de segurança de aplicativo são criados para dar suporte a esse aplicativo, um para cada camada: front-end, aplicativo e dados.
- Cada máquina virtual é atribuída ao grupo de segurança de aplicativo correspondente para sua função (texto vermelho no diagrama).
Para ver mais informações sobre grupos de segurança de aplicativos e como atribuí-los a máquinas virtuais, consulte Visão geral sobre grupos de segurança de aplicativos Azure.
Observação
Se você estiver usando load balancers o uso do respectivo endereço IP nos grupos de segurança de rede será necessário, pois os grupos de segurança de aplicativos não podem definir o escopo de um load balancer.
Etapa 5: proteger o tráfego e os recursos na VNet
Esta seção aborda as seguintes recomendações:
- Implantar regras de negação de linha de base para grupos de segurança de rede
- Implantar regras específicas de aplicativo para grupos de segurança de aplicativos
- 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 permitidas. 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 negar tudo em cada uma das regras de entrada e saída, com uma prioridade de 4.096. Essa é a última prioridade personalizada disponível, o que significa que você ainda tem o escopo restante para configurar as ações Permitir.
No grupo de segurança de rede, navegue até 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. Você notará que, na guia Regras de segurança de entrada, há um sinal de aviso na regra, conforme mostrado aqui.
Se você clicar na regra e rolar até a parte inferior, verá mais detalhes, conforme mostrado aqui.
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 na confiança zero, é assim que deve ser. Isso significa que só porque algo está nesta VNet, não significa que ela tenha acesso imediato aos seus recursos. Para cada padrão de tráfego, você precisará criar uma regra que permita explicitamente isso e deverá fazê-lo com a menor quantidade de permissões. Portanto, se você tiver conexões de saída específicas para gerenciamento, como controladores de domínio dos Active Directory Domain Services (AD DS), máquinas virtuais de DNS privadas ou sites externos específicos, elas precisarão ser controladas aqui.
Regras alternativas de negação
Se você estiver usando o Firewall do Azure para gerenciar suas conexões de saída, em vez de negar todas as saídas, poderá deixar todas as saídas abertas. Como parte da implementação do Firewall do Azure, você configurará uma tabela de rotas que envia a rota padrão (0.0.0.0/0) para o firewall, que manipula o tráfego fora da VNet.
Em seguida, você pode negar todas as saídas de VNet ou, em vez disso, permitir todas as saídas (mas proteger os itens com suas regras de entrada).
Leia mais sobre o Firewall do Azure e as tabelas de rotas a fim de entender como você pode usá-las para aumentar ainda mais a segurança do ambiente.
Regras de gerenciamento de máquinas virtuais
Para configurar máquinas virtuais com o Logon do Microsoft Entra, Antimalware e atualizações automáticas habilitadas, será necessário permitir as seguintes conexões de saída. Muitas delas são por FQDN, o que significa que o Firewall do Azure é necessário para regras de FQDN ou você fará um plano mais complexo. O Firewall do Azure é recomendado.
Aviso
Talvez seja melhor movê-las para a rede do hub.
As conexões de saída são:
- Na porta 443:
- enterpriseregistration.windows.net
- settings-win.data.microsoft.com
- sls.update.microsoft.com
- v10.events.data.microsoft.com
- login.microsoftonline.com
- pas.windows.net
- 169.254.169.254
- Na porta 80:
- ctldl.windowsupdate.com
- www.msftconnecttest.com
- Na porta 123:
- time.windows.com
- Na porta 1688:
- Azkms.core.windows.net
Implantar regras específicas de aplicativo para grupos de segurança de aplicativos
Defina padrões de tráfego com a menor quantidade de permissões e seguindo apenas caminhos explicitamente permitidos. Aqui está um diagrama de exemplo do uso de grupos de segurança de aplicativo para definir padrões de tráfego de rede nos grupos de segurança de rede para uma VNet spoke que é usada juntamente com uma VNet de hub. Essa é a configuração recomendada.
Como outro exemplo, aqui está uma configuração para uma VNet spoke independente na qual o Firewall de aplicativo Web é colocado na sub-rede do gateway de aplicativo da VNet spoke.
São necessárias as seguintes regras de grupo de segurança de rede:
- Permitir o tráfego de Internet na sub-rede APP GW (HTTPS 443).
- Permitir o tráfego da sub-rede APP GW para as máquinas virtuais da camada de front-end (HTTPS 433).
- Permitir o tráfego das máquinas virtuais da camada de front-end para o load balancer da camada de aplicativos (HTTPS 443).
- Permitir o tráfego do load balancer da camada de aplicativos para as máquinas virtuais da camada de aplicativos (HTTPS 443).
- Permitir o tráfego das máquinas virtuais da camada de aplicativos para o load balancer da camada de dados (SQL 1433).
- Permitir o tráfego do load balancer da camada de dados para as máquinas virtuais da camada de dados (SQL 1433).
- Permitir o tráfego entre máquinas virtuais da camada de dados (SQL 1433)
Configure o padrão SQL primeiro e, em seguida, repita o processo com as camadas restantes. As seções a seguir são as configurações das regras que limitam o tráfego de rede para uma única camada de aplicativo.
Regra 5 — Permitir o tráfego das máquinas virtuais da camada de aplicativos para o load balancer da camada de dados (SQL 1433)
No grupo de segurança de rede da sub-rede da camada de aplicativo, navegue até Regras de Segurança de Entrada e selecione Adicionar. Preencha a lista com o seguinte:
- Origem: grupo de segurança de aplicativo
- Grupos de segurança do aplicativo de origem: selecione o grupo de segurança de aplicativo da camada de negócios
- Intervalos de portas de origem: 1433 (Às vezes, o tráfego de origem pode vir de portas diferentes e, se esse padrão ocorrer, você poderá 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)
- Destino: Endereços IP
- Endereços IP de destino/intervalos CIDR: o IP explícito do load balancer
- É necessário usar o IP explícito aqui, pois não é possível associar um load balancer a um grupo de segurança de aplicativo.
- Você pode planejar seu esquema IP ou implantar o load balancer e fazer referência ao IP atribuído.
- Serviço: MS SQL
- Intervalos de portas de destino: são preenchidos automaticamente para a porta 1433
- Protocolo: isso é selecionado automaticamente para TCP
- Ação: Permitir
- Prioridade – um valor entre 100 e 4.096. Você pode começar com 105.
- Nome: Allow-App-Tier-to-Data-LB-Inbound
- Descrição: permite o acesso de entrada do load balancer da camada de dados às máquinas virtuais da camada de aplicativo.
Após a conclusão, você notará que há um ícone azul para alertas informativos sobre a regra. Clicar na regra fornece a seguinte mensagem:
- "As regras que usam grupos de segurança de aplicativo só podem ser aplicadas quando os grupos de segurança de aplicativo estão associados a interfaces de rede na mesma rede virtual."
Veja um exemplo.
A regra só se aplica quando esse grupo de segurança de aplicativo é usado nessa rede.
Por fim, no mesmo grupo de segurança de rede, navegue até Regras de Segurança de Saída e selecione Adicionar. Preencha a lista de forma semelhante ao exemplo, alterando Entrada para Saída.
Regra 6 — Permitir o tráfego do load balancer da camada de dados para as máquinas virtuais da camada de dados (SQL 1433)
No grupo de segurança de rede da sub-rede da camada de dados, navegue até Regras de Segurança de Entrada e selecione Adicionar. Preencha a lista com o seguinte:
- Origem: endereço IP
- Endereço IP de origem: o endereço IP do load balancer
- Intervalos de portas de origem: 1433
- Destino: grupo de segurança do aplicativo
- Grupos de segurança do aplicativo de destino: selecione o grupo de segurança de aplicativo da camada de dados
- Serviço: MS SQL
- Intervalos de portas de destino: são preenchidos automaticamente para a porta 1433.
- Protocolo: isso é selecionado automaticamente para TCP.
- Ação: Permitir
- Prioridade – um valor entre 100 e 4.096. Você pode começar com 105.
- Nome: Allow-SQL-LB-to-SQL-VMs-Inbound
- Descrição: permite o acesso de entrada às máquinas virtuais da camada de dados baseadas em SQL a partir do load balancer da camada de dados.
No mesmo grupo de segurança de rede, navegue até Regras de Segurança de Saída e selecione Adicionar. Preencha a lista como no exemplo, alterando Entrada para Saída.
Regra 7 — Permitir o tráfego entre máquinas virtuais da camada de dados (SQL 1433)
No grupo de segurança de rede da sub-rede da camada de dados, navegue até Regras de Segurança de Entrada e selecione Adicionar. Preencha a lista com o seguinte:
- Fonte: Grupo de segurança de aplicativo
- Grupos de segurança do aplicativo de destino: selecione o grupo de segurança de aplicativo da camada de dados
- Intervalos de portas de origem: 1433
- Destino: grupos de segurança do aplicativo
- Grupos de segurança do aplicativo de destino: selecione o grupo de segurança de aplicativo da camada de dados
- Serviço: MS SQL
- Intervalos de portas de destino: são preenchidos automaticamente para a porta 1433.
- Protocolo: isso é selecionado automaticamente para TCP.
- Ação: Permitir
- Prioridade – um valor entre 100 e 4.096. Você pode começar com 105.
- Nome: Allow-SQL-VM-to-SQL-VM-Inbound
- Descrição: permite acesso de entrada entre máquinas virtuais da camada de dados baseadas em SQL.
No mesmo grupo de segurança de rede, navegue até Regras de Segurança de Saída e selecione Adicionar. Preencha a lista como a lista anterior, alterando Entrada para Saída.
Com essas três regras, você definiu o padrão de conectividade de 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, é necessário planejar o tráfego de gerenciamento. No entanto, o tráfego de gerenciamento geralmente se origina fora da VNet spoke. Regras adicionais são necessárias. Primeiro, você precisará entender as portas e origens específicas das quais o tráfego de gerenciamento virá. Geralmente, todo o tráfego de gerenciamento deve fluir de um firewall ou outro NVA localizado na rede de hub para o spoke.
Consulte a arquitetura de referência completa no artigo Visão geral da aplicação dos princípios de confiança zero à IaaS do Azure.
Isso varia conforme suas necessidades específicas de gerenciamento. No entanto, as regras nos dispositivos de firewall e as regras no grupo de segurança de rede devem ser usadas para permitir explicitamente conexões no lado da rede da plataforma e no lado da rede da carga de trabalho.
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 suas metas foram atingidas. Você ainda precisa observar o tráfego que ocorre fora de seus padrões explícitos, para saber se um ataque está ocorrendo.
Para habilitar o log de fluxo do grupo de segurança de rede, você pode seguir o Tutorial: registrar o fluxo de tráfego de rede de e para uma máquina virtual em relação ao grupo de segurança de rede existente criado.
Observação
- A conta de armazenamento deve seguir as diretrizes da conta de armazenamento de confiança zero.
- O acesso aos logs deve ser restrito conforme necessário.
- Eles também devem fluir para a análise de logs e o Sentinel, conforme necessário.
Proteger o tráfego de entrada da Web com o IDPS
Além dos controles na sua rede virtual de spoke, você também pode usar um Firewall do Azure para aplicar inspeção adicional. Embora a função Firewall de Aplicativo Web do Azure Front Door e do Gateway de Aplicativo inspecione o tráfego em busca de ataques comuns da Web, o uso do Firewall do Azure pode proporcionar um nível mais profundo de inspeção.
Para usar todos os sinais disponíveis e manter a visibilidade central do tráfego de rede, é recomendável rotear o tráfego do Gateway de Aplicativo para o Firewall do Azure. Ele pode então inspecionar o tráfego em busca de sinais adicionais e capturar o comportamento em seus logs. Você pode ler mais sobre essa configuração no artigo Rede de confiança zero para aplicativos Web com o Firewall do Azure e o Gateway de Aplicativo. Para obter mais diretrizes sobre como configurar esse comportamento, consulte Configurar o Firewall do Azure Premium para Confiança Zero.
Etapa 6: proteger o acesso à VNet e aplicativos
A proteção do acesso à VNet e aos aplicativos inclui:
- Proteger o tráfego no ambiente do Azure para o aplicativo.
- Usar a autenticação multifator e as políticas de acesso condicional para permitir que o usuário acesse o aplicativo.
O diagrama a seguir mostra esses 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. As conexões seguras entre os recursos de armazenamento e as máquinas virtuais são configuradas em Aplicar princípios de confiança zero ao armazenamento do Azure.
Para proteger o acesso dos recursos de hub à VNet, consulte Aplicar princípios de confiança zero a uma rede virtual de hub no Azure.
Uso da autenticação multifator e das políticas de acesso condicional para acesso do usuário ao aplicativo
O artigo Aplicar princípios de confiança zero a máquinas virtuais recomenda como proteger solicitações de acesso diretamente a máquinas virtuais com autenticação multifator e acesso condicional. Essas solicitações provavelmente são de administradores e desenvolvedores. A próxima etapa é proteger o acesso ao aplicativo com autenticação multifator 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 acesso a identidades e dispositivos.
Ao configurar a autenticação multifator 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 máquinas virtuais 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 já pode estar protegida pelo Microsoft Defender para Nuvem (MDC), pois outros recursos do seu ambiente de negócios de TI em execução no Azure ou no local também podem estar protegidos.
Conforme mencionado nos outros artigos desta série, o Microsoft Defender para Nuvem é uma ferramenta de gerenciamento da postura de segurança na nuvem (GPSN) e proteção de cargas de trabalho (CWP) que oferece recomendações de segurança, alertas e recursos avançados, como a proteção de rede adaptativa para ajudá-lo à medida que você progride em sua jornada de segurança da nuvem. Para visualizar melhor onde o Defender para Nuvem se encaixa no cenário de segurança mais amplo da Microsoft, consulte Arquiteturas de referência de segurança cibernética da Microsoft.
Este artigo não aborda o Microsoft Defender para Nuvem em detalhes, mas é importante entender que o Microsoft Defender para Nuvem funciona com base nas políticas do Azure e nos logs ingeridos em um workspace do Log Analytics. Uma vez habilitado nas assinaturas com sua VNet spoke e recursos associados, você poderá ver recomendações para melhorar sua postura de segurança. Você pode filtrar essas recomendações ainda mais por tática MITRE, grupo de recursos, etc. Considere priorizar a resolução de recomendações que tenham um impacto maior na classificação de segurança da sua organização.
Aqui está um exemplo no portal do Microsoft Defender para Nuvem.
Se você optar por integrar um dos planos do Defender para Nuvem que oferecem proteções avançadas de carga de trabalho, ele incluirá recomendações de proteção de rede adaptável para melhorar as regras existentes do de grupo de segurança de rede. Veja um exemplo.
Você pode aceitar a recomendação selecionando Impor, que cria uma nova regra de grupo de segurança de rede ou modifica 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
- Proteger o acesso aos seus aplicativos usando os serviços de identidade do Azure
Para obter mais treinamento sobre segurança no Azure, veja estes recursos no catálogo da Microsoft:
Segurança no Azure | Microsoft Learn
Próximas etapas
Consulte estes artigos adicionais para aplicar os princípios de confiança zero ao Azure:
- Visão geral da 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
Ilustrações técnicas
Este cartaz fornece uma visão geral de uma única página dos componentes da IaaS do Azure como arquiteturas lógicas e de referência, juntamente com as etapas para garantir que esses componentes tenham os princípios "nunca confie, sempre verifique" do modelo de confiança zero aplicados.
| Item | Descrição |
|---|---|
 PDF | Visio Última atualização: março de 2024 |
Use esta ilustração com este artigo: Aplicar princípios de Confiança Zero à visão geral da IaaS do Azure Guias de soluções relacionadas |
Este cartaz apresenta as arquiteturas lógica e de referência e as configurações detalhadas dos componentes separados da confiança zero para IaaS do Azure. Use as páginas deste pôster para departamentos de TI ou especialidades separados ou, com a versão do arquivo do Microsoft Visio, personalize os diagramas para a infraestrutura.
| Item | Descrição |
|---|---|
 PDF | Visio Última atualização: março de 2024 |
Use estes diagramas junto dos artigos que começam aqui: Aplicar princípios de Confiança Zero à visão geral da IaaS do Azure Guias de soluções relacionadas |
Para ilustrações técnicas adicionais, clique aqui.
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 — Centro de Arquitetura do Azure
- Políticas de zona de destino do Azure
- Políticas comuns de acesso de dispositivo e identidade de confiança zero
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de