Recomendações para rede e conectividade

Artigo
11/15/2023

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

SE:05	Isolar, filtrar e controlar o tráfego de rede nos fluxos de entrada e saída. Aplique princípios de defesa em profundidade através da utilização de controlos de rede localizados em todos os limites de rede disponíveis em todo o tráfego este-oeste e norte-sul.

Este guia descreve as recomendações para a estrutura da rede. O foco está nos controlos de segurança que podem filtrar, bloquear e detetar adversários que atravessam limites de rede em várias profundidades da sua arquitetura.

Pode reforçar os seus controlos de identidade ao implementar medidas de controlo de acesso baseadas na rede. Juntamente com o controlo de acesso baseado em identidade, a segurança de rede é uma prioridade elevada para proteger recursos. Os controlos de segurança de rede adequados podem fornecer um elemento de defesa em profundidade que pode ajudar a detetar e conter ameaças e impedir que os atacantes obtenham entrada na sua carga de trabalho.

Definições

Termo	Definição
Tráfego leste-oeste	Tráfego de rede que se move dentro de um limite fidedigno.
Fluxo de saída	Tráfego de carga de trabalho de saída.
Rede hostil	Uma rede que não é implementada 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 segmentos pequenos e isolados, com controlos de segurança aplicados nos limites. Esta técnica ajuda a proteger recursos de redes hostis, como a Internet.
Transformação de rede	Um mecanismo que muta pacotes de rede para os ocultar.
Tráfego norte-sul	Tráfego de rede que se move de um limite fidedigno para redes externas que são potencialmente hostis e vice-versa.

Principais estratégias de design

A segurança de rede utiliza a obscuridade para proteger os recursos de carga de trabalho de redes hostis. Os recursos que estão atrás de um limite de rede estão ocultos até que os controlos de limite marquem o tráfego como seguro para avançar. A estrutura de segurança de rede baseia-se em três estratégias principais:

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

O principal limite de segurança é o limite de rede entre a aplicação e as redes públicas. É importante definir claramente este perímetro para que estabeleça um limite para isolar redes hostis. Os controlos nesta margem têm de ser altamente eficazes, uma vez que este limite é a sua primeira linha de defesa.

As redes virtuais fornecem um limite lógico. Por predefinição, uma rede virtual não consegue comunicar com outra rede virtual, a menos que o limite tenha sido intencionalmente quebrado através do peering. A sua arquitetura deve tirar partido desta medida de segurança segura fornecida pela plataforma.

Também pode utilizar outros limites lógicos, como sub-redes entalhadas numa rede virtual. Uma vantagem das sub-redes é que pode utilizá-las para agrupar recursos que estão dentro de um limite de isolamento e têm garantias de segurança semelhantes. Em seguida, pode configurar controlos no limite para filtrar o tráfego.
Filtrar. Esta estratégia ajuda a garantir que o tráfego que entra num limite é esperado, permitido e seguro. Numa perspetiva Zero-Trust, a filtragem verifica explicitamente todos os pontos de dados disponíveis ao nível da rede. Pode colocar regras no limite para verificar se existem condições específicas.

Por exemplo, ao nível do cabeçalho, as regras podem verificar se o tráfego tem origem numa localização esperada ou tem um volume esperado. Mas estes cheques não são suficientes. Mesmo que o tráfego apresente as características esperadas, o payload poderá não ser seguro. 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, pode remover cabeçalhos HTTP para eliminar o risco de exposição. Em alternativa, pode desativar o Transport Layer Security (TLS) a certa altura e restaurê-lo noutro salto com um certificado gerido de forma mais rigorosa.

Classificar os fluxos de tráfego

O primeiro passo para classificar fluxos é estudar um esquema da arquitetura da carga de trabalho. A partir do esquema, determine a intenção e as características do fluxo relativamente ao utilitário funcional e aos aspetos operacionais da carga de trabalho. Utilize as seguintes perguntas para ajudar a classificar o fluxo:

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

Existem muitas formas de classificar os fluxos de tráfego. As secções seguintes abordam os critérios utilizados frequentemente.

Visibilidade de redes externas

Público. Uma carga de trabalho é pública se a sua aplicação 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 (Public Domain Name System).
É privado. Uma carga de trabalho é privada se só puder ser acedida através de uma rede privada, como uma rede privada virtual (VPN). É exposto apenas através de um ou mais endereços IP privados e potencialmente através de um servidor DNS privado.

Numa rede privada, não existe nenhuma linha de visão da Internet pública para a carga de trabalho. Para o gateway, pode utilizar um balanceador de carga ou firewall. Estas opções podem fornecer garantias de segurança.

Mesmo com cargas de trabalho públicas, esforce-se por manter o máximo possível de cargas de trabalho privadas. Esta 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 ao agir como um proxy inverso.

Direção do tráfego

Entrada. A entrada é o tráfego de entrada que flui para uma carga de trabalho ou para os respetivos componentes. Para ajudar a proteger a entrada, aplique o conjunto anterior de estratégias-chave. Determine qual é a origem de tráfego e se é esperada, permitida e segura. Os atacantes que analisam os intervalos de endereços IP do fornecedor de cloud pública podem penetrar com êxito nas suas defesas se não verificar a 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 dos respetivos componentes. Para verificar a saída, determine para onde se dirige o tráfego e se o destino é esperado, permitido e seguro. O destino pode ser malicioso ou associado a riscos de exfiltração de dados.

Também pode determinar o seu nível de exposição ao considerar a proximidade da carga de trabalho com a Internet pública. Por exemplo, a plataforma de aplicações normalmente serve endereços IP públicos. O componente da carga de trabalho é o rosto da solução.

Âmbito de influência

Norte-sul. O tráfego que flui entre uma rede de carga de trabalho e redes externas é tráfego norte-sul. Este tráfego atravessa o limite da sua rede. As redes externas podem ser a Internet pública, uma rede empresarial ou qualquer outra rede fora do seu âmbito de controlo.

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. Pode definir o limite 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. No entanto, se considerar a rede do hub dentro da sua esfera de controlo, o tráfego norte-sul é expandido para a firewall no hub, porque o próximo salto é a Internet, que é potencialmente hostil.
Este-oeste. O tráfego que flui dentro de uma rede de carga de trabalho é tráfego este-oeste. Este tipo de tráfego resulta quando os componentes na carga de trabalho comunicam entre si. Um exemplo é o tráfego entre as camadas de uma aplicação de n camadas. Nos microsserviços, a comunicação serviço a serviço é o tráfego este-oeste.

Para fornecer defesa em profundidade, mantenha o controlo ponto a ponto das acessibilidades de segurança incluídas em cada salto ou que utiliza quando os pacotes cruzam segmentos internos. Diferentes níveis de risco requerem diferentes métodos de remediação de risco.

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

Nota

A identidade é sempre o perímetro principal. A gestão de acesso tem de ser aplicada aos fluxos de rede. Utilize identidades geridas quando utilizar o controlo de acesso baseado em funções (RBAC) do Azure entre componentes da sua 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. Quando conceber a defesa de rede em profundidade em todos os segmentos e em todos os tipos de tráfego, assuma uma falha em todos os pontos. Utilize uma combinação de vários controlos de rede localizados em todos os limites disponíveis. Para obter mais informações, veja Estratégias de segmentação.

Aplicar firewalls no edge

O tráfego de limite da Internet é tráfego norte-sul e inclui entrada e saída. Para detetar ou bloquear ameaças, uma estratégia edge tem de mitigar o maior número possível de ataques de e para a Internet.

Para saída, envie todo o tráfego vinculado à Internet através de uma única firewall que proporciona uma maior supervisão, governação e controlo do tráfego. Para a entrada, force todo o tráfego da Internet a passar por uma aplicação virtual de rede (NVA) ou uma firewall de aplicações Web.

Normalmente, as firewalls são singletons que são implementadas por região numa organização. Como resultado, são partilhados entre cargas de trabalho e pertencem a uma equipa central. Certifique-se de que todas as NVAs que utilizar estão configuradas para suportar as necessidades da sua carga de trabalho.
Recomendamos que utilize os controlos nativos do Azure o máximo possível.

Além dos controlos nativos, também pode considerar NVAs de parceiros que fornecem funcionalidades avançadas ou especializadas. Os produtos de fornecedor de firewall de aplicações Web e firewall de parceiros estão disponíveis no Azure Marketplace.

A decisão de utilizar funcionalidades nativas em vez de soluções de parceiros deve basear-se na experiência e nos requisitos da sua organização.

Desvantagem: muitas vezes, as capacidades dos parceiros fornecem funcionalidades avançadas que podem proteger contra ataques sofisticados, mas normalmente invulgares. A configuração de soluções de parceiros pode ser complexa e frágil, uma vez que estas soluções não se integram com os controladores de recursos de infraestrutura da cloud. Do ponto de vista dos custos, o controlo nativo é preferido porque é mais barato do que as soluções de parceiros.

Quaisquer opções tecnológicas que considere devem fornecer controlos de segurança e monitorização para fluxos de entrada e saída. Para ver as opções disponíveis para o Azure, veja a secção Segurança do Edge neste artigo.

Conceber a segurança da rede virtual e da sub-rede

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

Deslocar-se para espaços de endereços IP privados, o que pode realizar com redes virtuais. Minimize a linha de visão de rede mesmo dentro das suas próprias redes privadas.
Minimize o número de entradas DNS públicas que utiliza para expor menos da carga de trabalho.
Adicionar controlo de fluxo de rede de entrada e saída. Não permita tráfego que não seja fidedigno.

Estratégia de segmentação

Para minimizar a visibilidade da rede, segmente a sua rede e comece com controlos de rede com menos privilégios. Se um segmento não for encaminhável, não poderá ser acedido. Alargar o âmbito para incluir apenas segmentos que precisam de comunicar entre si através do acesso à rede.

Pode segmentar redes virtuais ao criar sub-redes. Os critérios de divisão devem ser intencionais. Quando colocar os serviços dentro de uma sub-rede, certifique-se de que esses serviços se conseguem ver uns aos outros.

Pode basear a segmentação em muitos fatores. Por exemplo, pode colocar diferentes camadas de aplicação em segmentos dedicados. Outra abordagem é planear as suas sub-redes com base em funções e funções comuns que utilizam protocolos bem conhecidos.

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

Firewalls de sub-rede

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

No Azure, pode definir regras de firewall em grupos de segurança de rede. Para obter mais informações, veja a secção Grupos de segurança de rede neste artigo.

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

Utilizar controlos ao nível do componente

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

Tráfego planeado ou comunicação intencional entre serviços de acordo com a estrutura da arquitetura. Por exemplo, planeou o tráfego quando a sua arquitetura recomenda que Funções do Azure extraia mensagens de Azure Service Bus.
Tráfego de gestão ou comunicação que ocorre como parte da funcionalidade do serviço. Este tráfego não faz parte da sua estrutura e não tem controlo sobre o mesmo. Um exemplo de tráfego gerido é a comunicação entre os serviços do Azure na sua arquitetura e o plano de gestão do Azure.

A distinção entre o tráfego planeado e de gestão ajuda-o a criar controlos localizados ou ao nível do serviço. Tenha uma boa compreensão da origem e do destino em cada salto. Compreenda especialmente como o seu plano de dados é exposto.

Como ponto de partida, determine se cada serviço está exposto à Internet. Se for, planeie como restringir o acesso. Se não estiver, coloque-a numa rede virtual.

Firewalls de serviço

Se espera que um serviço seja exposto à Internet, tire partido da firewall ao nível do serviço que está disponível para a maioria dos recursos do Azure. Quando utiliza esta firewall, pode definir regras com base em padrões de acesso. Para obter mais informações, veja a secção Firewalls do serviço do Azure neste artigo.

Nota

Quando o componente não for um serviço, utilize uma firewall baseada no anfitrião para além das firewalls ao nível da rede. Uma máquina virtual (VM) é um exemplo de um componente que não é um serviço.

Conectividade aos serviços PaaS (plataforma como serviço)

Considere utilizar pontos finais privados para ajudar a proteger o acesso aos serviços PaaS. É atribuído um endereço IP privado à rede virtual a um ponto final privado. O ponto final permite que outros recursos na rede comuniquem com o serviço PaaS através do endereço IP privado.

A comunicação com um serviço PaaS é obtida com o endereço IP público e o registo DNS do serviço. Essa comunicação ocorre através da Internet. Pode tornar essa comunicação privada.

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

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

Para obter mais informações, consulte a secção Pontos finais privados neste artigo.

Nota

Recomendamos que utilize pontos finais privados em conjunto com as firewalls do serviço. Uma firewall de serviço bloqueia o tráfego de entrada da Internet e, em seguida, expõe o serviço de forma privada aos utilizadores internos que utilizam o ponto final privado.

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

Contrapartida: Azure Private Link é um serviço pago que tem medidores para dados de entrada e saída processados. Também lhe são cobrados pontos finais privados.

Proteger contra ataques denial of service distribuídos (DDoS)

Um ataque DDoS tenta esgotar os recursos de uma aplicação para tornar a aplicação indisponível para utilizadores legítimos. Os ataques DDoS podem visar qualquer ponto final publicamente acessível através da Internet.

Um ataque DDoS é normalmente um abuso maciço, generalizado e geograficamente disperso dos recursos do seu sistema que dificulta a identificação e o bloqueio da origem.

Para suporte do Azure ajudar a proteger contra estes ataques, veja a secção Azure DDoS Protection neste artigo.

Facilitação do Azure

Pode utilizar os seguintes serviços do Azure para adicionar capacidades de defesa em profundidade à sua rede.

Rede Virtual do Azure

Rede Virtual ajuda os seus recursos do Azure a comunicarem entre si, com a Internet e com as redes no local em segurança.

Por predefinição, todos os recursos numa rede virtual podem interagir com a comunicação de saída com a Internet. Mas a comunicação de entrada é restrita por predefinição.

Rede Virtual oferece funcionalidades para filtrar o tráfego. Pode restringir o acesso ao nível da rede virtual com uma rota definida pelo utilizador (UDR) e um componente de firewall. Ao nível da sub-rede, pode filtrar o tráfego através de grupos de segurança de rede.

Segurança do Edge

Por predefinição, ambos os fluxos de entrada e saída são transmitidos através de endereços IP públicos. Consoante o serviço ou a topologia, pode definir estes endereços ou o Azure atribui-os. Outras possibilidades de entrada e saída incluem a passagem de tráfego através de um balanceador de carga ou de um gateway de tradução de endereços de rede (NAT). Mas estes serviços destinam-se à distribuição de tráfego e não necessariamente à segurança.

São recomendadas as seguintes opções tecnológicas:

Azure Firewall. Pode utilizar Azure Firewall na periferia da rede e em topologias de rede populares, como redes hub-spoke e WANs virtuais. Normalmente, implementa Azure Firewall como uma firewall de saída que atua como a porta de segurança final antes de o tráfego ir para a Internet. Azure Firewall podem encaminhar o tráfego que utiliza protocolos não HTTP e não HTTPS, tais como protocolo RDP (Remote Desktop Protocol), Secure Shell Protocol (SSH) e Protocolo FTP (File Transfer Protocol). O conjunto de funcionalidades do Azure Firewall inclui:
- Tradução de endereços de rede de destino (DNAT) ou reencaminhamento de portas.
- Deteção de assinaturas do sistema de deteção e prevenção de intrusões (IDPS).
- Regras de rede de nome de domínio completamente qualificado (FQDN) de camada 3, camada 4 e forte.
Nota

A maioria das organizações tem uma política de túnel forçada que força o tráfego a fluir através de uma NVA.

Se não utilizar uma topologia de WAN virtual, tem de implementar uma UDR com um NextHopType de Internet no endereço IP privado da NVA. As UDRs são aplicadas ao nível da sub-rede. Por predefinição, o tráfego da sub-rede para a sub-rede não flui através da NVA.

Também pode utilizar Azure Firewall em simultâneo para a entrada. Pode encaminhar tráfego HTTP e HTTPS. Em SKUs de escalão superior, o Azure Firewall oferece a terminação TLS para que possa implementar inspeções ao nível do payload.

Recomenda-se as seguintes práticas:
- Ative as definições de diagnóstico no Azure Firewall para recolher registos de fluxo de tráfego, registos IDPS e registos de pedidos DNS.
- Seja o mais específico possível nas regras.
- Quando for prático, evite etiquetas de serviço FQDN. Contudo, quando os utilizar, utilize a variante regional, que permite a comunicação com todos os pontos finais do serviço.
- Utilize grupos IP para definir origens que têm de partilhar as mesmas regras ao longo da vida útil do grupo IP. Os grupos IP devem refletir a sua estratégia de segmentação.
- Substitua a regra de permissão FQDN da infraestrutura apenas se a carga de trabalho necessitar de controlo de saída absoluto. Substituir esta regra inclui uma desvantagem de fiabilidade, porque os requisitos da plataforma do Azure mudam nos serviços.
Compromisso: Azure Firewall pode afetar o seu desempenho. A ordem das regras, a quantidade, a inspeção TLS e outros fatores podem causar latência significativa.

Também pode haver um impacto na fiabilidade da sua carga de trabalho. Pode deparar-se com o esgotamento da porta de tradução de endereços de rede de origem (SNAT). Para ajudar a resolver este 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. Esta atribuição pode ter um impacto a jusante na porta de segurança externa.
Azure Firewall de Aplicações Web. Este serviço suporta a filtragem de entrada e destina-se apenas ao tráfego HTTP e HTTPS.

Oferece segurança básica para ataques comuns, tais como ameaças que o Open Worldwide Application Security Project (OWASP) identifica no documento OWASP Top 10. O Azure Firewall de Aplicações Web também fornece outras funcionalidades de segurança focadas na camada 7, como limitação de taxa, regras de injeção de SQL e scripting entre sites.

Com o Azure Firewall de Aplicações Web, a terminação TLS é necessária, porque a maioria das verificações baseia-se em payloads.

Pode integrar o Azure Firewall de Aplicações Web com routers, como o Gateway de Aplicação do Azure ou o Azure Front Door. O Azure Firewall de Aplicações Web as implementações para esses tipos de routers podem variar.

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

Grupos de segurança de rede

Um grupo de segurança de rede é uma firewall de camada 3 e 4 que aplica ao nível da sub-rede ou da placa de interface de rede (NIC). Os grupos de segurança de rede não são criados ou aplicados por predefinição.

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

Para criar regras, comece com o conjunto de regras predefinido:

Para tráfego de entrada ou entrada:
- O tráfego de rede virtual de origens de gateway direto, em modo de peering e de VPN é permitido.
- Balanceador de Carga do Azure são permitidas sondas de estado de funcionamento.
- Todo o outro tráfego está bloqueado.
Para tráfego de saída ou saída:
- O tráfego de rede virtual para direcionar, peering e destinos de gateway de VPN é permitido.
- O tráfego para a Internet é permitido.
- Todo o outro tráfego está bloqueado.

Em seguida, considere os cinco fatores seguintes:

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. Tem de fornecer intervalos de endereços IP específicos para a carga de trabalho e estes são difíceis de manter.

Contudo, para os serviços do Azure, pode utilizar etiquetas de serviço para resumir intervalos de endereços IP de origem e de destino. Um benefício de segurança das etiquetas de serviço é que são opacas para o utilizador e a responsabilidade é descarregada para o Azure. Também pode atribuir um grupo de segurança de aplicação como um tipo de destino para o qual encaminhar o tráfego. Este tipo de grupo nomeado contém recursos que têm necessidades de acesso de entrada ou saída semelhantes.

Risco: os intervalos de etiquetas de serviço são muito amplos para que acomodem o maior leque possível de clientes. Atualizações às etiquetas de serviço ficam aquém das 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 etiqueta. Neste caso, as sub-redes de redes em modo de peering têm uma linha de visão direta. A definição geral da VirtualNetwork etiqueta pode ter um impacto significativo na segurança.

Quando utilizar etiquetas de serviço, utilize versões regionais sempre que possível, como Storage.WestUS em vez de Storage. Ao seguir esta abordagem, limita o âmbito a todos os pontos finais numa determinada região.

Algumas etiquetas destinam-se exclusivamente ao tráfego de entrada ou de saída . Outros são para ambos os tipos. Normalmente , as etiquetas de entrada permitem o tráfego de todas as cargas de trabalho de alojamento, como AzureFrontDoor.Backend, ou do Azure, para suportar runtimes de serviço, como LogicAppsManagement. Da mesma forma, as etiquetas de saída permitem o tráfego para todas as cargas de trabalho de alojamento ou do Azure para suportar runtimes de serviço.

Analise as regras o máximo possível. No exemplo seguinte, a regra está definida para valores específicos. Qualquer outro tipo de tráfego é negado.

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

Para resumir:

Seja preciso quando criar regras. Permitir apenas o tráfego necessário para que a sua aplicação funcione. Negar tudo o resto. Esta abordagem limita a linha de rede visual aos fluxos de rede necessários para suportar o funcionamento da carga de trabalho. Suportar mais fluxos de rede do que o necessário leva a vetores de ataque desnecessários e expande a área da superfície.

Restringir o tráfego não implica que os fluxos permitidos estejam fora do âmbito de um ataque. Uma vez que os grupos de segurança de rede funcionam nas camadas 3 e 4 na pilha Open Systems Interconnection (OSI), só contêm informações de forma e direção. Por exemplo, se a carga de trabalho precisar de permitir o tráfego DNS para a Internet, utilizaria um grupo de segurança de rede de Internet:53:UDP. Neste caso, um atacante poderá conseguir exfiltrar dados através do UDP na porta 53 para outro serviço.
Compreenda 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 adicionais. 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 registos de fluxo e análise de tráfego de rede.
- Utilize 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 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 uma firewall ao nível do serviço. Esta funcionalidade inspeciona o tráfego de entrada para o serviço a partir de intervalos de encaminhamento entre domínios (CIDR) sem classe especificados. Estas firewalls oferecem benefícios:

Fornecem um nível básico de segurança.
Há um impacto tolerável no desempenho.
A maioria dos serviços oferece estas firewalls sem custos adicionais.
As firewalls emitem registos através de diagnósticos do Azure, o que pode ser útil para analisar padrões de acesso.

Mas também existem preocupações de segurança associadas a estas firewalls e existem limitações associadas ao fornecimento de parâmetros. Por exemplo, se utilizar agentes de compilação alojados na Microsoft, terá de abrir o intervalo de endereços IP para todos os agentes de compilação alojados na Microsoft. Em seguida, o intervalo é aberto ao seu agente de compilação, a outros inquilinos e adversários que possam abusar do seu serviço.

Se tiver padrões de acesso para o serviço, que podem ser configurados como conjuntos de regras de firewall de serviço, deve ativar o serviço. Pode utilizar Azure Policy para a ativar. Certifique-se de que não ativa a opção de serviços fidedignos do Azure se não estiver ativada por predefinição. Fazê-lo traz todos os serviços dependentes que estão no âmbito das regras.

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

Pontos finais privados

Private Link fornece uma forma de dar a uma instância PaaS um endereço IP privado. Em seguida, o serviço é inacessível através da Internet. Os pontos finais privados não são suportados para todos os SKUs.

Tenha em atenção as seguintes recomendações quando utilizar pontos finais privados:

Configure serviços vinculados a redes virtuais para contactar os serviços PaaS através de pontos finais privados, mesmo que esses serviços PaaS também precisem de oferecer acesso público.
Promova a utilização de grupos de segurança de rede para pontos finais privados para restringir o acesso a endereços IP de ponto final privados.
Utilize sempre firewalls de serviço quando utiliza pontos finais privados.
Sempre que possível, se tiver um serviço que só esteja acessível através de pontos finais privados, remova a configuração de DNS para o respetivo ponto final público.
Considere as preocupações de linha de visão do runtime quando implementar pontos finais privados. Mas também considere o DevOps e as preocupações de monitorização.
Utilize Azure Policy para impor a configuração de recursos.

Desvantagem: os SKUs de serviço com pontos finais privados são dispendiosos. Os pontos finais privados podem complicar as operações devido à obscuridade de rede. Tem de adicionar agentes autoalojados, caixas de salto, uma VPN e outros componentes à sua arquitetura.

A gestão de DNS pode ser complexa em topologias de rede comuns. Poderá ter de introduzir reencaminhadores DNS e outros componentes.

Injeção de rede virtual

Pode utilizar o processo de injeção de rede virtual para implementar alguns serviços do Azure na sua rede. Exemplos desses serviços incluem Serviço de Aplicações do Azure, Funções, Gestão de API do Azure e Azure Spring Apps. Este processo isola a aplicação da Internet, sistemas em redes privadas e outros serviços do Azure. O tráfego de entrada e saída da aplicação é permitido ou negado com base nas regras de rede.

Azure Bastion

Pode utilizar o Azure Bastion para ligar a uma VM com o browser e o portal do Azure. O Azure Bastion melhora a segurança das ligações RDP e SSH. Um caso de utilização típico inclui ligar a uma caixa de salto na mesma rede virtual ou numa rede virtual em modo de peering. A utilização do Azure Bastion remove a necessidade de a VM ter um endereço IP público.

Azure DDoS Protection

Todas as propriedades no Azure estão protegidas pela proteção da infraestrutura do DDoS do Azure sem custos adicionais e sem configuração adicional. O nível de proteção é básico, mas a proteção tem limiares elevados. Também não fornece telemetria nem alertas e é agnóstico de carga de trabalho.

Os SKUs de camadas superiores da Proteção de DDoS estão disponíveis, mas não são gratuitos. O dimensionamento e a capacidade da rede do Azure implementada globalmente oferecem proteção contra ataques comuns de camada de rede. Tecnologias como a monitorização de tráfego sempre ativada e a mitigação em tempo real fornecem esta capacidade.

Para obter mais informações, veja Descrição geral do Azure DDoS Protection.

Exemplo

Eis alguns exemplos que demonstram a utilização de controlos de rede recomendados neste artigo.

Ambiente de TI

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

Personas de ataque de rede. Várias pessoas podem ser consideradas num ataque de rede, incluindo Administradores, funcionários, clientes do cliente e atacantes anónimos.
Acesso VPN. Um mau ator pode aceder ao ambiente no local através de uma VPN ou de um ambiente do Azure que esteja ligado ao ambiente no local através de uma VPN. Configure com o protocolo IPSec para ativar a comunicação segura.
Acesso público à aplicação. Tenha uma firewall de aplicações Web (WAF) à frente da aplicação para protegê-la na Camada 7 da camada OSI de rede.
Acesso de operador. O acesso remoto através da Camada 4 das camadas de OSI de rede tem de estar protegido. Considere utilizar Azure Firewall com funcionalidades de IDP/IDS.
Proteção contra DDoS. Ter proteção de DDoS para toda a VNet.
Topologia de rede. Uma topologia de rede, como hub-spoke, é mais segura e otimiza os custos. A rede hub fornece proteção de firewall centralizada para todos os spokes em modo de peering.
Pontos finais privados: considere adicionar serviços expostos publicamente à sua rede privada através de pontos finais privados. Estes criam um Cartão de Rede (NIC) na sua VNet privada e vinculam-se ao serviço do Azure.
Comunicação TLS. Proteja os dados em trânsito através da comunicação através do TLS.
Grupo de Segurança de Rede (NSG): proteja segmentos dentro de uma VNet com NSG, um recurso gratuito que filtra a comunicação de entrada e saída TCP/UDP tendo em conta os intervalos de IP e porta. Parte do NSG é o Grupo de Segurança da Aplicação (ASG) que lhe permite criar etiquetas para regras de tráfego para uma gestão mais fácil.
Log Analytics. Os recursos do Azure emitem telemetria ingerida no Log Analytics e, em seguida, são utilizados com uma solução SIEM, como o Microsoft Sentinel, para análise.
Integração do Microsoft Sentinel. O Log Analytics está integrado no Microsoft Sentinel e noutras soluções, como Microsoft Defender para a Cloud.
Microsoft Defender para a Cloud. Microsoft Defender para a Cloud fornece muitas soluções de proteção de cargas de trabalho, incluindo recomendações de rede para o seu ambiente.
Análise de Tráfego: monitorize os controlos de rede com a Análise de Tráfego. Isto é configurado através de Observador de Rede, parte do Azure Monitor, e agrega acessos de entrada e saída nas sub-redes recolhidas pelo NSG.

Arquitetura para uma carga de trabalho em contentores

Esta arquitetura de exemplo combina os controlos de rede descritos neste artigo. O exemplo não mostra a arquitetura completa. Em vez disso, foca-se nos controlos de entrada na cloud privada.

Gateway de Aplicação é um balanceador de carga de tráfego Web que pode utilizar para gerir o tráfego para as suas aplicações Web. Implementa Gateway de Aplicação numa sub-rede dedicada que tem controlos de grupo de segurança de rede e controlos de firewall de aplicações Web implementados.

A comunicação com todos os serviços PaaS é realizada através de pontos finais privados. Todos os pontos finais são colocados numa sub-rede dedicada. O DDoS Protection ajuda a proteger todos os endereços IP públicos configurados para um nível básico ou superior de proteção da firewall.

O tráfego de gestão é restringido através do Azure Bastion, o que ajuda a fornecer conectividade RDP e SSH segura e totalmente integrada às suas VMs diretamente a partir do portal do Azure através do TLS. Os agentes de compilação são colocados na rede virtual para que tenham uma vista de rede para recursos de carga de trabalho, como recursos de computação, registos de contentores e bases de dados. Esta abordagem ajuda a fornecer um ambiente seguro e isolado para os agentes de compilação, o que aumenta a proteção para o seu código e artefactos.

Os grupos de segurança de rede ao nível da sub-rede dos recursos de computação restringem o tráfego de saída. O túnel forçado é utilizado para encaminhar todo o tráfego através de Azure Firewall. Esta abordagem ajuda a fornecer um ambiente seguro e isolado para os seus recursos de computação, o que aumenta a proteção para os seus dados e aplicações.

Lista de verificação de segurança

Veja o conjunto completo de recomendações.

Lista de verificação de segurança

Recomendações para rede e conectividade