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 entre a lista de aplicativos ou serviços que incluem aplicativos integrados da Microsoft e quaisquer aplicativos integrados do Microsoft Entra, incluindo aplicativos de galeria, aplicativos fora de galeria e aplicativos publicados através do Proxy de Aplicativo.
  • Os administradores podem definir uma política com base 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 Seguro Global 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 de uma política de Acesso Condicional e do 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 se a entidade de serviço estiver presente no 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 oferece serviços de colaboração e produtividade baseados em nuvem, como 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 porque alguns aplicativos, como o Microsoft Teams, dependem de outros, como SharePoint ou Exchange.

O agrupamento de aplicativos do Office 365 possibilita direcionar esses serviços de uma só vez. É recomendável usar o agrupamento 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 do Office 365.

Os administradores podem excluir todo o pacote do Office 365 ou aplicativos de nuvem específicos do Office 365 das políticas 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 e o Microsoft Engage Center
  • 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
  • Hubs de Eventos do Azure
  • Azure PowerShell
  • 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
  • Microsoft IoT Central
  • Gerenciamento multilocatário do Microsoft Defender
  • Instância Gerenciada de SQL
  • Portal do administrador de assinaturas do Visual Studio

Cuidado

As políticas de Acesso Condicional associadas à API de Gerenciamento de Serviços do Windows Azure não abrangem mais o Azure DevOps.

Note

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.

Tip

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:

Note

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 aos próprios clientes públicos, mas se baseiam nos recursos que eles solicitam.
  • 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 impõe a 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).

Important

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.AllMember.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 motivos comerciais e a política de segurança da sua organização precisar incluir escopos de privilégios baixos relacionados ao diretório (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden), crie uma política de acesso condicional separada direcionada a 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

Note

Configure essa política conforme descrito nas diretrizes acima. Quaisquer desvios na criação da política conforme descrito (como definir exclusões de aplicativo) podem resultar na exclusão de escopos de privilégios baixos e na não aplicação da política conforme o esperado.

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.

Esses perfis no Acesso Seguro Global permitem que os administradores definam e controlem como o tráfego é roteado por meio do Microsoft Entra Internet Access e do Microsoft Entra Private Access. 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.

Todos os recursos do agente (versão prévia)

A aplicação de uma política de acesso condicional a todos os recursos de agentes impõe a política para todas as solicitações de token para principais do modelo de identidade de agentes e identidades de agentes.

Ações do usuário

As ações do usuário são tarefas executadas por um usuário. O Acesso Condicional dá suporte a duas ações de usuário:

  • Registrar informações de segurança: essa ação do usuário permite que as políticas de Acesso Condicional imponham regras quando os usuários tentam registrar suas informações de segurança. Para obter mais informações, consulte o registro combinado de informações de segurança.

Note

Se os administradores aplicarem uma política direcionada às ações do usuário para registrar informações de segurança e a conta de usuário for um convidado de uma MSA (conta pessoal da Microsoft), o controle "Exigir autenticação multifator" exigirá que o usuário do MSA registre 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. Ele permite que os administradores configurem a autenticação multifator para registrar ou conectar-se a dispositivos com mais granularidade do que uma política abrangente de locatário. Há três considerações importantes com essa ação do usuário:
    • Require multifactor authentication e Require auth strength são os únicos controles de acesso disponíveis com 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.
      • Não há suporte para o Windows Hello para Empresas e as chaves de passagem associadas ao dispositivo porque esses cenários exigem que o dispositivo já esteja registrado.
    • Client apps, Filters for devices, e Device state as condições não estão disponíveis com esta ação do usuário porque dependem do registro do dispositivo Microsoft Entra para impor políticas de acesso condicional.

Warning

Se uma política de Acesso Condicional estiver configurada com a ação de usuário Registrar ou ingressar dispositivos, defina ID do Entra>Dispositivos>Visão Geral>Configurações de Dispositivos - Require Multifactor Authentication to register or join devices with Microsoft Entra como Não. Caso contrário, as políticas de Acesso Condicional com essa ação de usuário não serão aplicadas corretamente. Saiba mais sobre essa configuração de dispositivo em Definir configurações de dispositivo.

Contexto de autenticação

O contexto de autenticação protege dados e ações em aplicativos. Esses aplicativos incluem aplicativos personalizados, aplicativos LOB (linha de negócios), SharePoint ou aplicativos protegidos pelo Microsoft Defender para Aplicativos de Nuvem. Ele também pode ser usado com o PIM (Microsoft Entra Privileged Identity Management) para impor políticas de acesso condicional durante a ativação da função.

Por exemplo, uma organização pode armazenar arquivos em sites do SharePoint, como um menu de almoço ou uma receita secreta de molho de churrasco. Todos podem acessar o site de menus de almoço, mas os usuários que acessam o site de receitas de molho de churrasco secreto podem precisar usar um dispositivo gerenciado e concordar com termos específicos de uso. Da mesma forma, um administrador que ativa uma função privilegiada por meio do PIM pode precisar executar a autenticação multifator ou usar um dispositivo em conformidade.

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

Gerencie contextos de autenticação indo para ID do Entra>Acesso Condicional>Contexto de Autenticação.

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

Selecione Novo contexto de autenticação para criar uma definição de contexto de autenticação. As organizações podem criar até 99 definições de contexto de autenticação (c1-c99). Configure estes 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.
  • Caixa de seleção "Publicar em aplicativos", quando selecionada, comunica o contexto de autenticação para aplicativos e o disponibiliza para ser atribuído. Se não estiver selecionado, 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 políticas de Acesso Condicional acessando Atribuições>aplicativos ou ações de Nuvem e selecionando contexto de autenticação no menu Selecionar para 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

Antes de excluir um contexto de autenticação, certifique-se de que nenhum aplicativo o use. Caso contrário, o acesso aos dados do aplicativo não será protegido. Confirme isto verificando os logs de entrada do usuário em busca de casos em que as políticas de Acesso Condicional aplicadas ao contexto de autenticação são aplicadas.

Para excluir um contexto de autenticação, verifique se ele não tem políticas de Acesso Condicional atribuídas e não está publicado em aplicativos. Isso impede a exclusão acidental de um contexto de autenticação ainda em uso.

Marcar recursos com contextos de autenticação

Para saber mais sobre como usar contextos de autenticação, consulte os artigos a seguir.

Conteúdo relacionado

  • Last updated on