Fonctionnalités de sécurité de Live Share

Les sessions de collaboration dans Visual Studio Live Share sont puissantes pour permettre à un nombre quelconque de personnes de participer à une session et de modifier, déboguer et bien plus encore. Toutefois, compte tenu de ce niveau d’accès, vous serez certainement intéressé par les fonctionnalités de sécurité fournies par Live Share. Dans cet article, nous allons fournir des recommandations et des options pour sécuriser votre environnement en fonction des besoins.

Comme avec n’importe quel outil de collaboration, n’oubliez pas que vous ne devez partager votre code, votre contenu et vos applications qu’avec les personnes que vous faites confiance.

Connectivité

Lors du lancement d’une session entre pairs, Live Share tente d’établir une connexion peer-to-peer, et uniquement si cela n’est pas possible (par exemple, en raison de pare-feu/NATs), il revient à utiliser un relais cloud. Toutefois, dans les deux types de connexion (P2P ou relais), toutes les données transmises entre pairs sont chiffrées de bout en bout à l’aide du protocole SSH. Dans le cas d’une connexion de relais, le chiffrement SSH est superposé sur des WebSockets chiffrés par TLS. Cela signifie que Live Share ne dépend pas du service de relais cloud pour la sécurité. Même si le relais a été compromis, il n’a pas pu déchiffrer l’une des communications Live Share.

Le rôle du service Live Share est limité à l’authentification utilisateur et à la découverte de session. Le service lui-même ne stocke pas ou 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 les extensions qui s’y appuient.

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

Chiffrement par câble

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 pivotée régulièrement pendant toute la durée de la session. Le secret de session partagé et toutes les clés de chiffrement sont conservées en mémoire uniquement par les deux côtés et sont valides uniquement pendant la durée de la session. Ils ne sont jamais écrits sur le disque ou envoyés à n’importe quel service (y compris Live Share).

Authentification d’homologue

La session SSH est également authentifiée de deux manières. L’hôte (rôle serveur SSH) utilise l’authentification par clé publique/privée, comme c’est le cas pour le protocole SSH. Lorsqu’un hôte partage une session Live Share, il génère une paire de clés publique/privée RSA unique pour la session. La clé privée de l’hôte est conservée uniquement en mémoire dans le processus hôte ; il n’est jamais écrit sur le disque ou envoyé à n’importe quel service, y compris le service Live Share. La clé publique de l’hôte est publiée sur le service Live Share, ainsi que les informations de connexion de 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 vérifier que l’hôte contient la clé privée correspondant à la clé publique publiée (sans que l’invité obtienne réellement 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 les revendications relatives à l’identité de l’utilisateur (obtenue par le biais de la connexion MSA, AAD ou GitHub). Le jeton a également des revendications qui indiquent que l’invité est autorisé à accéder à cette session Live Share spécifique (car il avait le lien d’invitation et/ou ils ont été spécifiquement invités par l’hôte). L’hôte valide ce jeton et vérifie les revendications (et en fonction des options peuvent inviter l’utilisateur hôte) avant d’autoriser l’invité à rejoindre la session.

Invitations et accès de jointure

Chaque fois que vous démarrez une nouvelle session de collaboration, Live Share génère un nouvel identificateur unique placé dans le lien d’invitation. Ces liens fournissent une base solide et sécurisée pour inviter ceux que vous faites confiance, car l’identificateur dans le lien est « non deviner » et n’est valide que pour la durée d’une seule session de collaboration.

Suppression d’un invité inattendu

En tant qu’hôte, vous êtes averti automatiquement 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 supprimer un invité joint si pour une raison quelconque vous ne les connaissez pas. (Par exemple, si vous avez accidentellement publié votre lien sur un système de conversation à l’échelle de l’entreprise et un employé aléatoire joint.) Cliquez simplement sur le bouton « Supprimer » dans la notification qui s’affiche et ils seront éjectés de la session de collaboration.

Dans VS Code, même si vous avez ignoré une notification de jointure, vous avez également la possibilité de supprimer un participant après cela. En ouvrant l’affichage Live Share dans l’Explorateur ou l’onglet personnalisé dans la barre d’activité VS Code, vous pouvez pointer ou cliquer avec le bouton droit sur le nom d’un participant et sélectionner l’icône ou l’option « Supprimer le participant ».

Exiger l’approbation de l’invité

En règle générale, les participants qui rejoignent une session de collaboration sont connectés à Live Share à l’aide d’un compte professionnel ou scolaire Microsoft (AAD), d’un compte Microsoft personnel ou d’un compte GitHub. Bien que la valeur par défaut « notification + suppression » pour les utilisateurs connectés offre une bonne combinaison de vitesse et de contrôle pour ces invités, vous pouvez verrouiller les choses un peu plus si vous effectuez quelque chose de sensible.

En outre, dans certaines circonstances, forcer tous les invités à se connecter pour rejoindre une session de collaboration peut être problématique. Par exemple, vous pouvez demander à une personne nouvelle de rejoindre Live Share en tant qu’invité, salle de classe/scénarios d’apprentissage ou lors de la collaboration avec une personne qui n’a pas l’un des types de comptes pris en charge. Pour ces raisons, Live Share peut autoriser les utilisateurs qui ne sont pas connectés à rejoindre des sessions de collaboration en tant qu’invités en lecture seule . Bien que l’hôte ait besoin d’approuver ces invités avant de pouvoir rejoindre par défaut, vous pouvez refuser ces invités « anonymes » ou toujours les approuver à la place.

Demande d’approbation d’invité 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 (Paramètres de préférences > de fichier>) :

  "liveshare.guestApprovalRequired": true
  

• Dans Visual Studio, définissez les options > outils > live Share > « Exiger l’approbation invité » sur True.

  

À partir de ce stade, vous serez invité à approuver chaque invité qui rejoint.

Dans Visual Studio Code :

Dans Visual Studio :

En tant qu’invité, si vous rejoignez une session où ce paramètre est activé, vous serez averti dans la barre d’état ou dans la boîte de dialogue de jointure que Live Share attend sur l’hôte pour approuver.

Rejet automatique ou acceptation d’utilisateurs qui ne sont pas connectés (anonyme)

Comme décrit ci-dessus, Live Share peut être configuré pour permettre aux utilisateurs qui ne sont pas 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 jonction, un nom simple ne fournit pas le même niveau d’assurance qu’une connexion réelle. Par conséquent, par défaut, l’hôte est invité à approuver n’importe quel invité anonyme, quel que soit le paramètre « exiger l’approbation invité » décrit ci-dessus.

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

• Dans VS Code, définissez liveshare.anonymousGuestApproval settings.json (Paramètres de préférences > de fichier>) acceptsur , rejectou prompt (valeur par défaut) selon les besoins.

• Dans Visual Studio, définissez les options > Outils > Live Share > « Approbation d’invité anonyme » sur Accepter, Rejeter ou Inviter (valeur par défaut) selon les besoins.

N’oubliez pas que vous ne devez envoyer que des liens d’invitation Live Share aux personnes que vous faites confiance.

Autorisation du contrôle de commande invité

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

• Dans VS Code, définissez liveshare.languages.allowGuestCommandControl settings.json (Paramètres de préférences > de fichier>) true sur ou false (valeur par défaut).

Contrôle de l’accès et de la visibilité des fichiers

En tant qu’invité, le modèle distant de Live Share vous donne un accès en lecture/écriture rapide aux fichiers et dossiers que l’hôte a partagés avec vous sans avoir à synchroniser l’intégralité du contenu d’un projet. Vous pouvez donc naviguer et modifier des fichiers indépendamment dans l’arborescence de fichiers partagés. Toutefois, cette liberté pose certains risques pour l’hôte. Dans le concept, un développeur peut choisir d’entrer et de modifier le code source sans vos connaissances ou voir le code source sensible ou les « secrets » situés quelque part dans l’arborescence de fichiers partagés. Par conséquent, en tant qu’hôte, vous ne souhaiterez 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 » les fichiers que vous ne souhaitez pas partager avec n’importe qui sans sacrifier les fonctionnalités. Vos invités peuvent toujours participer à des tâches telles que le débogage de sessions qui nécessiteraient normalement l’accès à ces fichiers s’ils voulaient le faire eux-mêmes.

Pour ce faire, ajoutez 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 validés dans le contrôle de code source afin que toute personne clonant un projet puisse tirer parti de ces règles sans effort supplémentaire de leur 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.

Voyons comment ces propriétés changent ce que les invités peuvent faire.

Propriétés

La propriété excludeFiles vous permet de spécifier une liste de modèles de fichiers glob (très similaires à ceux trouvés dans les fichiers .gitignore) qui empêche Live Share d’ouvrir certains fichiers ou dossiers pour les invités. N’oubliez pas que cela inclut des scénarios tels qu’un invité suivant ou sautant à votre emplacement de modification, en passant à pas dans un fichier pendant le débogage collaboratif, toutes les fonctionnalités de navigation de code comme aller à la définition, etc. Il est destiné aux fichiers que vous ne souhaitez jamais partager dans des circonstances telles que celles contenant des secrets, des certificats ou des mots de passe. Par exemple, étant donné qu’ils contrôlent la sécurité, les fichiers .vsls.json sont toujours exclus.

La propriété hideFiles est similaire, mais pas aussi stricte. Ces fichiers sont simplement masqués dans l’arborescence de fichiers. Par exemple, si vous avez passé à pas dans l’un de ces fichiers pendant le débogage, il est toujours ouvert dans l’éditeur. Cette propriété est principalement utile si vous n’avez pas de configuration de fichier .gitignore (comme c’est le cas si vous utilisez un autre système de contrôle de code source) ou si vous souhaitez simplement augmenter ce qui est déjà là pour éviter l’encombrement ou la confusion.

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

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

L’inconvénient du exclude paramètre est que le contenu des dossiers tels que node_modules sont fréquemment dans .gitignore, mais peut être utile pour passer au débogage. Par conséquent, Live Share prend en charge la possibilité d’inverser une règle à l’aide de « ! » dans la propriété excludeFiles. Par exemple, ce fichier .vsls.json exclut tout dans .gitignore, à l’exception de node_modules :

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

Les règles de masquage et d’exclusion sont traitées séparément. Par conséquent, si vous souhaitez toujours masquer node_modules pour réduire l’encombrement sans réellement l’exclure, 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 les fichiers .gitignore, .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é (le cas échéant), puis en parcourant chaque sous-dossier à partir de là, menant à un fichier donné pour rechercher les fichiers .vsls.json à traiter. Contenu des fichiers .vsls.json dans les dossiers plus loin dans l’arborescence de fichiers, puis compléter (ou remplacer) les règles établies à des niveaux supérieurs.

Remarque : il n’est pas possible de réinscrire (!) un fichier si un répertoire parent de ce fichier est exclu. Comme pour .gitignore, lorsque vous incluez à nouveau un fichier, vous devez également réinscrire 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 qui sont externes au dossier/solution partagé. Cela facilite l’ouverture rapide d’autres fichiers associés sans avoir à re-partager.

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

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

  "liveshare.shareExternalFiles": false
  

• Dans Visual Studio, définissez les options > Outils > Live Share « Partager > des fichiers externes » sur False

Mode Lecture seule

Parfois, lorsque vous partagez votre code en tant qu’hôte, vous ne souhaitez pas que vos invités effectuent des modifications. Vous devrez peut-être examiner certains de votre code, ou vous affichez votre projet à un grand nombre d’invités et ne souhaitez pas que des modifications inutiles ou accidentelles soient apporté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é se joint, il ne pourra pas apporter de modifications au code, bien que vous puissiez toujours voir les curseurs et les mises en surbrillance des uns et des autres, ainsi que parcourir le projet.

Vous pouvez toujours co-déboguer avec des invités en mode lecture seule. Les invités n’auront pas la possibilité d’effectuer un pas à pas dans le processus de débogage, mais peuvent toujours ajouter ou supprimer des points d’arrêt et inspecter des variables. En outre, vous pouvez toujours partager des serveurs et des terminaux (en 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 traitez de problèmes de codage difficiles ou de bogues, avoir une paire d’yeux supplémentaire lorsque le débogage peut être vraiment utile. Visual Studio Live Share active le « débogage collaboratif » ou le « co-débogage » en partageant la session de débogage avec tous les invités chaque fois que l’hôte démarre le débogage.

En tant qu’hôte, vous êtes en contrôle total sur le démarrage ou l’arrêt d’une session de débogage, mais la co-débogage pose certains risques si vous partagez avec quelqu’un que vous ne faites pas confiance. Live Share permet aux invités d’exécuter des commandes console/REPL et il existe donc un risque d’exécution d’un acteur malveillant exécutant une commande que vous ne souhaitez pas qu’ils exécutent.

Par conséquent, vous devez uniquement co-déboguer avec ceux que vous faites confiance.

En savoir plus :

Partage d’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 l’ordinateur de l’hôte au même port sur l’ordinateur de l’invité. En tant qu’invité, vous pouvez ensuite interagir avec l’application exactement comme si elle s’exécutait localement sur votre ordinateur (par exemple, l’hôte et l’invité peuvent accéder à une application web s’exécutant sur http://localhost:3000).

Toutefois, en tant qu’hôte, vous devez être très sélectif avec les ports que vous partagez avec les invités et partager uniquement 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 paramètre de configuration et l’hôte effectuant une action.

Dans Visual Studio, le port d’application web spécifié dans ASP.NET projets est automatiquement partagé pendant le débogage uniquement pour faciliter l’accès invité à l’application web lors de l’exécution. Toutefois, vous pouvez désactiver cette automatisation en définissant les options d’outils >> Live Share > « Partager l’application web sur le 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. Toutefois, vous pouvez le désactiver en ajoutant les éléments suivants à settings.json :

"liveshare.autoShareServers": false

Dans les deux cas, veillez à partager des ports supplémentaires.

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

Partage d’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 autoriser d’autres collaborateurs à voir simplement la sortie ou à utiliser un certain nombre d’outils en ligne de commande pour exécuter des tests, des builds ou même des problèmes spécifiques à l’environnement de triage.

Seuls les hôtes peuvent démarrer des terminaux partagés pour empêcher les invités de démarrer un terminal et de faire quelque chose que vous n’attendez pas ou regardez. 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. Toutefois, vous pouvez le désactiver en ajoutant les éléments suivants à settings.json :

"liveshare.autoShareTerminals": false

En savoir plus :

Consentement de l’administrateur AAD

Lorsque vous vous connectez à l’aide d’une adresse e-mail professionnelle ou scolaire microsoft, vous pouvez voir un message indiquant « Besoin d’approbation administrateur » lors de la connexion. Cela est dû au fait que Live Share nécessite un accès en lecture aux informations utilisateur pour ses fonctionnalités de sécurité et que votre locataire Azure AD est configuré pour exiger le « consentement administrateur » pour les nouvelles applications qui accèdent au contenu de l’annuaire.

Votre administrateur AD doit résoudre ce problème pour vous à l’aide des informations suivantes :

• Nom de l’application : Visual Studio Live Share (Insiders)
• Type d’application : application web
• État des applications : 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/

Cette opération ne doit être effectuée qu’une seule fois pour toute personne utilisant Live Share. Voir ici et ici pour plus d’informations.

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.