Bonnes pratiques pour sécuriser les comptes

À 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 en charge votre compte GitHub, il peut alors apporter des modifications malveillantes à votre code ou processus de génération. Ainsi, votre premier objectif doit être de rendre difficile pour quelqu’un de prendre en charge votre compte et les comptes d’autres utilisateurs membres de votre organisationvotre instance.

Centraliser l’authentification

Si vous êtes propriétaire d’entreprise ou d’organisation, vous pouvez configurer l’authentification centralisée avec SAML. Bien que vous puissiez ajouter ou supprimer manuellement des membres, il est plus simple et plus sécurisé de configurer l’authentification unique (SSO) et SCIM entre GitHub 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 de votre organisation sur GitHub via votre IdP, ou vous pouvez créer et contrôler les comptes de votre entreprise à l’aide de Enterprise Managed Users. Pour plus d’informations, consultez « Notions de base de la gestion des identités et des 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 IdP prennent en charge un protocole appelé SCIM, qui peut provisionner ou déprovisionner automatiquement les accès sur GitHub lorsque vous effectuez des modifications dans votre IdP. 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 Enterpriseou pour les entreprises qui utilisent Enterprise Managed Users. Pour plus d’informations, consultez « À propos de SCIM pour les organisations ».

Configurer l’authentification à 2 facteurs

La meilleure façon d’améliorer la sécurité de votre compte de configurer l’authentification à deux 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. Les informations d’identification supplémentaires garantissent que même si vous perdez l’accès à une information d’identification, vous ne serez pas verrouillé de votre compte.

Préférez également les clés d'accès et de sécurité aux applications d’authentification (appelées applications TOTP), et évitez l’utilisation de SMS chaque fois que c’est 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 2FA par GitHub, leurs jetons et clés continueront de fonctionner après l’échéance sans interruption. Seul l’accès à GitHub via l’interface utilisateur du site sera bloqué jusqu’à ce que le compte ait activé l’authentification à deux facteurs. 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 configurer une stratégie pour exiger 2FA pour toutes les organisations appartenant à votre entreprise.

Si vous êtes propriétaire d’une organisation, vous être en mesure de demander à tous les membres de l’organisation d’activer 2FA.

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 exiger l’authentification à deux facteurs (2FA) pour tous les l’instance. La disponibilité des stratégies 2FA GitHub dépend de la façon dont s’authentifient pour accéder aux ressourcesinstanced’entreprise.

Si votre entreprise utilise Enterprise Managed Users ou que l’authentification SAML est appliquée pour votre entreprise, vous ne pouvez pas configurer 2FA sur GitHub. 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

GitHub prend en charge plusieurs options pour 2FA et, même si l’une d’elles est meilleure que rien, l’option la plus sécurisée est des informations d’identification 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 au 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 empruntant l’identité de la page de connexion d’être utilisée sur GitHub.

Quand vous configurez l’authentification à 2 facteurs, vous devez toujours télécharger les codes de récupération et configurer plusieurs informations d'identification à 2 facteurs. 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’entreprise

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 :

1. Voir si l’authentification à 2 facteurs (2FA) est activée pour les utilisateurs de votre organisation
2. Préparation de l’obligation d’une authentification à 2 facteurs dans votre organisation
3. Exiger l’authentification à deux facteurs dans votre organisation

Se connecter à GitHub à l’aide de clés SSH

Il existe d’autres façons d’interagir avec GitHub au-delà de la connexion au site web. De nombreuses personnes signent le code qu’elles envoient vers GitHub à l’aide d’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 mots de passe 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 sauvegardées par le matériel 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 ».

Étapes suivantes

• Sécurisation de votre chaîne d’approvisionnement de bout en bout
• Bonnes pratiques pour sécuriser le code dans votre chaîne d’approvisionnement
• Bonnes pratiques pour sécuriser votre système de génération
• Bonnes pratiques pour empêcher les fuites de données dans votre organisation