Annexe 4 _Sécurité de l`information - e

ANNEXE 4
Sécurité de l’information
Document de référence
Aide à la Définition des exigences de sécurité
Dans le cadre de l’élaboration
D’un cahier de charges
13/06/2014
11/06/2014
GM
GM
04/06/2014
GM
Adaptation Interprétations acronyme MoSCoW
Document de base –
présentation groupe chef projet informatique
Elaboration du document.
Exigences sécurité
Lors de l’élaboration d’un cahier de charges,
1. Revue des exigences de base avec le Conseiller en Sécurité du Système d’Information
2. Au besoin, sélection, ajout, retrait d’exigences et adaptation des niveaux d’exigences
3. Emission d’un rapport contradictoire (identification et raison des écarts)
4. Validation formelle par l’utilisateur principal et l'exécutif du projet pour acceptation des risques non
couverts ou résiduels
5. Intégration des exigences retenues et de leur niveau d’exigence dans le cahier de charge
Le Dossier Patient Informatisé est au cœur du système d’information et est indispensable pour soutenir
l'activité de l'institution. Dans sa conception, son architecture, son développement, sa maintenance et dans
son utilisation, cette solution doit impérativement répondre aux exigences de sécurité de l’information et de
protection de la confidentialité des données à caractère personnel.
Il en est de même pour toute solution périphérique participant à la prise en charge médicale, soignant ou
administrative du patient ou participant aux missions des Cliniques gérant des données à caractère personnel,
des données critiques ou sensibles.
Côté patient, si l'informatisation du milieu hospitalier tend à assurer un meilleur partage de
l'information au sein de l'institution et des équipes médicales et soignantes lors de la prise en charge
médicale, la dématérialisation du dossier amène une certaine inquiétude : «Trop de monde peut
accéder à mon dossier ». Ainsi, toute solution doit répondre à cette préoccupation en vue du respect
des droits du patient. Le dossier ou toute partie participante à sa constitution doit être vu comme un
coffre-fort électronique dont l'accès est limité aux seules personnes habilités lors des prises en
charge médicale et pour assurer la continuité des soins.
Côté utilisateur, le souhait est d’avoir à disposition une solution ergonomique flexible, mobile,
d’accès facile et permanent pour les missions que l'utilisateur assure : prise en charge du patient
qu'elle soit médicale, soignante ou administrative, enseignement, recherche.
La question de la sécurité tend à trouver le point d'équilibre et de convergence dans le strict respect des lois
et des règles.
Les données à caractère personnel, et spécifiquement les données médicales, doivent être gérées
comme appartenant à un coffre-fort électronique à savoir un espace virtuel de stockage et de
conservation sécurisé et réputé inviolable permettant de restituer ce qui y a été déposé sans altération.
Dès lors, dans une vision idéale, seuls les professionnels de la santé qui participent à la continuité des soins
du patient, c’est-à-dire à des activités de diagnostic, de traitement ou de prévention, peuvent accéder aux
informations nominatives. Pour assurer les missions d'enseignement et de recherche, l'utilisateur accédera à
des informations anonymisées.
Les exigences s'appliquent à tout actif informationnel (solution informatisée et appareillage médical –
pour tout « objet » : exécutables, données, serveur (application ou base de données), poste utilisateur
(fixe ou mobile),...). En annexe1, schéma des bonnes pratiques en matière de datasecurity management.
Les différentes garanties à rencontrer sont :
• l'authentification (au besoin, forte) (qui),
• l'autorisation ou contrôle d'accès (qui peut avoir accès),
• la confidentialité (qui accède à quoi, quand, comment et pourquoi),
• le droit de modification (qui modifie quoi), et
• la traçabilité (qui a fait quoi)
• l’intégrité, la disponibilité et la rétention de l’information (sécuriser et protéger le quoi)
Relevé des exigences en rapport aux fonctionnalités des solutions
Le tableau suivant reprend les fonctionnalités. L’interprétation des valeurs de l'acronyme MoSCoW étant:
M - MUST - DOIT l’avoir – exigence obligatoire, impérative et vitale.
S - SHOULD - DEVRAIT l’avoir – exigence obligatoire, essentielle et critique mais peut être remplacée par
une solution alternative technique et/ou organisationnelle offrant un niveau de sécurité équivalent, reconnue
et validée par la commission de confidentialité et de sécurité de l’information.
C - COULD (POURRAIT l’avoir) –devrait être implémentée dans les intérêts du projet, si les ressources
projet le permettent. Une solution alternative assurant la finalité de l’exigence est à proposer si
l’implémentation de l’exigence se fera par la suite.
W – WOULD - peut être implémenté par la suite.
Fonctionnalités
Niveau
Niveau
proposé
retenu
1
Contrôle d’accès
1.1
Accès contrôlé aux seuls utilisateurs habilités (en fonction de M
profils individuels, rôle(s), association avec des groupes de travail)
aux applications et aux fonctions pour un « accès nécessaire et
suffisant » en liaison avec le contrôle de session.
1.2
Accès contrôlé pour des tiers externes (rejet des connexions M
abusives, logs des tentatives usurpées, refus d'interception de
session) (niveau browser, application et db)
1.3.
Format et valeurs de l’identifiant login calqués au format et valeurs M
des logins institutionnels.
1.4
Identification des utilisateurs synchronisés avec un annuaire central S
(A.D. ou type LDAP) sur base d'un groupe ou attribut.
1.5.
Comptes à privilèges (application, DB, server) propre à l’institution M
avec accès contrôlé et journalisé (refus d’une approche générique)
1.6.
Subordination à la solution institutionnelle de Single-Sign-On
2.
Fonctions de sécurité
2.1.
Plan de classement ou catégorisation des informations (à défaut, M
niveau le plus élevé doit être appliqué)
2.2.
Fonctionnalité de gestion des droits d'accès, attribution et M
révocation – avec historique des droits (via rôle administrateur
d'application)
2.3.
Mécanisme sécurisé de connexion et de gestion et de suivi de M
session. (usage protocole SSL, challenge de session, refus dans les
url de données de session/identification, absence de persistance de
données session en dehors de la session…)
2.4.
Mécanisme d'Horodatage (timestamping des informations)
2.5.
Mécanisme d'Horodatage certifié (conformité législation pour les M
S
M
Fonctionnalités
Niveau
Niveau
proposé
retenu
fonctionnalités de prescription) (compatibilité interface ehealth)
2.6.
Conversion des formats vers un format pérenne (en entrée) (exple C
de format jugé pérenne : pdf/A-1, XML, Tiff groupe 4, ODT,...)
2.7.
Pérennité - Conversion des formats au sein de la solution pour toute M
information nécessitant un archivage électronique (interface dossier
patient et conservation des données et rapports légaux) (exple de
format jugé pérenne : pdf/A-1, XML, Tiff groupe 4, ODT,...)
2.8.
Disponibilité (QoS) (en fonction des besoins des services M
utilisateurs – adaptation du SLA)
2.9.
Mécanisme et procédure intégrés au Plan de continuité et de reprise S
des services utilisateurs ou de l'institution
2.10.
Mécanisme de maintien des capacités (puissance, stockage S
adéquat)
2.11.
Outil d'audit de sécurité – interrogation et rapport de tout accès aux S
données sur base des traces
2.12.
Mécanisme d’impression sécurisée – marquage automatique de la M
mention « confidentiel », horodatage, identité utilisateur.
2.13.
Mécanisme de prévention contre la copie et la fuite de données S
(contrôle des ports, encryption,..)
3
Authentification - Non répudiation
3.1
Authentification univoque des utilisateurs et non répudiation des M
actions (au besoin, authentification forte suivant mécanisme adapté
à la sensibilité des informations, aux modes de communication)
3.2
Signature électronique associé aux actions (conformité législation M
des prescriptions)
3.3.
Signature électronique à valeur probante (conformité législation M
pour les documents communiqués électroniquement à un tiers
externe) (p.e. comptabilité carte eID)
3.4.
Mécanisme de délégation formelle (association responsable / S
délégué avec gestion des historiques des associations)
4
Protection du contenu
4.1.
Chiffrement du contenu en fonction de la catégorie de l'objet
M
4.2.
Chiffrement des communications et des échanges
M
5.
Intégrité / exactitude
.
5.1.
Intégrité (bit par bit) en contenu et en format
M
5.2.
Intégrité avec évolution des données / formulaires - gestion de la M
.
Fonctionnalités
Niveau
Niveau
proposé
retenu
présentation historique
5.3.
Lisibilité dans le temps
M
5.4.
Mécanisme de retrait logique d'informations et notification M
(données erronées, droit rectification émanant du patient)
5.5.
Mécanisme de couplage ou découplage de dossiers (fusion)
6.
Confidentialité
6.1.
Confidentialité (contenu secret) vis-à-vis des collaborateurs M
habilités (en fonction de la catégorisation des données et des
groupes métiers) (collecte et traitement des informations limités à
celles nécessaires, aux seuls fins attendues , accès à un champ en
fonction de l'utilisateur, du rôle, du groupe métier)
6.2.
Confidentialité (contenu secret) vis-à-vis de tiers externes. M
Séparation et isolement des données de celles des autres clients
(p.e. cas cloud privé/communautaire)
6.3.
Confidentialité vis-à-vis d’administrateurs du système
6.4.
Mécanisme contrôle d'accès en fonction du lien thérapeutique et/ou S
dossier ouvert/fermé en fonction des périodes de visites du patient
et possibilité de bris-de-glace (cas d'urgences)
6.5.
Anonymisation des données d'identification des patients/ des S
personnes pour accès dans le cadre des missions de recherche et
d'enseignement
6.6.
Indication des patients à risque élevé (notion de VIP, notion S
d'alertes,...)
6.7.
Mécanisme d'enregistrement du consentement éclairé du patient
6.8.
Mécanisme d'enregistrement du droit d'opposition du patient S
(écartement d'un prestataire de soins, retrait d’informations,...)
6.9.
Confidentialité des données relatives à des personnes tierces
6.10.
Automatisation du masquage des données nominatives pour les M
environnements de tests et de validation.
7.
Protection
7.1.
Protection logique des données (restriction d'accès de session M
(time-out), support crypté, mécanisme de Data Lost Protection,
contre altération et accès direct en DB, validation des backups,
procédure d'effacement sécurisé lors retrait des équipements) (être
attentif à l'appareillage médical et aux équipements mobiles)
7.2.
Stockage distinct entre les renseignements d'identité des patients et S
les informations médicales, de soins et de traitements. (Ce service
permettra également aux chercheurs et analystes autorisés
S
M
S
S
Fonctionnalités
Niveau
Niveau
proposé
retenu
d’accéder à des données longitudinales anonymisées).
7.3.
Protection physique des équipements (contre le vol, altération ou M
dégradation, interruptions (pannes de courant et défaillances
techniques),...) (être attentif à l'appareillage médical et aux
équipement mobiles)
7.4.
Maintien du niveau de sécurité (patching OS, anti-virus,...) de tout M
actif informationnel
7.5.
Intégration dans l’Alert Management institutionnel des services S
actifs, gestion des capacités, perte de disponibilité et perte
d’intégrité
7.6.
architecture sécurisée sur base d'un dialogue applicatif des flux en M
entrée, en sortie avec contrôle d'intégrité, de non répudiation,
d'habilitation (agent), supportant proxy, reverse-proxy, firewall,
filtrage IP, filtrage applicatif, emploi de protocole sécurisé.
7.7.
absence de stockage ou de cache de données sur les équipements M
intermédiaires lors des flux et traitements d'informations et absence
d'interface direct sql
8
Rétention des informations – archivage - nettoyage
8.1
Information de la période de rétention sur l'objet (document, S
données) ou chaque groupe d’objets (dossier patient)
8.2.
Mécanisme de gestion de la période de rétention sur chaque groupe C
d'objets (en vue d'un archivage et effacement sécurisé de
l'information)(30 ans dernier contact ou mort du patient)
8.3.
Période de maintien opérationnel du contenant en vue d'une S
restitution et transmission des informations à tout moment, en tout
lieu et en toute occasion
9.
Preuve, Traçabilité, Auditabilité
9.1.
Traçabilité de toutes les actions session (ouverture, clôture, M
tentative infructueuse) dans des journaux inviolables – principe
d'un rôle par session.
9.2.
Traçabilité de toutes les actions de traitement sur les informations M
(consultation, création, modification, suppression logique, dépôt
d'information, diffusion, extraction et impression, tentative
infructueuse d'accès) par groupes d'objets (niveau minimum exigé :
document ou formulaire structuré) dans des journaux inviolables
9.3.
Centralisation des traces vers un système central institution
9.4.
Traçabilité de toutes les actions de gestion (maintenance S
application, maintenance db) -
9.5.
Historique horodaté des modifications et retraits logiques
C
S
Fonctionnalités
Niveau
Niveau
proposé
retenu
9.6.
Sauvegarde horodatée des états et rapports de tout échange, M
traitement et envoi de données légales (p.e. interface eHealth,
portalhealth, registre spf santé,...)
9.7.
Interrogation historique - être en mesure d'afficher le contenu S
antérieur quelle que soit la date ainsi que les détails connexes sur la
personne ayant consulté, saisi ou modifié les données.
10.
Intégration dans le système d'information institutionnel
10.1.
Identification sans équivoques des patients - Synchronisation des S
signalétiques patient avec le référentiel central –
10.2.
Utilisation comme clé identifiant du numéro administratif unique M
par patient (identito-vigilance)
10.3.
Transfert des données médicales pertinentes dans le dossier patient M
informatisé institutionnel
10.4.
Adoption d'un standard de codification des informations (ICD-10, S
SNOMED)
10.5.
Gestion des prestataires de santé et des référentiels de S
nomenclatures intégrée au système d’information central (standard
d’échange HL7)
11.
Gestion de tiers – devoirs et obligations du fournisseur
11.1.
Signature engagement de protection des données
M
11.2.
Contrat fournisseur avec les cliniques
M
11.3.
Garantie de la tenue des informations dans l'espace européen ou M
équivalent (cas du cloud, cas des maintenances) – toute copie de
données nécessite accord préalable des Cliniques.
11.4.
Garantie de réversibilité des données.
11.5.
Garantie d'un cycle de vie de la solution, en programmation sûre et M
règle de passage de la phase développement à l'état production.
11.6.
Garantie d'application d'un change management tant pour M
l'implémentation que la maintenance (procédure change request,
procédure d'accès physique et logique (VPN), procédure de
documentation révisée, procédure d'entretien du matériel (sur poste
ou à l'extérieur),...)
11.7.
Garantie d'un retrait sécurisé des actifs informationnels avec plan M
testé et validé de la réversibilité des informations
11.8.
SLA adapté aux besoins métiers, garantie de résultat
M
M
Analyse contradictoire
Remarques et commentaires
(point
(commentaires et remarques pour justifier l’écart entre le niveau
considéré) proposé et le niveau retenu)
Niveau
Niveau
proposé
retenu
Remarques et commentaires
Niveau
Niveau
proposé
retenu
Annexe 1