CASBs Episode 2 : Shadow Data - protection et contrôle des données «at rest»

Dans mes précédents articles consacrés aux CASBs (ou Cloud Access Security Brokers ) je faisais la distinction entre Shadow IT et Shadow Data et j’expliquais comment mettre en œuvre la découverte du Shadow IT. Au-delà de cette phase de découverte, les CASBs sont conçus pour protéger les données dans le cloud au moyen de différentes techniques selon la nature des données. Explications.

Dans cet article intéressons-nous à la protection des data «at rest»: quelles sont les données «at rest» pouvant être traitées par un CASB, quelle est la technique de protection mise en œuvre et enfin quels sont les points de vigilance à garder à l’esprit à propos de ce mécanisme de sécurité ? Réponses en 3 points.

Quelles données traiter ?

Les données «at rest» (par opposition à celles «on fly») sont les données que les utilisateurs de l’entreprise ont déjà déposées ou enregistrées dans un service cloud. La protection et le contrôle seront donc appliqués a posteriori et non à la volée. Donc, en termes d’architecture, il n’est pas nécessaire que la donnée à traiter traverse le CASB. Il n’y aura donc pas de latence induite par le CASB. Intéressant non ?

Par définition, si les données traitées appartiennent à l’entreprise, cette méthode de protection et de contrôle des données va porter uniquement sur des « Sanctioned Apps » : des applications souscrites par l’entreprise. Les plus évidentes étant MS 365 et Google Docs mais pas uniquement. J’exclue donc du champ de la protection toutes les données personnelles qui pourraient être générées avec des comptes personnels par exemple sur Google doc.

Cette protection et ce contrôle par l’entreprise ne peuvent porter que sur les données lui appartenant pour d’évidentes questions de respect de la vie privée des utilisateurs.

L’identification des données appartenant à l’entreprise de celle d’un compte personnel est simple puisque chaque compte utilisateur est identifié sur la base de son adresse mail contenant le nom de domaine associé à l’entreprise.

Comment traiter les données «at rest»

Tous les éditeurs de CASB utilisent la même technique pour traiter les données enregistrées dans les applications cloud: le développement de connecteurs pour les APIs des éditeurs afin d’appliquer les traitements de sécurité sur les données enregistrées.

Au travers de ces APIs, le CASB peut obtenir des informations diverses et les comparer avec les règles de sécurité implémentées par les administrateurs.

Les données remontées (et donc susceptibles d’être contrôlées) par les APIs peuvent porter sur :

• les noms et types de fichiers enregistrés
• les autorisations et droits de partage des fichiers
• activités sur les fichiers (logins / logouts / modifications)
• ajout, téléchargement ou suppression de fichiers
• transactions et informations administratives etc

La mise en place de ce contrôle via API est relativement aisée : il suffit de paramétrer les CASB pour lui indiquer quelle API et quel compte d’entreprise utiliser pour contrôler une application cloud. De plus comme ce dialogue entre le CASB et le fournisseur cloud se fait en arrière-plan le déploiement d’une telle solution est totalement transparent pour les utilisateurs. Il est cependant indispensable de les informer de sa mise en place.

Les points de vigilance sur le contrôle des données «at rest"

Comme tout repose sur les APIs développées par les fournisseurs de l’application cloud il faut garder en tête trois choses :

• le traitement ne sera jamais en temps réel.
• vous ne pourrez contrôler que ce qui a été autorisé par l’API du fournisseur !
• si l’API éditeur évolue le CASB doit suivre les évolutions !

Comme le traitement de sécurité s’applique une fois la donnée enregistrée, la réactivité du CASB sera au mieux de quelques secondes après la violation d’une règle de sécurité. Lors de tests j’ai pu constater des écarts de plusieurs minutes entre l’enregistrement d’un document contrevenant aux règles de sécurité et la réaction du CASB. Potentiellement la latence pourrait même être de plusieurs heures : certains fournisseurs ne proposent pas mieux en termes de «SLAs» pour leurs APIs.

A quoi peut-on imputer cette variabilité du temps de réaction? Je manque clairement de recul à ce jour mais je me permets deux hypothèses :

• l’architecture: selon que votre CASB est en Europe et le fournisseur cloud aux USA il peut y avoir un impact sur le dialogue entre les deux solutions,
• les pics de charge de la solution cloud ou au niveau des CASBs. Là encore il n’y a pas à ce jour d’étude fiable permettant d’en savoir d’avantage.

Concernant la nature des contrôles il est clair que c’est l’API du fournisseur qui définit ce qu’un CASB peut faire sur les données ou pas. N’espérez pas du CASB qu’il réalise un contrôle ou interdise une action si cela n’a pas été prévu par l’éditeur. La richesse de l’API va donc déterminer la richesse des actions que la CASB pourra mener.

Enfin, lorsque l’éditeur de la solution cloud fera évoluer son API, ce qui est fréquent, le fournisseur du CASB devra faire évoluer son connecteur d’API en même temps. D’où l’importance :

• pour les éditeurs de CASB de travailler en étroite collaboration avec les éditeurs des solutions cloud pour éviter tout écart entre les deux solutions,
• pour l’acheteur d’être vigilant sur la qualité de la relation CASB / éditeur de cloud

N’hésitez pas à tester ces technologies si vous avez choisi d’implémenter des solutions cloud au sein de votre entreprise. Malgré les points de vigilance et malgré leur jeunesse, les CASBs offrent, au travers de leurs connecteurs d’API, un réel plus en terme de sécurité et de contrôle des données « at rest » dans le cloud.

Philippe

Pour aller plus loin

Cloud Access Security Brokers (CASB) : le nouvel eldorado de la sécurité ?
Pour tout savoir sur les tendances 2016 de la cyberdéfense en 120 secondes
Orange Cyberdefense protège vos essentiels
Exploitez tout le potentiel du Big Data et de l’Internet des objets