Huit points clés pour sécuriser vos applications SaaS

La sécurité d'une application SaaS doit combiner robustesse et flexibilité.

Un système Robuste garantira la sécurité de l'application en:

• contrôlant l'accès des utilisateurs dans les limites de leur souscription ;
• assurant la confidentialité des données entre utilisateurs partageant l'application ;
• éliminant les failles de sécurité et vous protégeant des attaques extérieures.

Un système Flexible contribuera au développement de votre business:

• il facilitera l'évolution de votre business model et la commercialisation de votre offre ;
• répondra aux demandes des clients sur la gestion des comptes utilisateurs (voir plus bas) ;
• supportera la montée en charge : optimisera les performances et simplifiera l'administration d'un volume important d'utilisateurs et de composants sécurisés.

Cet article recense les spécifications techniques et fonctionnelles permettant d'atteindre ce double objectif. Il vous aidera à concevoir la sécurité de votre application SaaS en prenant en compte les contraintes importantes dès le début du projet. Vous pourrez ainsi couvrir les besoins court-terme, tout en anticipant les futures évolutions nécessaires au développement de votre business.

Dans un premier temps, vous gérerez peut-être vous-même les comptes utilisateurs et leurs droits d'accès.

Lorsque le volume augmentera, vous souhaiterez peut-être - tout comme vos clients- leur déléguer certains droits d'administration pour qu'ils gèrent eux-mêmes les comptes de leurs utilisateurs.

Si tel est le cas, vous aurez besoin :

• d'une interface d'administration facilement utilisable par des non-techniciens. Vous pourrez ainsi déléguer l'administration des utilisateurs à des managers locaux ;
• cette interface d'administration devra offrir via Internet toutes les fonctionnalités de contrôle d'accès requises (gestion des comptes, des groupes, assignation des droits d'accès, visibilité et contrôle des données de sécurité.).

Si vous développez une application SaaS multitenant (une seule instance utilisée par plusieurs clients), vous devrez restreindre les droits d'administration du client à ses propres comptes utilisateurs: vous ne voulez pas qu'il puisse modifier les comptes d'autres clients ! Plus généralement, on pourra restreindre les droits d'administration délégués selon trois axes:

• limiter l'administration aux comptes utilisateurs d'un client, voire à une partie seulement des utilisateurs d'un client. Exemple : un chef des ventes ne pourra définir que les droits d'accès des commerciaux de son équipe ;
• limiter à certaines opérations d'administration. Exemple : un manager ne peut pas créer de nouveaux comptes utilisateurs. Il peut seulement leur donner des droits d'accès ;
• limiter l'administration à certaines applications. Exemple : un responsable des ressources humaines pourra gérer le contrôle d'accès à un module de paye, mais il ne pourra pas donner accès au module de gestion des stocks.

Selon les scénarios possibles, il faudra prévoir un système de contrôle d'accès flexible, permettant de déléguer plusieurs niveaux de droits d'administration, selon l'organisation interne et les demandes de vos clients.

En savoir plus sur le Contrôle d'accès pour les applications Multitenant et SaaS

Si votre offre est composée d'une suite d'applications, votre contrôle d'accès devra probablement inclure des fonctionnalités de Single Sign-On pour simplifier l'expérience de vos utilisateurs :

• ils pourront accéder à plusieurs applications, en passant librement d'une application à l'autre ;
• si les applications font appel à des services Web sécurisés, les utilisateurs seront aussi automatiquement authentifiés pour chaque service web utilisé ;
• chaque utilisateur se connectera une seule fois au premier site et pourra ensuite accéder aux autres applications sans fournir à nouveau ses identifiants (Single Sign-On).

Un système de SSO typique pour des applications SaaS inclura les fonctionnalités suivantes.

III-A. Gérer la session de l'utilisateur▲

III-B. Fournir un frontal web pour le Single Sign-On▲

III-C. Faciliter l'intégration des applications au système de SSO▲

III-D. Support des configurations complexes▲

Par défaut, un nouveau compte est créé pour chaque utilisateur accédant à l'application SaaS.

Le problème est que les utilisateurs possèdent déjà de multiples comptes qui génèrent des coûts significatifs pour les entreprises (lire l'article « Le vrai coût des mots de passe »).

Certaines entreprises souhaitent réutiliser les comptes de leurs utilisateurs (leurs comptes Windows par exemple).Votre système de contrôle d'accès devra alors permettre de donner à ces comptes existants des droits d'accès à vos applications.

En savoir plus sur comment combiner les fonctionnalités de fédération d'identité et le contrôle d'accès basé sur les permissions.

Le système de contrôle d'accès est souvent lié au business model (paiement à l'utilisation ou licence permanente) et au modèle de distribution du logiciel (SaaS ou sur site).

Selon les évolutions du marché et de votre stratégie d'entreprise, votre modèle initial sera peut-être complété par d'autres modèles (pour servir plusieurs catégories de clients ou élargir votre offre commerciale par exemple).

Votre système de sécurité devra permettre ces évolutions.

Reste à définir quels modèles seront pertinents pour votre entreprise parmi les plus courants :

Cas n° 1: Modèle SaaS par défaut

L'application est hébergée par le vendeur avec le système de sécurité. Les utilisateurs y accèdent par Internet.

Le client paye pour utiliser votre application sur une base limitée en temps et récurrente.

Business model : paiement à l'utilisation

Modèle de distribution : SaaS

Cas n° 2: Pour des raisons de sécurité ou techniques, le client peut demander l'installation de l'application dans son environnement. Les utilisateurs y accèdent via une connexion LAN ou Internet. Le vendeur continue de gérer le contrôle d'accès: le client paye pour l'utilisation de l'application sur une base limitée en temps et récurrente.

Business model: paiement à l'utilisation

Modèle de distribution: sur site

Cas n° 3: Si les clients souhaitent réutiliser des comptes de leurs utilisateurs (leurs comptes Windows par exemple).

Le système de contrôle d'accès doit alors donner à ces comptes existants des droits d'accès l'application SaaS.

Business model : paiement à l'utilisation
Modèle de distribution : SaaS

Cas n° 4: Modèle de distribution d'application classique. Le client est propriétaire d'une copie de l'application. Il gère lui-même le contrôle d'accès.

L'éditeur peut ajouter ce modèle à son catalogue - en plus du SaaS - pour élargir son offre.

Le système de contrôle d'accès doit être facilement déployable chez les clients (outils d'administration simples et robustes, documentation complète.).

Pour autant, ce type de déploiement n'interdit pas le paiement à l'utilisation. Il faudra pour cela que le système de gestion des clés logiciel les distribue des licences à durée limitée.

Business model : paiement à l'utilisation ou licence permanente

Modèle de distribution : Sur site

Si votre business model repose sur le paiement à l'utilisation (pay-per-use) de l'application SaaS ou sur des droits d'utilisation temporaire, votre système de contrôle d'accès devra supporter :

• les comptes utilisateurs à durée de vie limitée ;
• une API permettant de collaborer avec un système de facturation pour mettre à jour automatiquement les dates de fin d'utilisation de chaque compte ;
• une interface utilisateur pour que le service commercial ou le centre d'assistance puisse modifier ces informations - traiter les cas particuliers ou les erreurs par exemple, avec effet immédiat pour l'utilisateur concerné.

L'interface d'administration doit être conçue pour gérer de nombreux utilisateurs et droits d'accès (guider l'administrateur dans ses manipulations et ses recherches, optimiser les temps de réponse du référentiel de sécurité.).

Lorsque l'application SaaS est en production, le processus d'authentification de l'utilisateur et de calcul de ses droits d'accès doit être optimisé pour éviter un temps d'attente trop long. Par exemple, lorsqu'un système doit accéder au référentiel de sécurité à chaque fois qu'une nouvelle page est ouverte par l'utilisateur, la probabilité de rencontrer des problèmes de performance augmente parallèlement au volume d'utilisateurs et de pages vues.

Puisque l'application SaaS sera accessible via Internet et gèrera des données clients, il est nécessaire de concevoir le système de telle sorte qu'il ne soit pas vulnérable aux attaques les plus courantes.

Accès non autorisé aux données de sécurité :

• les données de sécurité ne doivent pas être lisibles par un accès direct SQL. Il faut imposer de passer par l'application SaaS ou par l'interface d'administration pour lire et modifier ces données ;
• les données sensibles telles que les mots de passe, doivent être cryptées.

Déni de service :le système de contrôle d'accès doit inclure une protection contre les attaques visant à rendre votre service indisponible en le saturant avec de nombreuses demandes d'ouverture de session.

Opérations d'administration nonautorisées : un utilisateur pourrait découvrir comment accéder à l'interface d'administration ou aux API qui gèrent le contrôle d'accès de l'application SaaS. Il faudra inclure une protection lui interdisant de donner illégalement des droits d'accès supplémentaires à des comptes utilisateurs.

Interception de données confidentielles :

• entre le navigateur client et le serveur Web(Support des protocoles SSL/HTTPS, cryptage des communications entre le navigateur et le serveur Web.) ;
• entre les composants.NET au sein de l'application SaaS.

Password cracking:le système de contrôle d'accès doit définir une politique de mot de passe sophistiquée afin d'empêcher le password cracking (deviner le mot de passe avec de multiples tentatives).

Packetsniffing: le système de contrôle d'accès doit inclure une protection contre la capture de packets de données permettant de trouver les mots de passe ou les tokens de sécurité transitant sur le réseau. Un hacker pourrait voler ces tokens et faire des appels au système comme s'il s'agissait d'un utilisateur.

Injection SQL: le système de contrôle d'accès contiendra probablement des champs de recherche pour retrouver un compte utilisateur par exemple. Il faudra prémunir le système contre des injections SQL, consistant à insérer des portions d'ordres SQL dans la recherche, dans le but de consulter des informations confidentielles ou de modifier illégalement les données de sécurité.

Le calendrier est la clé: on voit dans cet article que la sécurité et le contrôle d'accès d'une application SaaS impliquent des fonctionnalités complexes. Dans le cas d'un développement réalisé en interne, elles nécessitent un délai significatif et des compétences de haut niveau.

Si le calendrier du projet est serré ou si l'expertise correspondante n'est pas disponible, une solution commerciale de contrôle d'accès est peut-être la meilleure option.

Gestion des risques: une solution prête à l'emploi limitera vos risques court terme (dépassement de délai, bogues et failles de sécurité), mais vous serez exposés à d'autres risques contre lesquels il faudra vous couvrir.

• Evolutivité : consultez l'historique des versions de la solution : suit-elle les évolutions technologiques du marché, les sorties de versions sont-elles régulières et surtout récentes (risque d'obsolescence) ?
• Qualité produit & support : privilégiez une solution stable et déjà déployée, pour laquelle des retours d'utilisateurs sont consultables.
• Pérennité de la solution : que se passe-t-il si le fournisseur disparaît ? La solution est-elle livrée avec ses codes sources ? Le fournisseur propose-t-il un escrow agreement (dépôt des codes sources chez un tiers qui l'envoie aux utilisateurs en cas d'interruption de service de la part du fournisseur) ?

Pourquoi ne pas combiner tous les avantages ? Si le fournisseur est à l'écoute des utilisateurs pour faire évoluer sa solution avec le marché, vous bénéficiez des avantages d'une solution générique (plus complète, plus stable et moins couteuse) tout en influençant les futurs développements pour couvrir au mieux vos besoins spécifiques. Demandez à consulter la feuille de route de la solution et vérifiez que le fournisseur sait prendre en compte les suggestions de ses utilisateurs.

Nous remercions Claude LELOUP pour la relecture orthographique.