Neste artigo, você aprenderá sobre princípios de design e dependências para um cenário de Acesso Condicional baseado em Confiança Zero.
Estruturar princípios
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:
Faça o download de 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.
Use o 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.
Assuma a 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 legada.
- 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 baseado em Zero Trust e personas.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Claus Jespersen - Brasil | Consultor Principal ID&sec
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.