Guia de implantação da Proteção de Token – Aplicativos Web (versão prévia)

Este guia aborda as etapas necessárias para implantar e impor a Proteção de Token para tokens de sessão de entrada usados por aplicativos Web (baseados em navegador) que acessam o ARM (Azure Resource Manager).

Para obter uma visão geral da Proteção de Token e das plataformas com suporte, consulte Token Protection no Microsoft Entra Acesso Condicional. Examine a documentação de visão geral antes de usar este guia de implantação.

Pré-requisitos

O uso desse recurso requer licenças P1 do Microsoft Entra ID. Para encontrar a licença certa para seus requisitos, confira Comparar os recursos geralmente disponíveis do Microsoft Entra ID.

Aplicativos, recursos e navegadores com suporte

Aplicativos

• portal do Azure
• Centro de administração do Microsoft Intune
• centro de administração do Microsoft Entra
• Microsoft Engage Center
• Hub do Microsoft Engage

Somente os aplicativos Web anteriores têm suporte. O acesso dos usuários a outros aplicativos Web que acessam o ARM é bloqueado quando a política é imposta. Os principais aplicativos Web que acessam o ARM, mas não têm suporte , incluem, mas não se limitam a:

• Centro de Conformidade e Segurança do Microsoft 365
• Microsoft AppSource
• Azure Data Factory
• Azure aplicativo do AI Studio
• Synapse Studio do Azure
• Microsoft Power BI
• Portal do Desenvolvedor do Microsoft
• Azure OpenAI Studio
• Centro de administração do Power Platform

Recursos suportados

• Azure Resource Manager (ARM), configurado no Acesso Condicional como o recurso da API de Gerenciamento de Serviços Windows Azure.

Plataformas e navegadores com suporte

¹ Não há suporte para alguns tipos de registro de dispositivo. Consulte a lista de tipos de registro de dispositivo sem suporte.

Habilitar a Proteção de Token para ARM em Windows e macOS

Para minimizar a probabilidade de interrupção do usuário devido à incompatibilidade de aplicativo, navegador ou dispositivo, siga estas recomendações:

• Comece com um grupo piloto de usuários e expanda ao longo do tempo.
• Crie uma política de Acesso Condicional para a Proteção de Token no modo somente relatório antes de aplicá-la.
• Capture registros de logon interativos e não interativos.
• Analise esses logs tempo suficiente para cobrir o uso normal do aplicativo. As instruções para analisar e entender o impacto do usuário são descritas nas seções a seguir.
• Adicione usuários conhecidos e confiáveis a um grupo de usuários e imponha a política.

Esse processo ajuda a avaliar a preparação dos usuários para a imposição da proteção de token.

Etapa 1: Configurar dispositivos de usuário final

Conclua o seguinte em cada dispositivo manualmente ou por meio da Política de Grupo ou do Intune.

Windows

1. Verifique se o dispositivo é executado Windows 11 build 26100.8246/26200.8246 ou posterior.

2. Habilite esta visualização definindo o seguinte valor do Registro:

   [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\BrowserCore]
   "EnablePlatformAuth"=dword:00000001
   

3. Instale a extensão do navegador Microsoft Single Sign-On:

   • Google Chrome: Instale Microsoft Logon Único na Chrome Web Store, selecione Adicionar àextensão Adicionarao Chrome> e confirme se ele aparece na barra de ferramentas.
   • Microsoft Edge: vá para edge://extensions, ative Permitir extensões de outros repositórios, instale a extensão Microsoft Logon Único e confirme se ela está habilitada.

macOS

1. Instale o Microsoft Portal da Empresa ou implante-o por meio de sua solução de MDM. Portal da Empresa serve como agente de autenticação para entradas Microsoft Entra.
2. Habilite o registro com suporte de hardware usando uma das seguintes opções:
   • Opção A: Habilite o plug-in Microsoft Enterprise SSO.
   • Opção B: Configurar o SSO da Plataforma para macOS. O SSO da plataforma usa o armazenamento com suporte de hardware por padrão e não requer nenhuma configuração de sinalizador extra. Para obter instruções de instalação, consulte Configure Platform SSO para dispositivos macOS em Microsoft Intune.
3. Instale a extensão do navegador Microsoft logon único no Microsoft Edge ou no Google Chrome, conforme descrito na seção Windows anterior.

O que esperar após a Etapa 1

Depois que o dispositivo atender aos pré-requisitos e às propagações de configuração, as solicitações de autenticação de aplicativos e navegadores compatíveis param de ser concluídas inteiramente dentro do navegador e, em vez disso, são tratadas pelo agente de autenticação da plataforma. Esse comportamento é o que permite que esses aplicativos usem tokens de sessão de entrada associados ao dispositivo, como PRTs (Tokens de Atualização Primária) e satisfaçam a política de Acesso Condicional de Proteção de Token.

Planeje o seguinte:

• Permita pelo menos 24 horas para que a alteração entre em vigor. A mudança para a autenticação baseada em agente não é imediata depois que o valor do registro, a extensão ou o perfil de SSO da Plataforma são aplicados. Não vá para a Etapa 2 até que essa janela seja aprovada ou os dados somente de relatório não mostrem com precisão a preparação.
• A transição é automática na maioria dos casos. Os usuários geralmente não tomam nenhuma ação; as sessões existentes do navegador continuam funcionando enquanto a alteração se propaga.
• Alguns usuários veem uma breve caixa de diálogo de entrada. Durante a visualização, os usuários que acessam o portal do Azure podem ver brevemente um "Entrando em... ", mensagem informando que uma nova janela está sendo aberta. Nenhuma nova janela é exibida e nenhuma ação do usuário é necessária e a entrada é concluída por conta própria. Opcionalmente, comunique esse comportamento ao grupo piloto com antecedência para que ele não seja relatado como uma falha.

Etapa 2: Criar a política de Acesso Condicional no modo somente relatório

Depois de aguardar 24 horas após terminar a Etapa 1, você poderá continuar a definir uma política no modo somente relatório para examinar a preparação de imposição.

1. Entre no centro de administração do Microsoft Entra como pelo menos um Administrador de Acesso Condicional.
2. Navegue até Entra ID>Políticas de AcessoCondicional> e selecione Nova política e dê um nome a ela.
3. EmAtribuições usuários, inclua seus usuários> piloto ou de teste. Não inclua o acesso de emergência da sua organização ou contas de quebra de vidro.
4. Em Recursos de destino>(anteriormente aplicativos de nuvem)>Inclua>Selecionar recursos, selecione Windows Azure API de Gerenciamento de Serviços.
5. Em Condições Plataformas>de dispositivo, defina Configurar como Sim e inclua Windows, macOS ou ambos.
6. Em Condições>, definaConfigurar como Sim e inclua Navegador. Certifique-se de não selecionar aplicativos móveis e clientes da área de trabalho para esta versão prévia.
7. EmSessão de controles> do Access, selecione Exigir proteção de token para sessões de entrada e selecione Selecionar.
8. Defina Habilitar política para Somente Relatório e selecione Criar.

Etapa 3: Examinar a preparação para a imposição com logs e métricas

Depois que a política somente relatório estiver em execução, você deverá examinar o impacto da política, analisar seus logs de acesso e investigar com Log Analytics para examinar a prontidão para imposição.

Registros de entrada

Para exibir eventos de entrada relacionados à Proteção de Token no centro de administração:

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 saúde>Registros de entrada.
3. Adicione a coluna Proteção de Token – Código de Status da Sessão de Login à sua visualização para ver rapidamente os eventos de login relacionados. Além disso, filtre para o recurso Azure Resource Manager e defina o aplicativo Cliente como Navegador para isolar as solicitações de entrada relacionadas a essa visualização.
4. Selecione o evento de login que você está investigando.
5. Examine as guias acesso condicional e somente relatório , dependendo do estado da política, e selecione sua política de proteção de token.
6. Nos controles de sessão, verifique se os requisitos de política foram atendidos.
7. Selecione a guia Informações básicas e verifique o campo Proteção de Token – Sessão de Entrada para obter mais informações.

Os logs de entrada incluem uma tokenProtectionStatusDetails propriedade que indica se uma solicitação usa um token associado ao dispositivo:

"tokenProtectionStatusDetails": {
  "signInSessionStatus": "bound | unbound",
  "signInSessionStatusCode": <code>
}

Códigos de status de sessão de entrada

Para entender por que uma solicitação é exibida como desassociada ou para identificar a quais usuários você pode aplicar a política, consulte os seguintes códigos de status.

Identificar usuários auto-corretivos (somente macOS)

No macOS, os códigos 1003 e 1004 são auto-corretivos por meio de uma atualização de registro de dispositivo única.

Para identificar solicitações compatíveis ou atualizáveis com a ação do usuário, filtre para:

• signInSessionStatus == bound, ou
• signInSessionStatus == unbound com signInSessionStatusCode de 1003 ou 1004.

Exemplo Microsoft Graph consulta para entradas não interativas:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=(
  signInEventTypes/any(t: t eq 'nonInteractiveUser')
  and resourceDisplayName eq 'Azure Resource Manager'
  and (tokenProtectionStatusDetails/signInSessionStatusCode eq 1003
    or tokenProtectionStatusDetails/signInSessionStatusCode eq 1004
    or tokenProtectionStatusDetails/signInSessionStatus eq 'bound'))

Quando a Proteção de Token é imposta para esses usuários, eles são solicitados a entrar novamente e podem acessar recursos assim que terminarem de autenticar.

Análise de Logs

Você também pode usar Log Analytics para consultar logs de entrada interativos e não interativos para solicitações bloqueadas devido a uma falha de imposição da Proteção de Token. Essas consultas são apenas exemplos e estão sujeitas a alterações. Eles filtram o recurso Azure Resource Manager e adicionam métricas de preparação para que você possa distinguir blocos rígidos dos auto-correcionáveis.

Solicitações por aplicativo

A consulta de exemplo a seguir pesquisa os logs de entrada não interativos nos últimos sete dias, realçando solicitações bloqueadas versus permitidas ao ARM por aplicativo e os blocos de sinalizadores que os usuários podem corrigir automaticamente. SigninLogs Alterne para examinar as entradas interativas do navegador.

// Select the log to query (SigninLogs or AADNonInteractiveUserSignInLogs)
// SigninLogs
AADNonInteractiveUserSignInLogs
// Adjust the time range below
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, Status, UserPrincipalName, AppDisplayName,
    ResourceDisplayName, TokenProtectionStatusDetails
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Azure Resource Manager"
// Add UserPrincipalName if you want to filter to a specific user
// | 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 'Binding', 'Block', 'Allow')
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails)
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"])
| extend IsSelfRemediable = Result == "Block"
    and (bindingStatusCode == "1003" or bindingStatusCode == "1004")
| summarize by Id, UserPrincipalName, AppDisplayName, Result, IsSelfRemediable
| summarize Requests = count(),
    Users = dcount(UserPrincipalName),
    Allow = countif(Result == "Allow"),
    Block = countif(Result == "Block"),
    BlockSelfRemediable = countif(IsSelfRemediable == true),
    BlockedUsers = dcountif(UserPrincipalName, Result == "Block"),
    BlockedUsersSelfRemediable = dcountif(UserPrincipalName, IsSelfRemediable == true)
    by AppDisplayName
| extend PctAllowed = round(100.0 * Allow / (Allow + Block), 2)
| extend PctEnforceable = round(100.0 * (Allow + BlockSelfRemediable) / (Allow + Block), 2)
| project AppDisplayName, Requests, Users, Allow, Block,
    BlockSelfRemediable, BlockedUsers, BlockedUsersSelfRemediable,
    PctAllowed, PctEnforceable
| sort by Requests desc

Solicitações por usuário

A consulta a seguir analisa os logs de entrada não interativos dos últimos sete dias, realçando as solicitações bloqueadas versus permitidas ao ARM pelo usuário, com as mesmas métricas auto-correcionáveis e imposição.

// Per-user query for the Azure portal -> ARM web app scenario
// SigninLogs
AADNonInteractiveUserSignInLogs
// Adjust the time range below
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, UserPrincipalName, AppDisplayName,
    ResourceDisplayName, TokenProtectionStatusDetails
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Azure Resource Manager"
// Add UserPrincipalName if you want to filter to a specific user
// | 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 'Binding', 'Block', 'Allow')
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails)
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"])
| extend IsSelfRemediable = Result == "Block"
    and (bindingStatusCode == "1003" or bindingStatusCode == "1004")
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName, Result, IsSelfRemediable
| summarize Requests = count(),
    Allow = countif(Result == "Allow"),
    Block = countif(Result == "Block"),
    BlockSelfRemediable = countif(IsSelfRemediable == true)
    by UserPrincipalName, AppDisplayName, ResourceDisplayName
| extend PctAllowed = round(100.0 * Allow / (Allow + Block), 2)
| extend PctEnforceable = round(100.0 * (Allow + BlockSelfRemediable) / (Allow + Block), 2)
| project UserPrincipalName, AppDisplayName, ResourceDisplayName,
    Requests, Allow, Block, BlockSelfRemediable,
    PctAllowed, PctEnforceable
| sort by UserPrincipalName asc

Etapa 4: Impor a política

Depois de revisar os dados de logon e confirmar que seus usuários e dispositivos de destino estão prontos, mude a alternância de Habilitar política de Somente Relatório para Ativado.

Conteúdo relacionado

• Proteção de Token no Acesso condicional do Microsoft Entra
• Guia de implantação da Proteção de Token – Windows
• Guia de implantação da Proteção de Token – Plataformas da Apple
• O que é um token de atualização primário?