Acesso condicional: Conceder

Em uma política de Acesso Condicional, um administrador pode usar controles de acesso para conceder ou bloquear o acesso aos recursos.

Bloquear acesso

O controle de bloqueio de acesso avalia as atribuições e impede o acesso com base na configuração da política de acesso condicional.

O acesso a blocos é um controle poderoso que requer um aplicativo cuidadoso. Políticas com instruções de bloco podem causar efeitos colaterais não intencionais. Testes e validação adequados são essenciais antes de habilitar o controle em escala. Os administradores devem usar ferramentas como o modo somente relatório de Acesso Condicional e a ferramenta What If no Acesso Condicional ao fazer alterações.

Conceder acesso

Os administradores podem optar por impor um ou mais controles ao conceder acesso. Tais controles incluem as seguintes opções:

• Exigir autenticação multifator (Autenticação multifator do Microsoft Entra)
• Exigir força de autenticação
• Exigir que o dispositivo seja marcado como compatível (Microsoft Intune)
• Exigir um dispositivo ingressado no Microsoft Entra híbrido
• Exigir um aplicativo cliente aprovado
• Exigir uma política de proteção de aplicativo
• Exigir alteração de senha

Quando os administradores optam por combinar essas opções, eles podem usar os seguintes métodos:

• Exigir todos os controles selecionados (controle e controle)
• Exigir um dos controles selecionados (controle ou controle)

Por padrão, o Acesso condicional exige todos os controles selecionados.

Exigir autenticação multifator

Escolher essa caixa de seleção exige que os usuários executem a autenticação multifator do Microsoft Entra. Mais informações sobre a autenticação multifator do Microsoft Entra podem ser encontradas no artigo Planejamento de uma implantação de autenticação multifator do Microsoft Entra baseada em nuvem.

Windows Hello para Empresas cumpre o requisito de autenticação multifator em políticas de acesso condicional.

Exigir força de autenticação

Os administradores podem optar por exigir pontos fortes de autenticação específicos em suas políticas de Acesso Condicional. Esses pontos fortes de autenticação são definidos no Centro de administração do Microsoft Entra>Entra ID>Métodos de autenticação>Pontos fortes de autenticação. Os administradores podem optar por criar suas próprias versões ou usar as versões internas.

Exigir que o dispositivo seja marcado como em conformidade

As organizações que implantam o Intune podem usar as informações retornadas de seus dispositivos para identificar aqueles que atendem a requisitos de conformidade de política específicos. O Intune envia as informações de conformidade da política ao Microsoft Entra ID para que o acesso condicional possa decidir permitir ou bloquear o acesso aos recursos. Para mais informações sobre políticas de conformidade, confira Definir regras em dispositivos para permitir o acesso aos recursos em sua organização usando o Intune.

Um dispositivo pode ser marcado como compatível com o Intune para qualquer sistema operacional de dispositivo ou por um sistema de gerenciamento de dispositivo móvel não Microsoft para dispositivos Windows. Você pode encontrar uma lista de sistemas de gerenciamento de dispositivos móveis que não são da Microsoft compatíveis em Parceiros de conformidade de dispositivos não Microsoft em Intune.

Os dispositivos devem ser registrados no Microsoft Entra ID antes que possam ser marcados como compatível. Você pode encontrar mais informações sobre o registro de dispositivo em O que é uma identidade do dispositivo?.

O controle Exigir que o dispositivo seja marcado como em conformidade:

• Só dá suporte a dispositivos Windows 10+, iOS, Android, macOS e Linux Ubuntu registrados com a ID do Microsoft Entra e registrados no Intune.
• O Microsoft Edge no modo InPrivate no Windows é considerado como um dispositivo não compatível.

Você pode usar o aplicativo Microsoft Defender para Ponto de Extremidade com a política do aplicativo cliente aprovada no Intune para definir a política de conformidade do dispositivo como as políticas de Acesso Condicional. Não há nenhuma exclusão necessária para o aplicativo Microsoft Defender para Ponto de Extremidade ao configurar o Acesso Condicional. Embora o Microsoft Defender para Ponto de Extremidade no Android e iOS (ID do aplicativo dd47d17a-3194-4d86-bfd5-c6ae6f5651e3) não seja um aplicativo aprovado, ele tem permissão para relatar a postura de segurança do dispositivo. Essa permissão permite o fluxo de informações de conformidade para o Acesso Condicional.

Da mesma forma, a exigência de que o dispositivo seja marcado como compatível não bloqueia o UserAuthenticationMethod.Read acesso do aplicativo Microsoft Authenticator ao escopo. O Authenticator precisa de acesso ao escopo UserAuthenticationMethod.Read durante o registro para determinar quais credenciais um usuário pode configurar. O autenticador precisa de acesso a UserAuthenticationMethod.ReadWrite para registrar credenciais, o que não ignora a verificação Exigir que dispositivo seja marcado como compatível.

Exigir um dispositivo ingressado no Microsoft Entra híbrido

As organizações podem optar por usar a identidade do dispositivo como parte de sua política de Acesso condicional. As organizações podem exigir que os dispositivos sejam ingressados no Microsoft Entra híbrido usando essa caixa de seleção. Para obter mais informações sobre identidades de dispositivo, confira O que é uma identidade de dispositivo?.

Quando você usa o fluxo OAuth de código do dispositivo, não há suporte para o controle de concessão necessário para o dispositivo gerenciado ou para uma condição de estado do dispositivo. Isso ocorre porque o dispositivo que está executando a autenticação não pode fornecer o estado do dispositivo para o dispositivo que está fornecendo um código. Além disso, o estado do dispositivo no token está bloqueado para o dispositivo que está executando a autenticação. Em vez disso, use o controle Exigir autenticação multifator.

O controle Exigir um dispositivo ingressado no Microsoft Entra híbrido:

• Dá suporte somente a dispositivos Windows de nível inferior (anterior ao Windows 10) e Windows atual (Windows 10+) ingressados ​​no domínio.
• Não considera o Microsoft Edge no modo InPrivate como um dispositivo ingressado no Microsoft Entra híbrido.

Exigir um aplicativo cliente aprovado

As organizações podem exigir que um aplicativo cliente aprovado seja usado para acessar aplicativos de nuvem selecionados. Esses aplicativos cliente aprovados dão suporte a políticas de proteção de aplicativo do Intune independentemente de qualquer solução de gerenciamento de dispositivo móvel.

Para aplicar esse controle de concessão, o dispositivo precisa ser registrado no Microsoft Entra ID, o que requer o uso de um aplicativo agente. O aplicativo agente pode ser o Microsoft Authenticator para iOS ou o Microsoft Authenticator ou o Portal da Empresa da Microsoft para dispositivos Android. Se um aplicativo agente não estiver instalado no dispositivo quando o usuário tentar se autenticar, o usuário será redirecionado para a loja de aplicativos apropriada para instalar o aplicativo agente necessário.

Os seguintes aplicativos clientes têm suporte para essa configuração. Esta lista não é exaustiva e está sujeita a alterações:

• Proteção de Informações do Microsoft Azure
• Microsoft Cortana
• Microsoft Dynamics 365
• Microsoft Edge
• Microsoft Excel
• Microsoft Power Automate (automatização de processos)
• Faturamento da Microsoft
• Microsoft Kaizala
• Microsoft Launcher
• Listas da Microsoft
• Microsoft Office
• Microsoft OneDrive
• Microsoft OneNote
• Microsoft Outlook
• Planejador da Microsoft
• Aplicativos do Microsoft Power
• Microsoft Power BI
• Microsoft PowerPoint
• Microsoft SharePoint
• Microsoft Skype for Business
• Microsoft Stream
• Equipes da Microsoft
• Microsoft To Do
• Microsoft Visio
• Microsoft Word
• Microsoft Yammer
• Quadro branco da Microsoft
• Administrador do Microsoft 365

Comentários

• Os aplicativos cliente aprovados fornecem suporte ao recurso de gerenciamento de aplicativo móvel Intune.
• O requisito Exigir o aplicativo do cliente aprovado:
  • Dá suporte apenas para iOS e Android para a condição de plataforma de dispositivo.
  • Exige que um aplicativo agente registre o dispositivo. O aplicativo agente pode ser o Microsoft Authenticator para iOS ou o Microsoft Authenticator ou o Portal da Empresa da Microsoft para dispositivos Android.
• O acesso condicional não pode considerar o Microsoft Edge no modo InPrivate em um aplicativo cliente aprovado.
• As políticas de acesso condicional que exigem o aplicativo Microsoft Power BI como um aplicativo cliente aprovado não dão suporte ao uso do proxy de aplicativo do Microsoft Entra para conectar o aplicativo móvel Power BI ao Servidor de Relatórios do Power BI local.
• Modos de exibição da Web hospedados fora do Microsoft Edge não satisfazem a política de aplicativo cliente aprovada. Por exemplo, se um aplicativo estiver tentando carregar o SharePoint em um modo de exibição da Web, as políticas de proteção de aplicativo falharão.

Confira Exigir aplicativos cliente aprovados para acesso de aplicativo de nuvem com acesso condicional para exemplos de configuração.

Exigir uma política de proteção de aplicativo

Na política de acesso condicional, você pode exigir que uma política de proteção de aplicativos do Intune esteja presente no aplicativo cliente antes que o acesso esteja disponível para os aplicativos selecionados. Essas políticas de proteção de aplicativos de gerenciamento de aplicativo móvel (MAM) permitem que você gerencie e proteja os dados da organização em aplicativos específicos.

Para aplicar esse controle de concessão, o acesso condicional exige que o dispositivo seja registrado no Microsoft Entra ID, o que exige o uso de um aplicativo agente. O aplicativo agente pode ser o Microsoft Authenticator para iOS ou o portal da Empresa da Microsoft para dispositivos Android. Se um aplicativo agente não estiver instalado no dispositivo quando o usuário tentar se autenticar, o usuário será redirecionado para a loja de aplicativos apropriada para instalar o aplicativo agente. O aplicativo Microsoft Authenticator pode ser usado como o aplicativo agente, mas não oferece suporte para ser direcionado como um aplicativo cliente aprovado. As políticas de proteção de aplicativo estão geralmente disponíveis para iOS e Android, e em versão prévia pública para o Microsoft Edge no Windows. Os dispositivos Windows não suportam mais do que três contas de usuário do Microsoft Entra na mesma sessão. Para obter mais informações sobre como aplicar a política a dispositivos Windows, confira o artigo Exigir uma política de proteção de aplicativos em dispositivos Windows (versão prévia).

Os aplicativos devem atender a determinados requisitos para oferecer suporte a políticas de proteção de aplicativo. Os desenvolvedores podem encontrar mais informações sobre esses requisitos na seção Aplicativos que você pode gerenciar com políticas de proteção de aplicativo.

Os seguintes aplicativos clientes têm suporte para essa configuração. Esta lista não é exaustiva e está sujeita a alterações. Se o seu aplicativo não estiver na lista, entre em contato com o fornecedor do aplicativo para confirmar o suporte:

• Aplicativo móvel Adobe Acrobat Reader
• iAnnotate para Office 365
• Microsoft Cortana
• Microsoft Dynamics 365 para Telefones
• Vendas do Microsoft Dynamics 365
• Microsoft Edge
• Microsoft Excel
• Microsoft Power Automate (automatização de processos)
• Microsoft Launcher
• Listas da Microsoft
• Microsoft Loop
• Microsoft Office
• Microsoft OneDrive
• Microsoft OneNote
• Microsoft Outlook
• Planejador da Microsoft
• Microsoft Power BI
• Microsoft PowerApps
• Microsoft PowerPoint
• Microsoft SharePoint
• Aplicativo móvel do Microsoft Stream nativo 2.0
• Equipes da Microsoft
• Microsoft To Do
• Microsoft Word
• Serviços do Microsoft Whiteboard
• MultiLine para Intune
• Nine Mail – email e calendário
• Notate para Intune
• Provectus – Contatos Seguros
• Viva Engage (Android, iOS e iPadOS)
• Aplicativo do Windows (Android, iOS/iPadOS e Microsoft Edge no Windows)

Confira Como exigir política de proteção a e um aplicativo cliente aprovado para acesso de aplicativo de nuvem com Acesso condicional para exemplos de configuração.

Exigir alteração de senha

Quando o risco do usuário é detectado, os administradores podem empregar as condições de política de risco do usuário para que o usuário altere com segurança uma senha usando a redefinição de senha de autoatendimento do Microsoft Entra. Os usuários podem executar uma redefinição de senha self-service para autocorreção. Esse processo fecha o evento de risco do usuário para evitar alertas desnecessários para os administradores.

Quando um usuário receber uma solicitação para alterar uma senha, ele primeiro precisará realizar a autenticação multifator. Verifique se todos os usuários estão registrados para autenticação multifator, assim estarão preparados caso o risco seja detectado para a conta deles.

As seguintes restrições se aplicam quando você configura uma política usando o controle de alterações de senha:

• A política deve ser atribuída a Todos os recursos. Esse requisito impede que um invasor use um aplicativo diferente para alterar a senha do usuário e redefinir o risco da conta ao entrar em um aplicativo diferente.
• Exigir alteração de senha não pode ser usado com outros controles, por exemplo, o de exigir um dispositivo em conformidade.
• O controle de alterações de senha só pode ser usado com a condição de atribuição de usuário e grupo, condição de atribuição de aplicativo de nuvem (que precisa ser definida para "todos") e condições de risco do usuário.

Termos de uso

Se sua organização tiver criado termos de uso, outras opções poderão estar visíveis nos controles de concessão. Essas opções permitem que os administradores exijam a confirmação dos termos de uso como condição para acessar os recursos protegidos pela política. Mais informações sobre os termos de uso podem ser encontradas em Termos de uso do Microsoft Entra.

Vários controles de concessão

Quando vários controles de concessão se aplicam a um usuário, entenda que as políticas de Acesso Condicional seguem uma ordem de validação específica por design. Por exemplo, se um usuário tiver duas políticas que exigem MFA (autenticação multifator) e Termos de Uso (ToU), o Acesso Condicional validará primeiro a declaração de MFA do usuário e, em seguida, a ToU.

• Se uma declaração MFA válida não estiver no token, você verá uma "interrupção" (MFA pendente) e uma falha para a ToU nos logs, mesmo que a ToU tenha sido aceita em uma entrada anterior.
• Depois de concluir a autenticação multifator, uma segunda entrada de log será exibida, validando o ToU. Se o usuário já aceitou o ToU, você verá poderá usar a MFA e o ToU.
• Se uma declaração MFA válida estiver presente no token, um único log exibirá a conclusão bem-sucedida para MFA e ToU.

Se várias políticas forem aplicadas a um usuário que exige MFA, Estado do Dispositivo e ToU, o processo será semelhante. A ordem de validação é MFA, Estado do Dispositivo e, em seguida, ToU.

Controles personalizados (versão prévia)

Os controles personalizados são uma funcionalidade de visualização do Microsoft Entra ID. O uso de controles personalizados redireciona seus usuários para um serviço compatível para atender aos requisitos de autenticação separados da ID do Microsoft Entra. Para obter mais informações, confira o artigo Controles personalizados.

Próximas etapas

• Acesso condicional: controles de sessão

• Políticas de acesso condicional comuns

• Modo somente Relatório