Windows Hello para Empresas, chaves de hardware e SSO (Single Sign-On).

Se você gerencia identidades em ambientes Microsoft, provavelmente já ouviu falar de Windows Hello, Windows Hello para Empresas, teclas Hardwares e SSOMas é fácil se perder em meio a tantas siglas, tipos de confiança e requisitos. Além disso, em implantações híbridas com o Active Directory legado, entender o que o WHfB realmente oferece em comparação com um simples PIN ou login biométrico pode ser a diferença entre um projeto tranquilo... ou uma constante dor de cabeça.

Neste artigo, vamos detalhar minuciosamente como isso funciona. Windows Hello para Empresas (WHfB): qual o papel das teclas de hardware e como é implementado o logon único (SSO)? e como ele difere do Windows Hello "normal" para usuários domésticos. Analisaremos as fases internas (registro de dispositivo, provisionamento, sincronização de chaves, certificados e autenticação), modelos de implantação (somente em nuvem, híbrido e local), tipos de confiança, requisitos de PKI, licenciamento, desafios de implantação no mundo real e como tudo isso se encaixa com abordagens modernas como FIDO2 e segurança sem senha.

Windows Hello vs Windows Hello para Empresas: O que realmente muda?

O Windows Hello (em termos simples) é a experiência do usuário para fazer login com um PIN ou biometria. Em um dispositivo Windows, projetado para ambientes domésticos e profissionais. O Windows Hello para Empresas (WHfB), por outro lado, é a extensão empresarial que adiciona recursos robustos de identidade integrados ao Active Directory e ao Microsoft Entra ID.

Com ambos os métodos você pode usar PIN, impressão digital ou reconhecimento facial suportados pelo TPM para fazer login no computador. Você pode até mesmo autenticar em um domínio local clássico. A grande diferença é que o WHfB cria e gerencia credenciais criptográficas de nível empresarialPares de chaves ou certificados vinculados ao usuário e ao dispositivo, gerenciados por políticas e utilizáveis ​​para SSO em recursos locais e na nuvem.

Embora o Windows Hello "normal" seja essencialmente limitado a Substitua a senha por um gesto prático nesse dispositivo.O WHfB gera uma credencial forte que o provedor de identidade (AD, Microsoft Entra ID ou AD FS) reconhece, armazena e usa para emitir tokens de acesso e aplicar a segurança. Acesso condicional, validação rigorosa do KDC, PRT, Kerberos na nuvem e outros controles avançados.

A pergunta lógica é: se eu já tenho dispositivos ingressados ​​no domínio, gerenciados com o Intune, com TPM e biometria, e SSO para a nuvem via sincronização de hash de senha, O que exatamente eu ganho ao adicionar o WHfB? A resposta está em como as chaves são criadas e validadas, como o dispositivo é conectado e na capacidade de estender essa segurança a todo o ecossistema, não apenas ao login local.

Arquitetura básica: fases do Windows Hello para Empresas

WHfB é um sistema distribuído que depende de vários componentes: Dispositivo, TPM, provedor de identidade, PKI, sincronização de diretório e mecanismos de SSO.Para compreendê-lo sem se perder, é útil dividir seu funcionamento em cinco fases cronológicas de implementação.

1. Registro do dispositivo

A primeira peça do quebra-cabeça é a Registro do dispositivo junto ao provedor de identidade (IdP)Esta etapa permite associar o dispositivo a uma identidade no diretório e habilitá-lo para autenticação automática quando um usuário fizer login.

Em ambientes exclusivamente em nuvem ou híbridos, O IdP é a Microsoft. Insira o ID. e o dispositivo se registra em seu serviço de registro de dispositivos (associado ao Microsoft Entra, associado de forma híbrida ou registrado). Em cenários puramente locais, o IdP é normalmente AD FS com seu Serviço de Registro de Dispositivos Corporativos.

Após a conclusão deste cadastro, o IdP designa a equipe. Uma identidade única que será usada para estabelecer a confiança no diretório de dispositivos. em autenticações sucessivas. Este registro é classificado por “tipo de associação do dispositivo”, que determina se o dispositivo está associado a um domínio local, ao Entra ID, é híbrido ou simplesmente está registrado como pessoal.

2. Provisionamento: criação do contêiner do Windows Hello

Assim que o dispositivo for registrado, a fase começa. Provisionamento de credenciais do Windows Hello para empresasÉ aqui que é criado o chamado contêiner Windows Hello, que agrupa logicamente todo o material criptográfico do usuário naquele computador.

O fluxo de compras típico segue estas etapas principais, sempre seguindo um autenticação inicial Com credenciais fracas (nome de usuário e senha):

• O usuário se autentica com MFA no IdP. (Microsoft Insira MFA ou outro método compatível, ou um adaptador MFA no AD FS em ambientes locais).
• Após superar esse segundo fator, você será solicitado a configurar um PIN e, se houver hardware compatível disponível, um gesto biométrico. (pegada, rosto, íris).
• Após a confirmação do PIN, o Windows gera o Contêiner do Windows Hello para aquela conta naquela equipe.
• Dentro desse recipiente, um par de chaves criptográficas (pública e privada), vinculado ao TPM quando este existir ou, na sua falta, protegido por software.
• La A chave privada permanece no dispositivo e não pode ser exportada., permanecendo protegido pelo TPM e pelos protetores PIN/biométricos.
• La A chave pública está registrada no IdP. e está vinculado ao objeto do usuário: no ID de login da Microsoft, ele é gravado no usuário e, em cenários locais federados, o AD FS o transfere para o Active Directory.

O recipiente também inclui um chave administrativaIsso é útil em cenários como a redefinição de PIN; em dispositivos com TPM, um bloco de dados contendo certificados TPM também é armazenado. Todo o material é desbloqueado somente quando o usuário realiza o gesto (PIN ou biometria), e essa combinação inicial de MFA estabelece a confiança entre o usuário, o dispositivo e o IdP.

3. Chaves dentro do contêiner: autenticação e identificador do usuário

Dentro do contêiner do Windows Hello, encontramos vários tipos de chaves, com diferentes funções, todas elas. Criptografado com proteção baseada em PIN ou biométrica:

• Chave de autenticaçãoUm par de chaves assimétricas geradas durante o cadastro que devem sempre ser desbloqueadas com um PIN ou gesto biométrico. É a base sobre a qual outros materiais são reciclados quando o PIN é alterado.
• Chaves de identificação do usuárioAs chaves de identidade podem ser simétricas ou assimétricas, dependendo do Provedor de Identidade (IdP) e do modelo (chave ou certificado). Elas são usadas para assinar ou criptografar solicitações e tokens direcionados ao provedor de identidade. Em ambientes corporativos, geralmente são geradas como pares de chaves assimétricas, com a chave pública registrada no IdP.

Essas chaves de identificação do usuário podem ser obtidas de duas maneiras principais: associado à PKI corporativa para emitir certificados (por exemplo, para VPN, autenticação RDP ou Kerberos baseada em certificado) ou gerada diretamente pelo IdP em cenários sem PKI (modelo de chave pura).

A mesma infraestrutura permite o uso de Windows Hello como autenticador FIDO2/WebAuthn Em aplicativos e sites compatíveis. Os sites podem criar uma credencial FIDO dentro do contêiner do Windows Hello; em visitas subsequentes, o usuário se autentica com seu PIN ou biometria sem expor senhas.

4. Sincronização de teclas em ambientes híbridos

Em arquiteturas híbridas onde coexistem ID de login da Microsoft e Active DirectorySimplesmente registrar a chave na nuvem não é suficiente. Após o provisionamento, a chave pública do WHfB deve ser sincronizada com o diretório local para ser habilitada. Autenticação e SSO em recursos locais.

Nesses cenários, o Microsoft Entra Connect Sync cuida de tudo. Copie a chave pública para o atributo msDS-KeyCredentialLink. do objeto de usuário no Active Directory. Essa sincronização é fundamental para que o controlador de domínio possa validar as assinaturas geradas pelo dispositivo com a chave privada armazenada no TPM.

5. Registro de certificados (somente quando necessário)

Em alguns modelos (como o certificado de confiançaAlém das chaves, a organização precisa emitir certificados de autenticação para os usuários. Nesse caso, uma fase adicional é ativada. registro de certificados.

Após registrar a chave pública, o cliente gera um solicitação de certificado que envia a solicitação para a autoridade de registro de certificados, normalmente integrada ao AD FS em implantações federadas. Essa CRA valida a solicitação usando a PKI corporativa e Ele emite um certificado que é armazenado dentro do contêiner Hello., reutilizável para autenticação em recursos locais que ainda dependem de certificados.

Autenticação, chave privada e SSO: como tudo se encaixa

Após a conclusão das fases de registro e provisionamento, o dia a dia do usuário se resume a algo muito simples: Um gesto (PIN ou biometria) que "libera" a chave privada no dispositivo.O interessante é o que acontece nos bastidores.

Quando o usuário desbloqueia o computador, o Windows usa a parte privada da credencial WHfB para assinar criptograficamente os dados enviados ao IdPIsso verifica a assinatura usando a chave pública armazenada no objeto do usuário. Como o PIN nunca sai do dispositivo, nem a chave privada, o processo é resistente a phishing e roubo de credenciais tradicional.

Nos cenários de entrada de ID da Microsoft, concluir essa autenticação resulta em um Token de atualização primária (PRT)Um token web JSON contendo informações do usuário e do dispositivo. É a base do SSO para aplicativos em nuvem e, em combinação com o Microsoft Kerberos ou sincronização de chaves, também para recursos locais.

Sem o PRT, mesmo que o usuário possua uma credencial WHfB válida, Eu perderia o login único. e seriam obrigados a se autenticar continuamente em cada aplicativo. É por isso que as políticas de acesso condicional, sejam baseadas em dispositivo ou em risco, geralmente levam em consideração a presença e a validade desse PRT.

Para o Active Directory, ao usar a confiança de chave ou certificado, o WHfB atua como um... cartão inteligente virtualO usuário assina um nonce ou desafio do KDC, o controlador de domínio valida o certificado ou a chave e emite um ticket TGT do Kerberos, permitindo assim o SSO para serviços locais integrados ao Kerberos.

Segurança interna: biometria, TPM e proteção contra ataques.

Um dos pilares do WHfB é que o Os dados biométricos nunca saem do dispositivo.Os modelos gerados pelos sensores são armazenados localmente em bases de dados criptografado (por exemplo, no caminho C:\WINDOWS\System32\WinBioDatabase) usando chaves exclusivas por banco de dados, protegido com AES no modo CBC e SHA-256 como função de hash.

Isso significa que, mesmo que um invasor consiga obter acesso a esses arquivos, Não consegui reconstruir a imagem do rosto ou da impressão digital do usuário.Além disso, não podem ser usados ​​em outro dispositivo. Cada sensor mantém seu próprio armazenamento, reduzindo a possibilidade de um ponto central de roubo de modelos biométricos.

O PIN do Windows Hello para Empresas também é mais bem protegido do que uma senha tradicional. Ele não trafega pela rede, é validado localmente e o TPM (Terminal Protection Manager) aplica as medidas de segurança. bloqueios devido a muitas tentativas incorretasIsso torna os ataques de força bruta ou de dicionário inúteis. E se alguém roubar o PIN, ele só funcionará naquele dispositivo específico, já que a credencial está vinculada ao hardware.

Enfrentando ameaças modernas (Como identificar se um e-mail é de phishing(reutilização de senhas, roubo em massa de credenciais), o WHfB depende de Criptografia de chave pública vinculada a dispositivosIsso evita, por princípio, a exposição de segredos compartilhados. Tal abordagem está perfeitamente alinhada com os padrões e recomendações de regulamentações como a NIST 800-63B e com modelos de segurança de confiança zero.

Modelos de implantação: nuvem, híbrido e local

O WHfB é flexível em termos de topologia, mas essa flexibilidade traz consigo uma certa complexidade. De modo geral, podemos falar de três modelos de implantação que se combinam de diferentes maneiras. Microsoft Entra ID, Active Directory, PKI e federação.

Modelo exclusivamente em nuvem

Em organizações que vivem quase 100% em Microsoft 365 e outros serviços SaaS, sem a infraestrutura local relevante, o modelo mais simples é o de Somente na nuvem, com dispositivos conectados à Microsoft. Faça login.Neste cenário:

• Todos os usuários e dispositivos residem em ID de entrada da Microsoft.
• O registro do dispositivo e da chave é feito diretamente na nuvem.
• Não é necessário nenhum PKI empresarial. nem certificados de controlador de domínio.
• O SSO é baseado em tokens PRT e Microsoft Entra para aplicativos.

É a opção mais direta para empresas que priorizam a nuvem, com baixo custo de infraestrutura e implantação relativamente simplesIdeal para situações em que os recursos locais não estão disponíveis ou são mínimos.

Modelo híbrido: o caso mais comum

A grande maioria das empresas está algures entre estes dois extremos: Histórico do Active Directory combinado com ID de login da Microsoft sincronizadoO WHfB se destaca nesse aspecto, mas é também onde os problemas de configuração são mais comuns, caso não haja um bom planejamento.

Em um ambiente híbrido, as identidades são sincronizadas com o Microsoft Entra Connect Sync, e existem diversas combinações possíveis de Modelo de implantação (híbrido) e tipo de confiança (Kerberos na nuvem, chave ou certificado)O objetivo geralmente é oferecer:

• SSO para serviços em nuvem (SharePoint Online, Teams, aplicações OIDC/SAML).
• Acesso transparente aos recursos locais (ações, Aplicativos Kerberos, VPN, RDP).
• Uma rota de saída gradual para senhas, mantendo os aplicativos legados.

Os principais tipos de confiança em cenários híbridos são:

• Kerberos na nuvemO Microsoft Entra Kerberos emite TGTs para o Active Directory sem exigir uma Infraestrutura de Chaves Públicas (PKI) adicional. Este é o modelo híbrido mais moderno e simples, pois aproveita a infraestrutura FIDO2 existente e não requer a sincronização de chaves públicas com o Active Directory.
• Key TrustOs usuários se autenticam no Active Directory usando uma chave vinculada ao dispositivo; os controladores de domínio exigem certificados específicos. A Infraestrutura de Chaves Públicas (PKI) é necessária para os controladores de domínio, mas não para os certificados de usuário.
• Certificado de confiançaOs certificados de autenticação de usuário são emitidos e usados ​​para obter TGTs do Kerberos. Isso requer uma PKI completa, o AD FS como um CRA e uma configuração mais complexa.

Escolher o tipo certo de confiança é crucial: Nenhuma é inerentemente “mais segura”.No entanto, variam em custo, complexidade e requisitos de infraestrutura. Utilizar o Kerberos na nuvem costuma ser a melhor opção para novas implementações, desde que as versões do Windows do cliente e do servidor atendam aos requisitos mínimos.

Modelo local puro

Organizações com fortes restrições regulatórias, ou com pouca ou nenhuma adoção da nuvem, podem optar por uma implementação do WHfB. 100% local, com suporte do Active Directory e do AD FS.Neste modelo:

• O registro do dispositivo é gerenciado. AD FS.
• A autenticação pode ser baseada em chave ou em certificado, mas é sempre respaldada por uma PKI empresarial.
• As opções de MFA incluem adaptadores para AD FS ou soluções como o Azure MFA Server (já legado) integrado localmente.

Essa abordagem proporciona uma controle total sobre os dados de autenticaçãoNo entanto, isso exige um esforço considerável de manutenção (PKI, AD FS, publicação de CRLs acessíveis por computadores que não fazem parte do domínio, etc.), algo que nem todas as organizações estão dispostas a assumir a longo prazo.

Infraestrutura de chave pública (PKI) acessível, certificados de controlador de domínio e listas de revisão de certificados (CRLs).

Em modelos que dependem de certificados (sejam eles para usuários, controladores de domínio ou ambos), a PKI torna-se o núcleo da confiança. O WHfB exige Validação rigorosa de KDCs Quando um dispositivo se conecta à Microsoft, ele se autentica em um domínio local.

Na prática, isso significa que o certificado do controlador de domínio deve atender a uma série de condições técnicas: Emitido por uma CA raiz confiável para o dispositivo, com base no modelo de autenticação Kerberos, com EKU "Autenticação KDC", nome DNS correto, RSA 2048 e SHA-256 como algoritmo de assinatura.entre outros requisitos.

Além disso, é essencial que o dispositivo possa verificar a revogação dos certificadosAqui reside o problema clássico das CRLs: um dispositivo conectado apenas ao Microsoft Entra não consegue ler os caminhos LDAP no Active Directory se ainda não tiver sido autenticado, sendo necessário, portanto, publicar o ponto de distribuição da CRL em um URL HTTP acessível sem autenticação.

Isso envolve preparar um servidor web (IIS, por exemplo), criar um diretório virtual (cdp) e ajustar as permissões. NTFS e, a partir de recursos compartilhados, desative o armazenamento No cache offline, configure a CA para publicar a CRL nesse recurso compartilhado e expô-la via HTTP. Feito isso, você precisa... Renovar certificados de controlador de domínio Incluir o novo CDP e garantir que o certificado raiz corporativo seja implementado em dispositivos conectados ao Microsoft Entra (por exemplo, com o Intune e um perfil de "certificado confiável").

Sincronização de diretórios, MFA e configuração de dispositivos

A experiência do usuário final com o Windows Hello para Empresas depende em grande parte de Como a sincronização de diretórios, a MFA e a configuração de políticas são integradas.

Em implantações híbridas, o Microsoft Entra Connect Sync não apenas sincroniza contas; ele também pode sincronizar atributos críticos como msDS-KeyCredentialLinkque contém a chave pública WHfB necessária para autenticação no Active Directory. Em ambientes locais com o Azure MFA Server, a sincronização é usada para importar usuários para o servidor MFA, que então consulta o serviço em nuvem para verificação.

Em relação à autenticação multifator, as organizações têm diversas opções: Microsoft Entra MFA para cenários de nuvem ou híbridosMétodos externos integrados por meio de autenticação externa no Entra ID ou via federação, e adaptadores MFA de terceiros para AD FS em ambientes locais. O sinalizador FederatedIdpMfaBehavior em domínios federados determina se o Entra ID aceita, exige ou ignora a MFA realizada pelo IdP federado, o que pode ser crucial para o funcionamento correto do provisionamento do WHfB.

A configuração WHfB no equipamento pode ser feita com Política de grupo (GPO) ou CSP via MDM (por exemplo, Intune). Em organizações modernas, é comum habilitar o registro automático no WHfB, exigir MFA no primeiro login, definir políticas de complexidade de PIN e controlar quais métodos biométricos são aceitos (somente sensores certificados, câmeras infravermelhas, etc.).

Em paralelo, é essencial considerar a experiência de recuperação: redefinição de PIN por autoatendimento, métodos alternativos como chaves FIDO2 e Criptografia BitLocker Para proteger os dados armazenados em repouso caso o dispositivo seja perdido ou roubado.

Licenças, requisitos de sistema e limitações práticas.

Um dos mitos mais comuns é que você sempre precisa usar o WHfB. Microsoft Inserir ID P1 ou P2Na realidade, a funcionalidade principal do WHfB está disponível no plano gratuito Entra ID, e a autenticação multifator necessária para o provisionamento sem senha também pode ser ativada sem licenças premium, embora recursos como inscrição automática em MDM, acesso condicional avançado ou gravação adiada em dispositivos exijam planos superiores.

Em termos de sistema operacional, praticamente todas as versões modernas do Windows para clientes são compatíveis com o WHfB, mas o A confiança no Kerberos na nuvem exige mínimos concretos. (por exemplo, Windows 10 21H2 com determinados patches ou versões específicas de Windows 11Do lado do servidor, qualquer versão compatível do Windows Server geralmente pode funcionar como um controlador de domínio, embora a parte do Kerberos na nuvem exija versões e atualizações específicas nos controladores de domínio.

Além dos aspectos técnicos, existem desafios muito práticos: equipamentos compartilhados onde O WHfB, por ser específico para cada dispositivo e usuário, se encaixa regularmente.; hardware sem TPM 2.0 ou sensores biométricos; ou ambientes onde o custo de renovação de frotas antigas, implantação de PKI e atualização de data centers de 2012 torna a adoção completa do WHfB pouco atrativa no curto prazo.

Em alguns casos, o caminho razoável envolve Combine o WHfB com outros fatores que não exigem senha. (Chaves FIDO2, cartões inteligentes, autenticação por telefone) para abranger estações de trabalho compartilhadas, plataformas não Windows ou usuários altamente móveis, deixando o WHfB como o autenticador principal em laptops Empresas vinculadas à Entra ou híbridas.

Considerando o panorama geral, o Windows Hello para empresas oferece muito mais do que "um PIN simpático": ele introduz Credenciais assimétricas vinculadas a hardware, verificação rigorosa do KDC, integração profunda com o Microsoft Entra ID e o Active Directory, e uma estrutura robusta para SSO seguro. tanto na nuvem quanto em infraestruturas locais. No entanto, seu valor real em comparação com o Windows Hello básico depende do ponto de partida: em ambientes modernos, com foco em nuvem ou híbridos, com PKI e data centers atualizados, o salto em segurança e gerenciamento claramente supera o esforço; em domínios muito antigos, com pouca infraestrutura preparada e sem planos de modernização, pode ser mais sensato investir primeiro em hardware, PKI e controle de acesso antes de explorar todo o potencial do WHfB.

Artigo relacionado:

Como saber quais aplicativos têm acesso à sua câmera, microfone ou localização no Windows 11

Isaac

Escritor apaixonado pelo mundo dos bytes e da tecnologia em geral. Adoro compartilhar meu conhecimento por meio da escrita, e é isso que farei neste blog, mostrar a vocês tudo o que há de mais interessante sobre gadgets, software, hardware, tendências tecnológicas e muito mais. Meu objetivo é ajudá-lo a navegar no mundo digital de uma forma simples e divertida.