[chapo]En 2020 une politique “no-cloud”sera aussi rare qu’une politique “no-internet” aujourd’hui : point de vue du Gartner, conforté par l’idée que 70% des entreprises ont déjà une stratégie Cloud définie ou en cours d’identification (Source Gartner : «Building an Enterprise Cloud Strategy That Works»).[/chapo]
Cet engouement pour le Cloud se concentre aujourd’hui sur l’adoption de solutions SaaS (Software as a Service). Bien souvent vues comme du ShadowIT, ces solutions répondent avant tout à une attente des métiers, que la DSI doit être en mesure d’accompagner. La problématique principale porte sur l’intégration des applications SaaS qui doit être maîtrisée et industrialisée pour favoriser l’adoption des applications.
L’Architecte est l’interlocuteur clé de ces nouveaux usages : nous détaillons ici les fondamentaux auxquels il doit répondre pour s’assurer qu’une solution SaaS réponde aux besoins métiers et aux exigences de sécurité et d’intégration.
Respecter les exigences non fonctionnelles
L’aspect du cloud souvent mis en avant est la mise à disposition rapide d’une nouvelle application pour les utilisateurs finaux. Cet avantage est malheureusement trop souvent mal compris et peut mener au choix d’une solution qui sera rapidement abandonnée. Pour l’élection d’une solution SaaS, rien ne sert de partir tête baissée, il est primordial d’effectuer une étude approfondie sur le besoin métier fonctionnel / non fonctionnel et de connaitre les exigences des équipes sécurité et environnements de travail. Pour le métier, externaliser une application engendre forcement des questions non fonctionnelles auxquelles les fournisseurs Cloud doivent pouvoir répondre.
Les points importants sont :
- Ø Comment être certain du niveau de disponibilitéde la solution et principalement durant mes périodes critiques ?
- Ø Mes données sont « sensibles » et/ou personnelles, comment le prestataire s’assure-t-il de la confidentialitéde mes données ?
- Ø J’ai des contraintes légales qui m’obligent à garder une traçabilité en cas d’audit ou/et en cas de contentieux juridique. Comment vérifier que la solution réponde à ce besoin ?
- Pour mes tâches du quotidien, je dois être certain que les données affichées sont viables et donc que l’intégritéde mes données est respectée.
Disponibilité
Souvent les entreprises considèrent que le niveau de SLA fourni par le fournisseur est suffisant pour valider le niveau de disponibilité. Nous pensons que la vraie question est : Que se passe-t-il si ce niveau SLA n’est pas respecté par le prestataire ? Souvent, en cas de non respect du niveau du SLA, le préstataire « rembourse » un pourcentage du coût mensuel. Cette sommes est fréquement très éloignée des pertes financières réelles surtout si l’impact sur l’image de l’entreprise est prise en compte
Nous conseillons donc de vérifier durant des phases de RFI (Request for information)/RFP(Request for Proposal) que l’architecture technique du fournisseur à la capacité de répondre au besoin métier sur la Durée d’Interruption Maximum Admissible et Perte de données Maximale Admissible en cas de sinistre majeur (perte d’un datacenter) et Local (perte d’un serveur physique). Dans le cas ou le fournisseur ne possède pas de PRA cohérent avec le niveau d’attente de disponibilité du métier , vous pouvez l’éliminer durant ces phases.
Confidentialité
La grande crainte des entreprises reste et sera toujours la sécurité. Malgré l’effort de l’ensemble des fournisseurs Cloud, ne pas posséder les données dans ses propres locaux engendre des préoccupations majeures. En effet, comment puis-je m’assurer que seulement les personnes autorisées peuvent accéder à mes données, comment puis-je m’assurer que mes données restent en Europe ?
Vous avez la possibilité de demander les certifications/normes (ISO, SOC etc) obtenus pour l’hébergement des données. Par expérience, ces éléments sont rarement suffisants pour le RSSI. Il faut donc prendre le sujet dans l’autre sens et se demander : Quelles sont les données que je considère comme « sensibles » ? Puis-je noter la sensibilité de mes données sur une échelle de 1 à 4 ? Si oui, quels mécanismes de sécurité dois-je attendre pour m’assurer que le niveau de sécurité peut –être respecté par le fournisseur ? Dans ce cas de figure, les entreprises doivent travailler sur la déclinaison technique à attendre pour chaque niveau de confidentialité. La déclinaison peut avoir le modèle simplifié ci-dessous :
- Niveau 1 :Données publics. Pas de mécanisme particulier attendu par le fournisseur
- Niveau 2: Données internes. Chiffrement des disques et traçabilité obligatoire de l’ensemble des accès aux données
- Niveau 3: Information restreinte : Niveau 2 + Chiffrement/déchiffrement des données par clé. Possibilité de laisser la clé chez le fournisseur
- Niveau 4: Données sensibles. Obligation de garder les données dans les datacenter ou niveau 3 avec l’obligation de garder la clé de chiffrement dans le datacenter -> Actuellement solution très couteuse en termes de
- Une fois le niveau de sensibilité défini par le métier et la déclinaison technique réalisée par la sécurité, vous pouvez choisir le fournisseur SaaS le plus adapté à votre entreprise.
Traçabilité/intégrité
La traçabilité et l’intégrité des données peuvent être traitées comme la confidentialité. L’important est de pouvoir identifier des niveaux et de décliner les attentes techniques de chaque niveau.
Environnement de travail
Le principe d’une solution SaaS est d’être accessible depuis le navigateur Web. Afin d’éviter des impacts et des complications dans la gestion de dizaine de solutions SaaS, il est fondamental de vérifier :
- Ø la compatibilité des solutions avec la version de vos navigateurs web (Edge, Firefox, chrome)
- Ø qu’aucun client lourd ne doit être installé sur les postes de travail.
- Ø Que la solution soit en HTML5 uniquement. En effet, les composants tiers tels que Silverlight, Flash, applet java ne seront bientôt plus supportés par les navigateurs web
- Ø Qu’aucune configuration spécifiquedoit être effectuée dans les navigateurs.
Expérience utilisateur
Lorsque plusieurs solutions SaaS sont contractualisées, il n’est pas envisageable d’avoir des utilisateurs se connectant à chacune des applications avec un login/mdp différent. Le changement d’application deviendra vite un cauchemar pour l’utilisateur.
Imaginez-vous : devoir stocker l’ensemble des login/mdp, devoir les écrire dans chacune des applications, devoir mettre à jour le mot de passe dans chacune des applications (donc ne pas pouvoir mettre le même mot de passe)… Heureusement, pour pallier ce problème, des solutions de fédération d’identité permettent de réaliser du SSO (Sigle Sign On) à travers des standards tels que SAML, WS-Federation, OAuth et OpenID Connect.
Le marché propose de nombreuses solutions, par expérience, le standard SAMLv2 réalisé par le serveur fédération Pingfederate répond pleinement au besoin de fédération. Autre que la fédération d’identité, il permet de faire du Just-in-time provisining. C’est-à-dire provisionner les comptes utilisateurs à la première connexion de celui-ci. Ce mécanisme pour le provider identité (entreprise) consiste à envoyer le rôle de l’utilisateur (souvent associé à un groupe Active Directory) et des informations identification (nom, prénom, adresseMail) dans l’entête http. À l’envoi par le provider identité, le rôle est reconnu par la solution SaaS et l’utilisateur est ajouté automatiquement dans sa base locale.
Ce mécanisme comporte les avantages suivants :
Ø Contrôle centralisé aux applications SaaS : L’utilisateur doit être seulement ajouté dans un groupe AD interne. Une « best practice » est d’avoir un processus de validation pour ajout d’un utilisateur dans un groupe AD
Ø Simplification des échanges : Pas besoin d’envoyer un fichier « utilisateur» à l’ensemble des solutions SaaS
Ø Sécurité : L’affection des utilisateurs à des groupes est maitrisée complétement par l’entreprise/le métier.
La mise en place de cette solution de provisioning n’est malheureusement pas supportée par l’ensemble des éditeurs. Ce sujet peut donc être un point différenciant pour juger la maturité d’un éditeur mais une solution plus « classique » doit souvent être réalisable par l’entreprise.
Provisionning des comptes utilisateurs
La « méthode classique » de provisionning consiste à l’envoi d’un fichier CSV avec l’ensemble des informations attendues par l’éditeur (souvent identifiant unique, adresse mail, unité d’organisation). Chaque solution peut attendre sa propre structuration du fichier CSV(colonne 1 : Nom, Colonne 2 : Prénom) , le système d’échange doit donc être en capacité d’envoyer des fichiers formatés différemment à chaque fournisseur. C’est souvent dans ce cadre de transformation qu’interviendra une plateforme d’échange. Actuellement, certaine solution propose de s’adapter à votre format en faisant des mapping internes entre votre donnée du CSV et leur attendu interne. Ce mécanisme peut montrer une maturité plus importante du fournisseur.
L’ensemble de ces sujets montre les questions fondamentales à se poser pour réussir l’intégration des applications SaaS. Il est important d’anticiper l’ensemble de ces questions afin d’industrialiser et simplifier l’intégration des solutions SaaS. Le prochain article présentera une organisation possible (acteurs/responsabilités/outils) permettant de s’assurer que les solutions SaaS respectent les exigences de l’entreprise.
Sofiane MALTI – Publié le 07 Mai 2017
