Meilleure solution pour l’authentification et les permissions ?

1 Objectif de ce document

L’objectif de ce document est de proposer au lecteur un tour d’horizon sur la conception et la création d’un système de contrôle d’accès basé sur les rôles (RBAC).

2 Principaux concepts

Un système RBAC fournit 3 types de fonctionnalités : Authentification, Autorisation et Audit :

2.1 Authentification
L’authentification consiste à vérifier et confirmer l’identité de l’utilisateur qui se connecte à une application. Il s’agit d’un processus en deux étapes : En premier lieu, l’identification qui consiste déclarer son ’identité puis l’authentification qui consiste à la prouver.
La plupart du temps, ce processus est mis en place par l’utilisation d’un compte utilisateur et d’un mot de passe. Cette étape représente le premier niveau de sécurité.

2.2 Autorisation
Les autorisations définissent ce qu’un utilisateur peut faire dans une application : Il s’agit de définir ce que l’utilisateur pourra voir, faire et modifier dans l’application.

Il existe deux méthodes pour définir les autorisations :

• La méthode la plus sûre est d’interdire toutes les options par défaut pour ensuite pour ensuite attribuer des permissions et ouvrir des possibilités. Cette configuration permet une grande sécurité. Si on oublie de définir une permission,les conséquences négatives seront limitées. L’utilisateur sera bloqué et ne pourra pas faire une action autorisée plutôt que d’être capable de faire une action interdite.
• La méthode la plus rapide est d’autoriser toutes les options par défaut puis d’appliquer des restrictions sur certaines actions. Cette méthode est plus rapide que la précédente puisqu’il y a généralement moins de restrictions que de permissions.

En général, ce second niveau de sécurité entraîne de longs développements pour coder l’ensemble des permissions et restrictions.

2.3 Audit
L’audit consiste à conserver une trace des transactions sensibles réalisées dans l’application : Ce type d’information peut être requis pour se conformer à des règles de gestion de l’entreprise, des obligations légales telles que SOX ou pour obtenir des certifications telles que les normes ISO.
L’audit permet de savoir qui a fait quoi dans l’application, quand et qui a donné telle permission à tel utilisateur.

top

3 Composants de base

Les systèmes RBAC pour applications d’entreprise se composent des éléments suivants :

3.1 Un référentiel sécurisé où sont stockées les données de sécurité a
Vous avez besoin d’un endroit sécurisé où stocker les noms, mots de passe, rôles et permissions des utilisateurs : un référentiel de sécurité.

3.2 Un composant intégré à l’application
Ce composant permet la communication entre le référentiel de sécurité et l’application pour qu’elle soit ajustée aux autorisations de l’utilisateur.

3.3 Une console d’administration
Cette application est conçue pour permettre à des personnels non techniques de gérer les comptes utilisateur et leur attribuer des permissions. Son interface simplifiée permet de gérer facilement ce type d’information, libérant ainsi l’équipe de développement de la gestion quotidienne des mots de passe et comptes utilisateur.

3.4 Documentation pour les développeurs et les administrateurs
A tout moment vous pouvez avoir besoin d’une documentation pour tout le personnel qui travaille sur le processus de sécurité de vos applications (guide d’intégration, manuel utilisateur, FAQ, etc.)

top

4 Pourquoi les permissions doivent-elles être indépendantes du code ?

4.1 Qu’est-ce que cela signifie ?
Pour que les permissions soient indépendantes du code de l’application, elles ne doivent pas être définies à l’intérieur de celui-ci. Il faut biensur insérer un appel dans le code pour activer le système RBAC, mais il ne s’agit pas des permissions elles-mêmes.

Si le code qui définit les permissions est inclus dans le code de l’application, les coûts de maintenance sont très importants sur le long terme.

4.2 Permissions et application : un cycle de vie incompatible
L’administration système de sécurité exige une maintenance quasi permanente (création de nouveaux comptes, gestions des mots de passe, modifications dans les permissions, etc.). Par opposition, les changements au sein d’une application sont peu fréquents et une même version peut-être utilisée pendant plusieurs mois.
La durée de vie d’une permission est donc beaucoup plus courte que celle de l’application. Si les permissions sont imbriquées dans code de l’application, les utilisateurs devront attendre une nouvelle version de l’application pour bénéficier des nouvelles permissions.

La définition ou l’attribution de permissions ne doivent pas dépendre des nouvelles versions de l’application.
Vous devez pouvoir ajouter ou attribuer des permissions sans changer le code de l’application (ce qui impliquerait un cycle complet de développement : programmation, tests, correction de bugs, déploiements…). Si les nouvelles permissions sont prises en compte dynamiquement (non codées dans l’application), vous pouvez définir ou attribuer des permissions pendant que l’application est en production. Si tel est le cas, elles sont effectives immédiatement !

4.3 Autonomie des administrateurs
Les administrateurs connaissent les membres du personnel et leur tâches. Ils sont les mieux placés pour évaluer quelles autorisations attribuer (surtout dans le cas des sites distants). Ils ont donc besoin d’un outil d’administration, simple d’utilisation, qui leur permette de gérer les comptes et les permissions des utilisateurs sans devoir faire appel à l’équipe de développement. Ceci n’est possible que si la création de permission n’implique pas de modification du code de l’application.

4.4 Libérer l’équipe de développement
Si Les administrateurs prennent en charge la gestion quotidienne des comptes et des permissions des utilisateurs, l’équipe de développement peuvent se consacrer aux développements prioritaires.

top

5 Questions clés pour bien choisir son système RBAC :

5.1 Avez-vous besoin de... Sécuriser plusieurs applications dans un référentiel centralisé ?
Devez- vous sécuriser plusieurs applications dans un référentiel centralisé ? Vos administrateurs doivent-ils avoir une vision globale des applications et des comptes utilisateur de la société ?

5.2 … Gérer des rôles partagés ?
Un rôle partagé peut-être utilisé dans plusieurs applications tandis qu’un rôle spécifique n’est utilisé que pour une seule application. Les rôles partagés sont particulièrement utiles si vos employés utilisent plusieurs applications : vous n’avez plus à gérer un rôle par application pour un même utilisateur.

5.3 …Supporter le Single Sign-On (Authentification unique)?
Si vous utilisez Active Directory pour gérer les comptes utilisateur, il est généralement nécessaire de mettre en place un processus de Single Sign-on pour que la sécurité soit appliquée de la façon la plus transparente possible du point de vue de l’utilisateur final : dès que l’utilisateur est connecté à une session Windows, toutes les applications s’ouvrent sans qu’il ait besoin de s’identifier à nouveau.

5.4 …Supporter plusieurs technologies (winforms, webforms, services web) ?
Dans les années à venir, votre système RBAC devra-t-il supporter d’autres technologies ? .NET propose un large choix de technologies de développement : Winform, Webform, Services web,WCF, WPF… Si votre système ne prend en compte que les besoins à court terme (applications Winforms par exemple), vous devrez sûrement développer de nouvelles solutions pour supporter d’autres technologies, ce qui conduira au développement de plusieurs systèmes RBAC et augmentera significativement les coûts de développement, de maintenance et de formation.

5.5 …Générer des rapports sur les comptes utilisateurs et leurs permissions ?
Vous pouvez avoir besoin de fournir une description détaillée des comptes utilisateur existants, ainsi que des permissions accordées à chaque utilisateur.

5.6 …Se conformer aux exigences d’audit (SOX…) ?
Pour vous conformer aux exigences légales ou de certification (Sarbanes-Oxley Act, ISO, CMMI, ITIL…), vous pouvez avoir besoin de savoir qui a fait quoi dans l’application (qui se connecte à l’application, qui a ouvert une fenêtre, qui a modifié un enregistrement ?). Vous aurez peut-être besoin de passer en revue la liste des actions pour suivre les transactions sensibles (financières ?).

5.7 ...Supporter une grande équipe de développement voire de dimension internationale ?
Avez-vous une grande équipe de développement ? Votre équipe est-elle répartie sur différents sites ? Si tel est le cas, la coordination requiert un effort significatif, surtout si le turn over et le transfert de connaissance consituent un problème important.

5.8 ...Définir des permissions précises?
Quand on met en place un système permissions/restrictions, on commence généralement par désactiver des options de menu. On est rapidement confronté à des besoins beaucoup plus complexes. Par exemple, autoriser l’impression d’un document seulement pour une catégorie d’utilisateurs, à condition qu’ils aient eux même créé le document.
Vous pouvez donc avoir besoin d’un choix plus large d’actions sur l’application, allant de la désactivation d’un bouton au filtre d’une liste de données en fonction des autorisations de l’utilisateur.
Aurez-vous besoin d’une des options suivantes : masquer ou désactiver un champ, des options de menu, des onglets ou des contrôles ? Filtrer une liste différemment en fonction de l’utilisateur connecté ? Modifier des règles de gestion ?

top

6 Maintenance : Des coûts sous-estimés

Quand il faut choisir une solution, on se concentre généralement sur le coût initial : combien cela coûte-t-il de développer ou d’acheter la solution adéquate ?
Peu de personnes réalisent que ce coût ne représente que 10 à 20 % du budget global.
Forrester Research estime que 78% du budget informatique est destiné à la maintenance. Cette affirmation est vraie pour les applications de gestion, mais également pour les systèmes RBAC.
Il faut donc prendre en compte, dès la conception du système, les coûts supplémentaires auxquels il faudra faire face sur les 10 ou 20 prochaines années.

6.1 6.1 Assister les développeurs et les administrateurs
Quand on intégre un nouveau système de sécurité les développeurs doivent être assisté pour l’implémentation dans l’application, la définition des permissions, l’intégration d’un processus d’authentification, l’utilisation des nouvelles versions du framework .NET... Les administrateurs ont également besoin de support pour la gestion des comptes utilisateur, des rôles et des permissions.
IL faut prévoir une solution pour assister les développeurs et les administrateurs sur le long terme. Dans le cas d’une solution interne, vous devrez maintenir une équipe de support et malgré le turn over et le transfert de connaissance sur plusieurs années .

6.2 Maintenir la cohérence entre le code et les permissions
Quand une application évolue, il est nécessaire de s’assurer que les permissions restent compatibles avec le code de l’application. Par exemple, si un contrôle est modifié, il faudra vérifier manuellement que toutes les restrictions liées à ce contrôle continuent de fonctionner correctement.

Chaque nouvelle version de l’application doit faire l’objet d’une vérification complète des permissions même si cela prend du temps, sous peine de créer des failles de sécurité. Certains systèmes RBAC proposent un processus de vérification automatisé qui pourra être utilisé pour valider une nouvelle version de l’application.

6.3 Déployer de nouvelles versions de l’application
Chaque nouvelle version de l’application est livrée avec un ensemble de permissions. Les nouvelles permissions doivent être déployées avec la nouvelle version de l’application. Malheureusement, on ne peut pas se contenter de simplement remplacer le nouveau référentiel par l’ancien. Toutes les permissions créées par l’administrateur au cours de la vie de l’application (version1) seraient écrasées par le nouveau référentiel (version2).
Il faut insérer les nouvelles permissions dans le référentiel existant avec précaution. Cela implique une importation / exportation manuelle des permissions, à moins que votre système RBAC offre un outil de déploiement automatisé.

6.4 Gérer les migrations entre deux verisons de l’application
Quand une nouvelle version de l’application est en cours de déploiement, certains utilisateurs utilisent la nouvelle version tandis que d’autres continuent d’utiliser la version précédente. Il faut que les référentiels correspondants (version 1 et 2), soient disponibles durant la migration.
Il faut s’assurer que les deux versions sont disponibles et que chaque utilisateur à uniquement accès au référentiel approprié.

top

7 Développement interne, la solution par défaut pour sécuriser une application

Les solutions de sécurité développées en interne offrent un certains nombre de possibilités mais posent certains problèmes, tels que :

7.1 Le développement et la maintenance dépendent des ressources internes
Si vous utilisez une solution interne, il vous faut être particulièrement attentif à la maintenance, car ce sera votre plus gros centre de coûts.
Il faut maintenir une équipe capable de répondre à n’importe quelle question technique ou fonctionnelle et de gérer les changement ou les crises qui viendront à perturber votre système de sécurité.
Le turn over est une forte contrainte dans ce domaine. Vous ne pouvez vous permettre de vous trouver sans technicien qualifié et formé, apte à gérer votre système de sécurité.

7.2 Comptes utilisateur spécifiques à l’application
Il est difficile d’intégrer un système de sessions uniques (Single sign-on, SSO) dans une application .NET. Cela implique de communiquer avec Active Directory et de réutiliser les comptes Windows pour identifier les utilisateurs. C’est pourquoi la plupart des systèmes de sécurité utilisent des comptes créés spécifiquement pour l’application et stockés dans la base de données. Il s’agit certainement de la méthode la plus simple en terme de développement mais de la plus difficile à maintenir : les comptes utilisateurs doivent être gérés par l’équipe de développement tandis les comptes Windows/ Active Directory existants sont gérés par les administrateurs système..

7.3 Accès et permission : une faible précision (granularité)
Adapter une solution interne aux exigences de l’entreprise est un exercice difficile. Les responsables ont tendance à se foclaiser uniquement sur les fonctionnalités d’une solution, sans prendre en compte les implications techniques. Agir sur une option de menu est une chose, créer des permissions complexes à conditions multiple en est une autre.

7.4 Code spécifique dans l’application
En général, les solutions développées en interne mélangent le code des permissions avec le code de l’application. Les développeurs doivent donc gérer un système de sécurité complexe, difficile à maintenir et à mettre à jour. A chaque fois que les données de sécurité doivent être mises à jour, le développeur doit retourner dans le code, trouver les informations précédentes, les modifier, les tester et enfin re-déployer l’application. Ce processus génère un manque de réactivité et de flexibilté.
D’autre part, les besoins de sécurité apparaissent souvent longtemps après la phase de conception et il est souvent complexe, voire impossible de répondre à ces demandes lors du développement. Il arrive fréquemment que des besoins complexes soient identifiés une fois que l’application est en production et requierent une modification immédiate et coûteuse de l’application.

7.5 Une solution séparée pour chaque application : problèmes de maintenance
En théorie, il faudrait être capable d’avoir une idée précise de ce que sera l’entreprise dans 5 ou 10 ans pour pouvoir concevoir un système de sécurité global et unifié. En réalité, ceci est presque impossible. Le scénario le plus probable est que vous devrez développer de nouvelles applications avec des technologies nouvelles qui ne seront pas supportées par votre ancien système de sécurité. Il faudra donc en créer un nouveau. Au final, vous aurez de multiples systèmes de sécurité indépendants, autrement dit des coûts de maintenance énormes.

top

8 Visual Guard, une solution d’entreprise pour la sécurité de vos applications

Novalys développe des solutions d’authentification et de permissions depuis 15 ans. Forts de cette expérience, nous avons conçu Visual Guard, une solution destinée à sécuriser les applications .NET, quelle que soit la complexité de votre environnement.

8.1 Une solution unifiée pour sécuriser et centraliser toutes vos applications .NET
Visual Guard vous permet de sécuriser dans un seul outil tout type d’application : winform, webform et services web, WCF, WPF... La gestion de toutes vos applications et comptes utilisateur est centralisée dans un référentiel sécurisé unique.
Visual Guard fournit une solution clé en main de single sign-on basée sur les comptes Windows. (Si vous le souhaitez, vous pouvez utiliser les comptes applicatifs Visual Guard)
Pour simplifier encore la gestion des permissions, vous pouvez créer des rôles partagés qui regroupent les autorisations d’un utilisateur pour plusieurs applications.

8.2 Des permissions indépendantes du code
Avec Visual Guard, vous n’écrivez pas de code dans votre application pour définir les permissions.
Cela signifie que vous pouvez définir et intégrer des permissions sans repasser par un cycle complet de développement, test, déploiement, attente de feedback et corrections des bugs.
Vous pouvez définir des permissions à tout moment, même quand l’application est en production.
Les permissions sont actives immédiatement et dynamiquement.

8.3 Des outils de gestion conçus pour des personnels non techniques
La console de Visual Guard simplifie la gestion quotidienne de la sécurité pour les personnels non techniques. La gestion des comptes utilisateur, des rôles et des permissions ne requiert aucune connaissance technique.
De ce fait, le choix d’un responsable de la sécurité ne dépend plus de compétences techniques. Cela permet d’optimiser les process de l’entreprise pour une meilleure réactivité : les responsables peuvent être les personnes chargées de la sécurité, les administrateurs système, les responsables de sites distants…
Pour une meilleure flexibilité, vous pouvez définir plusieurs niveaux de privilèges pour les administrateurs.
Vous pouvez également créer votre propre formulaire d’administration et l’intégrer dans votre application. Il appellera l’API de Visual Guard pour gérer les utilisateurs et les rôles tout en respectant votre chartre graphique.

8.4 Des outils pour les développeurs : création des permissions, gestion des versions et du déploiement
Visual Guard offre un large choix d’outils et d’assistants destinés au développeurs : vous avez la possibilité de créer des permissions en quelques clics, vérifier automatiquement la cohérence entre l’application et les permissions, déployer de nouvelles permissions dans un référentiel existant sans altérer les données de sécurité en production, gérer plusieurs versions d’un référentiel pendant le déploiement de l’application...

8.5 Audit tools to generate permission reports and review application logs
Les auditeurs ont le droit de consulter et de générer des rapports détaillés sur les permissions existantes, les rôles et les comptes utilisateur de l’application. Ils peuvent passer en revue le log de l’application pour suivre des transactions particulières, ainsi que le log de la console d’administration pour vérifier qui a donné une autorisation à quelqu’un.

8.6 Un produit standard avec un support professionnel et des mises à jours fréquentes
Pourquoi réinventer la roue ? Visual Guard fournit des fonctionnalités prêtes à l’emploi pour la sécurité de vos applications. Depuis 15 ans, nous l’avons fait évoluer pour qu’il devienne une solution d’entreprise standard.
L’intégration de Visual Guard est simple et rapide, tout comme sa prise en main.
Novalys propose un support international : vous pouvez vous concentrer sur votre corps de métier et nous laisser résoudre vos problèmes de sécurité.
Novalys s’engage également à faire le meilleur usage des innovations constantes de Microsoft sur le framework .Net, l’OS Microsoft, etc.

top