Contrôle d’accès pour les applications Multi-tenant et les applications SaaS (ASP.NET, WCF/Silverlight…) 

Contrôle d’accès pour les applications Multi-tenant et SaaS

Qu’est-ce qu’une application multi-tenant ?

Le « multi-tenant » est un concept où un exemplaire unique de l’application fonctionne sur un serveur et est utilisée par de multiples entités utilisatrices ou clientes (tenants). L’application est conçue pour séparer ses données et configuration, ainsi chaque organisation travaille avec une instance adaptée et privée de l’application.

On rencontre le plus souvent deux types d’applications multi-tenant :

  • Des applications spécifiques : développées par des grands comptes et utilisées à distance par leurs entités, agences, filiales ou partenaires.
  • Des applications commerciales : Applications SAAS, hébergées en « Cloud » et utilisées par de nombreux clients.

Comment sécuriser les applications multi-tenant

Comme pour toute application, vous pouvez vouloir sécuriser ces applications avec l’authentification des utilisateurs, une gestion des permissions et des fonctionnalités d’auditing. Le « multi-tenant » implique des objectifs de contrôle d’accès :

1 - Protéger ses données d’un accès par d’autres tenants
Le risque perçu de divulgation des données est plus important avec les applications muti-tenant. Les utilisateurs doivent avoir confiance que leurs données personnelles sont sécurisées, bien qu’ils partagent l’application avec d’autres organisations.
Un système de contrôle d’accès robuste isolera les données de chaque organisation pour fournir le niveau adéquat de protection. Ce système devra fournir les fonctionnalités suivantes :

  • Définir et gérer les organisations et leur ensemble d’utilisateurs
  • Définir et gérer les comptes utilisateurs comme membres d’une organisation
  • Limiter l’accès aux données à l’intérieur de chaque organisation

2 - Déléguer l’administration des permissions
Le propriétaire de l’information doit pouvoir décider qui est autorisé à y accéder. Chaque organisation doit pouvoir adapter les droits d’accès de chaque utilisateur. Par conséquent, le système de contrôle d’accès devrait permettre de :

  • Déléguer l’administration de la sécurité aux administrateurs locaux
  • Protéger la confidentialité des données : l’administrateur d’une organisation ne doit pas avoir accès aux données de sécurité des autres organisations
  • Préserver la disponibilité des données : alors que les données nécessitent d’être sécurisées, c’est aussi nécessaire qu’elles soient accessibles et disponibles en temps opportun. Ce sont les fonctionnalités de l’administration

Gérer des organisations indépendantes

Le système de contrôle d’accès doit pouvoir répliquer n’importe quelle répartition de « sets of users » existant dans la réalité. Visual Guard permet de définir une hiérarchie de groupes d’utilisateurs, chaque groupe pouvant à son tour contenir des utilisateurs ou d’autres groupes.

Ce principe permet de s’adapter à la plupart des cas :

Exemple 1 : une application commerciale de type SAAS pourrait placer ses « Clients » au premier niveau de la hiérarchie des groupes. Chaque client peut ensuite créer ses propres sous-groupes à des niveaux inférieurs pour reproduire son organisation interne.

Exemple 2 : une administration pourrait définir un tenant pour chaque agence qui utilise son système. Si ces agences appartiennent à des départements ou des divisions, elles sont placées à des niveaux inférieurs de la hiérarchie des groupes.

Exemple 3 : si une organisation doit gérer une population mixte d’utilisateurs internes et externes, elle pourra définir des tenants pour gérer indépendants chaque sets of users.

Note : dans ce contexte, VG permet aussi de combiner une authentification par comptes Windows (users internes par exemple) et une authentification par comptes login/password (user externes). Pour plus d’information, voir authentification mixte.

Outre ces exemples basiques, Visual Guard supporte de nombreuses configurations. Par exemple, vous pourrez authentifier les utilisateurs avec leurs comptes Windows, bien que chaque tenant utilise son propre Active Directory. Dans ce cas, Visual Guard permet de fédérer plusieurs Active Directory qui ne sont pas sur le même réseau (cf. Fédération d'Identité). Dans certains cas, vous pourrez aussi implémenter un Single Sign-On (SSO) basé sur le compte Windows de l’utilisateur.

Vous pouvez définir la hiérarchie des groupes depuis :

  • La Console Windows de Visual Guard
  • La Console Web de Visual Guard
  • Votre application (ASP.NET ou WCF/Silverlight par exemple) qui appelle les API de Visual Guard

Comment sécuriser des applications multi-tenant

controle d'accès application multi-tenant et saas
  1. Développement
    Les développeurs définissent les permissions avec la WinConsole VG. Les permissions sont stockées dans un repository de développement.
    Les développeurs déploient les permissions en production avec un utilitaire VG.
  2. Administration
    Des administrateurs gèrent les utilisateurs et leur attribuent des permissions. Ils peuvent appartenir ou non à un tenant. Leurs droits d'administration peuvent être limités par tenant, groupe d'utilisateurs, application, type d'opérations ou une combinaison de ces éléments.
  3. Mise en application
    Les utilisateurs se connectent à l'application et Visual Guard la sécurise comme tout autre application.
    Par défaut, ils utilisent des comptes de types username/password. Ils peuvent également utiliser leur compte Windows (cf. Fédération d'identité). Leurs opérations peuvent être enregistrées dans le VG Repository.
  4. Audit
    Les auditeurs peuvent contrôler les attributs, les rôles et le privilèges des des utilisateurs à travers plusieurs systèmes. Ils peuvent également passer en revue leurs opérations.
    Ils peuvent appartenir ou non à un tenant.
    Comme pour les administrateurs, leurs accès peut être limités par tenant, groupe d'utilisateurs, application, type d'opérations ou n'importe quelle combinaison de ces éléments.

Notes

  • Ces fonctionnalités sont disponibles pour toutes les technologies supportées pas Visual Guard, en particulier les applications .NET ( Winforms, asp.net, WPF, WCF, Silverlight...).
  • Les Administrateurs et Auditeurs peuvent opérer depuis n'importe où avec une simple connexion Internet.

Restreindre les droits d’administration d’une organisation

En général, Visual Guard permet de donner des privilèges à un administrateur pour qu’il puisse gérer les utilisateurs et leur donner des permissions pour chaque application.

Il permet aussi de limiter ces privilèges d’administration à un groupe d’utilisateur. Dans ce cas, l’administrateur peut seulement voir et gérer les utilisateurs de ce groupe.

Dans le cas d’une application multi-tenant, on voudra probablement nommer au moins un administrateur par tenant, et limiter ces privilèges à ce tenant.


Exemple 1 : vous pouvez nommer un administrateur pour chaque tenant

Mais Visual Guard peut aller plus loin : on peut limiter les permissions d’administration à n’importe quel niveau de la hiérarchie des groupes. Ce système offre une grande flexibilité pour distribuer les droits d’administration dans chaque entité à l’intérieur d’un tenant.


Exemple 2 : vous pouvez limiter un administrateur à un sous-groupe à l’intérieur d’un tenant

Pour aller plus loin :
Vous pouvez combiner plusieurs critères pour limiter les permissions d’administration

  • Comme indiqué ci-dessus, vous pouvez limiter ces permissions à certains groupes d’utilisateurs
  • Vous pouvez aussi limiter ces permissions à certaines applications
  • Vous pouvez les limiter à certaines opérations d’administration (par exemple, l’administrateur peut créer des utilisateurs et leur donner des rôles, mais il ne peut pas définir les Rôles)


Exemple 3 : vous pouvez définir plusieurs niveaux d’administrateurs dans un tenant

Rendre les fonctionnalités d’administration disponibles pour chaque organisation

Il est important de simplifier l’accès aux fonctionnalités d’administration :

  • Les applications multi-tenant sont utilisées sur de multiple sites. L’interface d’administration doit être déployable aussi facilement que l’application elle-même.
  • Pour pouvoir distribuer les droits d’administration de façon très flexible, il faut que chaque utilisateur puisse accéder aux fonctionnalités d’administration, quel que soit son emplacement et son niveau technique.

Par défaut, les deux principales solutions sont les suivantes :

1 – Visual Guard Web Console:

  • Cette application permet de gérer les utilisateurs et leurs groupes, rôles, permissions, etc…
  • Il s’agit d’une application web (asp.net), utilisable avec un simple browser.
  • Elle peut-être déployée avec l’application et accessible par les mêmes utilisateurs.
  • Elle inclut un système d’extension : des consultants Visual Guard peuvent ajouter à la Console des pages ASP.NET personnalisées pour respecter des règles spécifiques de sécurité.
  • Vous trouverez plus d’information sur la VG WebConsole sur cette page.

2 – Interface d'administration personnalisée :

  • On pourra aussi développer une interface d’administration personnalisée en ASP.NET ou WCF/Silverlight.
  • Elle sera déployée comme une Console indépendante, ou intégrée à votre application.
  • Elle appellera les API de Visual Guard pour réaliser toutes les opérations d’administrations nécessaires. Ces API sont sécurisées comme décrit plus haut. Elles permettent en particulier de gérer les tenants et de déléguer des droits d’administration restreints pour chaque tenant. Vous trouverez plus d’information sur les API de Visual Guard sur cette page.
  • Vous pouvez développer ces formulaires personnalisé par vous-même ou confier cette tâche aux consultants Visual Guard.

Centraliser ou distribuer la visibilité et les contrôles (audit) ?

Comme pour les droits d’administration, il est possible de donner et limiter des permissions pour voir et contrôler la sécurité des applications multitenant.

Selon les cas, on souhaitera centraliser ou répartir ces permissions.

Exemple 1 : application spécifique utilisée par plusieurs entités d’une grande organisation

  • Par défaut, ce type d’application requiert un contrôle centralisé de la sécurité.
  • L’auditeur doit pouvoir voir tous les droits d’accès et toutes les opérations sensibles réalisées, quels que soient les utilisateurs, départements ou tenants concernés.
  • Libre ensuite à chaque organisation de limiter le périmètre de l’auditeur à certains ensembles d’utilisateurs et/ou applications.

Exemple 2 : Progiciel de type SaaS utilisée par de nombreux clients

  • L’éditeur de logiciel pourra proposer à chaque client de contrôler la sécurité pour ses propres utilisateurs. Dans ce cas, on limitera le périmètre de l’auditeur au tenant correspondant à chaque client.
  • L’auditeur de chaque tenant pourra voir les droits d’accès de ses utilisateurs. Il pourra aussi contrôler les opérations réalisées par les utilisateurs et les administrateurs de son tenant.
  • Si nécessaire, l’éditeur de logiciel pourra contrôler certaines opérations réalisées par ses clients. Cela pourra s’avérer utile dans certains cas de support technique, par exemple pour comprendre l’historique de l’utilisation de l’application et de son administration.

Sources :
http://en.wikipedia.org/wiki/Multitenancy
http://msdn.microsoft.com/en-us/library/ff966480.aspx
http://www.intranetjournal.com/articles/200311/ij_11_10_03a.html