Share via

Sécurité

  • Article

Les tunnels de développement sont un service de tunneling de développement axé sur la sécurité. Dans cet article, découvrez comment les tunnels de développement sont sécurisés.

Vue d’ensemble

Par défaut, l’hébergement et la connexion à un tunnel nécessitent une authentification avec le même compte Microsoft, Microsoft Entra ID ou GitHub qui a créé le tunnel. Le tunneling nécessite la création de connexions sortantes au service hébergé dans Azure. Aucune connexion entrante n’est requise pour utiliser le service.

Domaines

L’accès aux tunnels de développement peut être contrôlé en autorisant ou en refusant l’accès sortant aux domaines suivants :

  • Authentification

    • github.com
    • login.microsoftonline.com

  • Tunnels de développement

    • global.rel.tunnels.api.visualstudio.com
    • [clusterId].rel.tunnels.api.visualstudio.com
    • [clusterId]-data.rel.tunnels.api.visualstudio.com
    • *.[clusterId].devtunnels.ms
    • *.devtunnels.ms

La liste des valeurs actuelles [clusterId] est disponible à l’adresse https://global.rel.tunnels.api.visualstudio.com/api/v1/clusters.

Transfert web

Les ports de tunnel utilisant les protocoles HTTP(S)/WS(S) sont accessibles directement via l’URL de transfert web fournie (par exemple : https://tunnelid-3000.devtunnels.ms).

  • Les connexions clientes non sécurisées sont toujours mises à niveau automatiquement vers HTTPS/WSS.
  • Http Strict Transport Security (HSTS) est activé avec un âge maximal d’un an.
  • La version TLS minimale prise en charge par le service est 1.2, tls 1.3 étant la version préférée.
  • L’arrêt TLS est effectué à l’entrée du service à l’aide de certificats de service émis par une autorité de certification Microsoft.
    • Après l’arrêt TLS, la réécriture d’en-tête a lieu. Cela est nécessaire pour de nombreux scénarios de développement d’applications web.

Protection anti-hameçonnage

Lors de la connexion à une URL de transfert web pour la première fois, les utilisateurs sont présentés avec une page d’anti-hameçonnage interstitiel. La page est ignorée dans les circonstances suivantes :

  • La requête utilise une méthode autre que GET
  • L’en-tête de requête Accept ne contient pas text/html
  • La requête contient l’en-tête X-Tunnel-Skip-AntiPhishing-Page
  • La requête contient l’en-tête X-Tunnel-Authorization
  • L’utilisateur a déjà visité la page et cliqué sur Continuer

Accès au tunnel

Par défaut, les tunnels et les ports de tunnel sont privés et accessibles uniquement à l’utilisateur qui a créé le tunnel.

Si un tunnel ou un port de tunnel doit être accessible sans authentification, une entrée de contrôle d’accès anonyme (ACE) peut être ajoutée (utilisation --allow-anonymous).

L’accès au tunnel peut également être étendu à votre locataire Microsoft Entra actuel (utilisation --tenant) ou à des organisations GitHub spécifiques (utilisation --organization) ; pour ce dernier, voir Accès à l’organisation GitHub ci-dessous.

L’interface CLI peut également être utilisée pour demander des jetons d’accès qui accordent un accès limité à toute personne détenant le jeton (utilisation devtunnel token). Il s’agit d’une fonctionnalité avancée, mais peut être utile dans des situations spécifiques.

Actuellement, quatre types de jetons d’accès de tunnel sont disponibles :

  • Un « jeton d’accès client » permet au porteur de se connecter à tous les ports du tunnel.
  • Un « jeton d’accès hôte » permet au porteur d’héberger le tunnel et d’accepter les connexions, mais pas d’y apporter d’autres modifications.
  • Un « jeton d’accès aux ports de gestion » permet au porteur d’ajouter et de supprimer des ports sur un tunnel.
  • Un « jeton d’accès de gestion » permet au porteur d’effectuer toutes les opérations sur ce tunnel, notamment la définition des contrôles d’accès, l’hébergement, la connexion et la suppression du tunnel.

Tous les jetons sont limités au tunnel actuel ; ils n’accordent l’accès à aucun des autres tunnels de l’utilisateur actuel, le cas échéant. Les jetons expirent après un certain temps (actuellement 24 heures). Les jetons ne peuvent être actualisés qu’à l’aide d’une identité d’utilisateur réelle qui dispose d’un accès à l’étendue de gestion au tunnel (pas seulement un jeton d’accès de gestion).

La plupart des commandes CLI peuvent accepter un --access-token argument avec un jeton approprié comme alternative à la connexion.

Les clients web peuvent transmettre un jeton dans un en-tête pour autoriser les demandes à un URI de tunnel :

X-Tunnel-Authorization: tunnel <TOKEN>

Conseil

Cela est utile pour les clients non interactifs, car il leur permet d’accéder à des tunnels sans qu’un accès anonyme soit activé. Nous utilisons l’en-tête X-Tunnel-Authorization au lieu de l’en-tête standard Authorization pour empêcher l’interférence potentielle avec l’autorisation spécifique à l’application.

Consultez la section Gérer l’accès au tunnel de développement pour en savoir plus sur la gestion de l’accès au tunnel via l’interface CLI.

Accès à l’organisation GitHub

Pour prendre en charge les tunnels accordant l’accès à tous les membres d’une organisation GitHub, installez l’application GitHub Dev Tunnels dans l’organisation. Cela permet au service Dev Tunnels de case activée l’état d’appartenance des utilisateurs dans cette organisation. (Dev Tunnels ne nécessite pas d’autorisations de dépôt sur l’organisation.) Vous devrez peut-être être administrateur dans l’organisation GitHub pour effectuer cette opération.

Autres questions

Si, après avoir examiné cette page, vous avez d’autres questions, consultez Commentaires et support.