Vous avez besoin d’un outil d’accès à distance capable de réussir un audit ISO 27001 — pas de slogans marketing. Ce guide passe l’Annexe A clause par clause (ISO/IEC 27001:2013) et explique les preuves, configurations et contrôles opérationnels qu’un auditeur attend pour un produit d’accès à distance et les sessions qu’il crée.

Quels contrôles de l'Annexe A importent pour l'accès à distance

A.6 : Organisation de la sécurité de l'information — responsabilités, séparation des tâches, rôles pour l'approbation et l'escalade de l'accès à distance.
A.7 : Sécurité des ressources humaines — vérifications des antécédents, formation et accords d'accès pour les utilisateurs et opérateurs.
A.8 : Gestion des actifs — inventaire des clients distants, serveurs et identifiants utilisés par l'outil.
A.9 : Contrôle d'accès — provisionnement des utilisateurs, moindre privilège, contrôle des sessions, accès privilégié.
A.10 : Cryptographie — configuration TLS approuvée, gestion des certificats et des clés.
A.11 : Sécurité physique — accès physique sécurisé aux postes permettant des sessions distantes.
A.12 : Sécurité des opérations — configuration sécurisée, correctifs, protection contre les malwares, gestion des changements pour l'outil.
A.13 : Sécurité des communications — contrôles réseau, comportement NAT/relais, règles de pare-feu et segmentation.
A.15 : Relations avec les fournisseurs — contrats avec des tiers (relais), SLA, droits d'audit.
A.16 : Gestion des incidents de sécurité de l'information — détection, escalation et enregistrement des incidents liés aux sessions distantes.
A.18 : Conformité — journalisation, rétention, obligations légales et réglementaires, localisation des données.

Identité, authentification et contrôle d'accès (A.9)

Le contrôle d'accès est le cœur de tout audit d'accès à distance. Pour chaque contrôle de l'Annexe A, l'auditeur attend des politiques documentées et une application mesurable. Concrètement cela signifie :

Provisionnement & déprovisionnement des utilisateurs : cycle de vie des comptes documenté lié aux processus RH ou IAM. L'outil doit montrer comment les comptes sont créés, comment les privilèges sont attribués et comment l'accès est révoqué (p. ex. désactivation automatique lors de la suppression dans AD).
Moindre privilège : mappages de rôles ou groupes limitant qui peut initier des sessions interactives, qui peut atteindre des hôtes cibles spécifiques et qui peut escalader vers un contrôle administratif. Fournissez des matrices d'accès et des exemples.
Authentification forte : authentification multi‑facteur pour les contrôleurs et pour l'accès à toute console de gestion. Listez les méthodes prises en charge (TOTP, push, tokens matériels, SSO). Preuve de test : MFA activé pour 10 comptes exemples.
Contrôles de session : durées d'inactivité forcées, consentement explicite pour l'accès non supervisé et confirmation de session quand requis. Preuve = captures de configuration et documents de politique de session.
Accès privilégié : approbation additionnelle ou élévation just‑in‑time pour les sessions administratives, enregistrements des approbations et séparation des privilèges de surveillance et de contrôle.

Cryptographie et gestion des clés (A.10)

L'Annexe A attend que les contrôles cryptographiques soient appropriés et documentés. Pour l'accès à distance, l'accent est mis sur TLS, le traitement des certificats et la garde des clés.

Ce que recherchent les auditeurs :

Posture TLS : le produit doit utiliser des versions et chiffrements TLS modernes. Documentez les versions TLS prises en charge et le minimum appliqué. Fournissez un scan montrant que les points de terminaison relais et clients n'acceptent que TLS 1.2+ (ou la base imposée par votre organisation).
Identifiants par appareil : le modèle déployé (certificats d'appareil, clés ou jetons longue durée) doit être décrit et le cycle de vie couvert — émission, rotation, révocation. Pour Tenvo, le transport utilise TLS avec un certificat par appareil ; notez que lorsque le trafic est proxifié via un relais, TLS se termine au relais, donc l'opérateur du relais est en position d'inspecter les sessions.
Stockage des clés : où résident les clés privées (HSM, magasin de clés OS, TPM) et qui y a accès. Preuves : captures, politique de rotation des clés et exemples de certificats expirés/révokés.
N'affirmez pas que le relais « ne peut pas déchiffrer » : soyez explicite dans votre analyse de risque pour indiquer si les relais terminent TLS et quelles mesures contractuelles et techniques (p. ex. relais dédié, opérateur audité) sont en place.

Réseau et communications (A.13)

Les outils d'accès à distance font transiter du trafic sur les réseaux d'entreprise, les réseaux domestiques et l'Internet public. L'attente de l'Annexe A est de documenter les contrôles réseau, la segmentation et les raisons de tout recours à des relais tiers.

Diagrammes de topologie et de flux : montrez les flux pair‑à‑pair directs vs traversée NAT vs flux via relais. Annotez quels chemins traversent votre périmètre et lesquels passent par un tiers.
Politique pare‑feu & ports : justifiez tout port ouvert et privilégiez des connexions uniquement sortantes depuis les endpoints. Preuves : règles de pare‑feu, diagrammes réseau et test montrant qu'aucun port entrant n'est requis lors de l'utilisation du relais géré.
Segmentation : les endpoints d'accès distant doivent se trouver dans un réseau segmenté ou une zone bastion. Fournissez des ACL ou des règles de micro‑segmentation limitant ce qu'une session distante peut atteindre.
Choix du relais et résilience : si vous utilisez un relais tiers (cas fréquent pour l'accessibilité Internet), incluez des clauses contractuelles, la géolocalisation des relais et la bascule multi‑région. Le relais géré de Tenvo est la recommandation par défaut : clients natifs pour Windows/macOS/Linux, un client navigateur (public beta) et un relais géré multi‑région. Les paliers tarifaires de Tenvo sont Free $0 / Lite $2.99/mo / Pro $7.99/mo — tenez compte du SLA et du coût opérationnel dans votre décision fournisseur.
Quand s'auto‑héberger : l'auto‑hébergement est pertinent uniquement si une exigence écrite l'impose (localisation des données, réseau isolé ou règle de conformité interdisant l'infrastructure tiers). Documentez explicitement pourquoi vous avez choisi relais géré vs auto‑hébergement et incluez la comparaison des coûts opérationnels (patching, garde des clés, renouvellement de certificats, bascule).

Exploitation, journalisation et surveillance (A.12 et A.16)

Les auditeurs attendent des journaux complets et résistants aux altérations pour les sessions distantes — qui s'est connecté, d'où, ce qu'il a fait et pendant combien de temps. L'outil doit s'intégrer à vos processus de journalisation et à votre SIEM.

Types d'événements : début/fin de session, identité de l'utilisateur connecté, hôte cible, IP source, nœud relais, durée de la session, transferts de fichiers, événements presse‑papier et élévation de commandes. Cartographiez ces éléments vers la nomenclature d'événements de votre SIEM.
Rétention & intégrité : définissez des périodes de rétention conformes aux besoins légaux et politiques, et montrez comment les logs sont protégés contre les altérations (stockage en écriture unique, politiques de rétention, contrôles d'accès). Preuves : logs exportés d'exemple, configuration de rétention et captures des politiques S3 ou SIEM.
Enregistrement de session : si vous enregistrez la vidéo ou les frappes clavier, documentez le consentement, l'emplacement de stockage, le chiffrement au repos et la revue des accès. L'enregistrement de session implique des considérations de vie privée — intégrez cela aux validations RH et juridiques.
Alerte & réponse aux incidents : définissez des règles de détection (p. ex. sessions admin inattendues hors heures, sessions depuis de nouvelles plages IP) et reliez‑les aux playbooks d'IR. Preuves = règle d'alerte d'exemple, ticket d'incident et post‑mortem d'un exercice de test.
Voir aussi : Remote Desktop Audit Logging pour des modèles et des mappings SIEM.

Gestion des fournisseurs & conformité légale (A.15 et A.18)

L'utilisation d'un relais géré ou d'un fournisseur commercial d'accès à distance rend les contrôles fournisseurs obligatoires. L'Annexe A exige de traiter le relais/l'opérateur comme un fournisseur et de réaliser la due diligence.

Contrats & SLA : inclure des clauses de confidentialité, des dispositions de traitement des données, des délais de notification d'incident et des droits d'audit. Pour la conformité régionale, spécifiez la géolocalisation des relais ou choisissez des régions de relais dédiées.
Assurance tiers : obtenez un rapport SOC 2, un certificat ISO 27001 ou équivalent et joignez le rapport. Si le relais termine TLS, confirmez par écrit les limites d'accès et les contrôles de l'opérateur.
Localisation des données : si les régulateurs exigent que le trafic de session reste dans le pays, seul l'auto‑hébergement ou un relais régional sera acceptable. Documentez la décision et les contrôles compensatoires si vous conservez des relais hors juridiction.
Sortie contractuelle : définissez comment exporter les journaux et supprimer les identifiants à la fin du contrat.
Pour des conseils sur les choix d'hébergement et les compromis, voir Self‑Hosted Remote Desktop: Why, How, and What Breaks.

Facteurs humains, postes et contrôle des appareils (A.7, A.8, A.11)

L'accès distant n'est sécurisé que dans la mesure où le poste et les personnes le sont. L'Annexe A attend des contrôles RH et des contrôles des appareils.

Onboarding & formation : formation spécifique au rôle pour le personnel qui utilise ou supporte l'accès distant. Preuves : dossiers de formation, résultats de tests et accords d'utilisation signés.
Renforcement des endpoints : inventoriez tous les appareils autorisés à héberger des sessions distantes, assurez EDR/AV, chiffrement du disque, patching OS et politiques de verrouillage d'écran. Fournissez des rapports de conformité des appareils en exemple.
Accès non supervisé : exigez une approbation documentée pour les sessions non supervisées et des identifiants administratifs séparés pour le logiciel d'accès à distance (pas de mots de passe admin locaux partagés sans justification).
BYOD : si le BYOD est autorisé, présentez les profils MDM, règles d'accès conditionnel et la configuration minimale requise avant qu'un appareil puisse être utilisé pour des sessions distantes.

Checklist d'implémentation — quoi préparer pour un audit

Politiques & procédures : une politique d'accès à distance couvrant l'utilisation permise, les workflows d'approbation, MFA, séparation des tâches et traitement des incidents.
Preuves de configuration : captures ou exports montrant MFA activé, timeout de session configuré, application de la version TLS minimale et calendrier de rotation des certificats.
Preuves de journalisation : 90 jours de logs de session (ou la rétention de votre organisation), une alerte SIEM d'exemple liée à un incident de test et preuve d'intégrité des logs.
Documentation fournisseur : contrats, rapports SOC/ISO et liste de géolocalisation des relais.
Revues d'accès : preuves de revues d'accès trimestrielles complétées pour un échantillon de comptes privilégiés (montrez les changements et approbations).
Test d'intrusion ou scan de vulnérabilité : rapport récent des endpoints et relais d'accès distant, avec corrections suivies.

Arbitrages opérationnels : relais géré vs auto‑hébergement — angle conformité

Du point de vue conformité et opérationnel, un relais géré représente souvent le coût total et le risque les plus faibles. Vous évitez d'exploiter le logiciel de relais, de renouveler des certificats globaux, d'assurer la bascule multi‑région et la permanence d'astreinte 24/7 pour la disponibilité du relais. Le relais géré de Tenvo est présenté comme la recommandation par défaut pour la plupart des organisations car il inclut la bascule multi‑région et les mises à jour clients ; les paliers tarifaires (Free $0 / Lite $2.99/mo / Pro $7.99/mo) reflètent différents niveaux de support/SLA.

Cependant, l'auto‑hébergement est approprié et justifiable lorsqu'une exigence écrite interdit l'infrastructure tierce (p. ex. certaines règles du secteur public, lois strictes sur la localisation des données, ou un réseau physiquement isolé ne pouvant atteindre des relais externes). Si vous optez pour l'auto‑hébergement, documentez les activités opérationnelles supplémentaires que vous prendrez en charge : haute disponibilité, gestion des certificats, patching et accès judiciaire aux journaux relais.

Tests et collecte de preuves — étapes pratiques

Exécutez un test de découverte : produisez un diagramme de flux réseau d'un client vers une cible montrant si la session est P2P directe ou proxifiée via relais.
Échantillonnage des logs : exportez 30–90 jours de logs de session et vérifiez les champs requis par la politique (utilisateur, IP source, cible, durée, nœud relais).
Audit de configuration : exécutez une checklist de configuration de base sur les builds client et serveur pour démontrer les paramètres TLS, l'application de MFA et les politiques de session.
Exercice d'incident : simulez une session non autorisée et exécutez vos processus de détection & IR ; conservez le post‑mortem et le ticket comme preuves d'audit.
Revue d'accès : effectuez une revue d'accès privilégié trimestrielle et archivez les approbations dans votre IAM ou système de tickets.

Références et lectures associées

Ces articles internes fournissent des orientations opérationnelles approfondies réutilisables dans votre SMSI : Is Remote Desktop Secure? An Honest Threat Model, Remote Desktop Audit Logging, et Remote Desktop Without Port Forwarding Explained. Si vous hésitez sur les modèles d'hébergement, lisez aussi Self‑Hosted Remote Desktop: Why, How, and What Breaks.

Remarques finales et checklist rapide

Les auditeurs ISO 27001 n'auditeront pas le marketing : ils auditeront les politiques, configurations, logs, contrats et opérations. Traitez votre outil d'accès à distance comme un contrôle critique — cartographiez‑le aux contrôles de l'Annexe A ci‑dessus, produisez des preuves de configuration, effectuez des revues d'accès et incluez l'opérateur du relais dans la due diligence fournisseur. Par défaut, privilégiez un relais géré sauf si une exigence écrite de conformité impose l'auto‑hébergement ; incluez le coût opérationnel d'exploitation des relais dans votre comparaison d'options.

Prêt à tester une configuration d'accès à distance par rapport à votre checklist de l'Annexe A ? Téléchargez Tenvo et essayez‑le avec son relais géré (ou évaluez les options d'auto‑hébergement si votre conformité l'exige) : Download Tenvo.

ISO 27001 Remote Access : cartographie des contrôles de l'Annexe A