Guia de implementação da Proteção de Tokens - Aplicações Web (Pré-visualização)

Este guia cobre os passos necessários para implementar e aplicar a Proteção de Tokens para tokens de sessão de início de sessão usados por aplicações web (baseadas em browser) que acedem ao Azure Resource Manager (ARM).

Para uma visão geral da Proteção de Tokens e das plataformas suportadas, consulte Proteção de Tokens em Microsoft Entra Acesso Condicional. Consulte a documentação de visão geral antes de utilizar este guia de implementação.

Pré-requisitos

A utilização desta funcionalidade requer licenças Microsoft Entra ID P1. Para encontrar a licença certa para os seus requisitos, consulte Comparação das funcionalidades geralmente disponíveis do Microsoft Entra ID.

Aplicações, recursos e navegadores suportados

Aplicações

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

Apenas as aplicações web anteriores são suportadas. O acesso dos utilizadores a outras aplicações web que acedam ao ARM é bloqueado quando a política é aplicada. As principais aplicações web que acedem ao ARM mas não são suportadas incluem, mas não se limitam a:

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

Recursos suportados

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

Plataformas e navegadores suportados

¹ Alguns tipos de registo de dispositivos não são suportados. Consulte a lista de tipos de registo de dispositivos não suportados.

Ativar a Proteção de Tokens para ARM no Windows e macOS

Para minimizar a probabilidade de perturbação do utilizador devido à incompatibilidade da aplicação, 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 Tokens em modo apenas de relatório antes de a aplicar.
• Capture registos de entrada tanto interativos como não interativos.
• Analise esses logs por tempo suficiente para cobrir o uso normal do aplicativo. As instruções para analisar e compreender o impacto do utilizador são descritas nas secções seguintes.
• Adicione utilizadores conhecidos e fiáveis a um grupo de utilizadores e faça cumprir a política.

Este processo ajuda a avaliar a prontidão dos seus utilizadores para a aplicação da proteção de tokens.

Passo 1: Configurar dispositivos do utilizador final

Complete o seguinte em cada dispositivo, seja manualmente, através de Group Policy ou Intune.

Windows

1. Certifique-se de que o dispositivo corre a versão Windows 11 26100.8246 / 26200.8246 ou posterior.

2. Ative esta pré-visualização definindo o seguinte valor do registo:

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

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

   • Google Chrome: Instale o Microsoft Single Sign On a partir da Chrome Web Store, selecione Adicionarà extensãoAdicionar ao Chrome> e confirme que aparece na barra de ferramentas.
   • Microsoft Edge: Vai a edge://extensions, ativa o Permitir extensões de outras lojas, instala a extensão Microsoft Single Sign On e confirma que está ativada.

macOS

1. Instale o Microsoft Portal da Empresa ou implemente-o através da sua solução MDM. O Portal da Empresa serve como intermediário de autenticação para os inicios de sessão do Microsoft Entra.
2. Ative o registo suportado por hardware usando uma das seguintes opções:
   • Opção A: Ativar o plug-in SSO da Microsoft Enterprise.
   • Opção B: Configurar o SSO da Plataforma para macOS. O SSO da plataforma utiliza armazenamento com suporte de hardware por padrão e não requer configuração adicional de sinalizadores (flags). Para instruções de configuração, consulte Configure Platform SSO para dispositivos macOS em Microsoft Intune.
3. Instale a extensão do navegador Microsoft Single Log-On no Microsoft Edge ou Google Chrome, conforme descrito na secção Windows anterior.

O que esperar após o Step 1

Uma vez que o dispositivo cumpre os pré-requisitos e a configuração se propaga, os pedidos de autenticação das aplicações suportadas e navegadores deixam de ser concluídos completamente dentro do navegador e são tratados pelo broker de autenticação da plataforma. Este comportamento é o que permite que essas aplicações utilizem tokens de sessão de início de sessão limitados ao dispositivo, como os Primary Refresh Tokens (PRTs), e satisfaça a política de Acesso Condicional de Proteção de Tokens.

Planeie o seguinte:

• Espere pelo menos 24 horas para que a alteração faça efeito. A mudança para autenticação baseada em corretor não é imediata após a aplicação do valor do registo, extensão ou perfil SSO da Plataforma. Não avances para o Passo 2 até esta janela passar, ou os teus dados apenas de relatório não mostrarem com precisão a prontidão.
• A transição é automática na maioria dos casos. Os utilizadores geralmente não tomam qualquer ação; As sessões existentes do navegador continuam a funcionar enquanto a alteração se propaga.
• Alguns utilizadores veem um breve diálogo de início de sessão. Durante a pré-visualização, os utilizadores que acedam ao portal Azure podem ver brevemente uma mensagem "A iniciar sessão... " a indicar que uma nova janela está a abrir. Não aparece nenhuma nova janela nem é necessária qualquer ação do utilizador, e o início de sessão conclui-se sozinho. Opcionalmente, comunique este comportamento ao seu grupo piloto com antecedência para que não seja reportado como falha.

Passo 2: Criar a política de Acesso Condicional em modo apenas de relatório

Depois de esperar 24 horas após concluir o Step 1, pode continuar a definir uma política em modo apenas de relatório para rever a prontidão para a aplicação.

1. Inicie sessão no centro de administração Microsoft Entra como pelo menos um Administrador de Acesso Condicional.
2. Navegue até Entra ID>Políticas de Acesso >Condicional, depois selecione Nova política e dê-lhe um nome.
3. EmUtilizadores>de Atribuições, inclua os seus utilizadores piloto ou de teste. Não inclua os acessos de emergência ou contas de emergência da sua organização.
4. Em Recursos> de destinoRecursos (anteriormente aplicações na cloud)>Incluir>Recursos selecionados, selecionar recursos, selecionar Windows Azure API de Gestão de Serviços.
5. Em Condições>Plataformas de Dispositivos, defina Configurar para Sim e inclua Windows, macOS ou ambos.
6. Em Condições >Aplicações Cliente, defina Configurar para Sim e inclua Browser. Certifique-se de não selecionar aplicações móveis nem clientes de desktop nesta pré-visualização.
7. Em Sessão de Controlos> de Acesso, selecione Exigir proteção de token para sessões de início de sessão e depois selecione Selecionar.
8. Defina a política de Ativar para Apenas Relatórios e selecione Criar.

Passo 3: Rever a prontidão para a aplicação da lei com registos e métricas

Depois de a política de apenas relatório estar em vigor, deve rever o Impacto da Política, analisar os seus registos de início de sessão e investigar com o Log Analytics para avaliar a prontidão para implementação.

Registos de início de sessão

Para visualizar eventos de início de sessão relacionados com a Proteção de Tokens 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>Monitorização e saúde>Registos de entrada.
3. Adicione a coluna Proteção de Token – código de estado da sessão de início à sua vista para visualizar rapidamente os eventos de início de sessão relacionados. Além disso, filtre para o recurso Azure Resource Manager e defina a aplicação cliente para Browser para isolar os pedidos de início de sessão relacionados com esta pré-visualização.
4. Selecione o evento de início de sessão que está a investigar.
5. Revise os separadores de Acesso Condicional e Apenas Relatório , dependendo do estado da política, e selecione a sua política de proteção de tokens.
6. Nos controlos da Sessão, verifique se os requisitos da política foram cumpridos.
7. Selecione o separador Informação Básica e verifique o campo Proteção de Token - Sessão de Início de Sessão para mais informações.

Os registos de início de sessão incluem uma tokenProtectionStatusDetails propriedade que indica se um pedido utiliza um token ligado ao dispositivo:

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

Códigos de estado da sessão de início de sessão

Para perceber porque é que um pedido aparece como não vinculado ou para identificar a que utilizadores pode aplicar a política, consulte os seguintes códigos de estado.

Identificar utilizadores auto-remediáveis (apenas macOS)

No macOS, os códigos 1003 e 1004 são auto-remediáveis através de uma atualização única do registo do dispositivo.

Para identificar pedidos que sejam compatíveis ou atualizáveis com ações do utilizador, filtre por:

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

Exemplo de consulta Microsoft Graph para logins não interativos:

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 Tokens é aplicada a estes utilizadores, são convidados a iniciar sessão novamente e podem aceder aos recursos assim que terminarem a autenticação.

Análise de Registos

Também pode usar o Log Analytics para consultar logs de início de sessão interativos e não interativos para pedidos bloqueados devido a falhas na aplicação da Proteção de Tokens. Estas consultas são apenas amostras e estão sujeitas a alterações. Eles filtram o recurso do Azure Resource Manager e adicionam métricas de prontidão para que possas distinguir blocos rígidos dos auto-remediáveis.

Pedidos por aplicação

A seguinte consulta de exemplo pesquisa os registos de início de sessão não interativos dos últimos sete dias, destacando pedidos bloqueados versus permitidos ao ARM por aplicação, e sinaliza bloqueios que os utilizadores podem corrigir por si próprios. Em vez disso, faça a troca SigninLogs para rever os logins interativos 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

Pedidos do utilizador

A consulta seguinte analisa os registos de início de sessão não interativos dos últimos sete dias, destacando pedidos bloqueados versus permitidos ao ARM por utilizador, com as mesmas métricas auto-remediáveis e aplicáveis.

// 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

Passo 4: Aplicar a política

Depois de rever os dados do registo de início de sessão e confirmar que os utilizadores e dispositivos alvo estão prontos, mova a opção Ativar a política de Só Relatório para Ativado.

Conteúdo relacionado

• Proteção de Token no Acesso Condicional do Microsoft Entra
• Guia de implementação da Proteção de Tokens - Windows
• Guia de implementação da Proteção de Tokens - Plataformas Apple
• O que é um token de atualização primário?