Aplicar princípios de Zero Confiança a uma implantação de WAN Virtual do Azure
Nota
Próximo Livestream Junte-se à equipe do Azure FastTrack enquanto eles discutem este artigo. 9 outubro, 2024 | 10:00 - 11:00 (UTC-07:00) Hora do Pacífico (EUA & Canadá). Registe-se aqui.
Com a evolução da nuvem moderna, dos dispositivos móveis e de outros endpoints, depender apenas de firewalls corporativos e redes de perímetro não é mais suficiente. Uma estratégia Zero Trust de ponta a ponta pressupõe que as violações de segurança são inevitáveis. Isso significa que você deve verificar cada solicitação como se fosse originária de uma rede não controlada. A rede ainda desempenha um papel importante no Zero Trust para conectar e proteger infraestrutura, aplicativos e dados. No modelo Zero Trust, há três objetivos principais quando se trata de proteger suas redes:
- Esteja pronto para lidar com ataques antes que eles aconteçam.
- Minimize a extensão dos danos e a rapidez com que se espalham.
- Aumente a dificuldade de comprometer a sua pegada na nuvem.
A WAN Virtual do Azure permite uma arquitetura de rede de trânsito global ao permitir conectividade ubíqua, de qualquer para qualquer lugar, entre conjuntos globalmente distribuídos de cargas de trabalho de nuvem em redes virtuais (VNets), sites de filiais, aplicativos SaaS e PaaS e usuários. Adotar uma abordagem Zero Trust na WAN Virtual do Azure é fundamental para garantir que seu backbone esteja seguro e protegido.
Este artigo fornece etapas para aplicar os princípios do Zero Trust a uma implantação de WAN Virtual do 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 o Firewall do Azure com inspeção TLS (Transport Layer Security) para verificar riscos e ameaças com base em todos os dados disponíveis. Os controles de Acesso Condicional destinam-se a fornecer autenticação e autorização por diversos pontos de dados e o Firewall do Azure não executa a autenticação do usuário. |
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. | O acesso do usuário está além do escopo das implantações de infraestrutura de rede do Azure. O uso de soluções de identidade, como gerenciamento de acesso privilegiado, acesso condicional e outros controles, é a maneira de cumprir esse princípio. |
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. | Cada VNet spoke não tem acesso a outras VNets spoke a menos que o tráfego seja roteado através do firewall integrado dentro de cada hub WAN Virtual do Azure. O firewall está definido para negar por padrão, permitindo apenas o tráfego permitido por regras especificadas. No caso de um comprometimento ou violação de um aplicativo/carga de trabalho, ele tem capacidade limitada de se espalhar devido ao Firewall do Azure executar inspeção de tráfego e apenas encaminhar o tráfego permitido. Somente recursos na mesma carga de trabalho são expostos à violação no mesmo aplicativo. |
Para obter mais informações sobre como aplicar os princípios de Zero Trust em um ambiente IaaS do Azure, consulte Visão geral de Aplicar princípios de Zero Trust à infraestrutura do Azure.
Para uma discussão do setor sobre Zero Trust, consulte a Publicação Especial NIST 800-207.
WAN Virtual do Azure
A WAN Virtual do Azure é um serviço de rede que reúne muitas funcionalidades de rede, segurança e encaminhamento para proporcionar uma única interface operacional. Algumas das principais características incluem:
- Recursos avançados de roteamento
- Integração de segurança "bump-in-the-wire" através da Firewall do Azure ou de Dispositivos Virtuais de Rede (NVAs) suportados no hub
- Rota Expressa Criptografada
Uma abordagem Zero Trust para a WAN Virtual do Azure requer a configuração de vários serviços e componentes subjacentes da tabela de princípios Zero Trust listada anteriormente. Aqui está uma lista de etapas e ações:
- Implante o Firewall do Azure ou NVAs de Firewall de Próxima Geração (NGFW) com suporte dentro de cada hub de WAN Virtual.
- Configure o roteamento de ramificação inter-VNet e local para criar um ambiente de Zero Trust enviando todo o tráfego para dispositivos de segurança nos hubs para inspeção. Configure o roteamento para fornecer filtragem e proteção contra ameaças conhecidas.
- Certifique-se de que nenhum recurso nos raios tenha acesso direto à Internet.
- Fornecer micro-segmentação de aplicações em redes faladas, juntamente com uma estratégia de micro-perímetros de entrada/saída.
- Fornecer observabilidade para eventos de segurança de rede.
Arquitetura de referência
O diagrama a seguir mostra uma arquitetura de referência comum que demonstra um ambiente comumente implantado e como aplicar os princípios de Zero Trust à WAN Virtual do Azure.
A WAN Virtual do Azure pode ser implantada nos tipos Basic e Standard. A aplicação dos princípios de Confiança Zero para a WAN Virtual do Azure com o Firewall do Azure ou um NGFW requer o tipo Padrão.
A WAN Virtual do Azure com arquitetura de referência de hubs seguros inclui:
- Uma única WAN virtual lógica.
- Dois hubs virtuais seguros, um por região.
- Uma instância do Firewall Premium do Azure implantada em cada hub.
- Pelo menos uma política do Azure Firewall Premium.
- Gateways VPN e ExpressRoute ponto a site (P2S) e site a site (S2S).
- Ramificações conectadas a P2S, S2S e Rota Expressa.
- Uma VNet de serviços compartilhados que contém recursos de infraestrutura principais que não podem ser implantados em um hub WAN Virtual, como VMs DNS personalizadas ou Resolvedor Privado de DNS do Azure, controladores de domínio dos Serviços de Domínio Ative Directory [AD DS], Bastião do Azure e outros recursos compartilhados.
- VNets de carga de trabalho com o Gateway de Aplicativo do Azure, o firewall de aplicativo Web do Azure (WAF) e pontos de extremidade privados, se necessário.
A WAN Virtual do Azure dá suporte à integração de um conjunto limitado de firewalls de terceiros dentro de seus hubs como uma alternativa ao Firewall do Azure nativo. Este artigo descreve apenas o Firewall do Azure. O que está incluído no VNet-Shared Services falado na arquitetura de referência é apenas um exemplo do que você pode implantar. A Microsoft gerencia os hubs WAN virtuais do Azure e você não pode instalar mais nada neles, exceto o que o Firewall do Azure e os NVAs suportados permitem explicitamente.
Essa arquitetura de referência está alinhada aos princípios de arquitetura descritos no artigo do Cloud Adoption Framework para topologia de rede WAN virtual.
Segurança de roteamento
Proteger a propagação de rotas e o isolamento do ambiente local é um elemento de segurança crítico que deve ser gerenciado.
Além da segmentação de tráfego, a segurança de roteamento é uma parte crítica de qualquer projeto de segurança de rede. Os protocolos de roteamento são parte integrante da maioria das redes, incluindo o Azure. Você precisa proteger sua infraestrutura dos riscos inerentes aos protocolos de roteamento, como configurações incorretas ou ataques mal-intencionados. O protocolo BGP usado para VPN ou ExpressRoute oferece possibilidades muito ricas de proteger sua rede contra alterações de roteamento indesejadas, que podem incluir o anúncio de rotas muito específicas ou rotas muito amplas.
A melhor maneira de proteger sua rede é configurar seus dispositivos locais com políticas de rota e mapas de rota apropriados para garantir que apenas os prefixos permitidos sejam propagados em sua rede a partir do Azure. Por exemplo, pode:
Bloqueie prefixos de entrada que são muito genéricos.
Se, devido a uma configuração incorreta, o Azure começar a enviar prefixos genéricos, como 0.0.0.0/0 ou 10.0.0.0/8, isso pode estar atraindo tráfego que, de outra forma, poderia permanecer em sua rede local.
Bloqueie prefixos de entrada muito específicos.
Em determinadas circunstâncias, você pode obter alguns prefixos IPv4 longos do Azure (comprimento do prefixo de rede de 30 a 32), que normalmente são incluídos em outros prefixos menos específicos e, portanto, não são necessários. Eliminar esses prefixos evita que suas tabelas de roteamento locais cresçam desnecessariamente.
Bloqueie prefixos de entrada que não estão no Azure, a menos que você esteja usando o Azure como uma rede de trânsito.
Se você não estiver usando o Azure para transportar tráfego entre seus locais locais (por exemplo, com tecnologias como o ExpressRoute Global Reach), um prefixo local sendo anunciado do Azure indicaria um loop de roteamento. Somente usar prefixos do Azure em seus roteadores locais o protegeria desses tipos de loops de roteamento.
Bloqueie prefixos de saída que não estejam no local.
Se você não estiver usando sua rede local para trânsito entre regiões do Azure, não deve anunciar ao Azure qualquer prefixo que não use localmente. Se não o fizer, corre o risco de criar loops de roteamento, especialmente dado o fato de que as implementações de eBGP na maioria dos roteadores reanunciam todos os prefixos em links não preferenciais. Isso tem o efeito de enviar prefixos do Azure de volta para o Azure, a menos que você tenha configurado vários caminhos do eBGP.
Arquitetura lógica
A WAN Virtual do Azure é uma coleção de hubs e serviços disponibilizados dentro de um hub. Você pode implantar quantas WANs virtuais precisar. Em um hub WAN Virtual, há vários serviços, como VPN, ExpressRoute, Firewall do Azure ou um NVA integrado de terceiros.
O diagrama a seguir mostra a arquitetura lógica da infraestrutura do Azure para uma implantação de WAN Virtual do Azure, conforme descrito no Cloud Adoption Framework.
A maioria dos recursos está contida na assinatura de conectividade. Você implanta todos os recursos da WAN Virtual em um único grupo de recursos na assinatura de conectividade, inclusive quando está implantando em várias regiões. Os porta-vozes da VNet do Azure estão nas assinaturas da zona de destino. Se você usar a política de Firewall do Azure de herança e hierarquia , a política pai e a política filho deverão estar localizadas na mesma região. Você ainda pode aplicar uma política criada em uma região em um hub seguro de outra região.
O que contém este artigo?
Este artigo descreve as etapas para aplicar os princípios do Zero Trust na arquitetura de referência da WAN Virtual do Azure.
Passo | Tarefa | Princípio(s) de confiança zero aplicado(s) |
---|---|---|
1 | Crie a política do Firewall do Azure. | Verificar explicitamente Assuma a violação |
2 | Converta seus hubs WAN virtuais do Azure em hubs protegidos. | Verificar explicitamente Assuma a violação |
3 | Proteja o seu tráfego. | Verificar explicitamente Assuma a violação |
4 | Proteja as suas redes virtuais faladas. | Assuma a violação |
5 | Reveja a sua utilização da encriptação. | Assuma a violação |
6 | Proteja os seus utilizadores P2S. | Assuma a violação |
7 | Configure o monitoramento, a auditoria e o gerenciamento. | Assuma a violação |
Você deve fazer as etapas 1 e 2 em ordem. As outras etapas podem ser feitas em qualquer ordem.
Etapa 1: Criar a política do Firewall do Azure
Para implantações autônomas do Firewall do Azure em uma arquitetura clássica de hub e spoke, pelo menos uma política do Azure deve ser criada no Gerenciador de Firewall do Azure e associada aos hubs WAN Virtual do Azure. Esta política deve ser criada e disponibilizada antes da conversão de qualquer hub. Depois que a política é definida, ela é aplicada às instâncias do Firewall do Azure na Etapa 2.
As políticas do Firewall do Azure podem ser organizadas em uma hierarquia pai-filho. Para um cenário clássico de hub and spoke ou uma WAN Virtual do Azure gerenciada, você deve definir uma política raiz com um conjunto comum de regras de segurança em toda a TI para permitir ou negar tráfego. Em seguida, para cada hub, uma política filho poderia ser definida para implementar regras específicas do hub por meio de herança. Este passo é opcional. Se as regras que devem ser aplicadas a cada hub forem idênticas, uma única política poderá ser aplicada.
Para Zero Trust, uma política de Firewall do Azure Premium é necessária e deve incluir as seguintes configurações:
Proxy DNS – Você deve configurar o Firewall do Azure como um servidor DNS personalizado para VNets spoke que protegem o DNS real que reside em um serviço compartilhado falado ou local. Os firewalls do Azure atuam como um Proxy DNS, escutam na porta UDP 53 e encaminham solicitações DNS para os servidores DNS especificados nas configurações de política. Para cada falada, você deve configurar um servidor DNS no nível da rede virtual apontando para o endereço IP interno do Firewall do Azure no Hub WAN Virtual. Você não deve conceder acesso à rede de raios e ramificações para o DNS personalizado.
A inspeção TLS deve ser habilitada para estes cenários:
Inspeção TLS de saída para proteger contra tráfego mal-intencionado enviado de um cliente interno hospedado no Azure para a Internet.
Inspeção TLS Leste-Oeste para incluir o tráfego que vai de ou para filiais locais e entre raios WAN Virtuais. Isso protege suas cargas de trabalho do Azure contra tráfego mal-intencionado potencial enviado de dentro do Azure.
O sistema de deteção e prevenção de intrusões (IDPS) deve ser ativado no modo "Alerta e negação".
O Threat Intelligence deve ser ativado no modo "Alert and Deny".
Como parte da criação da política, você deve criar as regras de Conversão de Endereço de Rede de Destino, regras de rede e regras de aplicativo necessárias para habilitar apenas os fluxos de rede para tráfego explicitamente permitido. Para habilitar a inspeção TLS para destinos selecionados, a regra de aplicativo correspondente deve ter a configuração "Inspeção TLS" habilitada. Ao criar regras em Coleções de regras, você deve usar os mais restritivos "Destino" e "Tipo de destino".
Etapa 2: converter seus hubs WAN virtuais do Azure em hubs seguros
No núcleo da abordagem Zero Trust para a WAN Virtual do Azure está o conceito de hub WAN Virtual Seguro (hub seguro). Um hub seguro é um hub WAN Virtual do Azure com um Firewall do Azure integrado. O uso de dispositivos de segurança com suporte de terceiros é suportado como uma alternativa ao Firewall do Azure, mas não é descrito neste artigo. Você pode usar esses dispositivos virtuais para inspecionar todo o tráfego Norte-Sul, Leste-Oeste e ligado à Internet.
Recomendamos o Azure Firewall Premium for Zero Trust e que você o configure com a Política Premium descrita na Etapa 1.
Nota
O uso da Proteção contra DDoS não é suportado com um hub seguro.
Para obter mais informações, consulte Instalar o Firewall do Azure em um hub WAN Virtual.
Passo 3: Proteja o seu tráfego
Depois de atualizar todos os seus hubs WAN Virtual do Azure para hubs seguros, você deve configurar a intenção de roteamento e as políticas para os princípios de confiança zero. Essa configuração permite que o Firewall do Azure em cada hub atraia e inspecione o tráfego entre raios e ramificações no mesmo hub e entre hubs remotos. Você deve configurar suas políticas para enviar "tráfego da Internet" e "tráfego privado" por meio do Firewall do Azure ou do NVA de terceiros). A opção "Inter-hub" também deve estar ativada. Eis um exemplo.
Quando a política de roteamento "Tráfego Privado" está habilitada, o tráfego de VNet dentro e fora do Hub WAN Virtual, incluindo o tráfego entre hubs, é encaminhado para o Firewall do Azure ou NVA do próximo salto especificado na política. Os usuários com privilégios RBAC (Controle de Acesso Baseado em Função) podem substituir a programação de rota WAN Virtual para VNets spoke e associar uma UDR (User Defined Route) personalizada para ignorar o firewall do hub. Para evitar esta vulnerabilidade, as permissões RBAC para atribuir UDRs a sub-redes VNet spoke devem ser restritas a administradores de rede central e não delegadas aos proprietários da zona de aterrissagem das VNets spoke . Para associar um UDR a uma VNet ou sub-rede, um usuário deve ter a função de Colaborador de Rede ou uma função personalizada com a ação ou permissão "Microsoft.Network/routeTables/join/action".
Nota
Neste artigo, o Firewall do Azure é considerado principalmente para o tráfego da Internet e o controle de tráfego privado. Para o tráfego da Internet, pode ser utilizado um NVA de segurança suportado por terceiros ou um fornecedor de Segurança como Serviço (SECaaS) de terceiros. Para tráfego privado, NVAs de segurança com suporte de terceiros podem ser usados como uma alternativa ao Firewall do Azure.
Nota
As Tabelas de Rotas Personalizadas na WAN Virtual do Azure não podem ser usadas em conjunto com a Intenção de Roteamento e Políticas e não devem ser consideradas como uma opção de segurança.
Passo 4: Proteja as suas redes virtuais spoke
Cada hub WAN Virtual do Azure pode ter uma ou mais VNets conectadas ao emparelhamento de VNet. Com base no modelo de zona de aterrissagem no Cloud Adoption Framework, cada VNet contém uma carga de trabalho de zona de aterrissagem, aplicativos e serviços que dão suporte a uma organização. A WAN Virtual do Azure gerencia a conexão, a propagação e associação de rota e o roteamento de entrada e saída, mas não pode afetar a segurança intra-VNet. Os princípios Zero Trust devem ser aplicados dentro de cada VNet spoke de acordo com as orientações publicadas em Apply Zero Trust principles to a uma rede virtual spoke e outros artigos, dependendo do tipo de recurso, como máquinas virtuais e armazenamento. Considere os seguintes elementos:
Microssegmentação: mesmo que a WAN Virtual do Azure atraia e filtre o tráfego de saída, o uso de NSGs (grupos de segurança de rede) e ASGs (grupos de segurança de aplicativos) para regular fluxos intra-VNet ainda é recomendado.
DMZ local: uma regra de DNAT criada no firewall central dentro do Hub WAN Virtual do Azure deve filtrar e permitir tráfego de entrada não http ou https. O tráfego http ou https de entrada deve ser gerenciado por um Gateway de Aplicativo do Azure local e pelo Firewall de Aplicativo Web associado.
Embora os hubs virtuais seguros da WAN Virtual do Azure ainda não ofereçam suporte à Proteção contra DDoS do Azure, o uso de DDoS para proteger pontos de extremidade voltados para a Internet em VNets spoke é possível e altamente recomendado. Para obter mais informações, consulte Problemas conhecidos do Gerenciador de Firewall do Azure e Comparação de rede virtual e hub virtual seguro.
Deteção e proteção avançadas contra ameaças: consulte Aplicar os princípios do Zero Trust a uma rede virtual falada. Os elementos dentro do spoke devem ser protegidos com ferramentas de proteção contra ameaças, como o Microsoft Defender for Cloud.
Como o hub na WAN Virtual do Azure é bloqueado e gerenciado pelo Azure, os componentes personalizados não podem ser instalados ou habilitados lá. Alguns recursos que normalmente são implantados dentro do hub, em um modelo clássico de hub e spoke, devem ser colocados em um ou mais raios que atuam como redes de recursos compartilhados. Por exemplo:
- Azure Bastion: o Azure Bastion dá suporte à WAN Virtual do Azure, mas deve ser implantado dentro de uma rede virtual spoke porque o hub é restrito e gerenciado pelo Azure. A partir do Azure Bastion falado, os usuários podem acessar recursos em outras redes virtuais, mas requer conexão baseada em IP disponível com o Azure Bastion Standard SKU.
- Servidores DNS personalizados: o software de servidor DNS pode ser instalado em qualquer máquina virtual e atuar como servidor DNS para todos os raios na WAN Virtual do Azure. O servidor DNS deve ser instalado em uma VNet spoke que atenda a todos os outros raios diretamente ou por meio do recurso Proxy DNS oferecido pelo Firewall do Azure integrado dentro do hub WAN Virtual.
- Resolvedor de DNS Privado do Azure: a implantação de um Resolvedor de DNS Privado do Azure é suportada dentro de uma das VNets spoke conectadas a hubs WAN Virtuais. O Firewall do Azure integrado dentro do hub WAN Virtual pode usar esse recurso como um DNS personalizado quando você habilita o recurso Proxy DNS.
- Pontos de extremidade privados: esse tipo de recurso é compatível com a WAN virtual, mas deve ser implantado dentro de uma VNet falada. Isso fornece conectividade a qualquer outra rede virtual ou ramificação conectada à mesma WAN Virtual, se o Firewall do Azure integrado permitir o fluxo. Instruções sobre como proteger o tráfego para pontos de extremidade privados usando o Firewall do Azure integrado dentro de um hub WAN virtual podem ser encontradas em Tráfego seguro destinado a pontos de extremidade privados na WAN Virtual do Azure.
- Zona DNS Privada do Azure (links): esse tipo de recurso não vive dentro de uma rede virtual, mas deve estar vinculado a eles para funcionar corretamente. As zonas DNS privadas não podem ser vinculadas a hubs WAN virtuais. Em vez disso, eles devem ser conectados à VNet spoke contendo servidores DNS personalizados ou a um Resolvedor de DNS Privado do Azure (recomendado) ou diretamente às VNets spoke que exigem os registros DNS dessa zona.
Passo 5: Rever a encriptação
A WAN Virtual do Azure fornece alguns recursos de criptografia de tráfego por meio de seus próprios gateways para o tráfego que entra na rede da Microsoft. Sempre que possível, a encriptação deve ser ativada, com base no tipo de gateway. Considere o seguinte comportamento de criptografia padrão:
O gateway VPN Virtual WAN S2S fornece criptografia ao usar a conexão VPN IPsec/IKE (IKEv1 e IKEv2).
O gateway VPN P2S da WAN virtual fornece criptografia ao usar a conexão VPN do usuário através de OpenVPN ou IPsec/IKE (IKEv2).
O gateway de Rota Expressa da WAN Virtual não fornece criptografia, portanto, as mesmas considerações da Rota Expressa autônoma se aplicam.
Somente para circuitos de Rota Expressa provisionados sobre o ExpressRoute Direct, é possível aproveitar a criptografia MACsec fornecida pela plataforma para proteger as conexões entre seus roteadores de borda e os roteadores de borda da Microsoft.
A criptografia pode ser estabelecida usando uma conexão VPN IPsec/IKE de sua rede local para o Azure através do emparelhamento privado de um circuito de Rota Expressa do Azure. As políticas de intenção de roteamento e roteamento agora oferecem suporte a essa configuração com etapas de configuração adicionais necessárias, conforme explicado em Rota Expressa Criptografada.
Para dispositivos WAN (SD-WAN) definidos por software de terceiros e NVAs integrados ao hub WAN virtual, os recursos de criptografia específicos devem ser verificados e configurados de acordo com a documentação do fornecedor.
Depois que o tráfego entrar na infraestrutura de rede do Azure por meio de um dos gateways ou de um SD-WAN/NVA, não há nenhum serviço ou recurso de WAN Virtual específico que forneça criptografia de rede. Se o tráfego entre um hub e sua rede virtual e hub-to-hub não estiver criptografado, você deverá usar a criptografia no nível do aplicativo, se necessário.
Nota
Os raios de WAN virtual não dão suporte à criptografia de VNet-to-VNet usando o Gateway de VPN do Azure porque um spoke é necessário para usar o gateway remoto do hub WAN Virtual.
Passo 6: Proteja os seus utilizadores P2S
A WAN Virtual do Azure é um serviço de rede que reúne muitas funcionalidades de rede, segurança e encaminhamento para proporcionar uma única interface operacional. Do ponto de vista da identidade do usuário, o único ponto de contato com a WAN Virtual está no método de autenticação usado para permitir que um usuário P2S VPN. Vários métodos de autenticação estão disponíveis, mas recomendamos seguir os princípios gerais de Zero Trust da autenticação Microsoft Entra. Com o Microsoft Entra ID, você pode exigir autenticação multifator (MFA) e o Acesso Condicional aplicar princípios de Confiança Zero a dispositivos cliente e identidades de usuário.
Nota
A autenticação do Microsoft Entra só está disponível para gateways que usam o protocolo OpenVPN, que é suportado apenas para conexões de protocolo OpenVPN e requer o Cliente VPN do Azure.
A WAN Virtual do Azure e o Firewall do Azure não fornecem roteamento e filtragem de tráfego com base em nomes de conta de usuário ou grupo, mas é possível atribuir diferentes grupos de usuários a diferentes pools de endereços IP. Em seguida, você pode definir regras no Firewall do Azure integrado para restringir usuários ou grupos com base no pool de endereços IP P2S atribuído.
Se você dividir seus usuários P2S em grupos diferentes com base nos requisitos de acesso à rede, recomendamos diferenciá-los no nível da rede e garantir que eles possam acessar apenas um subconjunto da rede interna. Você pode criar vários pools de endereços IP para a WAN Virtual do Azure. Para obter mais informações, consulte Configurar grupos de usuários e pools de endereços IP para VPNs de usuário P2S.
Etapa 7: Configurar o monitoramento, a auditoria e o gerenciamento
A WAN Virtual do Azure fornece recursos abrangentes de monitoramento e diagnóstico com o Azure Monitor. Detalhes adicionais e topologia podem ser obtidos usando um painel de monitoramento focado e pré-criado no portal do Azure chamado Azure Monitor Insights for Virtual WAN. Essas ferramentas de monitoramento não são específicas de segurança. O Firewall do Azure implantado dentro de cada hub WAN Virtual fornece o ponto de integração para Zero Trust e monitoramento de segurança. Você deve configurar o Diagnóstico e o log para o Firewall do Azure da mesma forma que os Firewalls do Azure fora da WAN Virtual.
O Firewall do Azure fornece as seguintes ferramentas de monitoramento que você deve usar para garantir a segurança e a aplicação correta dos princípios de Zero Trust:
O Azure Firewall Policy Analytics fornece informações, visibilidade centralizada e controle ao Firewall do Azure. A segurança exige que as regras de firewall adequadas estejam em vigor e sejam eficazes para proteger a infraestrutura interna. O portal do Azure resume detalhes sobre "Potenciais Fontes Maliciosas" geradas pelos IDPS do mecanismo de firewall e pelos recursos de Inteligência de Ameaças.
A Pasta de Trabalho do Firewall do Azure fornece uma tela flexível para análise de dados do Firewall do Azure. Você pode obter informações sobre eventos do Firewall do Azure, saber mais sobre seu aplicativo e regras de rede e ver estatísticas de atividades de firewall em URLs, portas e endereços. É altamente recomendável que você revise periodicamente as Estatísticas de Log do IDPS e, na guia Investigações, verifique o tráfego negado, os fluxos de origem e destino e o relatório de Inteligência de Ameaças para revisar e otimizar as regras de firewall.
O Firewall do Azure também se integra ao Microsoft Defender for Cloud e ao Microsoft Sentinel. É altamente recomendável que você configure corretamente ambas as ferramentas e as use ativamente para Zero Trust das seguintes maneiras:
- Com a integração do Microsoft Defender for Cloud, você pode visualizar o status completo da infraestrutura de rede e da segurança de rede em um só lugar, incluindo a Segurança de Rede do Azure em todas as redes virtuais e Hubs Virtuais espalhados por diferentes regiões do Azure. Com uma única olhada, você pode ver o número de Firewalls do Azure, políticas de firewall e regiões do Azure onde os Firewalls do Azure são implantados.
- Uma solução Microsoft Sentinel para integração perfeita com o Firewall do Azure fornece deteção e prevenção de ameaças. Uma vez implantada, a solução permite a deteção de ameaças personalizável integrada sobre o Microsoft Sentinel. A solução também inclui uma pasta de trabalho, deteções, consultas de caça e playbooks.
Formação para administradores
Os módulos de treinamento a seguir ajudam sua equipe com as habilidades necessárias para aplicar os princípios de Confiança Zero à implantação da WAN Virtual do Azure.
Introdução à WAN Virtual do Azure
Formação | Introdução à WAN Virtual do Azure |
---|---|
Descreva como construir uma rede de longa distância (WAN) usando serviços de rede WAN Virtual do Azure definidos por software. |
Introdução ao Firewall do Azure
Formação | Introdução ao Firewall do Azure |
---|---|
Descreva como o Firewall do Azure protege os recursos da Rede Virtual do Azure, incluindo os recursos, regras, opções de implantação e administração do Firewall do Azure com o Gerenciador de Firewall do Azure. |
Introdução ao Azure Firewall Manager
Formação | Introdução ao Azure Firewall Manager |
---|---|
Descreva se você pode usar o Gerenciador de Firewall do Azure para fornecer política de segurança central e gerenciamento de rotas para seus perímetros de segurança baseados em nuvem. Avalie se o Gerenciador de Firewall do Azure pode ajudar a proteger seus perímetros de nuvem. |
Projetar e implementar segurança de rede
Formação | Projetar e implementar segurança de rede |
---|---|
Você aprenderá a projetar e implementar soluções de segurança de rede, como DDoS do Azure, Grupos de Segurança de Rede, Firewall do Azure e Firewall de Aplicativo Web. |
Para obter mais treinamento sobre segurança no Azure, consulte estes recursos no catálogo da Microsoft:
Segurança no Azure
Passos Seguintes
Consulte estes artigos adicionais para aplicar os princípios de Zero Trust ao Azure:
- Visão geral do Azure IaaS
- Azure Virtual Desktop
- Aplicativos IaaS na Amazon Web Services
- Microsoft Sentinel e Microsoft Defender XDR
Referências
Consulte estes links para saber mais sobre os vários serviços e tecnologias mencionados neste artigo.
WAN Virtual do Azure
- Visão geral da WAN Virtual do Azure
- Como configurar políticas de roteamento de hub WAN virtual
- Instalar o Firewall do Azure em um hub WAN Virtual
- O que é um hub virtual seguro?
- Como configurar políticas de roteamento de hub WAN virtual
- Tutorial: Proteger seu hub virtual usando o Gerenciador de Firewall do Azure
- Tutorial: Proteger seu hub virtual usando o Azure PowerShell
- Compartilhar um serviço de link privado na WAN Virtual
- Gerencie o acesso seguro a recursos em VNets spoke para clientes P2S
Linhas de base de segurança
Revisão do framework bem arquitetado
Segurança do Azure
- Introdução à segurança do Azure
- Diretrizes de implementação do Zero Trust
- Visão geral do benchmark de segurança na nuvem da Microsoft
- Criando a primeira camada de defesa com os serviços de segurança do Azure
- Arquiteturas de referência de segurança cibernética da Microsoft
Ilustrações técnicas
Você pode baixar as ilustrações usadas neste artigo. Use o arquivo do Visio para modificar essas ilustrações para seu próprio uso.
Para ilustrações técnicas adicionais, clique aqui.