O Okta FastPass é o autenticador resistente a phishing da Okta, disponível para dispositivos iOS, macOS, Windows e Android. Há alguns anos, clientes nossos relataram que o FastPass não estava funcionando corretamente em determinados ambientes virtuais do Windows. Então, decidimos identificar e resolver os problemas. Foi um desafio interessante.
Neste artigo do blog, vamos falar sobre o Okta Verify e o FastPass para Windows. Vamos investigar por que isso não funcionou em certos ambientes virtuais e como os engenheiros da Okta resolveram os desafios técnicos de forma criativa para levar nosso autenticador para ambientes virtuais.
Para mais informações sobre o FastPass, confira nossa análise aprofundada do FastPass e nosso whitepaper técnico do FastPass.
Por que o FastPass não funcionou em ambientes virtuais?
O FastPass não funcionou bem em ambientes virtuais por dois motivos principais. O primeiro tinha a ver com algumas das dependências no dispositivo; o segundo, com a verificação do usuário com o Windows Hello. Vamos examinar cada um desses problemas em detalhes. Antes disso, porém, vamos analisar os tipos de ambientes virtuais e as diferenças entre eles.
O que são VDIs?
VDI significa “virtual desktop infrastructure” (infraestrutura de desktop virtual). É um termo que engloba qualquer infraestrutura de virtualização criada para que os usuários tenham acesso a uma máquina virtual em formato de desktop. O termo VDI pode se referir tanto à infraestrutura quanto ao desktop ao qual um usuário se conecta.
Tipos de VDIs
Existem três tipos principais de VDIs:
- Persistente
- Não persistente
- Em camadas
VDIs persistentes
Em uma VDI persistente, o estado do VDI e todos os dados do usuário são mantidos entre as sessões. Por exemplo, quando um usuário cria uma máquina virtual em seu notebook, ela funciona como uma VDI persistente. Cada vez que o usuário se conecta, o estado do desktop e todos os dados dele são preservados.
Em um ambiente onde há vários usuários e várias máquinas virtuais, o usuário costuma ser atribuído à máquina de forma estática. Isso significa que um usuário se conecta à mesma máquina virtual cada vez que faz login. Por essa razão, as VDIs persistentes também são às vezes chamadas de VDIs estáticas.
VDIs não persistentes
Em uma VDI não persistente, o estado da máquina virtual (incluindo todos os dados do usuário) não é mantido entre as sessões. A máquina virtual é apagada ou restaurada a partir de uma imagem mestre limpa entre as sessões. Na maioria dos ambientes, há um pool de máquinas virtuais novas a partir do qual a máquina do usuário é selecionada aleatoriamente. Em um ambiente de VDI não persistente, o usuário pode se conectar a uma máquina virtual diferente cada vez que faz login.
VDIs em camadas
Alguns provedores de infraestrutura oferecem um terceiro tipo de VDI, que é um híbrido entre a VDI persistente e a não persistente. Esses ambientes costumam ser divididos em camadas distintas. Existe uma camada de usuário, uma camada de aplicativo, uma camada de máquina etc. Por essa razão, chamamos esses ambientes de “VDIs em camadas”. Em um ambiente de VDI em camadas, o usuário se conecta a uma máquina virtual não persistente, mas um serviço de perfil do usuário sincroniza os dados dele para que sejam preservados entre as sessões. Assim como em um ambiente de VDI não persistente, o usuário pode se conectar a uma máquina virtual diferente a cada vez que faz login. Mas, assim como uma VDI persistente, seus dados são preservados entre as sessões.
Os ambientes de VDI em camadas são o tipo mais difícil de ambiente virtual para dar suporte, pois o usuário está efetivamente em roaming entre máquinas virtuais. Vamos nos concentrar nos desafios técnicos de dar suporte a VDIs em camadas e, em seguida, discutir brevemente quais desafios e soluções também foram usados para dar suporte a VDIs estáticas.
Suporte a VDIs em camadas
Para dar suporte a ambientes de VDI em camadas, havia quatro componentes do Okta Verify e do FastPass que precisavam ser abordados:
- A conta de serviço usada para proteger o par de chaves criptográficas de prova de posse
- Chaves criptográficas protegidas por TPM
- Credencial com persistência local do Okta Verify
- As informações de identificação do dispositivo relatadas ao back-end da Okta
Vamos dar uma olhada em cada um desses componentes em detalhes.
A conta de serviço do Okta Verify
Um dos pares de chaves criptográficas que o Okta Verify utiliza para autenticação é o par de chaves de prova de posse (PoP). A chave PoP pode ser usada para autenticação silenciosa de fator único, sem interação com o usuário. Portanto, ela deve ser protegida para garantir que outro processo na máquina não possa acessá-la nem usá-la sem o conhecimento do usuário. No passado, o Okta Verify criava uma conta local do Windows que era usada para proteger a chave (PoP). Chamamos essa conta de serviço Okta Verify ou conta sandbox. O Okta Verify personifica a conta de serviço durante as operações da chave PoP. Como essa conta é uma conta do usuário local, ela não pode ser transferida com o usuário entre máquinas virtuais em um ambiente de VDI em camadas.
Nossa solução: para proteger a chave PoP em ambientes virtuais, utilizamos a proteção de chave por código de acesso. Ao iniciar o aplicativo, o Okta Verify deriva um código de acesso para proteção de chave. Quando o Okta Verify cria uma chave PoP usando as APIs Win32, usamos a função NCryptSetProperty com o identificador NCRYPT_PIN_PROPERTY para definir a propriedade PIN no identificador de chave. Em seguida, fornecemos nosso código de acesso para proteção de chave. A definição dessa propriedade instrui o sistema operacional a criar uma chave que é protegida por nosso código de acesso para proteção de chave. Após a criação, quando a chave é usada, a senha correta deve ser fornecida. Isso impede que outros processos na máquina carreguem e usem a chave PoP, pois eles não possuem nosso código de acesso para proteção da chave.
Chaves criptográficas protegidas por TPM
O Okta Verify protege as chaves criptográficas que cria com o Trusted Platform Module (TPM) da máquina, se estiver disponível. Mesmo em muitos ambientes virtuais, o Okta Verify protegerá as chaves com o TPM, já que muitos ambientes virtuais possuem TPMs virtuais. No entanto, em um ambiente de VDI em camadas, o Okta Verify não pode usar o TPM para proteger suas chaves. Quando o Okta Verify protege suas chaves com um TPM, essas chaves são criptograficamente vinculadas a esse TPM. Se o Okta Verify for movido para uma máquina diferente com um TPM diferente, como é o caso em um ambiente de VDI em camadas, ele não conseguirá acessar as chaves que criou e não conseguirá autenticar o usuário.
Nossa solução: em ambientes de VDI em camadas, o Okta Verify armazena suas chaves criptográficas em um provedor de armazenamento de chaves de software em formato não exportável. O provedor de armazenamento de chaves de software é fornecido e implementado pelo sistema operacional Windows, que armazena as chaves como um arquivo no diretório do usuário. Quando o serviço de sincronização de perfil do usuário da VDI em camadas sincroniza o diretório do usuário, todas as chaves do usuário armazenadas no armazenamento de chaves de software serão sincronizadas. Consulte a documentação de armazenamento de chaves da Microsoft para mais informações.
A credencial do Okta Verify
O Okta Verify armazena uma credencial de aplicativo no Windows Credential Manager, que é usado para proteger os recursos do aplicativo. O Okta Verify sempre definia a propriedade Persist na credencial como CRED_PERSIST_LOCAL_MACHINE, o que persistiria a credencial na máquina local. Uma credencial com persistência local não pode ser acessada pelo Okta Verify em uma máquina virtual diferente.
Nossa solução: para permitir que a credencial se mova com o perfil do usuário entre máquinas virtuais em um ambiente de VDI em camadas, definimos a propriedade Persist como CRED_PERSIST_ENTERPRISE.
Informações do dispositivo
O Okta Verify coleta duas informações de identificação do dispositivo que são reportadas ao back-end da Okta:
- O nome do dispositivo
- O identificador de segurança (SID) do dispositivo
Em ambientes de VDI em camadas, ambos os identificadores de dispositivo podem mudar entre as sessões, o que pode causar comportamentos inesperados, como falhas na autenticação.
Nossa solução: para reportar identificadores de dispositivo consistentes em ambientes de VDI em camadas, usamos o SID do usuário como o identificador base, uma vez que ele não mudará entre as sessões. A partir dele, derivamos um nome de dispositivo e o reportamos diretamente como o SID do dispositivo.
Depois que abordamos cada um desses itens, o Okta Verify ficava pronto para ambientes virtuais. Mas o FastPass ainda não estava totalmente pronto. Como os usuários ainda não conseguiam concluir a verificação do usuário, tínhamos trabalho a fazer.
Verificação do usuário (UV) em ambientes virtuais
A verificação do usuário é o processo pelo qual um autenticador (por exemplo, Okta FastPass) verifica se o usuário está presente e é quem ele declara ser.
O FastPass utiliza o Windows Hello para a verificação do usuário, permitindo que ele confirme sua identidade com um PIN ou verificação biométrica. No entanto, a maioria das máquinas virtuais não possui o Windows Hello. Para permitir que os usuários concluam a autenticação de dois fatores com a verificação do usuário em ambientes virtuais, apresentamos o recurso Okta Verify Passcode.
Inscrição no FastPass
Durante a inscrição no FastPass, o usuário precisa criar uma senha de oito dígitos dentro do Okta Verify.
Quando o Okta Verify cria o par de chaves de verificação criptográfica do usuário, utilizamos as mesmas APIs Win32 para configurar a propriedade NCRYPT_PIN_PROPERTY no identificador da chave, fornecendo o código de acesso do usuário como valor. Isso significa que a chave de verificação do usuário só pode ser acessada quando o código de acesso do usuário for fornecido. O Okta Verify não armazena o código de acesso do usuário. Ele simplesmente o transfere para o sistema operacional por meio das APIs Win32.
Autenticação do FastPass
Durante a autenticação, o Okta Verify solicita que o usuário insira seu código de acesso para concluir a verificação.
Quando o Okta Verify carrega a chave de verificação do usuário para assinar o JWT de desafio de autenticação, mais uma vez definimos a NCRYPT_PIN_PROPERTY no identificador da chave, fornecendo o código de acesso que o usuário forneceu. O sistema operacional lida com a verificação para garantir que o usuário forneceu o código de acesso correto.
Senha incorreta
Se o usuário inserir um código de acesso incorreto, ele terá no máximo mais duas tentativas antes que a solicitação de autenticação falhe.
Como o Okta Verify não armazena o código de acesso do usuário, ele não pode detectar diretamente um código de acesso incorreto. Em vez disso, ele lida com erros do provedor de armazenamento de chaves para determinar quando o código de acesso inserido pelo usuário está incorreto e, em seguida, mostra o erro de "código de acesso incorreto" ao usuário. O desafio é que o erro retornado varia de acordo com o provedor de armazenamento de chaves.
Quando a chave é armazenada no provedor de software, o código de erro NTE_INCORRECT_PASSWORD (0x80090033) é retornado ao abrirmos a chave e definirmos a propriedade NCRYPT_PIN_PROPERTY no identificador da chave com um valor incorreto. Isso nos permite detectar facilmente quando o usuário inseriu um código de acesso incorreto.
No entanto, o comportamento do TPM é diferente. Primeiro, nenhum código de erro é retornado quando a chave é aberta e a NCRYPT_PIN_PROPERTY é definida no identificador da chave com um valor incorreto. Em vez disso, um código de erro é retornado posteriormente quando o identificador da chave é usado, por exemplo, para hash de alguns dados. Segundo, o código de erro retornado não é NTE_INCORRECT_PASSWORD, mas sim NTE_PERM (ou seja, acesso negado, 0x80090010).
Como o erro de acesso negado é um erro genérico que pode ser levantado em uma variedade de outros contextos, não podemos simplesmente lidar com todos os erros de acesso negado como tentativas incorretas de senha pelo usuário. Em vez disso, temos que lidar com erros de acesso negado com base no contexto da operação. Se recebermos o erro de acesso negado ao tentar usar uma chave de verificação de usuário que sabemos estar protegida por uma senha fornecida pelo usuário, então lidamos com ele como um erro de senha incorreta e permitimos que o usuário reinsira sua senha.
Suporte a VDIs estáticos
O suporte para VDIs estáticas era muito mais fácil. Elas funcionam de forma muito semelhante às máquinas físicas. Depois que resolvemos os desafios no suporte a VDIs em camadas, conseguimos reutilizar algumas das soluções para dar suporte a VDIs estáticas. O principal desafio no suporte a uma VDI estática é a verificação do usuário. Para resolver isso, utilizamos o Okta Verify Passcode para a verificação de usuários em VDIs estáticas.
Uma nota sobre o suporte para VDIs não persistentes
O Okta Verify não é compatível com VDIs não persistentes, pois nenhum dado do usuário persiste entre as sessões, incluindo os dados do Okta Verify do usuário. Se um usuário tentasse se inscrever no FastPass em uma VDI não persistente, sua inscrição seria perdida após fazer logoff e entrar novamente na VDI.
Configuração do Okta Verify para ambientes virtuais
Para permitir que os administradores configurem o Okta Verify para ambientes virtuais, adicionamos um novo sinalizador de configuração chamado AuthenticatorOperationMode. Ele tem três valores:
- Normal
- VirtualDesktopStatic
- VirtualDesktopLayered
Consulte nossa documentação para mais informações sobre como configurar o Okta Verify para ambientes virtuais.
Para permitir que os administradores configurem o Okta Verify para usar o Okta Verify Passcode para verificação de usuário, adicionamos um novo sinalizador de instalação chamado UserVerificationType. Ele tem dois valores:
- Windows Hello
- OktaVerifyPasscode
Para facilitar a vida do administrador, ajustamos o valor padrão do sinalizador UserVerificationType com base no valor fornecido para o sinalizador AuthenticatorOperationMode.
- Quando o modo é Normal, o UserVerificationType é definido por padrão como Windows Hello
- Quando o modo é VirtualDesktopStatic ou VirtualDesktopLayered, o UserVerificationType usa OktaVerifyPasscode por padrão
Para configurar o Okta Verify para ser executado em um ambiente virtual e usar o Okta Verify Passcode para a verificação de usuários, o administrador precisa apenas definir corretamente o AuthenticatorOperationMode, e o UserVerificationType será configurado automaticamente como Okta Verify Passcode.
Consulte nossa documentação para mais informações sobre como configurar o tipo de verificação de usuário no Okta Verify.
Uma observação sobre os novos sinalizadores do instalador
Como os sinalizadores de instalação AuthenticatorOperationMode e UserVerificationType alteram a funcionalidade principal do Okta Verify, os valores deles são definidos uma única vez durante a instalação. Qualquer alteração nesses valores após a instalação não entra em vigor. Isso é necessário para evitar que o Okta Verify funcione incorretamente. No entanto, alguns clientes expressaram recentemente interesse em migrar seus usuários de um tipo de verificação de usuário para outro após a instalação.
Okta Verify Passcode no lugar do Windows Hello em máquinas físicas
Às vezes, os administradores não querem que seus usuários usem o Windows Hello; às vezes os usuários não podem usar o Windows Hello, mesmo em máquinas físicas. Por isso, criamos o recurso Okta Verify Passcode para funcionar também em máquinas físicas. O UserVerificationType pode ser configurado independentemente do AuthenticatorOperationMode para habilitar a verificação do usuário com o Okta Verify Passcode em máquinas físicas.
Consulte nossa documentação para mais informações.
Experimente
Acho interessante? Experimente. Você pode instalar a versão mais recente do Windows Okta Verify baixando-a no painel de administração. Siga nossas instruções para configurar o Okta Verify para ambientes virtuais e para configurar o tipo de verificação de usuário.
Tem perguntas sobre este artigo no blog? Entre em contato conosco pelo e-mail eng_blogs@okta.com.
Confira mais blogs de engenharia da Okta para expandir seu conhecimento.
Quer se juntar à nossa equipe apaixonada de engenheiros excepcionais? Visite nossa página de carreiras.
Aproveite o potencial do gerenciamento de identidade moderno e sofisticado para sua organização. Entre em contato com o departamento de vendas para mais informações.
