Qu'est-ce que le CASB ?
CASB (Cloud Access Security Broker) est une couche de sécurité entre les utilisateurs et les services cloud, qui rend visibles l'usage, la configuration et le flux de données des applications SaaS. Plutôt que d'autoriser ou de bloquer les services cloud en bloc, CASB permet des règles ciblées, par exemple quel groupe d'utilisateurs peut utiliser quels services et dans quelle mesure, ou quelles données peuvent y circuler. Cela s'accompagne souvent de contrôles de configuration directement dans l'application cloud, par exemple pour vérifier si des partages sont réglés de façon trop ouverte. L'usage du cloud reste ainsi productif, sans perdre le contrôle sur les données sensibles.
CASB en détail
Les fonctions CASB se répartissent globalement en deux approches : le CASB inline contrôle le trafic de données en temps réel, pendant qu'il circule entre l'utilisateur et le service cloud, selon une logique proche de celle de ZIA pour le trafic web général. Le CASB API, lui, se connecte directement à l'interface du service cloud et y vérifie par exemple les paramètres de partage ou les configurations, indépendamment de l'accès en cours. Les deux approches se complètent en pratique.
La discovery est un élément important : l'analyse des journaux d'accès permet d'identifier quels services cloud sont réellement utilisés dans l'entreprise, y compris ceux qui n'ont jamais été introduits officiellement. Cela fournit des indices précieux sur le Shadow IT, sans garantir une exhaustivité totale.
Pourquoi le CASB compte-t-il dans l'exploitation Zscaler ?
Les services cloud sont aujourd'hui la norme, pas l'exception, et beaucoup traitent des données d'entreprise sensibles. Sans visibilité CASB, l'IT ne sait souvent pas quels services sont réellement utilisés ni comment les données y sont configurées et partagées. Cela complique à la fois l'évaluation des risques et la preuve à apporter aux clients ou aux auditeurs.
Pour NIS2 et DORA, la sécurisation de la chaîne d'approvisionnement et des services utilisés compte de plus en plus. La visibilité CASB fournit à cet égard une base de données importante, sans toutefois remplacer un audit fournisseur complet.
Sources d'erreur courantes
- Les fonctions CASB sont sous licence, mais pas configurées pour les services cloud réellement utilisés.
- Les résultats de la discovery ne sont pas analysés régulièrement et deviennent ainsi vite obsolètes.
- Le manque de coordination entre les règles CASB et les règles DLP crée des lacunes sur les données sensibles.
- Des règles trop restrictives, définies sans analyse préalable, bloquent des services utilisés en production.
CASB en pratique : ce qu'apporte CentaurNexus
CASB Guard de CentaurNexus pose une couche de gouvernance sur les règles ZIA-CASB existantes : il affiche les règles actives du tenant et permet d'en activer ou désactiver certaines individuellement, avec aperçu en dry-run et validation à quatre yeux, plutôt que des modifications groupées sur un règlement en production. En complément, Policy Health Saga vérifie dans le contrôle de santé de licence si les fonctions CASB de la licence Zscaler sont effectivement configurées et actives, pour que les protections payées ne restent pas inutilisées. Pour en savoir plus sur l'exploitation systématique de la licence, consultez le guide Tirer davantage de votre licence Zscaler.
CASB en exploitation : comment le reconnaître
Les cas CASB arrivent rarement sous la forme « le CASB bloque ». Ils arrivent sous la forme « pourquoi ça marche ici et pas là », et la réponse tient presque toujours à l'une de trois distinctions.
« Dans Teams, j'ai pu partager le fichier, dans un autre service non. »
Ce que c'est le plus souvent : Ce n'est pas le fichier qui fait la différence, mais l'application et son classement. Deux services de la même catégorie peuvent être traités différemment si l'un est répertorié comme approuvé pour un usage professionnel et pas l'autre.
Comment le distinguer : La question à poser est : comment le service cible est-il classé, et quelle règle s'applique à cette catégorie ? Pas : qu'y avait-il dans le fichier ?
« Hier, le service était autorisé, aujourd'hui non. »
Ce que c'est le plus souvent : Souvent la distinction entre l'instance professionnelle et l'instance privée d'un même service. Même fournisseur, instance tenant différente, évaluation différente.
Comment le distinguer : Vérifiez si la règle cible l'application ou une instance précise. Cela explique l'apparente incohérence sans qu'aucune règle n'ait changé.
« L'utilisateur ne voit pas de page de blocage, il ne se passe simplement rien. »
Ce que c'est le plus souvent : Un indice sur le mode d'action. Si le trafic est contrôlé dans le flux de données, l'utilisateur voit une page de blocage. S'il est contrôlé a posteriori via l'interface du fournisseur, il ne remarque la mesure que plus tard, voire jamais.
Comment le distinguer : L'attente d'un retour immédiat de la part de l'utilisateur dépend du mode d'action. Cela doit figurer dans la réponse, sinon le résultat paraît arbitraire.
« Nous ne savions même pas que ce service était utilisé. »
Ce que c'est le plus souvent : Ce n'est pas une erreur du CASB, c'est justement son intérêt. Des services non approuvés apparaissent parce que quelqu'un voulait faire son travail.
Comment le distinguer : Shadow IT Findings détecte l'usage d'applications cloud non approuvées et évalue le risque. La découverte débouche sur un processus d'autorisation structuré plutôt que sur un blocage sans dialogue.
Qui connaît ces trois distinctions répond à la plupart des tickets CASB sans escalade : application ou catégorie, instance professionnelle ou privée, dans le flux de données ou a posteriori.
Termes associés
Questions fréquentes sur CASB
CASB signifie Cloud Access Security Broker, une couche de sécurité entre les utilisateurs et les services cloud. Elle rend visible quelles applications SaaS sont utilisées, comment elles sont configurées et quelles données y circulent, et permet sur cette base des règles ciblées plutôt qu'une autorisation ou un blocage général.
Le CASB inline contrôle le trafic de données en temps réel, pendant qu'il circule entre l'utilisateur et le service cloud, un peu comme ZIA le fait pour le trafic web général. Le CASB API se connecte directement à l'interface de programmation du service cloud et y vérifie par exemple les partages ou les configurations, indépendamment du trafic en cours. Beaucoup de solutions combinent les deux approches.
La discovery CASB analyse les journaux d'accès et peut ainsi rendre visible une grande partie des services cloud utilisés, en particulier ceux accédés via le web sur l'infrastructure surveillée. Une exhaustivité à cent pour cent n'est toutefois, en réalité, pas garantie.
Les règles DLP, c'est-à-dire les politiques de Data Loss Prevention, peuvent être appliquées de façon ciblée aux services cloud via CASB, par exemple pour empêcher que des fichiers sensibles soient téléversés vers un espace de stockage cloud non autorisé. CASB fournit pour cela la visibilité et le point de contrôle, DLP la règle de vérification du contenu.
Zscaler propose la fonctionnalité CASB comme partie intégrante de sa plateforme et désigne cette combinaison comme un CASB multimode : inline via Cloud App Control au sein de ZIA pour le trafic de données en cours, et out-of-band via la SaaS Security API pour les données au repos dans les applications SaaS déjà connectées. Le périmètre exact de licence est à vérifier dans le contrat Zscaler propre à l'entreprise.
- Portail d'aide Zscaler : SaaS Security Deployment and Operations Guide - help.zscaler.com/zscaler-deployments-operations/saas-security-api-deployment-and-operations-guide
Remarque : CentaurNexus est un produit indépendant de SourcingBlox GmbH et non une offre de Zscaler, Inc. Les noms de produits et de marques appartiennent à leurs détenteurs respectifs.