Este artigo descreve uma arquitetura de Acesso Condicional que adere aos princípios de Confiança Zero. A arquitetura usa uma abordagem baseada em persona para formar uma estrutura estruturada de Acesso Condicional.
Arquitetura de Confiança Zero de Acesso Condicional
Você primeiro precisa escolher uma arquitetura. Recomendamos que você considere uma arquitetura de Acesso Condicional de Confiança Direcionada ou Zero Trust. Este diagrama mostra as configurações correspondentes:
A arquitetura de Acesso Condicional Zero Trust é a que melhor se adapta aos princípios do Zero Trust. Se você selecionar a opção Todos os aplicativos na nuvem em uma política de Acesso Condicional, todos os pontos de extremidade serão protegidos pelos controles de concessão fornecidos, como usuário conhecido e dispositivo conhecido ou compatível. Mas a política não se aplica apenas aos pontos de extremidade e aplicativos que oferecem suporte ao Acesso Condicional. Aplica-se a qualquer ponto de extremidade com o qual o usuário interage.
Um exemplo é um ponto de extremidade de fluxo de login de dispositivo que é usado em várias novas ferramentas do PowerShell e do Microsoft Graph. O fluxo de login do dispositivo fornece uma maneira de permitir a entrada de um dispositivo no qual não é possível mostrar uma tela de entrada, como um dispositivo IoT.
Um comando de entrada baseado em dispositivo é executado no dispositivo fornecido e um código é mostrado ao usuário. Este código é usado em outro dispositivo. O usuário vai e especifica seu nome de usuário e https://aka.ms/devicelogin senha. Após o início de sessão a partir do outro dispositivo, o início de sessão é bem-sucedido no dispositivo IoT nesse contexto de utilizador.
O desafio com este início de sessão é que não suporta Acesso Condicional baseado em dispositivo. Isso significa que ninguém pode usar as ferramentas e os comandos se você aplicar uma política de linha de base que exija usuário conhecido e dispositivo conhecido para todos os aplicativos na nuvem. Existem outras aplicações que têm o mesmo problema com o Acesso Condicional baseado em dispositivo.
A outra arquitetura, a de destino, baseia-se no princípio de que você segmenta apenas aplicativos individuais que deseja proteger nas políticas de Acesso Condicional. Nesse caso, o login do dispositivo para pontos de extremidade anteriormente cobertos por todos os aplicativos de nuvem, como chamadas gráficas para o ID do Microsoft Entra, não é protegido pelas políticas de Acesso Condicional, portanto, eles continuam a funcionar.
Ao usar o device-login como exemplo para diferenciar as duas arquiteturas, você pode autenticar com device-login. O login de dispositivo pode ser potencialmente permitido para um ou alguns aplicativos individuais, dado que cada aplicativo é segmentável e, portanto, pode ser excluído em uma política de Acesso Condicional que requer login baseado em dispositivo.
O desafio com a arquitetura de destino é que você pode esquecer de proteger todos os seus aplicativos na nuvem. Mesmo assim, você escolheria todos os aplicativos selecionáveis nas políticas de Acesso Condicional. Você deixa o acesso aos aplicativos que não podem ser selecionados desprotegido. Os exemplos incluem o acesso ao portal do Office, ao portal do Azure EA (Enterprise Agreement) e ao portal de informações de segurança, que são portais muito confidenciais.
Outra consideração é que o número de aplicativos do Office 365 e do Microsoft Entra aumenta com o tempo, à medida que a Microsoft e os parceiros lançam novos recursos e os administradores de TI integram vários aplicativos com o Microsoft Entra ID. O acesso a todos esses aplicativos é protegido somente se você tiver um mecanismo que detete qualquer novo aplicativo que ofereça suporte ao Acesso Condicional e que aplique automaticamente uma política a ele. Criar e manter esse script pode ser difícil.
Além disso, o número máximo suportado de aplicações para qualquer política de Acesso Condicional é de aproximadamente 250. Poderá conseguir adicionar até 600 aplicações antes de receber um erro sobre a carga útil ter sido excedida, mas esse número não é suportado.
Personas de Acesso Condicional
Há muitas maneiras de estruturar políticas de Acesso Condicional. Uma abordagem consiste em estruturar políticas com base na sensibilidade do recurso a que se acede. Na prática, essa abordagem pode ser difícil de implementar de uma forma que ainda proteja o acesso aos recursos para vários usuários.
Por exemplo, você pode definir uma política de Acesso Condicional que exija um usuário conhecido e um dispositivo conhecido para acessar um recurso confidencial que precisa ser acessado por convidados e funcionários. Quando os convidados tentam aceder a partir de um dispositivo gerido, o pedido de acesso não funciona. Você precisaria ajustar a política de Acesso Condicional para atender a ambos os requisitos, o que normalmente resultaria em uma política que atendesse ao requisito menos seguro.
Outra abordagem é tentar definir políticas de acesso com base em onde um usuário está na organização. Essa abordagem pode resultar em muitas políticas de Acesso Condicional e pode não ser gerenciável.
Uma melhor abordagem consiste em estruturar políticas relacionadas com necessidades de acesso comuns e agrupar um conjunto de necessidades de acesso numa persona para um grupo de utilizadores que tenham as mesmas necessidades. Personas são tipos de identidade que compartilham atributos, responsabilidades, experiências, objetivos e acesso comuns da empresa.
Entender como os ativos e recursos da empresa são acessados por várias personas é essencial para desenvolver uma estratégia abrangente de Zero Trust.
Algumas personas de Acesso Condicional sugeridas pela Microsoft são mostradas aqui:
A Microsoft também recomenda definir uma persona separada para identidades que não fazem parte de nenhum outro grupo de persona. Isso é chamado de persona global. Global destina-se a impor políticas para identidades que não estão em um grupo de persona e políticas que devem ser aplicadas para todas as personas.
As seções a seguir descrevem algumas personas recomendadas.
A nível mundial
Global é uma persona/espaço reservado para políticas que são de natureza geral. É usado para definir políticas que se aplicam a todas as personas ou que não se aplicam a uma persona específica. Use-o para apólices que não são cobertas por outras personas. Você precisa dessa persona para proteger todos os cenários relevantes.
Por exemplo, suponha que você deseja usar uma política para bloquear a autenticação herdada para todos os usuários. Você pode torná-la uma política global em vez de usar um grupo de políticas herdadas que podem ser diferentes para várias personas.
Outro exemplo: você quer bloquear uma determinada conta ou usuário de aplicativos específicos, e o usuário ou conta não faz parte de nenhuma das personas. Por exemplo, se você criar uma identidade de nuvem no locatário do Microsoft Entra, essa identidade não fará parte de nenhuma das outras personas porque não lhe serão atribuídas funções do Microsoft Entra. Você ainda pode querer bloquear a identidade do acesso aos serviços do Office 365.
Talvez você queira bloquear todo o acesso de identidades que não são cobertas por nenhum grupo de persona. Ou talvez você queira apenas impor a autenticação multifator.
Administradores
Neste contexto, um administrador é qualquer identidade não convidada, na nuvem ou sincronizada, que tenha qualquer ID do Microsoft Entra ou outra função de administrador do Microsoft 365 (por exemplo, no Microsoft Defender for Cloud Apps, Exchange, Defender for Endpoint ou Compliance Manager). Como os hóspedes que têm essas funções são cobertos por uma persona diferente, os hóspedes são excluídos dessa persona.
Algumas empresas têm contas separadas para as funções de administrador confidenciais nas quais essa persona se baseia. Idealmente, os administradores usam essas contas confidenciais de uma Estação de Trabalho de Acesso Privilegiado (PAW). Mas muitas vezes vemos que as contas de administrador são usadas em estações de trabalho padrão, onde o usuário apenas alterna entre contas em um dispositivo.
Talvez você queira diferenciar com base na sensibilidade das funções de administrador de nuvem e atribuir funções menos confidenciais do Azure à persona Internals em vez de usar contas separadas. Em vez disso, você pode usar a elevação Just-In-Time (JIT). Nesse caso, um usuário é direcionado por dois conjuntos de políticas de Acesso Condicional, um para cada persona. Se você usa PAWs, também pode querer introduzir políticas que usam filtros de dispositivo no Acesso Condicional para restringir o acesso para que os administradores sejam permitidos apenas em PAWs.
Programadores
A persona de desenvolvedores contém usuários que têm necessidades exclusivas. Eles são baseados em contas do Ative Directory sincronizadas com o Microsoft Entra ID, mas precisam de acesso especial a serviços como Azure DevOps, pipelines de CI/CD, fluxo de código de dispositivo e GitHub. A persona de desenvolvedores pode incluir usuários que são considerados internos e outros considerados externos, mas uma pessoa deve estar em apenas uma das personas.
Internos
Internals contém todos os usuários que têm uma conta do Ative Directory sincronizada com o Microsoft Entra ID, que são funcionários da empresa e que trabalham em uma função de usuário final padrão. Recomendamos que você adicione usuários internos que são desenvolvedores à persona de desenvolvedores.
Externos
Essa persona contém todos os consultores externos que têm uma conta do Ative Directory sincronizada com o Microsoft Entra ID. Recomendamos que você adicione usuários externos que são desenvolvedores à persona de desenvolvedores.
Hóspedes
Convidados mantém todos os usuários que têm uma conta de convidado do Microsoft Entra que foi convidada para o locatário do cliente.
GuestAdmins
A persona GuestAdmins mantém todos os usuários que têm uma conta de convidado do Microsoft Entra atribuída a qualquer uma das funções de administrador mencionadas anteriormente.
Microsoft365ServiceAccounts
Essa persona contém contas de serviço baseadas em usuário na nuvem (Microsoft Entra ID) que são usadas para acessar serviços do Microsoft 365 quando nenhuma outra solução atende à necessidade, como usar uma identidade de serviço gerenciado.
AzureServiceAccounts
Essa persona contém contas de serviço baseadas em usuário na nuvem (Microsoft Entra ID) que são usadas para acessar serviços do Azure (IaaS/PaaS) quando nenhuma outra solução atende à necessidade, como usar uma identidade de serviço gerenciado.
CorpServiceAccounts
Essa persona contém contas de serviço baseadas no usuário que têm todas estas características:
- Originar-se do Ative Directory local.
- São usados no local ou de uma máquina virtual baseada em IaaS em outro datacenter (nuvem), como o Azure.
- São sincronizados com uma instância do Microsoft Entra que acessa qualquer serviço do Azure ou do Microsoft 365.
Este cenário deve ser evitado.
Identidades de carga de trabalho
Essa persona contém identidades de máquina, como entidades de serviço do Microsoft Entra e identidades gerenciadas. O Acesso Condicional agora oferece suporte à proteção do acesso a recursos dessas contas, com algumas limitações em relação às condições e controles de concessão disponíveis.
Aceder a cartões de modelo
Recomendamos que você use cartões de modelo de acesso para definir as características de cada persona. Eis um exemplo:
O cartão de modelo para cada persona fornece informações para criar as políticas de Acesso Condicional específicas para cada persona.
Orientações sobre Acesso Condicional
Analise uma estrutura de Acesso Condicional que inclua uma abordagem estruturada para agrupar políticas com base nas personas criadas.
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.
Próximos passos
- Caminho de aprendizagem: implementar e gerenciar identidade e acesso
- O que é o Acesso Condicional?
- Políticas de Acesso Condicional comuns