MyQ X Desktop Client

Der MyQ Desktop Client verwendet robuste Sicherheitsmechanismen, um eine sichere Kommunikation, Authentifizierung und Datenintegrität in Unternehmensdruckumgebungen zu gewährleisten. Dieses Dokument beschreibt die Protokolle, Authentifizierungsmethoden und Konfigurationsbest Practices, die die Sicherheitsarchitektur des Desktop Client untermauern, mit Schwerpunkt auf TLS-Verschlüsselung, integrierter Windows-Authentifizierung (IWA), Kerberos, NTLM und Entra ID-Integration. Technische Implementierungen wie die Registrierung von Service Principal Names (SPN), die Zertifikatsverwaltung und stille Anmeldeabläufe werden analysiert, um die Einhaltung moderner Sicherheitsstandards zu demonstrieren.

Sichere Kommunikationsarchitektur

TLS-Verschlüsselung als Standard

Druck- und Central Server erzwingen die TLS 1.2+-Verschlüsselung für alle Kommunikationskanäle, einschließlich der Interaktionen mit dem Desktop Client. Dies gewährleistet die Vertraulichkeit und Integrität der Daten während des Job-Spoolings, der Authentifizierung und der Berichterstellung. Administratoren müssen HTTPS-Endpunkte unter Verwendung von vollqualifizierten Domänennamen (FQDNs) konfigurieren, um Man-in-the-Middle-Angriffe (MITM) zu verhindern.

Zertifikatsvalidierungsmodi

• Strenger Modus: Erfordert, dass Serverzertifikate von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt oder manuell zum Vertrauensspeicher des Systems hinzugefügt werden. Verbindungsversuche schlagen fehl, wenn die Validierung fehlschlägt. Wir empfehlen, wann immer möglich den strengen Modus zu verwenden.

• Normalmodus: Ermöglicht es Benutzern, Warnungen zu nicht vertrauenswürdigen Zertifikaten zu umgehen, wobei akzeptierte Zertifikate für zukünftige Sitzungen gespeichert werden %ProgramData%\MyQ\Desktop Client\cert.store für zukünftige Sitzungen gespeichert werden.

Authentifizierungsmechanismen

Integrierte Windows-Authentifizierung (IWA)

IWA ermöglicht eine nahtlose Authentifizierung in Domänenumgebungen mit Kerberos oder NTLM. Der Server nutzt die Windows HTTP Server API (http.sys), um eingehende HTTP-Anfragen zu verarbeiten und Service Principal Names (SPNs) zu validieren, wodurch die Protokollintegrität gewährleistet wird.

Kerberos-Workflow

1. Erwerb eines Ticket Granting Ticket (TGT): Mit der Domäne verbundene Clients erhalten ein TGT vom Key Distribution Center (KDC).

2. Service Ticket Request: Der Client fordert ein Service Ticket für HTTP/<FQDN> vom KDC an.

3. Token-Validierung: Der MyQ-Server validiert das Dienstticket anhand des registrierten SPN.

Kritische Konfiguration:

• Der Server muss über einen ordnungsgemäß konfigurierten SPN verfügen, damit die Kerberos-Authentifizierung korrekt funktioniert.

• Der Zugriff über IP-Adressen umgeht Kerberos und erzwingt einen Fallback auf NTLM.

NTLM-Fallback

NTLM dient als Fallback in nicht domänen- oder IP-basierten Szenarien. Es ist zwar weniger sicher, verwendet jedoch einen Challenge-Response-Mechanismus, der mit dem Passwort des Benutzers gehasht wird. Um Kerberos ausschließlich zu erzwingen, befolgen Sie den obigen Vorschlag.

Entra ID Silent Login

Bei Entra ID-verbundenen oder hybriden Geräten verwendet Desktop Client die Microsoft Authentication Library (MSAL) und den Windows Authentication Manager (WAM), um Tokens stillschweigend über das Betriebssystemkonto zu erwerben. Der Ablauf umfasst:

1. Token-Erwerb: MSAL ruft mithilfe von WAM ein ID-Token ab.

2. Token-Austausch: Das ID-Token wird gegen ein MyQ-Zugriffstoken ausgetauscht, um REST-API-Aufrufe zu authentifizieren.

OAuth 2.0-Autorisierungscode-Ablauf

Für Nicht-Windows-Umgebungen unterstützt Desktop Client OAuth 2.0 über die authorization_code grant:

1. Benutzerumleitung: Der Client leitet Benutzer zur MyQ-Anmeldeseite um.

2. Codeaustausch: Nach der Authentifizierung wird der Autorisierungscode gegen einen Zugriffstoken ausgetauscht.

Zertifikatsverwaltung

Vertrauenswürdige Stammzertifikate

• Strenger Modus: Zertifikate müssen im Vertrauensspeicher des Betriebssystems vorinstalliert sein (z. B. über Gruppenrichtlinien).

• Normalmodus: Vom Benutzer genehmigte Zertifikate werden gespeichert cert.store und für nachfolgende Sitzungen wiederverwendet.

Validierungs-Workflow

1. Bei der Validierung von Serverzertifikaten wird die Vertrauenskette überprüft.

2. Wenn die Validierung fehlschlägt, werden Benutzer aufgefordert, das Zertifikat zu akzeptieren oder abzulehnen (dies ist nur der Fall, wenn der normale und nicht der strenge Validierungsmodus verwendet wird).

3. Akzeptierte Zertifikate werden zwischengespeichert, um wiederholte Aufforderungen zu vermeiden (dies ist nur der Fall, wenn der normale und nicht der strenge Validierungsmodus verwendet wird).

Fazit

Der MyQ Desktop Client integriert Authentifizierung und Verschlüsselung auf Unternehmensniveau, um Risiken wie den Diebstahl von Anmeldedaten und das Abhören von Daten zu minimieren. Durch die Durchsetzung von Kerberos, TLS und Zertifikatsvalidierung können Unternehmen die Zero-Trust-Prinzipien einhalten und gleichzeitig die Benutzerfreundlichkeit durch stille Authentifizierungsabläufe gewährleisten.