Planejar uma implantação de acesso condicional

O planejamento da implantação de acesso condicional é essencial para garantir a estratégia de acesso obrigatória da sua organização para aplicativos e recursos. As políticas de acesso condicional fornecem uma excelente flexibilidade de configuração. No entanto, essa flexibilidade também significa que você deve planejar cuidadosamente para evitar resultados indesejáveis.

O Microsoft Entra Conditional Access combina sinais como usuário, dispositivo e local para automatizar decisões e impor políticas de acesso organizacional a recursos. Essas políticas de Acesso Condicional ajudam a equilibrar a segurança e a produtividade, impondo controles de segurança quando necessário e ficando fora do caminho do usuário quando não for necessário.

O Acesso Condicional é a base do mecanismo de política de segurança Confiança Zero da Microsoft.

A Microsoft fornece padrões de segurança que garantem um nível básico de segurança habilitado nos locatários que não têm a licença P1 ou P2 do Microsoft Entra ID. Com o acesso condicional, você pode criar políticas que fornecem a mesma proteção que os padrões de segurança, mas com granularidade. O acesso condicional e os padrões de segurança não devem ser associados, pois criar políticas de acesso condicional impede que você habilite os padrões de segurança.

Pré-requisitos

• Um locatário do Microsoft Entra em funcionamento com a licença P1, P2 ou de avaliação do Microsoft Entra ID habilitada. Se necessário, crie um gratuitamente.
  • É necessário ter a licença P2 do Microsoft Entra ID para incluir o risco de Proteção do Microsoft Entra ID nas políticas de acesso condicional.
• Os administradores que interagem com o Acesso Condicional devem ter uma das seguintes atribuições de função, dependendo das tarefas que estão executando. Para seguir o princípio de Confiança Zero de privilégios mínimos, considere usar o Privileged Identity Management (PIM) para ativar atribuições de funções privilegiadas just-in-time.
  • Ler as configurações e as políticas de Acesso Condicional
    • Leitor de segurança
  • Criar ou modificar as políticas de Acesso Condicional
    • Administrador de acesso condicional
• Um usuário de teste (não um administrador) que permite verificar se as políticas funcionam conforme o esperado antes da implantação em usuários reais. Se você precisar criar um usuário, confira Início Rápido: Adicionar novos usuários ao Microsoft Entra ID.
• Um grupo do qual o usuário de teste é membro. Para criar um grupo, consulte Como criar um grupo e adicionar membros no Microsoft Entra ID.

Comunicar a alteração

A comunicação é fundamental para o sucesso de qualquer nova funcionalidade. Você deve se comunicar proativamente com seus usuários sobre como a experiência deles muda, quando muda e como obter suporte em caso de problemas.

Componentes de política de acesso condicional

As políticas de Acesso Condicional respondem a perguntas sobre quem pode acessar seus recursos, quais recursos eles podem acessar e mediante quais condições. As políticas podem ser projetadas para permitir o acesso, limitar o acesso a controles de sessão ou bloquear o acesso. Você cria uma Política de Acesso Condicional definindo as instruções if-then, da seguinte maneira:

Exclusões de usuário

As políticas de Acesso Condicional são ferramentas avançadas, recomendamos excluir as seguintes contas das suas políticas:

• Contas de acesso de emergência ou de interrupção para impedir o bloqueio de conta em todo o locatário. No cenário improvável de todos os administradores serem bloqueados de seu locatário, sua conta administrativa de acesso de emergência poderá ser usada para fazer logon no locatário para seguir as etapas de recuperação do acesso.
  • Mais informações podem ser encontradas no artigo Gerenciar contas de acesso de emergência no Microsoft Entra ID.
• Contas de serviço e entidades de serviço, como a conta de sincronização do Microsoft Entra Connect. As contas de serviço são contas não interativas que não estão ligadas a nenhum usuário específico. Normalmente, elas são usadas por serviços de back-end que permitem acesso programático a aplicativos, mas também são usadas para entrar em sistemas para fins administrativos. Contas de serviço como essas devem ser excluídas, pois a MFA não pode ser concluída programaticamente. As chamadas feitas pelas entidades de serviço não serão bloqueadas pelas políticas de Acesso Condicional com um escopo que inclua os usuários. Use o Acesso Condicional a identidades de carga de trabalho para definir políticas direcionadas a entidades de serviço.
  • Se a sua organização tiver essas contas em uso em scripts ou código, considere substituí-las por identidades gerenciadas. Como solução temporária, você pode excluir essas contas específicas da política de linha de base.

Faça as perguntas certas

Estas são algumas perguntas comuns sobre atribuições e controles de acesso. Documente as respostas para as perguntas de cada política antes de compilá-las.

Identidades de usuários ou de carga de trabalho

• Quais usuários, grupos, funções do diretório ou identidades de carga de trabalho estão incluídos na política ou excluídos dela?
• Quais contas ou grupos de acesso de emergência devem ser excluídos da política?

Aplicativos na nuvem ou ações

Essa política será aplicada a qualquer aplicativo, ação do usuário ou contexto de autenticação? Em caso afirmativo:

• A quais aplicativos ou serviços a política se aplicará?
• Quais ações do usuário estão sujeitas a esta política?
• A quais contextos de autenticação essa política será aplicada?

Filtrar aplicativos

Usar o filtro para aplicativos para incluir ou excluir aplicativos em vez de especificá-los individualmente ajuda as organizações a:

• Dimensionar e direcionar facilmente qualquer número de aplicativos.
• Gerenciar facilmente aplicativos com requisitos de política semelhantes.
• Reduzir o número de políticas individuais.
• Reduzir erros durante a edição de políticas: não é necessário adicionar/remover aplicativos manualmente da política. Basta gerenciar os atributos.
• Superar as restrições de tamanho da política.

Condições

• Quais plataformas de dispositivo estão incluídas na política ou excluídas dela?
• Quais são os locais de rede conhecidos da organização?
  • Quais locais estão incluídos na política ou excluídos dela?
• Quais tipos de aplicativos do cliente estão incluídos na política ou excluídos dela?
• Você precisa direcionar atributos de dispositivo específicos?
• Se estiver usando a Proteção do Microsoft Entra ID, você deseja incorporar o risco de entrada ou de usuário?

Risco de usuário e de entrada

As organizações com licenças P2 do Microsoft Entra ID podem incluir riscos do usuário e de logon nas políticas de acesso condicional. Essas adições podem ajudar a reduzir o atrito das medidas de segurança, exigindo autenticação multifator ou alteração de senha segura somente quando um usuário ou uma entrada é considerado arriscado.

Para obter mais informações sobre o risco e seu uso na política, confira o artigo O que é risco.

Bloquear ou conceder controles

Deseja conceder acesso aos recursos exigindo um ou mais dos seguintes itens?

• Autenticação multifator
• Dispositivo marcado como em conformidade
• Usar um dispositivo conectado de maneira híbrida ao Microsoft Entra
• Como usar um aplicativo cliente aprovado
• Política de proteção de aplicativo aplicada
• Alteração de senha
• Termos de Uso aceitos

Bloquear acesso é um controle poderoso que deve ser usado com o conhecimento apropriado. Políticas com instruções de bloco podem ter efeitos colaterais indesejados. Testes e validação adequados são vitais antes de habilitar o controle em escala. Ao fazer alterações, os administradores devem usar ferramentas como o modo somente relatório do Acesso condicional e a ferramenta de What If no Acesso condicional.

Controles de sessão

Deseja impor qualquer um dos seguintes controles de acesso em aplicativos de nuvem?

• Usar restrições de aplicativo impostas
• Usar o controle de aplicativos do acesso condicional
• Aplicar a frequência de entrada
• Usar sessão do navegador persistente
• Personalizar a avaliação contínua de acesso

Como combinar políticas

Ao criar e atribuir políticas, você deve levar em conta como os tokens de acesso funcionam. Os tokens de acesso permitem ou negam o acesso de acordo com o fato de o usuário que faz a solicitação ter sido ou não autorizado e autenticado. Se o solicitante puder provar que é quem afirma ser, ele poderá acessar os recursos ou funcionalidades protegidos.

Tokens de acesso são emitidos por padrão se uma condição de política de acesso condicional não disparar um controle de acesso.

Essa política não impede que o aplicativo tenha capacidade própria para bloquear acessos.

Por exemplo, considere um exemplo de política simplificada em que:

Usuários: GRUPO FINANCE
Acessando: APLICATIVO FOLHA DE PAGAMENTO
Controle de acesso: autenticação multifator

• O usuário A está no GRUPO FINANCE, ele é obrigado a executar a autenticação multifator para acessar o APLICATIVO FOLHA DE PAGAMENTO.
• O usuário B não está no GRUPO FINANCE. É emitido para ele um token de acesso e tem permissão para acessar o APLICATIVO FOLHA DE PAGAMENTO sem executar a autenticação multifator.

Para garantir que os usuários não pertencentes ao Grupo Finance não possam acessar o aplicativo de folha de pagamento, uma política separada deve ser criada para bloquear todos os outros usuários, como a seguinte política simplificada:

Usuários: incluir todos os usuários/Excluir GRUPO FINANCE
Acessando: APLICATIVO FOLHA DE PAGAMENTO
Controle de acesso: bloquear acesso

Agora, quando o Usuário B tenta acessar o APLICATIVO FOLHA DE PAGAMENTO, ele é bloqueado.

Recomendações

Levando em conta nossos aprendizados sobre o uso do Acesso Condicional e o suporte a outros clientes, aqui estão algumas recomendações com base em nossos aprendizados.

Aplicar políticas de Acesso Condicional a todos os aplicativos

Verifique se cada aplicativo tem, pelo menos, uma política de acesso condicional aplicada. Do ponto de vista da segurança, é melhor criar uma política que abrange todos os aplicativos de nuvem e excluir os aplicativos aos quais você não deseja aplicar a política. Essa prática garante que você não precise atualizar as políticas de acesso condicional sempre que integrar um novo aplicativo.

Minimizar o número de políticas de Acesso Condicional

A criação de uma política para cada aplicativo não é eficiente e resulta em uma administração difícil. O Acesso Condicional tem um limite de 195 políticas por locatário. Esse limite de política 195 inclui políticas de Acesso Condicional em qualquer estado, incluindo o modo somente relatório, ativado ou desativado.

Recomendamos que você analise seus aplicativos e agrupe-os em aplicativos que tenham os mesmos requisitos de recursos para os mesmos usuários. Por exemplo, se todos os aplicativos do Microsoft 365 ou todos os aplicativos de RH tiverem os mesmos requisitos para os mesmos usuários, crie uma só política e inclua todos os aplicativos aos quais ela se aplica.

As políticas de Acesso Condicional estão contidas em um arquivo JSON e esse arquivo está vinculado a um limite de tamanho que não esperamos que uma única política ultrapasse. Se você usar uma longa lista de GUIDs na política, poderá atingir esse limite. Se encontrar esses limites, recomendamos alternativas como:

• Usar grupos ou funções para incluir ou excluir usuários em vez de listar cada usuário individualmente.
• Usar filtro de aplicativos para incluir ou excluir aplicativos em vez de especificá-los individualmente.

Configurar o modo somente relatório

Por padrão, cada política criada com base no modelo é criada no modo somente relatório. Recomendamos que as organizações testem e monitorem o uso, para garantir o resultado pretendido, antes de ativar cada política.

Habilitar políticas no modo somente relatório. Depois de salvar uma política no modo somente de relatório, você poderá ver o efeito nas entradas em tempo real nos logs de entrada. Nos logs de entrada, selecione um evento e navegue até a guia Somente relatório para ver o resultado de cada política somente relatório.

Você pode exibir o efeitos agregados das políticas de Acesso Condicional na pasta de trabalho de Insights e Relatórios. Para acessar a pasta de trabalho, você precisa ter uma assinatura do Azure Monitor e transmitir seus logs de credenciais para um workspace do Log Analytics.

Planejar a interrupção

Para reduzir o risco de bloqueio durante interrupções imprevistas, planeje estratégias de resiliência para a organização.

Definir padrões de nomenclatura para suas políticas

Um padrão de nomenclatura ajuda você a localizar as políticas e a entender a finalidade delas sem precisar abri-las no portal de administração do Azure. Recomendamos que você denomine sua política com:

• Um número sequencial
• Os aplicativos de nuvem aos quais ela se aplica
• A resposta
• A quem ela se aplica
• Quando ela se aplica

Exemplo: uma política para exigir MFA dos usuários de marketing que acessam o aplicativo Dynamics CRP de redes externas pode ser:

Um nome descritivo ajuda você a manter uma visão geral da sua implementação de acesso condicional. O número de sequência será útil se você precisar fazer referência a uma política em uma conversa. Por exemplo, ao falar com um administrador ao telefone, você pode pedir a ele que abra a política CA01 para resolver um problema.

Padrões de nomenclatura para controles de acesso de emergência

Além das suas políticas ativas, você também deve implementar políticas desabilitadas que atuem como controles secundários de acesso resilientes em cenários de interrupção/emergência. O padrão de nomenclatura para as políticas de contingência deve incluir:

• HABILITAR EM EMERGÊNCIA no início para destacar o nome entre as outras políticas.
• O nome da interrupção a qual ele deve ser aplicado.
• Um número de sequência de ordenação para ajudar o administrador a saber em qual ordem as políticas devem ser habilitadas.

Exemplo: o seguinte nome indica que essa é a primeira de quatro políticas a habilitar se houver uma interrupção de MFA:

• EM01 – ATIVAR EM CASO DE EMERGÊNCIA: interrupção da MFA [1/4] - Exchange SharePoint: exigir a conexão híbrida do Microsoft Entra para usuários VIP.

Bloquear países/regiões dos quais você nunca espera um login

O Microsoft Entra ID permite criar locais nomeados. Crie a lista de países/regiões que são permitidos e uma política de bloqueio de rede com esses "países/regiões permitidos" como uma exclusão. Essa opção gera menos sobrecarga para os clientes que estão baseados em localizações geográficas menores. Certifique-se de isentar suas contas de acesso de emergência dessa política.

Implantar políticas de acesso condicional

Quando estiver pronto, implante as políticas de Acesso Condicional em fases.

Criar suas políticas de Acesso Condicional

Confira os Modelos de política de Acesso Condicional e as Políticas de segurança comuns para organizações do Microsoft 365 a fim de obter uma vantagem. Esses modelos são uma maneira conveniente de implantar recomendações da Microsoft. Lembre-se de excluir suas contas de acesso de emergência.

Avaliar o impacto da política

Recomendamos que você use as ferramentas a seguir para avaliar o efeito de suas políticas antes e depois de fazer alterações. Uma execução simulada oferece uma boa ideia do efeito que uma política de Acesso Condicional tem, mas não substitui uma execução de teste real em um ambiente de desenvolvimento configurado corretamente.

• Modo somente relatório e a pasta de trabalho de Insights e Relatórios de Acesso Condicional.
• A ferramenta What If

Testar suas políticas

Certifique-se de testar os critérios de exclusão de uma política. . Por exemplo, você pode excluir um usuário ou grupo de uma política que exige MFA. Teste se os usuários excluídos são solicitados a usar MFA, pois a combinação de outras políticas pode exigir MFA desses usuários.

Realize cada teste em seu plano de teste com usuários de teste. O plano de teste é importante para que se tenha uma comparação entre os resultados esperados e os resultados reais. A tabela a seguir descreve alguns exemplos de casos de teste. Ajuste os cenários e os resultados esperados com base na configuração de suas políticas de Acesso Condicional.

Implantação em produção

Depois que você confirmar o impacto usando o modo somente relatório, um administrador poderá mover a opção Habilitar política de Somente relatório para Ativado.

Reversão de políticas

Caso você precise reverter as suas políticas recentemente implementadas, use uma ou várias das opções a seguir:

• Desabilitar a política. Desabilitar uma política garante que ela não seja aplicada quando um usuário tenta se conectar. Você sempre pode voltar e habilitar a política quando quiser usá-la.

• Excluir um usuário ou grupo de uma política. Se um usuário não puder acessar o aplicativo, opte por excluir o usuário da política.

  Cuidado

  As exclusões devem ser usadas com moderação e somente nas situações em que o usuário for confiável. Os usuários devem ser adicionados de volta à política ou ao grupo assim que possível.

• Se a política não for mais necessária, exclua.

Solução de problemas das políticas de Acesso Condicional

Se um usuário tiver um problema com uma política de acesso condicional, colete as informações a seguir para facilitar a resolução.

• Nome UPN
• Nome de exibição do usuário
• Nome do sistema operacional
• Carimbo de data/hora (aproximado é ok)
• Aplicativo de destino
• Tipo de aplicativo cliente (navegador vs cliente)
• ID de correlação (essa ID é exclusiva para a entrada)

Se o usuário recebeu uma mensagem com um link Mais detalhes, ele pode coletar a maioria dessas informações para você.

Após coletar as informações, consulte os seguintes recursos:

• Problemas de entrada com o acesso condicional – Entenda os resultados de entrada inesperados relacionados ao acesso condicional usando mensagens de erro e o log de entradas do Microsoft Entra.
• Usando a ferramenta E-Se - Entenda por que uma política foi ou não foi aplicada a um usuário em uma circunstância específica ou se uma política seria aplicada em um estado conhecido.

Conteúdo relacionado

• Saiba mais sobre a autenticação multifator
• Saiba mais sobre o Microsoft Entra ID Protection
• Gerenciar políticas de acesso condicional com a API do Microsoft Graph