MSSanté : tendre vers une implémentation « Zero Trust »
La messagerie sécurisée de santé, MSS ou encore MSSanté permet l’échange de courriels via un flux chiffré entre acteurs définis comme étant de confiance, par l’agence du numérique en santé (ANS) et les différents opérateurs, industriels et établissements eux-même.
Chaque établissement est dans l’obligation d’être MSSanté compatible depuis le 1er janvier 2016. Pour cela, il a deux solutions, faire appel à un opérateur industriel ou devenir lui-même opérateur.
Dans le second cas, au-delà des formalités administratives relatives à la signature d’un contrat avec l’ANS, anciennement ASIP Santé, l’établissement opérateur doit utiliser un proxy MSSanté.
Beaucoup d’établissements ont fait ce choix, pour diverses raisons, avoir la maîtrise de la solution, interfaçage avec les logiciels métiers, coût…
Essayons donc de voir comment éviter de diminuer le niveau de sécurité des flux MSSanté en implémentant la solution dans son SI.
Commençons par le commencement, un proxy MSS, ça sert à quoi ?
Pour faire simple, un proxy MSS est une passerelle exposée sur Internet, intégrant le certificat fournit par l’ASIP / ANS permettant d’émettre et recevoir des messages MSSanté. Cette passerelle fait donc le lien entre un serveur de messagerie choisi par l’établissement et « l’espace » dit de confiance. Pour que les choses soient claires, « l’espace » ne désigne pas un réseau privé. Il s’agit d’une couche de chiffrement et d’authentification venant se placer au-dessus du réseau Internet, permettant ainsi aux différents opérateurs d’échanger les messages MSS de leurs utilisateurs.
L’implémentation au sein du SIH peut se faire de bien des façons.
1. Messagerie dédiée ou convergente avec la messagerie « classique » : premier dilemme
Le proxy ne représentant pas un « serveur de messagerie » à proprement parler, même s’il utilise forcément un outil de type serveur smtp pour échanger des messages avec les proxys MSS des autres opérateurs, il faut donc disposer d’un serveur de messagerie complet pour les utilisateurs. C’est là qu’il faut faire un choix, utiliser le serveur de messagerie existant ou utiliser un serveur de messagerie dédié. Ce choix ne peut évidemment pas être porté par le RSSI tout seul ou encore par la DSI. Voici en revanche quelques éléments de réflexion pour amener Direction et CME à faire le choix le plus judicieux.
1.1 Serveur de messagerie existant, la solution facile
1.1.1 Avantages :
- Facilité d’utilisation, l’utilisateur ne dispose que d’une seule boîte aux lettres
- Facilité d’administration, pas de nouveau serveur à installer et à maintenir
1.1.2 Risques :
- Risque de confusion entre messages MSS et non MSS pour l’utilisateur
- Possibilité de transférer directement des messages MSS à destination de messageries non-MSS. Via un transfert automatique vers une messagerie personnelle (si l’option n’est pas désactivée), ou de façon manuelle, en utilisant l’adresse d’expédition non-MSS, que l’action soit intentionnelle ou non. Autant dire que l’on perd complètement l’intérêt de la solution visant à garantir la confidentialité des données échangées et que l’on enfreint par la même occasion, le RGPD et le code de la santé publique.
1.2 Serveur de messagerie dédié, le choix de la sagesse
1.2.1 Avantages :
- Séparation des usages, meilleure maîtrise et compréhension pour les professionnels de santé
- Le transfert de messages MSS vers des messagerie non-MSS ne sera pas possible, pas de risque de confusion ou d’accident de ce côté-là. Un copié / collé ou une capture d’écran du message ne pourront bien évidemment pas être évités, mais l’utilisateur devra enfreindre les règles volontairement.
1.2.2 Inconvénients :
- Nécessite l’installation et le maintien d’un nouveau serveur
- Impose aux professionnels de santé d’ouvrir deux boîtes aux lettres
2. Enregistrements DNS, adresse IP publique, comment faire les bons choix
Comme pour une messagerie « classique », pour recevoir des messages, un enregistrement DNS de type MX est nécessaire. Qu’il soit enregistré sur les serveurs de l’ANS directement ou délégué sur vos serveurs DNS internes, peu importe. Il devrait ressembler à cela :
Il va ensuite falloir choisir une adresse IP publique à assigner à notre passerelle. Si l’on souhaite séparer les usages, il est préférable que cette adresse IP diffère de celle(s) de(s) (l’)enregistrement(s) MX pointant vers la messagerie « classique ». L’idéal à mon sens est de disposer d’une adresse IP dédiée. Il faudra donc créer un enregistrement DNS de type A ou AAAA (si vous disposez d’adresses IP V6) ressemblant à cela :
Pour éviter de se faire blacklister son adresse IP publique par les filtres anti-spam, créer un enregistrement de type PTR semble être une bonne idée :
Ainsi que spécifier le FQDN dans la bannière du serveur SMTP embarqué dans la solution de proxy MSSanté. Exemple ici avec la configuration du serveur Postfix dans la solution Enovacom Secure Messaging :
3. Cloisonnement et filtrage
Attribuer l’adresse IP publique directement à la carte réseau de notre proxy MSSanté n’étant pas vraiment une bonne idée, vous opterez certainement pour du NAT réalisé par un pare-feu de l’adresse IP publique vers une adresse IP privée. Puisque nous avons le choix, utiliser un VLAN dédié pour isoler le proxy semble être l’idéal car cela limiterait un éventuel déplacement latéral en cas de compromission du proxy.
Le serveur de messagerie MSSanté, n’ayant pas de raisons de se trouver dans un réseau composé de plusieurs machines, là encore, le placer dans un VLAN dédié apparaît comme la meilleure solution.
Qui dit réseaux dédiés, dit également création de règles de filtrage. L’application du moindre privilège reste de mise. Il est préférable de n’autoriser que le strict nécessaire, échanges de flux smtp entre les deux machines, accès aux protocoles d’administration des serveurs depuis le réseau d’administration, accès au Webmail pour les utilisateurs.
La création de règles de filtrages sur les pares-feux physiques ne devrait pas dispenser d’utiliser les pares-feux logiciels des serveurs, sur lesquels des règles équivalentes devraient être créées.
4. Chiffrement du flux SMTP
Nativement, les solutions de proxy MSS ne chiffrent pas forcément les flux d’émission / réception des messages avec le serveur de messagerie. Attention donc de ne pas rompre la chaîne de confiance. Si vous utilisez la solution Enovacom Secure Messaging par exemple, il sera facilement possible d’activer le chiffrement des flux entrants et sortants en configurant le serveur SMTP Postfix sur lequel s’appuie la solution. De la même manière, si le chiffrement n’est pas actif par défaut sur votre serveur de messagerie, il est nécessaire de l’activer et d’affiner son paramétrage. Afin d’avoir un niveau de chiffrement correcte, il est préférable de restreindre l’accès aux protocoles inférieurs à TLS1.2, de forcer l’utilisation des algorithmes de chiffrement du groupe « High » dans OpenSSL et de ne pas oublier d’annoncer STARTTLS pour établir une connexion chiffrée.
Négociation TLS1.2 :
Choix des algorithmes :
Pour vérifier que tout fonctionne correctement, rien de tel qu’une analyse de flux avec TCPDump ou Wireshark.
5. Vérifier la restriction d’émission de messages vers des adresses MSSanté
La confiance n’excluant pas le contrôle. Envoyer un message de test depuis une boîte MSS vers une boîte « classique » permet de s’assurer qu’il n’y a pas de problème de configuration sur le Proxy. Si votre message n’est pas bloqué, c’est qu’il y a un souci. Attention là encore, la règle de filtrage n’est pas native dans la solution Enovacom Secure Messaging. Pour activer la restriction :
6. Sécuriser l’authentification sur le serveur de messagerie
Vous pouvez bien évidemment opter pour une authentification à deux facteurs, vous appuyer sur une solution de SSO, mais attention de ne pas oublier que si vous vous appuyez sur votre annuaire Active Directory pour authentifier vos utilisateurs et que vous utilisez un serveur de messagerie autre qu’Exchange, tel que Zimbra par exemple, il est nécessaire d’utiliser un flux LDAP chiffré pour éviter de faire circuler les mots de passe des utilisateurs en clair sur le réseau.
Même si le terme « Zero Trust », pour lequel tout le monde n’a pas forcément la même définition, est très souvent utilisé comme argument commercial à tort ou à travers, le concept lancé par John Kindervald en 2010 repose sur quelque chose d’assez simple : ne pas attribuer plus de confiance à des réseaux et dispositifs internes qu’à ceux que l’on peut retrouver à l’extérieur du SI et de traiter tout le monde de la même façon : zéro confiance.