Synthèse
L’arrêt Schrems II a durablement modifié les conditions de transfert des données à caractère personnel européennes vers les États-Unis. Pour les plateformes d’essais cliniques, qui traitent des données de patients parmi les plus sensibles, les conséquences sont majeures. Les clauses contractuelles types (SCC) restent un mécanisme de transfert valable, mais uniquement lorsqu’elles sont associées à une analyse d’impact du transfert (TIA) démontrant un niveau de protection des données véritablement équivalent. Lorsque les données sont hébergées chez des hyperscalers américains, cette démonstration devient de plus en plus difficile sans contrôles techniques empêchant totalement le fournisseur cloud d’accéder aux données.
Bring Your Own Key (BYOK) constitue aujourd’hui la mesure technique complémentaire la plus pratique pour les plateformes d’essais cliniques. Correctement mis en œuvre, avec des clés adossées à des HSM et conservées hors du périmètre de confiance de l’hyperscaler, le BYOK garantit que même une demande légale d’accès adressée au fournisseur cloud par les autorités américaines ne produira aucune donnée exploitable. Ce livre blanc présente les risques liés à Schrems II pour les plateformes d’essais cliniques, les exigences techniques d’un BYOK défendable et les caractéristiques concrètes d’une architecture conforme.
1. L’arrêt Schrems II et ses exigences concrètes
En juillet 2020, la Cour de justice de l’Union européenne (CJUE) a invalidé le cadre du Privacy Shield UE–États-Unis dans l’affaire Data Protection Commissioner contre Facebook Ireland Limited et Maximillian Schrems (C-311/18). La Cour a estimé que le droit américain de la surveillance, notamment la section 702 de la FISA et l’Executive Order 12333, permet aux services de renseignement américains d’accéder aux données à caractère personnel traitées par des entreprises américaines dans des conditions incompatibles avec le droit au recours juridictionnel des personnes concernées dans l’UE.
Les clauses contractuelles types n’ont pas été invalidées. La Cour a toutefois été explicite : les SCC ne constituent un mécanisme de transfert valable que si l’importateur de données peut effectivement respecter les garanties contractuelles qu’elles prévoient. Lorsque le droit du pays de destination l’en empêche, comme le droit américain de la surveillance pour les données détenues par des fournisseurs cloud américains, les SCC seules ne suffisent pas.
En novembre 2020, le Comité européen de la protection des données (CEPD) a publié les recommandations 01/2020, qui ont formalisé l’exigence d’une analyse d’impact du transfert et recensé les mesures supplémentaires susceptibles de rendre défendable un transfert fondé sur les SCC. Point essentiel, le CEPD a identifié une catégorie de mesures techniques — notamment le chiffrement lorsque l’exportateur de données conserve seul le contrôle des clés — pouvant rendre les données « inaccessibles » à l’importateur et donc effectivement protégées, y compris au regard du droit américain de la surveillance.
En pratique, les plateformes d’essais cliniques qui traitent des données de patients de l’EEE sur des hyperscalers américains doivent pouvoir démontrer que le fournisseur cloud ne peut pas accéder aux données en clair, même s’il y est légalement contraint. Un BYOK correctement mis en œuvre permet d’apporter cette démonstration.
2. Pourquoi les données d’essais cliniques présentent un risque particulièrement élevé
Toutes les données à caractère personnel ne présentent pas le même profil de risque au regard de Schrems II. Les données d’essais cliniques se situent au niveau d’exposition le plus élevé pour deux raisons qui se cumulent.
Premièrement, les données d’essais cliniques relèvent des catégories particulières de données visées à l’article 9 du RGPD. Les données de santé, génétiques et biométriques appartiennent toutes à cette catégorie soumise à des conditions de traitement plus strictes et à des sanctions potentielles plus lourdes en cas de violation. Une violation de Schrems II portant sur des données d’essais cliniques n’est pas un incident RGPD ordinaire : elle expose l’exploitant de la plateforme aux sanctions prévues à l’article 83, paragraphe 5, pouvant atteindre 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial.
Deuxièmement, les données d’essais cliniques sont irremplaçables sur le plan opérationnel. Contrairement à une base de données clients compromise, elles ne peuvent pas simplement être régénérées : elles constituent le dossier principal de l’essai. Les autorités de réglementation, l’EMA, la FDA et les autorités nationales compétentes imposent des exigences d’archivage et d’accès qui s’étendent sur plusieurs décennies. Toute décision d’architecture compromettant l’intégrité ou la disponibilité des données entraîne donc des conséquences à la fois réglementaires et cliniques.
La combinaison d’une forte sensibilité réglementaire, de longues durées de conservation et de flux de données transfrontaliers — le traitement de données de patients européens sur des plateformes américaines étant l’architecture par défaut de la plupart des fournisseurs SaaS eClinical — soumet les plateformes d’essais cliniques à un examen au regard de Schrems II plus approfondi que presque toute autre catégorie de SaaS.
3. Les limites du couple SCC + TIA et la réponse apportée par le BYOK
Lorsque des plateformes d’essais cliniques s’appuient sur les SCC pour leurs transferts UE–États-Unis, elles doivent réaliser une TIA évaluant objectivement si le destinataire américain peut assurer les protections promises par ces clauses. Pour les données traitées sur les principaux hyperscalers américains (AWS, Azure, Google Cloud), la conclusion est délicate : le droit américain de la surveillance peut contraindre le fournisseur cloud à communiquer les données et, en tant que détenteur des clés de chiffrement dans une configuration KMS cloud standard, celui-ci en a techniquement la capacité.
Le BYOK comble précisément cette lacune. Si les clés de chiffrement sont conservées hors du contrôle de l’hyperscaler — dans un HSM exploité par une entité européenne, avec des accès gouvernés par le client européen — l’hyperscaler ne peut fournir aucune donnée exploitable, même s’il y est contraint. Il ne peut produire que du texte chiffré. La protection est alors réelle et technique, et non simplement contractuelle.
Trois conditions doivent être réunies pour que le BYOK constitue une mesure complémentaire efficace au regard de Schrems II :
La génération des clés doit avoir lieu hors de l’hyperscaler. Les clés générées dans AWS KMS ou Azure Key Vault se trouvent, par définition, dans son périmètre de confiance. Un BYOK défendable exige que les clés soient générées dans un HSM que l’hyperscaler n’exploite pas et auquel il n’a pas accès.
Le stockage et la gouvernance des clés doivent être isolés sur le plan juridictionnel. L’entité qui contrôle le HSM et le cycle de vie des clés doit être une personne morale européenne soumise au droit européen, sans société mère américaine susceptible d’être contrainte en vertu du droit américain. Cette exigence est aussi bien juridique que technique.
Les accès aux clés doivent être journalisés et contrôlés par le client. Pour qu’une TIA puisse établir que tout accès par le fournisseur cloud est empêché, une piste d’audit doit démontrer que chaque utilisation d’une clé est autorisée par le client, et non par le fournisseur cloud. La révocation des accès — c’est-à-dire la capacité à suspendre ou supprimer l’accès à une clé et à rendre les données inaccessibles — doit réellement relever du contrôle du client.
La gestion des clés native standard des hyperscalers ne satisfait pas à ces exigences. Une infrastructure externe de gestion des clés est nécessaire.
4. Architecture d’intégration aux KMS cloud
Les principaux hyperscalers ont chacun développé des interfaces d’intégration pour les clés gérées en externe, précisément pour répondre à ce besoin du marché :
AWS KMS External Key Store (XKS) permet à AWS d’utiliser, pour les opérations KMS, des clés de chiffrement provenant d’un gestionnaire de clés externe. Celui-ci exécute les opérations cryptographiques sans jamais exporter le matériel de clé vers AWS. AWS KMS lui envoie des requêtes de wrap/unwrap ; le gestionnaire les exécute et renvoie le résultat. La clé ne quitte jamais le HSM.
Azure Key Vault Managed HSM BYOK permet aux clients d’importer dans Azure Key Vault Managed HSM du matériel de clé généré dans leur propre HSM, au moyen d’un protocole d’échange qui protège ce matériel pendant le transit. Pour les cas d’usage Schrems II les plus exigeants, l’architecture privilégiée conserve le matériel de clé dans un HSM contrôlé par le client et utilise les mécanismes de clés externes d’Azure plutôt que de l’importer dans une infrastructure contrôlée par Azure.
Google Cloud KMS External Key Manager (EKM) s’intègre à un service externe de gestion des clés par l’intermédiaire d’une API REST. GCP envoie les demandes d’accès aux clés au KMS externe, qui les autorise ou les refuse selon une politique définie par le client, puis exécute localement l’opération cryptographique.
Dans chaque cas, le modèle d’intégration est identique : l’hyperscaler demande au gestionnaire de clés externe d’exécuter les opérations cryptographiques au lieu de les réaliser avec des clés qu’il contrôle. Le fournisseur cloud n’a jamais accès au matériel de clé en clair.
5. Caractéristiques d’une architecture conforme
Pour une plateforme d’essais cliniques traitant des données de patients de l’EEE sur des hyperscalers américains, une architecture défendable au regard de Schrems II présente les caractéristiques suivantes :
Les données de patients au repos sont chiffrées à l’aide de clés gérées par un KMS externe auquel le fournisseur cloud ne peut pas accéder. Ce KMS externe est exploité par une personne morale européenne, sur une infrastructure européenne et sous juridiction européenne.
Les opérations sur les clés — génération, rotation, suspension et révocation — sont exécutées par l’équipe sécurité de la plateforme ou déléguées à un fournisseur de services managés dans le cadre d’un accord de traitement des données conforme aux exigences de l’article 28 du RGPD.
Chaque accès à une clé est journalisé avec suffisamment de détails pour déterminer qui a accédé à quelles données, à quel moment et au moyen de quelle clé. Les journaux sont exportables et disponibles pour les contrôles réglementaires.
La révocation des accès est testée en conditions opérationnelles et documentée. La plateforme peut démontrer que la suspension d’une clé rend les données associées inaccessibles dans le délai défini par le SLA et que cette capacité a été effectivement éprouvée.
La TIA s’appuie sur l’architecture technique, en particulier sur la séparation juridictionnelle entre la gestion des clés et le traitement cloud, comme principal fondement permettant de conclure que le transfert est défendable.
Cette architecture ne supprime pas la nécessité des SCC ni d’une TIA. Elle rend la TIA défendable.
6. Comment Alcazarix prend en charge un BYOK conforme à Schrems II
Alcazarix fournit un service BYOK managé spécifiquement conçu pour les cas d’usage liés à Schrems II. Notre infrastructure de gestion des clés s’appuie sur Alcazarix Canada pour les charges de travail nord-américaines et Alcazarix Germany pour les charges de travail européennes, dans des datacenters dédiés et sous l’exploitation d’entités juridiques distinctes aux frontières juridictionnelles clairement définies.
Nous nous intégrons nativement à AWS KMS XKS, Azure Key Vault Managed HSM BYOK et Google Cloud KMS EKM. Les plateformes d’essais cliniques peuvent ainsi déployer le BYOK avec leur KMS cloud existant sans modifier la couche applicative. Les clés sont générées dans des HSM sous le contrôle d’Alcazarix, avec des politiques d’accès et de gouvernance définies par le client, une gestion complète du cycle de vie et des journaux d’audit exportables.
Pour les fournisseurs SaaS eClinical, nous prenons en charge des architectures multitenant dans lesquelles chaque promoteur d’essai peut détenir ses propres clés. L’isolation entre les jeux de données des promoteurs est ainsi maintenue au niveau de la gestion des clés, conformément aux attentes de l’ICH E6(R3) GCP en matière de contrôle des données par le promoteur.
Alcazarix a délibérément choisi de ne pas être certifié FIPS. Nous nous concentrons sur les contrôles essentiels pour Schrems II : maîtrise des clés, isolation juridictionnelle, gouvernance des accès et auditabilité. Cette approche permet de maintenir des coûts nettement inférieurs à ceux des fournisseurs HSM historiques tels que Thales ou Utimaco, sans compromettre les protections techniques qui rendent une TIA défendable.
7. Conclusion
Schrems II n’est pas une simple case à cocher en matière de conformité : il impose une évolution durable de l’architecture des transferts de données entre l’UE et les États-Unis. Pour les plateformes d’essais cliniques, qui traitent des données extrêmement sensibles dans un contexte réglementaire exigeant, l’approche SCC + TIA nécessite de véritables mesures techniques complémentaires. Le BYOK, mis en œuvre au moyen d’une gestion externe des clés adossée à des HSM et placée sous contrôle juridictionnel européen, est le moyen le plus direct de concrétiser ces mesures.
Pour les architectes sécurité qui évaluent la posture Schrems II de leur plateforme, la question essentielle n’est pas de savoir si des SCC sont en place — elles le sont dans la plupart des cas. Il s’agit de déterminer si leur TIA résisterait à l’examen d’une autorité européenne de protection des données. Si vos clés de chiffrement résident dans AWS KMS ou Azure Key Vault et sont gérées par le fournisseur cloud, la réponse objective est probablement négative.
Pour en savoir plus sur la manière dont Alcazarix accompagne les plateformes d’essais cliniques avec un BYOK conforme à Schrems II, contactez-nous à hello@alcazarix.com ou consultez alcazarix.com.