Quels outils pour contrôler les logiciels SaaS de vos équipes ?

Les outils SaaS sont difficiles à administrer de manière rigoureuse, ce qui peut générer des fuites de données sensibles et/ou personnelles. Une SaaS management plateforme (SMP) comme Sublim.io permet de sécuriser la gestion des logiciels SaaS. A côté des SMP, il existe de nombreux « faux amis ». Comment s’y retrouver ?

1. Une rigueur difficile

Devant la multiplication des outils SaaS, les entreprises rencontrent les plus grandes difficultés à s’y retrouver, rendant l’administration des logiciels SaaS aussi hasardeuse que dangereuse. Pourtant, sécurité et confidentialité des données sensibles et/ou personnelles sont en jeu.  

D’abord, chaque outil SaaS dispose de sa propre console d’administration. Cela oblige les personnes en charge de leur administration à multiplier les allers-retours entre chaque plateforme. Ouvrir (onboarder) ou fermer (offboarder) des comptes utilisateurs et définir les droits d’accès pour chacun devient un cauchemar. Le traitement manuel, la norme aujourd’hui, est fastidieux et chronophage. Il provoque surtout des erreurs multiples et variées.  

En outre, ces consoles d’administration ne satisfont pas aux besoins des entreprises. Pourquoi ? Car les éditeurs se concentrent généralement sur les fonctionnalités « métiers » de leurs outils SaaS (la promesse de valeur visible pour les utilisateurs) plutôt que sur la partie immergée de l’iceberg (les fonctionnalités d’administration).

Enfin, une homogénéisation des consoles d’administration d’un logiciel SaaS à l’autre impliquerait une concertation des éditeurs entre eux et la définition d’un standard commun. Ce qui relève évidemment de l’utopie la plus totale.   

2. Les SaaS management platforms (SMP)

Pour résoudre ces difficultés, les éditeurs de suites logicielles cloud comme G Suite (Google), Office 365 (Microsoft) ou AWS (Amazon) imaginèrent des portails avec, pour chacun, une console d’administration agrégeant les outils SaaS de la suite. Il s’agit des premières SaaS management platforms (SMP). Développées par chaque éditeur exclusivement pour sa suite logicielle, nous parlerons ici de « SMP natives ».

Problèmes des SMP natives :

  1. Elles n’agrègent que les outils SaaS d’une suite logicielle donnée,
  2. Elles sont complexes à prendre en main,
  3. Leur complexité provoque des erreurs et de l’insécurité,
  4. Leurs fonctionnalités standards et leurs réglages par défaut sont rarement adaptés aux règles de conformité/compliance propres à chaque entreprise,
  5. Elles ne proposent pas de workflows automatisés (en tout cas pas avec le niveau de granularité souhaité par l’entreprise).

D’où l’intérêt de SMP tiers plus larges et agnostiques, qui agrègent évidemment les suites logiciels G Suite, Office 365 et AWS, mais pas seulement. Des SMP qui intégrent également des outils SaaS extérieurs à ces écosystèmes. Autrement dit, des « méta SMP ».

3. Fonctionnalités des SMP

Les SMP offrent cinq grandes familles de fonctionnalités :

  • l’ouverture des accès et des comptes,
  • la gestion des rôles (rôle de simple user ou rôle d’administrateur),
  • la gestion des privilèges d’accès selon les profils (exemple : « manager », « utilisateur », « stagiaire », « prestataire externe »),
  • la fermeture des accès et des comptes,
  • Les alertes sécurité.

A la différence des SMP natifs de G Suite, Office 365 ou AWS, les « méta SMP » offrent d’avantages de fonctionnalités tout en proposant une simplicité et une expérience client optimisée (UX design). Avec le temps, ces « méta SMP » ont évidemment vocation à intégrer toujours plus d’outils SaaS indépendants (i.e. extérieurs aux univers Google, Microsoft ou Amazon). C’est ce que propose déjà un SMP comme Sublim.io.

Les « méta SMP » les plus perfectionnés comme Sublim proposent en outre des alertes sécurités et des workflows automatisés.

Exemple de workflows pour l’onboarding des nouveaux collaborateurs : pré-paramétrage de profils utilisateurs par poste, équipe, géographie, … ; pré-paramétrage de stacks métiers (équipe marketing, équipe sales, …).

Exemple de workflows pour l’offboarding : fermer les comptes d’un collaborateur à une date et à une heure préenregistrée.

Exemple de workflows suite à des alertes sécurité : lancement d’actions automatisées, comme réinitialiser les mots de passe dès qu’un comportement dangereux est détecté.

4. Les « faux amis »

Outre les SMP natifs, il existe des « faux amis » :

  • Les outils de gestion d’actifs logiciels (Software Asset Manager – SAM),
  • Les courtiers de sécurité d’accès au cloud (Cloud Access Security Broker – CASB),
  • Les outils d’identification unique (Single Sign On – SSO).  

Les Software Asset Managers – SAM

Les SAM visent à assurer le suivi des licences SaaS et l’optimisation des coûts liés au parc d’outils SaaS déployé dans l’entreprise. Rien à voir donc avec le pilotage et la sécurisation automatisée des accès.

Quelques exemples de SAM : Zylo, Flexera, Cloudability, Productiv, Applogie, Aspera.

Les Cloud Access Security Brokers – CASB

Les CASB, eux, se concentrent sur la détection des outils SaaS qui sont utilisés dans l’entreprise malgré leur interdiction et/ou leur non déclaration à la DSI (le shadow IT). A la différence des SMP, les CASB sont nécessairement déployés au niveau de la DSI centrale qui doit les intégrer en profondeur dans les systèmes d’information de l’entreprise. Rien à voir avec une approche décentralisée et légère. Les CASB sont très lourds et couteux à mettre en place. Surtout, ils ne traitent pas du contrôle et du pilotage au quotidien des outils SaaS par les équipes métiers.

Quelques exemples de CASB : Oracle, Cisco (Cloudlock), McAfee (Skyhigh), Symantec (Elastica), Forcepoint (Skyfence).

Les Single Sign On – SSO

Les SSO, enfin, permettent à chaque utilisateur d’accéder à de multiples services, sites web et applications SaaS, via un système d’authentification unique. L’objectif du SSO est ici de faciliter l’accès aux outils SaaS : aucun identifiant à mémoriser ou à saisir (login, mot de passe). En matière de sécurité, le SSO évite deux pratiques dangereuses : (i) lister tous ses identifiants sur un fichier Excel ou Word facile à pirater … , et/ou (ii) choisir un même identifiant pour tous ses outils SaaS.

De manière incidente, les SSO permettent également à un administrateur unique de contrôler et gérer les accès utilisateurs. Mais ces fonctionnalités sont bien moins poussées que celles d’un SMP dont c’est le « cœur de métier ». En matière de sécurité et d’administration des accès, les SSO ne sont donc clairement pas des solutions adaptées :

  • Les SSO sont très loins d’être compatibles avec tous les outils SaaS,
  • L’installation d’un SSO implique une mise en conformité du système d’information de l’entreprise utilisatrice, ce qui est lourd,
  • La mise en place d’un SSO implique également que la DSI ait connaissance de tous les outils SaaS à y intégrer, ce qui est rarement le cas (shadow-It),
  • Comme pour les CASB, un SSO nécessite d’être déployé de manière centralisée au niveau de la DSI, sans aucune marge de manoeuvre ni flexibilité pour les équipes métiers,
  • L’affiliation d’un outils SaaS à un système de SSO est très couteux (coût du prestataire SSO + coût du serveur d’authentification + coût d’un serveur de secours),
  • Le SSO fragilise la sécurité puisque le piratage d’un seul de ses identifiants compromet toutes les données de l’ensemble des logiciels SaaS inclus dans le SSO,
  • Enfin, si le serveur d’authentification tombe, tous les outils SaaS du SSO cessent d’être accessibles (d’où la nécessité de serveurs de secours…).

Un SSO, quand il est mis en place dans l’entreprise, n’est donc pas exclusif d’un méta SMP comme Sublim.io mais complémentaire. Sublim.io a d’ailleurs vocation à intégrer des SSO comme Okta.

Quelques exemples de SSO : Dashlane, OneLogin, Okta, AuthAnvil, LastPass.

5. Le marché des SMP selon Gartner

L’adoption des outils SaaS dans les entreprises est encore récente. L’analyse Gartner confirme que les consoles d’administration propres à chaque outil SaaS proposent des fonctionnalités grossières et inadaptés en matière de gestion des droits d’accès. Elles impliquent également une suite de tâches manuelles aussi chronophages que répétitives, sources d’erreurs nombreuses.

En l’absence de SMP, la pratique courante des entreprises interrogées est :

  • Développer leurs propres scripts d’automatisation, ce qui est nécessairement imparfait et gourmand en ressources temps,
  • Accepter les limites des consoles d’administration et revoir à la baisse leurs exigences en termes de gouvernance, de contrôle et de sécurité,
  • Renoncer à l’utilisation de certains outils SaaS pourtant sources de productivité.

Gartner identifie les enjeux de sécurité et de conformité des logiciels SaaS comme les principaux déclencheurs d’une souscription à un SMP. Les entreprises indiquent également vouloir utiliser les SMP pour créer des workflows automatisant des tâches jusque-là manuelles et risquées. Par exemple, « placer un nouvel utilisateur dans le groupe Marketing / Allemagne » afin de lui ouvrir automatiquement des comptes SaaS mais avec, pour chacun, des niveaux d’accès appropriés.

CONCLUSION

Grâce à des SMP comme Sublim.io, l’administration de tous vos outils SaaS devient simple, intuitive, centralisée et sécurisée. Fini les traitements manuels qui, le plus souvent, aboutissent à conserver les paramétrages d’origine laissés par défaut par les éditeurs SaaS. Un comportement qui revient à laisser les éditeurs SaaS décider des rôles administratifs, des politiques d’accès et des modèles d’organisation IT de leurs clients… Grâce aux SMP surtout, la sécurité et la confidentialité des données cesse d’être un frein à l’adoption d’outils SaaS aussi précieux que nécessaires dans le cadre de la transformation digitale des entreprises.