Neste artigo, você aprenderá sobre princípios de design e dependências para um cenário de Acesso Condicional baseado em Confiança Zero.
Princípios de conceção
Vamos começar com alguns princípios de design.
Acesso condicional como um mecanismo de política de confiança zero
A abordagem da Microsoft ao Zero Trust inclui o Acesso Condicional como o principal mecanismo de política. Aqui está uma visão geral dessa abordagem:
Baixe um arquivo SVG desta arquitetura.
O Acesso Condicional é usado como o mecanismo de política para uma arquitetura de Confiança Zero que abrange a definição e a imposição de políticas. Com base em vários sinais ou condições, o Acesso Condicional pode bloquear ou dar acesso limitado aos recursos, conforme mostrado aqui:
Aqui está uma visão mais detalhada dos elementos do Acesso Condicional e o que ele abrange:
Este diagrama mostra o Acesso Condicional e elementos relacionados que podem ajudar a proteger o acesso do usuário aos recursos, em oposição ao acesso não interativo ou não humano. O diagrama a seguir descreve ambos os tipos de identidades.
O Acesso Condicional tem se concentrado principalmente na proteção do acesso de humanos interativos aos recursos. À medida que o número de identidades não humanas cresce, o acesso a partir delas também deve ser considerado. A Microsoft oferece dois recursos relacionados à proteção de acesso e de identidades de carga de trabalho.
- Proteger o acesso a aplicativos representados por uma identidade de carga de trabalho que não pode ser selecionada no portal de Acesso Condicional do Microsoft Entra. Esta opção é suportada usando atributos de segurança. Atribuir um atributo de segurança a identidades de carga de trabalho e selecioná-las no portal de Acesso Condicional do Microsoft Entra faz parte da licença P1 do Microsoft Entra ID.
- Proteger o acesso a recursos iniciados por identidades de carga de trabalho (entidades de serviço). Um novo recurso "Microsoft Entra Workload Identities" é oferecido em uma licença separada que oferece suporte a esse cenário. Inclui o gerenciamento do ciclo de vida das identidades de carga de trabalho, incluindo a proteção do acesso a recursos com Acesso Condicional.
Modelo de acesso empresarial
A Microsoft já forneceu orientações e princípios para o acesso a recursos locais com base em um modelo de hierarquização:
- Nível 0: Controladores de domínio, PKI (infraestrutura de chave pública), servidores dos Serviços de Federação do Ative Directory (AD FS) e soluções de gerenciamento que gerenciam esses servidores
- Nível 1: Servidores que hospedam aplicativos
- Nível 2: Dispositivos cliente
Esse modelo ainda é relevante para recursos locais. Para ajudar a proteger o acesso a recursos na nuvem, a Microsoft recomenda uma estratégia de controle de acesso que:
- É abrangente e consistente.
- Aplica rigorosamente os princípios de segurança em toda a pilha de tecnologia.
- É flexível o suficiente para atender às necessidades da sua organização.
Com base nesses princípios, a Microsoft criou o seguinte modelo de acesso corporativo:
O modelo de acesso corporativo substitui o modelo de camada herdado, que se concentrava em conter o escalonamento não autorizado de privilégios em um ambiente local do Ative Directory do Windows Server. No novo modelo, a Camada 0 se expande para se tornar o plano de controle, a Camada 1 consiste no plano de gerenciamento e dados e a Camada 2 abrange o acesso do usuário e do aplicativo.
A Microsoft recomenda mover o controle e o gerenciamento para serviços de nuvem que usam o Acesso Condicional como o principal plano de controle e mecanismo de política, definindo e impondo o acesso.
Você pode estender o mecanismo de política de Acesso Condicional do Microsoft Entra para outros pontos de imposição de política, incluindo:
- Aplicações modernas: Aplicações que utilizam protocolos de autenticação modernos.
- Aplicativos herdados: Via proxy de aplicativo Microsoft Entra.
- VPN e soluções de acesso remoto: Soluções como Microsoft Always On VPN, Cisco AnyConnect, Palo Alto Networks, F5, Fortinet, Citrix e Zscaler.
- Documentos, correio eletrónico e outros ficheiros: através da Proteção de Informações da Microsoft.
- Aplicações SaaS.
- Aplicativos executados em outras nuvens, como AWS ou Google Cloud (com base na federação).
Princípios do Zero Trust
Os três principais princípios de Zero Trust que a Microsoft define parecem ser compreendidos, especialmente pelos departamentos de segurança. No entanto, às vezes a importância da usabilidade é negligenciada durante o design de soluções Zero Trust.
A usabilidade deve ser sempre considerada um princípio implícito.
Princípios do Acesso Condicional
Com base nas informações anteriores, aqui está um resumo dos princípios sugeridos. A Microsoft recomenda que você crie um modelo de acesso baseado no Acesso Condicional alinhado com os três principais princípios do Microsoft Zero Trust:
Verificar explicitamente
- Mova o plano de controle para a nuvem. Integre aplicativos com o Microsoft Entra ID e proteja-os usando o Acesso Condicional.
- Considere todos os clientes como externos.
Usar de acesso menos privilegiado
- Avalie o acesso com base na conformidade e no risco, incluindo o risco do utilizador, o risco de início de sessão e o risco do dispositivo.
- Use estas prioridades de acesso:
- Acesse o recurso diretamente, usando o Acesso Condicional para proteção.
- Publique o acesso ao recurso usando o proxy de aplicativo Microsoft Entra, usando o Acesso Condicional para proteção.
- Use VPN baseada em Acesso Condicional para acessar o recurso. Restrinja o acesso ao nível do aplicativo ou nome DNS.
Assumir violação
- Segmentar a infraestrutura de rede.
- Minimize o uso da PKI corporativa.
- Migre o logon único (SSO) do AD FS para a sincronização de hash de senha (PHS).
- Minimize as dependências em DCs usando Kerberos KDC no Microsoft Entra ID.
- Mova o plano de gerenciamento para a nuvem. Gerencie dispositivos usando o Microsoft Endpoint Manager.
Aqui estão alguns princípios mais detalhados e práticas recomendadas para o Acesso Condicional:
- Aplique os princípios de Confiança Zero ao Acesso Condicional.
- Use o modo somente relatório antes de colocar uma política em produção.
- Teste cenários positivos e negativos.
- Use o controle de alteração e revisão nas políticas de Acesso Condicional.
- Automatize o gerenciamento de políticas de Acesso Condicional usando ferramentas como Azure DevOps/GitHub ou Azure Logic Apps.
- Use o modo de bloqueio para acesso geral somente se e onde precisar.
- Certifique-se de que todas as aplicações e a sua plataforma estão protegidas. O Acesso Condicional não tem um "negar tudo" implícito.
- Proteja usuários privilegiados em todos os sistemas de controle de acesso baseado em função (RBAC) do Microsoft 365.
- Exigir alteração de senha e autenticação multifator para usuários de alto risco e entradas (impostas pela frequência de entrada).
- Restrinja o acesso de dispositivos de alto risco. Use uma política de conformidade do Intune com uma verificação de conformidade em Acesso Condicional.
- Proteja sistemas privilegiados, como o acesso aos portais de administrador do Office 365, Azure, AWS e Google Cloud.
- Impeça sessões persistentes do navegador para administradores e em dispositivos não confiáveis.
- Bloqueie a autenticação herdada.
- Restrinja o acesso de plataformas de dispositivos desconhecidos ou não suportados.
- Exigir dispositivo compatível para acesso aos recursos, quando possível.
- Restrinja o registro de credenciais fortes.
- Considere o uso da política de sessão padrão que permite que as sessões continuem se houver uma interrupção, se as condições apropriadas forem satisfeitas antes da interrupção.
Dependências de projeto e tecnologias relacionadas
O diagrama a seguir mostra dependências e tecnologias relacionadas. Algumas das tecnologias são pré-requisitos para o Acesso Condicional. Outros dependem do Acesso Condicional. O design descrito neste documento se concentra principalmente no Acesso Condicional e não nas tecnologias relacionadas.
Orientações sobre Acesso Condicional
Para obter mais informações, consulte design de Acesso Condicional com base em Zero Trust e personas.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Claus Jespersen | ID do Consultor Principal&Sec
Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.