MyQ X Desktop Client

Le Desktop Client MyQ utilise des mécanismes de sécurité robustes pour garantir la sécurité des communications, l'authentification et l'intégrité des données dans les environnements d'impression d'entreprise. Ce document détaille les protocoles, les méthodes d'authentification et les meilleures pratiques de configuration qui sous-tendent l'architecture de sécurité du Desktop Client, en mettant l'accent sur le chiffrement TLS, l'authentification Windows intégrée (IWA), Kerberos, NTLM et l'intégration Entra ID. Les implémentations techniques telles que l'enregistrement du nom principal de service (SPN), la gestion des certificats et les flux de connexion silencieux sont analysées afin de démontrer la conformité aux normes de sécurité modernes.

Architecture de communication sécurisée

Chiffrement TLS par défaut

Les serveurs d'impression et Central Server appliquent le chiffrement TLS 1.2+ pour tous les canaux de communication, y compris les interactions avec le Desktop Client. Cela garantit la confidentialité et l'intégrité des données pendant la mise en file d'attente des travaux, l'authentification et la création de rapports. Les administrateurs doivent configurer les points de terminaison HTTPS à l'aide de noms de domaine complets (FQDN) afin d'empêcher les attaques de type « man-in-the-middle » (MITM).

Modes de validation des certificats

• Mode strict : exige que les certificats de serveur soient émis par une autorité de certification (CA) de confiance ou ajoutés manuellement au magasin de confiance du système. Les tentatives de connexion échouent si la validation échoue. Nous recommandons d'utiliser le mode strict dans la mesure du possible.

• Mode normal : permet aux utilisateurs de contourner les avertissements relatifs aux certificats non fiables, les certificats acceptés étant stockés dans %ProgramData%\MyQ\Desktop Client\cert.store pour les sessions futures.

Mécanismes d'authentification

Authentification Windows intégrée (IWA)

L'IWA permet une authentification transparente dans les environnements joints à un domaine à l'aide de Kerberos ou NTLM. Le serveur exploite l'API Windows HTTP Server (http.sys) pour traiter les requêtes HTTP entrantes et valider les noms principaux de service (SPN), garantissant ainsi l'intégrité du protocole.

Workflow Kerberos

1. Acquisition du ticket d'accès (TGT) : les clients joints au domaine obtiennent un TGT auprès du centre de distribution de clés (KDC).

2. Demande de ticket de service : le client demande un ticket de service au HTTP/<FQDN> au KDC.

3. Validation du jeton : le serveur MyQ valide le ticket de service par rapport au SPN enregistré.

Configuration critique :

• Le serveur doit disposer d'un SPN correctement configuré pour que l'authentification Kerberos fonctionne correctement.

• L'accès via des adresses IP contourne Kerberos, ce qui oblige à revenir à NTLM.

Repli NTLM

NTLM sert de solution de secours dans les scénarios non basés sur un domaine ou sur IP. Bien que moins sécurisé, il utilise un mécanisme de défi-réponse haché avec le mot de passe de l'utilisateur. Pour appliquer exclusivement Kerberos, suivez la suggestion ci-dessus.

Connexion silencieuse Entra ID

Pour les périphériques hybrides ou connectés à Entra ID, Desktop Client utilise la bibliothèque d'authentification Microsoft (MSAL) et le gestionnaire d'authentification Windows (WAM) pour acquérir des jetons de manière silencieuse via le compte du système d'exploitation. Le flux comprend :

1. Acquisition de jetons : MSAL récupère un jeton d'identification à l'aide de WAM.

2. Échange de jetons : le jeton d'identification est échangé contre un jeton d'accès MyQ pour authentifier les appels API REST.

Flux de code d'autorisation OAuth 2.0

Pour les environnements non Windows, Desktop Client prend en charge OAuth 2.0 via le authorization_code autorisation :

1. Redirection de l'utilisateur : le client redirige les utilisateurs vers la page de connexion MyQ.

2. Échange de code : après authentification, le code d'autorisation est échangé contre un jeton d'accès.

Gestion des certificats

Certificats racine de confiance

• Mode strict : les certificats doivent être préinstallés dans le magasin de confiance du système d'exploitation (par exemple, via la stratégie de groupe).

• Mode normal : les certificats approuvés par l'utilisateur sont stockés dans cert.store et réutilisés pour les sessions suivantes.

Workflow de validation

1. La validation des certificats de serveur vérifie la chaîne de confiance.

2. Si la validation échoue, les utilisateurs reçoivent une invite leur demandant d'accepter ou de rejeter le certificat (ceci n'est le cas que si le mode de validation normal est utilisé plutôt que le mode strict).

3. Les certificats acceptés sont mis en cache afin d'éviter les invites répétées (ceci uniquement si le mode de validation normal est utilisé plutôt que le mode strict).

Conclusion

MyQ Desktop Client intègre une authentification et un chiffrement de niveau entreprise afin d'atténuer les risques tels que le vol d'identifiants et l'écoute clandestine. En imposant Kerberos, TLS et la validation des certificats, les organisations peuvent se conformer aux principes Zero Trust tout en conservant leur facilité d'utilisation grâce à des flux d'authentification silencieux.