Changer de cloud : transférer les clés et les accès

Les fichiers sont copiés dans le nouveau cloud, mais certaines archives dépendent encore d’une ancienne clé. Le prestataire sortant conserve aussi un compte sur la plateforme d’arrivée. Dans cette situation, la réussite du transfert ne démontre ni la continuité de lecture, ni la fermeture des anciens accès. La migration doit traiter ces deux sujets séparément.

Cette méthode s’adresse au responsable informatique et au référent RGPD qui doivent accepter une bascule. Elle permet de préparer un dossier de décision, sans supposer que les clés sont exportables ou qu’un mécanisme identique existe chez tous les fournisseurs.

Identifier ce qui ouvre réellement les données

Une clé de chiffrement rend possible le déchiffrement d’un contenu. Un mot de passe, un jeton d’API ou une autorisation sur un compte permet d’utiliser un service. Les deux peuvent se combiner : une application reçoit le droit d’appeler un service de clés sans jamais recevoir directement le secret cryptographique.

Il faut donc poser deux questions : qui peut déchiffrer et qui peut demander un déchiffrement ? Changer le mot de passe d’un administrateur ne révoque pas nécessairement l’identité d’une application. Inversement, retirer une permission ne détruit pas une clé ni une copie précédemment téléchargée.

La CNIL explique les différentes formes de chiffrement cloud. Un chiffrement opéré côté serveur ne supprime pas, à lui seul, les possibilités de lecture du fournisseur. Pour votre migration, documentez les capacités effectives de chaque acteur plutôt que de retenir uniquement la mention « chiffré » dans une offre commerciale.

L’Art. 32(1)(b)–(d) du RGPD concerne notamment confidentialité, intégrité, disponibilité, restauration et évaluation des mesures. Perdre l’accès à des archives encore nécessaires constitue donc un problème même si personne d’autre ne peut les lire. Le dossier de sécurité du cloud reste applicable pendant toute la transition.

Établir une fiche par ensemble de données

Commencez par les ensembles présentant des dépendances différentes : base active, pièces jointes, archives chiffrées, sauvegardes et fichiers de transit. Un inventaire par abonnement ne suffit pas lorsqu’une même application utilise plusieurs versions de clé.

Pour chaque ensemble, renseignez :

• l’emplacement source et la destination prévue ;
• les données encore nécessaires et les éléments exclus de la migration ;
• le mécanisme et les références des clés, sans inscrire leurs valeurs secrètes ;
• les personnes et services autorisés à lire, exporter ou administrer ;
• la preuve attendue de récupération et le responsable de sa vérification ;
• le sort des copies temporaires et de l’environnement source.

Une référence de clé doit être exploitable par l’équipe habilitée : service concerné, identifiant et version lorsque nécessaire. « Clé du cloud » ne permet pas de déterminer quelle archive resterait lisible après fermeture. Conservez les secrets dans les moyens sécurisés prévus pour eux, pas dans le tableau de suivi ou un ticket largement accessible.

Cette organisation prolonge la recommandation CNIL sur la gestion des clés : accès restreints et procédure couvrant leur gestion et leur récupération. Elle ne dispense pas d’une compétence technique pour choisir et configurer les mécanismes cryptographiques.

Choisir entre transfert de clé et reprise des contenus

Demandez aux fournisseurs une réponse écrite sur l’opération réellement supportée. Trois voies peuvent être étudiées, selon l’architecture ; elles ne constituent pas trois fonctions universellement disponibles.

Transférer une clé compatible. Il faut vérifier si son export est permis, dans quel format protégé et avec quelles conditions d’importation. Le fait de posséder juridiquement une clé ne prouve pas qu’un service permet son extraction. Vérifiez aussi les versions antérieures nécessaires à la lecture d’anciens contenus.

Déchiffrer puis chiffrer à nouveau. Si cette voie est retenue, définissez où les données deviennent lisibles, par quel processus, sous quelles permissions et pendant combien de temps. Une zone de transit peut contenir des données plus exposées que les fichiers source ; son nettoyage et ses sauvegardes doivent figurer au plan.

Maintenir provisoirement une dépendance. Un ancien service de clés peut rester nécessaire pour un périmètre réduit. Cette solution doit avoir un propriétaire, un coût identifié, des accès limités et une condition de sortie. Elle ne justifie pas de laisser ouvert l’ensemble du service sortant.

Refusez les réponses qui confondent ces voies. « Nous copions les fichiers » ne précise pas comment les lire ; « vous gardez la clé » ne précise pas qui continue de pouvoir l’utiliser. Si aucune solution ne garantit la récupération du périmètre nécessaire, la fermeture correspondante n’est pas prête.

Un dossier de bascule rempli : M-36

Prenons un exercice fictif : une société de maintenance change de plateforme documentaire. Le besoin métier, déjà validé dans le scénario, porte sur trente-six dossiers actifs et douze dossiers archivés encore nécessaires. Les archives utilisent une ancienne clé K-1 ; les dossiers actifs sont exportés par l’application puis chiffrés à destination avec K-2. Ces noms sont des références fictives, pas des secrets.

Le fournisseur confirme dans l’exercice que K-1 n’est pas exportable. L’équipe retient une reprise des archives par un processus autorisé, plutôt qu’un transfert direct de cette clé. Voici la fiche de décision renseignée :

La première vérification du scénario retrouve les trente-six dossiers actifs et onze archives lisibles. La douzième référence existe, mais sa pièce principale ne s’ouvre pas. Le bilan n’est donc pas « quarante-huit dossiers repris » : il est quarante-sept dossiers lisibles et une archive non récupérée. L’existence d’un nom de fichier ne vaut pas récupération de son contenu.

L’équipe conserve la dépendance nécessaire à K-1 et reprend la pièce depuis la source, dans le circuit sécurisé défini. Après vérification de son rattachement et de sa lecture à destination, les douze archives peuvent être déclarées récupérées. Cela ne suffit toujours pas à détruire K-1 : la sauvegarde source prévue pour le retour arrière en dépend aussi.

Le responsable de continuité décide donc de conserver cette clé avec un accès restreint jusqu’à la fin justifiée de cette sauvegarde. Le compte de migration du prestataire, lui, est retiré à destination. Ces décisions différentes évitent de maintenir un accès devenu inutile pour préserver une capacité de restauration encore nécessaire.

Préparer une recette qui démontre le bon périmètre

La vérification doit couvrir le contenu et les accès. Définissez avant la bascule ce qui sera contrôlé exhaustivement et ce qui sera échantillonné, avec une justification adaptée aux risques. Un échantillon lisible ne permet pas d’affirmer que chaque archive a été relue.

Sur le contenu, contrôlez le rapprochement des références, les pièces attendues et leur intelligibilité. Une empreinte identique peut établir l’identité de deux fichiers inchangés ; une conversion de format impose d’autres vérifications. Aucun contrôle technique ne prouve, à lui seul, que le fichier a été rattaché au bon client.

Sur les habilitations, prévoyez un utilisateur autorisé et un profil qui ne doit pas accéder au dossier. Vérifiez aussi les identités applicatives, les liens de partage et les accès d’administration. Le refus d’un ancien compte ne démontre pas que tous les autres accès du prestataire ont disparu.

La CNIL recommande de retirer les permissions devenues sans objet. Dans M-36, la preuve attendue est une liste des accès de migration avec leur issue : retiré, conservé pour une tâche précise, ou encore à vérifier. Une case globale « prestataire supprimé » masquerait ces différences.

Les contrôles décrits ici sont une méthode à exécuter dans votre environnement, pas les résultats d’un essai de logiciel effectué pour cet article. Joignez les résultats réels au dossier, avec l’heure, le périmètre, l’opérateur et les anomalies restant ouvertes.

Organiser le retour sans réintroduire des données périmées

Le plan de reprise d’activité doit préciser qui peut décider un retour et jusqu’à quel point. Dès que le nouveau système reçoit des modifications, restaurer simplement l’ancien état peut faire perdre des opérations ou réintroduire des données rectifiées ou effacées.

Dans M-36, deux interventions sont ajoutées après la bascule. Si un retour devient nécessaire, elles doivent être rapprochées du système repris, avec leurs pièces et leurs états. Copier un ancien instantané ne suffit pas. Les demandes RGPD exécutées pendant cette période suivent également un journal distinct permettant de réappliquer les décisions pertinentes.

Prévoyez les automatisations : notifications, synchronisations et exports. Deux plateformes actives ne doivent pas émettre deux fois la même opération ni écraser mutuellement leurs corrections. Si la réconciliation n’est pas démontrée, limitez les traitements concernés plutôt que d’autoriser un fonctionnement parallèle indéfini.

Clore séparément contrat, copies et clés

L’Art. 28(3)(g) du RGPD prévoit, au choix du responsable, la suppression ou le renvoi des données en fin de prestation et la destruction des copies, sauf obligation légale de conservation. Donnez une instruction précise au prestataire et demandez une réponse sur chaque périmètre, y compris les copies résiduelles.

La destruction d’une clé ne prouve pas automatiquement l’effacement sécurisé des données : il peut exister d’autres clés, des copies déchiffrées ou des exports. Elle peut aussi rendre indisponibles des données encore nécessaires. Faites confirmer les dépendances avant cette opération irréversible.

Enfin, une copie perdue, une altération accidentelle ou un accès non autorisé demande une qualification distincte : violation au sens de l’Art. 4(12), documentation et examen des notifications selon les Art. 33–34. Une réserve de migration n’est pas automatiquement une violation, mais sa résolution technique ne remplace pas cette analyse lorsqu’elle est nécessaire. Textes : chapitre I et chapitre IV.

Ce qu’il faut retenir

• Distinguez le secret cryptographique des permissions permettant de l’utiliser.
• Vérifiez la possibilité réelle de reprise avant de fermer l’ancien service.
• Une archive lisible, une sauvegarde restaurable et un accès retiré sont trois preuves différentes.
• Conservez les réserves et les dépendances jusqu’à leur résolution documentée.

FAQ

Faut-il toujours exporter les anciennes clés ?

Non. L’architecture peut imposer une reprise contrôlée des contenus puis un nouveau chiffrement. Il faut démontrer la lecture et la restauration nécessaires sans supposer une fonction d’export inexistante.

Peut-on détruire une clé après la bascule ?

Seulement après avoir déterminé les données qui en dépendent encore et leur sort légitime. Les sauvegardes, anciennes versions et copies déchiffrées nécessitent un examen distinct.

Une migration terminée ferme-t-elle tous les accès ?

Non. Comptes humains, identités applicatives, liens et permissions doivent être recensés puis traités. Les exceptions conservées ont besoin d’une justification et d’une échéance.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.