Mise à jour : 16 décembre 2024

Lecture : 8 min

Séparation des tâches et conformité avec GitLab

Maintenez la conformité sans compromettre la rapidité de développement grâce à votre plateforme DevSecOps.

Découvrez dans cet article les différentes façons de garantir la séparation des tâches ainsi que la sécurité et conformité logicielle continue avec la plateforme DevSecOps de GitLab. Définissons tout d'abord deux concepts clés.

La conformité désigne le fait de respecter les directives et les spécifications définies par votre entreprise ou par un organisme réglementaire. Elle permet de préserver l'éthique de l'entreprise, d'appliquer des stratégies d'utilisation appropriées, de respecter les normes de sécurité et plus largement, de protéger les utilisateurs.

Il s'agit d'un aspect fondamental, car les manquements peuvent entraîner des sanctions juridiques et financières importantes. Parallèlement, les équipes DevSecOps doivent également conjuguer vélocité de développement soutenue, simplicité, visibilité et contrôle.

La séparation des tâches vise à confier une tâche à plusieurs acteurs afin de limiter les risques d'erreurs et de bloquer les activités malveillantes. Lorsque cette approche s'applique, chaque tâche ne peut être effectuée que par les rôles les plus adaptés. Prenons un exemple incluant les rôles suivants, chacun doté d'un objectif spécifique :

  • Un développeur est responsable de la création de nouvelles fonctionnalités.
  • Un responsable de la conformité est chargé de créer et d'imposer l'utilisation d'un pipeline CI/CD.
  • Un ingénieur en sécurité applicative a pour mission d'approuver les merge requests comportant des vulnérabilités

En tenant compte de cette répartition des rôles, nous pouvons nous assurer qu'un développeur ne puisse pas modifier un pipeline CI/CD en cours d'exécution. Cette tâche est en effet réservée au responsable de la conformité, qui veille à ce que seul le code conforme puisse être fusionné sans nécessiter d'approbation supplémentaire.

L'ingénieur en sécurité applicative quant à lui est chargé de vérifier et d'approuver (ou pas) si le code comportant des vulnérabilités peut tout de même être fusionné. Il met en place des mesures d'atténuation appropriées afin d'éviter toute mauvaise surprise lorsque le code atteint l'environnement de production. Dans ce scénario, les développeurs ne peuvent pas fusionner le code tant que les exigences de conformité et de sécurité ne sont pas satisfaites.

Stratégies de sécurité

GitLab propose des stratégies de sécurité qui permettent aux équipes de sécurité d'exiger l'exécution de scans de sécurité conformément à une configuration spécifique, pour garantir que les scans n'ont pas été modifiés ou désactivés.

Les stratégies de sécurité peuvent être associées à des frameworks de conformité spécifiques et, dans ce cas, votre projet intègre des exigences de conformité plus strictes et nécessite une supervision supplémentaire. Ce label de conformité peut être créé dans Sécurisation > Centre de conformité > Frameworks au niveau de votre groupe principal.

Label du framework de conformité

Remarque : les labels de conformité ne peuvent être attribués qu'à des projets du groupe principal dans lequel ils sont créés.

Il existe trois types de stratégies : les stratégies d'exécution des scans, les politiques d'approbation des merge requests et les stratégies d'exécution des pipelines.

  • Stratégies d'exécution des scans : elles exigent l'exécution de scans de sécurité à une fréquence prédéfinie ou à chaque pipeline du projet.
  • Politiques d'approbation des merge requests : elles permettent de prendre des mesures en fonction des résultats des scans, par exemple en exigeant l'approbation de l'équipe de sécurité avant tout merge.
  • Stratégies d'exécution des pipelines : elles imposent l'exécution de certains jobs CI/CD pour les projets concernés.

Configurez-les dans l'Éditeur de stratégie de GitLab en suivant quelques étapes simples.

Exécution du scan

  1. Accédez à Sécurité et conformité > Stratégies.

  2. Créez une nouvelle stratégie en cliquant sur le bouton Nouvelle stratégie.

  3. Sélectionnez Exécution des scans.

  4. Créez la règle. Dans cet exemple, nous créons une règle qui exige qu'un SAST soit configuré pour qu'un pipeline puisse s'exécuter.

name: force_sast
description: 'require sast to run'
enabled: true
rules:
- type: pipeline branches: - main actions:
- scan: sast
  1. Soumettez la stratégie en créant une merge request, puis fusionnez-la.

L'ensemble des modifications apportées à la stratégie d'exécution des scans sont appliquées par le biais d'une tâche en arrière-plan qui s'exécute toutes les 10 minutes. Patientez le temps nécessaire pour que les modifications prennent effet après leur validation.

  1. Essayez ensuite d'exécuter votre pipeline. Celui-ci ne s'exécutera que si le SAST est correctement défini dans le fichier YAML.

Remarque : vous pouvez également forcer l'exécution d'un SAST à intervalles réguliers. Consultez la documentation dédiée aux stratégies d'exécution des scans pour en savoir plus.

Politique d'approbation des merge requests

  1. Accédez à Sécurisation > Stratégies.

  2. Créez une nouvelle stratégie en cliquant sur le bouton Nouvelle stratégie.

  3. Sélectionnez Politique d'approbation des merge requests.

  4. Définissez la portée de cette politique d'approbation.

  5. Créez la règle.

mise à jour de la séparation des tâches - image 1

  1. Ajoutez l'action à effectuer.

mise à jour de la séparation des tâches - image 2

Remarque : la politique d'approbation des merge requests est appliquée en fonction des règles que vous avez définies. Si celles-ci ne sont pas valides ou inexploitables, alors GitLab exige une approbation manuelle. Pour éviter ce blocage automatique, vous pouvez modifier le champ « Comportement par défaut en cas d'erreur » et le régler sur open.

mise à jour de la séparation des tâches - image 3

  1. Soumettez votre politique d'approbation en créant une merge request, puis en effectuant un merge.

  2. Créez ensuite une merge request distincte contenant des vulnérabilités.

Consultez la section Workflow de développement de l'atelier DevSecOps Workshop de GitLab.

  1. Vérifiez que la politique d'approbation des merge requests s'applique en consultant votre merge request.

Stratégie d'exécution des pipelines

Pour configurer une stratégie d'exécution des pipelines, vous devez d'abord créer un projet contenant les fichiers CI que vous souhaitez exécuter. Assurez-vous de limiter l'accès à l'équipe de sécurité et/ou à l'administrateur pour garantir la séparation des tâches. Nous avons créé un projet intitulé « Conformité et déploiement », qui contient le fichier YAML que nous souhaitons appliquer.

  1. Accédez à Sécurisation > Politiques.

  2. Cliquez sur le bouton Nouvelle stratégie pour créer une nouvelle stratégie.

  3. Sélectionnez Stratégie d'exécution des pipelines.

  4. Définissez la portée de la stratégie.

  5. Ajoutez l'action à effectuer.

mise à jour de la séparation des tâches - image 4

  1. Ajoutez des conditions.

  2. Créez une merge request pour soumettre cette stratégie, puis effectuer un merge.

  3. Essayez ensuite d'exécuter votre pipeline. Les étapes et les jobs spécifiques à cette stratégie s'afficheront alors dans votre pipeline.

Tableau de bord de gestion des audits et de la conformité

La conformité implique également de s'assurer qu'elle est réellement appliquée dans vos groupes/projets. GitLab dispose d'une fonctionnalité d'événements d'audit et de rapports de conformité pour vous assister.

La fonctionnalité d'événement d'audit permet aux propriétaires et administrateurs de GitLab de suivre les événements importants, tels que des actions précises effectuées par certains membres de l'équipe et l'heure à laquelle elles se sont produites.

Fonctionnalité d'événement d'audit

Elle enregistre différents types d'actions par groupe et par projet, comme indiqué dans la documentation dédiée à la fonctionnalité d'événement d'audit. Vous pouvez accéder à cette fonctionnalité dans Sécurité et conformité > Fonctionnalité d'événement d'audit. Voici quelques exemples :

  • Un utilisateur a été ajouté à un projet ainsi que ses autorisations.
  • Les autorisations d'un utilisateur affecté à un projet ont été modifiées.
  • Le statut de protection d'une variable CI/CD du projet a été ajouté, supprimé ou modifié.
  • Un utilisateur a été ajouté à un groupe ainsi que ses autorisations.
  • Le nom ou le chemin d'accès d'un groupe a été modifié.

Les événements d'audit peuvent également être envoyés à un point de terminaison HTTP à l'aide du streaming d'événements d'audit. Découvrez comment mettre en œuvre le streaming d'événements d'audit dans cette vidéo.

La fonctionnalité de respect des normes vous permet de suivre l'activité des merge requests d'un groupe. Elle fournit une vue d'ensemble de tous les projets du groupe.

mise à jour de la séparation des tâches - image 5

Grâce à ce rapport, vous pouvez :

  • Obtenir un aperçu des dernières merge requests pour chaque projet.
  • Vérifier si les merge requests ont été approuvées, et par qui.
  • Identifier les auteurs des merge requests.
  • Afficher le dernier résultat du pipeline CI/CD pour chaque merge request.

Le rapport de respect des normes est accessible dans le groupe principal en accédant à Sécurisation > Centre de conformité, puis en cliquant sur l'onglet Respect des normes.


Merci de votre intérêt pour cet article ! Découvrez plus d'informations sur la séparation des tâches au sein de GitLab en consultant notre ressource Conformité logicielle continue avec GitLab

Votre avis nous intéresse

Cet article de blog vous a plu ou vous avez des questions ou des commentaires ? Partagez vos réflexions en créant un sujet dans le forum de la communauté GitLab.

Plus de 50 % des entreprises du classement Fortune 100 font confiance à GitLab

Commencez à livrer des logiciels de meilleurs qualité plus rapidement

Découvrez comment la plateforme DevSecOps intelligente

peut aider votre équipe.