GitLab Dedicated : une nouvelle ère réglementaire pour la conformité

Les mesures réglementaires telles que la directive SRI 2 (NIS 2) ne relèvent plus d'une simple réflexion prospective. Le rapport NIS360 de l'Agence de l'Union européenne pour la cybersécurité (ENISA) confirme que les autorités de contrôle évaluent activement le niveau de maturité en matière de cybersécurité dans les secteurs critiques. L'agence passe désormais d'un rôle de conseil et de consultation à celui de surveillance active, de contrôle et de responsabilisation. Tel est l'environnement réglementaire dans lequel évoluent désormais les entreprises européennes.

Les plateformes cloud multilocataires éliminent les surcoûts opérationnels, mais placent le code source et les pipelines sur une infrastructure partagée que les régulateurs examinent désormais de près. Les solutions auto-gérées offrent une isolation, mais transfèrent la responsabilité des cycles de mise à niveau, des correctifs de sécurité et des tests de reprise après sinistre à une équipe plateforme déjà surchargée. Ces deux options de déploiement présentent des lacunes en matière de gestion des risques, de souveraineté des données et de fourniture de preuves d'audit.

Dans cet article, découvrez comment GitLab Dedicated, une solution SaaS monolocataire entièrement isolée, déployée dans la région Amazon Web Services (AWS) de votre choix, hébergée et gérée par GitLab, répond à ces défis et vous aide à suivre l'évolution des exigences de conformité.

« NatWest Group adopte GitLab Dedicated SaaS pour permettre à nos équipes d'ingénierie de s'appuyer sur une plateforme d'ingénierie cloud commune ; nous livrons ainsi de nouveaux résultats pour nos clients et nos collaborateurs rapidement, fréquemment et en toute sécurité, avec des tests automatisés de haute qualité, une infrastructure à la demande et un déploiement de bout en bout. »

Adam Leggett, Platform Lead for Engineering Platforms, NatWest Group

Les réglementations sont le moteur du changement

Dans l'Union européenne, plusieurs réglementations clés imposent une nouvelle approche en matière de plateformes. Ces réglementations convergent vers une décision que la plupart des entreprises avaient déjà prise avant leur entrée en vigueur : une plateforme sur laquelle leurs équipes de développement développent des logiciels. Cette décision entraîne aujourd'hui des conséquences inédites en matière d'audit.

1. Le règlement sur la résilience opérationnelle numérique (DORA), entré en vigueur dans les services financiers de l'UE en janvier 2025, impose aux institutions financières de garantir la résilience des technologies critiques, d'éviter toute dépendance excessive à l'égard de fournisseurs clés et de renforcer le signalement des incidents.
2. La directive SRI 2, adoptée en décembre 2022, impose aux secteurs essentiels et importants de renforcer la cybersécurité, de sécuriser les chaînes d'approvisionnement technologiques et de signaler rapidement les incidents majeurs aux autorités compétentes de l'Union européenne.
3. Le règlement général sur la protection des données (RGPD), applicable depuis mai 2018, impose aux organisations de protéger les données à caractère personnel, de documenter leur lieu de stockage et les personnes y ayant accès, et de justifier d'une base juridique valable pour chaque utilisation.

Infrastructure partagée et exposition opérationnelle

Sur les plateformes multilocataires, le partage de l'exécution, des runners et du stockage signifie qu'une seule vulnérabilité ou exposition commune (CVE) ou une seule mauvaise configuration peut exposer simultanément plusieurs locataires. Sur les déploiements auto-gérés, le risque se concentre en interne : les secrets et les identifiants s'accumulent et ne sont pas renouvelés régulièrement, tandis que les modifications manuelles, déclenchées par des incidents, entraînent une dérive par rapport aux références de l'Infrastructure as Code, ce qui masque la véritable surface d'attaque lors des audits.

GitLab Dedicated codifie les opérations

Les ingénieurs en fiabilité des sites (SRE) gèrent votre instance GitLab Dedicated dans un compte AWS isolé, sans accès direct par défaut aux environnements des clients. Toutes les modifications opérationnelles s'effectuent via des workflows automatisés et soumis à validation, par le biais d'un plan de contrôle défini, et non par une intervention directe sur le système. Les variables CI/CD et les jetons de runner peuvent être renouvelés selon une fréquence que vous définissez, afin de réduire les dérives de configuration et de contrôler étroitement la surface d’attaque opérationnelle grâce à des processus codifiés.

La reprise après sinistre est intégrée par défaut pour tous les clients GitLab Dedicated et chaque instance client dispose d'une région secondaire qui conserve une sauvegarde. GitLab Geo assure une réplication asynchrone et continue entre les deux sites. L'architecture de déploiement vise à limiter l'impact des défaillances régionales du cloud et à préserver la continuité des activités de nos clients. GitLab Dedicated assure la reprise après sinistre selon les objectifs suivants :

• Objectif de temps de reprise (RTO) : le service est rétabli dans votre région secondaire en huit heures ou moins.
• Objectif de point de reprise (RPO) : la perte de données est limitée à un maximum de quatre heures suivant les modifications les plus récentes, en fonction du moment où survient le sinistre par rapport à la dernière sauvegarde.

Souveraineté des données et sécurité contrôlée par le client

Les auditeurs ont besoin de précisions concernant le RGPD et la souveraineté des données : emplacement des données, droits d’accès et vérification que le trafic des runners ne quitte pas les régions approuvées. Sur les plateformes multilocataires, ces éléments sont contrôlés par le fournisseur, et les données peuvent traverser les frontières. Avec les déploiements auto-gérés, vous devez définir vous-même les politiques de stockage, la gestion des clés et le routage réseau afin de maintenir l'ensemble des données au sein de la région de votre choix.

GitLab Dedicated allie isolation et contrôle

La sélection de la région au moment du provisionnement lie le stockage d'objets, les artefacts et les données de calcul à la région AWS de votre choix. Vous choisissez également une région secondaire de basculement, de sorte que les seuls mouvements inter-régionaux sont ceux de la réplication que vous activez explicitement entre ces deux régions. Les clients de l'Union européenne peuvent conserver les deux régions dans leur juridiction. GitLab gère le basculement en respectant les objectifs de temps de reprise et de point de reprise définis.

Le modèle Bring Your Own Key (BYOK) permet le provisionnement de clés gérées par le client, de sorte que GitLab ne peut pas accéder aux données chiffrées si vous révoquez la clé. AWS PrivateLink crée un point de terminaison VPC dans votre compte : le trafic entre votre réseau, les jobs CI/CD et GitLab Dedicated reste sur le réseau dorsal privé d'AWS.

Une contrainte s'applique à tous les principaux fournisseurs de cloud et ne peut être levée au niveau de l'infrastructure : en tant que société américaine, Amazon Web Services reste soumise aux obligations légales des États-Unis, notamment au Clarifying Lawful Overseas Use of Data (CLOUD) Act, qui peut imposer la communication de données quel que soit l'emplacement physique des serveurs.

Le modèle BYOK résout le problème d'exposition au niveau de GitLab, puisque GitLab ne détient aucune clé et ne peut pas déchiffrer vos données. Cela ne modifie toutefois en rien les obligations d'AWS en vertu de la législation américaine. Les organisations soumises à des exigences juridictionnelles strictes doivent remédier à cette exposition résiduelle par le biais de mécanismes juridiques et contractuels : accords de traitement des données, analyses d'impact des transferts et base légale documentée pour les transferts, en complément des contrôles au niveau de l'infrastructure.

Lacunes en matière de preuves d'audit

Dans le cadre d'un SaaS multilocataire, les logs et les enregistrements d'incidents résident dans une infrastructure partagée, si bien que les auditeurs ont besoin de l'aide du fournisseur pour extraire les preuves propres à chaque locataire. Pour les déploiements auto-gérés, le principal risque d'audit provient de l'exposition aux CVE causée par des retards de mise à niveau. Prendre du retard sur les releases laisse des vulnérabilités connues dans l'environnement où réside le code source, ce qui est plus difficile à justifier auprès des auditeurs que de simples contraintes de capacité.

GitLab simplifie la mise en conformité

Les ingénieurs SRE de GitLab Dedicated veillent à ce que votre instance reste à jour selon une cadence de mise à niveau mensuelle prédéfinie, sans que cela n'alourdisse le backlog de votre équipe plateforme. Votre instance exécute la release mineure N-1 et reçoit une release mineure et deux releases correctives chaque mois, au cours d'une fenêtre de maintenance hebdomadaire fixe ; une maintenance d'urgence peut avoir lieu en dehors de cette fenêtre pour les problèmes de sécurité de niveau S1.

Via le portail en libre-service GitLab Trust Center, vous pouvez accéder à la documentation de conformité et aux artefacts d'assurance les plus récents de GitLab Dedicated. Par exemple, le dernier rapport d'audit DORA réalisé par Schellman. Grâce aux rapports d'audit prêts à l'emploi et aux preuves centralisées, vos équipes conformité et sécurité n'ont plus besoin de reconstituer des années d'historique de configuration auto-gérée ni d'extraire des données d'enregistrements partagés pour chaque soumission réglementaire ou revue annuelle. Vous disposez ainsi d'un processus reproductible pour préparer vos audits, avec une charge opérationnelle minimale.

Consultez cette démonstration interactive pour découvrir comment GitLab simplifie la gestion et l'exploitation de votre instance Dedicated.

Passer à GitLab Dedicated

Avec GitLab Dedicated, vous bénéficiez d'un choix et d'un contrôle accrus grâce à un SaaS monolocataire sécurisé et conforme. Les correctifs d'infrastructure, les preuves de disponibilité et les tests de reprise après sinistre relèvent du périmètre d'audit de GitLab, ce qui permet à vos équipes de documenter et de justifier la couche applicative plutôt que de devoir reconstituer les preuves relatives à l'infrastructure à chaque soumission.

Réservez une démonstration dès aujourd'hui pour découvrir comment GitLab Dedicated peut répondre à vos besoins de sécurité et de conformité.