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 le contrôle de votre compte sur GitHub Enterprise Server, 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 utilisateurs de votre instance.

Centraliser l'authentification

Si vous êtes l'administrateur de site de votre instance, vous pouvez simplifier l'expérience de connexion des utilisateurs en choisissant une méthode d'authentification qui se connecte avec votre IdP (fournisseur d'identité) existant, par exemple CAS, SAML ou LDAP. Cela signifie qu'ils n'ont plus besoin de mémoriser un mot de passe supplémentaire pour GitHub.

Certaines méthodes d'authentification prennent également en charge la communication d'informations supplémentaires à GitHub Enterprise Server, par exemple, les groupes dont l'utilisateur est membre ou la synchronisation des clés de chiffrement pour l'utilisateur. Il s'agit d'un excellent moyen de simplifier votre administration au fur et à mesure que votre organisation croît.

Pour plus d’informations sur les méthodes d’authentification disponibles pour GitHub Enterprise Server, consultez À propos de la gestion de l'identité et de l'accès.

Configurer l'authentification à 2 facteurs

La meilleure façon d’améliorer la sécurité de votre compte personnel ou votre instance 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.

Si vous êtes l'administrateur de site de votre instance, vous pouvez configurer l'authentification 2FA pour tous les utilisateurs de votre instance. La disponibilité de l'authentification à 2 facteurs sur GitHub Enterprise Server dépend de la méthode d'authentification que vous utilisez. Pour plus d’informations, consultez Centraliser l’authentification.

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 utilisateurs sur l'instance. La disponibilité des stratégies d'authentification à 2 facteurs sur GitHub Enterprise Server dépend de la façon dont les utilisateurs s'authentifient pour accéder à votre instance.

Si vous vous connectez à GitHub Enterprise Server via un fournisseur d’identité externe en utilisant l’authentification CAS ou SAML SSO, vous ne pouvez pas configurer l’authentification à 2 facteurs sur GitHub Enterprise Server. Une personne disposant d'un accès administratif à votre fournisseur d'identité doit configurer l'authentification à 2 facteurs pour le fournisseur d'identité.
Si vous vous connectez à GitHub Enterprise Server via un annuaire LDAP externe, vous pouvez exiger l’authentification à 2 facteurs pour votre entreprise sur GitHub Enterprise Server. Si vous autorisez l'authentification intégrée pour les utilisateurs en dehors de votre annuaire, les utilisateurs individuels peuvent activer l'authentification à 2 facteurs, mais vous ne pouvez pas exiger l'authentification à 2 facteurs pour votre entreprise.

Pour plus d’informations, consultez 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 administrateur de site a configurée, vous ne pourrez peut-être pas activer l'authentification 2FA pour votre compte personnel.

GitHub Enterprise Server 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 Server.

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 administrateur de site, 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 :

Se connecter à GitHub Enterprise Server avec des clés SSH

Il existe d’autres façons d’interagir avec GitHub Enterprise Server 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 ».