Sécurisation du Cloud: Cloud Access Security Broker (CASB)

Depuis quelques années, le système d’information des entreprises évolue très rapidement, en passant plus ou moins rapidement d’un environnement On-Premise au Multi-Cloud.

Cette évolution majeure engendre la mise en place de nouvelles infrastructures Cloud :

• Evolutives
• Répondant aux besoins métiers (« Time to Market »)
• Avec un excellent ressenti pour l’utilisateur final

La sécurisation de ces infrastructures se réalise selon trois axes :

• Sécuriser le modèle cloud
• Sécuriser selon le mode Privé ou Public
• Evaluer le niveau de sécurité des environnements des différents CSP souscrits (identification des menaces, analyse de risque, définition des plans et actions de remédiation)

Généralement, trois types de solutions sont nécessaires :

• Cloud Workload Protection Platform (CWPP)
• Cloud Security Posture Management (CSPM)
• Cloud Access Security Broker (CASB)

Dans cet article, nous allons nous intéresser plus particulièrement à la sécurisation des applications en mode SaaS grâce au Cloud Access Security Broker (CASB).

Pourquoi un CASB ?

Comme évoqué ci-dessus, le CASB doit répondre aux nouveaux usages (application en mode SaaS, …) et aux enjeux de la sécurité (BYOD, lutte contre le Shadow IT). Il étend la politique de sécurité de l’entreprise au niveau de ses applications Cloud et il aide les entreprises à :

• Identifier les activités de Shadow IT et apporter la visibilité des services Cloud consommés ;
• Aider à la mise en conformité règlementaire (RGPD, PCI-DSS, PII, HIPAA, SOX, …) ;
• Améliorer l’offre de service aux utilisateurs et leur apporter un niveau de sécurité avéré (SaaS et Cloud Apps, BYOD, …) ;
• Sécuriser les applications Corporate et services Cloud (Office 365, G Suite, Azure, GCP, Jive, Teams, …) ;
• Sensibiliser les utilisateurs ;
• Apporter une visibilité sur la donnée et protéger les données sensibles

Ainsi, les quatre principales fonctionnalités d’un CASB sont :

• La visibilité des applications ainsi que sur leur utilisation (BYOD, lutte contre le Shadow IT)
• La sécurité des données, avec le Data Loss Prevention (DLP) qui détecte les actions sur les données sensibles dans les applications Saas ainsi que dans les flux réseaux.
• La détection des menaces, avec le blocage de l’accès aux services lorsque le CASB détecte une menace ou un comportement anormal.
• La conformité vis-à-vis de la politique de sécurité et de la règlementation.

Quels sont les modes de fonctionnement d’un CASB ?

Le CASB possède deux modes de fonctionnement :

• InLine
• API

Le mode « InLine » s’apparente à un proxy. Il traite les flux comme une passerelle de sécurité.

Le CASB apporte également une visibilité et un contrôle sur le transit des données.

Le mode API utilise un connecteur API avec la solution Cloud. Il analyse les données présentes dans le service cloud et permet d’appliquer la politique de sécurité sur les données. Il sécurise l’environnement du Bring Your Own Device (BYOD)

Quelques conseils de mise en place

Nous conseillons fortement de réaliser un Proof of Concept (POC) lors de la mise en place du CASB afin de tester chaque « Use Case » référencé.

Par ailleurs, ces « Use Cases » doivent être clairs et précis. Voici quelques exemples :

• Autoriser l’usage de Drive professionnel et interdire l’usage Drive personnel ;
• Interdire la publication des documents confidentiels sur un Drive ;
• Autoriser la consultation de documents confidentiels, mais interdire leur modification ;
• Détecter des comportements anormaux (ex : une même personne se connecte à 3 min d’intervalle de France puis de Chine, une même personne est en train de télécharger tout le contenu d’un Drive, etc.).

Il est recommandé de mettre en place les deux modes de fonctionnement du CASB.

Dans un premier temps, Il faut mettre en place le mode API avec les diverses solutions Saas le permettant.

Ensuite, il faudra installer le mode « InLine » qui s’apparente à la mise en place d’un proxy. Les ingénieurs sécurité maitrisent déjà ce type d’installation mais cela reste une mise en œuvre complexe dans tous les cas.

Cependant, il ne faut pas oublier un transfert de compétence pour les diverses équipes directement impactées.

Enfin, l’utilisation de l’agent est souhaitable apportant généralement de nombreuses fonctionnalités supplémentaires.

La méthodologie la mieux adaptée pour le déploiement d’une solution CASB est la suivante :

• Faire un état des lieux è Mettre en place la solution afin d’avoir une visibilité et des remontées d’incidents
• Privilégier le mode Ouvert è Mettre en place des règles sans blocage
• Résoudre les divers incidents remontés => Traiter les dysfonctionnements et améliorer la configuration
• Mettre en place les processus de gestion des incidents et du changement.
• Passer en production

Il faut définir des périmètres pertinents de migration (par exemple par direction) et dérouler cette méthodologie à chaque fois.

Un projet en mode Agile est une bonne approche sur ce type de déploiement.

Un retour d’expérience sur les écueils

La mise en place d’un CASB engendre son lot de difficultés, parfois au niveau technique mais surtout au niveau de la gouvernance.

Nous allons donc vous exposer quelques-unes des problématiques déjà rencontrées :

• Le déploiement de l’agent et de la méthode d’authentification sont des points à bien étudier en amont autant du point de vue processus que compatibilité avec son système d’information;
• Il faut connaitre son degré de maturité surtout au niveau cartographie et gestion de la donnée. Aujourd’hui, peu de sociétés ont réellement cette visibilité. Si ce chantier n’est pas encore engagé, il est urgent de le commencer afin de bénéficier de l’analyse du CASB sur la donnée sensible. Le CASB permettra également d’accompagner cette mise en place lors de la phase de conception.
• Les flux « internet »  sont généralement chiffrés (voir recommandation de sécurité concernant des flux HTTPS de l’ANSSI https://www.ssi.gouv.fr/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https/, https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_TLS_NoteTech.pdf). Le déchiffrement SSL devient alors nécessaire pour maîtriser ces flux. Cependant certains flux ont obligation par la loi de rester chiffrés (ex : URSSAF, Impôt etc). Un travail afin d’identifier ces derniers devient nécessaire avec des juristes. De plus, il faudra aussi informer les salariés et les corporations syndicales. Cet exercice reste nécessaire et peut s’avérer complexe.
• La définition et la mesure de KPI : Il existe peu de retour d’expérience sur les KPI de solution cloud. La plupart des acteurs font confiance aux KPI fournis par les éditeurs de solution. Quels sont les indicateurs pertinents permettant de mesurer la « performance » de la solution ? disponibilité de la solution, « Mean Time To Restore », « Mean Time To Acknowledge », temps de traitement des flux, etc ? Comment réussir à mettre en place sa métrologie afin de disposer de ses propres indicateurs de performance et de pouvoir les corréler avec l’information fournie par les éditeurs ?

Conclusion

Il faut comprendre que le CASB répond parfaitement à la sécurisation des périmètres SaaS et devient un outil incontournable dans les infrastructures actuelles.

Le CASB est une des briques sécuritaires permettant la mise en place des nouveaux concepts et usages utilisateurs répondant ainsi au paradigme du « any time », « any where », « any device ».

Il faut reconnaitre que les éditeurs de solutions ont une approche R&D importante s’alimentant grâce aux demandes et retours des clients. Il faut donc être conscient que, lors du choix d’un éditeur, vous établirez un véritable partenariat.

Nous remarquons également de plus en plus l’intégration des périmètres CWPP et CSPM dans les environnements CASB afin de bâtir une solution couvrant l’ensemble de la problématique liée à la sécurisation du Cloud.

Mais cela est une autre histoire ! A suivre…