Le challenge de la protection des données dans le cloud

L’adoption des services hébergés est de plus en plus large. Y compris dans des secteurs d’activité historiquement hermétiques à cette approche pour des raisons de sécurité : les données hors du périmètre du S.I. peuvent potentiellement être divulguées.

Dans le cas d’Azure, Microsoft a mis en place il y a déjà quelques années des solutions pour le chiffrement de données basées sur :

• Des clés générées par Microsoft dans Azure Key Vault
• Des clés générées par le propriétaire du “tenant” et stockées dans Azure Key Vault (Bring Your Own Key)
• Des clés générées par le propriétaire du “tenant” et détenues par ce dernier (Hold Your Own Key)

Dans certains cas de figure, les deux premières approches sont trop limitées dans la mesure où la clé ne demeure pas vraiment sous contrôle exclusive de son propriétaire.
Le dernier cas répond à la problématique en contrôlant l’emplacement de la clé. Mais la configuration est souvent complexe, et n’est pas supporté dans la majorité des cas d’utilisation dans Azure.

Double Key Encryption: la solution pour la protection des données critiques dans le cloud.

Microsoft met désormais à disposition une “interface” permettant de repondre précisément à ce besoin: le “Double Key Encryption”. Le principe est relativement simple, utiliser une clé sous contrôle total de l’entreprise propriétaire des données pour le chiffrement des données. Il devient alors impossible pour le fournisseur cloud d’avoir accès au contenu des documents.

Entrust, partenaire de longue date d’e-Xpert Solutions pour ses solutions HSM nShield, a développé un logiciel implémentant DKE. Ce logiciel permet de mettre en place un service DKE, qui, couplé au HSM nShield, garantit un niveau de sécurité très élevé pour les documents chiffrés avec le système.

Le schéma ci-dessous présente les étapes du processus de chiffrement des documents avec le service DKE :

Processus de chiffrement d’un document avec DKE (Source : Entrust)

L’activation de ce processus pour un document est très simple, et consiste à associer un “Label” identifiant un document comme hautement confidentiel. La définition des “Labels” doit être liée à la politique de classification des données de l’entreprise.
Dans la configuration Azure, le paramétrage de ce label est lié à l’URL du service DKE Entrust sous control du propriétaire de l’information:

Configuration d’un label déclenchant DKE.

Il suffit donc à l’auteur d’un document d’ajouter le label défini ci-dessus lors de la création du fichier pour qu’il soit chiffré en utilisant DKE.

Quelles utilisations pour DKE ?

Le service n’a pas réellement vocation à être utilisé pour tous les documents produits par une entreprise, mais plutôt de protéger les biens d’entreprise les plus précieux, ou d’assurer la conformité vis à vis de certaines législation ou règlementations sectorielles.

• Emplacement géographique imposé pour la clé de chiffrement
• Contrôle exclusif de la clé par le propriétaire des données
• Auditabilité de l’utilisation de la clé de chiffrement
• Stockage de la clé privée sur un HSM

Il est fortement recommandé de mettre en place ou adapter la politique de classification des données de l’entreprise afin de cerner avec précision quels types de documents justifient l’utilisation de DKE dans l’organisation.

Limitations engendrées par DKE

La clé de déchiffrement n’étant plus accessibles par Azure, certaines fonctionnalités ne sont plus disponibles sur les documents protégés par DKE :

• Règle de transport nécessitant une visibila
• Microsoft Delve
• eDiscovery
• Recherche et indexation
• Office Web Apps y compris les fonction de “collaboration”

C’est également une raison pour laquelle l’utilisation de DKE doit cibler les documents les plus sensibles seulement.