À propos de ce guide
Ce guide décrit les modifications les plus importantes que vous pouvez apporter pour augmenter la sécurité des comptes. Chaque section décrit une modification que vous pouvez apporter à vos processus pour améliorer la sécurité. Les modifications les plus importantes sont listées en premier.
Quel est le risque ?
La sécurité des comptes est fondamentale pour la sécurité de votre chaîne d'approvisionnement. Si un attaquant peut prendre le contrôle de votre compte sur GitHub Enterprise Cloud, il peut apporter des modifications malveillantes à votre code ou processus de génération. Votre but premier doit donc être de compliquer la tâche à quelqu’un cherchant à prendre le contrôle de votre compte et des comptes des autres membres de votre organisation ou entreprise.
Centraliser l'authentification
Si vous êtes propriétaire d'une entreprise ou d'une organisation, vous pouvez configurer l'authentification centralisée avec SAML. Même si vous pouvez ajouter ou supprimer des membres manuellement, il est plus simple et plus sécurisé de configurer l'authentification unique (SSO) et SCIM entre GitHub Enterprise Cloud et votre fournisseur d'identité SAML (IdP). Cela simplifie également le processus d'authentification pour tous les membres de votre entreprise.
Vous pouvez configurer l'authentification SAML pour un compte d'entreprise ou d'organisation. Avec SAML, vous pouvez accorder l’accès aux comptes personnels des membres de votre entreprise ou organisation sur GitHub via votre fournisseur d’identité, ou vous pouvez créer et contrôler les comptes appartenant à votre entreprise en utilisant Enterprise Managed Users. Pour plus d’informations, consultez « À propos de la gestion de l'identité et de l'accès ».
Une fois que vous avez configuré l'authentification SAML, quand des membres demandent l'accès à vos ressources, ils sont dirigés vers votre flux d'authentification unique afin qu'il soit vérifié qu'ils sont toujours reconnus par votre fournisseur d'identité. S'ils ne sont pas reconnus, leur demande est refusée.
Certains fournisseurs d'identité prennent en charge un protocole appelé SCIM, qui peut provisionner ou déprovisionner automatiquement l'accès sur GitHub Enterprise Cloud quand vous apportez des modifications sur votre fournisseur d'identité. Avec SCIM, vous pouvez simplifier l'administration à mesure que votre équipe croît et vous pouvez révoquer rapidement l'accès aux comptes. SCIM est disponible pour les organisations individuelles sur GitHub Enterprise Cloud ou pour les entreprises qui utilisent Enterprise Managed Users. Pour plus d'informations, consultez « À propos de SCIM pour les organisations ».
Configurer l'authentification à 2 facteurs
Note
À partir de mars 2023, GitHub exige de tous les utilisateurs qui contribuent au code sur GitHub.com qu’ils activent une ou plusieurs formes d’authentification à 2 facteurs (2FA). Si vous faisiez partie d'un groupe éligible, vous auriez reçu un courriel de notification lorsque ce groupe a été sélectionné pour l’inscription, marquant le début d’une période d’inscription 2FA de 45 jours, et vous auriez vu des bannières vous invitant à vous inscrire à 2FA sur GitHub.com. Si vous n'avez pas reçu de notification, vous ne faisiez pas partie d’un groupe requis pour activer 2FA, bien que nous le recommandons vivement.
Pour plus d’informations sur le lancement des inscriptions 2FA, consultez ce billet de blog.
La meilleure façon d’améliorer la sécurité de vos comptes consiste à configurer l’authentification à 2 facteurs (2FA). Les mots de passe eux-mêmes peuvent être compromis en étant devinables, en étant réutilisés sur un autre site compromis ou par l'ingénierie sociale, comme le hameçonnage. L'authentification à 2 facteurs rend beaucoup plus difficile la compromission de vos comptes, même si un attaquant a votre mot de passe.
Pour garantir à la fois la sécurité et un accès fiable à votre compte, vous devez toujours avoir au moins deux identifiants comme second facteur inscrits sur votre compte. Avec des identifiants supplémentaires, vous avez la garantie que même si vous perdez l'accès aux premiers, vous n'êtes pas bloqué hors de votre compte.
Préférez également les clés d'accès, les clés de sécurité aux applications d'authentification (nommées applications TOTP) et à l'utilisation de SMS autant que possible. Les applications 2FA et TOTP basées sur les SMS sont vulnérables à l'hameçonnage et n'offrent pas le même niveau de protection que les clés d'accès et les clés de sécurité. Le SMS n'est plus recommandé dans les instructions du NIST 800-63B sur l'identité numérique.
Si les comptes de service de votre organisation ont été sélectionnés pour l'inscription à l'authentification 2FA par GitHub, leurs jetons et clés continuent de fonctionner après l'échéance sans interruption. Seul l'accès à GitHub via l'interface utilisateur du site web est bloqué tant que le compte n'a pas activé l'authentification 2FA. Nous vous recommandons de configurer TOTP comme deuxième facteur pour les comptes de service et de stocker le secret TOTP exposé lors de la configuration dans le gestionnaire de mots de passe partagé de votre entreprise, avec l'accès aux secrets contrôlé via une authentification unique.
Si vous êtes propriétaire d'entreprise, vous pouvez éventuellement configurer une stratégie afin d'exiger l'authentification à 2 facteurs pour toutes les organisations appartenant à votre entreprise.
Si vous êtes propriétaire d'une organisation, vous pouvez éventuellement exiger que tous les membres de l'organisation activent l'authentification à 2 facteurs.
Pour en savoir plus sur l'activation de l'authentification 2FA sur votre propre compte, consultez « Configuration de l’authentification à 2 facteurs ». Pour en savoir plus sur l'obligation d'avoir une authentification 2FA dans votre organisation, consultez « Exiger l’authentification à deux facteurs dans votre organisation ».
Configurer votre compte d'entreprise
Les propriétaires d'entreprise peuvent éventuellement exiger l'authentification à 2 facteurs pour tous les membres de l'entreprise. La disponibilité des stratégies d'authentification à 2 facteurs sur GitHub Enterprise Cloud dépend de la façon dont les membres s'authentifient pour accéder aux ressources de votre entreprise.
Si votre entreprise utilise Enterprise Managed Users ou que l’authentification SAML est appliquée pour votre entreprise, vous ne pouvez pas configurer l’authentification à 2 facteurs sur GitHub Enterprise Cloud. Une personne disposant d'un accès administratif à votre fournisseur d'identité doit configurer l'authentification à 2 facteurs pour le fournisseur d'identité.
Pour plus d'informations, consultez « À propos de SAML pour la gestion des identités et des accès d'entreprise » et « Application de stratégies pour les paramètres de sécurité dans votre entreprise ».
Configurer votre compte personnel
Note
Selon la méthode d'authentification qu'un propriétaire d'entreprise a configurée, vous ne pourrez peut-être pas activer l'authentification 2FA pour votre compte personnel.
GitHub Enterprise Cloud prend en charge plusieurs options pour l'authentification à 2 facteurs, et même si aucune ne se détache véritablement, l'option la plus sécurisée est un identifiant WebAuthn. WebAuthn nécessite un authentificateur tel qu'une clé de sécurité matérielle FIDO2, un authentificateur de plateforme tel que Windows Hello, un téléphone Apple ou Google, ou un gestionnaire de mots de passe. Il est possible, bien que difficile, d'hameçonner d'autres formes d'authentification à 2 facteurs (par exemple, quelqu'un vous demandant de lui lire votre mot de passe à 6 chiffres unique). Toutefois, WebAuthn est beaucoup plus résistant à l'hameçonnage, car l'étendue du domaine est intégrée au protocole, ce qui empêche les informations d'identification d'un site web imitant la page de connexion d'être utilisées sur GitHub Enterprise Cloud.
Quand vous configurez l'authentification à 2 facteurs, vous devez toujours télécharger les codes de récupération et configurer plusieurs identifiants 2FA. Cela garantit que l'accès à votre compte ne dépend pas d'un seul appareil. Pour plus d'informations, consultez « Configuration de l’authentification à 2 facteurs » et « Configuration de méthodes de récupération pour l’authentification à 2 facteurs ».
Configurer votre compte d'organisation
Note
En fonction de la méthode d'authentification configurée par un propriétaire d'entreprise, il se peut que vous ne puissiez pas exiger le 2FA pour votre organisation.
Si vous êtes propriétaire d'une organisation, vous pouvez voir quels utilisateurs n'ont pas l'authentification à 2 facteurs activée, les aider à la configurer, puis exiger l'authentification à 2 facteurs pour votre organisation. Pour vous guider dans ce processus, consultez :
- « Voir si l’authentification à 2 facteurs (2FA) est activée pour les utilisateurs de votre organisation »
- « Préparation de l’obligation d’une authentification à 2 facteurs dans votre organisation »
- « Exiger l’authentification à deux facteurs dans votre organisation »
Se connecter à GitHub Enterprise Cloud avec des clés SSH
Il existe d’autres façons d’interagir avec GitHub Enterprise Cloud au-delà de la connexion au site web. De nombreuses personnes autorisent le code qu'elles poussent (push) vers GitHub avec une clé privée SSH. Pour plus d’informations, consultez « À propos de SSH ».
Tout comme votre mot de passe de compte, si un attaquant pouvait obtenir votre clé privée SSH, il pourrait emprunter votre identité et pousser du code malveillant vers n’importe quel dépôt auquel vous disposez d’un accès en écriture. Si vous stockez votre clé privée SSH sur un lecteur de disque, il est judicieux de la protéger avec une phrase secrète. Pour plus d'informations, consultez « Utilisation des phrases secrètes de clé SSH ».
Une autre option consiste à générer des clés SSH sur une clé de sécurité matérielle. Vous pouvez utiliser la même clé que celle que vous utilisez pour l'authentification à 2 facteurs. Les clés de sécurité matérielles sont très difficiles à compromettre à distance, car la clé SSH privée reste sur le matériel et n'est pas directement accessible à partir d'un logiciel. Pour plus d'informations, consultez « Génération d’une nouvelle clé SSH et ajout de celle-ci à ssh-agent ».
Les clés SSH matérielles sont assez sécurisées, mais la configuration matérielle requise peut ne pas fonctionner pour certaines organisations. Une autre approche consiste à utiliser des clés SSH qui ne sont valides que pendant une courte période, de sorte que même si la clé privée est compromise, elle ne peut pas être exploitée pendant très longtemps. C'est le concept sur lequel repose l'exécution de votre propre autorité de certification SSH. Même si cette approche vous donne beaucoup de contrôle sur la façon dont les utilisateurs s'authentifient, elle vous impose de gérer vous-même une autorité de certification SSH. Pour plus d'informations, consultez « À propos des autorités de certification SSH ».