Recomendações para criar uma estratégia de segmentação
Aplica-se à recomendação da lista de verificação de segurança do Well-Architected Framework:
SE:04 | Crie segmentação intencional e perímetros em seu design de arquitetura e no volume da carga de trabalho na plataforma. A estratégia de segmentação deve incluir redes, funções e responsabilidades, identidades de carga de trabalho e organização de recursos. |
---|
Um segmento é uma seção lógica de sua solução que precisa ser protegida como uma unidade. Uma estratégia de segmentação define como uma unidade deve ser separada de outras unidades com seu próprio conjunto de requisitos e medidas de segurança.
Este guia descreve as recomendações para a criação de uma estratégia de segmentação unificada. Usando perímetros e limites de isolamento em cargas de trabalho, você pode criar uma abordagem de segurança que funcione para você.
Definições
Termo | Definição |
---|---|
Contenção | Uma técnica para conter o raio de explosão se um invasor obtiver acesso a um segmento. |
Acesso com privilégios mínimos | Um princípio Zero Trust que visa minimizar um conjunto de permissões para concluir uma função de trabalho. |
Perímetro | O limite de confiança em torno de um segmento. |
Organização do recurso | 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 trabalho. |
Segment | Uma unidade lógica isolada de outras entidades e protegida por um conjunto de medidas de segurança. |
Principais estratégias de design
O conceito de segmentação é comumente usado para redes. No entanto, o mesmo princípio subjacente pode ser usado em toda a solução, incluindo a segmentação de recursos para fins de gerenciamento e controle de acesso.
A segmentação ajuda você a projetar uma abordagem de segurança que aplica a defesa em profundidade com base nos princípios do modelo Zero Trust. Certifique-se de que um invasor que viola um segmento de rede não possa obter acesso a outro segmentando cargas de trabalho com diferentes controles de identidade. Em um sistema seguro, os atributos de identidade e rede bloqueiam o acesso não autorizado e ocultam a exposição dos ativos. Aqui estão alguns exemplos de segmentos:
- Assinaturas que isolam cargas de trabalho de uma organização
- Grupos de recursos que isolam ativos de carga de trabalho
- Ambientes de implantação que isolam a implantação por estágios
- Equipes e funções que isolam funções de trabalho relacionadas ao desenvolvimento e gerenciamento de carga de trabalho
- Camadas de aplicativo 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 garantir que você esteja construindo uma estratégia abrangente de defesa em profundidade:
O limite ou perímetro é a borda de entrada de um segmento onde você aplica controles de segurança. Os controles de perímetro devem bloquear o acesso ao segmento, a menos que explicitamente permitido. O objetivo é impedir que um invasor rompa o perímetro e ganhe o controle do sistema. Por exemplo, uma camada de aplicativo pode aceitar o token de acesso de um usuário final quando processa uma solicitação. Mas a camada de dados pode exigir um token de acesso diferente que tenha uma permissão específica, que somente a camada de aplicativo pode solicitar.
A contenção é a borda de saída de um segmento que impede o movimento lateral no sistema. O objetivo da contenção é minimizar o efeito de uma violação. Por exemplo, uma rede virtual do Azure pode ser usada para configurar grupos de segurança de rede e roteamento para permitir apenas os 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 protegê-las com um limite. O objetivo é a facilidade de gerenciamento e a contenção de um ataque dentro de um ambiente. Por exemplo, você pode agrupar os recursos relacionados a uma carga de trabalho específica em uma assinatura do Azure e, em seguida, aplicar o controle de acesso para que apenas equipes de carga de trabalho específicas possam acessar a assinatura.
É importante observar a distinção entre perímetros e isolamento. Perímetro refere-se aos pontos de localização que devem ser verificados. Isolamento é sobre agrupamento. Contenha ativamente um ataque usando esses conceitos juntos.
Isolamento não significa criar silos na organização. Uma estratégia de segmentação unificada fornece alinhamento entre as equipes técnicas e define linhas claras de responsabilidade. O Clarity reduz o risco de erro humano e falhas de automação que podem levar a vulnerabilidades de segurança, tempo de inatividade operacional ou ambos. Suponha que uma violação de segurança seja detectada em um componente de um sistema corporativo complexo. É importante que todos entendam quem é responsável por esse recurso para que a pessoa apropriada seja incluída na equipe de triagem. A organização e as partes interessadas podem identificar rapidamente como responder a diferentes tipos de incidentes, criando e documentando uma boa estratégia de segmentação.
Compensação: a segmentação introduz complexidade porque há sobrecarga no gerenciamento. Há também uma compensação no custo. Por exemplo, mais recursos são provisionados quando os ambientes de implantação executados lado a lado são segmentados.
Risco: A microssegmentação além de um limite razoável perde o benefício do isolamento. Quando você cria muitos segmentos, torna-se difícil identificar pontos de comunicação ou permitir caminhos de comunicação válidos dentro do segmento.
Estabelecer identidade como o perímetro de segurança principal
Várias identidades, como pessoas, componentes de software ou dispositivos, acessam segmentos de carga de trabalho. A identidade é um perímetro que deve ser a principal linha de defesa para autenticar e autorizar o acesso entre limites de isolamento, independentemente de onde a solicitação de acesso se origina. Use a identidade como um perímetro para:
Atribuir acesso por função. As identidades só precisam de acesso aos segmentos necessários para fazer seu trabalho. Minimize o acesso anônimo entendendo as funções e responsabilidades da identidade solicitante para que você conheça a entidade que está solicitando acesso a um segmento e para qual finalidade.
Uma identidade pode ter escopos de acesso diferentes em segmentos diferentes. Considere uma configuração de ambiente típica, com segmentos separados para cada estágio. As identidades associadas à função de desenvolvedor têm acesso de leitura/gravação ao ambiente de desenvolvimento. À medida que a implantação passa para o preparo, essas permissões são restringidas. No momento em que a carga de trabalho é promovida para produção, o escopo para desenvolvedores é reduzido para acesso somente leitura.
Considere as identidades de aplicativo e gerenciamento separadamente. Na maioria das soluções, os usuários têm um nível de acesso diferente dos desenvolvedores ou operadores. Em alguns aplicativos, você pode usar sistemas de identidade ou diretórios diferentes para cada tipo de identidade. Considere o uso de escopos de acesso e a criação de funções separadas para cada identidade.
Atribua acesso com privilégios mínimos. Se a identidade tiver permissão de acesso, determine o nível de acesso. Comece com o menor privilégio para cada segmento e amplie esse escopo somente quando necessário.
Ao aplicar o menor privilégio, você limita os efeitos negativos se a identidade for comprometida. Se o acesso for limitado pelo tempo, a superfície de ataque será reduzida ainda mais. O acesso por tempo limitado é especialmente aplicável a contas críticas, como administradores ou componentes de software que têm uma identidade comprometida.
Compensação: o desempenho da carga de trabalho pode ser afetado por perímetros de identidade. A verificação explícita de cada solicitação requer ciclos de computação extras e E/S de rede extra.
O RBAC (controle de acesso baseado em função) também resulta em sobrecarga de gerenciamento. Manter o controle de identidades e seus escopos de acesso pode se tornar complexo em atribuições de função. A solução alternativa é atribuir funções a grupos de segurança em vez de identidades individuais.
Risco: as configurações de identidade podem ser complexas. Configurações incorretas podem afetar a confiabilidade da carga de trabalho. Por exemplo, suponha que haja uma atribuição de função configurada incorretamente que tenha acesso negado a um banco de dados. As solicitações começam a falhar, eventualmente causando problemas de confiabilidade que não podem ser detectados até o tempo de execução.
Para obter informações sobre controles de identidade, consulte Gerenciamento de identidade e acesso.
Em contraste com os controles de acesso à rede, a identidade valida o controle de acesso no momento do acesso. É altamente recomendável 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, consulte Padrões de segmentação de identidade.
Aprimore com a rede como um perímetro
Os perímetros de identidade são independentes de rede, enquanto os perímetros de rede aumentam a identidade, mas nunca a substituem. Os perímetros de rede são estabelecidos para controlar o raio de explosão, bloquear acesso inesperado, proibido e inseguro e ofuscar recursos de carga de trabalho.
Embora o foco principal do perímetro de identidade seja o privilégio mínimo, você deve presumir que haverá uma violação ao projetar o perímetro de rede.
Crie perímetros definidos por software em seu volume de rede usando serviços e recursos do Azure. Quando uma carga de trabalho (ou partes de uma determinada carga de trabalho) é colocada em segmentos separados, você controla o tráfego de ou para esses segmentos para proteger os caminhos de comunicação. Se um segmento for comprometido, ele será contido e impedido de se espalhar lateralmente pelo restante da rede.
Pense como um invasor para obter uma posição na carga de trabalho e estabelecer controles para minimizar a expansão adicional. Os controles devem detectar, conter e impedir que invasores obtenham acesso a toda a carga de trabalho. Aqui estão alguns exemplos de controles de rede como um perímetro:
- Defina o perímetro de borda entre as redes públicas e a rede em que a carga de trabalho é colocada. Restrinja a linha de visão das redes públicas à sua rede o máximo possível.
- Implemente zonas desmilitarizadas (DMZs) na frente do aplicativo com controles adequados por meio de firewalls.
- Crie microssegmentação em sua rede privada agrupando 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 redes funcionais de carga de trabalho de redes operacionais.
Para obter padrões comuns relacionados à segmentação de rede, consulte Padrões de segmentação de rede.
Compensação: os controles de segurança de rede geralmente são caros porque estão incluídos nos SKUs premium. A configuração de regras em firewalls geralmente resulta em uma complexidade esmagadora, exigindo amplas exceções.
A conectividade privada altera o design arquitetônico, geralmente adicionando mais componentes, como jump boxes para acesso privado a nós de computação.
Como os perímetros de rede são baseados em pontos de controle, ou saltos, na rede, cada salto pode ser um ponto potencial de falha. Esses pontos podem afetar a confiabilidade do sistema.
Risco: os controles de rede são baseados em regras e há uma chance significativa de configuração incorreta, o que é uma preocupação de confiabilidade.
Para obter informações sobre controles de rede, consulte Rede e conectividade.
Defina funções e linhas claras de responsabilidade
A segmentação que evita confusão e riscos de segurança é obtida definindo claramente as linhas de responsabilidade dentro de uma equipe de carga de trabalho.
Documente e compartilhe funções e funções para criar consistência e facilitar a comunicação. Designe grupos ou funções individuais responsáveis pelas principais funções. Considere as funções internas 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. Esses modelos podem variar de um único grupo de TI centralizado até equipes independentes de TI e DevOps.
Risco: a associação a grupos pode mudar ao longo do tempo à medida que os funcionários entram ou saem de equipes ou mudam de função. O gerenciamento de funções entre segmentos pode resultar em sobrecarga de gerenciamento.
Organize recursos para promover a segmentação
A segmentação permite isolar recursos de carga de trabalho de outras partes da organização ou até mesmo dentro da equipe. Os constructos do Azure, como grupos de gerenciamento, assinaturas, ambientes e grupos de recursos, são maneiras de organizar seus recursos que promovem a segmentação. Aqui estão alguns exemplos de isolamento no nível do recurso:
- A persistência poliglota envolve uma combinação de tecnologias de armazenamento de dados em vez de um único sistema de banco de dados para suportar a segmentação. Use a persistência poliglota para separação por vários modelos de dados, separação de funcionalidades, como armazenamento e análise de dados, ou para separar por padrões de acesso.
- Aloque um serviço para cada servidor ao organizar sua computação. Esse nível de isolamento minimiza a complexidade e pode ajudar a conter um ataque.
- O Azure fornece isolamento interno para alguns serviços, por exemplo, separação de computação do armazenamento. Para obter outros exemplos, consulte Isolamento na nuvem pública do Azure.
Compensação: o isolamento de recursos pode resultar em um aumento no TCO (custo total de propriedade). Para armazenamentos de dados, pode haver complexidade e coordenação adicionais durante a recuperação de desastre.
Facilitação do Azure
Determinados serviços do Azure estão disponíveis para uso na implementação de uma estratégia de segmentação, conforme descrito nas seções a seguir.
Identidade
O RBAC do Azure dá suporte à segmentação isolando o acesso por função de trabalho. Somente determinadas ações são permitidas para determinadas funções e escopos. Por exemplo, funções de trabalho que só precisam observar o sistema podem receber permissões de leitor versus permissões de colaborador que permitem que a identidade gerencie recursos.
Para obter mais informações, consulte Práticas recomendadas para RBAC.
Rede
Redes virtuais: as redes virtuais fornecem contenção de recursos no nível da rede sem adicionar tráfego entre duas redes virtuais. As redes virtuais são criadas em espaços de endereçamento privados dentro de uma assinatura
NSG (grupos de segurança de rede): um mecanismo de controle de acesso para controlar o tráfego entre recursos em redes virtuais e redes externas, como a Internet. Implemente rotas definidas pelo usuário (UDR) para controlar o próximo salto para o tráfego. Os NSGs podem levar sua estratégia de segmentação a um nível granular criando perímetros para uma sub-rede, uma VM (máquina virtual) ou um grupo de VMs. Para obter informações sobre possíveis operações com sub-redes no Azure, consulte Sub-redes.
ASGs (grupos de segurança de aplicativos): os ASGs permitem agrupar um conjunto de VMs em uma marca de aplicativo e definir regras de tráfego que são aplicadas a cada uma das VMs subjacentes.
Firewall do Azure: um serviço nativo de nuvem, que pode ser implantado em sua rede virtual ou em implantações de hub da WAN Virtual do Azure. Use o Firewall do Azure para filtrar o tráfego que flui entre recursos de nuvem, a Internet e os recursos locais. Use o Firewall do Azure ou o Gerenciador de Firewall do Azure para criar regras ou políticas que permitem ou negam o tráfego usando controles de camada 3 a camada 7. Filtre o tráfego da Internet usando o Firewall do Azure e terceiros direcionando o tráfego por meio de provedores de segurança de terceiros para filtragem avançada e proteção do usuário. O Azure dá suporte à implantação de solução de virtualização de rede, o que ajuda na segmentação de firewalls de terceiros.
Exemplo
Aqui estão alguns padrões comuns para segmentar uma carga de trabalho no Azure. Escolha um padrão com base em suas necessidades.
Este exemplo se baseia no ambiente de TI (Tecnologia da Informação) estabelecido na linha de base de segurança (SE:01). O diagrama abaixo mostra a segmentação no nível do grupo de gerenciamento feita por uma organização.
Padrões de segmentação de identidade
Padrão 1: Agrupamento baseado em cargo
Uma maneira de organizar grupos de segurança é por cargo, como engenheiro de software, administrador de banco de dados, engenheiro de confiabilidade do site, engenheiro de garantia de qualidade ou analista de segurança. Essa abordagem envolve a criação de grupos de segurança para sua equipe de carga de trabalho com base em suas funções, sem considerar o trabalho que precisa ser realizado. Conceda permissões RBAC aos grupos de segurança, permanentes ou JIT (just in time), de acordo com suas responsabilidades na carga de trabalho. Atribua princípios humanos e de serviço a grupos de segurança com base em seu acesso conforme necessário.
A associação é altamente visível no nível de atribuição de função, facilitando a visualização a que uma função tem acesso. Cada pessoa geralmente é membro de apenas um grupo de segurança, o que facilita a integração e o desligamento. No entanto, a menos que os cargos se sobreponham perfeitamente às responsabilidades, o agrupamento baseado em títulos não é ideal para a implementação de privilégios mínimos. Você pode acabar combinando a implementação com o agrupamento baseado em função.
Padrão 2: Agrupamento baseado em função
O agrupamento baseado em funções é um método de organização de grupo de segurança que reflete o trabalho discreto que precisa ser realizado, sem levar em conta a estrutura da equipe. Com esse padrão, você concede permissões RBAC aos grupos de segurança, permanentes 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 em seu acesso conforme necessário. Sempre que possível, use 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 de banco de dados de produção
- Operadores de banco 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 live-site/triagem
- Acesso total à pré-produção
Essa abordagem mantém o acesso mais estrito com privilégios mínimos e fornece grupos de segurança onde o escopo é evidente, o que facilita a auditoria de associações em relação às funções de trabalho executadas. Muitas vezes, existe uma função interna do Azure para corresponder a essa função de trabalho.
No entanto, a associação é abstraída em pelo menos uma camada, forçando você a ir ao provedor de identidade para entender quem está no grupo ao examinar da perspectiva do recurso. Além disso, uma pessoa precisa ter várias associações mantidas para cobertura completa. A matriz de grupos de segurança sobrepostos pode ser complexa.
O Padrão 2 é recomendado para tornar os padrões de acesso o foco, não o organograma. Os organogramas e as funções dos membros às vezes mudam. Capturar o gerenciamento de identidade e acesso da carga de trabalho de uma perspectiva funcional permite que você abstraia a organização da equipe do gerenciamento seguro da carga de trabalho.
Padrões de segmentação de rede
Padrão 1: Segmentação dentro de uma carga de trabalho (limites flexíveis)
Nesse padrão, a carga de trabalho é colocada em uma única rede virtual usando sub-redes para marcar limites. A segmentação é obtida usando duas sub-redes, uma para banco de dados e outra para cargas de trabalho da Web. Você deve configurar NSGs que permitam que a Sub-rede 1 se comunique apenas com a Sub-rede 2 e a Sub-rede 2 se comunique apenas com a Internet. Esse padrão fornece controle de nível de camada 3.
Padrão 2: Segmentação em uma carga de trabalho
Esse padrão é um exemplo de segmentação no nível da plataforma. Os componentes decarga de trabalho são distribuídos por várias redes sem emparelhamento entre elas. Toda a comunicação é roteada por meio de um intermediário que serve como um ponto de acesso público. A equipe de carga de trabalho é proprietária de todas as redes.
O Padrão 2 fornece contenção, mas tem a complexidade adicional de gerenciamento e dimensionamento de rede virtual. A comunicação entre as duas redes ocorre pela internet pública, o que pode ser um risco. Também há latência com conexões públicas. No entanto, as duas redes podem ser emparelhadas, quebrando a segmentação conectando-as para criar um segmento maior. O emparelhamento deve ser feito quando nenhum outro ponto de extremidade público for necessário.
Considerações | Padrão 1 | Padrão 2 |
---|---|---|
Conectividade e roteamento: como cada segmento se comunica | O roteamento do sistema fornece conectividade padrão para componentes de carga de trabalho. Nenhum componente externo pode se comunicar com a carga de trabalho. | Dentro da rede virtual, o mesmo que o padrão 1. Entre as redes, o tráfego passa pela internet pública. Não há conectividade direta entre as redes. |
Filtragem de tráfego no nível da rede | O tráfego entre os segmentos é permitido por padrão. Use NSGs ou ASGs para filtrar o tráfego. | Dentro da rede virtual, o mesmo que o padrão 1. Entre as redes, você pode filtrar o tráfego de entrada e saída por meio de um firewall. |
Pontos de extremidade públicos não intencionais abertos | As placas de interface de rede (NICs) não obtêm IPs públicos. As redes virtuais não são expostas ao gerenciamento de API da Internet. | O mesmo que o padrão 1. Ponto de extremidade público aberto pretendido em uma rede virtual, que pode ser configurado incorretamente para aceitar mais tráfego. |
Organização do recurso
Organizar recursos do Azure com base na responsabilidade de propriedade
Considere uma propriedade do Azure que contém várias cargas de trabalho e componentes de serviço compartilhado, como redes virtuais de hub, firewalls, serviços de identidade e serviços de segurança, como o Microsoft Sentinel. Os componentes em todo o patrimônio devem ser agrupados com base em suas áreas funcionais, cargas de trabalho e propriedade. Por exemplo, os recursos de rede compartilhados devem ser agrupados em uma única assinatura e gerenciados por uma equipe de rede. Os componentes dedicados a cargas de trabalho individuais devem estar em seu próprio segmento e podem ser divididos com base em camadas de aplicativo ou outros princípios organizacionais.
Conceda acesso para gerenciar recursos em segmentos individuais criando atribuições de função RBAC. Por exemplo, a equipe de rede em nuvem pode receber acesso administrativo à assinatura que contém seus recursos, mas não a assinaturas de carga de trabalho individuais.
Uma boa estratégia de segmentação permite identificar facilmente os proprietários de cada segmento. Considere usar marcas de recurso do Azure para anotar grupos de recursos ou assinaturas com a equipe proprietária.
Configurar e revisar o controle de acesso
Conceda acesso apropriado com base na necessidade, definindo claramente segmentos para seus recursos.
Considere o princípio do privilégio mínimo ao definir políticas de controle de acesso. É importante distinguir entre operações do plano de controle (gerenciamento do próprio recurso) e operações do plano de dados (acesso aos dados armazenados pelo recurso). Por exemplo, suponha que você tenha uma carga de trabalho que contenha um banco de dados com informações confidenciais sobre funcionários. Você pode conceder acesso de gerenciamento a alguns usuários que precisam definir configurações como backups de banco de dados ou usuários que monitoram o desempenho do servidor de banco de dados. No entanto, esses usuários não devem ser capazes de consultar os dados confidenciais armazenados no banco de dados. Selecione permissões que concedam o escopo mínimo necessário para que os usuários desempenhem suas funções. Revise regularmente as atribuições de função para cada segmento e remova o acesso que não é mais necessário.
Observação
Algumas funções altamente privilegiadas, como a função de proprietário no RBAC, dão aos usuários a capacidade de conceder a outros usuários acesso a um recurso. Limite quantos usuários ou grupos recebem a função de proprietário e revise regularmente os logs de auditoria para garantir que eles executem apenas operações válidas.
Links relacionados
- Isolamento na nuvem pública do Azure
- Recomendações para RBAC
- Visão geral das redes virtuais
- ASGs
- Firewall do Azure
- Visão geral do Firewall Manager
Lista de verificação de segurança
Consulte o conjunto completo de recomendações.