Conception efficace des rôles
Dans de nombreux scénarios, la sécurité basée sur les rôles est un mécanisme très efficace, mais il existe des situations où elle est moins efficace. Vous devez prendre en considération un certain nombre de facteurs pour décider où et comment appliquer la sécurité basée sur les rôles à une application particulière.
Caractéristiques des utilisateurs et des données et adéquation des rôles
Les rôles fonctionnent très bien pour caractériser des groupes d’utilisateurs et, sur cette base, filtrer les actions que ces utilisateurs peuvent effectuer. Souvent, cela s’effectue dans la pratique en créant des rôles qui reflètent la place d’un utilisateur au sein d’un organization, par exemple les rôles « Gestionnaires » et « Guichetiers », « Administrateurs » et « Lecteurs », « Employés du projet Un » et « Employés du projet deux ». Dans ce cas, lorsque les données consultées sont assez génériques par rapport aux utilisateurs, les rôles peuvent être utilisés efficacement pour appliquer des règles métier telles que les suivantes :
« Les gestionnaires peuvent transférer n’importe quelle somme d’argent. Les caissières ne peuvent transférer que jusqu’à 10 000 $.
« Les administrateurs peuvent changer n’importe quoi. Tout le monde peut uniquement lire. »
« Les employés de Project One peuvent accéder à une certaine base de données. Personne d’autre ne le peut.
Les utilisateurs peuvent naturellement se trouver dans plusieurs rôles, selon la façon dont les rôles modélisent la structure organisationnelle d’une entreprise.
Toutefois, les rôles ne fonctionnent pas très bien lorsqu’une décision d’accès en matière de sécurité repose sur les caractéristiques d’un élément de données particulier. Par exemple, il serait difficile d’utiliser des rôles pour refléter des relations complexes entre l’utilisateur et les données, telles que les suivantes :
« Un responsable particulier peut accéder aux données du personnel uniquement pour ses rapports. »
« Joe Consumer peut rechercher le solde de son compte. »
Dans ce cas, la vérification de la sécurité doit souvent être effectuée au niveau de la base de données elle-même, où il est plus facile de prendre en compte les caractéristiques innées des données consultées. Cela signifie que vous devez utiliser l’emprunt d’identité pour transmettre l’identité du client à la base de données et laisser la base de données valider la demande. Cela peut affecter les performances et affecter la conception de l’application. Par exemple, le regroupement de connexions peut ne pas fonctionner lorsqu’une connexion est ouverte sous une identité d’utilisateur particulière. Pour plus d’informations sur les problèmes impliqués, consultez Sécurité des applications multiniveau et Emprunt d’identité et délégation du client.
Complexité et scalabilité d’une stratégie d’autorisation Role-Based
Quelle que soit la stratégie de sécurité que vous mettez en place, elle sera aussi efficace que son implémentation par les administrateurs système qui déploieront votre application. Si les administrateurs font des erreurs lors de l’attribution d’utilisateurs aux rôles appropriés en fonction de votre stratégie de sécurité, votre stratégie ne fonctionnera pas comme prévu. Les problèmes sont plus susceptibles de se produire dans les circonstances suivantes :
- Vous avez créé une stratégie basée sur les rôles très complexe, avec de nombreux rôles et utilisateurs mappés à de nombreux rôles.
- Vous créez des rôles avec des critères ambigus pour déterminer qui doit leur appartenir.
- Il y a de nombreux utilisateurs sur le site où l’application est installée, et les utilisateurs se déplacent fréquemment dans le organization, changeant en fonction des rôles que vous avez créés.
- Il existe de nombreux administrateurs sur le site où l’application est installée, avec une répartition des responsabilités, afin qu’un administrateur familiarisé avec les exigences de sécurité de votre application ne soit pas familiarisé avec les grands groupes d’utilisateurs qui doivent l’utiliser. Cela est particulièrement préoccupant lorsque les utilisateurs se déplacent dans le organization : ces informations doivent être bien communiquées.
En outre, à mesure que le nombre de rôles attribués à une application augmente, le temps que COM+ doit consacrer à la recherche de l’appartenance de l’appelant à ces rôles augmente, avec une dégradation probable des performances.
Pour gérer la complexité et atténuer ces problèmes, vous pouvez utiliser les instructions suivantes :
- Choisissez des noms de rôles auto-descriptifs. Rendre aussi évident que possible les utilisateurs qui doivent appartenir à quels rôles.
- Faites en sorte que votre stratégie basée sur les rôles soit aussi simple que possible (et pas plus simple). Choisissez le moins de rôles possible, tout en conservant une stratégie efficace.
- Documentez clairement la stratégie basée sur les rôles que vous construisez pour les administrateurs, si l’appartenance au rôle est évidente (pour vous). En particulier, utilisez le champ description disponible pour chaque rôle afin de décrire l’intention du rôle. Si vous ne pouvez pas décrire en général qui doit appartenir au rôle dans quelques phrases, c’est probablement trop compliqué.
- Recommandez vivement aux administrateurs de votre application de remplir les rôles avec des groupes d’utilisateurs plutôt qu’avec des utilisateurs individuels. Il s’agit d’une solution beaucoup plus évolutive. Il facilite l’affectation ou la suppression d’utilisateurs à mesure qu’ils se déplacent au sein du organization et protège les administrateurs d’une certaine quantité de supervision et de problèmes de communication.
Rubriques connexes