Pourquoi les directives d’externalisation de l’EBA exigent-elles le contrôle des clés de chiffrement

Les lignes directrices de l’Autorité bancaire européenne (EBA/GL/2019/02) sur l’externalisation, pleinement applicables depuis 2022, imposent des exigences strictes sur la manière dont les institutions financières délèguent des services technologiques à des prestataires tiers. Parmi ces exigences, le contrôle des clés de chiffrement s’impose comme une obligation incontournable, impactant directement l’architecture des environnements cloud, le choix des fournisseurs et la capacité à défendre la conformité réglementaire. Les institutions financières qui externalisent le traitement, le stockage ou la communication de données doivent garder un contrôle effectif sur les clés de chiffrement protégeant les données sensibles des clients, les enregistrements de transactions et les communications internes. Il convient également de noter que DORA (Digital Operational Resilience Act), entré en vigueur en janvier 2025, renforce et étend ces obligations, notamment en matière de gestion des risques liés aux TIC et de dépendances vis-à-vis de tiers.

Cette exigence engendre des défis opérationnels immédiats. De nombreux fournisseurs cloud et plateformes SaaS gèrent les clés de chiffrement pour le compte de leurs clients, ce qui répond aux exigences de base en matière de sécurité, mais ne satisfait pas les attentes de l’EBA concernant la séparation des contrôles. Les décideurs doivent comprendre pourquoi l’EBA insiste sur le contrôle des clés, quels modèles d’architecture répondent à cette exigence et comment mettre en œuvre la gestion des clés sans perturber les processus existants ni les relations avec les fournisseurs.

Cet article explique la logique réglementaire derrière l’exigence de contrôle des clés de chiffrement, précise ce que signifie un contrôle effectif dans la pratique et détaille comment les institutions financières peuvent opérationnaliser ces exigences dans des environnements cloud hybrides et des canaux de communication tiers.

Résumé Exécutif

Les lignes directrices de l’EBA sur l’externalisation imposent aux institutions financières de garder un contrôle effectif sur les clés de chiffrement protégeant les données sensibles traitées ou stockées par des prestataires tiers. Cette obligation existe parce que le contrôle des clés de chiffrement détermine si une institution peut accéder, récupérer ou révoquer l’accès à ses données de manière indépendante, sans dépendre de la coopération du prestataire. Sans contrôle direct des clés, les institutions ne peuvent pas prouver leur souveraineté sur les données, appliquer des stratégies de sortie ou garantir la récupération des données en cas de défaillance du fournisseur. Les responsables de la sécurité doivent mettre en place des architectures de gestion des clés séparant le contrôle cryptographique du contrôle de l’infrastructure, s’intégrant aux systèmes IAM existants et générant des journaux d’audit immuables reliant chaque opération sur les clés à des individus et obligations réglementaires spécifiques. Les institutions qui ne mettent pas en place un contrôle vérifiable des clés s’exposent à des contrôles réglementaires et à d’éventuelles sanctions.

Points Clés à Retenir

• Point clé 1 : Les lignes directrices de l’EBA (EBA/GL/2019/02) imposent aux institutions financières de garder un contrôle unilatéral sur les clés de chiffrement protégeant les données sensibles traitées par des prestataires tiers. Sans contrôle indépendant des clés, les institutions ne peuvent pas prouver leur souveraineté sur les données, mettre en œuvre des stratégies de sortie ou garantir la récupération des données en cas de défaillance ou de litige avec le fournisseur.

• Point clé 2 : Le chiffrement géré par le fournisseur expose à des risques réglementaires, car l’institution ne peut pas empêcher l’accès du fournisseur en cas de procédure judiciaire étrangère, ne peut pas garantir la récupération après une défaillance technique et ne peut pas vérifier que les personnes non autorisées n’ont pas accès. Les contrôles architecturaux doivent remplacer les garanties contractuelles pour assurer la défense réglementaire.

• Point clé 3 : Un contrôle effectif des clés nécessite une intégration avec les systèmes de gestion des identités pour appliquer la gestion des accès basée sur les rôles (RBAC), la révocation immédiate en cas de départ d’un utilisateur et des journaux d’audit immuables retraçant chaque opération sur les clés à des individus et objectifs métier précis. Ces fonctions permettent aux institutions de répondre aux exigences des contrôles réglementaires.

• Point clé 4 : Le choix des fournisseurs doit privilégier les capacités techniques permettant la gestion des clés par le client via des API standardisées, des architectures « bring-your-own-key » et des clauses contractuelles garantissant le contrôle unilatéral de l’institution tout en interdisant l’accès du fournisseur aux données en clair. Les clauses de sortie doivent garantir le transfert des données chiffrées sans exiger de déchiffrement géré par le fournisseur.

• Point clé 5 : Les architectures à haute disponibilité pour la gestion des clés doivent offrir une disponibilité au moins équivalente à celle des charges de travail protégées, grâce à des clusters répartis géographiquement et à des bascules automatiques. La planification de la reprise après sinistre doit permettre de rediriger les charges de travail vers d’autres environnements tout en maintenant la connexion à l’infrastructure de gestion des clés existante, sans régénérer les clés.

Fondement Réglementaire du Contrôle des Clés de Chiffrement

Les lignes directrices de l’EBA considèrent le contrôle des clés de chiffrement comme une condition fondamentale pour garantir la résilience opérationnelle et la souveraineté des données lors de la délégation de fonctions à des prestataires externes. Cette exigence découle du constat que le chiffrement sans contrôle indépendant des clés donne une fausse impression de sécurité. Si un prestataire gère à la fois les données chiffrées et les clés qui les protègent, l’institution ne peut pas vérifier de manière indépendante l’intégrité des données, appliquer des restrictions d’accès ou récupérer les données sans la participation active du fournisseur.

Les institutions financières sont soumises à des attentes réglementaires accrues. Elles traitent des dépôts clients, des instructions de paiement, des transactions sur titres et des informations financières personnelles soumises à de multiples réglementations, dont le RGPD, la DSP2 et la MiFID II. Ces cadres imposent que les responsables du traitement mettent en place des mesures techniques et organisationnelles suffisantes pour protéger les données tout au long de leur cycle de vie. Lorsqu’une institution externalise le traitement à un fournisseur cloud ou une plateforme SaaS, elle reste responsable du traitement avec une responsabilité juridique totale en cas de défaillance de protection.

Les lignes directrices de l’EBA précisent que les institutions doivent veiller à pouvoir accéder à leurs données même si le fournisseur cesse ses activités, ne respecte pas ses obligations contractuelles ou fait l’objet de restrictions légales. Cette exigence ne peut être satisfaite si le fournisseur détient les seules copies des clés de chiffrement. L’institution doit posséder des clés indépendantes ou contrôler directement l’infrastructure de gestion des clés, ce qui crée une exigence architecturale impactant le choix des fournisseurs, la négociation contractuelle et la mise en œuvre technique pour chaque externalisation impliquant des données sensibles.

Ce que Signifie un Contrôle Effectif des Clés dans la Pratique

Le contrôle effectif va bien au-delà de la simple possession d’une copie des clés de chiffrement. Les régulateurs attendent des institutions qu’elles prouvent leur capacité à générer, stocker, faire tourner, révoquer et auditer l’utilisation des clés sans l’aide du fournisseur. Cela signifie que l’institution doit exploiter ou contrôler directement le système de gestion des clés.

Plusieurs modèles d’architecture répondent à cette exigence. Les institutions peuvent déployer des modules matériels de sécurité (HSM) validés FIPS 140-3 dans leurs propres datacenters et les intégrer aux charges de travail cloud via des API sécurisées. Elles peuvent utiliser les services de gestion de clés par le client proposés par les plateformes cloud, où la plateforme chiffre les données mais le client contrôle le matériel de clé via une frontière de service distincte. Elles peuvent mettre en place des schémas de chiffrement en enveloppe, où les clés de chiffrement des données restent gérées par le fournisseur pour des raisons de performance, mais les clés maîtresses restent sous le contrôle du client.

L’élément clé évalué par les régulateurs est la capacité de l’institution à refuser unilatéralement l’accès du fournisseur aux données en clair. Si le fournisseur peut déchiffrer les données sans demander les clés aux systèmes contrôlés par le client, le contrôle effectif n’existe pas. Si le fournisseur stocke les clés maîtresses avec les données chiffrées dans le même domaine administratif, le contrôle effectif n’existe pas.

Le Risque de Non-Conformité Créé par les Clés Gérées par le Fournisseur

De nombreuses plateformes cloud et applications SaaS chiffrent par défaut les données clients à l’aide de clés gérées par le fournisseur. Cette approche est simple et performante, mais expose les institutions financières à des risques réglementaires. Le fournisseur décide quand le chiffrement a lieu, quels algorithmes sont utilisés, comment les clés sont renouvelées et à quel moment elles sont disponibles pour les opérations de déchiffrement.

Les régulateurs considèrent ce modèle comme insuffisant. L’institution ne peut pas empêcher le fournisseur d’accéder aux données si une procédure judiciaire étrangère l’y contraint. Elle ne peut pas garantir la récupération des données si le fournisseur subit une défaillance technique affectant ses systèmes de gestion des clés. Elle ne peut pas prouver que des personnes non autorisées du fournisseur n’ont pas accès aux données sensibles via des privilèges élevés. Ces scénarios représentent des risques opérationnels majeurs que les institutions doivent atténuer par des contrôles architecturaux, et non par de simples engagements contractuels.

Le chiffrement géré par le fournisseur complique également les stratégies de sortie. Lorsqu’une institution décide de quitter un fournisseur, elle doit compter sur lui pour déchiffrer et transférer les données de manière sécurisée. Si la relation s’est détériorée ou si le fournisseur est en difficulté financière, la coopération n’est pas garantie. Un contrôle indépendant des clés permet à l’institution de récupérer les données chiffrées et de les déchiffrer avec son propre matériel de clé, sans dépendre du fournisseur au-delà du transfert des données.

Mise en Œuvre Architecturale et Exigences Opérationnelles

Les lignes directrices de l’EBA sur l’externalisation s’appliquent à plusieurs catégories de services, chacune présentant des défis spécifiques pour le contrôle des clés de chiffrement. Les services d’infrastructure cloud, les plateformes SaaS et les systèmes de communication nécessitent tous une réflexion architecturale approfondie.

Les environnements d’infrastructure en tant que service offrent la plus grande flexibilité pour la gestion des clés par le client. Les institutions peuvent déployer des machines virtuelles exécutant leur propre logiciel de gestion des clés, intégrer des HSM validés FIPS 140-3 et mettre en œuvre le chiffrement en enveloppe, où les clés applicatives restent entièrement dans les systèmes contrôlés par le client. Les données au repos doivent être protégées par AES-256, et les données en transit sécurisées par TLS 1.3 au minimum. Le principal défi réside dans la complexité opérationnelle et la nécessité d’assurer une disponibilité équivalente de l’infrastructure de gestion des clés par rapport aux charges de travail protégées.

Les plateformes SaaS offrent moins de latitude, car le fournisseur contrôle l’architecture applicative. De nombreux éditeurs SaaS proposent désormais des fonctions « bring-your-own-key », où les clients fournissent des clés de chiffrement via des services de gestion de clés externes. L’application SaaS sollicite les clés en temps réel lors du chiffrement ou du déchiffrement, mais n’en conserve jamais de copie persistante. Ce modèle répond aux attentes réglementaires s’il est correctement mis en œuvre, mais les institutions doivent vérifier que les demandes de clés sont faites à la granularité appropriée et que le fournisseur ne peut pas mettre en cache les clés au-delà du cycle de vie prévu.

Les canaux de communication transportant des données sensibles en mouvement (e-mail, transfert de fichiers, plateformes collaboratives) exigent un contrôle des clés équivalent à celui des données au repos. Le chiffrement traditionnel des e-mails repose sur S/MIME ou PGP, confiant la gestion des clés aux utilisateurs finaux, ce qui génère une lourde charge opérationnelle. Les plateformes modernes de transfert sécurisé de fichiers (MFT) répondent à ce problème en mettant en œuvre un chiffrement applicatif avec AES-256 et des clés gérées par le client avant que les données ne quittent le périmètre institutionnel, toutes les communications étant protégées via TLS 1.3. Les contenus chiffrés traversent les infrastructures tierces mais restent protégés par des clés sous contrôle direct de l’institution.

Intégration des Journaux d’Audit et du Contrôle d’Accès

Le contrôle des clés de chiffrement va au-delà de l’architecture cryptographique et englobe la gouvernance des identités et la génération de journaux d’audit. Les régulateurs attendent des institutions qu’elles prouvent que chaque opération sur les clés est attribuée à un individu précis, réalisée pour un objectif métier documenté et laisse une trace immuable exploitable en cas d’enquête.

Les systèmes de gestion des clés doivent s’intégrer aux fournisseurs d’identité institutionnels via des protocoles standardisés comme SAML et OAuth. L’authentification pour l’accès aux clés doit imposer l’authentification multifactorielle, respecter la gestion des accès basée sur les rôles (RBAC) centralisée et appliquer les révocations immédiatement en cas de départ d’un utilisateur. Lorsqu’un collaborateur quitte l’institution, son accès aux clés de chiffrement doit être révoqué sans intervention manuelle.

La journalisation des accès doit fournir un niveau de détail suffisant pour reconstituer le contexte de chaque opération sur les clés. Les régulateurs attendent que les logs précisent quel utilisateur a demandé l’accès à la clé, quelles données sont protégées, quand l’opération a eu lieu, depuis quel emplacement réseau, et si elle a réussi ou échoué. Ces logs doivent être infalsifiables, via une signature cryptographique ou des mécanismes de stockage en écriture seule empêchant toute modification a posteriori.

Les institutions financières doivent répondre à des exigences issues de multiples cadres de conformité. Le RGPD impose la gestion des demandes d’accès et le droit à l’effacement. Les réglementations sur les services de paiement exigent la non-répudiation des transactions. Chaque obligation génère des exigences spécifiques sur la gestion des clés de chiffrement. Les architectures efficaces intègrent un marquage des métadonnées associant les clés à la classification des données, aux finalités de traitement et aux cadres réglementaires. Lorsqu’une institution reçoit une demande d’accès, les systèmes doivent identifier quelles clés protègent les données de l’individu concerné, vérifier l’autorisation, journaliser l’accès et fournir les données déchiffrées dans des formats portables.

Les processus automatisés (tâches batch, réplication, sauvegardes) nécessitent un accès aux données chiffrées sans intervention humaine. Les comptes de service doivent s’authentifier par certificats plutôt que par mots de passe statiques. L’accès aux clés pour ces comptes doit respecter le principe du moindre privilège, n’accordant l’accès qu’aux clés nécessaires au processus concerné. Les institutions doivent mettre en place des procédures d’urgence (« break-glass ») permettant de suspendre temporairement l’accès aux clés en cas d’incident de sécurité.

Sélection des Fournisseurs et Aspects Contractuels

La mise en œuvre d’un contrôle des clés de chiffrement conforme aux exigences de l’EBA débute dès la sélection des fournisseurs. Les institutions financières doivent évaluer les capacités techniques et la volonté contractuelle des prestataires à soutenir des modèles de gestion des clés par le client avant tout engagement d’externalisation.

L’évaluation des capacités techniques porte sur la prise en charge de l’intégration avec des gestionnaires de clés externes via des API standardisées. Les fournisseurs d’infrastructure cloud proposent de plus en plus ce type d’intégration. Les plateformes SaaS peuvent offrir des options « bring-your-own-key » via des partenariats avec des fournisseurs de gestion de clés. Les plateformes de communication doivent permettre un chiffrement géré par le client, où les opérations cryptographiques sont réalisées dans le périmètre institutionnel avant que les données n’entrent dans l’infrastructure du fournisseur.

Les contrats doivent préserver explicitement le contrôle unilatéral de l’institution sur les clés de chiffrement et délimiter clairement les responsabilités. Ils doivent préciser que le fournisseur n’aura jamais accès aux données sensibles en clair, que toutes les opérations de chiffrement utilisent des clés fournies par le client et que le fournisseur ne conserve aucune copie persistante du matériel de clé. Les clauses de sortie sont cruciales : les contrats doivent garantir que l’institution reçoit l’intégralité des données chiffrées dans des formats documentés à la résiliation, sans exiger de déchiffrement ou de rechiffrement géré par le fournisseur.

Les droits d’audit contractuels permettent à l’institution de vérifier la mise en œuvre effective des contrôles de gestion des clés. Il est recommandé de négocier le droit d’auditer les procédures de gestion des clés du fournisseur, d’inspecter les logs d’accès aux clés et de tester les procédures de récupération. Ces droits d’audit tiers sont particulièrement importants pour les plateformes SaaS, où l’institution ne peut pas inspecter directement l’infrastructure.

Résilience Opérationnelle et Préparation aux Contrôles Réglementaires

Les institutions financières exploitent des architectures hybrides couvrant plusieurs environnements. Une infrastructure centralisée de gestion des clés constitue la base du contrôle dans ces environnements hybrides. Les institutions doivent déployer des systèmes de gestion des clés offrant des API accessibles depuis les datacenters sur site, plusieurs fournisseurs cloud et des plateformes SaaS via des connexions réseau sécurisées. Cette centralisation garantit l’application cohérente des contrôles d’accès et la génération unifiée des journaux d’audit.

La centralisation de la gestion des clés crée des points de défaillance potentiels. Les décideurs doivent s’assurer que les systèmes de gestion des clés atteignent un niveau de disponibilité au moins équivalent à celui des applications protégées. Les architectures à haute disponibilité reposent généralement sur des clusters répartis géographiquement avec bascule automatique. Les stratégies de mise en cache optimisent les performances mais doivent être soigneusement mises en œuvre. Les applications peuvent mettre en cache localement les clés de chiffrement des données pour une durée limitée, mais ces clés mises en cache doivent respecter immédiatement les signaux de révocation.

La planification de la reprise après sinistre doit couvrir les scénarios où l’infrastructure de gestion des clés reste opérationnelle alors que les environnements principaux de traitement des données sont indisponibles. Les institutions doivent pouvoir rediriger les charges de travail vers d’autres environnements, établir de nouvelles connexions à l’infrastructure de gestion des clés existante et reprendre les opérations sans régénérer le matériel de clé.

Les contrôles réglementaires vérifient la traduction effective des exigences de l’EBA en réalité opérationnelle. Les examinateurs attendent des cadres de gouvernance documentaire, des schémas d’architecture technique, des matrices de contrôle d’accès et des journaux d’audit couvrant des périodes représentatives. La documentation commence par des politiques de gouvernance expliquant l’interprétation des exigences de l’EBA sur le contrôle des clés, les modèles d’architecture adoptés et la répartition des responsabilités entre équipes. Les schémas d’architecture doivent illustrer les composants de gestion des clés, la connectivité réseau, les points d’intégration avec les fournisseurs d’identité et les frontières séparant le contrôle institutionnel de l’infrastructure gérée par le fournisseur.

Les examinateurs analysent les journaux d’audit pour vérifier l’efficacité des politiques. Les institutions doivent préparer des échantillons représentatifs de logs couvrant l’accès normal des utilisateurs, les opérations des comptes de service, les tâches administratives et les tentatives d’authentification échouées. Une préparation efficace implique d’analyser les logs pour identifier et expliquer les anomalies avant qu’elles ne soient détectées par les examinateurs. La corrélation entre les logs d’accès aux clés et les plateformes SIEM renforce la démonstration de conformité.

Les examinateurs demandent de plus en plus des démonstrations en direct des capacités de contrôle des clés. Les institutions doivent se préparer à montrer des scénarios de révocation de clés, des procédures d’urgence (« break-glass ») et des procédures de récupération permettant d’accéder à des données chiffrées à partir de clés archivées. Il est recommandé de réaliser régulièrement des tests internes, en faisant tourner les personnes responsables de l’exécution des procédures pour s’assurer que la connaissance ne repose pas sur un seul expert.

Conclusion

Les lignes directrices de l’EBA sur l’externalisation font du contrôle des clés de chiffrement une exigence fondamentale, car il conditionne la capacité des institutions financières à garder la maîtrise réelle des données sensibles traitées par des tiers. Sans gestion indépendante des clés, les institutions ne peuvent pas valider l’intégrité des données, appliquer des restrictions d’accès, garantir la récupération ou démontrer leur souveraineté lors des contrôles réglementaires.

Répondre à ces exigences implique d’investir dans des infrastructures de gestion des clés par le client — incluant des HSM validés FIPS 140-3 et l’application d’AES-256 pour les données au repos et TLS 1.3 pour les données en transit —, de négocier des contrats préservant le contrôle unilatéral et de mettre en place des processus opérationnels intégrant la gestion des clés à la gouvernance des identités et à la génération des journaux d’audit. Les décideurs doivent privilégier ces fonctions lors du choix des fournisseurs, allouer les ressources nécessaires pour atteindre les objectifs de haute disponibilité et établir des cadres de gouvernance traduisant le langage réglementaire en contrôles opérationnels.

Les institutions qui mettent en place un contrôle robuste des clés de chiffrement bénéficient d’avantages stratégiques allant au-delà de la conformité. Elles réduisent la dépendance vis-à-vis des fournisseurs en gardant la capacité de déchiffrer et de migrer les données de manière indépendante. Elles améliorent leurs capacités de réponse aux incidents en contrôlant la révocation des clés comme mécanisme immédiat de confinement. Elles renforcent leurs arguments de souveraineté des données face à des exigences juridiques contradictoires selon les juridictions.

Les institutions financières ne peuvent plus considérer la gestion des clés de chiffrement comme une simple question technique à déléguer aux équipes d’infrastructure. Les exigences de l’EBA élèvent le contrôle des clés au rang de priorité de gouvernance, nécessitant l’attention de la direction générale, la supervision du conseil d’administration et des investissements continus à la hauteur de son rôle central dans les stratégies d’externalisation défendables.

Comment Kiteworks Permet un Contrôle Défendable des Clés de Chiffrement pour les Communications Sensibles

Les institutions financières rencontrent des difficultés particulières pour mettre en œuvre le contrôle des clés de chiffrement sur les données sensibles en mouvement via la messagerie électronique, le partage de fichiers et les intégrations API. Les approches traditionnelles reposent soit sur des clés gérées par le fournisseur, soit sur une gestion décentralisée par les utilisateurs finaux via S/MIME et PGP, ce qui s’avère insoutenable opérationnellement.

Le Réseau de données privé comble cette lacune en appliquant un chiffrement applicatif avec AES-256 et des clés gérées par le client avant que le contenu sensible ne quitte le périmètre institutionnel, toutes les communications étant sécurisées via TLS 1.3. Les institutions financières déploient Kiteworks dans leurs propres environnements ou dans des clouds dédiés, où elles gardent la maîtrise totale du matériel de clé de chiffrement, y compris l’intégration avec des HSM validés FIPS 140-3. Lorsque les utilisateurs partagent des fichiers, envoient des e-mails chiffrés ou transfèrent des données via des API sécurisées, Kiteworks chiffre le contenu avec des clés sous contrôle direct de l’institution. Les contenus chiffrés traversent les réseaux tiers mais restent protégés par des clés inaccessibles au fournisseur.

Cette architecture répond aux exigences de l’EBA, car l’institution garde la capacité unilatérale de refuser l’accès aux données en clair. Kiteworks agit comme plateforme de communication mais ne peut pas déchiffrer le contenu protégé sans demander les clés à l’infrastructure de gestion des clés contrôlée par le client. Les opérations sur les clés s’intègrent aux fournisseurs d’identité institutionnels, appliquent la gestion des accès basée sur les rôles (RBAC) centralisée et génèrent des journaux d’audit immuables retraçant chaque opération de chiffrement, de déchiffrement et d’accès aux clés à des utilisateurs et contextes métier précis.

Kiteworks propose des fonctions de cartographie de conformité associant automatiquement les opérations sur les clés au RGPD, à la DSP2 et à d’autres cadres réglementaires. Lorsqu’un régulateur demande des preuves d’audit, les équipes de sécurité peuvent produire des rapports détaillés montrant quels collaborateurs ont accédé à quelles catégories de données sensibles, à quelles fins et selon quelles chaînes d’autorisation. L’intégration avec les plateformes SIEM telles que Splunk, IBM QRadar et Microsoft Sentinel permet d’alimenter la gestion des clés dans les workflows de sécurité globaux.

Réservez votre démo sans attendre ! Découvrez comment Kiteworks permet à votre institution de mettre en œuvre un contrôle des clés de chiffrement conforme aux exigences de l’EBA tout en préservant l’efficacité opérationnelle des flux de communication sensibles.