Modèle de sécurité et chiffrement

Principes

Le modèle de sécurité d’Ubidesk repose sur trois principes :

1. Un canal unique : toutes les communications, console, agents et clients, passent par le port 443. Aucun autre port n’est ouvert vers la plateforme.
2. Pas de secret à long terme dans les sessions : chaque session négocie ses propres clés.
3. Une traçabilité infalsifiable : chaque action est consignée dans un journal chaîné par hachage.

Transport

Les connexions utilisent TLS 1.3. Les versions antérieures du protocole ne sont pas acceptées. Concrètement :

• le port 443 suffit, même derrière un pare-feu sortant restrictif ou un proxy ;
• les certificats sont vérifiés des deux côtés.

Chiffrement des sessions

Chaque session distante est chiffrée en AES-256-GCM, un chiffrement authentifié qui garantit à la fois la confidentialité et l’intégrité du flux.

Les clés sont dérivées par un échange ECDH propre à chaque session : la clé n’existe que le temps de la session, n’est jamais stockée, et la compromission d’une clé ne compromet pas les autres sessions.

Authentification des techniciens

La MFA est obligatoire pour tous les comptes de technicien, quel que soit le plan :

• codes TOTP via une application d’authentification ;
• passkeys, synchronisées ou liées à un appareil ;
• clés de sécurité FIDO2.

Sur le plan Business, l’authentification peut passer par un fournisseur d’identité en SSO SAML ou OIDC. La MFA reste requise même lorsque le SSO est activé.

Journal d’audit

Le journal enregistre les événements de session et d’administration : connexions, sessions ouvertes et fermées, transferts de fichiers et confirmations, changements de configuration.

Il est chaîné par hachage : chaque entrée référence l’empreinte de la précédente. Toute modification d’une entrée invalide la chaîne, ce qui rend les altérations détectables.

Le journal est exportable vers un SIEM au format Syslog et vers des intégrations Splunk et Microsoft Sentinel.

Résidence des données

Les données de l’espace sont hébergées dans une région choisie parmi l’Union européenne, le Canada et les États-Unis. Le choix se fait à la création de l’espace et détermine où sont stockées les métadonnées, les journaux et les enregistrements de session.

Transferts de fichiers et consentement

Aucun transfert de fichier ne démarre sans confirmation explicite de l’utilisateur. La confirmation est individuelle, journalisée, et le technicien ne peut pas la contourner.

Enregistrement des sessions

L’enregistrement des sessions, disponible à partir du plan Pro, est stocké dans la région de résidence de l’espace. Annoncez-le à l’utilisateur avant de lancer un enregistrement.

Modèle de menace

Ces mécanismes répondent à des menaces précises :

• interception : TLS 1.3 sur le port 443 empêche l’écoute passive et les attaques par rétrogradation sur le transport ;
• compromission d’une clé de session : les clés ECDH par session limitent l’impact d’une clé qui fuiterait ;
• prise de contrôle de compte : la MFA obligatoire bloque les attaques par mot de passe seul ; FIDO2 et passkeys résistent en plus au hameçonnage ;
• altération interne : la chaîne de hachage rend détectable toute modification silencieuse du journal.

Ce qu’ils ne font pas : protéger une machine dont les mots de passe locaux sont faibles, ni un utilisateur qui donnerait la main à une personne à qui il ne devrait pas faire confiance. Ce volet relève du guide de durcissement.

Ce qui reste de votre responsabilité

La sécurité d’une session dépend aussi de la configuration du poste : mots de passe locaux, verrouillage d’écran, mises à jour de l’OS. Voir le guide Durcir son accès à distance et la page Trust Layer.

Pour la partie programmatique, voir API REST : vue d’ensemble.