DORA Article 28 exige des entit\u00e9s financi\u00e8res qu’elles g\u00e8rent les risques li\u00e9s aux fournisseurs de services ICT tiers.<\/p>\n\n\n\n
Dans la livraison logicielle moderne, ces fournisseurs ne sont pas p\u00e9riph\u00e9riques \u2014 ils sont int\u00e9gr\u00e9s directement dans les pipelines CI\/CD et les environnements d’ex\u00e9cution cloud.<\/p>\n\n\n\n
Cet article pr\u00e9sente une vue architecturale pratique de DORA Article 28, montrant :<\/p>\n\n\n\n
L’objectif n’est pas de d\u00e9crire des outils, mais de clarifier les limites de contr\u00f4le<\/strong>, les points d’application<\/strong> et les attentes d’audit<\/strong>.<\/p>\n\n\n\n Il comble \u00e9galement l’\u00e9cart de perspective entre auditeurs<\/strong> et ing\u00e9nieurs<\/strong> \u2014 deux audiences qui lisent la m\u00eame architecture tr\u00e8s diff\u00e9remment, et dont l’alignement est essentiel pour une conformit\u00e9 r\u00e9ussie.<\/p>\n\n\n\n Un pipeline CI\/CD d’entreprise typique repose sur de multiples fournisseurs ICT externes, souvent sans \u00eatre explicitement trait\u00e9s comme tels.<\/p>\n\n\n\n Sous DORA Article 28, les composants suivants doivent \u00eatre consid\u00e9r\u00e9s comme des services ICT tiers :<\/p>\n\n\n\n L’Article 28 s’applique car chacun de ces fournisseurs peut affecter :<\/p>\n\n\n\n Tout composant tiers impliqu\u00e9 dans la construction, le test, le d\u00e9ploiement ou l’ex\u00e9cution de logiciel est dans le p\u00e9rim\u00e8tre de l’Article 28.<\/p>\n\n\n\n DORA Article 28 exige des entit\u00e9s financi\u00e8res qu’elles g\u00e8rent le risque tiers ICT de mani\u00e8re v\u00e9rifiable, applicable et auditable. Cependant, les auditeurs et les ing\u00e9nieurs ne lisent pas les architectures de la m\u00eame mani\u00e8re.<\/p>\n\n\n\n Un auditeur examinant la conformit\u00e9 DORA Article 28 n’\u00e9value pas les outils ou pipelines directement. Il v\u00e9rifie que le risque est contr\u00f4l\u00e9, document\u00e9 et g\u00e9r\u00e9 continuellement<\/strong>.<\/p>\n\n\n\n Du point de vue de l’auditeur, l’architecture doit r\u00e9pondre \u00e0 :<\/p>\n\n\n\n Un ing\u00e9nieur regardant la m\u00eame architecture voit un plan de contr\u00f4le<\/strong> \u2014 un ensemble de m\u00e9canismes d’application qui doivent \u00eatre construits, configur\u00e9s et maintenus.<\/p>\n\n\n\n Leur focus inclut :<\/p>\n\n\n\n DORA Article 28 exige que les deux perspectives soient satisfaites simultan\u00e9ment.<\/p>\n\n\n\n Les plateformes CI\/CD et les registres doivent suivre les r\u00e8gles de production : durcissement, contr\u00f4le d’acc\u00e8s, journalisation, surveillance et continuit\u00e9 test\u00e9e.<\/p>\n\n\n\n Ce ne sont pas des outils de d\u00e9veloppement \u2014 ce sont des syst\u00e8mes ICT r\u00e9glement\u00e9s<\/strong>.<\/p>\n\n\n\n Les clauses contractuelles doivent permettre (ou au moins soutenir) : les droits d’audit, la notification d’incidents, la r\u00e9tention des preuves, la transparence du traitement des donn\u00e9es et les strat\u00e9gies de sortie.<\/p>\n\n\n\n Les contrats seuls ne suffisent pas sous DORA Article 28. Les politiques d\u00e9finies contractuellement doivent \u00eatre appliqu\u00e9es techniquement<\/strong> :<\/p>\n\n\n\n Les pipelines CI\/CD sont la couche d’application naturelle pour ces politiques.<\/p>\n\n\n\n Les preuves doivent \u00eatre g\u00e9n\u00e9r\u00e9es par la plateforme et conserv\u00e9es automatiquement : logs, approbations, SBOM\/provenance, enregistrements d’acc\u00e8s, chronologies d’incidents et tests de sortie.<\/p>\n\n\n\n Si les preuves n\u00e9cessitent un assemblage manuel pendant un audit, elles ne satisferont probablement pas les attentes des auditeurs en mati\u00e8re d’objectivit\u00e9 et de continuit\u00e9.<\/p>\n\n\n\n Sous DORA Article 28, les organisations doivent d\u00e9montrer que les plateformes tierces ne peuvent pas \u00eatre utilis\u00e9es \u00e0 mauvais escient ou avoir des privil\u00e8ges excessifs.<\/p>\n\n\n\n Les principes cl\u00e9s incluent :<\/p>\n\n\n\n L’isolation d’acc\u00e8s s’applique \u00e0 :<\/p>\n\n\n\n Les preuves doivent d\u00e9montrer qu’aucun acteur ou syst\u00e8me unique ne peut contourner les contr\u00f4les de bout en bout.<\/p>\n\n\n\n Les politiques d\u00e9finies contractuellement doivent \u00eatre appliqu\u00e9es techniquement via les pipelines CI\/CD :<\/p>\n\n\n\n DORA Article 28 exige une visibilit\u00e9 sur la cha\u00eene d’approvisionnement logicielle, particuli\u00e8rement lorsque des composants tiers sont impliqu\u00e9s.<\/p>\n\n\n\n This includes:<\/p>\n\n\n\n Les auditeurs attendent la preuve que les artefacts produits via les syst\u00e8mes CI\/CD tiers n’ont pas \u00e9t\u00e9 alt\u00e9r\u00e9s.<\/p>\n\n\n\n Les services tiers doivent \u00eatre surveill\u00e9s continuellement :<\/p>\n\n\n\n Les auditeurs v\u00e9rifient que la surveillance s’applique aux fournisseurs tiers, pas seulement aux syst\u00e8mes internes. Les workflows d’incidents doivent r\u00e9f\u00e9rencer les fournisseurs tiers affect\u00e9s et d\u00e9montrer une escalade tra\u00e7able.<\/p>\n\n\n\n La planification de sortie est une exigence r\u00e9glementaire sous l’Article 28, pas un exercice optionnel.<\/p>\n\n\n\n Les auditeurs v\u00e9rifieront :<\/p>\n\n\n\n Les ing\u00e9nieurs soutiennent les strat\u00e9gies de sortie en :<\/p>\n\n\n\n Sous DORA Article 28, les auditeurs attendent des preuves dans cinq domaines :<\/p>\n\n\n\n Les preuves doivent \u00eatre :<\/p>\n\n\n\n Les tableurs manuels seuls satisfont rarement ces crit\u00e8res.<\/p>\n\n\n\n De nombreuses organisations \u00e9chouent aux revues DORA Article 28 non pas parce que les contr\u00f4les manquent, mais parce que :<\/p>\n\n\n\n En s\u00e9parant explicitement la vue auditeur et la vue ing\u00e9nieur, vous assurez que :<\/p>\n\n\n\n L’architecture DORA Article 28 ne consiste pas \u00e0 lister des outils \u2014 il s’agit de d\u00e9finir o\u00f9 r\u00e9side le risque tiers ICT<\/strong>, comment il est contr\u00f4l\u00e9<\/strong> et comment la conformit\u00e9 est prouv\u00e9e<\/strong>.<\/p>\n\n\n\n L’architecture doit soutenir \u00e0 la fois le besoin de preuves de l’auditeur et le besoin de contr\u00f4les applicables et automatis\u00e9s de l’ing\u00e9nieur. Lorsque les deux vues sont align\u00e9es, la conformit\u00e9 Article 28 devient une propri\u00e9t\u00e9 structurelle du syst\u00e8me de livraison \u2014 pas un exercice p\u00e9riodique.<\/p>\n\n\n\nLa v\u00e9ritable cha\u00eene d’approvisionnement CI\/CD sous DORA<\/h2>\n\n\n\n
\n
\n
Deux perspectives sur la m\u00eame architecture<\/h2>\n\n\n\n
Vue auditeur (prisme gouvernance et preuves)<\/h3>\n\n\n\n
\n
Vue ing\u00e9nieur (prisme impl\u00e9mentation et application)<\/h3>\n\n\n\n
\n
M\u00eame architecture, deux lectures<\/h3>\n\n\n\n
Aspect<\/th> Vue auditeur<\/th> Vue ing\u00e9nieur<\/th><\/tr><\/thead> Focus<\/td> Risque, gouvernance, conformit\u00e9<\/td> Automatisation, application, fiabilit\u00e9<\/td><\/tr> Question principale<\/td> \u00ab Pouvez-vous prouver le contr\u00f4le ? \u00bb<\/td> \u00ab O\u00f9 est-ce que j’applique le contr\u00f4le ? \u00bb<\/td><\/tr> Pipeline CI\/CD<\/td> Surface de risque<\/td> Plan de contr\u00f4le<\/td><\/tr> Fournisseurs tiers<\/td> Fournisseurs \u00e0 gouverner<\/td> Plateformes \u00e0 int\u00e9grer de mani\u00e8re s\u00e9curis\u00e9e<\/td><\/tr> Preuves<\/td> Exigence explicite<\/td> Sortie automatique<\/td><\/tr> Strat\u00e9gie de sortie<\/td> Obligatoire<\/td> Souvent n\u00e9glig\u00e9e<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Principes architecturaux pour la conformit\u00e9 Article 28<\/h2>\n\n\n\n
1. Traiter les outils tiers comme des actifs de niveau production<\/h3>\n\n\n\n
2. Faire appliquer les contr\u00f4les par les contrats<\/h3>\n\n\n\n
\n
3. Les preuves doivent \u00eatre con\u00e7ues, pas \u00ab collect\u00e9es plus tard \u00bb<\/h3>\n\n\n\n
Couches de contr\u00f4le dans le cycle de vie CI\/CD<\/h2>\n\n\n\n
Contr\u00f4le d’acc\u00e8s et isolation<\/h3>\n\n\n\n
\n
\n
Application des politiques contractuelles<\/h3>\n\n\n\n
\n
Int\u00e9grit\u00e9 de la cha\u00eene d’approvisionnement<\/h3>\n\n\n\n
\n
Surveillance et r\u00e9ponse aux incidents<\/h3>\n\n\n\n
\n
Strat\u00e9gie de sortie et continuit\u00e9<\/h3>\n\n\n\n
\n
\n
Ce que les auditeurs demandent g\u00e9n\u00e9ralement<\/h2>\n\n\n\n
\n
\n
Lacunes courantes et sch\u00e9mas de d\u00e9salignement<\/h2>\n\n\n\n
\n
\n
Conclusion<\/h2>\n\n\n\n
Ressources connexes<\/h2>\n\n\n\n
\n
\n\n\n