GitHub Enterprise : inventorier vos accès sensibles

L’inventaire des accès GitHub Enterprise donne enfin une vue exportable des identifiants qui peuvent atteindre une organisation. Cette nouveauté de GitHub Enterprise Cloud aide les responsables à partir de faits vérifiables lors d’un incident : quels jetons, clés SSH ou applications sont concernés, qui les possède, quels droits portent-ils et quand ont-ils été utilisés ? Elle ne remplace ni la révocation ni l’enquête ; elle rend ces décisions plus rapides et plus proportionnées.

Un inventaire des accès GitHub Enterprise, pas un simple fichier CSV

GitHub permet désormais aux propriétaires d’entreprise, ainsi qu’aux personnes disposant de la permission fine View enterprise credentials, d’exporter l’inventaire des identifiants rattachés à l’entreprise. Il couvre notamment les clés SSH, les jetons d’accès personnels classiques ou granulaires, les jetons OAuth et les jetons utilisateur-à-serveur ou d’installation des GitHub Apps.

L’export peut être téléchargé depuis les réglages d’entreprise ou récupéré au moyen d’une API REST paginée. Chaque entrée fournit des éléments utiles à l’arbitrage : propriétaire, portées et permissions, dates de création et d’expiration, dernière utilisation, ainsi que les organisations ou dépôts ciblés. La disponibilité annoncée est immédiate pour GitHub Enterprise Cloud ; le support GitHub Enterprise Server est prévu dans de prochaines versions.

Préparer une réponse à incident qui reste lisible

Un soupçon d’exposition de jeton pousse souvent à faire deux erreurs opposées : couper trop largement des accès indispensables, ou attendre parce qu’il est difficile d’évaluer le périmètre. Un inventaire ne tranche pas seul, mais il permet de construire une liste de travail traçable avant les actions irréversibles.

Un déroulé pragmatique

1. Définir le scénario à examiner. Distinguez un identifiant exposé, le départ d’un collaborateur, une application compromise ou un audit périodique : le niveau d’urgence et les données nécessaires diffèrent.
2. Extraire un périmètre minimal. Filtrez par type d’accès, utilisateur, application ou organisation avant de partager le résultat. L’export lui-même reste une donnée de sécurité à protéger.
3. Croiser avec les journaux d’audit. GitHub indique que l’inventaire peut être corrélé aux événements d’audit. Cette étape sépare un accès ancien mais inactif d’un identifiant encore utilisé.
4. Décider, puis vérifier. Révoquez ou remplacez l’accès ciblé, contrôlez les automatisations qui en dépendaient et conservez la justification de l’action menée.

Éviter les faux raccourcis de gouvernance

Voir un identifiant ne signifie pas qu’il faut le supprimer. Une clé SSH peut être nécessaire à une intégration, un jeton d’application peut desservir plusieurs dépôts et une dernière utilisation ne démontre pas à elle seule la légitimité d’un accès. La bonne règle est de relier chaque décision à un propriétaire, une finalité, un périmètre et une preuve de continuité pour le service concerné.

Commencez avec un exercice limité : sélectionnez une organisation, vérifiez le format de l’export, documentez qui peut y accéder et testez le parcours de remplacement d’un identifiant non critique. Vous obtenez ainsi une procédure exploitable avant qu’un incident impose de travailler dans l’urgence.

Faire de la visibilité un réflexe de sécurité

L’inventaire des accès GitHub Enterprise devient utile quand il s’intègre à une routine : revue des propriétaires, échéances d’expiration, suivi des applications et rapprochement avec les journaux d’audit. La publication officielle GitHub détaille les types d’identifiants, les permissions et les deux modes d’export disponibles.