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 de Acesso Condicional estruturada.
Arquitetura de Confiança Zero de Acesso Condicional
Primeiro, você precisa escolher uma arquitetura. Recomendamos que você considere uma arquitetura de Acesso Condicional de Confiança Zero ou Direcionada. Este diagrama mostra as configurações correspondentes:
A arquitetura de Acesso Condicional de Confiança Zero é a que melhor se ajusta aos princípios da Confiança Zero. Se você selecionar a opção Todos os aplicativos de 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 em conformidade. Mas a política não se aplica apenas aos pontos de extremidade e aplicativos que dão 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 logon do dispositivo usado em várias novas ferramentas do PowerShell e do Microsoft Graph. O fluxo de logon 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 especificado e um código é mostrado ao usuário. Esse código é usado em outro dispositivo. O usuário vai para https://aka.ms/devicelogin e especifica seu nome de usuário e senha. Após a entrada do outro dispositivo, a entrada é bem-sucedida no dispositivo IoT nesse contexto de usuário.
O desafio com essa entrada é que ela não dá suporte ao Acesso Condicional baseado em dispositivo. Isso significa que ninguém poderá usar as ferramentas e os comandos se você aplicar uma política de linha de base que exija um usuário conhecido e um dispositivo conhecido para todos os aplicativos de nuvem. Há outros aplicativos que têm o mesmo problema com o Acesso Condicional baseado em dispositivo.
A outra arquitetura, a direcionada uma, baseia-se no princípio de que você tem como alvo apenas aplicativos individuais que você deseja proteger nas políticas de Acesso Condicional. Nesse caso, o logon do dispositivo para pontos de extremidade cobertos anteriormente por todos os aplicativos de nuvem, como chamadas de grafo para a ID do Microsoft Entra, não é protegido pelas políticas de Acesso Condicional, portanto, eles continuam funcionando.
Ao usar o logon do dispositivo como exemplo para diferenciar as duas arquiteturas, você pode se autenticar com o logon do dispositivo. O logon do dispositivo pode potencialmente ser permitido para um ou alguns aplicativos individuais, considerando que cada aplicativo é direcionado e, portanto, pode ser excluído em uma política de Acesso Condicional que requer logon baseado em dispositivo.
O desafio com a arquitetura de direcionada é que você pode esquecer de proteger todos os seus aplicativos de 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 desprotegidos. Exemplos incluem acesso ao portal do Office, ao portal do EA do Azure (Enterprise Agreement) e ao portal de informações de segurança, que são todos portais muito confidenciais.
Outra consideração é que o número de aplicativos do Office 365 e do Microsoft Entra aumenta ao longo do tempo, à medida que a Microsoft e os parceiros lançam novos recursos e à medida que seus administradores de TI integram vários aplicativos à ID do Microsoft Entra. O acesso a todos esses aplicativos será protegido somente se você tiver um mecanismo que detecte qualquer novo aplicativo que dê 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 de aplicativos com suporte para qualquer política de Acesso Condicional é aproximadamente 250. Você pode adicionar até 600 aplicativos antes de receber um erro sobre o conteúdo ser excedido, mas esse número não tem suporte.
Personas de Acesso Condicional
Há muitas maneiras de estruturar políticas de Acesso Condicional. Uma abordagem é estruturar políticas com base na sensibilidade do recurso que está sendo acessado. 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 exige um usuário conhecido e um dispositivo conhecido para acesso a um recurso confidencial que precisa ser acessado por convidados e funcionários. Quando os convidados tentarem o acesso de um dispositivo gerenciado, a solicitação de acesso não funcionará. Você precisaria ajustar a política de Acesso Condicional para atender aos dois requisitos, o que normalmente resultaria em uma política que atenda 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 ser incontrolável.
Uma abordagem melhor é estruturar políticas relacionadas às necessidades comuns de acesso e agrupar um conjunto de necessidades de acesso em uma persona para um grupo de usuários que têm 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 corporativos são acessados por várias personas é essencial para desenvolver uma estratégia abrangente de Confiança Zero.
Algumas personas de Acesso Condicional sugeridas da 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 personas. Isso é chamado de persona global. O global destina-se a impor políticas para identidades que não estão em um grupo de personas e políticas que devem ser impostas para todas as personas.
As seções a seguir descrevem algumas personas recomendadas.
Global
Global é uma persona/espaço reservado para políticas de natureza geral. Ele é 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 políticas 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ê queira 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ê deseja 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 faz parte de nenhuma das outras personas porque ela não está atribuída a nenhuma função do Microsoft Entra. Talvez você ainda queira bloquear o acesso da identidade 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 personas. Ou talvez você queira apenas impor a autenticação multifator.
administradores
Nesse contexto, um administrador é qualquer identidade não convidada, nuvem ou sincronizada, que tenha qualquer ID do Microsoft Entra ou outra função de administrador do Microsoft 365 (por exemplo, no Microsoft Defender para Aplicativos de Nuvem, Exchange, Defender para Ponto de Extremidade ou Gerenciador de Conformidade). Como os convidados que têm essas funções são cobertos por uma persona diferente, os convidados 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 PAW (Estação de Trabalho de Acesso Privilegiado). Mas geralmente vemos que as contas de administrador são usadas em estações de trabalho padrão, em que 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 Internas em vez de usar contas separadas. Em vez disso, você pode usar a elevação JIT (Just-In-Time). Nesse caso, um usuário é direcionado por dois conjuntos de políticas de Acesso Condicional, um para cada persona. Se você usar PAWs, talvez também queira introduzir políticas que usam filtros de dispositivo no Acesso Condicional para restringir o acesso para que os administradores sejam permitidos somente em PAWs.
desenvolvedores
A persona Desenvolvedores contém usuários que têm necessidades exclusivas. Eles são baseados em contas do Active Directory que são sincronizadas com a ID do Microsoft Entra, mas precisam de acesso especial a serviços como Azure DevOps, pipelines de CI/CD, fluxo de código do dispositivo e GitHub. A persona de Desenvolvedores pode incluir usuários considerados internos e outros considerados externos, mas uma pessoa deve estar em apenas uma das personas.
Internos
Os internos contêm todos os usuários que têm uma conta do Active Directory sincronizada com a ID do Microsoft Entra, 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 Desenvolvedores.
Externos
Essa persona contém todos os consultores externos que têm uma conta do Active Directory sincronizada com a ID do Microsoft Entra. Recomendamos que você adicione usuários externos que são desenvolvedores à persona Desenvolvedores.
Convidados
Os convidados conté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 conté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 no usuário da nuvem (Microsoft Entra ID) que são usadas para acessar os serviços do Microsoft 365 quando nenhuma outra solução atende à necessidade, como usar uma identidade de serviço gerenciada.
AzureServiceAccounts
Essa persona contém contas de serviço baseadas no usuário da nuvem (Microsoft Entra ID) que são usadas para acessar os serviços do Azure (IaaS/PaaS) quando nenhuma outra solução atende à necessidade, como usar uma identidade de serviço gerenciada.
CorpServiceAccounts
Essa persona contém contas de serviço baseadas no usuário que têm todas essas características:
- Originam-se do Active Directory local.
- São usados no local ou em 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.
Esse cenário deve ser evitado.
WorkloadIdentities
Essa persona contém identidades de máquina, como entidades de serviço do Microsoft Entra e identidades gerenciadas. O Acesso Condicional agora dá suporte à proteção do acesso a recursos dessas contas, com algumas limitações em relação a quais condições e controles de concessão estão disponíveis.
Acessar cartões de modelo
Recomendamos que você use cartões de modelo de acesso para definir as características de cada persona. Veja um exemplo:
O cartão de modelo para cada persona fornece entrada para criar as políticas de Acesso Condicional específicas para cada persona.
Diretrizes de acesso condicional
Examine uma estrutura de acesso condicional que inclui uma abordagem estruturada para políticas de agrupamento com base nas personas criadas.
Contribuintes
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Claus Jespersen | ID do consultor principal&s
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
- Roteiro de aprendizagem: implementar e gerenciar a identidade e o acesso
- O que é o Acesso Condicional?
- políticas comuns de acesso condicional
Recursos relacionados
- visão geral do Acesso Condicional
- princípios e dependências de design de Acesso Condicional
- estrutura e políticas de Acesso Condicional