CASBs épisode 3 : protection et contrôle des données «on fly»

Dans les épisodes précédents consacrés aux CASBs j’avais traité des aspects découvertes du Shadow IT et de la protection et du contrôle des données « at rest », c’est-à-dire des données déjà déposées ou enregistrées dans le cloud au moyen des « Sanctioned apps ».

Dans cet article, je traiterai de la protection et du contrôle à la volée des données, ou encore « data on fly ». Comme pour l’épisode précédent, je répondrai en 3 points : quelles sont les données «on fly» qui peuvent ê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é.

Quelles données traiter

Les données «on fly» (par opposition à celles «at rest») sont les données que les utilisateurs de l’entreprise cherchent à déposer dans un service cloud. Comme les données ne sont pas encore enregistrées, la protection et le contrôle seront donc appliqués à la volée et non a posteriori.

En termes d’architecture, il est donc nécessaire que le CASB soit placé sur le chemin de la donnée à traiter, c’est-à-dire en coupure entre l’utilisateur et les applications cloud à protéger ou contrôler.

Contrairement au contrôle des données déjà enregistrées qui se fait a posteriori, le contrôle à la volée s’effectue en temps réel et peut s’appliquer, en théorie du moins, à tout type de donnée : qu’elle concerne une « Sanctioned app » ou une « Unsanctioned app ».

Deux difficultés doivent alors être traitées :

• identifier s’il s’agit d’une application, autorisée ou non ;
• dans le cadre d’une application autorisée ; identifier s’il s’agit d’une utilisation à titre personnel ou professionnel !

En effet, la protection et le 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.

Comment traiter les données «on fly»

Contrairement à l’épisode précédent, les éditeurs de CASB n’utilisent pas tous la même architecture technique pour traiter les données « on fly » vers les applications cloud: certains privilégient le mode proxy d’autre le mode reverse proxy.

Chaque architecture a ses avantages et inconvénients, tout dépend en fait de quel point de vue l’on se place. S’il s’agit de contrôler finement l’activité d’une « Sanctioned app » le mode reverse proxy peut être le plus adapté. En revanche si vous souhaitez contrôler globalement un ensemble d’applications le mode proxy peut se révéler plus avantageux.

• Déploiement en mode Reverse Proxy :

L’usage d’un CASB en mode Reverse Proxy se définit le plus souvent au niveau de l’application.

Ce mode de déploiement est particulièrement adapté pour le contrôle d’une application professionnelle que l’on souhaite contrôler dans tous les cas. Que les utilisateurs viennent d’un navigateur web ou d’une application nomade, d’un PC ou d’une tablette.

La redirection vers le CASB peut se faire soit :

• par modification du chemin vers l’application (URL) ;
• en utilisant un « Identity Provider » (IdP) permettant le SSO. Si on utilise le SAML, deux modes d’intégration sont possibles : IdP Initiated et SP Inititated. Dans le premier mode, l’utilisateur adresse la requête à l’IdP qui fournit une assertion SAML et redirige vers le Reverse Proxy. Dans le second mode, l’utilisateur se connecte au Service Provider (SP) - l’application Cloud - en utilisant l’URL du Reverse Proxy. Le SP redirige vers l’IdP qui authentifie l’utilisateur via une assertion SAML.

L’utilisation d’un « Identity Provider » est intéressante en termes de sécurité pour la gestion des droits des utilisateurs qui se fait alors au niveau de l’entreprise et non plus dans l’application Cloud. 

Ce mode de déploiement est donc particulièrement intéressant en termes de contrôle puisque tous les flux concernant l’application cloud professionnelle vont traverser le CASB paramétré en Reverse Proxy.

• Déploiement en mode Proxy :

Dans le déploiement en mode proxy c’est la configuration du réseau qui, en redirigeant les flux vers l’applicatif va forcer l’utilisation du CASB. Cette architecture assure que tous les flux venant du réseau de l’entreprise à destination de l’application web à protéger seront traités par le CASB.

Pour cela, le CASB peut être déclaré en « proxy chaining » d’un proxy existant. Ce mode de déploiement a l’avantage d’être transparent pour l’utilisateur, car l’accès à l’application n’est pas modifié.

Le mode « proxy chaining » permet également de choisir quels flux envoyer vers le CASB et quels flux envoyer directement vers Internet ou, a contrario, il permet de faire contrôler l’usage de toutes les applications Web par le CASB.

Les points de vigilance sur le contrôle des données «on fly »

De façon générale, placé en coupure des flux applicatifs, le CASB peut ajouter de la latence et devenir un SPOF (Single Point of Failure) dans l’architecture. Ajoutons à cela quelques spécificités propres à chaque type de déploiement.

• Déploiement en mode Reverse Proxy :

Les inconvénients d’un déploiement en mode Reverse Proxy sont directement liés à cette architecture :

• le déploiement est plus complexe et rarement transparent pour les utilisateurs lorsque l’on a un chemin spécifique pour l’application. Pour contourner cette difficulté, l’utilisation d’une plate-forme de fédération de service permettant un point d’entrée unique est intéressante.
• la gestion des certificats entre le Reverse Proxy, l’application Cloud et éventuellement la fédération de service et « l’Identity Provider » est souvent complexe
• cette architecture peut être problématique pour certaines applis mobiles qui utilisent des URLs codées en dur ou qui ne permettent pas de gérer les certificats permettant d’accéder à l’application.
• Déploiement en mode Proxy :

Les principaux points de vigilance avec un CASB déployé en mode proxy sont les suivants :

• le BYOD échappe souvent au contrôle car les flux issus de ces appareils personnels échappent le plus souvent au proxy de l’entreprise
• la séparation entre données personnelles et données professionnelles est délicate dans le cas d’une application qui peut être utilisée dans les deux situations
• certaines architectures ne supportent pas le « proxy chaining ».

Vous l’avez compris cette sécurisation et ce contrôle des données « on fly » est plus délicat à mettre en œuvre que celui des données « at rest ». Les architectures proxy ou reverse proxy doivent donc être étudiées avec soin, et les arguments « pour » et ceux « contre » soigneusement pesés.

Cependant, en raison de son aspect protection en temps réel, il est très complémentaire du contrôle des données au moyen des connecteurs d’APIs qui lui se fait a posteriori. A terme ces fonctions de contrôle devraient être intégrées dans nombre de proxy (appliance ou cloud), ou Next Gen firewall. Le rachat d’Elastica par Bluecoat ou plus récemment de CloudLock par Cisco en sont des exemples forts.

Philippe

avec la participation active de Chistophe Gouleau

Pour aller plus loin :

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

Cloud Access Security Brokers (CASB) – Episode 1 : à la découverte du Shadow IT