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 na 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 maneira 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, poderá ser difícil para outras pessoas conhecerem a finalidade da política.
Seguir uma estrutura estruturada facilita a compreensão das políticas. Também facilita a cobertura de todos os cenários e evitar 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 a finalidade de uma política, o que permite facilitar o gerenciamento de políticas e a solução de problemas. Sua convenção de nomenclatura deve se ajustar à estrutura usada para estruturar suas políticas.
A política de nomenclatura recomendada é baseada em personas, tipos de política e aplicativos. Tem esta aparência:
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>
Os componentes desse nome são descritos aqui:
| Componente de nomenclatura | Descrição/exemplo |
|---|---|
| Número da CA | Usado para identificar rapidamente o escopo e a ordem do Tipo de Política. Exemplo: CA001-CA099. |
| Persona | Global, Administradores, Internos, Externos, 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, Unknown, WindowsPhone, macOS, iOS, Android. |
| Controle de concessão | Bloquear, ADHJ, Conformidade, Não Gerenciado (não gerenciado é especificado na condição de estado do dispositivo). |
| Descrição | Descrição opcional da finalidade da política. |
Esquema de numeração
Para facilitar a administração, sugerimos esse esquema de numeração:
| Grupo de personas | Alocação de número |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| CA-Persona-WorkloadIdentities | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
Tipos de política
Estes são os tipos de política recomendados:
| Tipo de política | Descrição/exemplos |
|---|---|
| BaseProtection | Para cada pessoa, há uma proteção básica coberta por este tipo de política. Para usuários em dispositivos gerenciados, esse normalmente é um usuário conhecido e um dispositivo conhecido. Para convidados externos, pode ser usuário conhecido e autenticação multifator. A proteção base é a política padrão para todos os aplicativos para usuários no perfil especificado. Se um aplicativo específico tiver uma política diferente, exclua esse aplicativo da política de proteção base e adicione uma política explícita direcionada somente a esse aplicativo. Exemplo: suponha que a proteção básica para Internos seja exigir um usuário conhecido e um dispositivo conhecido para todos os aplicativos em nuvem, mas que você deseje permitir o Outlook na web a partir 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, na qual você precisa de autenticação multifator ou dispositivo conhecido. |
| Proteção de Identidade | Além da proteção base para cada persona, você pode ter políticas de Acesso Condicional relacionadas à identidade. Exemplos: bloquear a autenticação herdada, exigir autenticação multifator extra para alto risco de entrada ou usuário, exigir dispositivo conhecido para registro de autenticação multifator. |
| Proteção de Dados | Esse tipo de política indica políticas delta que protegem os dados como uma camada extra sobre a proteção base. Exemplos:
|
| AppProtection | Esse tipo de política é outra adição à proteção base. Exemplos:
|
| AttackSurfaceReduction | A finalidade desse tipo de política é atenuar vários ataques. Exemplos:
|
| Conformidade | Você pode usar uma política de conformidade para exigir que um usuário exiba os termos de uso para convidados que acessam serviços de atendimento ao cliente. |
Aplicação
A tabela a seguir descreve o componente App de um nome de política:
| Nome do aplicativo | Descrição/exemplos |
|---|---|
| AllApps | AllApps indica que todos os aplicativos de nuvem são visados na política de Acesso Condicional. Todos os pontos de extremidade são abordados, incluindo aqueles que dão suporte ao Acesso Condicional e aqueles que não o fazem. Em alguns cenários, direcionar todos os aplicativos não funciona bem. É recomendável direcionar todos os aplicativos na política base para que todos os pontos de extremidade sejam cobertos por essa política. Novos aplicativos que aparecem na ID do Microsoft Entra também aderirão automaticamente à política. |
| <AppName> | <AppName> é um espaço reservado para o nome de um aplicativo que a política aborda. Evite que o nome se torne muito longo. Nomes de exemplo:
|
Tipo de plataforma
A tabela a seguir descreve o componente Platform de um nome de política:
| Tipo de plataforma | Descrição |
|---|---|
| AnyPlatform | A política tem como destino qualquer plataforma. Normalmente, você configura isso selecionando Qualquer Dispositivo. (Nas políticas de Acesso Condicional, a palavra plataforma e a palavra dispositivo são usadas.) |
| Ios | A política tem como alvo plataformas Apple iOS. |
| Andróide | A política tem como alvo as plataformas Google Android. |
| Windows | Essa política tem como destino a plataforma Windows. |
| Linux | Essa política tem como destino as plataformas Linux. |
| WindowsPhone | A política tem como destino plataformas do Windows Phone. |
| macOS | A política tem como destino as plataformas macOS |
| iOSAndroid | A política tem como destino plataformas iOS e Android. |
| Desconhecido | A política tem como destino qualquer plataforma não listada anteriormente. Normalmente, você configura essa opção incluindo Any Device e excluindo todas as plataformas individuais. |
Permitir tipos de controle
A tabela a seguir descreve o componente Grant Control de um nome de política:
| Tipo de concessão | Descrição/exemplos |
|---|---|
| Bloquear | A política bloqueia a entrada |
| MFA | A política requer autenticação multifator. |
| Em conformidade | A política requer um dispositivo em conformidade, conforme determinado pelo Endpoint Manager, portanto, o dispositivo precisa ser gerenciado pelo Endpoint Manager. |
| CompliantorAADHJ | A política requer um dispositivo em conformidade OU um dispositivo ingressado híbrido no Microsoft Entra. Um computador corporativo padrão ingressado no domínio também é ingressado no Microsoft Entra ID. Telefones celulares e computadores Windows 10 cogerenciados ou ingressados no Microsoft Entra podem estar em conformidade. |
| CompliantandAADHJ | A política requer um dispositivo que esteja em conformidade E que esteja ingressado híbrido no Microsoft Entra. |
| MFAorCompliant | A política exige um dispositivo compatível OU autenticação multifator se o dispositivo não estiver em conformidade. |
| MFAandCompliant | A política exige uma autenticação multifator E um dispositivo em conformidade. |
| MFAorAADHJ | A política exigirá um computador ingressado híbrido no Microsoft Entra OU a autenticação multifator se não for um computador ingressado híbrido no Microsoft Entra. |
| MFAandAADHJ | A política exige computador ingressado híbrido no Microsoft Entra E uma autenticação multifator. |
| RequireApprovedClient | A política requer um aplicativo cliente aprovado. |
| AppProtection | A política requer proteção do aplicativo |
| Não gerenciado | A política visa 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. |
Locais nomeados
Recomendamos que você defina esses 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 de sistema de computador, autenticação em nível de rede ou detecção de intrusão. Esses locais são mais seguros, portanto, a imposição do Acesso Condicional pode ser relaxada. Considere se o Azure ou outros locais de datacenter (IPs) devem ser incluídos neste local ou se devem ter suas próprias locações nomeadas.
- IPs confiáveis do Citrix. Se você tiver o Citrix local, talvez seja útil configurar endereços IPv4 de saída separados para os farms do Citrix, se você precisar ser capaz de se conectar aos serviços de nuvem a partir de sessões do Citrix. Nesse caso, você poderá excluir esses locais das políticas de Acesso Condicional, se necessário.
- Locais do 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 do Zscaler. Portanto, vale a pena definir os IPs de origem do Zscaler no Acesso Condicional e exigir que todas as solicitações 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 em que os funcionários normalmente trabalham e um que representa outros locais. Isso permite que você aplique controles adicionais a solicitações originadas de fora das áreas em que sua organização normalmente opera.
- Locais em que a autenticação multifator pode ser difícil ou impossível. Em alguns cenários, a exigência de autenticação multifator pode dificultar o trabalho dos funcionários. Por exemplo, a equipe pode não ter tempo ou oportunidade de responder a desafios frequentes de autenticação multifator. Ou, em alguns locais, a triagem rf ou a interferência elétrica podem 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ções na Internet pública, mas a proteção proporcionada pelos limites de rede pode ser considerada menos relevante do que antes. Não recomendamos depender apenas do local como condição para acesso. Mas, para alguns cenários, pode ser o melhor controle que você pode usar, como se você estiver protegendo o acesso de uma conta de serviço do local que é usada em um cenário não interativo.
Políticas de acesso condicional recomendadas
Criamos uma planilha que contém 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 importantes para sua empresa. 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 utilizam qualquer dispositivo não gerenciado, com base na autenticação de múltiplos fatores, proteção de aplicativo e uso de um aplicativo cliente aprovado.
- Implemente a proteção de informações para garantir que as informações confidenciais não são baixadas sem uma proteção aprimorada fornecida pela Proteção de Informações do Azure.
- Forneça proteção contra cópia e colagem por convidados.
Atualmente, várias funcionalidades estão entrando em versão prévia pública, então aguarde atualizações para o conjunto sugerido de políticas iniciais de CA (Acesso Condicional) em breve.
Diretrizes de acesso condicional
Agora que você tem um conjunto inicial de políticas de Acesso Condicional, precisa implantá-las de maneira controlada e em fases. Sugerimos que você use um modelo de implantação.
Aqui está uma abordagem:
A ideia é primeiro implantar políticas em um pequeno número de usuários dentro de um grupo de personas. Você pode usar um grupo associado do Microsoft Entra chamado Persona Ring 0 para essa implantação. Depois de verificar se tudo funciona, você altera a atribuição para um grupo, Persona Ring 1, que tem mais membros e assim por diante.
Em seguida, habilite 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 são 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, você pode querer automatizar as alterações nas políticas usando pipelines de CI/CD. Você pode usar o Microsoft365DSC para essa automação.
Colaboradores
Este artigo é mantido pela Microsoft. 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.
Próximas etapas
- Roteiro de aprendizagem: implementar e gerenciar a identidade e o acesso
- políticas de acesso condicional
Recursos relacionados
- visão geral do Acesso Condicional
- Princípios e dependências de design de acesso condicional
- Design de Acesso Condicional baseado em Confiança Zero e personas