MyQ Desktop Client

O MyQ Desktop Client emprega mecanismos de segurança robustos para garantir comunicação segura, autenticação e integridade dos dados em ambientes de impressão corporativos. Este documento detalha os protocolos, métodos de autenticação e melhores práticas de configuração que sustentam a arquitetura de segurança do Desktop Client, com foco na criptografia TLS, na Autenticação Integrada do Windows (IWA), no Kerberos, no NTLM e na integração com o Entra ID. Implementações técnicas, como o registro do Nome Principal do Serviço (SPN), o gerenciamento de certificados e os fluxos de login silencioso, são analisadas para demonstrar a conformidade com os padrões modernos de segurança.

Arquitetura de Comunicação Segura

Criptografia TLS por padrão

Os servidores de impressão e centrais impõem a criptografia1.2+ TLS para todos os canais de comunicação, incluindo interações com o Cliente de Desktop. Isso garante a confidencialidade e a integridade dos dados durante o spooling de trabalhos, a autenticação e a geração de relatórios. Os administradores devem configurar pontos de extremidade HTTPS usando Nomes de Domínio Totalmente Qualificados (FQDNs) para evitar ataques do tipo “man-in-the-middle” (MITM).

Modos de validação de certificados

• Modo estrito: exige que os certificados do servidor sejam emitidos por uma Autoridade Certificadora (CA) confiável ou adicionados manualmente ao armazenamento de confiança do sistema. As tentativas de conexão falham se a validação falhar. Recomendamos o uso do modo estrito sempre que possível.

• Modo Normal: permite que os usuários ignorem avisos de certificados não confiáveis, com os certificados aceitos armazenados %ProgramData%\MyQ\Desktop Client\cert.store para sessões futuras.

Mecanismos de autenticação

Autenticação Integrada do Windows (IWA)

A IWA permite uma autenticação contínua em ambientes associados a um domínio usando Kerberos ou NTLM. O servidor utiliza a API do Servidor HTTP do Windows (http.sys) para processar solicitações HTTP recebidas e validar Nomes Principais de Serviço (SPNs), garantindo a integridade do protocolo.

Fluxo de trabalho do Kerberos

1. Aquisição do Ticket de Concessão de Ticket (TGT): Clientes integrados ao domínio obtêm um TGT do Centro de Distribuição de Chaves (KDC).

2. Solicitação de Ticket de Serviço: O cliente solicita um ticket de serviço HTTP/<FQDN> do KDC.

3. Validação do token: o MyQ Server valida o ticket de serviço em relação ao SPN registrado.

Configuração crítica:

• O servidor deve ter um SPN configurado corretamente para que a autenticação Kerberos funcione adequadamente.

• O acesso por meio de endereços IP ignora o Kerberos, forçando o uso do NTLM como alternativa.

Recurso de fallback do NTLM

O NTLM funciona como um recurso alternativo em cenários fora do domínio ou baseados em IP. Embora seja menos seguro, ele utiliza um mecanismo de desafio-resposta com hash da senha do usuário. Para aplicar exclusivamente o Kerberos, siga a sugestão acima.

Login silencioso do Entra ID

Para dispositivos integrados ao Entra ID ou híbridos, o Desktop Client utiliza a Biblioteca de Autenticação da Microsoft (MSAL) e o Gerenciador de Autenticação do Windows (WAM) para adquirir tokens silenciosamente por meio da conta do sistema operacional. O fluxo envolve:

1. Aquisição de token: a MSAL recupera um token de identificação usando o WAM.

2. Troca de token: o token de identificação é trocado por um token de acesso do MyQ para autenticar chamadas da API REST.

Fluxo de código de autorização OAuth 2.0

Para ambientes que não sejam Windows, o Desktop Client oferece suporte ao OAuth 2.0 por meio do authorization_code grant:

1. Redirecionamento do usuário: O cliente redireciona os usuários para a página de login do MyQ.

2. Troca de código: Após a autenticação, o código de autorização é trocado por um token de acesso.

Gerenciamento de certificados

Certificados raiz confiáveis

• Modo estrito: os certificados devem estar pré-instalados no repositório de confiança do sistema operacional (por exemplo, por meio da Política de Grupo).

• Modo Normal: os certificados aprovados pelo usuário são armazenados cert.store e reutilizados para sessões subsequentes.

Fluxo de trabalho de validação

1. A validação do certificado do servidor verifica a cadeia de confiança.

2. Se a validação falhar, os usuários receberão uma solicitação para aceitar ou rejeitar o certificado (isso ocorre apenas se estiver em uso o modo de validação normal, e não o modo estrito).

3. Os certificados aceitos são armazenados em cache para evitar solicitações repetidas (isso ocorre apenas se estiver em uso o modo de validação Normal, e não o modo de validação Rigorosa).

Conclusão

O MyQ Desktop Client integra autenticação e criptografia de nível corporativo para mitigar riscos como roubo de credenciais e interceptação de dados. Ao aplicar Kerberos, TLS e validação de certificados, as organizações podem alinhar-se aos princípios do Zero Trust, mantendo a usabilidade por meio de fluxos de autenticação silenciosos.