Il Desktop Client MyQ utilizza robusti meccanismi di sicurezza per garantire comunicazioni sicure, autenticazione e integrità dei dati negli ambienti di stampa aziendali. Questo documento descrive in dettaglio i protocolli, i metodi di autenticazione e le best practice di configurazione alla base dell'architettura di sicurezza del Desktop Client, con particolare attenzione alla crittografia TLS, all'autenticazione integrata di Windows (IWA), a Kerberos, a NTLM e all'integrazione di Entra ID. Vengono analizzate implementazioni tecniche quali la registrazione del nome principale del servizio (SPN), la gestione dei certificati e i flussi di accesso silenzioso per dimostrare la conformità agli standard di sicurezza moderni.
Architettura di comunicazione sicura
Crittografia TLS predefinita
I server di stampa e Central Server applicano la crittografia TLS 1.2+ per tutti i canali di comunicazione, comprese le interazioni con Desktop Client. Ciò garantisce la riservatezza e l'integrità dei dati durante lo spooling dei lavori, l'autenticazione e la reportistica. Gli amministratori devono configurare gli endpoint HTTPS utilizzando nomi di dominio completi (FQDN) per prevenire attacchi man-in-the-middle (MITM).
Modalità di convalida dei certificati
-
Modalità rigorosa: richiede che i certificati server siano emessi da un'autorità di certificazione (CA) attendibile o aggiunti manualmente all'archivio di fiducia del sistema. I tentativi di connessione falliscono se la convalida non va a buon fine. Si consiglia di utilizzare la modalità rigorosa quando possibile.
-
Modalità normale: consente agli utenti di ignorare gli avvisi relativi ai certificati non attendibili, con i certificati accettati memorizzati in
%ProgramData%\MyQ\Desktop Client\cert.storeper le sessioni future.
Meccanismi di autenticazione
Autenticazione Windows integrata (IWA)
L'IWA consente un'autenticazione senza interruzioni in ambienti collegati al dominio utilizzando Kerberos o NTLM. Il server sfrutta l'API del server HTTP di Windows (http.sys) per gestire le richieste HTTP in entrata e convalidare i nomi principali del servizio (SPN), garantendo l'integrità del protocollo.
Flusso di lavoro Kerberos
-
Acquisizione del Ticket Granting Ticket (TGT): i client collegati al dominio ottengono un TGT dal Key Distribution Center (KDC).
-
Richiesta di ticket di servizio: il client richiede un ticket di servizio
HTTP/<FQDN>dal KDC. -
Convalida del token: MyQ Server convalida il ticket di servizio rispetto all'SPN registrato.
Configurazione critica:
-
Il server deve disporre di un SPN correttamente configurato affinché l'autenticazione Kerberos funzioni correttamente.
-
L'accesso tramite indirizzi IP bypassa Kerberos, costringendo il fallback a NTLM.
Applicazione di Kerberos
Per gli ambienti che richiedono una sicurezza più rigorosa, è possibile configurare l'applicazione in modo che utilizzi esclusivamente Kerberos e non consenta il fallback NTLM. Ciò viene eseguito a livello di server, non esclusivamente per il Desktop Client.
-
Disabilitare NTLM tramite
KerberosOnly=Trueinconfig.ini. -
Registrare gli SPN per tutti i server MyQ utilizzando
setspn. -
Utilizza FQDN invece di indirizzi IP per gli endpoint del server.
Fallback NTLM
NTLM funge da fallback in scenari non basati su dominio o IP. Sebbene meno sicuro, utilizza un meccanismo di challenge-response con hash della password dell'utente. Per applicare esclusivamente Kerberos, seguire il suggerimento sopra riportato.
Accesso silenzioso Entra ID
Per i dispositivi Entra ID o ibridi, Desktop Client utilizza Microsoft Authentication Library (MSAL) e Windows Authentication Manager (WAM) per acquisire i token in modo silenzioso tramite l'account del sistema operativo. Il flusso prevede:
-
Acquisizione del token: MSAL recupera un token ID utilizzando WAM.
-
Scambio di token: il token ID viene scambiato con un token di accesso MyQ per autenticare le chiamate API REST.
Flusso del codice di autorizzazione OAuth 2.0
Per gli ambienti non Windows, Desktop Client supporta OAuth 2.0 tramite la authorization_code concessione:
-
Reindirizzamento utente: il client reindirizza gli utenti alla pagina di accesso MyQ.
-
Scambio di codici: dopo l'autenticazione, il codice di autorizzazione viene scambiato con un token di accesso.
Configurazione Entra ID
-
Abilita Accedi con Microsoft nelle impostazioni del server MyQ per i dispositivi con connessione ibrida.
-
Assicurarsi che i dispositivi siano registrati con Entra ID per sfruttare l'autenticazione silenziosa.
Gestione dei certificati
Certificati radice attendibili
-
Modalità rigorosa: i certificati devono essere preinstallati nell'archivio di fiducia del sistema operativo (ad esempio, tramite Criteri di gruppo).
-
Modalità normale: i certificati approvati dall'utente vengono archiviati in
cert.storee riutilizzati per le sessioni successive.
Flusso di lavoro di convalida
-
La convalida del certificato server verifica la catena di fiducia.
-
Se la convalida non va a buon fine, agli utenti viene chiesto di accettare o rifiutare il certificato (questo avviene solo se è in uso la modalità di convalida normale anziché quella rigorosa).
-
I certificati accettati vengono memorizzati nella cache per evitare richieste ripetute (solo se è in uso la modalità di convalida normale anziché quella rigorosa).
Best practice per i certificati
Si consiglia di implementare sempre certificati firmati da CA aziendali per i server MyQ.
Conclusione
MyQ Desktop Client integra autenticazione e crittografia di livello aziendale per mitigare rischi quali il furto di credenziali e l'intercettazione. Applicando Kerberos, TLS e la convalida dei certificati, le organizzazioni possono allinearsi ai principi Zero Trust mantenendo l'usabilità attraverso flussi di autenticazione silenziosi.