Fonctionnalités de sécurité de Live Share

Les sessions de collaboration dans Visual Studio Live Share sont puissantes dans la mesure où elles permettent à n’importe quel nombre de personnes de rejoindre une session et d’éditer, déboguer et plus encore de manière collaborative. Cependant, étant donné ce niveau d’accès, vous serez sans aucun doute intéressé par les fonctionnalités de sécurité que Live Share fournit. Dans cet article, nous fournirons quelques recommandations et options pour sécuriser votre environnement selon les besoins.

Comme avec tout outil de collaboration, souvenez-vous que vous ne devez partager votre code, contenu et applications qu’avec des personnes en qui vous avez confiance.

Connectivité

Lors de l’initiation d’une session entre pairs, Live Share tente d’établir une connexion peer-to-peer, et ce n’est que si cela n’est pas possible (par exemple en raison de pare-feux/NAT), qu’il utilise un relais cloud en retour. Cependant, dans les deux types de connexion (P2P ou relais), toutes les données transmises entre pairs sont chiffrées de bout en bout en utilisant le protocole SSH. Dans le cas d’une connexion de relais, le chiffrement SSH est superposé aux WebSockets chiffrés TLS. Cela signifie que Live Share ne dépend pas du service de relais cloud pour la sécurité. Même si le relais était compromis, il ne pourrait pas déchiffrer aucune des communications de Live Share.

Le rôle du service Live Share se limite à l’authentification des utilisateurs et à la découverte des sessions. Le service lui-même ne stocke pas et n’a jamais accès au contenu d’une session. Tout le contenu utilisateur dans Live Share est transmis via la session SSH. Cela inclut le code, les terminaux, les serveurs partagés et toutes les autres fonctionnalités de collaboration fournies par Live Share ou des extensions qui s’y appuient.

Pour en savoir plus sur la modification de ces comportements et les exigences de connectivité de Live Share, veuillez consulter la section exigences de connectivité pour Live Share.

Chiffrement des communications

Le protocole SSH utilise un échange de clés Diffie-Hellman pour établir un secret partagé pour la session, et en dérive une clé pour le chiffrement symétrique AES. La clé de chiffrement est renouvelée périodiquement pendant toute la durée de la session. Le secret partagé de la session et toutes les clés de chiffrement sont maintenus uniquement en mémoire par les deux parties, et ne sont valides que pendant la durée de la session. Ils ne sont jamais écrits sur le disque ou envoyés à un quelconque service (y compris Live Share).

Authentification des pairs

La session SSH est également authentifiée dans les deux sens. L’hôte (rôle de serveur SSH) utilise l’authentification par clé publique/privée comme standard pour le protocole SSH. Lorsqu’un hôte partage une session Live Share, il génère une paire de clés RSA publique/privée unique pour la session. La clé privée de l’hôte est conservée uniquement en mémoire dans le processus hôte ; elle n’est jamais écrite sur le disque ou envoyée à un quelconque service, y compris le service Live Share. La clé publique de l’hôte est publiée sur le service Live Share avec les informations de connexion de la session (adresse IP et/ou point de terminaison de relais) où les invités peuvent y accéder via le lien d’invitation. Lorsqu’un invité se connecte à la session SSH de l’hôte, l’invité utilise le protocole d’authentification de l’hôte SSH pour valider que l’hôte détient la clé privée correspondant à la clé publique publiée (sans que l’invité ait réellement accès à la clé privée).

L’invité utilise un jeton Live Share pour s’authentifier auprès de l’hôte. Le jeton est un JWT signé émis par le service Live Share qui inclut des revendications sur l’identité de l’utilisateur (obtenues via MSA, AAD ou la connexion GitHub). Le jeton contient également des revendications indiquant que l’invité est autorisé à accéder à cette session Live Share spécifique (car il avait le lien d’invitation et/ou il a été spécifiquement invité par l’hôte). L’hôte valide ce jeton et vérifie les revendications (et, selon les options, peut inviter l’utilisateur hôte) avant de permettre à l’invité de rejoindre la session.

Invitations et accès à la participation

Chaque fois que vous démarrez une nouvelle session de collaboration, Live Share génère un nouvel identifiant unique qui est placé dans le lien d’invitation. Ces liens offrent une base solide et sécurisée pour inviter les personnes en qui vous avez confiance puisque l’identifiant dans le lien est « non-devinable » et est valide uniquement pour la durée d’une seule session de collaboration.

Retirer un invité inattendu

En tant qu’hôte, vous êtes automatiquement notifié chaque fois qu’un invité rejoint la session de collaboration.

Dans Visual Studio Code :

Dans Visual Studio :

Mieux encore, la notification vous donne la possibilité de retirer un invité qui a rejoint si, pour une raison quelconque, vous ne le connaissez pas. (Par exemple, si vous avez accidentellement publié votre lien sur un système de chat à l’échelle de l’entreprise et qu’un employé aléatoire a rejoint.) Il suffit de cliquer sur le bouton « Retirer » dans la notification qui apparaît et il sera expulsé de la session de collaboration.

Dans VS Code, même si vous avez rejeté une notification de participation, vous avez également la possibilité de retirer un participant par la suite. En ouvrant la vue Live Share dans l’Explorateur ou l’onglet personnalisé dans la barre d’activités de VS Code, vous pouvez survoler ou faire un clic droit sur le nom d’un participant et sélectionner l’icône ou l’option « Retirer le participant ».

Exiger l’approbation des invités

Typiquement, les participants qui rejoignent une session de collaboration seront connectés à Live Share en utilisant un compte professionnel ou scolaire Microsoft (AAD), un compte Microsoft personnel ou un compte GitHub. Bien que le paramètre par défaut « notification + retrait » pour les utilisateurs connectés offre un bon équilibre entre rapidité et contrôle pour ces invités, vous pourriez vouloir renforcer la sécurité un peu plus si vous faites quelque chose de sensible.

De plus, dans certaines circonstances, forcer tous les invités à se connecter pour rejoindre une session de collaboration peut poser des problèmes. Les exemples incluent demander à quelqu’un de nouveau sur Live Share de rejoindre en tant qu’invité, des scénarios de classe/apprentissage, ou lors de la collaboration avec quelqu’un qui n’a pas un des types de comptes pris en charge. Pour ces raisons, Live Share peut permettre aux utilisateurs qui sont non connectés de rejoindre des sessions de collaboration en tant qu’invités en lecture seule. Bien que l’hôte doive approuver ces invités avant qu’ils puissent rejoindre par défaut, vous pourriez vouloir soit interdire ces invités « anonymes », soit toujours les approuver à la place.

Exiger l’approbation des invités pour les utilisateurs connectés

Si vous souhaitez empêcher les invités connectés de rejoindre vos sessions de collaboration jusqu’à ce que vous les ayez « approuvés », modifiez le paramètre suivant :

• Dans VS Code, ajoutez ce qui suit à settings.json (Fichier > Préférences > Paramètres) :

  "liveshare.guestApprovalRequired": true
  

• Dans Visual Studio, réglez Outils > Options > Live Share > « Exiger l’approbation des invités » sur Vrai.

  

À partir de ce moment, il vous sera demandé d’approuver chaque invité qui rejoint.

Dans Visual Studio Code :

Dans Visual Studio :

En tant qu’invité, si vous rejoignez une session où l’hôte a activé ce paramètre, vous serez notifié dans la barre d’état ou la boîte de dialogue de participation que Live Share attend l’approbation de l’hôte.

Rejet automatique ou acceptation des utilisateurs non connectés (anonymes)

Comme décrit ci-dessus, Live Share peut être configuré pour permettre aux utilisateurs non connectés de rejoindre une session de collaboration en tant qu’invités en lecture seule. Bien que ces « invités anonymes » doivent entrer un nom lors de la participation, un nom simple ne fournit pas le même niveau d’assurance qu’une véritable connexion. Par conséquent, par défaut, l’hôte est invité à approuver tout invité anonyme indépendamment du paramètre « exiger l’approbation des invités » décrit ci-dessus.

Vous pouvez toujours rejeter (désactiver les invités anonymes) ou toujours accepter les utilisateurs anonymes comme suit :

• Dans VS Code, réglez liveshare.anonymousGuestApproval dans settings.json (Fichier > Préférences > Paramètres) sur accept, reject, ou prompt (le paramètre par défaut) selon ce qui est approprié.

• Dans Visual Studio, réglez Outils > Options > Live Share > « Approbation des invités anonymes » sur Accepter, Rejeter ou Inviter (le paramètre par défaut) selon ce qui est approprié.

Quoi qu’il en soit, souvenez-vous que vous ne devez envoyer des liens d’invitation Live Share qu’aux personnes en qui vous avez confiance.

Permettre le contrôle des commandes des invités

Pour permettre aux invités d’exécuter des commandes arbitraires via les actions de code (« corrections rapides ») et CodeLens, réglez le paramètre suivant :

• Dans VS Code, réglez liveshare.languages.allowGuestCommandControl dans settings.json (Fichier > Préférences > Paramètres) sur true ou false (le paramètre par défaut).

Contrôler l’accès aux fichiers et la visibilité

En tant qu’invité, le modèle distant de Live Share vous donne un accès rapide en lecture/écriture aux fichiers et dossiers que l’hôte a partagés avec vous sans avoir à synchroniser tout le contenu d’un projet. Vous pouvez donc naviguer et éditer indépendamment les fichiers dans toute l’arborescence de fichiers partagée. Cependant, cette liberté présente certains risques pour l’hôte. En principe, un développeur pourrait choisir de modifier le code source sans votre connaissance ou de voir du code source sensible ou des « secrets » situés quelque part dans l’arborescence de fichiers partagée. Par conséquent, en tant qu’hôte, vous ne voudrez peut-être pas toujours que l’invité ait accès à l’intégralité d’un projet que vous partagez. Heureusement, un avantage supplémentaire de ce modèle distant est que vous pouvez choisir « d’exclure » des fichiers que vous ne souhaitez partager avec personne sans sacrifier la fonctionnalité. Vos invités peuvent toujours participer à des éléments tels que des sessions de débogage qui normalement nécessiteraient l’accès à ces fichiers s’ils voulaient le faire par eux-mêmes.

Vous pouvez accomplir cela en ajoutant un fichier .vsls.json au dossier ou au projet que vous partagez. Tous les paramètres que vous ajoutez à ce fichier au format json modifient la façon dont Live Share traite les fichiers. En plus de vous fournir un contrôle direct, ces fichiers peuvent également être ajoutés au contrôle de source afin que toute personne clonant un projet puisse profiter de ces règles sans effort supplémentaire de sa part.

Voici un exemple de fichier .vsls.json :

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"none",
    "excludeFiles":[
        "*.p12",
        "*.cer",
        "token",
        ".gitignore"
    ],
    "hideFiles": [
        "bin",
        "obj"
    ]
}

Remarque

Vous pouvez également rendre tous les fichiers/dossiers que vous partagez en lecture seule lorsque vous démarrez une session de collaboration. Voir ci-dessous pour plus de détails.

Examinons comment ces propriétés modifient ce que les invités peuvent faire.

Propriétés

La propriété excludeFiles vous permet de spécifier une liste de motifs glob de fichiers (très semblables à ceux trouvés dans les fichiers .gitignore) qui empêchent Live Share d’ouvrir certains fichiers ou dossiers pour les invités. Soyez conscient que cela inclut des scénarios tels qu’un invité suivant ou sautant vers votre emplacement d’édition, entrant dans un fichier lors du débogage collaboratif, toute fonctionnalité de navigation de code comme aller à la définition, et plus. Il est destiné aux fichiers que vous ne souhaitez jamais partager en aucune circonstance, tels que ceux contenant des secrets, des certificats ou des mots de passe. Par exemple, puisque ces fichiers contrôlent la sécurité, les fichiers .vsls.json sont toujours exclus.

La propriété hideFiles est similaire, mais pas tout à fait aussi stricte. Ces fichiers sont simplement cachés de l’arborescence des fichiers. Par exemple, si vous entrez dans l’un de ces fichiers lors du débogage, il s’ouvre toujours dans l’éditeur. Cette propriété est principalement utile si vous n’avez pas configuré de fichier .gitignore (comme ce serait le cas si vous utilisez un système de contrôle de source différent) ou si vous souhaitez simplement compléter ce qui est déjà en place pour éviter l’encombrement ou la confusion.

Le paramètre gitignore établit comment Live Share doit traiter le contenu des fichiers .gitignore dans les dossiers partagés. Par défaut, tous les glob trouvés dans les fichiers .gitignore sont traités comme s’ils étaient spécifiés dans la propriété « hideFiles ». Cependant, vous pouvez choisir un comportement différent en utilisant l’une des valeurs suivantes :

Option	Résultat
none	Le contenu de .gitignore est visible pour les invités dans l’arborescence des fichiers (à condition qu’ils ne soient pas filtrés par un paramètre d’éditeur d’invité).
hide	Valeur par défaut. Les glob à l’intérieur de .gitignore sont traités comme s’ils étaient dans la propriété « hideFiles ».
exclude	Les glob à l’intérieur de .gitignore sont traités comme s’ils étaient dans la propriété « excludeFiles ».

Un inconvénient du paramètre exclude est que le contenu des dossiers comme node_modules est fréquemment dans .gitignore mais peut être utile pour entrer lors du débogage. Par conséquent, Live Share prend en charge la possibilité d’inverser une règle en utilisant « ! » dans la propriété excludeFiles. Par exemple, ce fichier .vsls.json exclurait tout ce qui se trouve dans ".gitignore" sauf node_modules :

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"exclude",
    "excludeFiles":[
        "!node_modules"
    ]
}

Les règles de masquage/exclusion sont traitées séparément, donc si vous souhaitez toujours masquer node_modules pour réduire l’encombrement sans l’exclure réellement, vous pouvez simplement modifier le fichier comme suit :

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"exclude",
    "excludeFiles":[
        "!node_modules"
    ],
    "hideFiles":[
        "node_modules"
    ]
}

Fichiers .vsls.json dans les sous-dossiers

Enfin, tout comme .gitignore, les fichiers .vsls.json peuvent être placés dans des sous-dossiers. Les règles de masquage/exclusion sont déterminées en commençant par le fichier .vsls.json dans le dossier racine que vous avez partagé (s’il est présent) puis en parcourant chaque sous-dossier à partir de là menant à un fichier donné pour rechercher les fichiers .vsls.json à traiter. Le contenu des fichiers .vsls.json dans les dossiers plus bas dans l’arborescence des fichiers complète (ou remplace) les règles établies à des niveaux supérieurs.

Remarque : il n’est pas possible de réinclure (!) un fichier si un répertoire parent de ce fichier est exclu. Semblable à .gitignore, lors de la réinclusion d’un fichier, vous devrez également réinclure chaque répertoire parent du fichier.

Désactivation du partage de fichiers externes

Par défaut, Live Share partagera également tous les fichiers que l’hôte ouvre et qui sont externes au dossier / solution partagée. Cela facilite l’ouverture rapide d’autres fichiers liés sans avoir à les partager à nouveau.

Si vous préférez désactiver cette fonctionnalité :

• Dans VS Code, ajoutez ce qui suit à settings.json :

  "liveshare.shareExternalFiles": false
  

• Dans Visual Studio, réglez Outils > Options > Live Share > « Partager des fichiers externes » sur False

Mode Lecture seule

Parfois, lorsque vous partagez votre code en tant qu’hôte, vous ne voulez pas que vos invités effectuent des modifications. Vous pourriez avoir besoin que votre invité jette un œil à une partie de votre code, ou vous montrez votre projet à un grand nombre d’invités et ne souhaitez pas que des modifications inutiles ou accidentelles soient effectuées. Live Share offre la possibilité de partager des projets en mode lecture seule.

En tant qu’hôte, lors du partage, vous avez la possibilité d’activer le mode lecture seule pour une session de collaboration. Lorsqu’un invité rejoint, il ne pourra pas modifier le code, bien que vous puissiez toujours voir les curseurs et les surlignages de chacun ainsi que naviguer dans le projet.

Vous pouvez toujours co-déboguer avec des invités en mode lecture seule. Les invités n’auront pas la possibilité de parcourir le processus de débogage, mais pourront toujours ajouter ou supprimer des points d’arrêt et inspecter des variables. De plus, vous pouvez toujours partager des serveurs et des terminaux (lecture seule) avec des invités.

Vous pouvez en savoir plus sur le démarrage d’une session de collaboration en lecture seule :

Codébogage

Lorsque vous vous attaquez à des problèmes de codage difficiles ou à des bugs, avoir un regard supplémentaire lors du débogage peut être très utile. Visual Studio Live Share permet le « débogage collaboratif » ou « co-débogage » en partageant la session de débogage avec tous les invités chaque fois que l’hôte commence le débogage.

En tant qu’hôte, vous avez un contrôle total sur le démarrage ou l’arrêt d’une session de débogage, mais le co-débogage présente certains risques si vous partagez avec quelqu’un en qui vous n’avez pas confiance. Live Share permet aux invités que vous invitez d’exécuter des commandes console/REPL et il y a donc un risque qu’un acteur malveillant exécute une commande que vous ne voudriez pas qu’ils exécutent.

Par conséquent, vous devriez co-déboguer uniquement avec ceux en qui vous avez confiance.

En savoir plus :

Partager un serveur local

Lors du codébogage, il peut être très utile de pouvoir accéder aux différentes parties de l’application prise en charge par l’hôte pendant la session de débogage. Il se peut que vous souhaitiez accéder à l’application dans un navigateur, à une base de données locale ou à un terminal REST à partir de vos outils. Live Share vous permet de « partager un serveur » qui mappe un port local sur la machine de l’hôte au même port exact sur la machine de l’invité. En tant qu’invité, vous pouvez alors interagir avec l’application exactement comme si elle s’exécutait localement sur votre machine (par exemple, l’hôte et l’invité peuvent tous deux accéder à une application web s’exécutant sur http://localhost:3000).

Cependant, en tant qu’hôte, vous devriez être très sélectif avec les ports que vous partagez avec les invités et ne partager que les ports d’application plutôt que les ports système. Du côté des invités, les ports partagés se comportent exactement comme si le serveur/service était en cours d’exécution sur leur propre ordinateur. Cette fonction est très utile, mais il faut éviter tout risque de partager le mauvais port. Pour cette raison, Live Share ne fait aucune hypothèse sur ce qui doit ou ne doit pas être partagé sans un paramètre de configuration et une action de l’hôte.

Dans Visual Studio, le port de l’application web spécifié dans les projets ASP.NET est partagé automatiquement uniquement lors du débogage pour faciliter l’accès des invités à l’application web lorsqu’elle est en cours d’exécution. Cependant, vous pouvez désactiver cette automatisation en réglant Outils > Options > Live Share > « Partager l’application web lors du débogage » sur « False » si vous préférez.

Dans Visual Studio Code, Live Share tente de détecter les ports d’application appropriés et de les partager. Cependant, vous pouvez désactiver cela en ajoutant ce qui suit à settings.json :

"liveshare.autoShareServers": false

Dans les deux cas, faites preuve de prudence lors du partage de ports supplémentaires.

Vous pouvez en savoir plus sur la configuration de la fonctionnalité ici :

Partager un terminal

Aujourd’hui, le développement utilise couramment un large éventail d’outils en ligne de commande. Heureusement, Live Share vous permet de « partager un terminal » avec vos invités en tant qu’hôte. Le terminal partagé peut fonctionner en lecture seule ou en collaboration totale, auquel cas tant l’hôte que les invités ont la possibilité d’exécuter des commandes et de voir les résultats. En tant qu’hôte, vous pouvez permettre aux autres collaborateurs soit de voir uniquement la sortie, soit d’utiliser divers outils en ligne de commande pour exécuter des tests, des builds ou même résoudre des problèmes spécifiques à l’environnement.

Seuls les hôtes peuvent démarrer des terminaux partagés pour empêcher les invités d’en démarrer un et de faire quelque chose que vous ne prévoyez pas ou que vous ne surveillez pas. Lorsque vous démarrez un terminal partagé en tant qu’hôte, vous pouvez spécifier s’il doit être en lecture seule ou en lecture/écriture. Dans le deuxième cas, tout le monde, y compris l’hôte, peut taper dans le terminal, ce qui permet d’intervenir si un invité effectue une action indésirable. Dans un souci de sécurité toutefois, ne donnez un accès en lecture/écriture qu’aux invités qui en ont réellement besoin et tenez-vous-en aux terminaux en lecture seule si vous souhaitez simplement qu’ils voient le résultat des commandes exécutées.

Dans Visual Studio, les terminaux ne sont pas partagés par défaut. Dans VS Code, les terminaux sont automatiquement partagés en lecture seule par défaut. Cependant, vous pouvez désactiver cela en ajoutant ce qui suit à settings.json :

"liveshare.autoShareTerminals": false

En savoir plus :

Consentement Admin AAD

Lors de la connexion en utilisant une adresse e-mail professionnelle ou scolaire soutenue par Microsoft, vous pouvez voir un message disant « Besoin d’approbation admin » lors de la connexion. Cela est dû au fait que Live Share nécessite un accès en lecture aux informations des utilisateurs pour ses fonctionnalités de sécurité et que votre locataire Azure AD est configuré pour exiger un « consentement admin » pour les nouvelles applications accédant au contenu de l’annuaire.

Votre administrateur AD devra résoudre cela pour vous en utilisant les informations suivantes :

• Nom de l’application : Visual Studio Live Share (Insiders)
• Type d’application : Web App
• Statut de l’application : Production
• Autorisations déléguées : User.Read
• URL de l’application : https://visualstudio.microsoft.com/services/live-share/
• URL de réponse : https://insiders.liveshare.vsengsaas.visualstudio.com/auth/redirect/windowslive/

Cela n’aurait besoin d’être fait qu’une seule fois pour toute personne utilisant Live Share. Voir ici et ici pour plus de détails.

Voir aussi

• Installer et se connecter à Live Share dans Visual Studio Code
• Installer et se connecter à Live Share dans Visual Studio
• Exigences de connectivité pour Live Share

Vous rencontrez des problèmes ? Voir la section dépannage ou fournir des commentaires.