À propos de ce guide
En tant que propriétaire d’une organisation, empêcher l’exposition de données privées ou sensibles doit être une priorité absolue. Qu’elles soient intentionnelles ou accidentelles, les fuites de données peuvent entraîner un risque important pour les parties concernées. Bien que GitHub prenne des mesures pour vous protéger contre les fuites de données, vous êtes également responsable de l’administration de votre organisation pour renforcer la sécurité.
Quand il s’agit de se défendre contre les fuites de données, il y a plusieurs composants importants :
- Adopter une approche proactive en matière de prévention
- Détection précoce des fuites possibles
- Gestion d’un plan d’atténuation quand un incident se produit
La meilleure approche va dépendre du type d’organisation que vous gérez. Par exemple, un organisation qui se concentre sur le développement open source peut nécessiter des contrôles plus relâchés qu’une organisation entièrement commerciale pour permettre une collaboration externe. Cet article fournit des conseils généraux sur les fonctionnalités et les paramètres de GitHub à prendre en compte, que vous devez implémenter en fonction de vos besoins.
Sécuriser les comptes
Protégez les référentiels et les paramètres de votre organisation en implémentant les meilleures pratiques de sécurité, notamment en activant l’authentification à 2 facteurs et en la rendant obligatoire pour l’ensemble des membres, ainsi qu’en établissant des instructions de mot de passe forts.
- Activer des processus d’authentification sécurisés en utilisant des intégrations SAML et SCIM ainsi que l’authentification à 2 facteurs dans la mesure du possible. Pour plus d’informations, consultez « À propos de la gestion des identités et des accès avec l’authentification unique SAML », « À propos de SCIM pour les organisations » et « Sécurisation de votre compte avec l’authentification à 2 facteurs ».
-
Exiger des membres de l’organisation, des collaborateurs externes et des responsables de facturation d’activer l’authentification à 2 facteurs pour leurs comptes personnels, ce qui complique l’accès des acteurs malveillants aux dépôts et aux paramètres d’une organisation. Il s’agit d’une étape supplémentaire dans l’activation de l’authentification sécurisée. Pour plus d’informations, consultez « Exiger l’authentification à deux facteurs dans votre organisation ».
-
Encouragez vos utilisateurs à créer des mots de passe forts et à les sécuriser de façon appropriée, en suivant les conseils sur les mots de passe recommandés par GitHub. Pour plus d’informations, consultez « Création d’un mot de passe fort ».
-
Encouragez vos utilisateurs à maintenir la protection push pour les utilisateurs activée dans les paramètres de leur compte personnel, de sorte qu’ils soient protégés, quel que soit le dépôt public vers lequel ils effectuent leur envoi (push). Pour plus d’informations, consultez « Protection par émission de données pour les utilisateurs ».
-
Établir d’une stratégie de sécurité interne dans GitHub, afin que les utilisateurs sachent quelles mesures prendre et qui contacter en cas de suspicion d’incident. Pour plus d’informations, consultez « Ajout d’une stratégie de sécurité à votre dépôt ».
Pour plus d’informations sur la sécurisation des comptes, consultez « Bonnes pratiques pour sécuriser les comptes ».
Empêcher les fuites de données
En tant que propriétaire d’une organisation, vous devez limiter et réviser les accès en fonction du type de votre organisation. Prenez en compte les paramètres suivants pour un contrôle plus strict :
| Recommandation | Plus d’informations |
|---|---|
| Désactivez la possibilité de dupliquer des dépôts. | « Gestion de la stratégie de duplication pour votre référentiel » |
| Désactivez la modification de la visibilité des dépôts. | « Restriction des changements de visibilité des dépôts dans votre organisation » |
| Limitez la création de dépôts au seul niveau privé ou interne. | « Restriction de création de dépôts dans votre organisation » |
| Désactivez la suppression et le transfert de dépôts. | « Définition des autorisations pour la suppression ou le transfert de référentiels » |
| Désactivez la possibilité d’utiliser des clé de déploiement. | « Restriction des clés de déploiement dans votre organisation » |
| Limitez personal access token aux autorisations minimales nécessaires. | None |
| Sécurisez votre code en convertissant les dépôts publics en dépôts privés quand c’est approprié. Vous pouvez alerter automatiquement les propriétaires de dépôt de cette modification en utilisant une GitHub App. | Prevent-Public-Repos dans GitHub Marketplace |
| Confirmez l’identité de votre organisation en vérifiant votre domaine et en limitant les notifications par e-mail aux seuls domaines de messagerie vérifiés. | « Vérification ou approbation d’un domaine pour votre organisation » et « Limitation des notifications par e-mail de l’organisation » |
| Vérifiez que vos organisations ont effectué la mise à niveau vers le contrat client GitHub plutôt que d’employer les conditions standard d’utilisation du service. | "Mise à niveau vers le contrat client GitHub" |
| Empêchez les contributeurs d’effectuer des commits accidentels. | « Suppression de données sensibles dans un dépôt » |
Détecter les fuites de données
Quelle que soit l’efficacité avec laquelle vous protégez votre organisation contre les fuites de données, certaines fuites peuvent toujours se produire, et vous pouvez y répondre en utilisant secret scanning, le journal d’audit et des règles de protection des branches.
Utiliser secret scanning
Secret scanning permet de sécuriser le code et de préserver la sécurité des secrets dans les organisations et les dépôts en analysant et en détectant les secrets qui ont été accidentellement commités dans l’historique Git complet de chaque branche des dépôts GitHub. Les chaînes qui correspondent à des modèles fournis par des partenaires d’analyse des secrets, par d’autres fournisseurs de services, ou définis par vous ou votre organisation, sont signalées en tant qu’alertes dans l’onglet Sécurité des dépôts.
Deux formes de secret scanning sont disponibles : Alertes d’analyse des secrets pour les partenaires et Alertes d’analyse des secrets pour les utilisateurs .
-
Alertes d’analyse des secrets pour les partenaires : elles sont activées par défaut et s’exécutent automatiquement sur tous les dépôts publics et packages npm publics.
-
Alertes d’analyse des secrets pour les utilisateurs : pour bénéficier de fonctionnalités d’analyse supplémentaires pour votre organisation, vous devez activer les alertes d’analyse des secrets pour les utilisateurs.
Quand elles sont activées, les alertes d’analyse des secrets pour les utilisateurs peuvent être détectées sur les types de dépôts suivants :
- Dépôts publics appartenant à des organisations qui utilisent GitHub Enterprise Cloud (gratuitement)
- Dépôts privés et internes quand vous disposez d’une licence pour GitHub Advanced Security
Pour plus d’informations sur secret scanning, consultez « À propos de l’analyse des secrets ».
Vous pouvez également activer l’secret scanning en tant que protection des poussées (push) pour un dépôt ou une organisation. Quand vous activez cette fonctionnalité, l’secret scanning empêche les contributeurs de pousser du code comportant un secret détecté. Pour plus d’informations, consultez « À propos de la protection push ». Enfin, vous pouvez aussi étendre la détection pour y inclure des structures de chaînes de secrets personnalisées. Pour plus d’informations, consultez « Définition de modèles personnalisés pour l’analyse des secrets ».
Passer en revue le journal d’audit pour votre organisation
Vous pouvez aussi sécuriser de façon proactive les adresses IP et maintenir la conformité de votre organisation en tirant parti du journal d’audit de votre organisation ainsi que de l’API Journal d’audit GraphQL. Pour plus d’informations, consultez « Examen du journal d’audit de votre organisation » et « Interfaces ».
Configurer des règles de protection des branches
Pour garantir que tout le code est correctement révisé avant d’être fusionné dans la branche par défaut, vous pouvez activer la protection de branche. En définissant des règles de protection de branche, vous pouvez appliquer certains workflows ou certaines exigences avant qu’un contributeur puisse envoyer des modifications. Pour plus d’informations, consultez « À propos des branches protégées ».
En guise d’alternative aux règles de protection de branche, vous pouvez créer des ensembles de règles. Les ensembles de règles présentent quelques avantages par rapport aux règles de protection des branches, telles que les états et une meilleure détectabilité sans nécessiter d’accès administrateur. Vous pouvez également appliquer plusieurs ensembles de règles en même temps. Pour plus d’informations, consultez « À propos des ensembles de règles ».
Atténuer les fuites de données
Si un utilisateur envoie des données sensibles, demandez-lui de les supprimer en utilisant l’outil git filter-repo ou de l’outil open source BFG Repo-Cleaner. Pour plus d’informations, consultez « Suppression de données sensibles dans un dépôt ». En outre, il est possible de rétablir presque tout dans Git. Pour plus d’informations, consultez the GitHub Blog.
Au niveau de l’organisation, si vous ne parvenez pas à vous coordonner avec l’utilisateur qui a envoyé les données sensibles pour les supprimer, nous vous recommandons de contacter le avec le SHA du commit concerné.
Si vous ne parvenez pas à vous coordonner directement avec le propriétaire du dépôt pour supprimer les données dont vous êtes certain d’être propriétaire, vous pouvez remplir un formulaire de suppression DMCA et en informer le support GitHub. Pour plus d’informations, consultez Avis de retrait DMCA.
Note
Si un de vos dépôts a été supprimé en raison d’une fausse revendication, vous devez remplir un formulaire de notification de compteur DMCA et alerter le support GitHub. Pour plus d’informations, consultez Avis de compteur DMCA.