Règles de conformité pour une diffusion réglementée

Une multinationale qui utilise Upsun gère plus de 400 sites web. Chaque filiale a ses propres sites, sa propre équipe, son propre calendrier de déploiement et ses propres exigences locales. Ce qu’elles partagent, c’est une seule couche de contrôle d’infrastructure : le même modèle d’accès, les mêmes paramètres de chiffrement par défaut, les mêmes journaux d’activité, la même région et la même politique de sauvegarde pour chaque projet. Ajouter le 401e site n’implique pas d’ajouter un 401e ensemble de contrôles d’infrastructure à vérifier. 

C’est le résultat qui vaut la peine d’être visé, car chaque responsable informatique chargé de la conformité finit par se heurter au même obstacle. L’équipe d’ingénierie veut gagner en rapidité. Le service de conformité a besoin de preuves que rien n’a été compromis au cours du processus. 

Historiquement, ces deux exigences ont été conciliées grâce à des processus : revues manuelles, comités consultatifs sur les changements et gel des versions avant les périodes d’audit. Cette conciliation fonctionne, mais elle est lente et s’adapte mal à l’échelle. Ce qui évolue, ce n’est pas le nombre d’applications, mais le nombre de versions soumises à la réglementation. Une poignée d’applications sensibles déployées plusieurs fois par semaine peut générer la même charge de travail de révision que des centaines d’applications plus discrètes ; c’est pourquoi se contenter de compter les applications minimise le problème.

L’alternative consiste à appliquer la même rigueur un niveau plus bas, au sein de la plateforme par laquelle chaque équipe passe déjà pour ses livraisons, ce qui évite à chaque équipe de devoir la réappliquer à chaque version.

Où doivent se situer les garde-fous

Point clé : les garde-fous doivent se situer au niveau de la plateforme, pas au niveau des applications. Tout ce qui doit être correct à chaque fois, peu importe ce que construit une équipe, doit être imposé de manière structurelle plutôt que vérifié manuellement.

L’architecture de référence sépare le processus de livraison en deux couches bien délimitées : une couche de garde-fous que la plateforme applique de manière cohérente à chaque équipe et à chaque version, et une couche applicative où les équipes conservent une marge de manœuvre significative dans les limites des capacités prises en charge par la plateforme.

• Accès et identité. Qui peut déployer dans quel environnement, et sous quel rôle, doit être défini une fois pour toutes et appliqué de manière cohérente dans tous les projets. C’est la couche visée par les exigences de contrôle d’accès des normes SOC 2 et ISO 27001 : il ne s’agit pas de savoir si un document de politique existe, mais si l’accès est clairement délimité et revu de manière vérifiable. Upsun propose des autorisations basées sur les rôles, qu’il s’agisse d’organisations, de projets ou de types d’environnements. L’application de l’authentification multifactorielle (MFA) à l’échelle de l’organisation et l’authentification unique (SSO) sont des fonctionnalités optionnelles et non par défaut ; le modèle d’accès qu’un auditeur voit dépend donc de celles que l’organisation a activées.
• Chiffrement et protection des données. Le chiffrement au repos et en transit, la gestion des clés et le traitement des secrets devraient être des paramètres par défaut de la plateforme, et non des décisions de configuration à prendre projet par projet. Une équipe qui développe un nouveau service ne devrait pas avoir à décider de chiffrer ou non les données ; cette décision devrait déjà avoir été prise pour elle.
• Historique des activités lié à l’autorisation des modifications. Upsun consigne automatiquement, pour chaque projet, les déploiements, les poussées, les activités de configuration et les accès aux environnements, avec horodatage, nom de l’utilisateur responsable et état du déploiement final. Mais les journaux d’exécution prouvent ce qui s’est passé, pas que ça ait été autorisé. C’est en les associant à la révision des pull requests, où un validateur distinct donne son accord avant la fusion, qu’on comble cette lacune dans les contrôles de gestion des changements. Une exception : les journaux de sessions SSH ne sont pas directement accessibles aux clients et peuvent nécessiter une demande d’assistance auprès d’Upsun lors d’un audit.
• Sélection de la région. L'emplacement où les données réglementées peuvent être stockées doit être une propriété contrôlée du projet, et non une convention que les équipes sont censées respecter. Sur Upsun, la région d’un projet est choisie lors de sa création, puis reste une propriété contrôlée de ce projet, vérifiable via les données d’état et d’activité du projet. Elle n’est pas déclarée dans la configuration gérée par contrôle de version ; ce n’est donc pas quelque chose qu’une équipe modifie dans une pull request. Ça veut dire que la réponse à la question « où résident ces données ? » se trouve dans l’état actuel du projet, et non dans un document que quelqu’un doit aller vérifier.
• Tests de sauvegarde, de reprise et de restauration. Des sauvegardes automatisées et planifiées, avec une durée de conservation configurable par type d’environnement, constituent une exigence de base tant pour les critères de disponibilité de la norme SOC 2 que pour la norme PCI DSS, mais le calendrier ne représente que la moitié du contrôle. Upsun effectue par défaut des sauvegardes quotidiennes automatisées des environnements de production, avec une durée de conservation configurable pour correspondre à l’objectif de point de reprise (RPO) requis par un référentiel donné. L’autre moitié, c’est à toi de la gérer. Choisir une durée de conservation conforme au référentiel et prouver qu’une sauvegarde peut être restaurée sont des décisions que la plateforme ne prend pas à ta place, et ces deux aspects doivent s’inscrire dans un rythme de révision régulier.

Aucune de ces cinq mesures de sécurité ne doit être laissée à la discrétion d’une seule équipe, qui déciderait de bien ou mal les mettre en œuvre. Elles constituent le socle sur lequel repose chaque version, appliquées via les mêmes contrôles, que l’équipe déploie une nouvelle fonctionnalité destinée aux clients ou un service backend que personne ne voit. La durée de conservation, la région et le périmètre d’accès restent définis par projet. Ce qui ne varie pas, c’est le mécanisme qui les définit ni les preuves qu’ils génèrent.

Ce qui reste flexible

Point clé : une fois la couche de garde-fous définie, les décisions qui s’y rapportent relèvent de l’équipe, dans les limites des capacités prises en charge par la plateforme. La conformité n’exige pas de standardiser ce qui n’affecte pas la posture d’audit.

C’est cette distinction qui détermine si une architecture de conformité est adoptée ou contournée. Les équipes qui perçoivent la conformité comme une contrainte sur chaque décision trouveront des solutions de contournement. Celles qui la considèrent comme une base solide dont elles n’ont pas à se soucier, avec une réelle liberté au-dessus, utiliseront le système tel qu’il a été conçu.

• Langage et framework. Le langage dans lequel un service est écrit n’a aucune incidence sur la bonne application des contrôles d’accès, du chiffrement et de la journalisation d’audit. Ces éléments restent du ressort de l’équipe.
• Rythme de déploiement. Certaines équipes déploient plusieurs fois par jour ; d’autres fonctionnent selon un cycle plus lent et plus réfléchi. Aucun de ces rythmes n’est plus ou moins conforme, à condition que la couche de protection soit cohérente dans les deux cas. Un pipeline de livraison standardisé prend en charge les deux sans imposer un rythme de déploiement uniforme.
• Architecture et dépendances des services. Le choix de la base de données, la stratégie de mise en cache, les limites internes des services : ce sont des décisions techniques et relatives au produit qui relèvent de l’équipe la plus proche du problème. La couche de protection ne dicte pas ce qu’une équipe développe, mais uniquement comment ce qui est développé est déployé, accessible et documenté.
• Sécurité au niveau de l’application et logique d’autorisation. Les garde-fous de la plateforme sécurisent la couche d’infrastructure : qui peut déployer, comment les données sont chiffrées, comment les accès sont journalisés. Ce qu’une équipe développe par-dessus reste entièrement sous sa responsabilité, y compris les vulnérabilités de l’application, les risques liés aux dépendances et à la composition logicielle, ainsi que sa propre logique d’authentification et d’autorisation des utilisateurs. C’est cette limite de responsabilité partagée qui compte le plus dans la pratique, et ça vaut le coup d’être précis à ce sujet plutôt que de laisser entendre que la plateforme couvre tout.

Mise en correspondance de l’architecture avec des référentiels spécifiques

Point clé à retenir : SOC 2, ISO 27001, le RGPD, PCI DSS et DORA valorisent tous la même chose au niveau de la couche d’infrastructure : des contrôles que tu peux démontrer plutôt que ceux que tu décris, mais ils ne sont pas interchangeables. Chacun met l’accent sur des aspects spécifiques différents, et chacun exige un travail de jugement qu’aucune couche d’infrastructure ne fournit à elle seule.

• La norme SOC 2 Type 2 évalue si les contrôles fonctionnent réellement sur une période d’audit, généralement de trois à douze mois, et pas seulement s’ils sont documentés. La journalisation automatisée des accès et le chiffrement correspondent directement aux critères communs de sécurité ; les sauvegardes automatisées et testées correspondent aux critères de disponibilité. Les auditeurs SOC 2 font également la distinction entre les preuves d’exécution (un déploiement a bien eu lieu) et les preuves d’autorisation (il a été correctement examiné avant d’avoir lieu), ce qui explique précisément pourquoi associer les enregistrements d’activité de la plateforme à des processus d’approbation basés sur Git est plus important que les journaux seuls.
• La norme ISO 27001 est d’abord une norme de système de gestion, puis un ensemble de contrôles techniques. Le cœur d’une certification ISO 27001, c’est un système de gestion de la sécurité de l’information axé sur les risques : évaluation des risques, plans de traitement, cycles de revue de direction et déclaration d’applicabilité. Les contrôles techniques auxquels répond une architecture de protection (contrôle d’accès, cryptographie, journalisation) relèvent de l’annexe A et viennent étayer le SMSI ; ils ne remplacent pas le travail de gouvernance que la norme exige réellement.
• Le RGPD n'impose pas que les données à caractère personnel de l'UE restent physiquement à l'intérieur de l'UE, c'est une idée fausse courante. Ce qu'il exige, c'est une base légale pour le traitement, la minimisation des données, le respect des droits des personnes concernées et la tenue de registres précis des activités de traitement, le chapitre V régissant tout transfert en dehors de l'EEE par le biais de mécanismes tels que les clauses contractuelles types ou une décision d'adéquation. La sélection de la région au niveau du projet répond à l’exigence de garanties techniques de l’article 32 du RGPD et simplifie les évaluations des risques liés aux transferts transfrontaliers, mais il s’agit d’un mécanisme d’appui, pas de l’exigence principale de conformité.
• La norme PCI DSS, le cas échéant, met l’accent sur l’isolation de l’environnement des données des titulaires de carte du reste du système, sur une cryptographie forte, sur l’authentification multifactorielle pour tout accès à cet environnement et sur la gestion continue des vulnérabilités, et non pas principalement sur les procédures de sauvegarde. Une architecture de « garde-fou » favorise la réduction du périmètre et un contrôle d’accès cohérent, mais la conformité à la norme PCI DSS nécessite tout de même une délimitation réfléchie de l’environnement des données des titulaires de carte, spécifique à la charge de travail.
• La DORA, la loi européenne sur la résilience opérationnelle numérique (Digital Operational Resilience Act), à ne pas confondre avec le rapport de recherche DevOps du même nom, est en vigueur depuis le 17 janvier 2025. Elle s’applique aux entités financières et à leurs fournisseurs TIC autour de cinq piliers : la gestion des risques, le signalement des incidents, les tests de résilience opérationnelle, la gestion des risques liés aux tiers et le partage d’informations. La surveillance directe au niveau européen s’applique aux prestataires TIC tiers qui ont été officiellement désignés comme critiques, et non à tous les prestataires technologiques auxquels une entité financière fait appel. Pour tous les autres, les obligations s’appliquent indirectement, via les exigences contractuelles et de gestion des risques liés aux tiers que l’entité financière doit elle-même respecter. L’architecture « guardrail » soutient spécifiquement les piliers de la gestion des risques et des tests ; elle ne constitue pas à elle seule un programme complet de conformité à la DORA.

Le point commun entre ces cinq piliers : ils se recoupent suffisamment au niveau de l’infrastructure pour qu’un ensemble cohérent de contrôles fonctionne vraiment pour chacun d’entre eux, mais ils divergent dans la pondération qu’ils accordent, et chacun a des exigences spécifiques qu’une couche de garde-fous ne suffit pas à elle seule à satisfaire. L’architecture élimine le travail manuel au niveau de l’infrastructure. Les décisions discrétionnaires, le périmètre, l’évaluation des risques et la base légale restent du ressort de la fonction de conformité.

Y parvenir sans tout refaire

Point clé : la mise en place de cette architecture ne nécessite pas de changer de plateforme pour tous les services existants. Il suffit de mettre en place la couche de protection une seule fois et d’y réaliser l’intégration des nouveaux projets dès le premier jour, en migrant les services existants au fur et à mesure.

Ce qui freine la plupart des efforts de mise en place d’une architecture de conformité, c’est l’idée qu’il faut déplacer tous les services existants d’un seul coup. Ce n’est pas le cas. Les nouveaux projets adoptent la couche de protection dès leur premier commit, ce qui empêche la dette de conformité de continuer à s’accumuler. Les services existants sont migrés au fur et à mesure qu’on y travaille activement : lors d’un cycle de fonctionnalités, d’une mise à jour de dépendances ou d’une correction de sécurité, plutôt que dans le cadre d’un sprint dédié à la migration de conformité.

L’ordre qui fonctionne le mieux commence par l’accès et l’identité, car c’est généralement au niveau de l’accès que l’écart par rapport à la politique est le plus important dans un environnement fragmenté, et c’est là que les preuves sont les plus difficiles à reconstituer a posteriori. Le chiffrement et la journalisation suivent naturellement, car il s’agit en grande partie de paramètres par défaut de la plateforme plutôt que d’un travail de configuration projet par projet. Le choix de la région et la politique de sauvegarde viennent en dernier, car ce sont les éléments les plus spécifiques à chaque charge de travail et qu’il est préférable de les ajuster une fois que la couche de base est déjà en place.

En procédant dans cet ordre, les services s’intègrent progressivement à une architecture de protection cohérente au fur et à mesure de leur mise en service, sans aucune bascule forcée. Certains ne s’adapteront pas parfaitement. Les charges de travail présentant des exigences inhabituelles en matière de traitement des données, de réseau ou de certification nécessitent davantage de planification, une intégration supplémentaire ou un parcours d’exception documenté, et il vaut mieux les identifier dès le début plutôt que de les découvrir en cours de migration.

Passe en revue ton architecture de prestation réglementée avec Upsun

Foire aux questions (FAQ)

Cette architecture nécessite-t-elle d’abandonner nos outils et services existants ? 
Non. La couche de garde-fous régit l’accès, le chiffrement, les journaux d’activité, la sélection de la région et les sauvegardes au niveau de la plateforme. Elle ne nécessite pas de réécrire le code des applications ni de remplacer les bases de données, les frameworks ou les services qu’une équipe a déjà choisis. La migration consiste à intégrer les projets existants dans la couche de garde-fous, pas à les reconstruire.

Comment gérer un framework que cette architecture de référence ne couvre pas explicitement ? 
Les cinq garde-fous (accès, chiffrement, journaux d’activité, sélection de la région et sauvegarde) correspondent aux preuves exigées, sous une forme ou une autre, par la plupart des cadres de conformité. Commence par identifier lequel de ces cinq éléments est le plus important pour ton framework spécifique, puis vérifie que la couche de garde-fous produit des preuves au format attendu par ton auditeur ou ton régulateur. Pour les cadres comportant des exigences supplémentaires spécifiques à leur champ d’application, comme l’isolation de l’environnement des données des titulaires de carte dans la norme PCI DSS ou le pilier des tests de résilience de la norme DORA, considère la couche de protection comme la base sur laquelle tu construis ce travail supplémentaire, et non comme un substitut à celui-ci.

Quelle est la différence entre ça et le simple fait d’embaucher plus de personnel chargé de la conformité ? Le personnel chargé de la conformité
continue de prendre les décisions : interpréter le périmètre, gérer les exceptions, mener des évaluations des risques, s’occuper des attestations spécifiques exigées par un cadre. Ce que cette architecture supprime, c’est le travail manuel de collecte de preuves qui sous-tend ces décisions, cette semaine passée à extraire des journaux de systèmes dispersés avant chaque audit. Ça rend le personnel chargé de la conformité plus efficace, pas superflu.

La standardisation de la couche de « garde-fous » ralentit-elle les équipes qui avancent déjà vite ? En 
général, non, car les garde-fous, le contrôle d’accès, le chiffrement et l’enregistrement des activités sont des pratiques que les équipes bien organisées s’efforcent déjà de mettre en œuvre de manière cohérente. Ce qui change, c’est que ces éléments deviennent des paramètres par défaut de la plateforme au lieu de nécessiter une mise en œuvre par équipe, ce qui, en général, accélère le travail des équipes plutôt que de le ralentir.

Que doit vérifier en premier lieu un responsable informatique avant d’adopter ce modèle ? Commence
par l’accès et l’identité : peux-tu actuellement indiquer, pour chaque environnement, qui y a accès et pourquoi, et peux-tu prouver que les modifications d’accès ont fait l’objet d’une autorisation en bonne et due forme, plutôt que de simplement montrer qu’elles ont eu lieu ? Si l’une ou l’autre de ces réponses prend plus de quelques minutes à fournir, ou nécessite de consulter plusieurs systèmes, c’est là la lacune que cette architecture de référence est conçue pour combler en priorité.