Comment sécuriser votre référentiel Git avec des commits et des balises signés
Agence web » Actualités du digital » Comment sécuriser votre référentiel Git avec des commits et des balises signés

Comment sécuriser votre référentiel Git avec des commits et des balises signés

Les référentiels Git stockent un code source précieux et sont utilisés pour créer des applications qui fonctionnent avec des données sensibles. Si un attaquant était capable de compromettre un compte GitHub avec un référentiel vulnérable, il pourrait pousser les commits malveillants directement en production. Les commits signés aident à garantir que cela ne se produise pas.

Que sont les commits signés ?

Les validations signées impliquent l’ajout d’une signature numérique à vos validations, à l’aide d’une clé cryptographique privée, généralement GPG, bien qu’elle prenne également en charge SSH ou X.509. Une fois créée, vous devez ajouter la clé de signature à la fois à votre profil GitHub et à votre client Git local.

Les commits signés fournissent une couche de sécurité supplémentaire en garantissant que le commit n’a pas été falsifié et, plus important encore, qu’il provient d’une source de confiance qui possède à la fois la clé GPG et a le pouvoir d’accéder au compte GitHub.

Pour pousser les commits vers un référentiel qui n’autorise que les commits signés, l’attaquant doit pouvoir compromettre la clé GPG privée de la victime, ce qui signifie généralement avoir accès à l’ensemble de son ordinateur, pas seulement à son compte GitHub. Comme il s’agit d’un vecteur d’attaque assez rare et difficile, les commits signés fournissent un excellent moyen de vérifier que les commits proviennent de qui ils prétendent être.

Configuration d’une nouvelle clé GPG

Tout d’abord, vous devrez créer une nouvelle clé GPG utilisée pour la signature, puis vous devrez en informer à la fois votre client Git et GitHub.

Pour générer la clé, vous aurez besoin du gpg commande installée sur votre système. Cela devrait être là par défaut, mais si ce n’est pas le cas, vous pouvez l’obtenir auprès de votre gestionnaire de packages. Ensuite, vous pouvez générer une nouvelle clé :

gpg --full-generate-key

Vous pouvez appuyer sur Entrée pour la plupart des invites, mais vous devez entrer une phrase secrète et vous devez entrer votre adresse e-mail GitHub. Si vous souhaitez que votre adresse soit privée, vous pouvez utiliser l’adresse « sans réponse » de votre compte GitHub.

Ensuite, répertoriez les clés et exportez le bloc de clé publique pour l’ID de clé que vous venez de créer :

gpg --list-secret-keys
gpg --armor --export [keyID]

Ensuite, nous l’ajouterons à votre compte GitHub. Dans vos paramètres utilisateur, cliquez sur « Clés SSH et GPG » et ajoutez une nouvelle clé GPG. Vous pouvez également activer le mode Vigilant ici, qui marquera les commits sur GitHub n’utilisant pas ces clés comme non vérifiés.

Définissez un nom et collez-le dans le bloc de clé publique que vous avez exporté avec gpg --export.

Ensuite, informez votre client Git local de votre clé. Si vous utilisez un client GUI Git comme GitKraken, vous pourrez peut-être simplement l’importer, mais sinon, vous devrez le faire à partir de la ligne de commande.

Étant donné que cela est lié à votre utilisateur, vous souhaiterez probablement le définir en tant que configuration globale, mais vous pouvez également utiliser des configurations au niveau du référentiel. Ensemble user.signingkey à l’ID de clé GPG que vous avez utilisé pour exporter.

git config --global user.signingkey [keyID]

Ensuite, vous voudrez dire à Git de signer tous les commits par défaut. Cela peut être défini pour des référentiels individuels si vous le souhaitez :

git config --global commit.gpgsign true

Sinon, vous pouvez utiliser le -S flag pour signer les commits manuellement.

Application des engagements signés avec la protection de branche

Les règles de protection des branches appliquent des restrictions et des directives sur des branches spécifiques de votre référentiel. Bien qu’ils soient couramment utilisés pour appliquer une demande d’extraction et un flux de travail de fusion spécifiques, et restreindre l’accès aux branches de publication, ils peuvent également être configurés pour n’accepter que les validations signées.

Seul le fait d’accepter des commits signés fournit une couche de sécurité supplémentaire et oblige chaque contributeur à avoir une clé GPG associée à son compte.

Il est facile de créer une nouvelle règle de protection de branche à partir de l’onglet « Branches » dans les paramètres de votre référentiel. Vous voudrez définir le filtre sur « * » pour inclure toutes les branches.

Sélectionnez ensuite « Exiger des commits signés ».

À partir de maintenant, tous les commits poussés vers toutes les branches de ce référentiel doivent contenir des signatures de signature GPG.

★★★★★