Recomendações para redes e conectividade

Artigo
10/31/2024

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

SE:06	Isole, filtre e controle o tráfego de rede nos 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 o design de rede. O foco está nos controles de segurança que podem filtrar, bloquear e detetar adversários que cruzam os limites da rede em várias profundidades da 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 da rede é uma alta prioridade para proteger ativos. Controles de segurança de rede adequados podem fornecer um elemento de defesa profunda que pode ajudar a detetar e conter ameaças e impedir que invasores entrem em sua carga de trabalho.

Definições

Vigência	Definição
Tráfego Este-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 sua 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 em regras especificadas.
Segmentação ou isolamento de rede	Uma estratégia que divide uma rede em pequenos segmentos isolados, com controlos de segurança aplicados nos limites. Esta técnica ajuda a proteger os recursos de redes hostis, como a Internet.
Transformação da rede	Um mecanismo que muta pacotes de rede para obscurecê-los.
Tráfego Norte-Sul	Tráfego de rede que se move de um limite confiável para redes externas potencialmente hostis e vice-versa.

Principais estratégias de design

A segurança de rede usa obscuridade para proteger ativos de carga de trabalho de 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. A conceção da segurança da rede baseia-se em três estratégias principais:

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

O principal limite de segurança é 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 nesta borda devem ser altamente eficazes, porque este 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 de emparelhamento. Sua arquitetura deve tirar proveito dessa medida de segurança forte e fornecida pela plataforma.

Você também pode usar outros limites lógicos, como sub-redes esculpidas dentro de 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 perspetiva de confiança zero, a filtragem verifica explicitamente todos os pontos de dados disponíveis no nível da rede. Você pode colocar regras no limite para verificar 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 apresente as características esperadas, a carga útil 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 medida de segurança. Por exemplo, você pode remover cabeçalhos HTTP para eliminar o risco de exposição. Ou você pode desativar o Transport Layer Security (TLS) em um ponto e restabelecê-lo em outro salto com um certificado gerenciado com mais rigor.

Classificar os fluxos de tráfego

O primeiro passo para classificar fluxos é estudar um esquema da sua arquitetura de carga de trabalho. A partir do esquema, determine a intenção e as características do fluxo em relação à utilidade funcional e aos aspetos operacionais de sua carga de trabalho. Use as seguintes perguntas para ajudar a classificar o fluxo:

Se a carga de trabalho precisa 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? Existem requisitos de conformidade ao nível da rede?

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

Visibilidade a partir de redes externas

Pública. Uma carga de trabalho é voltada para o público se seu aplicativo e outros componentes estiverem acessíveis a partir da Internet pública. A aplicação é exposta através de um ou mais endereços IP públicos e servidores DNS (Sistema de Nomes de Domínio) públicos.
Privado. Uma carga de trabalho é privada se só puder ser acessada por meio de uma rede privada, como uma rede virtual privada (VPN). É exposto apenas através de um ou mais endereços IP privados e, potencialmente, através de um servidor DNS privado.

Em uma rede privada, não há 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 chegam de uma rede pública. Um gateway nesse caminho pode funcionar como um ponto de transição agindo como um proxy reverso.

Sentido do tráfego

Ingresso. Ingress é o tráfego de entrada que flui para uma carga de trabalho ou seus componentes. Para ajudar a garantir a entrada, aplique o conjunto anterior de estratégias-chave. Determine qual é a origem do tráfego e se ele é esperado, permitido e seguro. Os invasores que verificam os intervalos de endereços IP do provedor de nuvem pública podem penetrar com sucesso em suas defesas se você não verificar a entrada ou implementar medidas básicas de segurança de rede.
Egresso. Egress é o tráfego de saída que flui para longe de uma carga de trabalho ou de seus componentes. Para verificar a saída, determine para onde o tráfego está indo e se o destino é esperado, permitido e seguro. O destino pode ser malicioso ou associado a riscos de exfiltração de dados.

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

Âmbito 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. Este tráfego atravessa a extremidade da sua 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.

Como exemplo, considere o fluxo de saída de uma topologia de rede hub-spoke. Você pode definir a borda de rede de sua 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 é estendido para o firewall no hub, porque 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 da 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 em profundidade, mantenha o controle de ponta a ponta dos recursos de segurança incluídos em cada salto ou que você usa quando os pacotes cruzam segmentos internos. Diferentes níveis de risco exigem diferentes métodos de remediação de riscos.

O diagrama anterior ilustra a defesa de rede em profundidade na nuvem privada. Neste diagrama, a fronteira entre os espaços de endereço IP público e privado está significativamente mais longe 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.

Nota

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 os 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, assuma 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 é o tráfego norte-sul e inclui entrada e saída. Para detetar ou bloquear ameaças, uma estratégia de borda deve mitigar o maior número possível de ataques de e para a Internet.

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

Os firewalls geralmente são singletons que são implantados por região em uma organização. Como resultado, eles são compartilhados entre cargas de trabalho e pertencentes a uma equipe central. Certifique-se de que todos os NVAs que você usa estão configurados para dar suporte às necessidades de sua carga de trabalho.
Recomendamos que você use os controles nativos do Azure tanto quanto possível.

Além de controles nativos, você também pode considerar NVAs de parceiros que fornecem recursos avançados ou especializados. Os produtos de fornecedor de firewall de parceiro e firewall de aplicativos Web estão disponíveis no 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: os recursos de parceiros 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, porque essas soluções não se integram com os controladores de malha da nuvem. Do ponto de vista dos custos, o controle nativo é preferido porque é mais barato do que as soluções de parceiros.

Quaisquer 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 de borda neste artigo.

Projetar segurança de rede virtual e sub-rede

O principal objetivo de uma nuvem privada é obscurecer os recursos da internet pública. Existem várias formas de alcançar este objetivo:

Mova para espaços de endereços IP privados, o que você pode fazer 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 de sua carga de trabalho.
Adicione controle de fluxo de rede de entrada e saída. Não permita tráfego não confiável.

Estratégia de segmentação

Para minimizar a visibilidade da rede, segmente sua rede e comece com controles de rede de 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, certifique-se de que esses serviços possam 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 comuns e funções que usam protocolos bem 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 principais estratégias 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 da Rede Virtual do Azure.

Usar controles no nível do componente

Depois de minimizar a visibilidade da sua rede, mapeie seus recursos do Azure de uma perspetiva de rede e avalie os fluxos. São possíveis os seguintes tipos de fluxos:

Tráfego planejado ou comunicação intencional entre serviços de acordo com seu projeto de arquitetura. Por exemplo, você planejou o tráfego quando sua arquitetura recomenda que o Azure Functions extraia mensagens do Barramento de Serviço do Azure.
Gerenciamento de tráfego ou comunicação que acontece 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 tráfego planejado e de gerenciamento ajuda 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 está 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.

Nota

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

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

Considere o uso de 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 da sua rede virtual. O ponto de extremidade permite que outros recursos na rede se comuniquem com o serviço PaaS através do endereço IP privado.

A comunicação com um serviço 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 a partir do endereço IP privado do componente para um ponto de extremidade privado nessa sub-rede, que então 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.

Nota

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, em seguida, 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: o Azure Private Link é um serviço pago que tem medidores para dados de entrada e saída que são processados. Você também é cobrado por pontos de extremidade privados.

Proteja-se contra ataques distribuídos de negação de serviço (DDoS)

Um ataque DDoS tenta esgotar os recursos de um aplicativo para torná-lo indisponível para usuários legítimos. Os ataques DDoS podem ter como alvo qualquer ponto de extremidade acessível publicamente através da Internet.

Um ataque DDoS é geralmente um abuso maciço, generalizado e geograficamente disperso dos recursos do seu sistema que torna difícil identificar e bloquear a fonte.

Para obter 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 seguintes serviços do Azure para adicionar recursos de defesa profunda à sua rede.

Rede Virtual do Azure

A Rede Virtual ajuda os seus recursos do Azure a comunicar de forma segura entre si, com a Internet e com redes locais.

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

A Rede Virtual oferece recursos para filtrar o tráfego. Você pode restringir o acesso no nível da rede virtual usando uma rota definida pelo usuário (UDR) 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 sobre 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 a passagem de tráfego através de um balanceador de carga ou gateway de conversão de endereços de rede (NAT). Mas estes serviços destinam-se à distribuição de tráfego e não necessariamente à segurança.

Recomendam-se as seguintes opções tecnológicas:

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

A maioria das organizações tem uma política de tunelamento forçado que força o tráfego a fluir através de um NVA.

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

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

Recomendam-se as seguintes práticas:
- Habilite as configurações de diagnóstico 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 tags de serviço FQDN. Mas quando você usá-los, use a variante regional, que permite a comunicação com todos os pontos finais do serviço.
- Use grupos IP para definir fontes que devem compartilhar as mesmas regras ao longo da vida do grupo IP. Os grupos de IP devem refletir sua estratégia de segmentação.
- Substitua a regra de permissão do FQDN da infraestrutura somente se sua carga de trabalho exigir controle absoluto de saída. A substituição dessa regra vem com uma compensação de confiabilidade, porque os requisitos da plataforma Azure mudam nos serviços.
Compensação: o Firewall do Azure pode afetar seu desempenho. Ordem de regras, quantidade, inspeção TLS e outros fatores podem causar latência significativa.

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

Risco: Para tráfego de saída, o Azure atribui um endereço IP público. Esta atribuição pode ter um impacto a jusante na sua porta de segurança externa.
Firewall de Aplicativo Web do Azure. Este serviço suporta 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 Firewall de Aplicativo Web do Azure também fornece outros recursos de segurança focados na camada 7, como limitação de taxa, regras de injeção de SQL e scripts entre sites.

Com o Firewall de Aplicativo Web do Azure, a terminação TLS é necessária, porque a maioria das verificações é baseada em cargas úteis.

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

O Firewall do Azure e o 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 Application Gateway 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 sub-rede ou placa de interface de rede (NIC). 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 entra e sai 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 do ponto de vista da saída. Para a entrada, não é permitido tráfego de entrada na Internet.

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 VPN é permitido.
- As sondas de integridade do Balanceador de Carga do Azure são permitidas.
- Todo o restante tráfego está bloqueado.
Para tráfego de saída ou saída:
- É permitido tráfego de rede virtual para destinos diretos, emparelhados e de gateway VPN.
- O tráfego para a internet é permitido.
- Todo o restante tráfego está 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 destino. Um benefício de segurança das tags de serviço é que elas são opacas para o usuário e a responsabilidade é transferida 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 semelhantes de acesso de entrada ou saída.

Risco: As gamas de etiquetas de serviço são muito amplas para que possam acomodar o maior número possível de clientes. As atualizações das etiquetas de serviço atrasam as 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 tag . Assim, neste caso, as sub-redes de redes emparelhadas têm uma linha de visão direta. A definição ampla da VirtualNetwork tag 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 tags são exclusivamente para tráfego de entrada ou saída . Outros são para ambos os tipos. As tags de entrada geralmente permitem o tráfego de todas as cargas de trabalho de hospedagem, como AzureFrontDoor.Backend, ou do Azure para dar suporte a tempos de execução de serviço, como LogicAppsManagement. Da mesma forma, as tags de saída permitem o tráfego para todas as cargas de trabalho de hospedagem ou do Azure para dar suporte a tempos de execução de serviço.

Alargar as regras tanto quanto possível. No exemplo a seguir, a regra é definida como valores específicos. Qualquer outro tipo de tráfego é negado.

Informação	Exemplo
Protocolo	Protocolo de Controle de Transmissão (TCP), UDP
Endereço IP de origem	Permitir a entrada na sub-rede a partir do intervalo> de endereços IP de <origem: 4575/UDP
Porta de origem	Permitir a entrada na sub-rede a partir da etiqueta> de <serviço: 443/TCP
Endereço IP de destino	Permitir saída da sub-rede para <destino-IP-endereço-intervalo>: 443/TCP
Porta de destino	Permitir saída da sub-rede para <a etiqueta> de serviço: 443/TCP

Para resumir:

Seja preciso ao criar regras. Permita apenas o tráfego necessário para que seu aplicativo funcione. Negue tudo 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. O 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 estejam 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 sua carga de trabalho precisar permitir o tráfego DNS para a Internet, você usaria um grupo de segurança de rede de Internet:53:UDP. Nesse caso, um invasor pode ser capaz de exfiltrar dados através do UDP na porta 53 para algum outro serviço.
Entenda que os grupos de segurança de rede podem diferir ligeiramente 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.
- Adicionar 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 a Política do Azure 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 suportar 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 de nível de serviço. Esse recurso inspeciona o tráfego de entrada para o serviço a partir de intervalos CIDR (roteamento entre domínios sem classe) especificados. Esses firewalls oferecem benefícios:

Proporcionam 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 extra.
Os firewalls emitem logs por meio do diagnóstico do Azure, 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 compilação hospedados pela Microsoft, precisará abrir o intervalo de endereços IP para todos os agentes de compilação hospedados pela Microsoft. O intervalo é então aberto para seu agente de compilação, outros locatários e adversários que possam abusar do 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, deverá habilitar o serviço. Você pode usar a Política do Azure para habilitá-la. Certifique-se de que não ativa a opção de serviços fidedignos do Azure se esta não estiver ativada por predefinição. Ao fazê-lo, todos os serviços dependentes que estão no âmbito de aplicação das regras.

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

Pontos finais privados

O Private Link fornece uma maneira de dar a uma instância PaaS um endereço IP privado. O serviço fica então inacessível através da internet. Os pontos de extremidade privados não são suportados para todas as SKUs.

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

Configure serviços vinculados a redes virtuais para entrar em contato com serviços PaaS por meio de pontos de extremidade privados, mesmo que esses serviços 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 quando 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 tempo de execução ao implementar pontos de extremidade privados. Mas considere também DevOps e preocupações de monitoramento.
Use a Política do Azure 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 da rede. Você precisa adicionar agentes auto-hospedados, caixas de salto, 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 de 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 o Serviço de Aplicativo do Azure, o Functions, o Gerenciamento de API do Azure e o Azure Spring Apps. Esse processo isola o aplicativo da Internet, de 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 nas regras de rede.

Azure Bastion

Você pode usar o Azure Bastion para se conectar a uma VM usando seu navegador e o portal do Azure. O Azure Bastion melhora a segurança das conexões RDP e SSH. Um caso de uso típico inclui a conexão com uma caixa de salto na mesma rede virtual ou uma rede virtual emparelhada. Usar o Azure Bastion elimina a necessidade de a VM ter um endereço IP público.

Azure DDoS Protection

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

SKUs de nível mais alto de 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 da camada de rede. Tecnologias como monitoramento de tráfego sempre ativo e mitigação em tempo real fornecem esse recurso.

Para obter mais informações, consulte 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 baseia-se no ambiente de Tecnologia da Informação (TI) 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 de clientes e invasores anônimos.
Acesso VPN. Um agente mal-intencionado 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 permitir uma comunicação segura.
Acesso público à aplicação. Tenha um firewall de aplicativo Web (WAF) na frente do aplicativo para protegê-lo na Camada 7 da camada OSI da rede.
Acesso do operador. O acesso remoto através da Camada 4 das camadas OSI da rede deve ser protegido. Considere usar o Firewall do Azure com recursos IDP/IDS.
Proteção contra DDoS. Tenha proteção contra DDoS para toda a sua rede virtual.
Topologia de rede. Uma topologia de rede, como hub-spoke, é mais segura e otimiza custos. A rede de hub fornece proteção de firewall centralizada para todos os raios emparelhados.
Pontos de extremidade privados: considere adicionar serviços expostos publicamente à sua rede privada usando pontos de extremidade privados. Eles criam uma placa de rede (NIC) em sua rede virtual privada e se associam ao serviço do Azure.
Comunicação TLS. Proteja os dados em trânsito comunicando-se por TLS.
Network Security Group (NSG): proteja segmentos dentro de uma VNet com NSG, um recurso gratuito que filtra a comunicação de entrada e saída TCP/UDP considerando intervalos de IP e portas. Parte do NSG é o Application Security Group (ASG) que permite criar tags para regras de tráfego para facilitar o gerenciamento.
Log Analytics. Os recursos do Azure emitem telemetria que é ingerida no Log Analytics e depois usada com uma solução SIEM como o Microsoft Sentinel para análise.
Integração com o Microsoft Sentinel. O Log Analytics está integrado com o Microsoft Sentinel e outras soluções como o Microsoft Defender for Cloud.
Microsoft Defender para Cloud. O Microsoft Defender for Cloud oferece muitas soluções de proteção de carga de trabalho, incluindo recomendações de rede para o seu ambiente.
Análise de Tráfego: Monitorize os seus controlos de rede com a Análise de Tráfego. Isso é configurado por meio do Observador de Rede, parte do Monitor do Azure, e agrega acessos de entrada e saída em suas sub-redes coletadas pelo NSG.

Arquitetura para uma carga de trabalho em contêiner

Este exemplo de arquitetura 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.

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

A comunicação com todos os serviços de PaaS é realizada através de terminais 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 por firewall.

O tráfego de gerenciamento é restrito por meio do Azure Bastion, que ajuda a fornecer conectividade RDP e SSH segura e contínua para suas VMs diretamente do portal do Azure por TLS. Os agentes de compilação 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 compilação, o que aumenta a proteção para seu código e artefatos.

Os grupos de segurança de rede no nível de 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 do 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 de 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

Partilhar via

Recomendações para redes e conectividade