Compartilhar via

Acesso condicional do Microsoft Entra: proteção de token (versão prévia)

A proteção de token (às vezes chamado de vinculação de token no setor) tenta reduzir os ataques usando roubo de token, garantindo que um token seja utilizável apenas no dispositivo pretendido. Quando um invasor consegue roubar um token, por sequestro ou repetição, ele pode se passar por sua vítima até que o token expire ou seja revogado. O roubo de token é considerado um evento relativamente raro, mas o dano dele pode ser significativo.

A proteção de token cria um vínculo criptograficamente seguro entre o token e o dispositivo (segredo do cliente) para o qual é emitido. Sem o segredo do cliente, o token vinculado é inútil. Quando um usuário registra um dispositivo Windows 10 ou mais recente na ID do Microsoft Entra, sua identidade primária é associada ao dispositivo. O que isso significa: uma política pode garantir que apenas tokens de sessão de entrada (ou atualização) vinculados, também conhecidos como PRTs (Tokens de Atualização Principal), sejam usados pelos aplicativos ao solicitar acesso a um recurso.

Importante

A proteção ao token está atualmente disponível em versão preliminar pública. Para obter mais informações sobre visualizações, consulte Os Termos de Licença Universais para Serviços Online. Com esta versão preliminar, estamos lhe dando a capacidade de criar uma política de Acesso Condicional para exigir proteção de token para tokens de entrada (tokens atualizados) para serviços específicos. Oferecemos suporte à proteção de token para tokens de entrada no Acesso Condicional para aplicativos de desktop que acessam o Exchange Online e o SharePoint Online em dispositivos Windows.

Importante

As seguintes alterações foram feitas na Proteção de Token desde a versão de visualização pública inicial:

  • Saída de logs de entrada: O valor da cadeia de caracteres usada em enforcedSessionControls e sessionControlsNotSatisfied foi alterado de Binding para SignInTokenProtection no final de junho de 2023. As consultas nos dados do Log de Entrada devem ser atualizadas para refletir essa alteração.
  • Não há mais suporte para dispositivos ingressados no Microsoft Entra usando determinados métodos. Consulte a seção limitações conhecidas para obter uma lista completa.
  • Alteração do código de erro: o código de erro da política de acesso condicional de proteção de token está mudando de 53003 para 530084 para identificar melhor os erros relacionados à proteção de token.
  • A proteção de token agora dá suporte ao Aplicativo Windows, estendendo a proteção para o Windows 365 e a Área de Trabalho Virtual do Azure.

Captura de tela de uma política de Acesso Condicional que exige proteção de token como o controle de sessão.

Requisitos

O uso desse recurso requer licenças P2 do Microsoft Entra ID. Para encontrar a licença certa para seus requisitos, consulte os planos e preços do Microsoft Entra.

Observação

A imposição de proteção de token faz parte do Microsoft Entra ID Protection e requer licenças do Microsoft Entra ID P2 na disponibilidade geral.

Os seguintes dispositivos e aplicativos dão suporte ao acesso a recursos nos quais uma política de acesso condicional de proteção de token é aplicada:

Dispositivos com suporte:

  • Dispositivos Windows 10 ou mais recentes ingressados no Microsoft Entra, ingressados no Microsoft Entra híbrido ou registrados no Microsoft Entra. Consulte a seção de limitações conhecidas para tipos de dispositivo sem suporte.
  • Windows Server 2019 ou mais recente que são ingressados no Microsoft Entra híbrido.

Aplicativos com suporte:

  • Cliente de sincronização do OneDrive versão 22.217 ou mais recente
  • Cliente nativo do Teams versão 1.6.00.1331 ou mais recente
  • Power BI desktop versão 2.117.841.0 (maio de 2023) ou mais recente
  • Módulo do Exchange PowerShell versão 3.7.0 ou mais recente
  • Microsoft Graph PowerShell versão 2.0.0 ou mais recente com a opção EnableLoginByWAM
  • Visual Studio 2022 ou mais recente ao usar a opção de entrada 'Agente de autenticação do Windows'
  • Windows App versão 2.0.379.0 ou mais recente

Limitações conhecidas

  • Não há suporte para clientes perpétuos do Office.
  • Os seguintes aplicativos não dão suporte à entrada usando fluxos de token protegidos e os usuários são bloqueados ao acessar o Exchange e o SharePoint:
    • Módulos do PowerShell que acessam o SharePoint
    • Extensão do PowerQuery para Excel
    • Extensões para Visual Studio Code que acessam o Exchange ou o SharePoint
  • Não há suporte para os seguintes dispositivos cliente Windows:
    • Surface Hub
    • Sistemas MTR (Salas do Microsoft Teams) baseados em Windows
  • Há suporte para usuários externos que atendem aos requisitos de registro do dispositivo de proteção de token em seu tenant de origem. No entanto, os usuários que não atendem a esses requisitos veem uma mensagem de erro não clara sem nenhuma indicação da causa raiz.
  • Os dispositivos registrados com a ID do Microsoft Entra usando os seguintes métodos não têm suporte:
  • Novos dispositivos registrados do Microsoft Entra em versões do Windows anteriores a 24H2 poderão ser bloqueados se os usuários não fizerem login novamente durante o registro. Se bloqueado, os usuários deverão registrar novamente o dispositivo.

Para identificar os dispositivos afetados devido a tipos de registro sem suporte listados anteriormente, inspecione o atributo tokenProtectionStatusDetails nos logs de entrada. As solicitações de token bloqueadas devido a um tipo de registro de dispositivo sem suporte podem ser identificadas com um signInSessionStatusCode valor de 1003.

Para evitar qualquer interrupção para a nova integração, você pode modificar a política de acesso condicional de proteção de token adicionando uma condição de filtro de dispositivo que exclui todos os dispositivos que se enquadram na categoria de implantação descrita anteriormente. Por exemplo, para excluir:

  • PCs de nuvem ingressados no Microsoft Entra, você pode usar systemLabels -eq "CloudPC" and trustType -eq "AzureAD".
  • As Áreas de Trabalho Virtuais do Azure ingressadas no Microsoft Entra, você pode usar systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD".
  • Grupos de computadores hospedados do Power Automate que são ingressados no Microsoft Entra, você pode usar systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD".
  • Dispositivos do Windows Autopilot implantados em modo de autoimplantação podem usar a propriedade enrollmentProfileName. Por exemplo, se você tiver criado um perfil de registro no Intune para seus dispositivos de modo de auto-implantação do Autopilot como "Perfil de auto-implantação do Autopilot", poderá usar `enrollmentProfileName -eq "Perfil de auto-implantação do Autopilot".
  • Máquinas virtuais do Windows no Azure ingressadas no Microsoft Entra, você pode usar profileType -eq "SecureVM" and trustType -eq "AzureAD".

Implantação

Para os usuários, a implantação de uma política de Acesso Condicional para reforçar a proteção de token deve ser invisível ao usar plataformas de cliente compatíveis em dispositivos registrados e aplicativos compatíveis.

Para minimizar a probabilidade de interrupção do usuário devido à incompatibilidade do aplicativo ou dispositivo, recomendamos:

  • Comece com um grupo piloto de usuários e expanda ao longo do tempo.
  • Crie uma política de Acesso Condicional no modo somente relatório antes de passar para a imposição da proteção de token.
  • Capture logs de entrada Interativos e Não interativos.
  • Analise esses logs por tempo suficiente para cobrir o uso normal do aplicativo.
  • Adicione bons usuários conhecidos a uma política de imposição.

Esse processo ajuda a avaliar a compatibilidade do cliente e do aplicativo de seus usuários para a aplicação da proteção de token.

Criar uma política de Acesso Condicional

Os usuários que executam funções especializadas como as descritas nos níveis de segurança de acesso privilegiado são possíveis destinos para essa funcionalidade. Recomendamos a pilotagem com um subconjunto pequeno para começar.

As etapas a seguir ajudam a criar uma política de Acesso Condicional para exigir proteção de token para Exchange Online e SharePoint Online em dispositivos Windows.

  1. Entre no Centro de administração do Microsoft Entra como pelo menos um Administrador de Acesso Condicional.
  2. Navegue até Entra ID>Acesso Condicional>Políticas.
  3. Selecione Nova política.
  4. Dê um nome à sua política. Recomendamos que as organizações criem um padrão significativo para os nomes de suas políticas.
  5. Em Atribuições, selecione Usuários ou identidades de carga de trabalho.
    1. Em Incluir, selecione os usuários ou grupos que estão testando essa política.
    2. Em Excluir, selecione Usuários e grupos e escolha as contas de acesso de emergência ou quebra de vidro da sua organização.
  6. Em Recursos alvo>Recursos (anteriormente aplicativos em nuvem)>Incluir>Selecionar recursos

    1. Em Selecionar, selecione os seguintes aplicativos compatíveis com a versão prévia:

      1. Office 365 Exchange Online
      2. Office 365 - SharePoint Online
      3. Se você implantou o Aplicativo Windows em seu ambiente, inclua:
        1. Área de Trabalho Virtual do Azure
        2. Windows 365
        3. Logon na Nuvem do Windows

      Aviso

      Sua política de Acesso Condicional só deve ser configurada para esses aplicativos. Selecionar o grupo de aplicativos do Office 365 pode resultar em falhas não intencionais. Essa alteração é uma exceção à regra geral de que o grupo de aplicativos do Office 365 deve ser selecionado em uma política de Acesso Condicional.

    2. Escolha Selecionar.

  7. Em condições:
    1. Em plataformas de dispositivos:
      1. Defina Configurar como Sim.
      2. Incluir>Selecionar plataformas de dispositivos>Windows.
      3. Selecione Concluído.
    2. Em aplicativos cliente:

      1. Defina Configurar como Sim.

        Aviso

        Não configurar a condição aplicativos cliente ou deixar o Navegador selecionado pode fazer com que aplicativos que usam MSAL.js, como o Teams Web, sejam bloqueados.

      2. Nos clientes de autenticação moderna, selecione apenas aplicativos móveis e clientes de área de trabalho. Deixe outros itens desmarcados.

      3. Selecione Concluído.

  8. EmSessão de > do Access, selecione Exigir proteção de token para sessões de entrada e selecione Selecionar.
  9. Confirme suas configurações e defina Ativar política para Apenas relatório.
  10. Selecione Criar para criar para habilitar sua política.

Depois que os administradores avaliarem as configurações de política usando impacto da política ou modo somente relatório, eles poderão alternar habilitar política de Somente relatório para Ativar.

Dica

Como as políticas de Acesso Condicional que exigem proteção de token estão atualmente disponíveis apenas para dispositivos Windows, é necessário proteger seu ambiente contra possíveis desvios de política quando um invasor pode parecer vir de uma plataforma diferente.

Além disso, você deve configurar as seguintes políticas:

Capturar logs e analisar

Monitore a imposição de proteção de token no acesso condicional antes e depois da aplicação usando recursos como Impacto de Política (Versão Prévia), logs de autenticação ou Log Analytics.

Logs de entrada

Use o log de entrada do Microsoft Entra para verificar o resultado de uma política de imposição da proteção de token no modo somente relatório ou no modo habilitado.

Captura de tela mostrando um exemplo de uma política que não está sendo atendida.

  1. Entre no Centro de administração do Microsoft Entra como pelo menos um Administrador de Acesso Condicional.
  2. Navegue até Entra ID>Monitoramento e integridade>Registros de entrada.
  3. Selecione uma solicitação específica para determinar se a política é aplicada ou não.
  4. Vá para o painel Acesso Condicional ou Somente Relatório , dependendo de seu estado e selecione o nome da política que exige proteção de token.
  5. Em Controles de Sessão, verifique se os requisitos de política foram satisfeitos ou não.
  6. Para encontrar mais detalhes sobre o estado de associação da solicitação, selecione o painel Informações Básicas e veja o campo Proteção de Token – Sessão de Entrada. Os valores possíveis são os seguintes:
    1. Associado: a solicitação estava usando protocolos associados. Alguns logins podem incluir várias solicitações, e todas as solicitações devem ser vinculadas para atender à política de proteção de tokens. Mesmo que uma solicitação individual pareça estar associada, ela não garante a conformidade com a política se outras solicitações não estiverem associadas. Para ver todas as solicitações de entrada, você pode filtrar todas as solicitações de um usuário específico ou procurar por corelationid.
    2. Não associado: a solicitação não estava usando protocolos associados. Possíveis statusCodes quando a solicitação não está associada:
      1. 1002: A solicitação não está associada devido à falta de estado do dispositivo Microsoft Entra ID.
      2. 1003: A solicitação não está associada porque o estado do dispositivo do Microsoft Entra ID não atende aos requisitos de política de Acesso Condicional para proteção de token. Esse erro pode ser devido a um tipo de registro de dispositivo sem suporte ou o dispositivo não foi registrado usando novas credenciais de entrada.
      3. 1005: A solicitação não está associada por outros motivos não especificados.
      4. 1006: A solicitação não é associada porque a versão do sistema operacional não tem suporte.
      5. 1008: A solicitação não está vinculada porque o cliente não está integrado ao agente da plataforma, como o Gerenciador de Contas do Windows (WAM).

Captura de tela mostrando uma entrada de exemplo com o atributo Proteção de Token – Sessão de Entrada realçado.

Análise de Logs

Você também pode usar o Log Analytics para consultar os logs de entrada (interativos e não interativos) para solicitações bloqueadas devido a uma falha de imposição de proteção de token.

Aqui está um exemplo de consulta do Log Analytics pesquisando os logs de entrada não interativos nos últimos sete dias, realçando solicitações Bloqueadas versus Permitidas por Aplicativo. Essas consultas são apenas exemplos e estão sujeitas a alterações.

Observação

Saída de logs de autenticação: O valor da string usada em "enforcedSessionControls" e "sessionControlsNotSatisfied" foi alterado de "Binding" para "SignInTokenProtection" no final de junho de 2023. As consultas nos dados do Log de Entrada devem ser atualizadas para refletir essa alteração. Os exemplos abrangem os dois valores para incluir dados históricos.

//Per Apps query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, Status,UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]' 
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"] 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id,UserPrincipalName, AppDisplayName, Result 
| summarize Requests = count(), Users = dcount(UserPrincipalName), Block = countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by Requests desc

O resultado da consulta anterior deve ser semelhante à seguinte captura de tela:

Captura de tela mostrando resultados de exemplo de uma consulta do Log Analytics procurando políticas de proteção de token

O exemplo de consulta a seguir analisa o log de entrada não interativo dos últimos sete dias, realçando as solicitações Bloqueadas versus Permitidas pelo Usuário.

//Per users query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies.sessionControlsNotSatisfied 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName,Result  
| summarize Requests = count(),Block = countif(Result == "Block"), Allow = countif(Result == "Allow") by UserPrincipalName, AppDisplayName,ResourceDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by UserPrincipalName asc

O exemplo de consulta a seguir analisa o log de entrada não interativo dos últimos sete dias, destacando os usuários que estão usando dispositivos, em que o estado do dispositivo do Microsoft Entra ID não atende aos requisitos de política de AC de proteção de token.

AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| where TokenProtectionStatusDetails!= "" 
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails) 
| extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"]) 
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"]) 
| where bindingStatusCode == 1003 
| summarize count() by UserPrincipalName

Experiência do usuário final

Um usuário que registrou ou matriculou seu dispositivo não passa por diferenças na experiência de login em um aplicativo com suporte à proteção de token quando o requisito de proteção de token está habilitado.

Um usuário que não se registrou ou não inscreveu o seu dispositivo ou que usa um aplicativo não suportado quando o requisito de proteção de token está habilitado verá a seguinte captura de tela após a autenticação.

Captura de tela da mensagem de erro de proteção de token quando o dispositivo não está registrado ou registrado.

Um usuário que não estiver usando um aplicativo com suporte quando o requisito de proteção de token estiver habilitado verá a captura de tela a seguir após a autenticação.

Captura de tela da mensagem de erro quando uma política de proteção de token bloqueia o acesso.

Conteúdo relacionado

O que é um token de atualização primário?