Restreindre l'accès à GitHub.com à l'aide d'un proxy d'entreprise

Si vous utilisez Enterprise Managed Users, vous pouvez empêcher les utilisateurs de votre réseau de s'authentifier sur GitHub.com avec des comptes qui ne sont pas membres de votre entreprise. Cela permet de réduire le risque que les données de votre entreprise soient exposées au public.

Pour appliquer cette restriction, vous devez configurer votre proxy réseau ou votre pare-feu de manière à injecter un en-tête dans les requêtes web et API de vos utilisateurs à GitHub.com.

Cette fonction nécessite un pare-feu externe ou un proxy. Support GitHub ne peut pas aider à l'installation ou au dépannage d'outils externes tels que ceux-ci. Pour en savoir plus sur l'étendue de l'aide, voir À propos du support GitHub.

Activation des restrictions d’accès

Cette fonctionnalité n’est pas activée par défaut. Un propriétaire d’entreprise peut activer cette fonctionnalité pour votre entreprise.

Dans le coin supérieur droit de GitHub, cliquez sur votre photo de profil, puis sur Votre entreprise.
En haut de la page, cliquez sur Paramètres.
Sous Paramètres, cliquez sur Sécurité de l'authentification.
Dans la section « Restrictions d’accès de l’entreprise », sélectionnez Activer les restrictions d’accès de l’entreprise.

Prérequis

Vous devez utiliser un entreprise avec utilisateurs managés sur GitHub.com.
- Vous saurez que vous utilisez un entreprise avec utilisateurs managés si tous les noms d'utilisateur de vos utilisateurs sont complétés par le shortcode de votre entreprise.
- Si vous utilisez GitHub Enterprise Cloud avec résidence des données, votre entreprise réside sur un sous-domaine dédié de GHE.com, de sorte que l'en-tête n'est pas nécessaire pour différencier le trafic vers les ressources de votre entreprise.
Pour appliquer la restriction, tout le trafic doit passer par un proxy ou un pare-feu. Le proxy ou le pare-feu doit :
- être capable d'intercepter et de modifier le trafic, ce qu'on appelle communément un proxy « break and inspect » (« casser et inspecter »)
- Prendre en charge l'injection d'en-têtes arbitraires
Votre propriétaire d’entreprise a activé cette fonctionnalité.

Trouver l'en-tête

Pour appliquer la restriction, vous injecterez un en-tête dans tout le trafic allant vers certains points d'extrémité pris en charge. L'en-tête se présente sous la forme suivante.

sec-GitHub-allowed-enterprise: ENTERPRISE-ID

Un propriétaire d'entreprise peut identifier l'ID d'entreprise correct à utiliser dans l'en-tête pour son entreprise.

Dans le coin supérieur droit de GitHub, cliquez sur votre photo de profil, puis sur Votre entreprise.
En haut de la page, cliquez sur Paramètres.
Sous Paramètres, cliquez sur Sécurité de l'authentification.
Dans la section « Restrictions d'accès de l'entreprise », recherchez l'en-tête de votre entreprise.

Utilisation de l’en-tête

Pour obtenir de meilleurs résultats, configurez votre proxy pour injecter l’en-tête dans tout le trafic vers les points de terminaison pris en charge suivants.

Point de terminaison	Objectif
`github.com/*`	Trafic web vers GitHub.com
`api.github.com/*`	Demandes d'API REST et GraphQL
`*.githubcopilot.com`	Trafic requis pour certaines fonctionnalités GitHub Copilot

Cela empêchera les personnes de votre réseau d'accéder à ces terminaux avec des comptes d'utilisateur qui n'appartiennent pas à votre entreprise. Parallèlement à cette fonction, vous pouvez bloquer le trafic provenant de l'extérieur de votre réseau en établissant une liste d'adresses IP autorisées. Consultez Restriction du trafic réseau vers votre entreprise avec une liste d’adresses IP autorisées.

Remarque

Accès à github.com/login est nécessaire pour créer des tickets d'assistance. Pour que les utilisateurs ayant des droits d'assistance puissent demander de l'aide, vous pouvez les exempter de la restriction.

Lever la restriction pour certains utilisateurs

Il se peut que vous souhaitiez lever cette restriction pour certains utilisateurs qui doivent contribuer à des ressources open source à l'aide d'un compte personnel, ou qui doivent créer des tickets d'assistance en cas de problème. Pour y remédier, vous devez configurer votre réseau de manière à n'injecter l'en-tête que pour les utilisateurs que vous souhaitez restreindre.

Options disponibles :

séparation des réseaux : Créer un réseau « professionnel » qui injecte l'en-tête et un réseau « open source » qui ne l'injecte pas. Limiter l'accès au réseau « open source » aux utilisateurs qui en ont besoin.
regroupement d’appareils: si votre proxy ou pare-feu est authentifié, vous pouvez collecter un groupe d’utilisateurs qui n’ont pas besoin de l’en-tête et les exclure de l’injection de manière sélective.

Fonctionnalités non prises en charge

Étant donné que cette restriction ne s'applique qu'aux demandes envoyées via un proxy qui ajoute un en-tête d'entreprise, certaines fonctionnalités GitHub ne prennent pas en charge la restriction visant à empêcher les utilisateurs d'accéder à leurs comptes personnels ou de les utiliser. Pour empêcher les utilisateurs de votre réseau d'accéder à ces fonctions, vous devez effectuer les modifications décrites ci-dessous.

Fonctionnalité	Point de terminaison associé	Notes
GitHub Pages	`github.io`	Il s’agit généralement de contenu généré par l’utilisateur qui ne peut pas accepter les données. Vous ne souhaiterez peut-être pas restreindre l’accès.
GitHub Codespaces	`github.dev`	Pour restreindre l’accès, bloquez entièrement le point de terminaison.
Accès SSH	Port 22 sur GitHub.com	Pour restreindre l'accès, bloquez entièrement le point de terminaison.
SSH sur HTTPS	`ssh.github.com`	Pour restreindre l'accès, bloquez entièrement le point de terminaison.
GitHub-a accueilli des exécuteurs	Divers	Pour appliquer un routage spécifique, utilisez la mise en réseau privée Azure. Consultez À propos de la mise en réseau privée Azure pour les exécuteurs hébergés par GitHub dans votre entreprise.

Points de terminaison qui ne nécessitent pas de restriction

Les points de terminaison suivants ne prennent pas en charge ni ne nécessitent la restriction, car ils fournissent uniquement des données et ne l’acceptent pas.

*.githubusercontent.com
*.githubassets.com
Trafic web vers GitHub.com

Comment fonctionne la restriction ?

Pour le trafic qui inclut l'en-tête de l'entreprise, lorsqu'un utilisateur tente d'accéder à GitHub.com via le web, Git ou API en utilisant un compte d'utilisateur (ou un jeton associé à un compte d'utilisateur) qui n'est pas membre de l'entreprise :

L’utilisateur voit un message d’erreur avec un code d’état 403 . Consultez Erreurs affichées pour les utilisateurs bloqués.
Un événement business.proxy_security_header_unsatisfied sera journalisé dans les journaux d’audit d’entreprise. Ces événements de journal n’ont aucun champ actor en raison de raisons de confidentialité, mais ont un champ actor_ip s’ils sont activés (voir Affichage des adresses IP dans le journal d’audit de votre entreprise). Pour examiner ces événements plus loin, vous pouvez passer en revue les journaux de proxy dans votre environnement.

Les sections suivantes fournissent des détails sur le comportement attendu qui s’applique aux demandes d’API et d’activité web de vos utilisateurs.

Activité web

Pour l’activité dans les GitHub.com interface utilisateur, l’en-tête restreint les comptes auxquels un utilisateur peut se connecter.

Sur votre réseau, un utilisateur :

Peut se connecter à un compte d’utilisateur managé dans votre entreprise.
Impossible de se connecter à un compte en dehors de votre entreprise.
Impossible de utiliser le sélecteur de compte pour basculer vers un compte en dehors de votre entreprise.

Si un utilisateur est déjà connecté à un compte en dehors de votre entreprise (par exemple, il s'est connecté en dehors de votre réseau), lorsqu'il ramène son appareil dans votre réseau, il recevra une erreur et ne pourra pas accéder à GitHub.com jusqu'à ce qu'il se connecte avec son compte appartenant à l'entreprise.

Activité Git

Si votre proxy est configuré pour injecter l'en-tête dans les requêtes HTTP(S), les utilisateurs de votre réseau ne pourront pas s'authentifier auprès de GitHub.com via HTTP(S), à moins qu'ils ne soient membres de votre entreprise. Les demandes de lecture publiques ne sont pas bloquées pour les utilisateurs anonymes non authentifiés.

Vous ne pouvez pas utiliser l’en-tête d’entreprise pour restreindre l’activité Git via SSH. Au lieu de cela, vous pouvez choisir de bloquer entièrement le port pour les requêtes SSH. Voir Fonctionnalités non prises en charge.

Demandes d’API

Pour le trafic des API REST et GraphQL vers api.github.com, y compris les demandes via GitHub CLI, l'en-tête restreint l'utilisation des jetons d'accès lorsque les utilisateurs sont connectés à votre réseau.

Scénario	Résultat	Types de jetons concernés
Un utilisateur utilise un personal access token associé à un compte appartenant à votre entreprise.	Le personal access token fonctionne comme prévu dans les requêtes API.	`ghp_` et `github_pat_`
Alors qu'il est connecté à votre réseau, un utilisateur tente d'utiliser un personal access token associé à un utilisateur extérieur à votre entreprise.	Les demandes utilisant le jeton sont bloquées.	`ghp_` et `github_pat_`
En dehors de votre réseau, à l'aide d'un compte extérieur à votre entreprise, un utilisateur se connecte à une application OAuth qui fonctionne sur son appareil. L’utilisateur amène ensuite son appareil à l’intérieur de votre réseau.	Les jetons OAuth de l’application arrêtent de fonctionner.	`gho_`
En dehors de votre réseau, à l'aide d'un compte extérieur à votre entreprise, un utilisateur se connecte à une GitHub App qui s'exécute sur son appareil. L’utilisateur amène ensuite son appareil à l’intérieur de votre réseau.	Les jetons de l’application arrêtent de fonctionner.	`ghu_`
Lorsqu'elle est connectée à votre réseau, une application tente de rafraîchir une session pour un utilisateur extérieur à votre entreprise à l'aide d'un jeton de rafraîchissement GitHub App.	L'actualisation échoue.	`ghr_`
Lors de la connexion à votre réseau, une application tente d’obtenir un jeton d’installation (un jeton sans identité utilisateur, simplement l’identité de l’application) pour une organisation en dehors de votre entreprise.	Le jeton ne fonctionnera pas.	`ghs_`

Erreurs affichées aux utilisateurs bloqués

Les erreurs sont affichées aux utilisateurs lorsque la restriction fonctionne comme prévu. Des erreurs se produisent dans les situations suivantes :

activité web : lorsqu’un utilisateur est bloqué de se connecter ou d’utiliser une session obsolète existante.
activité d’API : lorsqu’un utilisateur tente d’utiliser un jeton associé à un utilisateur en dehors de l’entreprise.
jeton d’installation : Quand une application tente d’utiliser un jeton d’installation pour accéder à une organisation ou un compte d’utilisateur en dehors de l’entreprise. Pour les installations, seules les demandes d’écriture sont bloquées. Les demandes de lecture ne sont pas bloquées sur les ressources en dehors de l’entreprise. Pour en savoir plus sur les jetons d’installation, consultez Installation de l’authentification en tant qu’application GitHub.

Scénario	Code d’erreur	Message
Activité web	403	Votre administrateur réseau a bloqué l'accès à GitHub sauf pour `ENTERPRISE` l'entreprise. Connectez-vous avec votre compte `_SHORTCODE` pour accéder à GitHub.
Activité de l'API	403	Votre administrateur réseau a bloqué l'accès à GitHub sauf pour `ENTERPRISE`l'entreprise. Veuillez utiliser un jeton pour un utilisateur de l'entreprise `_SHORTCODE` pour accéder à GitHub.
Jeton d'installation	403	Votre administrateur réseau a bloqué l'accès à GitHub sauf pour `ENTERPRISE` l'entreprise. Uniquement des jetons pour l'entreprise»`SHORTCODE`» peuvent accéder GitHub.

Les erreurs avec un code 400 indiquent une erreur dans votre configuration. Consultez la rubrique Résolution des problèmes.

Exemple de test localement

Vous pouvez tester votre configuration réseau localement à l’aide d’un outil de débogage web. Cette section présente un exemple d'utilisation de Fiddler. Notez que Fiddler et d’autres outils de débogage externe ne sont pas dans l’étendue des Support GitHub.

Dans l’exemple suivant, vous allez ajouter un certain FiddlerScript à exécuter sur chaque requête.

Installez Fiddler.
Configurez Fiddler pour déchiffrer le trafic HTTPS. Consultez la documentation Fiddler.

Dans Fiddler, accédez à l’onglet « FiddlerScript » et ajoutez le code suivant à la fonction OnBeforeRequest . Définissez la variable enterpriseId sur votre propre ID d’entreprise.

JavaScript

// Your enterprise id
var enterpriseId: String = "YOUR-ID";

 //Inject on the web UI
 if (oSession.HostnameIs("github.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "green";
 }

 // Inject on API calls
 if (oSession.HostnameIs("api.github.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "blue";
     }

 // Inject on Copilot API calls
 if (oSession.HostnameIs("githubcopilot.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "yellow";
 }

// Your enterprise id
var enterpriseId: String = "YOUR-ID";

 //Inject on the web UI
 if (oSession.HostnameIs("github.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "green";
 }

 // Inject on API calls
 if (oSession.HostnameIs("api.github.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "blue";
     }

 // Inject on Copilot API calls
 if (oSession.HostnameIs("githubcopilot.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "yellow";
 }

Cliquez sur Enregistrer le script.

L’en-tête est désormais injecté pour chacun des domaines spécifiés pendant que la capture de paquets est active. Pour activer ou désactiver l’injection, vous pouvez activer ou désactiver la capture de paquets en cliquant sur Fichier > Capturer le trafic.

Vous pouvez activer et désactiver cette injection pour simuler la connexion avec un compte non autorisé, puis entrer le réseau, ou essayer de se connecter à un compte non autorisé pendant qu’il est sur le réseau.

Dépannage

Si votre injection d’en-tête ne fonctionne pas comme prévu, vous verrez des erreurs avec un code 400 lorsque vous essayez d’utiliser des points de terminaison affectés. Elles sont distinctes des erreurs 403 affichées lorsque la fonctionnalité fonctionne comme prévu (voir Erreurs affichées pour les utilisateurs bloqués).

En général, 400 des erreurs se produisent dans les situations suivantes.

L’en-tête utilise un slug non valide ou un ID d’entreprise.
L’en-tête répertorie plusieurs entreprises.
La requête contient plusieurs en-têtes sec-GitHub-allowed-enterprise .

Scénario	Code d’erreur	Message
Code ou identifiant invalide	400	L’entreprise nommée dans l’en-tête `sec-GitHub-allowed-enterprise` est introuvable. Assurez-vous que le « slug d'entreprise » est correctement saisi dans les paramètres du pare-feu ou du proxy. Contactez votre administrateur réseau si cette erreur persiste.
Plusieurs entreprises	400	Une seule entreprise peut être utilisée avec l’en-tête `sec-GitHub-allowed-enterprise` . Vérifiez que seule une seule entreprise et un en-tête sont fournis. Si le problème persiste, contactez votre administrateur réseau
En-têtes multiples	400	Plus d'un `sec-GitHub-allowed-enterprise` a été reçu. Cet en-tête doit être écrasé par le pare-feu ou le proxy, afin de s'assurer qu'une seule entreprise se voit accorder l'accès. Si le problème persiste, contactez votre administrateur réseau.

Pour aller plus loin

Gestion de l’accès de GitHub Copilot au réseau de votre organisation