Recomendações para a construção de 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 e perímetros intencionais em seu projeto de arquitetura e na pegada 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 da 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 projetar 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 de recursos | Uma estratégia para agrupar recursos relacionados por fluxos dentro de um segmento. |
Role | Um conjunto de permissões necessárias para concluir uma função de trabalho. |
Segmento | 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 uma solução, incluindo a segmentação de recursos para fins de gerenciamento e controle de acesso.
A segmentação ajuda 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 viole um segmento de rede não possa obter acesso a outro segmentando cargas de trabalho com controles de identidade diferentes. Em um sistema seguro, os atributos de identidade e rede bloqueiam o acesso não autorizado e ocultam os ativos de serem expostos. Eis 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 aplicativos 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 é evitar que um atacante invada 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.
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 roteamento e segurança de rede 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 gestão 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 notar a distinção entre perímetros e isolamento. Perímetro refere-se aos pontos de localização que devem ser verificados. O isolamento tem a ver com 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 proporciona o alinhamento entre as equipas técnicas e define linhas claras de responsabilidade. A clareza reduz o risco de erros humanos 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 detetada em um componente de um sistema empresarial 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 na gestão. Há também uma compensação no custo. Por exemplo, mais recursos são provisionados quando ambientes de implantação executados lado a lado são segmentados.
Risco: A microssegmentação para 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 a 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 através dos limites de isolamento, independentemente da origem da solicitação de acesso. Use a identidade como um perímetro para:
Atribua acesso por função. As identidades só precisam de acesso aos segmentos necessários para fazer o 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 com que 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 e 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 os 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 diferente de acesso do que os desenvolvedores ou operadores. Em alguns aplicativos, você pode usar diferentes sistemas de identidade ou diretórios para cada tipo de identidade. Considere usar escopos de acesso e criar funções separadas para cada identidade.
Atribua acesso de 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 apenas 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 é reduzida ainda mais. O acesso por tempo limitado é especialmente aplicável a contas críticas, como administradores ou componentes de software que tenham 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 controle de acesso baseado em função (RBAC) 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. Erros de configuração podem afetar a confiabilidade da carga de trabalho. Por exemplo, suponha que haja uma atribuição de função mal configurada 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 detetados 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 revisões regulares de acesso 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.
Melhore com a 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 a substituem. Os perímetros de rede são estabelecidos para controlar o raio de explosão, bloquear acessos inesperados, proibidos e inseguros e ofuscar os recursos da carga de trabalho.
Embora o foco principal do perímetro de identidade seja o menor privilégio, você deve assumir que haverá uma violação ao projetar o perímetro de rede.
Crie perímetros definidos por software em sua pegada de rede usando os 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 estiver comprometido, ele será contido e impedido de se espalhar lateralmente pelo resto da rede.
Pense como um invasor para alcançar uma posição dentro da carga de trabalho e estabelecer controles para minimizar a expansão adicional. Os controles devem detetar, conter e impedir que invasores tenham acesso a toda a carga de trabalho. Aqui estão alguns exemplos de controles de rede como um perímetro:
- Defina seu perímetro de borda entre redes públicas e a rede onde sua carga de trabalho é colocada. Restrinja ao máximo a linha de visão de redes públicas para a sua rede.
- Implemente zonas desmilitarizadas (DMZs) na frente do aplicativo com controles adequados via 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 a partir de redes operacionais.
Para 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 nas SKUs premium. A configuração de regras em firewalls geralmente resulta em uma complexidade avassaladora, exigindo amplas exceções.
A conectividade privada altera o projeto arquitetônico, muitas vezes adicionando mais componentes, como caixas de salto 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. Estes pontos podem ter um efeito sobre a fiabilidade 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.
Definir papéis e linhas claras de responsabilidade
A segmentação que evita confusões e riscos de segurança é alcançada através da definição clara de linhas de responsabilidade dentro de uma equipe de carga de trabalho.
Documente e partilhe funções e funções para criar consistência e facilitar a comunicação. Designar grupos ou funções individuais responsáveis por funções essenciais. 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 a equipes de TI e DevOps majoritariamente 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. O gerenciamento de funções em todos os segmentos pode resultar em despesas gerais de gerenciamento.
Organizar 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. As construções 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 de 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 dar suporte à 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 de 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 custo total de propriedade (TCO). Para armazenamentos de dados, pode haver complexidade e coordenação adicionais durante a recuperação de desastres.
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. Apenas determinadas ações são permitidas para determinadas funções e escopos. Por exemplo, as 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ços privados dentro de uma assinatura
Grupos de segurança de rede (NSG): 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 máquina virtual (VM) ou um grupo de VMs. Para obter informações sobre possíveis operações com sub-redes no Azure, consulte Sub-redes.
Grupos de segurança de aplicativos (ASGs): 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 da nuvem, que pode ser implantado em sua rede virtual ou em implantações de hub WAN Virtual do Azure. Use o Firewall do Azure para filtrar o tráfego que flui entre recursos de nuvem, a Internet e recursos locais. Use o Firewall do Azure ou o Gerenciador de Firewall do Azure para criar regras ou políticas que permitam ou neguem 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 dispositivo virtual de rede, 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 nas suas necessidades.
Este exemplo baseia-se no ambiente de Tecnologia da Informação (TI) 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. Conceder permissões RBAC a grupos de segurança, em pé ou just in time (JIT), 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 do 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 desembarque. 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çõ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 precisa ser realizado, não levando em conta a estrutura da equipe. Com esse padrão, você concede aos grupos de segurança permissões RBAC, em pé ou JIT conforme necessário, de acordo com sua 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 ao vivo/triagem
- Pré-produção todos os acessos
Essa abordagem mantém o acesso de privilégios mínimos mais rigoroso e fornece grupos de segurança onde o escopo é evidente, o que facilita a auditoria de associações relativas à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 olhar da perspetiva 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 a identidade da sua carga de trabalho e o gerenciamento de acesso de uma perspetiva funcional permite que você abstraia sua organização de 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 é realizada usando duas sub-redes, uma para banco de dados e outra para cargas de trabalho da web. Você deve configurar NSGs que permitem que a Sub-rede 1 se comunique apenas com a Sub-rede 2 e a Sub-rede 2 para se comunicar somente com a Internet. Esse padrão fornece controle de nível de camada 3.
Padrão 2: Segmentação dentro de uma carga de trabalho
Esse padrão é um exemplo de segmentação no nível da plataforma. Os responsáveis pela carga de trabalhoestão espalhados por várias redes sem emparelhamento entre elas. Toda a comunicação é encaminhada através de um intermediário que serve como 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 através da Internet pública, o que pode ser um risco. Há também 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 é 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 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 finais públicos abertos não intencionais | As placas de interface de rede (NICs) não recebem IPs públicos. As redes virtuais não estã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 de recursos
Organizar recursos do Azure com base na responsabilidade de propriedade
Considere uma propriedade do Azure que contenha 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 toda a propriedade 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 aplicativos 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 recursos do Azure para anotar grupos de recursos ou assinaturas com a equipe do proprietário.
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 menor privilégio 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 executem suas tarefas. Revise regularmente as atribuições de função para cada segmento e remova o acesso que não é mais necessário.
Nota
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.
Ligações relacionadas
- Isolamento na nuvem pública do Azure
- Recomendações para o RBAC
- Visão geral das redes virtuais
- ASGs
- Azure Firewall
- Visão geral do Firewall Manager
Lista de verificação de segurança
Consulte o conjunto completo de recomendações.