Audit et definition de la politique de sécurité du réseau informatique de la first bank

3. LES MODELES DE SECURITE

A partir du début des années 70, plusieurs modèles de sécurité se sont succédés : I-BAC, R-BAC, V-BAC, T-MAC et plus récemment Or-BAC. Nous allons évoquer brièvement ces modèles de sécurité mais nous marquerons un temps d'arrêt sur le modèle Or-BAC que nous utiliserons dans la suite.

3.1. LE MODÈLE I-BAC (IDENTITY BASED CONTROL ACCESS)

Premier modèle de contrôle d'accès proposé dans la littérature, ce modèle introduit les concepts fondamentaux de sujet, d'action et d'objet :

§ le sujet est l'entité active du SI (utilisateur, ordinateur, processus, programme,...) ;

§ l'objet est l'entité passive du SI (fichier, base de donnée, ordinateur, programme,...) ;

§ l'action désigne l'effet recherché lorsqu'un sujet accède à un objet (lire, écrire, modifier,...).

L'objectif du modèle I-BAC est de contrôler tout accès direct des sujets aux objets via l'utilisation des actions. Ce contrôle est basé sur l'identité du sujet et l'identificateur de l'objet, d'où le nom du modèle I-BAC.

Le modèle I-BAC présente cependant des limites. La politique d'autorisation devient complexe à exprimer et administrer. Il est en effet nécessaire d'énumérer les autorisations pour chaque sujet, action et objet. En particulier, lorsqu'un nouveau sujet ou objet est créé, il est nécessaire de mettre à jour la politique d'autorisation pour définir les nouvelles permissions associées à ce sujet ou objet.

3.2. LE MODÈLE R-BAC (ROLE BASED ACCESS CONTROL)

Le modèle RBAC (Role Based Access Control) propose de structurer l'expression de la politique d'autorisation autour du concept de rôle. Un rôle est un concept organisationnel : des rôles sont affectés aux utilisateurs conformément à la fonction attribuée à ces utilisateurs dans l'organisation. Le principe de base du modèle R-BAC est de considérer que les autorisations sont directement associées aux rôles. Dans R-BAC, les rôles reçoivent donc des autorisations de réaliser des actions sur des objets.

Un autre concept introduit par le modèle R-BAC est celui de session. Pour pouvoir réaliser une action sur un objet, un utilisateur doit d'abord créer une session et, dans cette session, activer un rôle qui a reçu l'autorisation de réaliser cette action sur cet objet. Si un tel rôle existe et si cet utilisateur a été affecté à ce rôle, alors cet utilisateur aura la permission de réaliser cette action sur cet objet une fois ce rôle activé. Lorsqu'un nouveau sujet est créé dans le SI, il suffit d'affecter des rôles au sujet pour que ce sujet puisse accéder au SI conformément aux permissions accordées à cet ensemble de rôles.

Comparé au modèle I-BAC, la gestion de la politique d'autorisation s'en trouve simplifiée puisqu'il n'est plus nécessaire de mettre à jour cette politique chaque fois qu'un nouveau sujet est créé.

Mais comme I-BAC, le modèle R-BAC ne considère que des autorisations positives (permissions) et fait donc l'hypothèse que la politique est fermée. Bien plus, dans les modèles I-BAC et R-BAC, les actions correspondent généralement à des commandes élémentaires, comme la lecture du contenu d'un objet ou l'écriture dans un objet. Dans les applications récentes, le besoin apparaît de contrôler la réalisation d'actions composites, appelées tâches ou activités. Par exemple, dans une agence de voyage, la tâche d'achat d'un billet d'avion se décompose en plusieurs actions plus élémentaires telles que la réservation du billet, le paiement du billet et l'édition d'une facture. Le besoin de contrôle sur des activités composites est en particulier présent dans les applications de type workflow8(*) d'où la modèle T-BAC.

* ⁸ On appelle « workflow » (traduisez littéralement « flux de travail ») la modélisation et la gestion informatique de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d'un processus métier.