Estrutura e políticas de acesso condicional
Este artigo fornece uma estrutura para implementar uma arquitetura de Acesso Condicional baseada em persona, como a descrita em Arquitetura de Confiança Zero de Acesso Condicional. Neste artigo, há detalhes sobre como formar e nomear as políticas de Acesso Condicional. Há também um ponto de partida para a criação de políticas.
Se você não usar uma estrutura como a fornecida aqui, incluindo um padrão de nomenclatura, as políticas tendem a ser criadas ao longo do tempo por diferentes pessoas de forma ad-hoc. Isso pode resultar em políticas que se sobrepõem. Se a pessoa que criou uma política não estiver mais disponível, pode ser difícil para outras pessoas saber o propósito da política.
Seguir um quadro estruturado facilita a compreensão das políticas. Também facilita a cobertura de todos os cenários e evita políticas conflitantes que são difíceis de solucionar.
Convenções de nomenclatura
Uma convenção de nomenclatura definida corretamente ajuda você e seus colegas a entender o propósito de uma política, o que facilita o gerenciamento de políticas e a solução de problemas. Sua convenção de nomenclatura deve se adequar à estrutura que você usa para estruturar suas políticas.
A política de nomenclatura recomendada é baseada em personas, tipos de política e aplicativos. Esta secção tem o seguinte aspeto:
<CANumber-Persona-PolicyType-App-Platform-GrantControl-OptionalDescription><><><><><><>
Os componentes deste nome são descritos aqui:
| Componente de nomenclatura | Descrição/Exemplo |
|---|---|
| Número CA | Usado para identificar rapidamente o escopo e a ordem do Tipo de Política. Exemplo: CA001-CA099. |
| Persona | Global, Admins, Internals, Externals, GuestUsers, GuestAdmins, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Tipo de Política | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Conformidade. |
| Aplicação | AllApps, O365 (para todos os serviços do Office 365), EXO (para Exchange Online). |
| Plataforma | AnyPlatform, Desconhecido, WindowsPhone, macOS, iOS, Android. |
| Controlo de Subvenções | Block, ADHJ, Compliant, Unmanaged (onde unmanaged é especificado na condição de estado do dispositivo). |
| Description | Descrição opcional do objetivo da política. |
Esquema de numeração
Para facilitar a administração, sugerimos este esquema de numeração:
| Grupo Persona | Atribuição do número |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internos | CA200-CA299 |
| CA-Persona-Externos | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceContas | CA800-CA899 |
| CA-Persona-WorkloadIdentities | CA900-CA999 |
| CA-Persona-Desenvolvedores | CA1000-CA1099 |
Tipos de política
Estes são os tipos de política recomendados:
| Tipo de política | Descrição/Exemplos |
|---|---|
| Proteção de Base | Para cada persona, há uma proteção de linha de base coberta por esse tipo de política. Para usuários em dispositivos gerenciados, isso normalmente é usuário conhecido e dispositivo conhecido. Para convidados externos, pode ser conhecido usuário e autenticação multifator. A proteção base é a política padrão para todos os aplicativos para usuários em determinada persona. Se um aplicativo específico tiver uma política diferente, exclua esse aplicativo da política de proteção básica e adicione uma política explícita direcionada apenas para esse aplicativo. Exemplo: Suponha que a proteção base para Internals é exigir usuário conhecido e dispositivo conhecido para todos os aplicativos de nuvem, mas você deseja permitir o Outlook na Web de qualquer dispositivo. Você pode excluir o Exchange Online da política de proteção base e adicionar uma política separada para o Exchange Online, onde você precisa de dispositivo conhecido OU autenticação multifator. |
| Proteção de identidade | Além da proteção básica para cada persona, você pode ter políticas de Acesso Condicional relacionadas à identidade. Exemplos: bloqueie a autenticação herdada, exija autenticação multifator extra para alto risco de usuário ou login, exija um dispositivo conhecido para registro de autenticação multifator. |
| Proteção de dados | Esse tipo de política indica políticas delta que protegem dados como uma camada extra sobre a proteção básica. Exemplos:
|
| AppProtection | Este tipo de política é outra adição à proteção básica. Exemplos:
|
| AttackSurfaceReduction | O objetivo deste tipo de política é mitigar vários ataques. Exemplos:
|
| Conformidade | Você pode usar uma política de conformidade para exigir que um usuário visualize os termos de uso dos hóspedes que acessam o atendimento ao cliente. |
Aplicação
A tabela a seguir descreve o componente Aplicativo de um nome de política:
| Nome da aplicação | Descrição/Exemplos |
|---|---|
| AllApps | AllApps indica que todos os aplicativos na nuvem são direcionados na política de Acesso Condicional. Todos os pontos de extremidade são cobertos, incluindo aqueles que oferecem suporte ao Acesso Condicional e aqueles que não suportam. Em alguns cenários, a segmentação de todos os aplicativos não funciona bem. Recomendamos segmentar todos os aplicativos na política base para que todos os pontos de extremidade sejam cobertos por essa política. Os novos aplicativos que aparecem no Microsoft Entra ID também aderirão automaticamente à política. |
| <AppName> | <AppName> é um espaço reservado para o nome de um aplicativo endereçado pela política. Evite tornar o nome demasiado longo. Nomes de exemplo:
|
Tipo de plataforma
A tabela a seguir descreve o componente Plataforma de um nome de política:
| Tipo de plataforma | Description |
|---|---|
| Qualquer plataforma | A política destina-se a qualquer plataforma. Normalmente, você configura isso selecionando Qualquer dispositivo. (Nas políticas de Acesso Condicional, tanto a palavra plataforma quanto a palavra dispositivo são usadas.) |
| iOS | A política tem como alvo as plataformas iOS da Apple. |
| Android | A política tem como alvo as plataformas Google Android. |
| Windows | Esta política destina-se à plataforma Windows. |
| Linux | Esta política destina-se às plataformas Linux. |
| Telemóvel Windows | A política destina-se a plataformas Windows Phone. |
| macOS | A política tem como alvo as plataformas macOS |
| iOSAndroid | A política visa as plataformas iOS e Android. |
| Desconhecido | A política destina-se a qualquer plataforma não listada anteriormente. Normalmente, você configura isso incluindo Qualquer Dispositivo e excluindo todas as plataformas individuais. |
Tipos de controlo de subvenções
A tabela a seguir descreve o componente Controle de Concessão de um nome de política:
| Tipo de subvenção | Descrição/Exemplos |
|---|---|
| Bloquear | A política bloqueia o início de sessão |
| MFA | A política requer autenticação multifator. |
| Compatível | A política requer um dispositivo compatível, conforme determinado pelo Endpoint Manager, portanto, o dispositivo precisa ser gerenciado pelo Endpoint Manager. |
| CompliantorAADHJ | A política requer um dispositivo compatível OU um dispositivo associado híbrido Microsoft Entra. Um computador padrão da empresa que ingressou no domínio também é o Hybrid Microsoft Entra ID associado. Telefones celulares e computadores com Windows 10 que são cogerenciados ou que o Microsoft Entra ingressou podem ser compatíveis. |
| CompliantandAADHJ | A política requer um dispositivo compatível E o Microsoft Entra híbrido ingressado. |
| Compatível com MFAorCompliant | A política requer um dispositivo compatível OU autenticação multifator, se não estiver em conformidade. |
| Compatível com MFAandCompliant | A política requer um dispositivo compatível E autenticação multifator. |
| MFAorAADHJ | A política requer um computador associado híbrido do Microsoft Entra OU autenticação multifator se não for um computador associado híbrido do Microsoft Entra. |
| MFAandAADHJ | A política requer um computador associado ao Microsoft Entra híbrido E autenticação multifator. |
| RequireApprovedClient | A política requer aplicativo cliente aprovado. |
| AppProtection | A política requer proteção do aplicativo |
| Não Gerido | A política destina-se a dispositivos que não são conhecidos pelo Microsoft Entra ID. Por exemplo, você pode usar esse tipo de concessão para permitir o acesso ao Exchange Online de qualquer dispositivo. |
Localizações com nome
Recomendamos que você defina estes locais padrão para uso em políticas de Acesso Condicional:
- IPs confiáveis / Redes internas. Essas sub-redes IP representam locais e redes que têm restrições de acesso físico ou outros controles em vigor, como gerenciamento do sistema do computador, autenticação no nível da rede ou deteção de intrusão. Esses locais são mais seguros, portanto, a aplicação do Acesso Condicional pode ser relaxada. Considere se o Azure ou outros locais de datacenter (IPs) devem ser incluídos nesse local ou ter seus próprios locais nomeados.
- IPs confiáveis da Citrix. Se você tiver o Citrix no local, pode ser útil configurar endereços IPv4 de saída separados para os farms da Citrix, se precisar ser capaz de se conectar a serviços de nuvem a partir de sessões da Citrix. Nesse caso, você pode excluir esses locais das políticas de Acesso Condicional, se necessário.
- Localizações Zscaler, se aplicável. Os computadores têm um agente ZPA instalado e encaminham todo o tráfego para a Internet para ou através da nuvem Zscaler. Por isso, vale a pena definir os IPs de origem do Zscaler no Acesso Condicional e exigir que todos os pedidos de dispositivos não móveis passem pelo Zscaler.
- Países/regiões com os quais permitir negócios. Pode ser útil dividir países/regiões em dois grupos de locais: um que representa áreas do mundo onde os funcionários normalmente trabalham e outro que representa outros locais. Isso permite que você aplique controles adicionais a solicitações originadas de fora das áreas onde sua organização normalmente opera.
- Locais onde a autenticação multifator pode ser difícil ou impossível. Em alguns cenários, exigir autenticação multifator pode dificultar o trabalho dos funcionários. Por exemplo, a equipe pode não ter tempo ou oportunidade para responder a desafios frequentes de autenticação multifator. Ou, em alguns locais, a triagem de RF ou interferência elétrica pode dificultar o uso de dispositivos móveis. Normalmente, você usaria outros controles nesses locais ou eles poderiam ser confiáveis.
Os controles de acesso baseados em localização dependem do IP de origem de uma solicitação para determinar a localização do usuário no momento da solicitação. Não é fácil realizar falsificação na internet pública, mas a proteção proporcionada pelos limites da rede pode ser considerada menos relevante do que já foi. Não recomendamos confiar apenas na localização como condição para o acesso. Mas, para alguns cenários, pode ser o melhor controle que você pode usar, como se estiver protegendo o acesso de uma conta de serviço local usada em um cenário não interativo.
Políticas de Acesso Condicional recomendadas
Criámos uma folha de cálculo que contém as políticas de Acesso Condicional recomendadas. Você pode baixar a planilha aqui.
Use as políticas sugeridas como ponto de partida.
Suas políticas provavelmente mudarão ao longo do tempo para acomodar casos de uso que são importantes para o seu negócio. Aqui estão alguns exemplos de cenários que podem exigir alterações:
- Implemente o acesso somente leitura ao Exchange Online para funcionários que usam qualquer dispositivo não gerenciado com base em autenticação multifator, proteção de aplicativo e um aplicativo cliente aprovado.
- Implemente a proteção de informações para garantir que informações confidenciais não sejam baixadas sem uma proteção aprimorada fornecida pela Proteção de Informações do Azure.
- Fornece proteção contra copiar e colar pelos hóspedes.
Várias visualizações estão atualmente entrando em visualização pública, portanto, espere atualizações para o conjunto sugerido de políticas iniciais de Acesso Condicional (CA) em breve.
Orientações sobre Acesso Condicional
Agora que você tem um conjunto inicial de políticas de Acesso Condicional, precisa implantá-las de forma controlada e em fases. Sugerimos que você use um modelo de implantação.
Aqui está uma abordagem:
A ideia é primeiro implantar políticas para um pequeno número de usuários dentro de um grupo de persona. Você pode usar um grupo associado do Microsoft Entra chamado Persona Ring 0 para essa implantação. Depois de verificar se tudo funciona, altere a atribuição para um grupo, Persona Ring 1, que tenha mais membros, e assim por diante.
Em seguida, você habilita as políticas usando a mesma abordagem baseada em anel até que todas as políticas sejam implantadas.
Normalmente, você gerencia os membros do anel 0 e do anel 1 manualmente. Um grupo de anel 2 ou 3 que contém centenas ou até milhares de usuários pode ser gerenciado por meio de um grupo dinâmico baseado em uma porcentagem dos usuários em uma determinada persona.
O uso de anéis como parte de um modelo de implantação não é apenas para implantação inicial. Você também pode usá-lo quando novas políticas ou alterações nas políticas existentes forem necessárias.
Com uma implantação concluída, você também deve projetar e implementar os controles de monitoramento que foram discutidos nos princípios de Acesso Condicional.
Além de automatizar a implantação inicial, convém automatizar as alterações nas políticas usando pipelines de CI/CD. Você pode usar o Microsoft365DSC para essa automação.
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
- Políticas de acesso condicional