Compartilhar via

Acesso condicional: recursos de destino

Os recursos de destino (anteriormente, aplicativos de nuvem, ações e contexto de autenticação) são sinais chave em uma política de Acesso Condicional. As políticas de Acesso Condicional permitem que os administradores atribuam controles a aplicativos, serviços, ações ou contexto de autenticação específicos.

  • Os administradores podem escolher na lista de aplicativos ou serviços que incluem aplicativos integrados da Microsoft e quaisquer aplicativos integrados ao Microsoft Entra, incluindo da galeria, que não são da galeria e aplicativos publicados por meio do Application Proxy.
  • Os administradores podem optar por definir a política não com base em um aplicativo de nuvem, mas em uma ação do usuário , como Registrar informações de segurança ou registrar ou ingressar dispositivos, permitindo que o Acesso Condicional imponha controles em torno dessas ações.
  • Os administradores podem direcionar perfis de encaminhamento de tráfego do Acesso Global Seguro para funcionalidade aprimorada.
  • Os administradores podem usar o contexto de autenticação para fornecer uma camada extra de segurança em aplicativos.

Captura de tela exibindo uma política de Acesso Condicional e o painel de recursos de destino.

Aplicativos em nuvem da Microsoft

Os administradores podem atribuir uma política de Acesso Condicional a aplicativos de nuvem da Microsoft, desde que a entidade de serviço apareça em seu locatário, com exceção do Microsoft Graph. O Microsoft Graph funciona como um recurso guarda-chuva. Use o Relatório de Audiência para ver os serviços subjacentes e direcionar esses serviços em suas políticas. Alguns aplicativos como o Office 365 e a API de Gerenciamento de Serviços do Windows Azure incluem vários aplicativos ou serviços filho relacionados. Quando novos aplicativos de nuvem da Microsoft são criados, eles aparecem na lista de seletores de aplicativos assim que a entidade de serviço é criada no locatário.

Office 365

O Microsoft 365 fornece serviços de produtividade e colaboração baseados em nuvem, como o Exchange, SharePoint e Microsoft Teams. Os serviços de nuvem do Microsoft 365 são profundamente integrados para que haja experiências contínuas e colaborativas. Essa integração pode causar confusão ao criar políticas, pois alguns aplicativos como o Microsoft Teams têm dependências de outros como SharePoint ou Exchange.

O pacote do Office 365 torna possível direcionar todos esses serviços de uma só vez. É recomendável usar o novo pacote do Office 365, em vez de direcionar aplicativos de nuvem individuais para evitar problemas com dependências de serviço.

Direcionar esse grupo de aplicativos ajuda a evitar problemas que podem surgir devido a políticas e dependências inconsistentes. Por exemplo: o aplicativo Exchange Online está vinculado a dados tradicionais do Exchange Online, como e-mail, calendário e informações de contato. Metadados relacionados podem ser expostos por meio de recursos diferentes, como pesquisa. Para garantir que todos os metadados sejam protegidos conforme o esperado, os administradores devem atribuir políticas ao aplicativo Office 365.

Os administradores podem excluir todo o conjunto do Office 365 ou aplicativos de nuvem específicos do Office 365 da política de Acesso Condicional.

Uma lista completa de todos os serviços incluídos pode ser encontrada no artigo Aplicativos incluídos no pacote de aplicativos do Office 365 de Acesso Condicional.

API de Gerenciamento de Serviços do Microsoft Azure

Quando você direciona o aplicativo de API de Gerenciamento de Serviços do Microsoft Azure, a política é imposta para tokens emitidos para um conjunto de serviços intimamente associados ao portal. Esse agrupamento inclui as IDs do aplicativo de:

  • Azure Resource Manager
  • Portal do Azure, que também abrange o Centro de Administração do Microsoft Entra
  • Azure Data Lake
  • API do Application Insights
  • API do Log Analytics

Como a política é aplicada ao portal de gerenciamento do Azure e à API, todos os serviços ou clientes que dependem da API do Azure podem ser afetados indiretamente. Por exemplo:

  • CLI do Azure
  • Portal do Azure Data Factory
  • Azure DevOps
  • Hubs de eventos do Azure
  • PowerShell do Azure
  • Barramento de Serviço do Azure
  • Banco de Dados SQL do Azure
  • Azure Synapse
  • APIs de modelo de implantação clássico
  • Centro de administração Microsoft 365
  • Central IoT da Microsoft
  • Instância Gerenciada de SQL
  • Portal do administrador de assinaturas do Visual Studio

Observação

O aplicativo de API de Gerenciamento de Serviços do Windows Azure se aplica ao Azure PowerShell, que chama a API do Azure Resource Manager. Ele não se aplica ao Microsoft Graph PowerShell, que chama a API do Microsoft Graph.

Para obter mais informações sobre como configurar uma política de exemplo para a API de Gerenciamento de Serviços do Windows Azure, consulte Acesso Condicional: Exigir MFA para o gerenciamento do Azure.

Dica

Para o Azure Government, você deve ter como destino o aplicativo API de Gerenciamento de Nuvem do Azure Government.

Portais de Administração da Microsoft

Quando uma política de Acesso condicional tem como alvo o aplicativo de nuvem do Portais de Administração da Microsoft, a política é imposta para tokens emitidos para IDs de aplicativos dos seguintes portais administrativos da Microsoft:

  • Portal do Azure
  • Centro de Administração do Exchange
  • Centro de administração Microsoft 365
  • Portal do Microsoft 365 Defender
  • Centro de administração do Microsoft Entra
  • Centro de administração do Microsoft Intune
  • Portal de conformidade do Microsoft Purview
  • Centro de administração do Microsoft Teams

Estamos continuamente adicionando mais portais administrativos à lista.

Outros aplicativos

Os administradores podem adicionar qualquer aplicativo registrado do Microsoft Entra às políticas de acesso condicional. Esses aplicativos podem incluir:

Observação

Como a política de Acesso Condicional define os requisitos para acessar um serviço, você não pode aplicá-lo a um aplicativo cliente (público/nativo). Em outras palavras, a política não é definida diretamente em um aplicativo cliente (público/nativo), mas é aplicada quando um cliente chama um serviço. Por exemplo, uma política definida no serviço SharePoint se aplica a todos os clientes que chamam o SharePoint. Uma política definida no Exchange se aplica à tentativa de acessar o email usando o cliente do Outlook. É por isso que os aplicativos cliente (público/nativo) não estão disponíveis para seleção no seletor de aplicativo e a opção acesso condicional não está disponível nas configurações de aplicativo para o aplicativo cliente (público/nativo) registrado em seu locatário.

Alguns aplicativos não aparecem no seletor. A única maneira de incluir esses aplicativos em uma política de Acesso Condicional é incluir Todos os recursos (anteriormente 'Todos os aplicativos de nuvem') ou adicionar a entidade de serviço ausente usando o cmdlet New-MgServicePrincipal PowerShell ou usando a API do Microsoft Graph.

Noções básicas sobre o acesso condicional para diferentes tipos de cliente

O Acesso Condicional aplica-se a recursos e não a clientes, exceto quando o cliente é um cliente confidencial solicitando um token de ID.

  • Cliente público
    • Os clientes públicos são aqueles que são executados localmente em dispositivos como o Microsoft Outlook na área de trabalho ou aplicativos móveis, como o Microsoft Teams.
    • As políticas de Acesso Condicional não se aplicam ao próprio cliente público, mas se aplicam com base nos recursos solicitados pelos clientes públicos.
  • Cliente confidencial
    • O Acesso Condicional se aplica aos recursos solicitados pelo cliente e ao próprio cliente confidencial se ele solicitar um token de ID.
    • Por exemplo: se o Outlook Web solicitar um token para escopos Mail.Read e Files.Read, o Acesso Condicional aplicará políticas para Exchange e SharePoint. Além disso, se o Outlook Web solicitar um token de ID, o Acesso Condicional também aplicará as políticas para o Outlook Web.

Para exibir os logs de entrada para esses tipos de cliente no Centro de administração do Microsoft Entra:

  1. Entre no Centro de administração do Microsoft Entra como pelo menos um Leitor de Relatórios.
  2. Acesse Entra ID>Monitoramento e integridade>Logs de entrada.
  3. Adicionar um filtro para o tipo de credencial do cliente .
  4. Ajuste o filtro para exibir um conjunto específico de logs com base na credencial do cliente usada na entrada.

Para obter mais informações, consulte o artigo Cliente público e aplicativos cliente confidenciais.

Todos os recursos

A aplicação de uma política de Acesso Condicional a Todos os recursos (anteriormente 'Todos os aplicativos de nuvem') sem exclusões de aplicativo resulta na imposição da política para todas as solicitações de token de sites e serviços, incluindo perfis de encaminhamento de tráfego do Acesso Seguro Global. Essa opção inclui aplicativos que não são direcionados individualmente na política de Acesso Condicional, como Windows Azure Active Directory (00000002-0000-0000-c000-00000000000000).

Importante

A Microsoft recomenda a criação de uma política de autenticação multifator de linha de base direcionada a todos os usuários e a todos os recursos (sem exclusões de aplicativo), como a explicada em Exigir autenticação multifator para todos os usuários.

Comportamento de acesso condicional quando uma política de todos os recursos tem uma exclusão de aplicativo

Se qualquer aplicativo for excluído da política, para não bloquear inadvertidamente o acesso do usuário, determinados escopos de privilégios baixos serão excluídos da imposição da política. Esses escopos permitem chamadas para as APIs subjacentes do Graph, como Windows Azure Active Directory (00000002-0000-0000-c0000-0000000000000) e Microsoft Graph (00000003-0000-0000-c0000-000000000000), para acessar informações de associação de grupo e perfil de usuário comumente usadas por aplicativos como parte da autenticação. Por exemplo: quando o Outlook solicita um token para o Exchange, ele também solicita que o escopo User.Read seja capaz de exibir as informações básicas da conta do usuário atual.

A maioria dos aplicativos tem uma dependência semelhante, e é por isso que esses escopos de privilégios baixos são excluídos automaticamente sempre que há uma exclusão de aplicativo em uma política Todos os recursos . Essas exclusões de escopo de privilégios baixos não permitem acesso a dados além das informações básicas do perfil do usuário e do grupo. Os escopos excluídos são listados da seguinte maneira, o consentimento ainda é necessário para que os aplicativos usem essas permissões.

  • Os SPAs (clientes nativos e aplicativos de página única) têm acesso aos seguintes escopos de privilégios baixos:
    • Azure AD Graph: email, , offline_access, openid, , profileUser.Read
    • Microsoft Graph: email, , offline_access, openid, profile, , User.ReadPeople.Read
  • Os clientes confidenciais terão acesso aos seguintes escopos de privilégios baixos, se forem excluídos de uma política Todos os recursos :
    • Azure AD Graph: email, , offline_access, openid, profile, User.Read, , , User.Read.AllUser.ReadBasic.All
    • Microsoft Graph: email, offline_access, openid, profile, User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden

Para obter mais informações sobre os escopos mencionados, consulte a referência de permissões do Microsoft Graph e escopos e permissões na plataforma de identidade da Microsoft.

Proteger informações de diretório

Se a política de MFA de linha de base recomendada sem exclusões de aplicativo não puder ser configurada por razões de negócios e a política de segurança da sua organização precisar incluir escopos de baixo privilégio relacionados ao diretório (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden), uma alternativa é criar uma política de acesso condicional separada que tenha como alvo Windows Azure Active Directory (00000002-0000-0000-c000-000000000000). O Windows Azure Active Directory (também chamado de Azure AD Graph) é um recurso que representa os dados armazenados no diretório, como usuários, grupos e aplicativos. O recurso do Windows Azure Active Directory está incluído em Todos os recursos , mas pode ser direcionado individualmente em políticas de Acesso Condicional usando as seguintes etapas:

  1. Entre no Centro de administração do Microsoft Entra como administrador de definição de atributo e administrador de atribuição de atributo.
  2. Navegue até Entra ID>Atributos de segurança personalizados.
  3. Crie um novo conjunto de atributos e uma definição de atributo. Para obter mais informações, consulte Adicionar ou desativar definições de atributo de segurança personalizadas na ID do Microsoft Entra.
  4. Navegue até Entra ID>Aplicativos empresariais.
  5. Remova o filtro de tipo de aplicativo e pesquise pela ID de aplicativo que começa com 00000002-0000-0000-c000-000000000000.
  6. Selecioneatributos de segurança personalizados> do Windows Azure Active Directory>Adicionar atribuição.
  7. Selecione o conjunto de atributos e o valor do atributo que você planeja usar na política.
  8. Navegue até Entra ID>Acesso Condicional>Políticas.
  9. Criar ou modificar uma política existente.
  10. Em Recursos de destino>(anteriormente aplicativos de nuvem)>Incluir, selecione >Selecionar recursos> e Editar filtro.
  11. Ajuste o filtro para incluir seu conjunto de atributos e definição mencionada anteriormente.
  12. Salvar a política

Todos os recursos da Internet com Acesso Seguro Global

A opção Todos os recursos da Internet com Acesso Seguro Global permite que os administradores direcionem o perfil de encaminhamento de tráfego de acesso à Internet do Microsoft Entra Internet Access.

Os perfis no Acesso Global Seguro permitem que os administradores definam e controlem como o tráfego é roteado por meio do Acesso à Internet do Microsoft Entra e do Acesso privado do Microsoft Entra. Os perfis de encaminhamento de tráfego podem ser atribuídos a dispositivos e redes remotas. Para obter um exemplo de como aplicar uma política de Acesso Condicional a esses perfis de tráfego, consulte o artigo Como aplicar políticas de Acesso Condicional ao perfil de tráfego do Microsoft 365.

Para obter mais informações sobre esses perfis, consulte o artigo Perfis de encaminhamento de tráfego do Acesso Seguro Global.

Ações do usuário

As ações do usuário são tarefas executadas por um usuário. Atualmente, o acesso condicional dá suporte a duas ações do usuário:

  • Registrar informações de segurança: essa ação do usuário permite que a política de Acesso Condicional seja imposta quando os usuários habilitados para tentativas de registro combinadas registrarem suas informações de segurança. Mais informações podem ser encontradas no artigo, Registro combinado de informações de segurança.

Observação

Quando os administradores aplicam uma política voltada para ações de usuários visando o registro de informações de segurança, se a conta de usuário for um convidado de uma conta pessoal da Microsoft (MSA), o uso do controle 'Exigir autenticação multifator' exige que o usuário da MSA registre suas informações de segurança na organização. Se o usuário convidado for de outro provedor, como o Google, o acesso será bloqueado.

  • Registrar ou ingressar dispositivos: essa ação do usuário permite que os administradores imponham a política de Acesso Condicional quando os usuários registram ou ingressam dispositivos na ID do Microsoft Entra. Isso fornece granularidade na configuração da autenticação multifator para registrar ou ingressar dispositivos, em vez de uma política de todo o locatário atualmente existente. Há três considerações importantes com essa ação do usuário:
    • Require multifactor authentication é o único controle de acesso disponível para essa ação do usuário e todos os outros estão desabilitados. Essa restrição impede conflitos com controles de acesso que dependem do registro de dispositivo do Microsoft Entra ou que não se aplicam ao registro de dispositivos do Microsoft Entra.
    • Client apps, Filters for devices, e Device state as condições não estão disponíveis com esta ação do usuário, pois dependem do registro do dispositivo Microsoft Entra para impor políticas de acesso condicional.

Aviso

Quando uma política de Acesso Condicional é configurada com a ação de usuário Registrar ou ingressar dispositivos, você deve definir Entra ID>Dispositivos>Visão geral>Configurações de Dispositivo - Require Multifactor Authentication to register or join devices with Microsoft Entra para Não. Caso contrário, as políticas de Acesso Condicional com essa ação de usuário não serão aplicadas corretamente. Mais informações sobre essa configuração de dispositivo podem ser encontradas em Definir configurações do dispositivo.

Contexto de autenticação

O contexto de autenticação pode ser usado para proteger ainda mais dados e ações em aplicativos. Esses aplicativos podem ser seus próprios aplicativos personalizados, aplicativos de linha de negócios personalizados (LOB), aplicativos como o SharePoint ou aplicativos protegidos pelo Microsoft Defender para Aplicativos de Nuvem.

Por exemplo, uma organização pode manter arquivos em sites do SharePoint, como o menu de almoço ou sua receita secreta de molho de churrasco. Todos podem ter acesso ao site de menu de almoço, mas os usuários que têm acesso ao site de receita de molho de churrasco secreto podem precisar acessar de um dispositivo gerenciado e concordar com termos específicos de uso.

O contexto de autenticação funciona com usuários ou identidades de carga de trabalho, mas não na mesma política de Acesso Condicional.

Configurar contextos de autenticação

Os contextos de autenticação são gerenciados em ID do Entra>Acesso Condicional>Contexto de autenticação.

Captura de tela mostrando o gerenciamento de contextos de autenticação.

Crie novas definições de contexto de autenticação selecionando novo contexto de autenticação. As organizações estão limitadas a um total de 99 definições de contexto de autenticação c1-c99. Configure os seguintes atributos:

  • O nome de exibição é o nome usado para identificar o contexto de autenticação no Microsoft Entra ID e nos aplicativos que utilizam contextos de autenticação. Recomendamos nomes que podem ser usados entre recursos, como dispositivos confiáveis, para reduzir o número de contextos de autenticação necessários. Ter um conjunto reduzido limita o número de redirecionamentos e fornece uma experiência melhor para o usuário final.
  • A descrição fornece mais informações sobre as políticas. Essas informações são usadas por administradores e aqueles que aplicam contextos de autenticação aos recursos.
  • A caixa de seleção Publicar nos aplicativos, quando marcada, anuncia o contexto de autenticação para aplicativos e os torna disponíveis para serem atribuídos. Se não for verificado, o contexto de autenticação não estará disponível para recursos downstream.
  • A ID é somente leitura e usada em tokens e aplicativos para definições de contexto de autenticação específicas da solicitação. Listado aqui para casos de uso de solução de problemas e desenvolvimento.

Adicionar à política de Acesso Condicional

Os administradores podem selecionar contextos de autenticação publicados em suas políticas de Acesso Condicional em atribuições>de aplicativos ou ações de nuvem e selecionar o contexto de Autenticação no menu Selecionar o que essa política se aplica .

Captura de tela mostrando como adicionar um contexto de autenticação de Acesso Condicional a uma política

Excluir um contexto de autenticação

Ao excluir um contexto de autenticação, verifique se nenhum aplicativo ainda o está usando. Caso contrário, o acesso aos dados do aplicativo não está mais protegido. Você pode confirmar esse pré-requisito verificando os logs de entrada para casos em que as políticas de acesso condicional de contexto de autenticação estão sendo aplicadas.

Para excluir um contexto de autenticação, ele não deve ter políticas de Acesso Condicional atribuídas e não deve ser publicado em aplicativos. Esse requisito ajuda a evitar a exclusão acidental de um contexto de autenticação que ainda está em uso.

Marcar recursos com contextos de autenticação

Para obter mais informações sobre o uso de contexto de autenticação em aplicativos, consulte os artigos a seguir.

Próximas etapas