Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Os recursos de destino (anteriormente aplicativos na 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 a partir da lista de aplicativos ou serviços que incluem aplicativos internos da Microsoft e quaisquer aplicativos integrados do Microsoft Entra, incluindo galeria, não galeria e aplicativos publicados por meio 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 em dispositivos, permitindo que o Acesso Condicional imponha controles em torno dessas ações.
- Os administradores podem direcionar perfis de encaminhamento de tráfego do Global Secure Access para obter funcionalidade aprimorada.
- Os administradores podem usar o contexto de autenticação para fornecer uma camada extra de segurança nos aplicativos.
Aplicações na nuvem da Microsoft
Os administradores podem atribuir uma política de Acesso Condicional aos aplicativos de nuvem da Microsoft se a entidade de serviço aparecer em seu locatário, exceto para o Microsoft Graph. O Microsoft Graph funciona como um recurso guarda-chuva. Use o Relatório de Público para ver os serviços subjacentes e segmentar esses serviços em suas políticas. Algumas aplicações, como o Office 365 e a API de Gestão de Serviços do Windows Azure, incluem múltiplas sub-aplicações ou serviços 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.
Escritório 365
O Microsoft 365 oferece serviços de produtividade e colaboração baseados na nuvem, como Exchange, SharePoint e Microsoft Teams. Os serviços de nuvem do Microsoft 365 são profundamente integrados para garantir experiências suaves e colaborativas. Essa integração pode causar confusão ao criar políticas porque alguns aplicativos, como o Microsoft Teams, dependem de outros, como o SharePoint ou o Exchange.
O agrupamento de aplicativos do Office 365 torna possível direcionar esses serviços de uma só vez. Recomendamos usar o agrupamento do Office 365, em vez de segmentar aplicativos de nuvem individuais para evitar problemas com dependências de serviço.
O direcionamento desse 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 email, calendário e informações de contato. Os metadados relacionados podem ser expostos através de diferentes recursos, como a pesquisa. Para garantir que todos os metadados sejam protegidos conforme pretendido, os administradores devem atribuir políticas à aplicação 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.
Está disponível no artigo Aplicações incluídas no conjunto de aplicações do Office 365 no Acesso Condicional uma lista completa de todos os serviços incluídos.
API de Gestão do Serviço do Microsoft Azure
Quando tem como alvo a API de Gestão de Serviços do Windows Azure, a política é imposta para tokens emitidos para um conjunto de serviços estreitamente ligados ao portal. Este agrupamento inclui os IDs de aplicação de:
- Azure Resource Manager
- Portal do Azure, que também abrange o centro de administração do Microsoft Entra e o Centro do Microsoft Engage
- Azure Data Lake
- API de Insights de Aplicação
- API de Log Analytics
Como a política é aplicada ao portal de gerenciamento e à API do Azure, quaisquer serviços ou clientes que dependem da API do Azure podem ser afetados indiretamente. Por exemplo:
- Azure CLI
- Portal do Azure Data Factory
- Hubs de Eventos do Azure
- Azure PowerShell
- Azure Service Bus
- Base de Dados SQL do Azure
- Azure Synapse
- APIs de modelo de implantação clássico
- Centro de administração do Microsoft 365
- Microsoft IoT Central
- Gestão Multitenant do Microsoft Defender
- SQL Managed Instance
- Portal do administrador de assinaturas do Visual Studio
Atenção
As políticas de Acesso Condicional associadas à API de Gerenciamento de Serviços do Windows Azure não abrangem mais o Azure DevOps.
Note
A aplicação API de Gestão de Serviços do Windows Azure aplica-se ao Azure PowerShell, que chama a API do Azure Resource Manager. Ele não se aplica ao Microsoft Graph PowerShell, que chama o Microsoft Graph API.
Tip
Para o Azure Government, deve almejar a aplicação da API de Gestão de Nuvem do Azure Government.
Portais de Administração da Microsoft
Quando uma política de Acesso Condicional tem como alvo o aplicativo em nuvem Microsoft Admin Portals, a política é aplicada aos tokens emitidos para os IDs de aplicativo dos seguintes portais administrativos da Microsoft:
- portal do Azure
- Centro de administração do Exchange
- Centro de administração do Microsoft 365
- Portal do Microsoft 365 Defender
- centro de administração Microsoft Entra
- Centro de administração do Microsoft Intune
- Portal de conformidade do Microsoft Purview
- Centro de administração do Microsoft Teams
Estamos continuamente a adicionar mais portais administrativos à lista.
Outras aplicações
Os administradores podem adicionar qualquer aplicativo registrado do Microsoft Entra às políticas de Acesso Condicional. Essas aplicações podem incluir:
- Aplicações publicadas através do proxy de aplicações do Microsoft Entra
- Aplicações adicionadas a partir da galeria
- Aplicações personalizadas de fora da galeria
- Aplicações antigas publicadas através de controladores e redes de entrega de aplicações
- Aplicações que utilizam o início de sessão único baseado em palavra-passe
Note
Como a política de Acesso Condicional define os requisitos para acessar um serviço, não é possível aplicá-la 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, um conjunto de políticas no serviço do SharePoint aplica-se a todos os clientes que chamam o SharePoint. Uma política definida no Exchange aplica-se à tentativa de aceder ao e-mail com o cliente Outlook. É por isso que os aplicativos cliente (público/nativo) não estão disponíveis para seleção no seletor de aplicativos e a opção Acesso Condicional não está disponível nas configurações do aplicativo cliente (público/nativo) registrado em seu locatário.
Algumas aplicações não aparecem de todo no seletor. A única maneira de incluir esses aplicativos em uma política de Acesso Condicional é incluir Todos os recursos (anteriormente 'Todos os aplicativos na 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 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 que solicita 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 no desktop 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 baseiam-se nos recursos solicitados por eles.
- Cliente confidencial
- O Acesso Condicional aplica-se aos recursos solicitados pelo cliente e pelo próprio cliente confidencial se ele solicitar um token de ID.
- Por exemplo: se o Outlook Web solicitar um token para escopos
Mail.ReadeFiles.Read, o Acesso Condicional aplicará políticas para o Exchange e o 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 ver os registos de acesso destinados a estes tipos de clientes no centro de administração do Microsoft Entra:
- Entre no centro de administração do Microsoft Entra como pelo menos um Leitor de Relatórios.
- Navegue até Entra ID>Monitorização e saúde>Registos de entrada.
- Adicione um filtro para o tipo de credencial de cliente .
- 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 na nuvem") sem exclusões de aplicativos impõe a política para todas as solicitações de token de sites e serviços, incluindo perfis de encaminhamento de tráfego de Acesso Seguro Global. Esta opção inclui aplicações que não podem ser direcionadas individualmente na política de Acesso Condicional, como Windows Azure Active Directory (00000002-0000-0000-c000-000000000000).
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 todos os recursos (sem exclusões de aplicativos), 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 algum aplicativo for excluído da política, para não bloquear inadvertidamente o acesso do usuário, determinados escopos de baixo privilégio serão excluídos da aplicação da política. Esses escopos permitem chamadas para as APIs subjacentes do Graph, como Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) e Microsoft Graph (00000003-0000-0000-c000-000000000000), para aceder a informações de perfil de utilizador e de filiação em grupos, comumente usadas por aplicações como parte da autenticação. Por exemplo: quando o Outlook solicita um token para o Exchange, ele também solicita o escopo User.Read para poder exibir as informações básicas da conta do usuário atual.
A maioria das aplicações tem uma dependência semelhante, e é por isso que esses escopos de baixo privilégio são automaticamente excluídos sempre que há uma exclusão de aplicação em uma política Todas os recursos. Essas exclusões de escopo de baixo privilégio não permitem acesso a dados além das informações básicas de perfil de usuário e grupo. Os escopos excluídos estão listados da seguinte forma, o consentimento ainda é necessário para que os aplicativos usem essas permissões.
- Clientes nativos e aplicativos de página única (SPAs) têm acesso aos seguintes escopos de baixo privilégio:
- Grafo Azure AD:
email,offline_access,openid,profile,User.Read - Microsoft Graph:
email,offline_access,openid,profile,User.Read, ,People.Read
- Grafo Azure AD:
- Os clientes confidenciais têm acesso aos seguintes âmbitos de baixo privilégio, se forem excluídos de uma política de Todos os recursos:
- Azure AD Graph:
email,offline_access,openid,profileUser.Read,User.Read.AllUser.ReadBasic.All - Microsoft Graph:
email, , ,offline_accessopenid,profile,User.Read,User.Read.All,User.ReadBasic.All,People.Read, ,People.Read.All,GroupMember.Read.AllMember.Read.Hidden
- Azure AD Graph:
Para obter mais informações sobre os âmbitos mencionados, consulte a referência de permissões do Microsoft Graph e Âmbitos e permissões na plataforma de identidade Microsoft.
Protegendo informações de diretório
Se a política de linha de base recomendada de MFA sem exclusões de aplicativos não puder ser configurada devido a razões empresariais, e a política de segurança da sua organização tiver que 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), crie uma política de Acesso Condicional separada, tendo como alvo Windows Azure Active Directory (00000002-0000-0000-c000-000000000000). O Ative Directory do Windows Azure (também chamado de Azure AD Graph) é um recurso que representa dados armazenados no diretório, como usuários, grupos e aplicativos. O recurso do Ative Directory do Windows Azure está incluído em Todos os recursos mas pode ser direcionado individualmente nas políticas de Acesso Condicional usando as seguintes etapas:
- Entre no centro de administração do Microsoft Entra como um Administrador de Definição de Atributo e um Administrador de Atribuição de Atributos.
- Navegue até Entra ID>Atributos de segurança personalizados.
- Crie um novo conjunto de atributos e uma nova definição de atributos. Para obter mais informações, consulte Adicionar ou desativar definições de atributos de segurança personalizados no Microsoft Entra ID.
- Navegue até Entra ID>Enterprise apps.
- Remova o filtro Tipo de Aplicação e procure pelo ID da Aplicação que começa com 00000002-0000-0000-c000-000000000000.
- Selecione Windows Azure Active Directory>atributos personalizados de segurança>Adicionar atribuição.
- Selecione o conjunto de atributos e o valor do atributo que você planeja usar na política.
- Navegue até Entra ID>Acesso Condicional>Políticas.
- Crie ou modifique uma política existente.
- Em Recursos de destino>Recursos (anteriormente aplicativos na nuvem)>Incluir, selecione >Selecionar recursos>Editar filtro.
- Ajuste o filtro para incluir o conjunto de atributos e a definição anteriores.
- Em Controlos de acesso>, Conceder autorização, selecione Conceder acesso, Exigir nível de autenticação, selecione Autenticação multifator, e depois selecione Selecionar.
- Confirme as suas configurações e defina Ativar política como Apenas para relatório.
- Selecione Criar para criar para habilitar sua política.
Note
Configure esta política conforme descrito nas orientações acima. Quaisquer desvios na criação da política conforme descrito (como a definição de exclusões de aplicativos) podem resultar na exclusão de escopos de privilégios baixos e na não aplicação da política conforme pretendido.
Todos os recursos da Internet com Global Secure Access
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 a partir do Microsoft Entra Internet Access.
Esses perfis no Global Secure Access permitem que os administradores definam e controlem como o tráfego é roteado através 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 estes perfis, consulte o artigo Global Secure Access traffic forwarding profiles.
Todos os recursos para agentes (Pré-visualização)
Aplicar uma política de Acesso Condicional a Todos os recursos do agente aplica a política para todos os pedidos de token aos princípios do blueprint de identidade do agente e às identidades dos agentes.
Ações do usuário
As ações do usuário são tarefas que um usuário executa. O Acesso Condicional suporta duas ações do utilizador:
- Registrar informações de segurança: essa ação do usuário permite que as políticas de Acesso Condicional apliquem regras quando os usuários tentam registrar suas informações de segurança. Para obter mais informações, consulte Registro de informações de segurança combinadas.
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 conta pessoal da Microsoft (MSA), 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 Google, o acesso será bloqueado.
-
Registrar ou ingressar dispositivos: esta ação do usuário permite que os administradores apliquem a política de Acesso Condicional quando os usuários se registram ou ingressam dispositivos na ID do Microsoft Entra. Ele permite que os administradores configurem a autenticação multifator para registrar ou ingressar dispositivos com mais granularidade do que uma política para todo o locatário. Há três considerações principais com esta ação do usuário:
-
Require multifactor authenticationeRequire auth strengthsão os únicos controles de acesso disponíveis com esta ação do usuário e todos os outros estão desativados. Essa restrição evita conflitos com controles de acesso que dependem do registro do dispositivo Microsoft Entra ou não são aplicáveis ao registro do dispositivo Microsoft Entra.- O Windows Hello for Business e as chaves de acesso associadas ao dispositivo não são suportados porque esses cenários exigem que o dispositivo já esteja registrado.
-
Client apps,Filters for deviceseDevice stateas condições não estão disponíveis com esta ação do utilizador porque dependem do registo do dispositivo Microsoft Entra para aplicar políticas de Acesso Condicional.
-
Warning
Se uma política de Acesso Condicional estiver configurada com a ação de Registo ou adesão de dispositivos de utilizador, defina Entra ID> Dispositivos> Visão geral> Configurações do dispositivo - 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 do usuário não serão aplicadas corretamente. Saiba mais sobre esta definição de dispositivo em Definir definições do dispositivo.
Contexto de autenticação
O contexto de autenticação protege dados e ações em aplicativos. Esses aplicativos incluem aplicativos personalizados, aplicativos de linha de negócios (LOB), SharePoint ou aplicativos protegidos pelo Microsoft Defender for Cloud Apps. Também pode ser utilizado com o Microsoft Entra Privileged Identity Management (PIM) para aplicar políticas de Acesso Condicional durante a ativação de funções.
Por exemplo, uma organização pode armazenar arquivos em sites do SharePoint, como um menu de almoço ou uma receita secreta de molho BBQ. Todos podem acessar o site do menu de almoço, mas os usuários que acessam o site secreto de receitas de molho BBQ podem precisar usar um dispositivo gerenciado e concordar com termos de uso específicos. De forma semelhante, um administrador que ativa um papel privilegiado através do PIM pode ser obrigado a realizar autenticação multifator ou a utilizar um dispositivo compatível.
O contexto de autenticação funciona com utilizadores ou identidades de carga de trabalho, mas não dentro da mesma política de Acesso Condicional.
Configurar contextos de autenticação
Gerencie contextos de autenticação acessando Entra ID>Acesso Condicional>Contexto 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:
- Nome de exibição é o nome usado para identificar o contexto de autenticação no ID do Microsoft Entra e nos aplicativos que consomem contextos de autenticação. Recomendamos nomes que possam 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 proporciona uma melhor experiência ao usuário final.
- 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 a recursos.
- A caixa de seleção Publicar em aplicativos , quando selecionada, anuncia o contexto de autenticação para aplicativos e o torna disponível para ser atribuído. Se não for selecionado, o contexto de autenticação não estará disponível para recursos downstream.
- O ID é de apenas leitura e usado em tokens e aplicativos para definições de contexto de autenticação específicas da solicitação. Listados aqui para a resolução de problemas e casos de uso para desenvolvimento.
Adicionar à política de Acesso Condicional
Os administradores podem selecionar contextos de autenticação publicados em políticas de> Acesso Condicional indo para Atribuiçõesde aplicativos ou ações na nuvem e selecionando Contexto de autenticação no menu Selecione a que esta política se aplica.
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 ao verificar os logs de entrada para casos em que são aplicadas políticas de Acesso Condicional baseadas no contexto de autenticação.
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 evita a exclusão acidental de um contexto de autenticação ainda em uso.
Marcar recursos com contextos de autenticação
Para saber mais sobre a utilização de contextos de autenticação, consulte os seguintes artigos.
- Usar rótulos de sensibilidade para proteger conteúdo no Microsoft Teams, grupos do Microsoft 365 e sites do SharePoint
- Aplicativos do Microsoft Defender para Nuvem
- Aplicações personalizadas
- Gestão de Identidades Privilegiadas - Ao ativar, requer o contexto de autenticação do Acesso Condicional Microsoft Entra
Conteúdo relacionado
- Acesso condicional: condições – Saiba como configurar condições para refinar suas políticas.
- Políticas comuns de acesso condicional – Explore modelos de políticas comuns para começar rapidamente.
- Dependências do aplicativo cliente – Entenda como as dependências afetam as políticas de Acesso Condicional.