Vous êtes dans : Accueil > Tribunes libres >

DPI de GHT : habilitations et contrôles, partie IV

Cédric Cartau, MARDI 27 FéVRIER 2018 Soyez le premier à réagirSoyez le premier à réagir

Dans une première partie(1), nous avons examiné les deux grandes familles de politique d’habilitation dans les accès à un DPI d’établissement de santé. Nous en avons conclu que la seule méthode viable à terme au sein d’un GHT était celle du contrôle a posteriori. Dans une deuxième partie(2), nous avons décrit les trois conditions pour aller vers ce mode de gestion : concertation entre les CME, systèmes homogènes de sanctions au sein de tous les établissements du GHT et généralisation de l’analyse des traces d’accès. Dans une troisième partie(3), nous avons décrit les grands principes du système de contrôle d’accès aux données patients. Intéressons-nous maintenant à la question des accès aux données des administrateurs qui, à une époque pas si lointaine, faisait pas mal fantasmer dans les chaumières (j’ai connu des diplodocus qui refusaient de saisir des données dans un logiciel métier au prétexte que le DBA(4) y avait accès en direct en saisissant des requêtes SQL).  

Premier point : les administrateurs ne sont pas seulement des personnels de la DSI ; la notion désigne toute personne qui dispose de droits étendus sur un logiciel. Dans le cas d’un DPI, il faut y ranger une partie des personnels d’un DIM, certains référents fonctionnels métiers, les admin système bien entendu, mais aussi les ingénieurs applicatifs en charge des entrepôts de données, et pas mal de personnels de recherche (la création tous azimuts des entrepôts de données médicales pour la recherche, plus ou moins formalisée, est un défi de taille pour tous les GHT adossés à un CHU).

Deuxième point : disons-le tout net, si vous pensez qu’il est possible d’interdire l’accès à des données sensibles à tout ce beau monde, vous vous trompez lourdement. Il y a toujours quelqu’un qui possède les clés de la boutique, et les seuls dispositifs qui évitent cet écueil fonctionnent sur des systèmes de quorum (il faut deux clés sur trois pour ouvrir la boîte), mais cela induit un retard considérable dans l’accès à la donnée, donc aux interventions de maintenance, donc à la disponibilité des logiciels, donc à la sécurité du patient. Et en plus, cela coûte un bras. Fin du débat. 

Cela étant, entre ne rien faire et tout bloquer, le curseur peut bouger, et on peut – on doit – encadrer ces accès. Un beau jour dans pas longtemps, un contrôleur quelconque, interne ou externe, viendra exiger des DSI qu’elles mettent en place des dispositifs d’encadrement de ces accès : autant anticiper ce qui de toute manière finira immanquablement par arriver. 

Premièrement, il faut former tous ces agents. Formation obligatoire à l’arrivée dans la fonction (on est nul dans les DSI sur ce point), révision annuelle des personnels formés (car ils bougent), et formation par des Mooc tout au long de l’année. J’aime beaucoup celui de l’Anssi(5), qui est remarquablement bien construit, mais si des lecteurs ont d’autres exemples, je suis preneur. Ensuite, il faut faire signer les profils de postes adéquats, et éventuellement une charte admin ou un engagement de confidentialité. Point suivant, il faut que toutes ces personnes aient accès à une expertise SSI en cas de question pointue, et il va forcément s’en poser : ai-je le droit de lancer telle requête ? Un chef de service me demande telle extraction, est-elle légitime ?, etc. Enfin il faut contrôler a minima les accès tous les ans, ce qui est le point le plus complexe dans la mesure où les outils utilisés (accès direct aux bases, SAS, etc.) ne permettent pas toujours une traçabilité facilement exploitable. Et, j’allais oublier, tous ces agents disposent d’un compte admin nominatif, et surtout distinct de leur compte agent. 

Certes, il y a des trous dans la raquette, mais ce dispositif est assez léger à mettre en place, ne coûte pas bien cher et surtout permet de démontrer la bonne foi de l’institution en cas de contrôle.


(1)   http://www.dsih.fr/article/2834/dpi-de-ght-habilitations-et-controles-partie-i.html 

(2)   http://www.dsih.fr/article/2844/dpi-de-ght-habilitations-et-controles-partie-ii.html 

(3)   http://www.dsih.fr/article/2850/dpi-de-ght-habilitations-et-controles-partie-iii.html 

(4)   Administrateur de base de données.

(5)   https://secnumacademie.gouv.fr 

logiciel, dpi, dsih, dsi, formation