Personne (presque) ne sait ce qu'est une autorisation.

Au cours de mon travail d'architecte dans des projets de mise en œuvre IdM, j'ai analysé des dizaines de mises en œuvre de mécanismes d'autorisation à la fois dans des solutions internes d'entreprises et dans des produits commerciaux, et je peux dire que presque partout avec des exigences relativement complexes, elles ne sont pas faites correctement ou, du moins, pas de manière optimale. La raison, à mon avis, est la faible attention du client et des développeurs à cet aspect dans les étapes initiales et l'évaluation insuffisante de l'impact des exigences. Cela confirme indirectement l'usage abusif généralisé du terme: quand je vois l'expression «autorisation à deux facteurs», je commence à avoir mal juste en dessous de mon dos. Par intérêt, nous avons analysé les 100 premiers articles sur Habré dans les résultats de recherche pour "autorisation", le résultat était décevant, il y avait beaucoup de douleur:


Dans plus de 80% des cas, le terme est mal utilisé, le mot «authentification» doit être utilisé à la place. Ensuite, je vais essayer d'expliquer ce que c'est et pourquoi il est extrêmement important d'accorder une attention particulière à ce sujet.

Qu'est-ce que c'est?

Pour citer Wikipedia:
Du point de vue de tout système d'information, il s'agit du processus décisionnel permettant de donner accès au sujet pour effectuer l'opération sur la base de toute connaissance du sujet. À ce stade, le sujet, en règle générale, devrait déjà être identifié (nous devons savoir qui il est) et authentifié (son identité est confirmée).

La mise en œuvre de l'autorisation dans le développement d'un système d'information d'entreprise ou d'un produit axé sur le secteur des entreprises est une tâche très difficile et responsable, qui reçoit souvent une attention insuffisante au stade de la conception et de la phase initiale de développement, ce qui conduit à l'avenir à une mise en œuvre «béquille».

Problème

Voyons quelles sont les exigences d'autorisation remplies et pourquoi il est extrêmement important de les prendre en compte lors de la conception d'un système, et de ne pas les reporter pour l'avenir. Il y a généralement deux sources d'exigences d'autorisation dans un système d'information d'entreprise - ce sont les affaires et la sécurité de l'information. En général, une entreprise souhaite garder les secrets confidentiels et accorder des droits aux utilisateurs en fonction de leur fonction dans le processus métier, et la sécurité veut garantir le minimum de pouvoirs pour chaque utilisateur et accéder à l'audit.

Prenons, par exemple, un système hypothétique de négociation de contrats de grande entreprise, une entreprise sanglante typique. Les exigences d'autorisation commerciale suivantes se présenteront très probablement:

1. Un utilisateur qui n'est pas lié à un contrat spécifique ne doit pas le voir dans le système
2. L'auteur du contrat doit le voir à toutes les étapes.
3. Un utilisateur avec une note d'au moins 10 a le droit de créer un contrat.
4. Le visiteur doit voir le contrat, en commençant par sa réception au stade et plus loin.
5. Les chefs de département devraient voir les contrats de leurs unités dans la hiérarchie.
6. L'auteur du contrat et le chef de l'unité ont le droit de retirer le contrat à tout stade de l'approbation.
7. La direction et le secrétariat du siège social devraient consulter les documents de toutes les succursales.
8. L'utilisateur qui a créé le contrat ne devrait pas avoir le droit de l'approuver.

De la sécurité, nous pourrions obtenir les exigences suivantes :

1. Savoir qui a accès à un contrat spécifique.
2. Sachez qui a eu accès à un contrat spécifique à un moment donné.
3. Priver l'utilisateur de l'accès aux documents précédemment disponibles lors de la modification de ses fonctions.

Je pense que les développeurs avaient déjà peur :). Une douleur supplémentaire est la grande variabilité de ces exigences. Soit dit en passant, selon les statistiques d'une grande franchise 1C, les exigences d'autorisation supplémentaires sont l'une des tâches les plus courantes pour personnaliser les configurations typiques.

Nous indiquons donc pourquoi ces exigences sont problématiques:

• Ils ne sont pas stables. La probabilité de leur évolution, même à court terme, tend à 1.
• Ils sont transversaux. Leur implémentation affecte toutes les couches, de la conception de la base de données à l'interface utilisateur.
• Ils se trouvent dans le plan du sujet. Cela conduit à une forte connectivité du mécanisme d'autorisation avec une couche de logique métier.
• Ils affectent les performances.

Des solutions

Les modèles de contrôle d'accès développés nous aident à résoudre ce problème:

MAC est un modèle de contrôle d'accès des informations d'identification. L'accès du sujet à l'objet est déterminé par son niveau d'accès: le niveau d'accès du sujet ne doit pas être inférieur au niveau de confidentialité de l'objet.

DAC - contrôle d'accès direct. L'accès du sujet à l'objet est déterminé par la présence du sujet dans la liste d'accès (ACL) de l' objet.

RBAC est un modèle de contrôle d'accès. L'accès du sujet à l'objet est déterminé par la présence du rôle du sujet contenant les pouvoirs correspondant à l'accès demandé.

ABAC est un modèle d'attribut de contrôle d'accès. L’accès du sujet à l’objet est déterminé dynamiquement sur la base d’une analyse des politiques qui prennent en compte les valeurs des attributs du sujet, de l’objet et de l’environnement. Cela comprend également PBAC, RAdAC, CBAC , avec quelques nuances ( examen chic de CUSTIS ).

Il est fortement recommandé de les utiliser dans leur forme d'origine sans réinventer la roue. Très souvent, dans les systèmes d'information complexes, une combinaison de modèles est utilisée. Par exemple, la combinaison ACL + RBAC est populaire lorsqu'un rôle est inclus dans une liste d'accès. Cependant, l'utilisation correcte de modèles prêts à l'emploi n'est pas non plus une tâche facile. Tout le monde ne peut pas choisir le bon modèle, le séparer de la logique métier et obtenir des performances acceptables du mécanisme d'autorisation.

Pour mettre en œuvre les exigences énoncées ci-dessus dans la section «Problèmes», à première vue, je choisirais la combinaison PBAC + ACL. Les exigences pourraient être mises en œuvre comme suit:

Les exigences SI répertoriées sont implémentées sans aucun problème à l'aide des listes de contrôle d'accès, mais nous implémentons les exigences métier 5 et 7 à l'aide de PBAC. Donc, pour implémenter les exigences des SI 1 et 2, vous devrez leur ajouter un journal ou un mécanisme similaire, car malgré toute sa beauté, les règles dynamiques sont mal auditées:

Total

L'autorisation est un sujet négligé à tort, tant dans les publications que directement dans le processus de développement. L'authentification à deux facteurs via SMS sera vissée sur le site par l'enfant. La mise en œuvre correcte de l'autorisation dans le système d'entreprise sans faire de béquilles est une tâche difficile dont les seigneurs et les architectes brisent les lances, et de nombreux produits commerciaux populaires (par exemple, Atlassian Jira) se tiennent sur des béquilles en raison de la complexité des exigences.

Nous prévoyons une série d'articles sur les modèles d'autorisation et le sujet dans son ensemble. Nous accueillons volontiers les questions et suggestions sur les sujets à examiner.