La CNIL encadre le déchiffrement des flux HTTPS

Le 31 mars 2015, la CNIL livrait son analyse concernant le flux https et notamment les bonnes pratiques à mettre en place concernant le déchiffrement de ces flux pour sécuriser un système d’information.

Le protocole de transfert HTTPS est un protocole de transfert de données sécurisé par application d’un certificat d’authentification. Simple à mettre en œuvre et efficace, il est de plus en plus utilisé notamment en matière de commerce électronique, services bancaires en ligne ou encore sur les réseaux sociaux. La CNIL recommande d’ailleurs son utilisation relevant que ce protocole permet de réduire les risques liés à l’interception des communications.

Pourtant, mettre en place cette mesure peut également générer un risque pour l’entreprise et son système d’information. En effet, les données ne sont pas contrôlées ni lors de leur entrée, ni lors de leur sortie dans le système. En conséquence, des salariés peuvent intentionnellement ou non faire entrer des données malveillantes ou encore faire sortir des données confidentielles du système d’information.

Pour écarter ce risque, les responsables des systèmes d’information ont la possibilité de :

–   déchiffrer le flux de données HTTPS avant l’entrée ou la sortie dans le système d’information ;

–   analyser le contenu ;

–   re-chiffrer ce flux avant de le renvoyer vers sa destination.

L’ANSSI a précisé les bonnes pratiques « techniques » à mettre en place pour réaliser ce déchiffrement dans un guide[1].

La CNIL précise les bonnes pratiques à mettre en place afin de respecter la loi Informatique et Libertés et d’assurer la sécurité du système d’information de l’entreprise, celle-ci doit cependant être encadrée :

–   Les salariés doivent être informés de façon précise quant à ce déchiffrement ;

–   Les droits d’accès des administrateurs quant aux courriers électroniques doivent être gérés de façon stricte ;

–   Il est également nécessaire de limiter la conservation des traces en conservant strictement les informations nécessaires et pertinentes  (ex : garder une trace des fichiers malveillants, de leur source ou de leur destination mais pas les identifiants et mots de passe) ;

–   Les  données d’alertes extraites de  l’analyse doivent enfin être protégées, par exemple en étant conservées dans un environnement à part.