Planear a implementação do Acesso Condicional
Planejar a implantação do Acesso Condicional é fundamental para alcançar a estratégia de acesso da sua organização para aplicativos e recursos. As políticas de Acesso Condicional oferecem grande flexibilidade de configuração. No entanto, essa flexibilidade também significa que você deve planejar cuidadosamente para evitar resultados indesejáveis.
O Acesso Condicional do Microsoft Entra combina sinais como usuário, dispositivo e localização para automatizar decisões e aplicar políticas de acesso organizacional para recursos. Estas políticas de Acesso Condicional ajudam-no a equilibrar a segurança e a produtividade, impondo controlos de segurança quando necessário e mantendo-se afastado do utilizador quando tal não acontece.
O Acesso Condicional é a base do mecanismo de política de segurança Zero Trust da Microsoft.
A Microsoft fornece padrões de segurança que garantem um nível básico de segurança habilitado em locatários que não têm o Microsoft Entra ID P1 ou P2. 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 combinados, pois a criação de 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 o Microsoft Entra ID P1, P2 ou licença de avaliação habilitada. Se necessário, crie um gratuitamente.
- O Microsoft Entra ID P2 é necessário para incluir o risco de Proteção de ID do Microsoft Entra 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 menor privilégio do Zero Trust, considere o uso do PIM, Gerenciamento Privilegiado de Identidades para ativar atribuições de função privilegiadas just-in-time.
- Ler políticas e configurações de Acesso Condicional
- Criar ou modificar políticas de Acesso Condicional
- Um usuário de teste (não um administrador) que permite verificar se as políticas funcionam conforme o esperado antes de implantar para usuários reais. Se você precisar criar um usuário, consulte Guia de início rápido: adicionar novos usuários ao ID do Microsoft Entra.
- Um grupo do qual o usuário de teste é membro. Se precisar de criar um grupo, consulte Criar um grupo e adicionar membros no Microsoft Entra ID.
Comunicar a mudança
A comunicação é fundamental para o sucesso de qualquer nova funcionalidade. Você deve se comunicar proativamente com seus usuários como a experiência deles muda, quando ela muda e como obter suporte se eles tiverem problemas.
Componentes da Política de Acesso Condicional
As políticas de Acesso Condicional respondem a perguntas sobre quem pode aceder aos seus recursos, a que recursos podem aceder e em que condições. As políticas podem ser concebidas para garantir o acesso, limitar o acesso com controlos de sessão ou bloquear o acesso. Você cria uma política de Acesso Condicional definindo as instruções if-then como:
| Se uma tarefa for cumprida | Aplicar os controles de acesso |
|---|---|
| Se você é um usuário em Finanças acessando o aplicativo Folha de pagamento | Exigir autenticação multifator e um dispositivo compatível |
| Se você não é um membro do Finanças acessando o aplicativo Folha de Pagamento | Bloquear o acesso |
| Se o risco do usuário for alto | Exigir uma autenticação multifator e uma alteração de senha segura |
Exclusões de utilizadores
As políticas de Acesso Condicional são ferramentas poderosas, recomendamos excluir as seguintes contas das suas políticas:
- Acesso de emergência ou contas de quebra-vidro para evitar o bloqueio devido à configuração incorreta da política. No cenário improvável de todos os administradores estarem bloqueados, sua conta administrativa de acesso de emergência pode ser usada para fazer login e tomar medidas para recuperar o 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 vinculadas a nenhum utilizador em particular. Normalmente, são usadas por serviços de back-end que permitem acesso programático a aplicações, mas também são usadas para iniciar sessão em sistemas para fins administrativos. As chamadas feitas por principais de serviço não serão bloqueadas pelas políticas de Acesso Condicional com âmbito definido para os utilizadores. Use o Acesso Condicional para identidades de carga de trabalho para definir políticas direcionadas para principais de serviço.
- Se sua organização tiver essas contas em uso em scripts ou código, considere substituí-las por identidades gerenciadas.
Faça as perguntas certas
Aqui estão algumas perguntas comuns sobre atribuições e controles de acesso. Documente as respostas às perguntas de cada política antes de criá-la.
Usuários ou identidades de carga de trabalho
- Quais usuários, grupos, funções de diretório ou identidades de carga de trabalho estão incluídos ou excluídos da política?
- Quais contas ou grupos de acesso de emergência devem ser excluídos da política?
Aplicações na app ou ações
Essa política se aplicará a qualquer aplicativo, ação do usuário ou contexto de autenticação? Em caso afirmativo:
- A que aplicações ou serviços se aplicará a política?
- Que ações do utilizador estão sujeitas a esta política?
- A que contextos de autenticação esta política será aplicada?
Filtro para aplicações
Usar o filtro para aplicativos para incluir ou excluir aplicativos em vez de especificá-los individualmente ajuda as organizações a:
- Dimensione e direcione facilmente qualquer número de aplicativos.
- Gerencie facilmente aplicativos com requisitos de política semelhantes.
- Reduzir o número de políticas individuais.
- Reduzir erros ao editar políticas: Não há necessidade de adicionar/remover aplicativos manualmente da política. Basta gerenciar os atributos.
- Supere as restrições de tamanho da política.
Condições
- Que plataformas de dispositivos estão incluídas ou excluídas da política?
- Quais são os locais de rede conhecidos da organização?
- Que locais estão incluídos ou excluídos da política?
- Que tipos de aplicativo cliente estão incluídos ou excluídos da política?
- Você precisa segmentar atributos específicos do dispositivo?
- Se estiver usando a Proteção de ID do Microsoft Entra, você deseja incorporar o risco de entrada ou do usuário?
Bloquear ou conceder controlos
Deseja conceder acesso aos recursos exigindo um ou mais dos seguintes itens?
- Autenticação multifator
- Dispositivo marcado como em conformidade
- Usando um dispositivo associado híbrido do Microsoft Entra
- Usando um aplicativo cliente aprovado
- Política de proteção de aplicativos aplicada
- Alteração da palavra-passe
- Termos de Utilização aceites
Bloquear o acesso é um controlo muito forte que só deve aplicar tendo os conhecimentos adequados. As políticas com instruções de bloqueio podem ter efeitos secundários não desejados. Testes e validação adequados são vitais antes de habilitar o controle em escala. Os administradores devem usar ferramentas como o modo somente relatório de Acesso Condicional e a ferramenta E Se no Acesso Condicional ao fazer alterações.
Controlos de sessões
Pretende impor algum dos seguintes controlos de acesso em aplicações na nuvem?
- Usar restrições impostas pelo aplicativo
- Usar o controle Aplicativo de Acesso Condicional
- Impor a frequência de início de sessão
- Usar sessões persistentes do navegador
- Personalizar a avaliação contínua de acesso
Combinação de políticas
Ao criar e atribuir políticas, você deve levar em conta como os tokens de acesso funcionam. Os tokens de acesso concedem ou negam acesso com base no fato de os usuários que fazem uma solicitação terem sido autorizados e autenticados. Se o solicitante puder provar que é quem afirma ser, ele pode acessar os recursos ou funcionalidades protegidos.
Os tokens de acesso são emitidos por padrão se uma condição de política de Acesso Condicional não acionar um controle de acesso.
Essa política não impede que o aplicativo tenha sua própria capacidade de bloquear o acesso.
Por exemplo, considere um exemplo de política simplificada em que:
Utilizadores: FINANCE GROUP
Acesso: APP DE FOLHA DE PAGAMENTO
Controle de acesso: autenticação multifator
- O usuário A está no GRUPO DE FINANÇAS, ele é obrigado a realizar a autenticação multifator para acessar o PAYROLL APP.
- O usuário B não está no GRUPO FINANÇAS, recebe um token de acesso e tem permissão para acessar o APLICATIVO DE FOLHA DE PAGAMENTO sem realizar autenticação multifator.
Para garantir que os usuários fora do grupo financeiro não possam acessar o aplicativo de folha de pagamento, uma política separada pode ser criada para bloquear todos os outros usuários, como a seguinte política simplificada:
Utilizadores: Incluir todos os utilizadores / Excluir FINANCE GROUP
Acesso: APP DE FOLHA DE PAGAMENTO
Controle de acesso: Bloquear acesso
Agora, quando o Usuário B tenta acessar o APLICATIVO DE FOLHA DE PAGAMENTO, ele é bloqueado.
Recomendações
Tendo em conta as nossas aprendizagens na utilização do Acesso Condicional e apoiando outros clientes, aqui estão algumas recomendações baseadas nas nossas aprendizagens.
Aplicar políticas de Acesso Condicional a todas as aplicações
Certifique-se de que cada aplicativo tenha pelo menos uma política de Acesso Condicional aplicada. Do ponto de vista da segurança, é melhor criar uma política que englobe Todos os recursos (anteriormente "Todos os aplicativos na nuvem") e, em seguida, excluir os aplicativos aos quais você não deseja que a política se aplique. Essa prática garante que você não precise atualizar as políticas de Acesso Condicional toda vez que integrar um novo aplicativo.
Gorjeta
Tenha muito cuidado ao usar o bloco e todos os aplicativos em uma única política. Isso pode bloquear os administradores e as exclusões não podem ser configuradas para pontos de extremidade importantes, como o Microsoft Graph.
Minimizar o número de políticas de Acesso Condicional
Criar uma política para cada aplicativo não é eficiente e leva a uma administração difícil. O Acesso Condicional tem um limite de 195 políticas por inquilino. Este 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 os agrupe 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 única 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 cresça além. Se você usar uma longa lista de GUIDs em sua política, poderá atingir esse limite. Se você encontrar esses limites, recomendamos alternativas como:
- Use grupos ou funções para incluir ou excluir Usuários em vez de listar cada usuário individualmente.
- Use filtro para aplicativos para incluir ou excluir aplicativos em vez de especificá-los individualmente.
Configurar o modo só de relatório
Por padrão, cada política criada a partir do 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.
Habilite as políticas no modo somente relatório. Depois de salvar uma política no modo somente relatório, você pode 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 os efeitos agregados de suas políticas de Acesso Condicional na pasta de trabalho Insights e Relatórios. Para acessar a pasta de trabalho, você precisa de uma assinatura do Azure Monitor e precisa transmitir seus logs de entrada para um espaço de trabalho de análise de log.
Planejar a interrupção
Para reduzir o risco de bloqueio durante interrupções imprevistas, planeje estratégias de resiliência para sua organização.
Ativar ações protegidas
A habilitação de ações protegidas coloca outra camada de segurança nas tentativas de criar, modificar ou excluir a política de Acesso Condicional. As organizações podem exigir uma nova autenticação multifator ou outro controle de concessão antes de modificar a política.
Definir padrões de nomenclatura para suas políticas
Um padrão de nomenclatura ajuda você a encontrar políticas e entender sua finalidade sem abri-las no portal de administração do Azure. Recomendamos que você nomeie sua política para mostrar:
- Um número sequencial
- As aplicações na nuvem às quais se aplica
- A resposta
- A quem se aplica
- Quando é aplicável
Exemplo: Uma política para exigir MFA para 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 implementação do Acesso Condicional. O Número de Sequência é útil se você precisar fazer referência a uma política em uma conversa. Por exemplo, quando fala com um administrador ao telefone, pode pedir-lhe para abrir a política CA01 para resolver um problema.
Normas de nomenclatura para controlos de acesso de emergência
Além de suas políticas ativas, implemente políticas desabilitadas que atuam como controles de acesso resilientes secundários em cenários de interrupção ou emergência. Seu padrão de nomenclatura para as políticas de contingência deve incluir:
- HABILITAR EM EMERGÊNCIA no início para fazer o nome se destacar entre as outras políticas.
- O nome da perturbação a que se deve aplicar.
- Um número de sequência de pedidos para ajudar o administrador a saber em que ordem as políticas devem ser habilitadas.
Exemplo: O nome a seguir indica que essa política é a primeira de quatro políticas a serem habilitadas se houver uma interrupção de MFA:
- EM01 - ATIVAR EM CASO DE EMERGÊNCIA: Interrupção do MFA [1/4] - Exchange SharePoint: Exigir associação híbrida do Microsoft Entra Para usuários VIP.
Bloquear países/regiões dos quais nunca espera iniciar sessão
O Microsoft Entra ID permite que você crie locais nomeados. Crie a lista de países/regiões permitidos e, em seguida, crie uma política de bloqueio de rede com estes "países/regiões permitidos" como uma exclusão. Essa opção cria menos despesas gerais para os clientes baseados em locais geográficos menores. Certifique-se de isentar suas contas de acesso de emergência desta política.
Implantar políticas de Acesso Condicional
Quando estiver pronto, implante suas políticas de Acesso Condicional em fases.
Crie suas políticas de Acesso Condicional
Consulte Modelos de política de Acesso Condicional e Políticas de segurança comuns para organizações do Microsoft 365 para obter uma vantagem inicial. Esses modelos são uma maneira conveniente de implantar recomendações da Microsoft. Certifique-se de excluir suas contas de acesso de emergência.
Avaliar o impacto da política
Recomendamos que você use as seguintes ferramentas para avaliar o efeito de suas políticas antes e depois de fazer alterações. Uma execução simulada dá uma boa ideia do efeito que uma política de Acesso Condicional tem, ela não substitui uma execução de teste real em um ambiente de desenvolvimento configurado corretamente.
- Modo somente relatório e as informações de Acesso Condicional e a pasta de trabalho Relatórios.
- A ferramenta E Se
Teste as 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 exija MFA. Teste se os usuários excluídos são solicitados para MFA, porque a combinação de outras políticas pode exigir MFA para esses usuários.
Realize cada teste no seu plano de teste com os utilizadores de teste. O plano de teste é importante para ter 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 das políticas de Acesso Condicional.
| Política | Cenário | Resultado esperado |
|---|---|---|
| Inícios de sessão de risco | O utilizador inicia sessão na Aplicação utilizando um browser não aprovado | Calcula uma pontuação de risco com base na probabilidade de o início de sessão não ter sido efetuado pelo utilizador. Requer que o usuário se auto-corrija usando MFA |
| Gestão de Dispositivos | O utilizador autorizado tenta iniciar sessão a partir de um dispositivo autorizado | Acesso concedido |
| Gestão de Dispositivos | O utilizador autorizado tenta iniciar sessão a partir de um dispositivo não autorizado | Acesso bloqueado |
| Alteração de senha para usuários arriscados | O utilizador autorizado tenta iniciar sessão com credenciais comprometidas (início de sessão de alto risco) | O usuário é solicitado a alterar a senha ou o acesso é bloqueado com base na sua política |
Implantar em produção
Depois de confirmar o impacto usando o modo somente relatório, um administrador pode mover a alternância Habilitar política de Somente relatório para Ativado.
Políticas de reversão
Caso precise de reverter as políticas recém-implementadas, utilize uma ou mais das seguintes opções:
Desative a política. A desativação de uma política garante que ela não se aplica quando um usuário tenta entrar. Você sempre pode voltar e ativar a política quando quiser usá-la.
Excluir um usuário ou grupo de uma política. Se um usuário não conseguir acessar o aplicativo, você poderá optar por excluí-lo da política.
Atenção
As exclusões devem ser usadas com moderação, apenas em situações em que o usuário é confiável. Os usuários devem ser adicionados novamente à política ou ao grupo o mais rápido possível.
Se uma política estiver desativada e não for mais necessária, exclua-a.
Solucionar problemas de políticas de Acesso Condicional
Se um usuário tiver um problema com uma política de Acesso Condicional, colete as seguintes informações para facilitar a solução de problemas.
- Nome Principal do Utilizador
- Nome de exibição do usuário
- Nome do sistema operacional
- Carimbo de data/hora (aproximado é ok)
- Aplicação de destino
- Tipo de aplicativo cliente (navegador vs cliente)
- ID de correlação (este ID é exclusivo para o início de sessão)
Se o utilizador receber uma mensagem com uma ligação Mais detalhes, poderá recolher a maior parte destas informações para lhe transmitir.
Depois de coletar as informações, consulte os seguintes recursos:
- Problemas de início de sessão com o Acesso Condicional – Compreenda os resultados de início de sessão inesperados relacionados com o Acesso Condicional utilizando mensagens de erro e o registo de início de sessão do Microsoft Entra.
- Usando a ferramenta Hipóteses - Entenda por que uma política foi ou não aplicada a um usuário em uma circunstância específica ou se uma política seria aplicada em um estado conhecido.