Pular para o conteúdo principal

Novidade no Microsoft Entra: Proteção de Tokens agora disponível para apps do Windows!

A Microsoft acaba de liberar uma novidade poderosa para quem se preocupa com segurança de identidade: agora é possível aplicar Token Protection (Proteção de Tokens) em aplicativos do Windows, como Azure Virtual Desktop (AVD) e Windows 365!

Essa funcionalidade representa um grande avanço na prevenção contra o uso indevido de tokens de acesso, especialmente em ambientes corporativos ou virtuais onde o risco de comprometimento de sessões é maior.

✅ Com essa novidade, tokens roubados ou exportados não poderão mais ser reutilizados fora do dispositivo onde foram emitidos!

🔍 O que é Token Protection?

A Proteção de Tokens é um recurso do Microsoft Entra que vincula o token de acesso ao dispositivo original onde ele foi emitido. Isso significa que, mesmo que um atacante consiga interceptar um token, ele não conseguirá usá-lo em outro dispositivo.

Essa é uma defesa eficiente contra ataques como:

  • Replay de token

  • Pass-the-token

  • Uso indevido de sessões em VDIs comprometidos

🚀 Agora compatível com:

  • Azure Virtual Desktop (AVD)

  • Windows 365

  • Qualquer outro app corporativo rodando em Windows e integrado ao Entra ID

🛠️ Como configurar a política de Token Protection no Microsoft Entra

Abaixo, mostro o passo a passo completo para criar essa política de forma prática e segura:

1. Acesse o portal do Microsoft Entra

👉 https://entra.microsoft.com

Vá até Segurança > Acesso Condicional (Conditional Access).

2. Crie uma nova política

Clique em “Nova política” e dê um nome intuitivo, como:
📌 Token Protection - Windows Apps

3. Defina os usuários

Em “Usuários ou cargas de trabalho”, escolha quem será impactado:

  • Grupos de teste

  • Equipe de TI

  • Ou “Todos os usuários” (recomendado após validação)

4. Escolha os aplicativos

Em “Aplicativos ou ações”, selecione:

  • Azure Virtual Desktop

  • Windows 365

  • Ou outros aplicativos corporativos em uso

5. Adicione condições (opcional)

Exemplo de filtros:

  • Plataforma do dispositivo: Windows

  • Estado do dispositivo: Em conformidade

  • Local: Apenas acessos internos

6. Configure o controle de acesso

Na aba “Conceder” (Grant):

  • Marque ✅ “Requer proteção de token”

  • ✅ “Requer autenticação multifator (MFA)” (opcional)

💡 Se a opção "Token protection" não aparecer, seu tenant ainda pode não ter recebido a atualização.

7. Defina o modo de ativação

  • Para testar: selecione “Somente relatório” (Report-only)

  • Para aplicar: selecione “Ativado”

8. Salve e monitore

Após salvar a política, acompanhe os logs e relatórios para garantir que tudo esteja funcionando conforme esperado.

🔐 Segurança elevada sem impacto no usuário

A beleza dessa solução é que ela é transparente para o usuário — desde que o acesso ocorra a partir do dispositivo autorizado. É mais uma camada de proteção poderosa para sua organização, sem atrito para o colaborador.

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Otimize Custos e Segurança: Auditoria Fácil de Usuários e Licenças no Azure DevOps

Por que criei este script de auditoria para o Azure DevOps? Em meu trabalho diário com equipes que utilizam o Azure DevOps, percebi que muitos gestores e administradores enfrentam um desafio comum: controlar quem realmente está usando o ambiente, qual tipo de licença está ativa e, principalmente, quando foi a última vez que cada usuário acessou a plataforma. Em ambientes com múltiplas organizações e centenas de usuários, controlar quem realmente utiliza repositórios, pipelines e boards pode gerar uma economia significativa. Tudo isso de forma segura, sem modificar nada no ambiente, garantindo que a auditoria seja apenas informativa. Essa auditoria é essencial para manter a segurança, controlar custos e garantir conformidade. Pensando nisso, criei um script de auditoria que: O que o script verifica? Para cada usuário com licença Basic , o script checa: Commits em repositórios Git Execução de builds no Azure Pipelines Atividades nos Boards (work items modificados) Se o...
Postar um comentário
Leia mais

Auditoria de Usuários Ativos no Azure AD com Último Login e Tipo de Conta

Durante a gestão de ambientes em nuvem, é comum nos depararmos com contas de usuários que permanecem ativas, mesmo sem uso recente. Isso impacta diretamente no consumo de licenças e na postura de segurança da organização. Pensando nisso, desenvolvi um script em PowerShell utilizando o Microsoft Graph para facilitar auditorias de contas ativas no Azure AD , trazendo informações importantes como: Nome do usuário E-mail (UPN) Departamento e cargo Data de criação da conta Último login registrado Tipo de conta (nuvem ou sincronizada com AD local) O que o script faz? - Conecta-se ao Microsoft Graph com as permissões necessárias - Busca todos os usuários internos ativos (tipo "Member") - Verifica a última data de login registrada - Informa se a conta é nuvem (Cloud Only) ou sincronizada (On-Premises) - Exporta os dados para um relatório CSV ================================================================ # Script para auditoria de usuários ativos no Azure...
Postar um comentário
Leia mais

Auditoria no Azure AD: o risco oculto das caixas compartilhadas

Durante o planejamento de uma auditoria de contas no Azure AD, me deparei com um desafio importante: ao listar usuários Cloud-Only, percebi que caixas compartilhadas do Exchange Online também são exibidas como contas de usuário comuns no diretório . O problema: Shared Mailboxes que "parecem" usuários Quando criamos uma caixa compartilhada (Shared Mailbox) no Microsoft 365, o sistema cria automaticamente uma conta de usuário associada, com UPN e tudo. Mesmo após a conversão da caixa para o tipo "compartilhada", essa conta permanece visível no Azure AD e continua se comportando como uma conta Cloud-Only. Ou seja, se você estiver rodando um script ou fazendo uma auditoria manual para identificar contas inativas ou que devem ser excluídas, corre o risco de excluir acidentalmente uma caixa de e-mail ativa e compartilhada com outros times . A solução: auditoria com checagem de tipo de caixa Para evitar esse tipo de erro, desenvolvi um script em PowerShell que: Identi...
Postar um comentário
Leia mais