Sergey Nivens - Fotolia

Comme promis, Slack laisse les entreprises gérer leurs clés de chiffrement

La plateforme collaborative permet désormais à ses clients de disposer d’un contrôle accru sur le chiffrement de leurs données. Mais pour l’heure, il faut impérativement passer par le service AWS KMS.

Slack l’avait annoncé en septembre dernier et de premiers clients pouvaient en profiter depuis l’automne, mais désormais, tous peuvent gérer eux-mêmes leurs clés de chiffrement et, ainsi, mieux contrôler la confidentialité de leurs échanges sur la plateforme collaborative.

Slack assurait déjà un chiffrement des messages et des fichiers échangés sur sa plateforme. Mais là, il s’agit d’offrir « toute la sécurité d’une solution en local, avec les avantages d’un outil en mode cloud ». La gestion des clés s’appuie sur le service ad hoc d’Amazon Web Services (AWS), le Key Management Service (KMS), comme c’est le cas pour Box depuis le début 2016.

Lancé en mars 2013, le service KMS permet de disposer d’une appliance dédiée au stockage des clés de chiffrement, et distincte des instances de stockage des données chiffrées. Ce n’est pas autre chose qu’une version logicielle, virtualisée, d’un module de sécurité matériel initialement signé SafeNet (HSM, ou Hardware Security Module) – avant son rachat par Gemalto, passé depuis sous la bannière de Thales –, qui assure notamment l’authentification des certificats et le stockage des clés.

Dans le domaine du collaboratif, Slack n’est pas isolé. Cisco, avec WebEx Teams, permet également aux entreprises de gérer leurs clés. Et cela vaut également pour Symphony, une application populaire dans les secteurs fortement réglementés.

Dans un échange avec la rédaction, Slack explique sa décision par le fait que le contrôle des clés de chiffrement « serait utile à [ses] clients Enterprise Grid, en particulier ceux de secteurs réglementés ». Pour l’heure, seul AWS KMS est supporté, mais Slack « prévoit d’envisager d’autres solutions KMS et HSM » s’il en voit émerger la demande. Symphony est déjà ouvert à cela.

Tous les éléments qui peuvent faire l’objet d’une recherche – fichiers et messages – sont concernés. Mais pas les échanges audio et vidéo : « ils ne sont pas sauvegardés et ne peuvent pas faire l’objet d’une recherche ; nous ne les chiffrons pas », explique Slack.

La plateforme précise au passage que « l’index de recherche est chiffré au repos avec les clés du client. Nous avons ajouté pour cela des attributs à chaque message et fichier pour rendre cela possible. Ces attributs sont l’espace de travail, le canal, l’identifiant de l’organisation, et l’heure d’envoi du message. Un administrateur IT peut désormais révoquer les clés d’un message ou d’un fichier sur la base de n’importe lequel de ces paramètres ».

Mais quid des applications personnalisées et, notamment, des bots développés et utilisés en interne ? Là, Slack renvoie tout d’abord au chiffrement des échanges en transit. Une fois que la plateforme reçoit un message du bot, elle « demande au KMS le prêt d'une clé pour chiffrer ou déchiffrer cette information au besoin. Cela fonctionne de la même manière » dans l’autre sens, depuis la plateforme vers l’application.

Pour approfondir sur Sécurité du Cloud, SASE

Close