Cliente de escritorio MyQ X

El Desktop Client MyQ emplea mecanismos de seguridad robustos para garantizar la comunicación segura, la autenticación y la integridad de los datos en los entornos de impresión empresariales. Este documento detalla los protocolos, los métodos de autenticación y las prácticas recomendadas de configuración que sustentan la arquitectura de seguridad del Desktop Client, centrándose en el cifrado TLS, la autenticación integrada de Windows (IWA), Kerberos, NTLM y la integración de Entra ID. Se analizan implementaciones técnicas como el registro del nombre principal del servicio (SPN), la gestión de certificados y los flujos de inicio de sesión silencioso para demostrar el cumplimiento de las normas de seguridad modernas.

Arquitectura de comunicación segura

Cifrado TLS por defecto

Los servidores de impresión y Central Server aplican el cifrado TLS 1.2+ para todos los canales de comunicación, incluidas las interacciones con Desktop Client. Esto garantiza la confidencialidad y la integridad de los datos durante el almacenamiento en cola de trabajos, la autenticación y la generación de informes. Los administradores deben configurar los puntos finales HTTPS utilizando nombres de dominio completos (FQDN) para evitar ataques de tipo «man-in-the-middle» (MITM).

Modos de validación de certificados

• Modo estricto: requiere que los certificados de servidor sean emitidos por una autoridad de certificación (CA) de confianza o añadidos manualmente al almacén de confianza del sistema. Los intentos de conexión fallan si la validación falla. Recomendamos utilizar el modo estricto siempre que sea posible.

• Modo normal: permite a los usuarios omitir las advertencias de certificados no fiables, con los certificados aceptados almacenados en %ProgramData%\MyQ\Desktop Client\cert.store para futuras sesiones.

Mecanismos de autenticación

Autenticación integrada de Windows (IWA)

La IWA permite una autenticación fluida en entornos unidos a un dominio mediante Kerberos o NTLM. El servidor aprovecha la API del servidor HTTP de Windows (http.sys) para gestionar las solicitudes HTTP entrantes y validar los nombres principales de servicio (SPN), lo que garantiza la integridad del protocolo.

Flujo de trabajo de Kerberos

1. Adquisición de tickets de concesión de tickets (TGT): los clientes unidos al dominio obtienen un TGT del centro de distribución de claves (KDC).

2. Solicitud de ticket de servicio: el cliente solicita un ticket de servicio HTTP/<FQDN> al KDC.

3. Validación del token: El servidor MyQ valida el ticket de servicio con el SPN registrado.

Configuración crítica:

• El servidor debe tener un SPN correctamente configurado para que la autenticación Kerberos funcione correctamente.

• El acceso a través de direcciones IP omite Kerberos, lo que obliga a recurrir a NTLM.

Recurso NTLM

NTLM sirve como alternativa en escenarios que no son de dominio o basados en IP. Aunque es menos seguro, utiliza un mecanismo de desafío-respuesta con hash con la contraseña del usuario. Para aplicar Kerberos de forma exclusiva, siga la sugerencia anterior.

Inicio de sesión silencioso de Entra ID

Para los dispositivos híbridos o unidos a Entra ID, Desktop Client utiliza la biblioteca de autenticación de Microsoft (MSAL) y el administrador de autenticación de Windows (WAM) para adquirir tokens de forma silenciosa a través de la cuenta del sistema operativo. El flujo implica:

1. Adquisición de tokens: MSAL recupera un token de identificación utilizando WAM.

2. Intercambio de tokens: el token de identificación se intercambia por un token de acceso MyQ para autenticar las llamadas a la API REST.

Flujo de código de autorización OAuth 2.0

Para entornos que no sean Windows, Desktop Client admite OAuth 2.0 a través de la authorization_code concesión:

1. Redirección de usuario: el cliente redirige a los usuarios a la página de inicio de sesión de MyQ.

2. Intercambio de código: Después de la autenticación, el código de autorización se intercambia por un token de acceso.

Gestión de certificados

Certificados raíz de confianza

• Modo estricto: los certificados deben estar preinstalados en el almacén de confianza del sistema operativo (por ejemplo, a través de la política de grupo).

• Modo normal: los certificados aprobados por el usuario se almacenan en cert.store y se reutilizan para sesiones posteriores.

Flujo de trabajo de validación

1. La validación del certificado del servidor comprueba la cadena de confianza.

2. Si la validación falla, los usuarios reciben un mensaje para aceptar o rechazar el certificado (esto solo ocurre si se utiliza el modo de validación normal en lugar del estricto).

3. Los certificados aceptados se almacenan en caché para evitar que se repitan los mensajes (esto solo ocurre si se utiliza el modo de validación normal en lugar del estricto).

Conclusión

MyQ Desktop Client integra autenticación y cifrado de nivel empresarial para mitigar riesgos como el robo de credenciales y el espionaje. Al aplicar Kerberos, TLS y la validación de certificados, las organizaciones pueden alinearse con los principios de Zero Trust y, al mismo tiempo, mantener la usabilidad a través de flujos de autenticación silenciosos.