Rapport explicatif

La communauté ne peut pas assurer la protection et la sécurité des données sans le concours des institutions de santé qui lui sont affiliées et d’éventuels fournisseurs de biens et services. C’est pourquoi il faut que ses exigences en matière de protection et de sécurité des données soient respectées non seulement par son personnel (p. ex. personnel du service d’assistance pour les professionnels de la santé), mais aussi par les éventuels tiers auxquels il est fait appel (p. ex. l’exploitant de la structure informatique de la communauté). C’est ce que prévoit la let. f. Les exigences qu’énoncent les CTO pour le personnel portent en particulier sur la gestion des personnes ainsi que de leurs accès et droits d’utilisateur (cf. ch. 4.10 CTO). Les communautés doivent également suivre des règles dans la gestion de leurs fournisseurs afin qu’un niveau élevé de sécurité puisse être maintenu en permanence pour tous les acteurs impliqués (communautés, institutions, fournisseurs et sous-traitants), quelle que soit la structure d’organisation adoptée (cf. ch. 4.11 et 4.12 CTO). Par exemple, les communautés ont l’obligation d’imposer le respect des exigences de protection et de sécurité des données tout au long de la chaîne d’approvisionnement, au cas où les fournisseurs mandateraient des sous-traitants (cf. ch. 4.11.5.5 CTO).

L’obligation de déclarer les incidents jugés importants pour la sécurité de l’information à l’organisme de certification et à l’OFSP qu’instaure l’al. 2 a pour but de fournir des informations sur les points faibles découverts ou exploités dans l’organisation ou l’infrastructure informatique des différentes communautés. Ces informations seront analysées et évaluées en vue de prendre éventuellement des mesures visant à prévenir de nouveaux incidents. Il s’agit avant tout d’étendre les connaissances et l’expérience pour les communautés et les communautés de référence, mais aussi pour les organismes de certification et pour l’OFSP en sa qualité d’autorité régulatrice dans le domaine de la protection et de la sécurité des données. De plus, l’évaluation régulière des incidents de sécurité peut faire apparaître d’éventuelles tendances au niveau des menaces rencontrées, permettant ainsi aux communautés d’adopter en temps utile des contre-mesures appropriées. Aux termes de l’art. 36, l’OFSP peut ordonner des mesures en cas de grave mise en danger de la protection ou de la sécurité des données du dossier électronique du patient. Les communautés et les communautés de référence ainsi que les organisations d’exploitation peuvent en outre, si elles le souhaitent, bénéficier des services de conseil et d’information de la Centrale d’enregistrement et d’analyse pour la sûreté de l’information de la Confédération (MELANI). MELANI peut fournir à ses clients des informations précieuses sur les dangers actuels et les mesures appropriées pour y faire face, mais aussi faciliter les échanges d’informations entre les exploitants d’infrastructures critiques ou exposées à des dangers.

En application de l’al. 3, le DFI complète, aux ch. 4.13 à 4.23 CTO, les prescriptions énoncées à l’al. 1, let. a à f, par des règles de protection et de sécurité des données qui portent, entre autres, sur les domaines suivants :

 sécurité d’exploitation, restauration des systèmes et historisation de l’exploitation des systèmes (cf. ch. 4.14 CTO) ;

 achat, développement et maintenance des systèmes (cf. ch. 4.15 CTO) ;

 cryptage de la communication et de l’enregistrement des données (cf. ch. 4.16 à 4.18 CTO) ;  gestion des réseaux et des services réseau utilisés pour l’exploitation des systèmes (cf. ch. 4.19 à 4.22 CTO) ;

 accessibilité (cf. ch. 4.23 CTO).

Un aspect appelle des explications particulières : le choix des mesures pour mettre en œuvre les exigences en matière de cryptage des données doit se baser sur les risques et, notamment, tenir compte du volume de données à protéger. Il convient tout d’abord de sélectionner des algorithmes et des procédures cryptographiques sûrs, mais aussi en particulier d’utiliser un ou plusieurs niveaux de cryptage en fonction des risques (p. ex. cryptage des disques, des bases de données ou des applications). On a renoncé dans un premier temps à imposer dans les présentes dispositions d’exécution un cryptage systématique des contenus transmis (et pas seulement du canal de transmission) de terminal à terminal (end-to-end-encryption E2EE). En effet, il est actuellement impossible d’apporter des réponses défini-