Les très nombreuses solutions (CASB, plateforme sécurisée, VPN, full-disk encryption, ...) offrant du chiffrement finissent par rendre illisible cet écosystème. Il faut faire attention, des différences architecturales profondes entre ces solutions existent et cela peut avoir impact sur le système d'information du client et le modèle de sécurité tout aussi profond.

Nous avions déjà expliqué nos différences avec les protocoles PGP et S/MIME, et dans cet article nous allons expliquer nos différences avec un Cloud Application Security Broker (CASB).

Le premier problème qu'un CASB adresse est d'être un rempart au shadow IT, c'est-à-dire d'empêcher les employés en entreprise d'utiliser des applications Cloud non promues par la Direction des Systèmes d'Information (DSI). Selon une étude du CESIN et de Symantec menée en 2017, les entreprises utilisent chacune en moyenne 1697 applications Cloud différentes, reflétant une fragmentation du SI et rendant donc quasi impossible la tâche de garder les informations sensibles confidentielles.

Voici à quoi ressemble le SI sans CASB:

Les promesses d'un CASB sont donc de se placer entre les applications et les utilisateurs comme un proxy, de bloquer les requêtes à des services jugés non sûrs, et de chiffrer et déchiffrer le contenu des requêtes pour que l'application Cloud n'ait pas accès à son contenu en clair.

Comment fonctionne un CASB?

De façon simplifiée, un CASB est un serveur intermédiaire chiffrant et déchiffrant à la volée les requêtes faites à une application Cloud.

Cette méthode présente des avantages et des inconvénients:

  • la protection est complètement transparente et invisible pour l'utilisateur;
  • mais pour y arriver, de complexes solutions de contournement, outrepassant des protections déja mises en places par les applications Cloud, sont implémentées, ce que nous allons détailler.

Gestion des clés

Le travail principal du CASB est donc de générer les clés de chiffrement des documents et de les utiliser à la volée pour chiffrer ce qui va vers les applications Cloud et déchiffrer ce qui en vient. Pour fonctionner, celui-ci est contraint de briser la chaîne de sécurité puisque le flux TLS entre le client et l'application Cloud est interrompu, inspecté et modifié par le CASB.

Afin de donner la maîtrise des clés au client, il existe deux possibilités:

  • soit le CASB est installé comme appliance au sein de l'entreprise (le plus fréquent), et les utilisateurs se connectent à celle-ci au lieu de se connecter aux applications Cloud.
  • soit le CASB est utilisé dans sa version Cloud. Celui-ci effectue des requêtes pour obtenir les clés à la demande, que celles-ci soient hébergées au sein de l'entreprise, ou dans des Hardware Security Modules (HSM) managés — c'est ce que les fournisseurs appellent le Bring Your Own Key (BYOK).

Il est à noter que dans ce dernier mode, même en BYOK, le document en clair transite dans sa version non chiffrée dans le Cloud.

Détection du Shadow IT

Une deuxième fonctionnalité des CASB est la détection d'utilisation du shadow IT. Pour cela, le CASB doit se placer en tant que proxy interceptant tout le trafic de l'entreprise, et plus seulement un reverse proxy pour un service donné. Cela permet de gérer une liste noire de services Cloud permettant ainsi de contraindre les utilisateurs à n'utiliser que les applications promues par l'entreprise.

Quelles sont les limitations d'un CASB ?

Infrastructure

Comme toute installation de proxy, l'installation d'un CASB implique, entre autres, des modifications des configurations des paramètres DHCP, des configurations de routeurs ainsi de questions de clustering et haute disponibilité. Dans le cas d'une installation en appliance — pour une maîtrise des clés plus complète — cela implique également de lourdes tâches d'intégration matérielle.

Afin de détecter le shadow IT, un CASB doit intercepter tout le trafic internet de l’entreprise et l'inspecter, cassant ainsi la chaîne de sécurité entre le client et l'application Cloud. Cela pose par ailleurs des problèmes règlementaires car les entreprises sont soumises à certaines obligations si elles souhaitent inspecter le traffic de leurs employés. L'ANSSI a rédigé ce guide sur l'inspection des flux TLS, et notamment l'annexe A de ce document détaille les aspects juridiques.

Modèle de sécurité

Le fait que le CASB concentre tous les accès en un point constitue par construction un Single Point Of Failure. Il ne s’agit donc pas de chiffrement de bout-en-bout: les chiffrements et déchiffrements finaux ne s’opèrent pas sur les terminaux des utilisateurs, mais sur le CASB qui les redirige ensuite à l’utilisateur. Cela fait que:

  • le CASB a accès à tous les documents en clair;
  • que les utilisateurs ont accès aux versions en clair, pouvant ensuite être échangées librement par d’autres canaux, le contrôle d’accès étant effectué avant téléchargement et déchiffrement, et non après.

De plus, cela ne fonctionne avec des gens à l’extérieur de l’entreprise que si l’entreprise expose le CASB sur Internet, augmentant ainsi la surface d’attaque.

La fonctionnalité de recherche

Les applications Cloud dont nous parlons depuis le début ne font pas que du simple stockage de documents ou de textes, il permettent aussi d'effectuer des recherches dedans et d'en tirer de la valeur. Seul le chiffrement homomorphe permet d'effectuer des opérations sur un document chiffré, et aujourd'hui aucun CASB et/ou application Cloud ne permet d'utiliser une telle technologie: elle est bien trop lourde et encore expérimentale. Les éditeurs ont donc dû faire un choix:

Les éditeurs ont donc dû faire un choix:

  • Soit ils utilisent un chiffrement dégradé dit par tokenisation, c'est-à-dire qu'un mot est toujours chiffré de la même façon, par exemple "bonjour" deviendra toujours "2cb4b14", de sorte que lorsque quand l'utilisateur recherche "bonjour" le CASB le transforme en "2cb4b14" et que l'application Cloud exécute la requête avec "2cb4b14". Cela paraît anodin, mais beaucoup de cryptanalystes vous diront que c'est tellement dangereux qu'il ne s'agit même plus de chiffrement, et n'est pas conforme avec les recommandations de l'ANSSI ou du FIPS.
  • Soit ils réimplémentent les fonctionnalités de recherche des applications Cloud dans le CASB avec un index chiffré créé et utilisé par celui-ci. Cela doit être refait pour chaque application Cloud, et l'éditeur du CASB ne sait pas comment ces fonctionnalités ont été implémentées par l'éditeur de l'application Cloud, les rendant par conception instables.

Quel que soit le choix fait, les fonctionnalités de recherche, de tri, ou n'importe quelle opération exploitant des documents pour en tirer de la valeur ne fonctionneront pas correctement, ou alors au prix d'un gros compromis de sécurité.

Seald est-il un CASB ?

Non.
Plus en détail, Seald est une application de chiffrement installée sur les terminaux des utilisateurs, opérant les chiffrements et déchiffrements finaux dessus. Un fichier chiffré peut être stocké et transmis notamment sur toutes les applications Cloud, mais aussi par clé USB ou email.

Par ailleurs, chez Seald il n’existe pas de serveur unique permettant d’accéder à toutes les clés et données. Chaque utilisateur dispose d’une clé privée unique sur chacun de ses terminaux, minimisant ainsi grandement la surface d'attaque exposée.

Conclusion

Sans trop de surprise, vous vous êtes sans doute rendu compte que notre avis sur les CASB est partial. En effet, de nombreux avantages sont présents dans Seald:

  • le chiffrement est effectué côté client, donc il n'y a pas de SPOF compromettant la confidentialité;
  • les données reste sécurisées en toutes circonstances, même lorsqu'il est sorti du périmètre de l'entreprise;
  • il n'y a pas d'infrastructure réseau lourde à mettre en oeuvre;
  • Seald a fait le choix de suivre les recommandations de l'ANSSI en termes de choix d'algorithmes de chiffrement.

Better Seald than sorry.

Fin-article_Plan-de-travail-1-2