Photo de l'article Infrastructure cloud et intégration des applications : architecture, contrats et sortie en Suisse
Photo par ColossusCloud sur Pixabay

Voies d'intégration

Infrastructure cloud et intégration des applications : architecture, contrats et sortie en Suisse

Le cloud computing signifie techniquement que les applications, logiciels, espaces de stockage, outils de développement, capacités réseau ou puissance de calcul sont fournis à la demande via un réseau – par exemple Internet –…

Comprendre les modèles d’architecture et les limites de responsabilité

Le cloud computing signifie techniquement que les applications, logiciels, espaces de stockage, outils de développement, capacités réseau ou puissance de calcul sont fournis à la demande via un réseau – par exemple Internet – par un prestataire de services cloud. Si des données personnelles sont transmises dans ce processus, la Loi fédérale sur la protection des données (LPD) s’applique. L’élément décisif pour l’architecture est la limite de responsabilité entre le prestataire et le client. Celle-ci varie considérablement selon le modèle.

Avec le Software as a Service (SaaS), les entreprises utilisent des applications prêtes à l’emploi – par exemple pour la comptabilité, la gestion de la relation client (CRM) ou la bureautique – directement auprès du prestataire. Elles n’installent rien et bénéficient de mises à jour continues ainsi que d’un support technique. Le logiciel est généralement fourni via le web ; le prestataire assume la responsabilité de l’exploitation et de la maintenance.

Le Desktop as a Service (DaaS) est un sous-type. Le prestataire met à disposition des postes de travail virtuels depuis le cloud ; l’utilisateur obtient un bureau complet qui s’exécute sur le serveur du prestataire. Ici aussi, le prestataire assume toute la responsabilité de l’infrastructure.

Avec l’Infrastructure as a Service (IaaS), l’entreprise loue des capacités serveur, de l’espace de stockage ou une infrastructure réseau et peut y faire fonctionner ses propres logiciels. La responsabilité de l’infrastructure physique, de la haute disponibilité et de la sécurité fondamentale des données incombe au prestataire ; pour le système d’exploitation et la couche application, l’entreprise reste responsable. Cette part de responsabilité propre est souvent sous-estimée dans la pratique.

Quel que soit le modèle, la responsabilité en matière de protection des données reste du côté du client. Les entreprises restent responsables du respect de la LPD lorsqu’elles externalisent des données dans le cloud et confient des tâches techniques au prestataire. Le simple stockage de données personnelles dans le cloud est déjà considéré comme un traitement et relève de la LPD. La loi exige un traitement transparent, lié à un but précis et proportionné, ainsi que des mesures techniques et organisationnelles appropriées.

Il en découle des questions récurrentes d’architecture : où se trouvent géographiquement les données, et dans quelle mesure l’environnement de chaque client est-il isolé de celui des autres clients ? Comment la haute disponibilité est-elle organisée sur plusieurs sites, et à quel niveau le chiffrement est-il appliqué ?

Les fournisseurs de solutions de cloud privé mettent en avant des centres de données géoredondants en Suisse, des environnements dédiés et entièrement isolés par client, ainsi qu’un chiffrement intégral. De telles affirmations doivent être vérifiées contractuellement et techniquement, et ne pas être acceptées comme de simples arguments marketing.

Intégrer les applications sans perdre de vue les flux de données

Les aspects critiques du point de vue de la protection des données concernent souvent des applications cloud banales et quotidiennes. Cela inclut les outils bureautiques pour la collaboration en ligne entre collaborateurs, les outils de gestion en ligne des adresses e-mail pour les newsletters ou le conseil à la clientèle, les systèmes CRM en ligne, le téléchargement de vidéos sur des plateformes de streaming ainsi que le téléversement de fichiers sur un serveur accessible via Internet. Dans tous ces cas, des données personnelles sont traitées, même si l’application sert principalement à un objectif opérationnel.

Avant l’intégration, il convient de définir quelles données vont où. Il faut documenter au minimum les catégories de données concernées et leur origine, les interfaces entrantes et sortantes, les destinataires au sein et en dehors de l’organisation, les sous-traitants impliqués ainsi que les lieux de stockage et de traitement, y compris les éventuelles copies de sauvegarde. Cet enregistrement n’est pas une opération ponctuelle. Il doit être revu lors de l’adoption de chaque nouvelle application, de chaque mise à jour apportant de nouvelles fonctionnalités et de chaque changement de prestataire.

La clarté des rôles est une condition préalable. L’entreprise qui fournit des services cloud agit généralement en tant que sous-traitant au sens de l’art. 9 LPD. Le client peut lui-même être responsable du traitement des données ou être à son tour sous-traitant ; s’il est sous-traitant, il doit satisfaire aux exigences définies par le responsable pour ses traitements de données. En tant que responsable, il porte la responsabilité que les traitements effectués pour son compte soient conformes à la protection des données et que les droits des personnes concernées ne soient pas réduits par l’externalisation.

Concrètement, cela signifie : celui qui intègre une plateforme de newsletter, un CRM ou une plateforme vidéo doit clarifier, avant le premier import de données, s’il s’agit d’un sous-traitance, quels sous-traitants sont impliqués et si des données transitent vers un autre pays. Si un service est mis en production sans cette vérification, la reconstruction du niveau des flux de données sera ultérieurement très coûteuse.

Liste de contrôle pour l’intégration d’applications cloud présentant des risques pour la protection des données

  • Documenter les catégories de données et leur origine
  • Identifier les interfaces entrantes et sortantes
  • Définir les destinataires au sein et en dehors de l’organisation
  • Vérifier les sous-traitants et leurs lieux d’établissement
  • Clarifier les lieux de stockage et de traitement, y compris les copies de sauvegarde

Contrats : sous-traitance, sous-traitants ultérieurs et droits de contrôle

Dans le cloud computing, il s’agit généralement d’une sous-traitance de données : le prestataire traite les données transmises pour le compte du client. Cette sous-traitance doit être réglementée contractuellement. Le standard minimal comprend un droit d’instruction et de contrôle du mandant ainsi qu’un niveau de base de sécurité des données.

En tant que responsable, l’utilisateur du cloud est tenu de s’assurer et de sécuriser contractuellement qu’il respecte les exigences relatives à la sous-traitance selon l’art. 9 LPD.

Les grands fournisseurs de cloud disposent de modèles de contrats préétablis pour la sous-traitance de données. Ces modèles doivent être examinés de manière critique et non repris tels quels. Ils sont souvent formulés en faveur du fournisseur et ne couvrent pas toujours les exigences suisses. Il convient de régler particulièrement les conditions de recours à d’autres sous-traitants, l’information et, le cas échéant, le droit d’opposition du client en cas de changements, les obligations de notification en cas d’incidents de sécurité ainsi que la question de savoir qui supporte les coûts d’un audit.

Les droits de contrôle ne devraient pas rester lettre morte. Il est judicieux de préciser clairement quelles preuves le prestataire fournit régulièrement, dans quelles conditions des audits sur place sont possibles et comment interpréter les certifications. La suppression et la restitution des données doivent également figurer explicitement dans le contrat. Quand les données sont-elles supprimées, sous quel format sont-elles restituées, et qu’advient-il des copies dans les systèmes de sauvegarde et chez les sous-traitants ?

Exigences suisses en matière de protection des données dans le cloud computing

  • Entrée en vigueur de la LPD le 1er septembre 2023Champs d’application élargis, y compris pour les traitements initiés à l’étranger
  • Pas de droit de séparation en cas de failliteLes données ne sont pas considérées comme des choses au sens du Code civil suisse (CC) – pas de propriété sur les données

Transfert vers des pays tiers et souveraineté des données : États-Unis, UE et régions suisses

Les données personnelles ne peuvent en principe être transférées que vers des pays offrant un niveau de protection des données adéquat. Selon l’opinion largement répandue, un tel niveau n’est pas garanti pour les États-Unis. De tels transferts doivent être sécurisés autrement – sinon ils doivent être abstention. Comme garantie de substitution, les clauses contractuelles types prévues par le droit européen à l’art. 46 du RGPD entrent notamment en considération.

La Suisse dépend quant à elle de la reconnaissance par l’UE. La décision d’adéquation de la Commission européenne concernant la Suisse date de l’an 2000. La révision du droit suisse de la protection des données a également été réalisée dans le but de garantir cette reconnaissance.

La LPD révisée, ainsi que la nouvelle Ordonnance sur la protection des données et l’Ordonnance sur la certification en matière de protection des données, sont entrées en vigueur le 1er septembre 2023. Le champ d’application a été élargi. Il s’étend désormais également aux traitements qui ont des effets en Suisse, bien qu’ils aient été initiés à l’étranger. Seules les personnes physiques sont protégées.

Chez les grands fournisseurs de cloud, les emplacements des serveurs peuvent généralement être limités régionalement. Il est recommandé de limiter cette région à l’Europe et de prévoir contractuellement qu’aucune donnée personnelle ne quitte cette région. Une telle limitation géographique est plus efficace qu’une simple déclaration d’intention, car elle peut être vérifiée techniquement et contractuellement.

Il faut distinguer cette question de celle de la souveraineté des données. Les modèles de cloud dit « souverain » visent à ce que ni les gouvernements étrangers ni les multinationales étrangères ne puissent accéder à l’infrastructure ou la surveiller. Qu’un tel modèle tienne la route dépend des structures de propriété, du siège du prestataire, des obligations de divulgation applicables et des possibilités réelles d’accès aux clés et au système d’exploitation. Le stockage régional seul ne suffit pas si le prestataire peut rester légalement obligé d’accéder aux données.

Sortie : restitution des données, faillite et absence de droit de séparation

Si le prestataire de cloud fait faillite, il se peut que l’utilisateur du cloud ne puisse plus accéder à ses données. Selon le droit actuel en Suisse, il n’existe pas de droit de séparation pour les données d’un tiers en cas de faillite d’une entreprise. Le droit suisse ne connaît pas non plus de droit de propriété sur les données. Les données ne tombent pas sous la notion de chose au sens du Code civil suisse (CC), car elles manquent de la corporéité nécessaire.

Cette situation de départ ne peut pas être résolue par une simple clause contractuelle. Le cas de figure ne peut généralement pas être clarifié uniquement au regard du droit suisse, puisque la plupart des grands fournisseurs de cloud sont établis à l’étranger. La sortie doit donc être planifiée de manière prospective – comme partie intégrante de l’architecture et non comme annexe au contrat.

Il faut ancrer contractuellement au minimum : un droit à la restitution complète des données dans un format courant et lisible par machine ; des délais pour la restitution et la suppression subséquente ; l’obligation d’aide à la transition pendant une phase de migration définie ; ainsi que la sécurisation de copies en dehors de l’environnement du prestataire. Celui qui ne miroite pas ses données dans un système propre et contrôlé dépend, en cas de sinistre, uniquement de la volonté de coopération de la masse faillitaire.

Le plan de sortie devrait également identifier les efforts en personnel et les dépendances techniques : quelles applications dépendent de la même plateforme, quelles interfaces doivent être remplacées, et quels formats de données peuvent être repris sans perte ? Une sortie qui n’est réfléchie qu’en cas de faillite n’est pratiquement plus réalisable.

Plan de déroulement pour une sortie sécurisée du cloud

  1. Définir contractuellementrestitution dans un format lisible par machine
  2. Convenir de délais pour la restitution et la suppression
  3. Organiser l’aide à la transition pendant la phase de migration
  4. Sécuriser des copies en dehors de l’environnement du prestataire
  5. Tester préalablement la capacité de restauration

Les sauvegardes sont une proie : repenser la sauvegarde et la restauration des données

De nombreuses PME partent du principe qu’une sauvegarde existante constitue déjà une protection. Précisément cette hypothèse est aujourd’hui un risque. Les copies de sauvegarde peuvent se trouver dans le même compte cloud que les données de production et être accessibles avec les mêmes identifiants. En cas de compromission du compte, elles peuvent être chiffrées ou supprimées conjointement ; une sauvegarde au même endroit et avec les mêmes droits que l’original ne protège pas contre les scénarios de dommages les plus probables.

Les sauvegardes font donc partie de l’architecture cloud et du plan de sortie, et ne relèvent pas de la seule responsabilité du département IT. Des sauvegardes chiffrées et redondantes, conservées à un endroit séparé du système de production et restaurables à tout moment par sa propre organisation, sont judicieuses. Là où les données doivent rester en Suisse, cela doit également s’appliquer aux copies de sauvegarde et aux systèmes de sauvegarde d’éventuels sous-traitants.

Aussi importante que la sauvegarde est la restauration. Une restauration qui n’a jamais été testée n’est, en cas d’urgence, qu’une supposition. Il faut clarifier : combien de temps dure une restauration complète, qui peut la déclencher, quels droits sont nécessaires pour cela, et comment vérifie-t-on que les données restaurées sont complètes et inchangées ? Ces tests devraient être documentés et répétés à intervalles réguliers.

Enfin, la sauvegarde des données doit être coordonnée avec la sous-traitance : qui sauvegarde quelles données, combien de temps les sauvegardes sont-elles conservées, et comment sont-elles supprimées lorsque le contrat prend fin ? Sans cette coordination, il reste ouvert de savoir si des résidus de données subsistent dans les systèmes de sauvegarde après un changement de prestataire.

Vérification du prestataire sous l’angle de l’exploitation, de la conformité et de la sortie

La vérification d’un prestataire de cloud ne devrait pas s’arrêter à l’étendue des fonctionnalités et au prix. Une interrogation structurée autour de huit points s’est avérée efficace.

Cela inclut l’emplacement des données et les lieux de stockage des sauvegardes ; les sous-traitants utilisés, avec leur siège et les modalités de changement ; les mesures de sécurité techniques et organisationnelles, y compris le chiffrement et la gestion des clés. Il convient également de vérifier les droits contractuels d’instruction et de contrôle ainsi que les possibilités d’audit ; les éventuels transferts vers des pays tiers et leur sécurisation ; le risque de faillite et la position juridique du prestataire ; les modalités de restitution des données, y compris le format et l’exhaustivité ; ainsi que les délais de sortie et l’aide à la transition.

Les indications du PFPDT sur le cloud computing servent d’orientation. Selon celles-ci, trois aspects sont particulièrement à prendre en compte : le recours à des sous-traitants et sous-traitants ultérieurs, la sécurité du traitement des données et le transfert de données personnelles vers des pays tiers. Le PFPDT mentionne sous « Autres informations » la fiche d’information révisée de privatim « Risques spécifiques au cloud et mesures » (2022). Il y cite également les brochures de l’Office fédéral allemand de la sécurité dans le domaine des technologies de l’information sur l’utilisation sécurisée des services cloud (2016) et sur le choix d’un service cloud (2022).

Lors de l’évaluation, il faut tenir compte du fait que les services cloud sont fournis en tant que solutions standardisées. La standardisation réduit les coûts et augmente l’évolutivité, mais rend plus difficiles les accords individuels. Lorsque le prestataire n’autorise aucune dérogation à ses conditions standards, l’organisation doit décider si les risques restants sont acceptables pour les données concrètes – et si, le cas échéant, une autre solution avec une limitation régionale plus forte ou un environnement propre n’est pas plus judicieuse.

La vérification doit être documentée et répétée. Les occasions pour ce faire sont la première acquisition d’un service, des modifications substantielles du contrat ou des fonctionnalités, de nouveaux sous-traitants, des changements dans la situation juridique ainsi que le départ de personnes clés chez le prestataire. Celui qui consigne les résultats par écrit peut prouver ultérieurement que la sélection a été effectuée avec soin. Lors du prochain changement de prestataire, les questions décisives seront déjà rassemblées.

Liste de contrôle en 8 points pour la vérification du prestataire cloud

  1. Emplacement des données et lieux de stockage des sauvegardes
  2. Recours à des sous-traitants et leurs emplacements
  3. Mesures de sécurité techniques et organisationnelles
  4. Droits d’instruction et de contrôle ainsi que possibilités d’audit
  5. Transferts vers des pays tiers et leur sécurisation
  6. Risque de faillite et position juridique du prestataire
  7. Modalités de restitution des données (format, exhaustivité)
  8. Délais de sortie et aide à la transition

Plus dans Voies d'intégration