Acesso condicional: Conceder

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

Captura de tela de uma Política de acesso condicional com um controle de concessão que exige autenticação multifator.

Acesso bloqueado

O controle para bloquear o acesso considera as atribuições existentes e impede o acesso com base na configuração da política de acesso condicional.

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.

Permitir acesso

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

Ao optar por combinar essas opções, os administradores 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 Azure AD (Azure Active Directory). Mais informações sobre a autenticação multifator do Azure AD podem ser encontradas no artigo Planejamento de uma implantação de Autenticação Multifator do Azure AD baseada em nuvem.

O Windows Hello para empresas cumpre o requisito de autenticação multifator em políticas de Acesso condicional.

Exigir força de autenticação (Visualizaçã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 portal do Azure>Azure Active Directory>Segurança>Métodos de autenticação>Forças de autenticação (visualização). Os administradores podem optar por criar suas próprias ou usar as versões internas.

Observação

Exigir força de autenticação está atualmente em versão prévia pública. Para saber mais sobre versões prévias, consulte os Termos de Uso Complementares para Visualizações do Microsoft Azure.

Exigir que o dispositivo seja marcado como em conformidade

As organizações que implantaram 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 Azure AD 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 em conformidade pelo Intune para qualquer SO do dispositivo ou pelo sistema de MDM de terceiros para dispositivos Windows 10. Você pode encontrar uma lista de sistemas de gerenciamento de dispositivos móveis de terceiros compatíveis em Parceiros de conformidade de dispositivos de terceiros em Intune.

Os dispositivos devem ser registrados no Azure AD 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:

  • Dá suporte somente a dispositivos Windows 10+, iOS, Android e macOS registrados com o Azure AD e registrados com o Intune.
  • Considera o Microsoft Edge no modo InPrivate um dispositivo sem conformidade.

Observação

No Windows 7, iOS, Android, macOS e alguns navegadores da Web de terceiros, o Azure AD identifica o dispositivo que está usando um certificado de cliente que é provisionado quando o dispositivo é registrado no Azure AD. Quando um usuário entra pela primeira vez pelo navegador, ele é solicitado a selecionar o certificado. O usuário deve selecionar esse certificado antes que possa continuar usando o navegador.

Você pode usar o aplicativo Microsoft Defender para Ponto de Extremidade junto com a política de aplicativo Cliente Aprovado no Intune para definir a política de conformidade do dispositivo como 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.

Exigir um dispositivo ingressado no Azure AD 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 Azure AD 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 Azure AD híbrido:

  • Dá suporte somente a dispositivos Windows de nível inferior (pré Windows 10) e Windows atuais (Windows 10+) ingressados no domínio.
  • Não considera o Microsoft Edge no modo InPrivate como um dispositivo ingressado no Azure AD 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 Azure AD, 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 cliente dão suporte a essa configuração, essa lista não é exaustiva e está sujeita a alterações:

  • Proteção de Informações do Microsoft Azure
  • Microsoft Bookings
  • Microsoft Cortana
  • Microsoft Dynamics 365
  • Microsoft Edge
  • Microsoft Excel
  • Microsoft Power Automate
  • Microsoft Invoicing
  • Microsoft Kaizala
  • Microsoft Launcher
  • Microsoft Lists
  • Microsoft Office
  • Microsoft OneDrive
  • Microsoft OneNote
  • Microsoft Outlook
  • Microsoft Planner
  • Microsoft Power Apps
  • Microsoft Power BI
  • Microsoft PowerPoint
  • Microsoft SharePoint
  • Microsoft Skype for Business
  • Microsoft StaffHub
  • Microsoft Stream
  • Microsoft Teams
  • Microsoft To-Do
  • Microsoft Visio
  • Microsoft Word
  • Microsoft Yammer
  • Microsoft Whiteboard
  • 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:
    • Fornece suporte apenas para iOS e Android para 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 Azure AD para conectar o aplicativo móvel Power BI ao Servidor de Relatórios do Power BI local.

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

Requer política de proteção do aplicativo

Em sua política de acesso condicional, você pode exigir que uma política de proteção de aplicativo do Intune esteja presente no aplicativo cliente antes que o acesso fique disponível para os aplicativos de nuvem selecionados.

Para aplicar esse controle de concessão, o acesso condicional exige que o dispositivo seja registrado no Azure AD, 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.

Os aplicativos precisam ter o SDK do Intune com a garantia da política implementada e atender a determinados requisitos para dar suporte a essa configuração. Os desenvolvedores que implementam aplicativos com o SDK do Intune podem obter mais informações sobre os requisitos na documentação do SDK.

Está confirmado que os seguintes aplicativos cliente dão suporte a essa configuração, essa lista não é exaustiva e está sujeita a alterações:

  • iAnnotate para Office 365
  • Microsoft Cortana
  • Microsoft Edge
  • Microsoft Excel
  • Microsoft Launcher
  • Microsoft Lists
  • Microsoft Office
  • Microsoft OneDrive
  • Microsoft OneNote
  • Microsoft Outlook
  • Microsoft Planner
  • Microsoft Power BI
  • Microsoft PowerApps
  • Microsoft PowerPoint
  • Microsoft SharePoint
  • Aplicativo móvel do Microsoft Stream nativo 2.0
  • Microsoft Teams
  • Microsoft To-Do
  • Microsoft Word
  • Microsoft Whiteboard Services
  • Microsoft Field Service (Dynamics 365)
  • MultiLine for Intune
  • Nine Mail – email e calendário
  • Notate para Intune
  • Yammer (Android, iOS e iPadOS)

Esta lista não é abrangente, se o seu aplicativo não estiver nesta lista, verifique com o fornecedor do aplicativo para confirmar o suporte.

Observação

Kaizala, Microsoft Skype for Business e Visio não dão suporte à concessão de Exigir política de proteção de aplicativo. Se precisar que esses aplicativos funcionem, use exclusivamente a concessão de Exigir aplicativos aprovados. O uso da cláusula "or" entre as duas concessões não funcionará para esses três aplicativos.

Aplicativos para a política de proteção de aplicativo dão suporte ao recurso de gerenciamento de aplicativos móveis do Intune com proteção de política.

O controle Exigir política de proteção de aplicativo:

  • Dá suporte apenas para iOS e Android para condição de plataforma de dispositivo.
  • Exige que um aplicativo agente registre o dispositivo. No iOS, o aplicativo agente é o Microsoft Authenticator. No Android, o aplicativo agente é o Portal da Empresa do Intune.

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 risco do usuário é detectado, os administradores podem usar as condições da política de risco do usuário para fazer com que o usuário altere a senha com segurança usando a redefinição de senha self-service do Azure AD. Os usuários podem executar uma redefinição de senha self-service para autocorreção. Esse processo fechará 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 se registraram para autenticação multifator, assim estarão preparados caso o risco seja detectado para a conta deles.

Aviso

Os usuários devem ter se registrado previamente para redefinição de senha self-service antes de disparar a política de risco do usuário.

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

  • A política precisa ser atribuída a "todos os aplicativos de nuvem". Esse requisito impede que um invasor use um aplicativo diferente para alterar a senha do usuário e redefinir o risco da conta dele entrando 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 uma 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 Azure Active Directory.

Controles personalizados (versão prévia)

Os controles personalizados são uma funcionalidade em versão prévia do Azure AD. Quando você usa controles personalizados, seus usuários são redirecionados para um serviço compatível a fim de atender a requisitos separados do Azure AD. Para obter mais informações, confira o artigo Controles personalizados.

Próximas etapas