La résidence des données, c'est l'endroit où elles sont stockées. La
souveraineté des données détermine qui peut être contraint de les
communiquer. Le débat sur la souveraineté numérique s'arrête le plus souvent
à l'emplacement du centre de données, et beaucoup de questionnaires
fournisseurs vérifient le premier point tout en présumant le second. C'est dans
cet écart qu'un déploiement en apparence conforme échoue sans que
personne ne s'en aperçoive.
Le déploiement, qui semblait conforme, échoue sans que l'on s'en aperçoive.
Le mécanisme en cause ici est le CLOUD Act américain. Un fournisseur soumis à la juridiction des États- Unis peut être contraint de communiquer les données qu'il détient, dont il a la garde ou le contrôle, en réponse à une demande légale américaine, même lorsque ces données sont stockées hors des États-Unis. L'obligation s'attache au fournisseur, non à l'emplacement du serveur. Nous avons développé ailleurs l'argumentaire complet de souveraineté pour le secteur public, et il vaut tout autant pour une banque, un assureur, un hôpital ou un cabinet d'avocats.
Le plus simple est de comprendre la distinction. Établir si un fournisseur précis de votre liste restreinte réussit réellement ce test est plus difficile, car le fournisseur, sa maison mère, son fournisseur de cloud, son partenaire d'hébergement et son prestataire de support peuvent relever chacun d'une juridiction différente. Les cinq questions suivantes permettent de le vérifier. Inscrivez-les noir sur blanc dans l'appel d'offres, et traitez une réponse vague ou partielle comme un constat, pas comme une formalité.
Les cinq questions
1. Quelles entités juridiques figurent réellement dans la chaîne ?
L'adresse du siège n'est pas une réponse sur la juridiction. Demandez l'identité de l'entité contractante, de sa société mère ultime et de toute filiale qui détient, traite ou peut accéder aux données clients, ainsi que le pays de constitution de chacune. Un fournisseur dont le siège est hors des États-Unis peut néanmoins rester exposé à une obligation de communication si une société mère ou une filiale américaine détient les données ou en a le contrôle. Demandez à chaque fournisseur de votre liste restreinte d'énoncer sa position juridictionnelle au niveau de l'entité, et pas seulement au niveau de la marque. L'entité d'Inuvika qui signe le contrat est établie au Canada ou au Royaume-Uni, et n'est pas soumise à la juridiction américaine. C'est ce niveau de précision, entité par entité, que la réponse doit apporter.
À quoi ressemble une mauvaise réponse: une adresse commerciale, un nom de pays sans entité derrière, ou le silence sur la société mère.
2 Qui d'autre, dans la chaîne, peut être contraint de communiquer les données ?
Cette question met au jour un risque que la première ne couvre pas. L'éditeur du logiciel n'est qu'un maillon. Le fournisseur de cloud, le partenaire d'hébergement, l'infogéreur et tout sous-traitant de support relèvent chacun de leur propre juridiction, et chacun peut détenir des données susceptibles de devoir être communiquées, en avoir la garde ou le contrôle. Un déploiement chez un hyperscaler américain, ou un support assuré par un prestataire américain, peut réintroduire le risque que la situation juridictionnelle du fournisseur semblait avoir écarté. Si cette partie détient des données pertinentes, en a la garde ou le contrôle, le risque existe. Un fournisseur peut être entièrement hors juridiction américaine et livrer malgré tout votre service via des parties qui ne le sont pas.
Cartographiez chaque partie de la chaîne et la juridiction dont elle relève. Parce qu'Inuvika OVD Enterprise est agnostique en matière d'hyperviseur et de cloud, vous pouvez maintenir cette chaîne dans l'infrastructure et avec les partenaires de votre choix, plutôt que d'hériter de l'empreinte juridique d'un cloud mondial unique.
À quoi ressemble une mauvaise réponse: une réponse qui ne couvre que l'entité du fournisseur lui-même, ou une région de cloud présentée comme si la région faisait la juridiction.
3. À quoi chaque partie peut-elle accéder, et qui détient les clés ?
Les « données clients » ne se limitent pas aux documents. Pour chaque partie de la chaîne, demandez à quoi elle peut accéder parmi les contenus, les journaux, les sauvegardes, la télémétrie et les fichiers de support, et demandez qui détient les clés de chiffrement. La garde des clés est une question de juridiction, pas seulement de sécurité. Car une partie qui détient les clés peut être en mesure de communiquer des données lisibles. Pour les déploiements sur site, OVD Enterprise ne collecte aucune donnée client (hormis, de façon volontaire, la date d'expiration de l'abonnement et les données agrégées d'utilisation), ce qui réduit sensiblement ce que nous pourrions un jour être amenés à communiquer. OVD Enterprise peut également fonctionner dans un environnement totalement isolé (« air gap »). Lorsque le client opte pour un service géré, nous le livrons via des partenaires d'hébergement locaux et indépendants, dans votre pays, plutôt que via un opérateur mondial unique.
À quoi ressemble une mauvaise réponse: « les données sont chiffrées », sans dire qui détient les clés, ou un périmètre limité aux documents, sans un mot sur les journaux, les sauvegardes ou la télémétrie.
4. Quelles données quittent l'environnement lors du support à distance ?
Même une installation sur site n'est pas hermétique d'office. Demandez quelles données sortent de l'environnement pour les mises à jour, les diagnostics et le support, et si les sessions de support à distance créent un accès temporaire aux informations clients. Ce sont les canaux capables de réintroduire une exposition qu'une vérification de la résidence des données a pu considérer comme close. Faites confirmer ce qui est transmis, y compris s'il s'agit de métadonnées opérationnelles ou de contenu client, qui le reçoit, et de quelle juridiction relève le destinataire.
À quoi ressemble une mauvaise réponse: « rien ne sort de l'environnement », affirmé sans la liste de ce que transmettent réellement les canaux de licence, de mise à jour et de diagnostic.
5. Comment le fournisseur traite-t-il une demande gouvernementale ?
La question de la compétence juridictionnelle porte en fin de compte sur ce qui se passe lorsqu’une demande est effectivement reçue. Demandez à chaque prestataire de vous communiquer sa procédure documentée. Remet-il en cause ou restreint-il les demandes trop générales ? Informe-t-il le client lorsque la loi l’y autorise ? Rend-il compte du volume de demandes qu’il reçoit ? Un prestataire ne disposant pas d’une procédure documentée risque de devoir improviser avec vos données si une demande lui est adressée. Voici un exemple de requête sur Google.
À quoi ressemble une mauvaise réponse: l'assurance qu'aucune demande n'a jamais été reçue, offerte à la place d'un processus pour toute demande future.
C'est aux questions deux à cinq que beaucoup de revendications de souveraineté se défont, et un fournisseur ne peut pas y répondre par une seule ligne sur son siège social.
Où cela se place dans votre grille d'évaluation
Pour les organisations dont les obligations de souveraineté excluent toute obligation de communication imposée par une autorité étrangère, la juridiction est un critère éliminatoire : une solution qui ne satisfait pas ce critère doit être écartée avant même la comparaison des fonctionnalités et du prix. Pour toutes les autres organisations soumises à la réglementation, elle entre dans la grille comme un facteur important de risque juridique, pondéré au regard de la sensibilité de vos données, des exigences de votre régulateur, de votre mode de déploiement et de ce que vos contrats couvrent déjà, plutôt que renvoyée en note de bas de page. Dans les deux cas, ce critère doit faire l'objet d'une évaluation explicite, à partir de questions écrites à l'avance.
Nous avons conçu OVD Enterprise pour les acheteurs qui posent ces questions. Découvrez comment OVD Enterprise est conçu pour un déploiement souverain et sécurisé, ou lancez un essai gratuit.
Questions fréquentes
Un partenaire d'hébergement local peut-il réintroduire une exposition étrangère ?
Oui, et c'est une manière courante de faire dérailler un examen de souveraineté. Si le partenaire
d'hébergement, sa maison mère ou le fournisseur de cloud sous-jacent relèvent d'une juridiction étrangère et
détiennent des données pertinentes, en ont la garde ou le contrôle, l'exposition peut revenir, quel que soit le
pays d'immatriculation du fournisseur et quel que soit l'endroit où les données résident physiquement. Le test
de juridiction doit s'appliquer à chaque partie de la chaîne, pas seulement au nom qui figure sur le contrat.
Que doit contenir, concrètement, le processus d'un fournisseur face à une demande gouvernementale ?
Au minimum : un processus documenté d'examen de la validité juridique de la demande, un engagement à
contester ou à restreindre les demandes trop larges, une notification du client partout où la loi l'autorise, et
une forme de rapport de transparence sur le nombre de demandes. Demandez-le par écrit. Un fournisseur qui
n'a pas déjà de processus a peu de chances d'en produire un crédible sous la pression d'un appel d'offres.
Un déploiement sur site règle-t-il la question à lui seul ?
Pas automatiquement. Le déploiement sur site élimine une catégorie majeure d'exposition, mais il ne couvre
pas à lui seul les vérifications de licence, les canaux de mise à jour et de diagnostic, ni les sessions de support
à distance, dont chacun peut faire sortir de l'information de l'environnement. Demandez à tout fournisseur de
documenter précisément ce que ces canaux transmettent, à qui, et de quelle juridiction relève le destinataire.
Ces canaux subsistent même en cas de déploiement sur site, et c'est exactement pour cela qu'ils doivent être
évalués séparément.