Recomendações para rede e conectividade

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

Este guia descreve as recomendações para o design de rede. O foco está nos controles de segurança que podem filtrar, bloquear e detectar adversários que cruzam os limites da 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 da rede é uma alta prioridade para proteger os 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 invasores entrem em sua carga de trabalho.

Definições

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. O design de segurança de rede é construído em três estratégias principais:

• 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 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 nessa borda devem ser altamente eficazes, porque 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 forte medida de segurança 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 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 se há 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 útil pode não ser segura. As verificações de validação podem revelar um ataque de injeção de SQL.

• Transformar. Altere 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 TLS (Transport Layer Security) em um ponto e restabelecê-lo em outro salto com um certificado gerenciado com mais rigor.

Classifique 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 à utilidade funcional e aos aspectos operacionais de sua 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á algum requisito de conformidade no nível da rede?

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

Visibilidade de redes externas

• Público. Uma carga de trabalho é 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úblicos.

• Particular. Uma carga de trabalho é privada se 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á 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 cruzar um limite privado quando 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. A 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-chave. Determine qual é a origem do tráfego e se ela é esperada, permitida e segura. Os invasores que verificam os intervalos de endereços IP do provedor de nuvem pública podem penetrar com êxito em suas defesas se você 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 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 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 de sua carga de trabalho com a Internet pública. Por exemplo, a plataforma de aplicativos normalmente atende a 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. Esse tráfego cruza a borda 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 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 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 requerem diferentes métodos de remediaçã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.

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 de seus 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.

Aplique firewalls na borda

O tráfego de borda da internet é tráfego norte-sul e inclui entrada e saída. Para detectar ou bloquear ameaças, uma estratégia de borda deve mitigar o máximo possível de ataques para e da 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 solução de virtualização de rede (NVA) ou um ffirewall do 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 de propriedade de uma equipe central. Verifique se todas as NVAs que você usa estão configuradas para dar suporte às necessidades de sua 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. Os produtos de firewall de parceiro e firewall de aplicativo 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 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 é preferido 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.

Criar segurança de rede virtual e sub-rede

O objetivo principal de uma nuvem privada é ocultar recursos da Internet pública. Existem várias maneiras de atingir esse objetivo:

• Mova para espaços de endereço 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 que não seja 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 para divisão devem ser intencionais. Ao colocar serviços dentro de uma sub-rede, certifique-se de que esses serviços possam ver uns aos outros.

Você pode basear sua segmentação em muitos fatores. Por exemplo, você pode colocar diferentes camadas de aplicativos 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 principais 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 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 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 projeto de arquitetura. Por exemplo, você planejou o tráfego quando sua arquitetura recomenda que o Azure Functions efetue pull de mensagens do Barramento de Serviço do Azure.

• Tráfego de gerenciamento 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 estiver, 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.

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

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 pelo 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 em 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.

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 Link Privado do Azure é 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 endpoint que possa ser acessado publicamente pela Internet.

Um ataque DDoS geralmente é um abuso massivo, generalizado e geograficamente disperso dos recursos do seu sistema que dificulta a identificação e o bloqueio da 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 em profundidade à sua rede.

Rede Virtual do Azure

A Rede Virtual ajuda seus 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.

A 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 a passagem de tráfego por meio de um balanceador de carga ou gateway de conversão de endereços de rede (NAT). 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 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 o portão 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 porta.
  • Detecção de assinatura do sistema de detecção e prevenção de intrusão (IDPS).
  • Regras de rede fortes de camada 3, camada 4 e FQDN (nome de domínio totalmente qualificado).

  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 o Firewall do Azure simultaneamente para entrada. Ele pode rotear o tráfego HTTP e HTTPS. Em SKUs de camada superior, o Firewall do Azure oferece terminação TLS para que você possa implementar inspeções no nível da carga.

  As seguintes práticas são recomendadas:

  • Habilite as configurações de diagnóstico no Firewall do Azure para coletar logs de fluxo de tráfego, logs de IDPS e logs de solicitação de 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 endpoints do serviço.

  • Use grupos de IPs 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 de FQDN de infraestrutura somente se sua carga de trabalho exigir controle de saída absoluto. A substituição dessa regra vem com uma compensação de confiabilidade, pois os requisitos da plataforma Azure mudam nos serviços.

  Compensação: o Firewall do Azure pode afetar 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 confiabilidade de sua carga de trabalho. Ele pode experimentar 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 tráfego de saída, o Azure atribui um endereço IP público. Essa atribuição pode ter um impacto downstream em seu portão de segurança externo.

• Firewall de Aplicativo Web do Azure. Esse serviço dá suporte à filtragem de entrada e visa apenas o 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 do TLS é necessária, pois a maioria das verificações é baseada em conteúdos.

  Você pode integrar o Firewall de Aplicativo Web do Azure a roteadores, como o Gateway de Aplicativo do Azure 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 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 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 padrão.

As regras do grupo de segurança de rede atuam como um firewall para interromper 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 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.
  • As investigações de integridade do Azure Load Balancer 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 destino. Um benefício de segurança das marcas 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 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: As faixas de etiquetas de serviço são muito amplas para acomodar a maior variedade possível de clientes. As atualizações nas marcas de serviço ficam atrás 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 marca. Portanto, nesse caso, as sub-redes das 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 tags 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.Backendo , ou 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.

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

Para resumir:

• Seja preciso ao criar regras. Permita apenas o tráfego necessário para que seu aplicativo funcione. Negue 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. 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 da pilha OSI (Interconexão de Sistemas Abertos), 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 por meio do UDP na porta 53 para algum outro serviço.

• Entenda que os grupos de segurança de rede podem diferir um pouco 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 o 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 de nível de 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 extra.
• 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 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. O intervalo é aberto para seu agente de build, outros locatários e adversários que podem 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á ativar o serviço. Você pode usar o 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

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

Lembre-se das seguintes recomendações ao usar pontos de extremidade privados:

• Configure os serviços associados a redes virtuais para entrar em contato com os 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 privado.

• 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 com a linha de visão do tempo de execução ao implementar pontos de extremidade privados. Mas também considere o DevOps e as preocupações de monitoramento.

• Use o 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 da 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, Funções, Gerenciamento de API do Azure e Azure Spring Apps. Esse processo isola o aplicativo da Internet, sistemas em redes privadas e 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 aprimora a segurança das conexões RDP e SSH. Um caso de uso típico inclui a conexão com um jumpbox na mesma rede virtual ou em uma rede virtual emparelhada. O uso do Azure Bastion elimina a necessidade de a VM ter um endereço IP público.

Proteção contra DDoS do Azure

Cada propriedade no Azure é protegida 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 limites altos. Ele também não fornece telemetria ou alerta e é independente de carga de trabalho.

SKUs de camada superior de proteção contra DDoS estão disponíveis, mas não são gratuitas. A escala e a capacidade da rede do Azure implantada globalmente oferecem proteção contra ataques comuns na camada de rede. Tecnologias como monitoramento de tráfego sempre ativo e mitigação em tempo real fornecem esse recurso.

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.

1. 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.

2. Acesso VPN. Um ator 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 a comunicação segura.

3. Acesso público ao aplicativo. Tenha um firewall de aplicativo da Web (WAF) na frente do aplicativo para protegê-lo na camada 7 da camada OSI de rede.

4. Acesso do operador. O acesso remoto através da camada 4 das camadas OSI de rede deve ser protegido. Considere usar o Firewall do Azure com recursos de IDP/IDS.

5. Proteção contra DDoS. Tenha proteção contra DDoS para toda a sua VNet.

6. Topologia de rede. Uma topologia de rede, como hub-spoke, é mais segura e otimiza os custos. A rede de hub fornece proteção de firewall centralizada para todos os spokes emparelhados.

7. 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 associam-se ao serviço do Azure.

8. Comunicação TLS. Proteja os dados em trânsito comunicando-se por TLS.

9. 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 portas. Parte do NSG é o ASG (Grupo de Segurança de Aplicativos) que permite criar marcas para regras de tráfego para facilitar o gerenciamento.

10. Log Analytics. Os recursos do Azure emitem telemetria ingerida no Log Analytics e usada com uma solução SIEM como o Microsoft Sentinel para análise.

11. Integração do Microsoft Sentinel. O Log Analytics é integrado ao Microsoft Sentinel e a outras soluções, como o Microsoft Defender para Nuvem.

12. Microsoft Defender para Nuvem. O Microsoft Defender para Nuvem oferece muitas soluções de proteção de carga de trabalho, incluindo recomendações de rede para seu ambiente.

13. Análise de tráfego: monitore seus controles de rede com a análise de tráfego. Isso é configurado por meio do 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êiner

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 nos controles de entrada na nuvem privada.

O 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 o 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 é conduzida 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 de firewall.

O tráfego de gerenciamento é restrito por meio do Azure Bastion, o 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 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 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.

Links relacionados

• Recomendações para projetar estratégias de segmentação
• Sub-redes da Rede Virtual do Azure
• Rede Virtual do Azure
• Firewall do Azure
• Firewall do aplicativo Web do Azure
• Firewall e Gateway de Aplicativo para redes virtuais
• Grupos de segurança de rede
• Marcas de serviço
• Link Privado do Azure
• Pontos de extremidade privados
• Azure Bastion
• Visão geral da Proteção contra DDoS do Azure

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.