Aplicar os princípios do Zero Trust a uma rede virtual spoke no Azure
Resumo: Para aplicar os princípios de Zero Confiança a uma rede virtual spoke no Azure, você deve aproveitar o RBAC (Controle de Acesso Baseado em Função), isolar sub-redes e máquinas virtuais (grupos de recursos, grupos de segurança de rede e grupos de segurança de aplicativos), proteger o tráfego e os recursos dentro da VNet e dos aplicativos de máquina virtual e habilitar a deteção, o alerta e a proteção avançados de ameaças.
Este artigo ajuda você a aplicar os princípios do Zero Trust a uma rede virtual spoke (VNet) para cargas de trabalho IaaS no Azure 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 grupos de segurança de aplicativos para verificar se NICs individuais têm permissões para se comunicar por canais específicos. |
| 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. | Não habilite o acesso 3389/RDP por padrão em nenhum canal. Use as permissões de função corretas para o contexto falado. |
| 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 consegue iniciar sessão em 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. |
Este artigo faz parte de uma série de artigos que demonstram como aplicar os princípios do Zero Trust em um ambiente no Azure que inclui uma VNet spoke hospedando uma carga de trabalho baseada em máquina virtual. Para obter mais informações, consulte a Visão geral de Aplicar princípios de Zero Confiança à 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 suportar um aplicativo IaaS composto por máquinas virtuais.
- O aplicativo 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 Application Gateway contido em sua 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 para a VNet de hub.
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, um para cada camada de aplicativo
- Três grupos de segurança de aplicativos, um para cada camada de aplicativo
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 máquinas virtuais a grupos de segurança de aplicativos. A tabela a seguir descreve as recomendações para proteger essa arquitetura.
| Passo | Tarefa | Princípio(s) de confiança zero aplicado(s) |
|---|---|---|
| 1 | Use o controle de acesso baseado em função (RBAC) do Microsoft Entra ou configure funções personalizadas para recursos de rede. | Use o acesso menos privilegiado |
| 2 | Isole a infraestrutura em seu próprio grupo de recursos. | Assuma a violação |
| 3 | Crie um grupo de segurança de rede para cada sub-rede. | Use o acesso menos privilegiado Assuma a violação |
| 4 | Crie um grupo de segurança de aplicativo para cada função de máquina virtual. | Verificar explicitamente Use o acesso menos privilegiado Assuma a violação |
| 5 | Proteja o tráfego e os recursos dentro da rede virtual: |
Verificar explicitamente Use o acesso menos privilegiado Assuma a violação |
| 6 | Acesso seguro à rede virtual e ao aplicativo. | Use o acesso menos privilegiado Assuma a violação |
| 7 | Habilite a deteção, alerta e proteção avançados de ameaças. | Assuma a violação |
Etapa 1: Usar o Microsoft Entra RBAC ou configurar funções personalizadas para recursos de rede
Você pode usar funções internas do Microsoft Entra RBAC para colaboradores de rede. No entanto, outra abordagem é usar funções personalizadas. Os gerentes de rede spoke não precisam de acesso total aos recursos de rede concedidos pela função de Colaborador de Rede do Microsoft Entra RBAC, mas precisam de mais permissões do que outras funções comuns. Você pode usar uma função personalizada 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 Aterrissagem do Azure.
A função específica é a função personalizada Gerenciamento de Rede 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
Você pode criar essa função usando os scripts para as funções personalizadas ou por meio da ID do Microsoft Entra com o processo descrito em Funções personalizadas do Azure - Azure RBAC.
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 da rede spoke disponíveis em vários contextos em um grupo de recursos compartilhado, crie um grupo de recursos dedicado para ele. A arquitetura de referência suportada por este artigo 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 falado.
Com um grupo de recursos dedicado, 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 - Azure RBAC.
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 identidade empresarial.
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: Navegue até Registro 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 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.
Para obter mais informações sobre a democratização da assinatura, consulte Princípios de design da zona de aterrissagem do Azure - Cloud Adoption Framework.
Você configura o diagnóstico a partir da categoria Segurança da configuração de Diagnóstico no Azure Monitor, conforme mostrado aqui.
Consulte Configurações de diagnóstico para entender como revisar esses logs e alertá-los.
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. É recomendável aplicar um grupo de segurança de rede a cada sub-rede, que é imposta 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, pode especificar a origem e o destino, a porta e o 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 figura 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 na configuração incorreta de alguns ou de 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.
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 aplicações permitem-lhe configurar a segurança de rede como uma extensão natural da estrutura de uma aplicação, possibilitando o agrupamento de máquinas virtuais e a definição de políticas de segurança de rede com base nesses grupos. Pode reutilizar a política de segurança em escala sem a manutenção manual de endereços IP explícitos. A plataforma lida com a complexidade dos endereços IP explícitos e dos múltiplos conjuntos de regras, permitindo-lhe focar-se na lógica de negócio.
Dentro da 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 aplicativos 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 obter mais informações sobre grupos de segurança de aplicativos e como atribuí-los a máquinas virtuais, consulte Visão geral de grupos de segurança de aplicativos do Azure.
Nota
Se você estiver usando balanceadores de carga, o uso do endereço IP do balanceador de carga 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 balanceador de carga.
Etapa 5: Proteger o tráfego e os recursos dentro da rede virtual
Esta secção abrange 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 aplicativos para grupos de segurança de aplicativos
- 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 permitidas. 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 Permitir.
No grupo de segurança de rede, navegue até 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. 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 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 tenha acesso imediato aos seus recursos. Para cada padrão de tráfego, você precisará criar uma regra que o permita explicitamente e deve 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 Serviços de Domínio Ative Directory (AD DS), máquinas virtuais 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 executar uma negação de saída total, 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 lida com o tráfego fora da rede virtual.
Em seguida, você pode criar uma negação de 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 para 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 Microsoft Entra Login, Antimalware e atualizações automáticas habilitadas, você precisará permitir as seguintes conexões de saída. Muitos deles são por FQDN, o que significa que o Firewall do Azure é necessário para regras FQDN ou você fará um plano mais complexo. O Firewall do Azure é recomendado.
Aviso
Em vez disso, podemos movê-los para a rede de 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 aplicativos 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 aplicativos para definir padrões de tráfego de rede nos grupos de segurança de rede para uma VNet spoke que é usada junto com uma VNet de hub. Esta é a configuração recomendada.
Como outro exemplo, aqui está uma configuração para uma VNet spoke autônoma na qual o Web Application Firewall é colocado na sub-rede do Application Gateway da VNet spoke .
Você precisa das seguintes regras de grupo de segurança de rede:
- Permitir o tráfego de internet na sub-rede APP GW (HTTPS 443).
- Permitindo 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 balanceador de carga da camada de aplicativo (HTTPS 443).
- Permitir o tráfego do balanceador de carga da camada de aplicativo para as máquinas virtuais da camada de aplicativo (HTTPS 443).
- Permitir o tráfego das máquinas virtuais da camada de aplicativo para o balanceador de carga da camada de dados (SQL 1433).
- Permitindo o tráfego do balanceador de carga da camada de dados para as máquinas virtuais da camada de dados (SQL 1433).
- Permitindo 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 para as regras que limitam o tráfego de rede para uma única camada de aplicativo.
Regra 5 - Permitir o tráfego de máquinas virtuais da camada de aplicativo para o balanceador de carga 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:
- Fonte: Application Security Group
- Grupos de segurança de aplicativos de origem: selecione seu grupo de segurança de aplicativos de 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ê 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)
- Destino: Endereços IP
- Endereços IP de destino/intervalos CIDR: o IP explícito do balanceador de carga
- Você precisa usar o IP explícito aqui porque não pode associar um balanceador de carga a um grupo de segurança de aplicativo.
- Você pode planejar seu esquema IP ou implantar o balanceador de carga e consultar o IP atribuído.
- Serviço: MS SQL
- Intervalos de portas de destino: Este é preenchido automaticamente para a porta 1433
- Protocolo: Este é selecionado automaticamente para TCP
- Ação: Permitir
- Prioridade: um valor entre 100 e 4096. Você pode começar com 105.
- Nome: Allow-App-Tier-to-Data-LB-Inbound
- Descrição: Permite o acesso de entrada do balanceador de carga da camada de dados às máquinas virtuais da camada de aplicativo.
Você notará após a conclusão que há um ícone azul para alertas informativos sobre a regra. Ao clicar na regra, obtém-se a seguinte mensagem:
- "As regras que usam grupos de segurança de aplicativos só podem ser aplicadas quando os grupos de segurança de aplicativos estão associados a interfaces de rede na mesma rede virtual."
Eis um exemplo.
A regra só se aplica quando este grupo de segurança da aplicação é utilizado nesta rede.
Finalmente, 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 balanceador de carga da camada de dados para 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: Endereço IP
- Endereço IP de origem: O endereço IP do balanceador de carga
- Intervalos de portas de origem: 1433
- Destino: Grupo de segurança do aplicativo
- Grupos de segurança de aplicativos de destino: selecione seu grupo de segurança de aplicativos da camada de dados
- Serviço: MS SQL
- Intervalos de portas de destino: Este é preenchido automaticamente para a porta 1433.
- Protocolo: Este é selecionado automaticamente para TCP.
- Ação: Permitir
- Prioridade: um valor entre 100 e 4096. 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 balanceador de carga 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 feito no exemplo, alterando Entrada para Saída.
Regra 7 - Permitir 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 do aplicativo
- Grupos de segurança de aplicativos de destino: selecione seu grupo de segurança de aplicativos da camada de dados
- Intervalos de portas de origem: 1433
- Destino: Grupos de segurança de aplicativos
- Grupos de segurança de aplicativos de destino: selecione seu grupo de segurança de aplicativos da camada de dados
- Serviço: MS SQL
- Intervalos de portas de destino: Este é preenchido automaticamente para a porta 1433.
- Protocolo: Este é selecionado automaticamente para TCP.
- Ação: Permitir
- Prioridade: um valor entre 100 e 4096. Você pode começar com 105.
- Nome: Allow-SQL-VM-to-SQL-VM-Inbound
- Descrição: Permite o acesso de entrada entre máquinas virtuais de 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 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, você precisa planejar o tráfego de gerenciamento. No entanto, o tráfego de gerenciamento geralmente se origina fora da VNet falada. São necessárias regras adicionais. Primeiro, você precisará entender as portas e fontes específicas de onde virá o tráfego de gerenciamento. Geralmente, todo o tráfego de gerenciamento deve fluir de um firewall ou outro NVA localizado na rede de hub para o falado.
Consulte a arquitetura de referência completa no artigo de visão geral Apply Zero Trust to Azure IaaS.
Isso varia de acordo com suas necessidades específicas de gerenciamento. No entanto, as regras sobre os dispositivos de firewall e as regras sobre o 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 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 ocorrendo 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 que é criado.
Nota
- A conta de armazenamento deve seguir as orientações da conta de armazenamento Zero Trust.
- O acesso aos logs deve ser restrito conforme necessário.
- Eles também devem fluir para o Log Analytics e o Sentinel, conforme necessário.
Proteja o tráfego da Web de entrada com IDPS
Além dos controles em sua rede virtual falada, você também pode usar um Firewall do Azure para aplicar inspeção adicional. Enquanto a função Web Application Firewall para Azure Front Door e Application Gateway inspeciona o tráfego em busca de ataques Web comuns, o uso do Firewall do Azure pode fornecer 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, recomenda-se rotear o tráfego do seu 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 registros. 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 Aplicativos. Para obter mais orientações sobre como configurar esse comportamento, consulte Configurar o Firewall Premium do Azure para Zero Trust.
Etapa 6: Proteger o acesso à rede virtual e ao aplicativo
A proteção do acesso à rede virtual e ao aplicativo inclui:
- Protegendo o tráfego dentro do ambiente do Azure para o aplicativo.
- Usando autenticação multifator e políticas de acesso condicional para acesso do usuário ao aplicativo.
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. 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 do hub à rede virtual, consulte Aplicar princípios de confiança zero a uma rede virtual de hub no Azure.
Usando autenticação multifator e políticas de Acesso Condicional para acesso do usuário ao aplicativo
O artigo Apply Zero Trust principles to virtual machines recomenda como proteger solicitações de acesso diretamente a máquinas virtuais com autenticação multifator e acesso condicional. Essas solicitações são provavelmente de administradores e desenvolvedores. O próximo passo é 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 identidade e acesso ao dispositivo.
Ao configurar a autenticação multifator com acesso condicional e políticas relacionadas, use o conjunto de políticas recomendado para Zero Trust como guia. Isso inclui políticas de "Ponto de partida" que não exigem 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 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 já pode estar protegida pelo Microsoft Defender for Cloud (MDC), 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 Microsoft 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 o Adaptive Network Hardening para ajudá-lo à medida que você progride em sua jornada de Segurança na Nuvem. Para visualizar melhor onde o Defender for Cloud se encaixa no cenário de segurança da Microsoft, consulte Arquiteturas de referência de segurança cibernética da Microsoft.
Este artigo não discute o Microsoft Defender for Cloud em detalhes, mas é importante entender que o Microsoft Defender for Cloud funciona com base em Políticas do Azure e logs ingeridos em um espaço de trabalho do Log Analytics. Uma vez ativada na(s) assinatura(s) 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 pontuação segura da sua organização.
Aqui está um exemplo no portal do Microsoft Defender for Cloud.
Se você optar por integrar um dos planos do Defender for Cloud que oferecem proteções avançadas de carga de trabalho, ele incluirá recomendações de proteção de rede adaptável para melhorar suas regras de grupo de segurança de rede existentes. Eis um exemplo.
Você pode aceitar a recomendação selecionando Enforce, que cria uma nova regra de grupo de segurança de rede ou modifica 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
- Proteja o acesso aos seus aplicativos usando os serviços de identidade do Azure
Para obter mais treinamento sobre segurança no Azure, consulte estes recursos no catálogo da Microsoft:
Segurança no Azure | Microsoft Learn
Passos Seguintes
Consulte estes artigos adicionais para aplicar os princípios de Zero Trust ao Azure:
- Visão geral do Azure IaaS
- Área de Trabalho Virtual do Azure
- WAN Virtual do Azure
- Aplicativos IaaS na Amazon Web Services
- Microsoft Sentinel e Microsoft Defender XDR
Ilustrações técnicas
Este cartaz fornece uma visão rápida e de página única 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 Zero Trust aplicado.
| Item | Description |
|---|---|
 PDF | Visio Atualizado em março de 2024 |
Use esta ilustração junto com este artigo: Aplicar princípios de Zero Confiança à visão geral de IaaS do Azure Guias de solução relacionados |
Este cartaz fornece as arquiteturas lógicas e de referência e as configurações detalhadas dos componentes separados do Zero Trust para IaaS do Azure. Use as páginas deste cartaz para departamentos ou especialidades de TI separados ou, com a versão do arquivo do Microsoft Visio, personalize os diagramas para sua infraestrutura.
| Item | Description |
|---|---|
 PDF | Visio Atualizado em março de 2024 |
Use estes diagramas juntamente com os artigos que começam aqui: Aplicar princípios de Zero Trust à visão geral de IaaS do Azure Guias de solução relacionados |
Para ilustrações técnicas adicionais, clique aqui.
Referências
- Adote a segurança proativa com o Zero Trust
- Proteja as redes com Zero Trust
- Rede de confiança zero para aplicativos Web com o Firewall do Azure e o Gateway de Aplicativo - Central de Arquitetura do Azure
- Políticas da Zona de Aterrissagem do Azure
- Políticas comuns de identidade e dispositivo Zero Trust
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