Recomendações de rede e conectividade

Artigo
11/15/2023

Aplica-se a esta recomendação de lista de verificação de Segurança do Azure Well-Architected Framework:

SE:05	Isolar, filtrar e controlar o tráfego de rede entre fluxos de entrada e saída. Aplique princípios de defesa em profundidade usando controles de rede localizados em todos os limites de rede disponíveis no tráfego leste-oeste e norte-sul.

Este guia descreve as recomendações para design de rede. O foco está nos controles de segurança que podem filtrar, bloquear e detectar adversários cruzando limites de rede em várias profundidades de sua arquitetura.

Você pode fortalecer seus controles de identidade implementando medidas de controle de acesso baseadas em rede. Juntamente com o controle de acesso baseado em identidade, a segurança de rede é uma prioridade alta para proteger ativos. Os controles de segurança de rede adequados podem fornecer um elemento de defesa em profundidade que pode ajudar a detectar e conter ameaças e impedir que os invasores entrem em sua carga de trabalho.

Definições

Termo	Definição
Tráfego leste-oeste	Tráfego de rede que se move dentro de um limite confiável.
Fluxo de saída	Tráfego de carga de trabalho de saída.
Rede hostil	Uma rede que não é implantada como parte da carga de trabalho. Uma rede hostil é considerada um vetor de ameaça.
Fluxo de entrada	Tráfego de carga de trabalho de entrada.
Filtragem de rede	Um mecanismo que permite ou bloqueia o tráfego de rede com base nas regras especificadas.
Segmentação ou isolamento de rede	Uma estratégia que divide uma rede em segmentos pequenos e isolados, com controles de segurança aplicados nos limites. Essa técnica ajuda a proteger recursos de redes hostis, como a Internet.
Transformação de rede	Um mecanismo que altera pacotes de rede para obscurecê-los.
Tráfego norte-sul	Tráfego de rede que passa de um limite confiável para redes externas que são potencialmente hostis e vice-versa.

Principais estratégias de design

A segurança de rede usa a obscuridade para proteger ativos de carga de trabalho contra redes hostis. Os recursos que estão atrás de um limite de rede ficam ocultos até que os controles de limite marquem o tráfego como seguro para avançar. O design de segurança de rede é criado em três estratégias de main:

Segmento. Essa técnica isola o tráfego em redes separadas adicionando limites. Por exemplo, o tráfego de e para uma camada de aplicativo passa um limite para se comunicar com outras camadas, que têm requisitos de segurança diferentes. Camadas de segmentação realizam a abordagem de defesa em profundidade.

O limite de segurança mais importante é a borda de rede entre seu aplicativo e redes públicas. É importante definir claramente esse perímetro para que você estabeleça um limite para isolar redes hostis. Os controles nessa borda devem ser altamente eficazes, pois esse limite é sua primeira linha de defesa.

As redes virtuais fornecem um limite lógico. Por design, uma rede virtual não pode se comunicar com outra rede virtual, a menos que o limite tenha sido intencionalmente quebrado por meio do emparelhamento. Sua arquitetura deve aproveitar essa medida de segurança forte e fornecida pela plataforma.

Você também pode usar outros limites lógicos, como sub-redes esculpidas em uma rede virtual. Um benefício das sub-redes é que você pode usá-las para agrupar recursos que estão dentro de um limite de isolamento e têm garantias de segurança semelhantes. Em seguida, você pode configurar controles no limite para filtrar o tráfego.
Filtrar. Essa estratégia ajuda a garantir que o tráfego que entra em um limite seja esperado, permitido e seguro. De uma perspectiva Zero-Trust, a filtragem verifica explicitamente todos os pontos de dados disponíveis no nível da rede. Você pode colocar regras no limite para marcar para condições específicas.

Por exemplo, no nível do cabeçalho, as regras podem verificar se o tráfego se origina de um local esperado ou tem um volume esperado. Mas essas verificações não são suficientes. Mesmo que o tráfego exiba características esperadas, a carga pode não ser segura. As verificações de validação podem revelar um ataque de injeção de SQL.
Transformar. Mutar pacotes no limite como uma medida de segurança. Por exemplo, você pode remover cabeçalhos HTTP para eliminar o risco de exposição. Ou você pode desativar o TLS (Transport Layer Security) em um ponto e reestabeleçá-lo em outro salto com um certificado gerenciado com mais rigor.

Classificar os fluxos de tráfego

A primeira etapa na classificação de fluxos é estudar um esquema de sua arquitetura de carga de trabalho. No esquema, determine a intenção e as características do fluxo em relação ao utilitário funcional e aos aspectos operacionais da carga de trabalho. Use as seguintes perguntas para ajudar a classificar o fluxo:

Se a carga de trabalho precisar se comunicar com redes externas, qual deve ser o nível necessário de proximidade com essas redes?
Quais são as características de rede do fluxo, como o protocolo esperado e a origem e a forma dos pacotes? Há requisitos de conformidade no nível de rede?

Há muitas maneiras de classificar fluxos de tráfego. As seções a seguir discutem critérios comumente usados.

Visibilidade de redes externas

Público. Uma carga de trabalho será voltada para o público se seu aplicativo e outros componentes puderem ser acessados pela Internet pública. O aplicativo é exposto por meio de um ou mais endereços IP públicos e servidores DNS (Sistema de Nomes de Domínio Público).
Privado. Uma carga de trabalho será privada se ela só puder ser acessada por meio de uma rede privada, como uma VPN (rede virtual privada). Ele é exposto apenas por meio de um ou mais endereços IP privados e, potencialmente, por meio de um servidor DNS privado.

Em uma rede privada, não há nenhuma linha de visão da Internet pública para a carga de trabalho. Para o gateway, você pode usar um balanceador de carga ou firewall. Essas opções podem fornecer garantias de segurança.

Mesmo com cargas de trabalho públicas, esforce-se para manter o máximo possível da carga de trabalho privada. Essa abordagem força os pacotes a atravessar um limite privado quando eles chegam de uma rede pública. Um gateway nesse caminho pode funcionar como um ponto de transição atuando como um proxy reverso.

Direção do tráfego

Entrada. Entrada é o tráfego de entrada que flui em direção a uma carga de trabalho ou seus componentes. Para ajudar a proteger a entrada, aplique o conjunto anterior de estratégias principais. Determine qual é a fonte de tráfego e se ela é esperada, permitida e segura. Os invasores que examinam intervalos de endereços IP do provedor de nuvem pública poderão penetrar com êxito em suas defesas se você não marcar entrada ou implementar medidas básicas de segurança de rede.
Saída. A saída é o tráfego de saída que flui para longe de uma carga de trabalho ou de seus componentes. Para marcar saída, determine para onde o tráfego está indo e se o destino é esperado, permitido e seguro. O destino pode ser mal-intencionado ou associado a riscos de exfiltração de dados.

Você também pode determinar seu nível de exposição considerando a proximidade da carga de trabalho com a Internet pública. Por exemplo, a plataforma de aplicativo normalmente atende endereços IP públicos. O componente de carga de trabalho é a face da solução.

Escopo de influência

Norte-sul. O tráfego que flui entre uma rede de carga de trabalho e redes externas é o tráfego norte-sul. Esse tráfego cruza a borda da rede. As redes externas podem ser a Internet pública, uma rede corporativa ou qualquer outra rede que esteja fora do seu escopo de controle.

A entrada e a saída podem ser tráfego norte-sul.

Por exemplo, considere o fluxo de saída de uma topologia de rede hub-spoke. Você pode definir a borda de rede da carga de trabalho para que o hub seja uma rede externa. Nesse caso, o tráfego de saída da rede virtual do spoke é o tráfego norte-sul. Mas se você considerar a rede de hub dentro de sua esfera de controle, o tráfego norte-sul será estendido para o firewall no hub, pois o próximo salto é a Internet, que é potencialmente hostil.
Leste-Oeste. O tráfego que flui dentro de uma rede de carga de trabalho é o tráfego leste-oeste. Esse tipo de tráfego resulta quando os componentes em sua carga de trabalho se comunicam entre si. Um exemplo é o tráfego entre as camadas de um aplicativo de n camadas. Em microsserviços, a comunicação serviço a serviço é o tráfego leste-oeste.

Para fornecer defesa detalhadamente, mantenha o controle de ponta a ponta das funcionalidades de segurança incluídas em cada salto ou que você usa quando os pacotes cruzam segmentos internos. Diferentes níveis de risco exigem diferentes métodos de correção de risco.

O diagrama anterior ilustra a defesa de rede em profundidade na nuvem privada. Neste diagrama, a borda entre os espaços de endereço IP público e privado está significativamente mais distante da carga de trabalho do que no diagrama de nuvem pública. Várias camadas separam as implantações do Azure do espaço de endereço IP público.

Observação

A identidade é sempre o perímetro primário. O gerenciamento de acesso deve ser aplicado aos fluxos de rede. Use identidades gerenciadas ao usar o RBAC (controle de acesso baseado em função) do Azure entre componentes da rede.

Depois de classificar fluxos, execute um exercício de segmentação para identificar pontos de injeção de firewall nos caminhos de comunicação dos segmentos de rede. Ao projetar sua defesa de rede em profundidade em todos os segmentos e todos os tipos de tráfego, suponha uma violação em todos os pontos. Use uma combinação de vários controles de rede localizados em todos os limites disponíveis. Para obter mais informações, consulte Estratégias de segmentação.

Aplicar firewalls na borda

O tráfego de borda da Internet é de tráfego norte-sul e inclui entrada e saída. Para detectar ou bloquear ameaças, uma estratégia de borda deve atenuar o máximo possível de ataques de e para a Internet.

Para saída, envie todo o tráfego vinculado à Internet por meio de um único firewall que fornece supervisão, governança e controle aprimorados do tráfego. Para entrada, force todo o tráfego da Internet a passar por uma NVA (dispositivo virtual) de rede ou um firewall de aplicativo Web.

Os firewalls geralmente são singletons implantados por região em uma organização. Como resultado, eles são compartilhados entre cargas de trabalho e pertencentes a uma equipe central. Verifique se todas as NVAs que você usa estão configuradas para dar suporte às necessidades da carga de trabalho.
Recomendamos que você use os controles nativos do Azure o máximo possível.

Além dos controles nativos, você também pode considerar NVAs de parceiros que fornecem recursos avançados ou especializados. O firewall do parceiro e os produtos do fornecedor do firewall do aplicativo Web estão disponíveis em Azure Marketplace.

A decisão de usar recursos nativos em vez de soluções de parceiros deve ser baseada na experiência e nos requisitos da sua organização.

Compensação: as funcionalidades do parceiro geralmente fornecem recursos avançados que podem proteger contra ataques sofisticados, mas normalmente incomuns. A configuração de soluções de parceiros pode ser complexa e frágil, pois essas soluções não se integram aos controladores de malha da nuvem. Do ponto de vista do custo, o controle nativo é preferencial porque é mais barato do que as soluções de parceiros.

Todas as opções tecnológicas que você considerar devem fornecer controles de segurança e monitoramento para fluxos de entrada e saída. Para ver as opções disponíveis para o Azure, consulte a seção Segurança do Edge neste artigo.

Projetar segurança de rede virtual e sub-rede

O objetivo principal de uma nuvem privada é obscurecer recursos da Internet pública. Há várias maneiras de atingir essa meta:

Mova para espaços de endereço IP privados, que você pode realizar usando redes virtuais. Minimize a linha de visão da rede mesmo dentro de suas próprias redes privadas.
Minimize o número de entradas DNS públicas que você usa para expor menos da carga de trabalho.
Adicione o controle de fluxo de rede de entrada e saída. Não permita o tráfego que não é confiável.

Estratégia de segmentação

Para minimizar a visibilidade da rede, segmente sua rede e comece com controles de rede com privilégios mínimos. Se um segmento não for roteável, ele não poderá ser acessado. Amplie o escopo para incluir apenas segmentos que precisam se comunicar entre si por meio do acesso à rede.

Você pode segmentar redes virtuais criando sub-redes. Os critérios de divisão devem ser intencionais. Ao colocar serviços dentro de uma sub-rede, verifique se esses serviços podem se ver.

Você pode basear sua segmentação em muitos fatores. Por exemplo, você pode colocar diferentes camadas de aplicativo em segmentos dedicados. Outra abordagem é planejar suas sub-redes com base em funções e funções comuns que usam protocolos conhecidos.

Para obter mais informações, consulte Estratégias de segmentação.

Firewalls de sub-rede

É importante inspecionar o tráfego de entrada e saída de cada sub-rede. Use as três estratégias de main discutidas anteriormente neste artigo, em Principais estratégias de design. Verifique se o fluxo é esperado, permitido e seguro. Para verificar essas informações, defina regras de firewall baseadas no protocolo, na origem e no destino do tráfego.

No Azure, você define regras de firewall em grupos de segurança de rede. Para obter mais informações, consulte a seção Grupos de segurança de rede neste artigo.

Para obter um exemplo de um design de sub-rede, consulte Sub-redes do Azure Rede Virtual.

Usar controles no nível do componente

Depois de minimizar a visibilidade da rede, mapeie os recursos do Azure de uma perspectiva de rede e avalie os fluxos. Os seguintes tipos de fluxos são possíveis:

Tráfego planejado ou comunicação intencional entre serviços de acordo com seu design de arquitetura. Por exemplo, você planejou o tráfego quando sua arquitetura recomenda que Azure Functions efetua pull de mensagens de Barramento de Serviço do Azure.
Tráfego de gerenciamento ou comunicação que ocorre como parte da funcionalidade do serviço. Esse tráfego não faz parte do seu design e você não tem controle sobre ele. Um exemplo de tráfego gerenciado é a comunicação entre os serviços do Azure em sua arquitetura e o plano de gerenciamento do Azure.

A distinção entre o tráfego planejado e de gerenciamento ajuda você a criar controles localizados ou de nível de serviço. Tenha uma boa compreensão da origem e do destino em cada salto. Entenda especialmente como seu plano de dados é exposto.

Como ponto de partida, determine se cada serviço é exposto à Internet. Se for, planeje como restringir o acesso. Se não estiver, coloque-o em uma rede virtual.

Firewalls de serviço

Se você espera que um serviço seja exposto à Internet, aproveite o firewall de nível de serviço disponível para a maioria dos recursos do Azure. Ao usar esse firewall, você pode definir regras com base em padrões de acesso. Para obter mais informações, consulte a seção Firewalls de serviço do Azure neste artigo.

Observação

Quando o componente não for um serviço, use um firewall baseado em host, além de firewalls no nível da rede. Uma VM (máquina virtual) é um exemplo de um componente que não é um serviço.

Conectividade com serviços de PaaS (plataforma como serviço)

Considere usar pontos de extremidade privados para ajudar a proteger o acesso aos serviços de PaaS. Um ponto de extremidade privado recebe um endereço IP privado de sua rede virtual. O ponto de extremidade permite que outros recursos na rede se comuniquem com o serviço PaaS pelo endereço IP privado.

A comunicação com um serviço de PaaS é obtida usando o endereço IP público e o registro DNS do serviço. Essa comunicação ocorre pela Internet. Você pode tornar essa comunicação privada.

Um túnel do serviço paaS para uma de suas sub-redes cria um canal privado. Toda a comunicação ocorre do endereço IP privado do componente para um ponto de extremidade privado nessa sub-rede, que se comunica com o serviço PaaS.

Neste exemplo, a imagem à esquerda mostra o fluxo para pontos de extremidade expostos publicamente. À direita, esse fluxo é protegido usando pontos de extremidade privados.

Para obter mais informações, consulte a seção Pontos de extremidade privados neste artigo.

Observação

Recomendamos que você use pontos de extremidade privados em conjunto com firewalls de serviço. Um firewall de serviço bloqueia o tráfego de entrada da Internet e expõe o serviço de forma privada para usuários internos que usam o ponto de extremidade privado.

Outra vantagem de usar pontos de extremidade privados é que você não precisa abrir as portas no firewall para o tráfego de saída. Os pontos de extremidade privados bloqueiam todo o tráfego de saída na porta para a Internet pública. A conectividade é limitada aos recursos dentro da rede.

Compensação: Link Privado do Azure é um serviço pago que tem medidores para dados de entrada e saída processados. Você também é cobrado por pontos de extremidade privados.

Proteger contra ataques de DDoS (negação de serviço distribuído)

Um ataque de DDoS tenta esgotar os recursos de um aplicativo para tornar o aplicativo indisponível para usuários legítimos. Os ataques de DDoS podem ter como alvo qualquer ponto de extremidade publicamente acessível pela Internet.

Um ataque de DDoS geralmente é um abuso massivo, generalizado e geograficamente disperso dos recursos do seu sistema que dificulta identificar e bloquear a origem.

Para Suporte do Azure para ajudar a proteger contra esses ataques, consulte a seção Proteção contra DDoS do Azure neste artigo.

Facilitação do Azure

Você pode usar os serviços do Azure a seguir para adicionar recursos de defesa em profundidade à sua rede.

Rede Virtual do Azure

Rede Virtual ajuda os recursos do Azure a se comunicarem com segurança entre si, com a Internet e com as redes locais.

Por padrão, todos os recursos em uma rede virtual podem se envolver na comunicação de saída com a Internet. Mas a comunicação de entrada é restrita por padrão.

Rede Virtual oferece recursos para filtrar o tráfego. Você pode restringir o acesso no nível da rede virtual usando uma UDR (rota definida pelo usuário) e um componente de firewall. No nível da sub-rede, você pode filtrar o tráfego usando grupos de segurança de rede.

Segurança de borda

Por padrão, a entrada e a saída fluem por endereços IP públicos. Dependendo do serviço ou da topologia, você define esses endereços ou o Azure os atribui. Outras possibilidades de entrada e saída incluem passar o tráfego por meio de um balanceador de carga ou gateway nat (conversão de endereços de rede). Mas esses serviços destinam-se à distribuição de tráfego e não necessariamente à segurança.

As seguintes opções de tecnologia são recomendadas:

Firewall do Azure. Você pode usar Firewall do Azure na borda da rede e em topologias de rede populares, como redes hub-spoke e WANs virtuais. Normalmente, você implanta Firewall do Azure como um firewall de saída que atua como o portão de segurança final antes que o tráfego vá para a Internet. Firewall do Azure pode rotear o tráfego que usa protocolos não HTTP e não HTTPS, como RDP (Protocolo de Área de Trabalho Remota), Protocolo SSH (Secure Shell) e FTP (Protocolo de Transferência de Arquivos). O conjunto de recursos de Firewall do Azure inclui:
- DNAT (conversão de endereços de rede de destino) ou encaminhamento de porta.
- Detecção de assinatura do IDPS (sistema de detecção e prevenção de intrusões).
- Regras de rede de FQDN (nome de domínio totalmente qualificado), camada 3, camada 4.
Observação

A maioria das organizações tem uma política de túnel forçado que força o tráfego a fluir por meio de uma NVA.

Se você não usar uma topologia de WAN virtual, deverá implantar uma UDR com um NextHopType de Internet no endereço IP privado da NVA. As UDRs são aplicadas no nível da sub-rede. Por padrão, o tráfego de sub-rede para sub-rede não flui pela NVA.

Você também pode usar Firewall do Azure simultaneamente para entrada. Ele pode rotear o tráfego HTTP e HTTPS. Em SKUs de camadas mais altas, Firewall do Azure oferece terminação TLS para que você possa implementar inspeções no nível do conteúdo.

As seguintes práticas são recomendadas:
- Habilite diagnóstico configurações no Firewall do Azure para coletar logs de fluxo de tráfego, logs IDPS e logs de solicitação DNS.
- Seja o mais específico possível nas regras.
- Quando for prático, evite marcas de serviço FQDN. Mas ao usá-los, use a variante regional, que permite a comunicação com todos os pontos de extremidade do serviço.
- Use grupos de IP para definir fontes que devem compartilhar as mesmas regras durante a vida útil do grupo de IP. Os grupos de IP devem refletir sua estratégia de segmentação.
- Substitua a regra de permissão FQDN de infraestrutura somente se sua carga de trabalho exigir controle de saída absoluto. Substituir essa regra vem com uma compensação de confiabilidade, pois os requisitos da plataforma Azure mudam nos serviços.
Compensação: Firewall do Azure pode afetar seu desempenho. A ordem das regras, a quantidade, a inspeção de TLS e outros fatores podem causar latência significativa.

Também pode haver um impacto na confiabilidade da carga de trabalho. Ele pode enfrentar o esgotamento da porta SNAT (conversão de endereços de rede de origem). Para ajudar a superar esse problema, adicione endereços IP públicos conforme necessário.

Risco: para o tráfego de saída, o Azure atribui um endereço IP público. Essa atribuição pode ter um impacto downstream no portão de segurança externo.
Azure Firewall de Aplicativo Web. Esse serviço dá suporte à filtragem de entrada e destina-se apenas ao tráfego HTTP e HTTPS.

Ele oferece segurança básica para ataques comuns, como ameaças que o Open Worldwide Application Security Project (OWASP) identifica no documento OWASP Top 10. O Azure Firewall de Aplicativo Web também fornece outros recursos de segurança que se concentram na camada 7, como limitação de taxa, regras de injeção de SQL e scripts entre sites.

Com o Azure Firewall de Aplicativo Web, a terminação TLS é necessária, pois a maioria das verificações se baseia em conteúdos.

Você pode integrar o Azure Firewall de Aplicativo Web a roteadores, como Gateway de Aplicativo do Azure ou Azure Front Door. As implementações de Firewall de Aplicativo Web do Azure para esses tipos de roteadores podem variar.

Firewall do Azure e Firewall de Aplicativo Web do Azure não são opções mutuamente exclusivas. Para sua solução de segurança de borda, várias opções estão disponíveis. Para obter exemplos, consulte Firewall e Gateway de Aplicativo para redes virtuais.

Grupos de Segurança de Rede

Um grupo de segurança de rede é um firewall de camada 3 e camada 4 que você aplica no nível de nic (cartão de interface de rede) ou sub-rede. Os grupos de segurança de rede não são criados ou aplicados por padrão.

As regras do grupo de segurança de rede atuam como um firewall para interromper o tráfego que flui dentro e fora no perímetro de uma sub-rede. Um grupo de segurança de rede tem um conjunto de regras padrão que é excessivamente permissivo. Por exemplo, as regras padrão não definem um firewall da perspectiva de saída. Para entrada, nenhum tráfego de entrada da Internet é permitido.

Para criar regras, comece com o conjunto de regras padrão:

Para tráfego de entrada ou entrada:
- O tráfego de rede virtual de fontes diretas, emparelhadas e de gateway de VPN é permitido.
- Azure Load Balancer investigações de integridade são permitidas.
- Qualquer outro tráfego será bloqueado.
Para tráfego de saída ou saída:
- O tráfego de rede virtual para destinos diretos, emparelhados e de gateway de VPN é permitido.
- O tráfego para a Internet é permitido.
- Qualquer outro tráfego será bloqueado.

Em seguida, considere os cinco fatores a seguir:

Protocolo
Endereço IP de origem
Porta de origem
Endereço IP de destino
Porta de destino

A falta de suporte para FQDN limita a funcionalidade do grupo de segurança de rede. Você precisa fornecer intervalos de endereços IP específicos para sua carga de trabalho e eles são difíceis de manter.

Mas, para os serviços do Azure, você pode usar marcas de serviço para resumir os intervalos de endereços IP de origem e de destino. Um benefício de segurança das marcas de serviço é que elas são opacas para o usuário e a responsabilidade é descarregada para o Azure. Você também pode atribuir um grupo de segurança de aplicativo como um tipo de destino para o qual rotear o tráfego. Esse tipo de grupo nomeado contém recursos que têm necessidades de acesso de entrada ou saída semelhantes.

Risco: os intervalos de marcas de serviço são muito amplos para que acomodem a maior variedade possível de clientes. Atualizações para marcas de serviço ficam atrás de alterações no serviço.

Na imagem anterior, os grupos de segurança de rede são aplicados na NIC. O tráfego da Internet e o tráfego de sub-rede para sub-rede são negados. Os grupos de segurança de rede são aplicados com a VirtualNetwork marca. Portanto, nesse caso, as sub-redes de redes emparelhadas têm uma linha de visão direta. A definição ampla da VirtualNetwork marca pode ter um impacto significativo na segurança.

Ao usar marcas de serviço, use versões regionais quando possível, como Storage.WestUS em vez de Storage. Ao adotar essa abordagem, você limita o escopo a todos os pontos de extremidade em uma região específica.

Algumas marcas são exclusivamente para tráfego de entrada ou saída . Outros são para ambos os tipos. As marcas de entrada geralmente permitem o tráfego de todas as cargas de trabalho de hospedagem, como AzureFrontDoor.Backendou do Azure, para dar suporte a runtimes de serviço, como LogicAppsManagement. Da mesma forma, as marcas de saída permitem o tráfego para todas as cargas de trabalho de hospedagem ou do Azure para dar suporte a runtimes de serviço.

Escopo das regras o máximo possível. No exemplo a seguir, a regra é definida como valores específicos. Qualquer outro tipo de tráfego é negado.

Informações do	Exemplo
Protocolo	Protocolo de controle de transmissão (TCP), UDP
Endereço IP de origem	Permitir a entrada para a sub-rede de <source-IP-address-range>: 4575/UDP
Porta de origem	Permitir entrada para a sub-rede da <marca> de serviço: 443/TCP
Endereço IP de destino	Permitir saída da sub-rede para <destination-IP-address-range>: 443/TCP
Porta de destino	Permitir saída da sub-rede para a <marca> de serviço: 443/TCP

Para resumir:

Seja preciso ao criar regras. Permita apenas o tráfego necessário para que seu aplicativo funcione. Negar todo o resto. Essa abordagem limita a linha de visão da rede aos fluxos de rede necessários para dar suporte à operação da carga de trabalho. Dar suporte a mais fluxos de rede do que o necessário leva a vetores de ataque desnecessários e estende a área de superfície.

Restringir o tráfego não implica que os fluxos permitidos estão além do escopo de um ataque. Como os grupos de segurança de rede funcionam nas camadas 3 e 4 na pilha OSI (Open Systems Interconnection), eles contêm apenas informações de forma e direção. Por exemplo, se a carga de trabalho precisar permitir o tráfego DNS para a Internet, você usará um grupo de segurança de rede do Internet:53:UDP. Nesse caso, um invasor pode ser capaz de exfiltrar dados por meio do UDP na porta 53 para algum outro serviço.
Entenda que os grupos de segurança de rede podem ser ligeiramente diferentes uns dos outros. É fácil ignorar a intenção das diferenças. Para ter filtragem granular, é mais seguro criar grupos de segurança de rede extras. Configure pelo menos um grupo de segurança de rede.
- A adição de um grupo de segurança de rede desbloqueia muitas ferramentas de diagnóstico, como logs de fluxo e análise de tráfego de rede.
- Use Azure Policy para ajudar a controlar o tráfego em sub-redes que não têm grupos de segurança de rede.
Se uma sub-rede der suporte a grupos de segurança de rede, adicione um grupo, mesmo que seja minimamente impactante.

Firewalls de serviço do Azure

A maioria dos serviços do Azure oferece um firewall no nível do serviço. Esse recurso inspeciona o tráfego de entrada para o serviço de intervalos CIDR (roteamento entre domínios sem classe) especificados. Esses firewalls oferecem benefícios:

Eles fornecem um nível básico de segurança.
Há um impacto tolerável no desempenho.
A maioria dos serviços oferece esses firewalls sem custo adicional.
Os firewalls emitem logs por meio do diagnóstico do Azure, o que pode ser útil para analisar padrões de acesso.

Mas também há preocupações de segurança associadas a esses firewalls e há limitações associadas ao fornecimento de parâmetros. Por exemplo, se você usar agentes de build hospedados pela Microsoft, precisará abrir o intervalo de endereços IP para todos os agentes de build hospedados pela Microsoft. Em seguida, o intervalo é aberto para seu agente de build, outros locatários e adversários que podem abusar de seu serviço.

Se você tiver padrões de acesso para o serviço, que podem ser configurados como conjuntos de regras de firewall de serviço, habilite o serviço. Você pode usar Azure Policy para habilitá-lo. Certifique-se de não habilitar a opção de serviços confiáveis do Azure se ela não estiver habilitada por padrão. Isso traz todos os serviços dependentes que estão no escopo das regras.

Para obter mais informações, consulte a documentação do produto de serviços individuais do Azure.

Pontos de extremidade privados

Link Privado fornece uma maneira de dar a uma instância de PaaS um endereço IP privado. Em seguida, o serviço é inacessível pela Internet. Não há suporte para pontos de extremidade privados para todos os SKUs.

Tenha em mente as seguintes recomendações ao usar pontos de extremidade privados:

Configure serviços associados a redes virtuais para entrar em contato com serviços de PaaS por meio de pontos de extremidade privados, mesmo que esses serviços de PaaS também precisem oferecer acesso público.
Promova o uso de grupos de segurança de rede para pontos de extremidade privados para restringir o acesso a endereços IP de ponto de extremidade privados.
Sempre use firewalls de serviço ao usar pontos de extremidade privados.
Quando possível, se você tiver um serviço acessível apenas por meio de pontos de extremidade privados, remova a configuração de DNS para seu ponto de extremidade público.
Considere as preocupações de linha de visão de runtime ao implementar pontos de extremidade privados. Mas também considere as preocupações com o DevOps e o monitoramento.
Use Azure Policy para impor a configuração de recursos.

Compensação: SKUs de serviço com pontos de extremidade privados são caros. Os pontos de extremidade privados podem complicar as operações devido à obscuridade de rede. Você precisa adicionar agentes auto-hospedados, jump boxes, uma VPN e outros componentes à sua arquitetura.

O gerenciamento de DNS pode ser complexo em topologias de rede comuns. Talvez seja necessário introduzir encaminhadores DNS e outros componentes.

Injeção da rede virtual

Você pode usar o processo de injeção de rede virtual para implantar alguns serviços do Azure em sua rede. Exemplos desses serviços incluem Serviço de Aplicativo do Azure, Functions, Azure Gerenciamento de API e Azure Spring Apps. Esse processo isola o aplicativo da Internet, dos sistemas em redes privadas e de outros serviços do Azure. O tráfego de entrada e saída do aplicativo é permitido ou negado com base em regras de rede.

Azure Bastion

Você pode usar o Azure Bastion para se conectar a uma VM usando o navegador e o portal do Azure. O Azure Bastion aprimora a segurança das conexões RDP e SSH. Um caso de uso típico inclui conectar-se a uma jump box na mesma rede virtual ou em uma rede virtual emparelhada. O uso do Azure Bastion remove a necessidade de a VM ter um endereço IP público.

Proteção contra DDoS do Azure

Todas as propriedades no Azure são protegidas pela proteção de infraestrutura de DDoS do Azure sem custo adicional e sem nenhuma configuração adicional. O nível de proteção é básico, mas a proteção tem limites altos. Ele também não fornece telemetria nem alertas e é independente da carga de trabalho.

SKUs de camadas mais altas da Proteção contra DDoS estão disponíveis, mas não são gratuitos. A escala e a capacidade da rede do Azure implantada globalmente oferecem proteção contra ataques comuns de camada de rede. Tecnologias como monitoramento de tráfego always-on e mitigação em tempo real fornecem essa funcionalidade.

Para saber mais, confira Visão geral da Proteção contra DDoS do Azure.

Exemplo

Aqui estão alguns exemplos que demonstram o uso de controles de rede recomendados neste artigo.

Ambiente de TI

Este exemplo se baseia no ambiente de TI (Tecnologia da Informação) estabelecido na linha de base de segurança (SE:01). Essa abordagem fornece uma ampla compreensão dos controles de rede aplicados em vários perímetros para restringir o tráfego.

Personas de ataque de rede. Várias personas podem ser consideradas em um ataque de rede, incluindo Administradores, funcionários, clientes do cliente e invasores anônimos.
Acesso VPN. Um ator inválido pode acessar o ambiente local por meio de uma VPN ou um ambiente do Azure conectado ao ambiente local por meio de uma VPN. Configure com o protocolo IPSec para habilitar a comunicação segura.
Acesso público ao aplicativo. Tenha um WAF (firewall do aplicativo Web) na frente do aplicativo para protegê-lo na Camada 7 da camada OSI de rede.
Acesso do operador. O acesso remoto por meio da Camada 4 das camadas OSI de rede deve ser protegido. Considere usar Firewall do Azure com recursos de IDP/IDS.
Proteção contra DDoS. Tenha proteção contra DDoS para toda a VNet.
Topologia de rede. Uma topologia de rede, como hub-spoke, é mais segura e otimiza os custos. A rede do hub fornece proteção de firewall centralizada para todos os spokes emparelhados.
Pontos de extremidade privados: considere adicionar serviços expostos publicamente à sua rede privada usando pontos de extremidade privados. Eles criam uma NIC (placa de rede) em sua VNet privada e se associam ao serviço do Azure.
Comunicação TLS. Proteja os dados em trânsito comunicando-se por TLS.
NSG (Grupo de Segurança de Rede): proteja segmentos em uma VNet com NSG, um recurso gratuito que filtra a comunicação de entrada e saída TCP/UDP considerando intervalos de IP e porta. Parte do NSG é o ASG (Grupo de Segurança do Aplicativo) que permite criar marcas para regras de tráfego para facilitar o gerenciamento.
Log Analytics. Os recursos do Azure emitem telemetria ingerida no Log Analytics e, em seguida, usadas com uma solução SIEM como o Microsoft Sentinel para análise.
Integração do Microsoft Sentinel. O Log Analytics é integrado ao Microsoft Sentinel e a outras soluções, como Microsoft Defender para Nuvem.
Microsoft Defender para Nuvem. Microsoft Defender for Cloud oferece muitas soluções de proteção de carga de trabalho, incluindo recomendações de rede para seu ambiente.
Análise de Tráfego: monitore seus controles de rede com a Análise de Tráfego. Isso é configurado por meio de Observador de Rede, parte do Azure Monitor e agrega ocorrências de entrada e saída em suas sub-redes coletadas pelo NSG.

Arquitetura para uma carga de trabalho em contêineres

Esta arquitetura de exemplo combina os controles de rede descritos neste artigo. O exemplo não mostra a arquitetura completa. Em vez disso, ele se concentra em controles de entrada na nuvem privada.

Gateway de Aplicativo é um balanceador de carga de tráfego da Web que você pode usar para gerenciar o tráfego para seus aplicativos Web. Você implanta Gateway de Aplicativo em uma sub-rede dedicada que tem controles de grupo de segurança de rede e controles de firewall de aplicativo Web em vigor.

A comunicação com todos os serviços de PaaS é realizada por meio de pontos de extremidade privados. Todos os pontos de extremidade são colocados em uma sub-rede dedicada. A Proteção contra DDoS ajuda a proteger todos os endereços IP públicos configurados para um nível básico ou superior de proteção contra firewall.

O tráfego de gerenciamento é restrito por meio do Azure Bastion, o que ajuda a fornecer conectividade RDP e SSH segura e perfeita para suas VMs diretamente do portal do Azure por TLS. Os agentes de build são colocados na rede virtual para que tenham uma exibição de rede para recursos de carga de trabalho, como recursos de computação, registros de contêiner e bancos de dados. Essa abordagem ajuda a fornecer um ambiente seguro e isolado para seus agentes de build, o que aumenta a proteção para seu código e artefatos.

Os grupos de segurança de rede no nível da sub-rede dos recursos de computação restringem o tráfego de saída. O túnel forçado é usado para rotear todo o tráfego por meio de Firewall do Azure. Essa abordagem ajuda a fornecer um ambiente seguro e isolado para seus recursos de computação, o que aumenta a proteção para seus dados e aplicativos.

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.

Lista de verificação de segurança

Recomendações de rede e conectividade