Sécurité
du dépôt
Le code source et le dépôt GitOps donnent accès à la production. Ils se protègent comme elle.
Appliquer à GitLab et aux postes de développement les mesures du guide d’hygiène informatique de l’ANSSI et du guide CPME-ANSSI, traduites en gestes concrets.
Aucun secret dans Git
Mots de passe, jetons d’API, clés privées, clés JWT, chaînes de connexion et fichiers .env ne doivent apparaître ni dans le code, ni dans l’historique, ni dans les merge requests, ni dans les tickets.
| Où mettre les secrets | Comment |
|---|---|
| Pipelines GitLab | Variables CI/CD masquées et protégées (Paramètres › CI/CD › Variables) |
| Kubernetes | Secrets provisionnés dans le namespace, jamais versionnés dans le dépôt GitOps |
| Développement local | Fichier .env ignoré, avec un .env.example versionné sans valeurs |
| Partage entre collègues | Gestionnaire de mots de passe de l’équipe, jamais par messagerie ou dans un ticket |
Les valeurs par défaut versionnées (application.yml, environment.ts) sont des valeurs de développement, jamais exploitables en production. Elles sont toujours surchargées en recette et en production (ANSSI, mesure 12).
Détecter avant qu’il soit trop tard
# analyser le dépôt et tout son historique
gitleaks git -v
# analyser les modifications indexées, avant chaque commit
gitleaks git --pre-commit --staged
gitleaks s’installe en hook pre-commit. Côté serveur, le modèle Secret Detection de GitLab analyse chaque pipeline :
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
Si un secret a été poussé
- Révoquer et régénérer le secret immédiatement. C’est l’étape qui compte : réécrire l’historique ne suffit pas, le secret est déjà dans des clones, des caches et des journaux de pipeline.
- Remplacer le secret partout où il est utilisé : variables CI, secrets Kubernetes, postes.
- Nettoyer l’historique si nécessaire avec git filter-repo, en coordination avec l’équipe, car tous les clones devront être refaits.
- Déclarer l’incident au référent sécurité.
S’authentifier
| Mesure | Mise en œuvre | Source |
|---|---|---|
| Double authentification | Obligatoire sur GitLab. Application TOTP ou clé de sécurité physique, jamais le SMS | ANSSI, mesure 13 |
| Mot de passe unique | Mot de passe GitLab utilisé nulle part ailleurs, rangé dans un gestionnaire de mots de passe | ANSSI, mesures 10 et 11 ; CPME, règle 1 |
| Clé SSH protégée | Clé Ed25519 avec phrase de passe, une clé par poste, date d’expiration dans GitLab | ANSSI, mesures 11 et 21 |
| Pas d’identifiants en clair | Jamais de jeton dans l’URL d’un dépôt ni dans ~/.git-credentials : gestionnaire d’identifiants chiffré | ANSSI, mesure 11 |
| Jetons personnels limités | Portée minimale (read_repository plutôt que api) et expiration courte | ANSSI, mesure 8 |
| Comptes de service dédiés | CI et ArgoCD utilisent des deploy tokens ou jetons de projet nommés explicitement, jamais le jeton d’une personne | ANSSI, mesures 5 et 8 |
Rangez les codes de récupération de la double authentification dans le gestionnaire de mots de passe, et verrouillez le téléphone qui porte l’application TOTP.
Gérer les droits
- Comptes nominatifs : aucun compte GitLab partagé. Chaque commit est attribuable à une personne (ANSSI, mesure 8).
- Moindre privilège : rôle Developer par défaut, Maintainer pour les responsables techniques, Owner à titre exceptionnel, attribués au niveau du groupe (ANSSI, mesures 9 et 29).
- Branches protégées et merge requests obligatoires : voir Branches & workflow.
- Dépôt GitOps plus fermé que les dépôts applicatifs : pouvoir y fusionner sur
prod, c’est pouvoir déployer en production. - Visibilité : aucun dépôt public. Le code des clients reste interne.
- Revue des accès chaque trimestre : membres, mainteneurs, jetons, clés de déploiement (ANSSI, mesure 5).
Arrivées et départs
| Moment | Actions | Source |
|---|---|---|
| Arrivée | Compte nominatif, rôle minimal, double authentification dès le premier jour, lecture de ces guides | ANSSI, mesures 1, 6 et 13 |
| Changement de mission | Retrait des groupes du projet précédent | ANSSI, mesure 6 |
| Départ | Blocage du compte (plutôt que suppression, pour garder l’historique), révocation des jetons et clés SSH, reprise des pipelines programmés, changement des secrets partagés qu’il connaissait | ANSSI, mesure 6 ; CPME, règle 3 |
| Stagiaire ou prestataire | Date d’expiration sur l’adhésion au groupe | ANSSI, mesure 6 |
Protéger le poste de développement
- Disque chiffré, verrouillage automatique de la session, pare-feu actif (ANSSI, mesures 14 et 31).
- Mises à jour de sécurité du système, de Git, de l’IDE et des outils appliquées rapidement (ANSSI, mesure 34 ; CPME, règle 2).
- Logiciels et dépendances téléchargés depuis les sources officielles uniquement. Attention aux paquets npm ou Maven au nom proche d’un paquet connu (CPME, règle 9).
- Serveurs de développement (
8080,4200) accessibles en local uniquement. - Séparer les usages : pas de code client sur un poste ou un compte personnel, pas de copie vers un GitHub personnel, pas de code collé dans des outils en ligne non validés (CPME, règle 11).
- Hors des locaux : connexion par le VPN, jamais de Wi-Fi public sans VPN (ANSSI, mesure 32 ; CPME, règle 7).
- Poste perdu ou volé : prévenir immédiatement, révoquer ses clés SSH et ses jetons.
Pour séparer identité professionnelle et personnelle sur un même poste :
# ~/.gitconfig
[includeIf "gitdir:~/Documents/"]
path = ~/.gitconfig-agitex
Maintenir les dépendances à jour
- Fichiers de verrouillage (
package-lock.json) commités, installation parnpm cien CI. - Analyse des dépendances vulnérables en CI :
npm audit, Dependency Scanning de GitLab, mises à jour proposées par Renovate. - Suivi des fins de support de Spring Boot, Angular, du JDK, de Node et des images Docker de base (ANSSI, mesure 35).
Sauvegarder
Un clone n’est pas une sauvegarde : il ne contient ni les tickets, ni les merge requests, ni les variables CI, ni le registre d’images (ANSSI, mesure 37 ; CPME, règle 4).
- Sauvegarde planifiée de l’instance GitLab, avec ses fichiers de secrets, conservée hors site et chiffrée.
- Restauration testée au moins une fois par an.
Réagir à un incident
| Situation | Premiers gestes |
|---|---|
| Secret poussé dans un dépôt | Révoquer et régénérer, puis nettoyer (voir plus haut) |
| Compte GitLab compromis | Bloquer le compte, révoquer jetons et clés, contrôler les MR, pipelines et réglages récents |
| Poste compromis | Le débrancher du réseau sans l’éteindre, prévenir le référent sécurité par téléphone |
Dans tous les cas, prévenez le référent sécurité et consignez l’incident (ANSSI, mesures 39 et 40 ; CPME, « En cas d’incident »).