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 design
Vamos começar com alguns princípios de design.
Acesso Condicional como um mecanismo de política de Confiança Zero
A abordagem de Confiança Zero da Microsoft inclui acesso condicional como o mecanismo de política principal. Segue uma visão geral dessa abordagem:
Baixe um arquivo SVG dessa 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:
Veja abaixo uma exibição mais detalhada dos elementos do Acesso Condicional e o que ele aborda:
Este diagrama mostra o Acesso Condicional e elementos relacionados que podem ajudar a proteger o acesso do usuário aos recursos, em vez de acesso não interativo ou não humano. O diagrama a seguir descreve os dois tipos de identidade.
O Acesso Condicional tem se concentrado principalmente na proteção do acesso aos recursos por humanos interativos. À medida que o número de identidades não humanas aumenta, o acesso delas também deve ser considerado. A Microsoft oferece dois recursos relacionados à proteção de acesso bidirecional das identidades de carga de trabalho.
- Proteção do acesso a aplicativos representados por uma identidade de carga de trabalho que não é selecionável no portal de Acesso Condicional do Microsoft Entra. Essa opção é permitida usando atributos de segurança. Designar 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.
- Proteção do acesso a recursos iniciados pelas identidades de carga de trabalho (entidades de serviço). Um novo recurso "Identidades de Carga de Trabalho do Microsoft Entra" é oferecido em uma licença separada que dá suporte a esse cenário. Ele inclui o gerenciamento do ciclo de vida de identidades de carga de trabalho, incluindo a proteção do acesso a recursos com Acesso Condicional.
Modelo de acesso corporativo
A Microsoft já forneceu diretrizes e princípios para acesso a recursos locais com base em um modelo de camadas:
- Camada 0: controladores de domínio, PKI (infraestrutura de chave pública), servidores de Serviços de Federação do Active Directory (AD FS) e soluções de gerenciamento que gerenciam esses servidores
- Camada 1: servidores que hospedam aplicativos
- Camada 2: dispositivos cliente
Esse modelo ainda é relevante para recursos locais. Para ajudar a proteger o acesso aos recursos na nuvem, a Microsoft recomenda uma estratégia de controle de acesso que:
- Seja abrangente e consistente.
- Aplique rigorosamente os princípios de segurança em toda a pilha de tecnologia.
- Seja flexível o suficiente para atender às necessidades da 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 do Windows Server Active Directory local. No novo modelo, a Camada 0 se expande para se tornar o plano de controle, a Camada 1 consiste no plano de dados e de gerenciamento e a Camada 2 abrange o acesso de usuário e aplicativo.
A Microsoft recomenda mover o controle e o gerenciamento para serviços de nuvem que usam o Acesso Condicional como o plano de controle principal e o mecanismo de política, definindo e impondo assim 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:
- Aplicativos modernos: aplicativos que usam protocolos de autenticação modernos.
- Aplicativos legados: via proxy de aplicativo do Microsoft Entra.
- Soluções de VPN e acesso remoto: soluções como VPN do Microsoft Always On, Cisco AnyConnect, Palo Alto Networks, F5, Fortinet, Citrix e Zscaler.
- Documentos, email e outros arquivos: por Proteção de Informações da Microsoft.
- Aplicativos SaaS.
- Aplicativos executados em outras nuvens, como AWS ou Google Cloud (com base em federação).
Princípios de Confiança Zero
Os três principais princípios de Confiança Zero 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 de Confiança Zero.
A usabilidade deve ser sempre considerada um princípio implícito.
Princípios de acesso condicional
Com base nas informações anteriores, veja abaixo um resumo dos princípios sugeridos. A Microsoft recomenda que você crie um modelo de acesso com base no Acesso Condicional alinhado aos três principais fundamentos da Confiança Zero a Microsoft:
Verificação explícita
- Mova o plano de controle para a nuvem. Integre aplicativos com o Microsoft Entra ID e proteja-os usando o Acesso Condicional.
- Considere que todos os clientes são externos.
Usar o acesso de privilégio mínimo
- Avalie o acesso com base na conformidade e no risco, incluindo risco do usuário, risco de conexão e 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 do Microsoft Entra e o Acesso Condicional para proteção.
- Use uma VPN baseada em Acesso Condicional para acessar o recurso. Restrinja o acesso ao nível do aplicativo ou nome DNS.
Pressupor a violação
- Infraestrutura de rede do segmento.
- Minimize o uso de PKI corporativo.
- Migre o SSO (logon único) do AD FS para o PHS (sincronização de hash de senha).
- Minimize as dependências em DCs usando o KDC Kerberos no Microsoft Entra ID.
- Mova o plano de gerenciamento para a nuvem. Gerenciar dispositivos com o Microsoft Endpoint Manager.
Veja abaixo alguns princípios mais detalhados e práticas recomendadas para 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 o Azure DevOps/GitHub ou os Aplicativos Lógicos do Azure.
- Use o modo de bloco para acesso geral somente se e onde você precisar.
- Verifique se todos os aplicativos e sua plataforma estão protegidos. O Acesso Condicional não tem uma função "negar tudo" implícita.
- Proteja usuários privilegiados em todos os sistemas RBAC (controle de acesso baseado em função) do Microsoft 365.
- Exigir a alteração de senha e a autenticação multifator para usuários e entradas de alto risco (imposto 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 no Acesso Condicional.
- Proteger sistemas privilegiados, como acesso aos portais de administrador para o Office 365, o Azure, o AWS e o Google Cloud.
- Evite executar 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 dispositivo desconhecidas ou sem suporte.
- 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 foram atendidas antes da interrupção.
Criar dependências e tecnologias relacionadas
O diagrama a seguir mostra dependências e tecnologias relacionadas. Algumas das tecnologias são pré-requisitos para Acesso Condicional. Outras dependem do Acesso Condicional. O design descrito neste documento se concentra principalmente no Acesso Condicional e não nas tecnologias relacionadas.
Diretrizes de Acesso Condicional
Para mais informações, confira Design de Acesso Condicional baseado em Confiança Zero e personas.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Claus Jespersen | ID do Consultor de Entidade de Segurança&Sec
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.