Recomendações para criar uma estratégia de segmentação

Aplica-se à recomendação da lista de verificação do Well-Architected Framework Security:

SE:04 Crie segmentação intencional e perímetros na estrutura da sua arquitetura e a quantidade de espaço da carga de trabalho na plataforma. A estratégia de segmentação tem de incluir redes, funções e responsabilidades, identidades de cargas de trabalho e organização de recursos.

Um segmento é uma secção lógica da sua solução que precisa de ser protegida como uma unidade. Uma estratégia de segmentação define como uma unidade deve ser separada de outras unidades com o seu próprio conjunto de requisitos e medidas de segurança.

Este guia descreve as recomendações para criar uma estratégia de segmentação unificada. Ao utilizar perímetros e limites de isolamento em cargas de trabalho, pode conceber uma abordagem de segurança que funcione para si.

Definições 

Termo Definição
Contenção Uma técnica para conter o raio de explosão se um atacante obtiver acesso a um segmento.
Acesso com menos privilégios Um princípio Confiança Zero que visa minimizar um conjunto de permissões para concluir uma função de trabalho.
Perímetro O limite de confiança à volta de um segmento.
Organização de recursos Uma estratégia para agrupar recursos relacionados por fluxos dentro de um segmento.
Função Um conjunto de permissões necessárias para concluir uma função de tarefa.
Segment Uma unidade lógica isolada de outras entidades e protegida por um conjunto de medidas de segurança.

Principais estratégias de conceção

O conceito de segmentação é normalmente utilizado para redes. No entanto, o mesmo princípio subjacente pode ser utilizado numa solução, incluindo segmentação de recursos para fins de gestão e controlo de acesso.

A segmentação ajuda-o a conceber uma abordagem de segurança que aplica a defesa em profundidade com base nos princípios do modelo de Confiança Zero. Certifique-se de que um atacante que viola um segmento de rede não consegue aceder a outro segmentando cargas de trabalho com diferentes controlos de identidade. Num sistema seguro, os atributos de identidade e rede bloqueiam o acesso não autorizado e ocultam os recursos de serem expostos. Eis alguns exemplos de segmentos:

  • Subscrições que isolam cargas de trabalho de uma organização
  • Grupos de recursos que isolam recursos de carga de trabalho
  • Ambientes de implementação que isolam a implementação por fases
  • Equipas e funções que isolam funções de trabalho relacionadas com o desenvolvimento e a gestão de cargas de trabalho
  • Camadas de aplicação que isolam por utilitário de carga de trabalho
  • Microsserviços que isolam um serviço de outro

Considere estes elementos-chave da segmentação para se certificar de que está a criar uma estratégia abrangente de defesa em profundidade:

  • O limite ou perímetro é a margem de entrada de um segmento onde aplica controlos de segurança. Os controlos de perímetro devem bloquear o acesso ao segmento, a menos que seja explicitamente permitido. O objetivo é impedir que um atacante incorra no perímetro e obtenha o controlo do sistema. Por exemplo, uma camada de aplicação pode aceitar o token de acesso de um utilizador final quando processa um pedido. Mas a camada de dados pode exigir um token de acesso diferente que tenha uma permissão específica, que só a camada da aplicação pode pedir.

  • A contenção é o limite de saída de um segmento que impede o movimento lateral no sistema. O objetivo da contenção é minimizar o efeito de uma falha de segurança. Por exemplo, uma rede virtual do Azure pode ser utilizada para configurar grupos de segurança de rede e encaminhamento para permitir apenas padrões de tráfego esperados, evitando o tráfego para segmentos de rede arbitrários.

  • O isolamento é a prática de agrupar entidades com garantias semelhantes para as proteger com um limite. O objetivo é a facilidade de gestão e a contenção de um ataque num ambiente. Por exemplo, pode agrupar os recursos relacionados com uma carga de trabalho específica numa subscrição do Azure e, em seguida, aplicar o controlo de acesso para que apenas equipas de cargas de trabalho específicas possam aceder à subscrição.

É importante ter em atenção a distinção entre perímetros e isolamento. Perímetro refere-se aos pontos de localização que devem ser verificados. O isolamento é sobre agrupamento. Contiver ativamente um ataque ao utilizar estes conceitos em conjunto.

O isolamento não significa criar silos na organização. Uma estratégia de segmentação unificada proporciona alinhamento entre as equipas técnicas e define linhas claras de responsabilidade. Clarity reduz o risco de erros humanos e falhas de automatização que podem levar a vulnerabilidades de segurança, tempo de inatividade operacional ou ambos. Suponha que é detetada uma falha de segurança num componente de um sistema empresarial complexo. É importante que todos compreendam quem é responsável por esse recurso para que a pessoa adequada seja incluída na equipa de triagem. A organização e os intervenientes podem identificar rapidamente como responder a diferentes tipos de incidentes ao criar e documentar uma boa estratégia de segmentação.

Desvantagem: a segmentação introduz complexidade porque existe sobrecarga na gestão. Há também uma desvantagem nos custos. Por exemplo, são aprovisionados mais recursos quando os ambientes de implementação que são executados lado a lado são segmentados.

Risco: a micro segmentação para além de um limite razoável perde o benefício do isolamento. Quando cria demasiados segmentos, torna-se difícil identificar pontos de comunicação ou permitir caminhos de comunicação válidos no segmento.

Identidade como perímetro

Várias identidades, como pessoas, componentes de software ou dispositivos, acedem a segmentos de cargas de trabalho. A identidade é um perímetro que deve ser a linha primária de defesa para autenticar e autorizar o acesso através dos limites de isolamento, independentemente da origem do pedido de acesso. Utilize a identidade como perímetro para:

  • Atribuir acesso por função. As identidades só precisam de acesso aos segmentos necessários para fazerem o seu trabalho. Minimize o acesso anónimo ao compreender as funções e responsabilidades da identidade de pedido para que conheça a entidade que está a pedir acesso a um segmento e para que finalidade.

    Uma identidade pode ter diferentes âmbitos de acesso em segmentos diferentes. Considere uma configuração de ambiente típica, com segmentos separados para cada fase. As identidades associadas à função de programador têm acesso de leitura/escrita ao ambiente de desenvolvimento. À medida que a implementação passa para o teste, essas permissões são restringidas. Quando a carga de trabalho é promovida para produção, o âmbito para programadores é reduzido para acesso só de leitura.

  • Considere as identidades da aplicação e da gestão separadamente. Na maioria das soluções, os utilizadores têm um nível de acesso diferente dos programadores ou operadores. Em algumas aplicações, pode utilizar diferentes sistemas de identidade ou diretórios para cada tipo de identidade. Considere utilizar âmbitos de acesso e criar funções separadas para cada identidade.

  • Atribua acesso com menos privilégios. Se a identidade for permitida, determine o nível de acesso. Comece com o menor privilégio para cada segmento e expanda esse âmbito apenas quando necessário.

    Ao aplicar o menor privilégio, limita os efeitos negativos se a identidade for alguma vez comprometida. Se o acesso for limitado por tempo, a superfície de ataque será ainda mais reduzida. O acesso com limite de tempo é especialmente aplicável a contas críticas, como administradores ou componentes de software que tenham uma identidade comprometida.

Desvantagem: o desempenho da carga de trabalho pode ser afetado pelos perímetros de identidade. Verificar cada pedido explicitamente requer ciclos de computação adicionais e E/S de rede extra.

O controlo de acesso baseado em funções (RBAC) também resulta numa sobrecarga de gestão. Manter um registo das identidades e dos respetivos âmbitos de acesso pode tornar-se complexo nas atribuições de funções. A solução é atribuir funções a grupos de segurança em vez de identidades individuais.

Risco: as definições de identidade podem ser complexas. As configurações incorretas podem afetar a fiabilidade da carga de trabalho. Por exemplo, suponha que existe uma atribuição de função configurada incorretamente que não tem acesso a uma base de dados. Os pedidos começam a falhar, causando eventualmente problemas de fiabilidade que, de outra forma, não podem ser detetados até ao runtime.

Para obter informações sobre controlos de identidade, veja Gestão de identidades e acessos.

Ao contrário dos controlos de acesso à rede, a identidade valida o controlo de acesso no momento do acesso. É altamente recomendado realizar uma revisão de acesso regular e exigir um fluxo de trabalho de aprovação para obter privilégios para contas de impacto crítico. Por exemplo, veja Padrões de segmentação de identidade.

Rede como um perímetro

Os perímetros de identidade são agnósticos de rede enquanto os perímetros de rede aumentam a identidade, mas nunca os substituem. Os perímetros de rede são estabelecidos para controlar o raio da explosão, bloquear o acesso inesperado, proibido e não seguro e impedir recursos de carga de trabalho.

Embora o foco principal do perímetro de identidade seja o menor privilégio, deve assumir que haverá uma falha de segurança quando estiver a estruturar o perímetro de rede.

Crie perímetros definidos pelo software no espaço de rede com os serviços e funcionalidades do Azure. Quando uma carga de trabalho (ou partes de uma determinada carga de trabalho) é colocada em segmentos separados, controla o tráfego de ou para esses segmentos para proteger caminhos de comunicação. Se um segmento for comprometido, é contido e impedido de se espalhar lateralmente pelo resto da sua rede.

Pense como um atacante para alcançar uma posição de pé dentro da carga de trabalho e estabelecer controlos para minimizar a expansão adicional. Os controlos devem detetar, conter e impedir que os atacantes obtenham acesso a toda a carga de trabalho. Eis alguns exemplos de controlos de rede como perímetro:

  • Defina o perímetro de limite entre as redes públicas e a rede onde a carga de trabalho é colocada. Restrinja a linha de visão das redes públicas para a sua rede o máximo possível.
  • Implemente zonas desmilitarizadas (DMZs) à frente da aplicação com controlos adequados através de firewalls.
  • Crie a micro segmentação na sua rede privada ao agrupar partes da carga de trabalho em segmentos separados. Estabeleça caminhos de comunicação seguros entre eles.
  • Crie limites com base na intenção. Por exemplo, segmente as redes funcionais da carga de trabalho a partir de redes operacionais.

Para obter padrões comuns relacionados com a segmentação de rede, veja Padrões de segmentação de rede.

Desvantagem: os controlos de segurança de rede são muitas vezes dispendiosos porque são incluídos com os SKUs premium. A configuração de regras em firewalls resulta, muitas vezes, numa complexidade esmagadora que requer exceções abrangentes.

A conectividade privada altera o design da arquitetura, muitas vezes adicionando mais componentes, como jumpboxs, para acesso privado a nós de computação.

Uma vez que os perímetros de rede são baseados em pontos de controlo ou saltos na rede, cada salto pode ser um potencial ponto de falha. Estes pontos podem ter um efeito na fiabilidade do sistema.

Risco: os controlos de rede são baseados em regras e existe uma probabilidade significativa de configuração incorreta, o que é uma preocupação de fiabilidade.

Para obter informações sobre os controlos de rede, veja Rede e conectividade.

Funções e responsabilidades

A segmentação que impede confusões e riscos de segurança é obtida ao definir claramente linhas de responsabilidade dentro de uma equipa de carga de trabalho.

Documente e partilhe funções e funções para criar consistência e facilitar a comunicação. Designe grupos ou funções individuais responsáveis por funções-chave. Considere as funções incorporadas no Azure antes de criar funções personalizadas para objetos.

Considere a consistência ao acomodar vários modelos organizacionais ao atribuir permissões para um segmento. Estes modelos podem variar de um único grupo de TI centralizado a equipas de TI e DevOps maioritariamente independentes.

Risco: a associação a grupos pode mudar ao longo do tempo à medida que os funcionários entram ou saem das equipas ou mudam de funções. A gestão de funções entre segmentos pode resultar numa sobrecarga de gestão.

Organização de recursos

A segmentação permite-lhe isolar recursos de cargas de trabalho de outras partes da organização ou mesmo dentro da equipa. As construções do Azure, como grupos de gestão, subscrições, ambientes e grupos de recursos, são formas de organizar os recursos que promovem a segmentação. Eis alguns exemplos de isolamento ao nível dos recursos:

  • A persistência poliglota envolve uma combinação de tecnologias de armazenamento de dados em vez de um único sistema de base de dados para suportar a segmentação. Utilize persistência poliglota para separação por vários modelos de dados, separação de funcionalidades como armazenamento de dados e análise ou para separar por padrões de acesso.
  • Aloque um serviço para cada servidor ao organizar a sua computação. Este nível de isolamento minimiza a complexidade e pode ajudar a conter um ataque.
  • O Azure fornece isolamento incorporado para alguns serviços, por exemplo, separação da computação do armazenamento. Para obter outros exemplos, veja Isolamento na cloud pública do Azure.

Desvantagem: o isolamento de recursos pode resultar num aumento do custo total de propriedade (TCO). Para os arquivos de dados, pode haver mais complexidade e coordenação durante a recuperação após desastre.

Facilitação do Azure

Determinados serviços do Azure estão disponíveis para utilização na implementação de uma estratégia de segmentação, conforme descrito nas secções seguintes.

Identidade

O RBAC do Azure suporta a segmentação ao isolar o acesso por função de tarefa. Apenas determinadas ações são permitidas para determinadas funções e âmbitos. Por exemplo, as funções de trabalho que só precisam de observar o sistema podem ser atribuídas permissões de leitor versus permissões de contribuidor que permitem que a identidade faça a gestão de recursos.

Para obter mais informações, veja Melhores práticas para o RBAC.

Rede

Diagrama que mostra as opções de rede para segmentação.

Redes virtuais: as redes virtuais fornecem a contenção de recursos ao nível da rede sem adicionar tráfego entre duas redes virtuais. As redes virtuais são criadas em espaços de endereços privados numa subscrição

Grupos de segurança de rede (NSG): um mecanismo de controlo de acesso para controlar o tráfego entre recursos em redes virtuais e redes externas, como a Internet. Implemente rotas definidas pelo utilizador (UDR) para controlar o próximo salto para o tráfego. Os NSGs podem levar a sua estratégia de segmentação a um nível granular ao criar perímetros para uma sub-rede, uma máquina virtual (VM) ou um grupo de VMs. Para obter informações sobre possíveis operações com sub-redes no Azure, veja Sub-redes.

Grupos de segurança de aplicações (ASGs): os ASGs permitem-lhe agrupar um conjunto de VMs numa etiqueta de aplicação e definir regras de tráfego que são aplicadas a cada uma das VMs subjacentes.

Azure Firewall: um serviço nativo da cloud, que pode ser implementado na sua rede virtual ou nas implementações do hub WAN Virtual do Azure. Utilize Azure Firewall para filtrar o tráfego que flui entre os recursos da cloud, a Internet e os recursos no local. Utilize Azure Firewall ou Azure Firewall Manager para criar regras ou políticas que permitam ou neguem o tráfego através de controlos de camada 3 a 7. Filtre o tráfego da Internet com Azure Firewall e terceiros ao direcionar o tráfego através de fornecedores de segurança de terceiros para filtragem avançada e proteção do utilizador. O Azure suporta a implementação de aplicações virtuais de rede, o que ajuda a segmentar a partir de firewalls de terceiros.

Exemplo

Seguem-se alguns padrões comuns para segmentar uma carga de trabalho no Azure. Escolha um padrão com base nas suas necessidades.

Este exemplo baseia-se no ambiente de Tecnologias de Informação (TI) estabelecido na linha de base de segurança (SE:01). O diagrama abaixo mostra a segmentação ao nível do grupo de gestão efetuada por uma organização.

Diagrama que mostra um exemplo da estratégia de segmentação de uma organização para várias cargas de trabalho.

Padrões de segmentação de identidade

Padrão 1: Agrupamento baseado no cargo

Uma forma de organizar grupos de segurança é através do cargo de engenheiro de software, administrador de bases de dados, engenheiro de fiabilidade do site, engenheiro de garantia de qualidade ou analista de segurança. Esta abordagem envolve a criação de grupos de segurança para a sua equipa de carga de trabalho com base nas respetivas funções, sem considerar o trabalho que tem de ser realizado. Conceda permissões RBAC a grupos de segurança, de pé ou just-in-time (JIT), de acordo com as respetivas responsabilidades na carga de trabalho. Atribua princípios humanos e de serviço a grupos de segurança com base no respetivo acesso conforme necessário.

A associação é altamente visível ao nível da atribuição de funções, o que torna mais fácil ver a que função tem acesso. Normalmente, cada pessoa é membro de apenas um grupo de segurança, o que facilita a integração e a exclusão. No entanto, a menos que os títulos de trabalho se sobreponham perfeitamente às responsabilidades, o agrupamento baseado em títulos não é ideal para a implementação com menos privilégios. Pode acabar por combinar a implementação com o agrupamento baseado em funções.

Padrão 2: agrupamento baseado em funções

O agrupamento baseado em funções é um método de organização de grupo de segurança que reflete o trabalho discreto que tem de ser realizado, não tendo em conta a estrutura da sua equipa. Com este padrão, concede permissões RBAC a grupos de segurança, em pé ou JIT, conforme necessário, de acordo com a função necessária na carga de trabalho.

Atribua princípios humanos e de serviço a grupos de segurança com base no respetivo acesso conforme necessário. Sempre que possível, utilize grupos homogéneos existentes como membros dos grupos baseados em funções, como os grupos do padrão 1. Exemplos de grupos baseados em funções incluem:

  • Operadores da base de dados de produção
  • Operadores de base de dados de pré-produção
  • Operadores de rotação de certificados de produção
  • Operadores de rotação de certificados de pré-produção
  • Produção em direto/triagem
  • Pré-produção de todos os acessos

Esta abordagem mantém o acesso menos privilegiado e fornece grupos de segurança onde o âmbito é evidente, o que facilita a auditoria de associações relativamente aos deveres de trabalho executados. Muitas vezes, existe uma função incorporada do Azure para corresponder a esta função de tarefa.

No entanto, a associação é abstraída pelo menos uma camada, forçando-o a aceder ao fornecedor de identidade para compreender quem está no grupo ao olhar da perspetiva do recurso. Além disso, uma pessoa precisa de ter várias associações mantidas para uma cobertura completa. A matriz de grupos de segurança sobrepostos pode ser complexa.

O Padrão 2 é recomendado para tornar o foco nos padrões de acesso e não no organograma. Por vezes, os organogramas e as funções de membros mudam. Capturar a gestão de identidades e acessos da carga de trabalho de uma perspetiva funcional permite-lhe abstrair a sua organização de equipa da gestão segura da carga de trabalho.

Padrões de segmentação de rede

Padrão 1: segmentação numa carga de trabalho (limites suaves)

Diagrama que mostra uma única rede virtual.

Neste padrão, a carga de trabalho é colocada numa única rede virtual com sub-redes para marcar limites. A segmentação é obtida com duas sub-redes, uma para a base de dados e outra para cargas de trabalho Web. Tem de configurar NSGs que permitam à Sub-rede 1 comunicar apenas com a Sub-rede 2 e a Sub-rede 2 para comunicar apenas com a Internet. Este padrão fornece controlo de nível de camada 3.

Padrão 2: segmentação numa carga de trabalho

Diagrama que mostra várias redes virtuais.

Este padrão é um exemplo de segmentação ao nível da plataforma. As cargas de trabalho components são distribuídas por várias redes sem peering entre elas. Toda a comunicação é encaminhada através de um intermediário que serve de ponto de acesso público. A equipa de carga de trabalho é proprietária de todas as redes.

O Padrão 2 fornece contenção, mas tem a complexidade adicional da gestão e do dimensionamento da rede virtual. A comunicação entre as duas redes ocorre através da Internet pública, o que pode ser um risco. Também existe latência com ligações públicas. No entanto, as duas redes podem ser em modo de peering, interrompendo a segmentação ao ligá-las para criar um segmento maior. O peering deve ser feito quando não são necessários outros pontos finais públicos.

Considerações Padrão 1 Padrão 2
Conectividade e encaminhamento: como cada segmento comunica O encaminhamento do sistema fornece conectividade predefinida aos componentes da carga de trabalho. Nenhum componente externo pode comunicar com a carga de trabalho. Na rede virtual, tal como o padrão 1.
Entre redes, o tráfego passa pela Internet pública. Não existe conectividade direta entre as redes.
Filtragem de tráfego ao nível da rede O tráfego entre os segmentos é permitido por predefinição. Utilize NSGs ou ASGs para filtrar o tráfego. Na rede virtual, tal como o padrão 1.
Entre as redes, pode filtrar o tráfego de entrada e saída através de uma firewall.
Pontos finais públicos abertos não intencionais As placas de interface de rede (NICs) não obtêm IPs públicos. As redes virtuais não são expostas à gestão de API da Internet. O mesmo que o padrão 1. Destina-se a abrir o ponto final público numa rede virtual, que pode ser configurado incorretamente para aceitar mais tráfego.

Organização de recursos

Organizar recursos do Azure com base na responsabilidade de propriedade

Diagrama de uma propriedade do Azure que contém várias cargas de trabalho.

Considere um património do Azure que contém várias cargas de trabalho e componentes de serviço partilhado, como redes virtuais de hub, firewalls, serviços de identidade e serviços de segurança, como o Microsoft Sentinel. Os componentes em toda a propriedade devem ser agrupados com base nas respetivas áreas funcionais, cargas de trabalho e propriedade. Por exemplo, os recursos de rede partilhados devem ser agrupados numa única subscrição e geridos por uma equipa de rede. Os componentes dedicados a cargas de trabalho individuais devem estar no seu próprio segmento e podem ser ainda mais divididos com base nas camadas da aplicação ou noutros princípios organizacionais.

Conceda acesso para gerir recursos em segmentos individuais ao criar atribuições de funções RBAC. Por exemplo, a equipa de rede na cloud pode ter acesso administrativo à subscrição que contém os respetivos recursos, mas não a subscrições de cargas de trabalho individuais.

Uma boa estratégia de segmentação permite identificar facilmente os proprietários de cada segmento. Considere utilizar etiquetas de recursos do Azure para anotar grupos de recursos ou subscrições com a equipa do proprietário.

Configurar e rever o controlo de acesso

Conceda o acesso adequado com base na necessidade ao definir claramente segmentos para os seus recursos.

Considere o princípio do menor privilégio quando definir políticas de controlo de acesso. É importante distinguir entre as operações do plano de controlo (gestão do próprio recurso) e as operações do plano de dados (acesso aos dados armazenados pelo recurso). Por exemplo, suponha que tem uma carga de trabalho que contém uma base de dados com informações confidenciais sobre funcionários. Pode conceder acesso de gestão a alguns utilizadores que precisam de configurar definições como cópias de segurança de bases de dados ou utilizadores que monitorizam o desempenho do servidor de bases de dados. No entanto, estes utilizadores não devem conseguir consultar os dados confidenciais armazenados na base de dados. Selecione as permissões que concedem o âmbito mínimo necessário para que os utilizadores efetuem as suas funções. Reveja regularmente as atribuições de funções de cada segmento e remova o acesso que já não é necessário.

Nota

Algumas funções altamente privilegiadas, como a função de proprietário no RBAC, permitem aos utilizadores conceder aos outros utilizadores acesso a um recurso. Limite quantos utilizadores ou grupos são atribuídos à função de proprietário e reveja regularmente os registos de auditoria para garantir que apenas realizam operações válidas.

Lista de verificação de segurança

Veja o conjunto completo de recomendações.