Aplicar princípios de Confiança Zero a uma implantação da WAN Virtual do Azure
Com a evolução moderna da nuvem, dispositivos móveis e outros pontos de extremidade, depender apenas de firewalls corporativos e redes de perímetro não é mais suficiente. Uma estratégia de Confiança Zero 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 originada de uma rede não controlada. A rede ainda desempenha um papel importante em Confiança Zero para conectar e proteger infraestrutura, aplicativos e dados. No modelo de Confiança Zero, há três objetivos principais quando se trata de proteger suas redes:
- Esteja preparado para lidar com ataques antes que eles ocorram.
- Minimize a extensão do dano e a rapidez com que ele se espalha.
- Aumente a dificuldade de comprometer seu volume de nuvem.
A WAN Virtual do Azure permite uma arquitetura de rede de trânsito global ao habilitar uma conectividade any-to-any onipresente entre conjuntos distribuídos globalmente de cargas de trabalho de nuvem em VNets (redes virtuais), locais de branch, aplicativos SaaS e PaaS e usuários. Adotar uma abordagem de Confiança Zero na WAN Virtual do Azure é fundamental para garantir que seu backbone esteja seguro e protegido.
Este artigo fornece etapas para aplicar os princípios de Confiança Zero a uma implantação de WAN Virtual do 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 o Firewall do Azure com inspeção de protocolo TLS 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. |
| 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. | 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 pilar de identidade, como Privileged Access Management, acesso condicional e outros controles, é a maneira de cumprir esse princípio. |
| 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. | Cada VNet spoke não tem acesso a outras VNets spoke, a menos que o tráfego seja roteado pelo firewall integrado dentro de cada hub de WAN Virtual do Azure. O firewall é definido para negar por padrão, aceitando apenas o tráfego permitido por regras especificadas. Em caso de comprometimento ou violação de um aplicativo/carga de trabalho, a capacidade de disseminação é limitada, pois o Firewall do Azure realiza a inspeção do tráfego e encaminha apenas 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 Confiança Zero em um ambiente de IaaS do Azure, veja Aplicar princípios de Confiança Zero à visão geral de infraestrutura do Azure.
Para uma discussão do setor sobre Confiança Zero, veja a Publicação Especial do 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 roteamento para fornecer uma interface operacional. Alguns dos principais recursos incluem:
- Recursos de roteiros avançados
- Integração "bump-in-the-wire" de segurança por meio do Firewall do Azure ou NVAs (soluções de virtualização de rede) com suporte no hub
- ExpressRoute criptografado
Uma abordagem de Confiança Zero para WAN Virtual do Azure requer a configuração de vários serviços e componentes subjacentes da tabela de princípios de Confiança Zero listada anteriormente. Aqui está uma lista de etapas e ações:
- Implante o Firewall do Azure ou NVAs NGFW (Next Generation Firewall) com suporte em cada hub de WAN Virtual.
- Configure o roteamento de branch entre VNet e local para criar um ambiente de Confiança Zero encaminhando todo o tráfego para dispositivos de segurança nos hubs para inspeção. Configure o roteamento para fornecer filtragem e proteção para ameaças conhecidas.
- Certifique-se de que nenhum recurso nas redes spoke tenha acesso direto à internet.
- Fornecer microssegmentação de aplicativos em redes spoke, juntamente de uma estratégia de microperímetros de ingress/egress.
- 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 Confiança Zero à WAN Virtual do Azure.
A WAN Virtual do Azure pode ser implantada nos tipos Básico e Standard. A aplicação de princípios de Confiança Zero para WAN Virtual do Azure com o Firewall do Azure ou um NGFW requer o tipo Standard.
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 do Azure Premium implantada em cada hub.
- Pelo menos uma política do Azure Firewall Premium.
- VPN ponto a site (P2S) e gateways site a site (S2S) e ExpressRoute.
- Ramificações conectadas a P2S, S2S e ExpressRoute.
- Uma VNet de serviços compartilhados que contém recursos de infraestrutura principais que não podem ser implantados em um hub de WAN Virtual, como VMs DNS personalizadas ou Resolvedor Privado de DNS do Azure, controladores de domínio dos Active Directory Domain Services [AD DS], Azure Bastion e outros recursos compartilhados.
- VNets de carga de trabalho com o Gateway de Aplicativo do Azure, o WAF (firewall de aplicativo Web) do Azure e pontos de extremidade privados, se necessário.
A WAN Virtual do Azure oferece suporte à integração de um conjunto limitado de firewalls de terceiros em em hubs como uma alternativa ao Firewall do Azure nativo. Este artigo descreve apenas o Firewall do Azure. O que está incluído nos serviços compartilhados com a VNet spoke na arquitetura de referência é apenas um exemplo do que você pode implantar. A Microsoft gerencia hubs de WAN Virtual do Azure e você não pode instalar mais nada neles, exceto o que o Firewall do Azure e os NVAs com suporte permitem explicitamente.
Essa arquitetura de referência se alinha 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 design de segurança de rede. Os protocolos de roteamento são parte integrante da maioria das redes, incluindo o Azure. Você precisa proteger a infraestrutura contra os 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 a 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 prefixos permitidos sejam propagados para a rede a partir do Azure. Por exemplo, você pode:
Bloqueie prefixos de entrada 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, ele 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 30 a 32), que normalmente são incluídos em outros prefixos menos específicos e, portanto, não são necessários. A eliminação desses prefixos impede que as tabelas de roteamento local 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 o tráfego entre localizações locais (por exemplo, com tecnologias como o Alcance Global do ExpressRoute), um prefixo local sendo anunciado do Azure indicaria um loop de roteamento. Somente assumir prefixos do Azure em seus roteadores locais protegeria você contra esses tipos de loops de roteamento.
Bloqueie prefixos de saída que não estejam no local.
Se você não estiver usando a rede local para trânsito entre regiões do Azure, não deverá anunciar no Azure nenhum prefixo que não use localmente. Se você não fizer isso, corre o risco de criar loops de roteamento, especialmente dado o fato de que as implementações de eBGP na maioria dos roteadores anunciam novamente 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 o eBGP multi-path.
Arquitetura lógica
Uma WAN Virtual do Azure é uma coleção de hubs e serviços disponibilizados dentro do hub. Você pode implantar a quantidade necessária de WANs Virtuais. Em um hub de 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 na Cloud Adoption Framework.
A maioria dos recursos está contida na assinatura de conectividade. Você implanta todos os recursos da WAN Virtual em um só grupo de recursos na assinatura de conectividade, incluindo quando você estiver implantando em várias regiões. As VNets spokes do Azure estão nas assinaturas da zona de destino. Se você usar a política de herança e hierarquia do Firewall do Azure, 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 você encontrará neste artigo?
Este artigo percorre as etapas para aplicar os princípios da Confiança Zero na arquitetura de referência da WAN Virtual do Azure.
| Etapa | Tarefa | Princípios de confiança zero aplicados |
|---|---|---|
| 1 | Crie uma Política de Firewall do Azure. | Verificação explícita Pressupor a violação |
| 2 | Converta hubs de WAN Virtual do Azure em hubs protegidos. | Verificação explícita Pressupor a violação |
| 3 | Proteja o tráfego. | Verificação explícita Pressupor a violação |
| 4 | Proteja as VNets spoke. | Pressupor a violação |
| 5 | Revise o uso da criptografia. | Pressupor a violação |
| 6 | Proteja os usuários P2S. | Pressupor a violação |
| 7 | Configure o monitoramento, a auditoria e o gerenciamento. | Pressupor a violação |
Você deve executar as etapas 1 e 2 na ordem. As demais etapas podem ser feitas em qualquer ordem.
Etapa 1: crie uma política de 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 de WAN Virtual do Azure. Essa 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 dispostas em uma hierarquia pai-filho. Para um cenário clássico de hub e 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 de hub por herança. Essa etapa é opcional. Se as regras que devem ser aplicadas a cada hub forem idênticas, uma única política poderá ser aplicada.
Para Confiança Zero, 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, spoke 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 rede spoke, 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 de 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 de TLS de saída para proteção contra o 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/para ramificações locais e entre as redes WAN Virtual spokes, o que protege suas cargas de trabalho do Azure contra potencial tráfego malicioso enviado de dentro do Azure.
O sistema de detecção e prevenção de intrusões (IDPS) deve ser habilitado no modo "Alertar e Negar".
As informações sobre ameaças devem ser habilitadas no modo "Alertar e Negar".
Como parte da criação da política, você deve criar as regras de conversão de endereços de rede de destino (DNAT), 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 aplicação 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 hubs de WAN Virtual do Azure em hubs seguros
No centro da abordagem de Confiança Zero para WAN Virtual do Azure está o conceito de hub de WAN Virtual protegido (hub seguro). Um hub seguro é um hub de WAN virtual do Azure com o 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 Internet.
Recomendamos o Firewall do Azure Premium para Confiança Zero e que você o configure com a Política Premium descrita na Etapa 1.
Observação
O uso da proteção contra DDoS não é suportado com um hub seguro.
Para mais informações, veja Instalar o Firewall do Azure em um hub de WAN Virtual.
Etapa 3: proteja o tráfego
Depois de atualizar todos os hubs de WAN Virtual do Azure para hubs seguros, você deve configurar os princípios de Intenção de Roteamento e Políticas para Confiança Zero. Essa configuração permite que o Firewall do Azure em cada hub atraia e inspecione o tráfego entre spokes e ramificações no mesmo hub e entre hubs remotos. Você deve configurar as 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 habilitada. Veja um exemplo.
Quando a política de roteamento "Tráfego Privado" está habilitada, o tráfego de VNet dentro e fora do hub de 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 de WAN Virtual para VNets spoke e associar uma UDR (Rota Definida pelo Usuário) personalizada para ignorar o firewall do hub. Para evitar essa vulnerabilidade, as permissões RBAC para atribuir UDRs a sub-redes de VNet spoke devem ser restritas aos administradores de rede central e não delegadas aos proprietários da zona de destino 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".
Observação
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, um NVA de segurança suportado de terceiros pode ser usado ou um provedor 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.
Observação
As tabelas de rotas personalizadas na WAN Virtual do Azure não podem ser usadas em conjunto com Intenção e Políticas de Roteamento e não devem ser consideradas como uma opção de segurança.
Passo 4: proteja as VNets spoke
Cada hub de WAN Virtual do Azure pode ter uma ou mais VNets conectadas com emparelhamento VNet. Com base no modelo de zona de destino na Cloud Adoption Framework, cada VNet contém uma carga de trabalho, aplicativos e serviços de zona de destino 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 saída e entrada, mas não pode afetar a segurança intra-VNet. Os princípios de Confiança Zero devem ser aplicados dentro de cada VNet spoke, de acordo com as diretrizes publicadas em Aplicar princípios de Confiança Zero 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 aplicativo) para regular fluxos intra-VNet ainda é recomendado.
DMZ local: uma regra de DNS criada no firewall central dentro do hub de 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, confira Problemas conhecidos do Gerenciador de Firewall do Azure e Comparação entre a rede virtual do hub e o hub virtual seguro.
Detecção e proteção avançadas de ameaças: veja Aplicar princípios de Confiança Zero a uma rede virtual spoke. Os elementos dentro do spoke devem ser protegidos com ferramentas de proteção contra ameaças, como o Microsoft Defender para Nuvem.
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 uma ou mais redes spokes 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 spoke, os usuários podem acessar recursos em outras VNets, mas requer conexão baseada em IP disponível com o Azure Bastion Standard SKU.
- Servidores DNS personalizados: o software para servidores DNS pode ser instalado em qualquer máquina virtual e atuar como servidor DNS para todos as redes spokes na WAN Virtual do Azure. O servidor DNS deve ser instalado em uma VNet spoke que atenda a todos as outras redes spokes diretamente ou por meio do recurso Proxy DNS oferecido pelo Firewall do Azure integrado ao hub WAN Virtual.
- Resolvedor de DNS Privado do Azure: a implantação de um Resolvedor de DNS Privado do Azure tem suporte dentro de uma das VNets spoke conectadas a hubs de WAN Virtual. O Firewall do Azure integrado ao hub de 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 rede VNet spoke. 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 em um hub de WAN virtual podem ser encontradas no tráfego seguro destinado a pontos de extremidade privados no WAN Virtual do Azure.
- Zona DNS Privada do Azure (links): esse tipo de recurso não reside em uma rede virtual, mas deve estar vinculado a eles para funcionar corretamente. As zonas DNS privadas não podem ser vinculadas a hubs de WAN virtual. Em vez disso, eles devem ser conectados à VNet spoke que contém 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.
Etapa 5: revisar a criptografia
A WAN Virtual do Azure fornece algumas capacidades 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 criptografia deve ser habilitada, com base no tipo de gateway. Considere o seguinte comportamento de criptografia padrão:
O gateway de VPN WAN Virtual S2S fornece criptografia ao usar a conexão VPN IPsec/IKE (IKEv1 e IKEv2).
O gateway de VPN WAN Virtual P2S fornece criptografia ao usar a conexão VPN do usuário sobre OpenVPN ou IPsec/IKE (IKEv2).
O gateway WAN Virtual ExpressRoute não fornece criptografia, portanto, as mesmas considerações da ExpressRoute autônoma se aplicam.
Somente para circuitos de ExpressRoute provisionados sobre a ExpressRoute Direct, é possível aproveitar a criptografia MACsec fornecida pela plataforma para proteger as conexões entre seus roteadores de borda e os roteadores do Microsoft Edge.
A criptografia pode ser estabelecida usando uma conexão VPN IPsec/IKE da rede local para o Azure através do emparelhamento privado de um circuito do Azure ExpressRoute. A intenção e as políticas de roteamento agora oferecem suporte a essa configuração com etapas de configuração adicionais necessárias, conforme explicado em ExpressRoute criptografada.
Para dispositivos SD-WAN (Software-Defined Wan) de terceiros e NVAs integrados ao hub WAN Virtual, capacidades de criptografia específicas devem ser verificadas e configuradas 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 haverá nenhum serviço ou capacidade 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 em nível de aplicativo, se necessário.
Observação
As redes WAN virtuais spokes não oferecem suporte à criptografia do tipo VNet-to-VNet usando o Gateway de VPN do Azure porque um spoke é necessário para usar o gateway remoto do hub de WAN virtual.
Etapa 6: proteja os usuários P2S
A WAN Virtual do Azure é um serviço de rede que reúne muitas funcionalidades de rede, segurança e roteamento para fornecer uma interface operacional. De uma perspectiva de identidade do usuário, o único ponto de contato com a WAN Virtual está no método de autenticação usado para permitir uma VPN P2S do usuário. Vários métodos de autenticação estão disponíveis, mas recomendamos seguir os princípios gerais de Confiança Zero da autenticação do Microsoft Entra. Com o Microsoft Entra ID, você pode exigir que aMFA (Autenticação Multifator) e o Acesso Condicional apliquem princípios de Confiança Zero a dispositivos cliente e identidades do usuário.
Observação
A autenticação do Microsoft Entra está disponível apenas para gateways que usam o protocolo OpenVPN, compatível apenas com conexões de protocolo 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 contas de usuário ou grupos, 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, veja 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 e topologia adicionais podem ser obtidos usando um dashboard de monitoramento de destaque, pré-criado no portal do Azure chamado Azure Monitor Insights para WAN Virtual. Essas ferramentas de monitoramento não são específicas de segurança. O Firewall do Azure implantado em cada hub de WAN Virtual fornece o ponto de integração para Confiança Zero e monitoramento de segurança. Você deve configurar o Diagnóstico e o registro em log do 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 Confiança Zero:
A análise da política do firewall fornece insights, visibilidade centralizada e controle para o 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 por IDPS do mecanismo de firewall e recursos de informações sobre ameaças.
A Pasta de Trabalho do Firewall do Azure oferece uma tela flexível para análise de dados do Firewall do Azure. Você pode obter insights sobre eventos de Firewall do Azure, saber mais sobre suas regras de aplicativo e rede e ver estatísticas para 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 tab Investigações, verifique o tráfego negado, os fluxos de origem e destino e o relatório de informações sobre ameaças para revisar e otimizar as regras de firewall.
O Firewall do Azure também se integra ao Microsoft Defender para Nuvem e ao Microsoft Sentinel. É altamente recomendável configurar corretamente ambas as ferramentas e usá-las ativamente para Confiança Zero das seguintes maneiras:
- Com a integração do Microsoft Defender para Nuvem, 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 VNets e hubs Virtuais espalhados por diferentes regiões no 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 do Firewall do Azure fornece detecção e prevenção de ameaças. Uma vez implantada, a solução permite a detecção de ameaças personalizável integrada sobre o Microsoft Sentinel. A solução contém uma pasta de trabalho, detecções, consultas de busca e guias estratégicos.
Treinamento 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 de WAN Virtual do Azure.
Introdução à WAN Virtual do Azure
| Treinamento | Introdução à WAN Virtual do Azure |
|---|---|
|
Descrever instruções para construir uma rede de área ampla (WAN) usando serviços de rede Azure Virtual WAN definidos por software. |
Introdução ao Firewall do Azure
| Treinamento | Introdução ao Firewall do Azure |
|---|---|
|
Descreva como o Firewall do Azure protege os recursos da VNet do Azure, incluindo os recursos, as regras e as opções de implantação do Firewall do Azure, bem como a administração com o Gerenciador de Firewall do Azure. |
Introdução ao Gerenciador de Firewall do Azure
| Treinamento | Introdução ao Gerenciador de Firewall do Azure |
|---|---|
|
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 parâ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 a segurança de rede
| Treinamento | Projetar e implementar a 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, veja estes recursos no catálogo da Microsoft:
Segurança no Azure
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
- 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 do hub de WAN Virtual
- Instalação do Firewall do Azure em um hub de WAN Virtual
- O que é um hub virtual seguro?
- Como configurar políticas de roteamento do hub de 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
- Gerenciar o acesso seguro aos recursos em VNets spoke para clientes P2S
Linhas de base de segurança
Revisão de Well-Architected Framework
Segurança do Azure
- Introdução à segurança do Azure
- Diretrizes de implementação de Confiança Zero
- Visão geral do Microsoft Cloud Security Benchmark
- Criar 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 fazer o download das 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.
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