Expression des politiques-contrats sous forme d’automates temporisés

Les automates temporisés (timed automata) ont été proposés pour décrire les comportements de systèmes en tenant compte de caractéristiques temporelles [Alur & Dill, 1994]. En fait, un automate temporisé est un automate fini incluant un ensemble d'horloges (clocks), c'est-à-dire des variables réelles et positives qui croissent de manière linéaire avec le temps. Les transitions d’un automate temporisé sont étiquetées par des gardes (guards), c'est-à-dire des conditions sur les valeurs d'horloges, des actions et des mises à jour, qui attribuent de nouvelles valeurs aux horloges. Notons que les transitions sont instantanées et que le temps est consommé dans les états : chaque état est étiqueté par un invariant qui représente une condition booléenne sur les horloges ; le temps d'occupation de l’état dépend de l’invariant, l’état est occupé si l'invariant est vrai.

La composition d'automates temporisés est obtenue par un produit synchrone : chaque action a exécutée par un automate temporisé correspond à une action avec le même nom a exécutée en parallèle par un autre automate temporisé. En d'autres termes, une transition qui exécute l'action a ne peut être déclenchée dans un automate que si une transition étiquetée par l’action a peut également être déclenchée dans l’autre automate. Les deux transitions sont déclenchées simultanément, ce qui correspond à un mécanisme de communication par

rendez-vous. Enfin, il est important de noter que la représentation d’un système par un automate

temporisé se prête bien à la vérification par modèle (model-checking). En particulier, il est possible de représenter une propriété en termes d’accessibilité de certains états, et l’analyse d’accessibilité des états (à partir d’une configuration initiale de l’automate) peut être effectuée automatiquement par des outils de model-checking adaptés.

Pour représenter une politique-contrat avec la richesse des modalités principales d’OrBAC (permissions, interdictions, obligations), il faut représenter ces modalités dans les automates temporisés. C’est l’objet des sections suivantes.

3.4.2.1 Expression des permissions

Tout d'abord, une permission (correpondant à une action qui est autorisée par les clauses de la politique-contrat) est simplement représentée par le biais de transitions dans les automates temporisés. Par exemple, dans la Figure 28, le système peut exécuter l'action a à tout moment, puis se comporter selon les possibilités définies dans l'automate A.

78

Figure 28 : Modélisation des permissions. Figure 29 : Modélisation des interdictions.

3.4.2.2 Expression des interdictions

Pour ce qui concerne les interdictions, il faut en distinguer deux types dans les politiques-contrats :

• L’interdiction implicite: comme dans les politiques de contrôle d’accès positives, tout ce qui n’est pas explicitement autorisé est interdit, une action qui ne correspond à aucune transition dans l’automate est interdite.

• L'interdiction explicite: dans notre modèle, une interdiction explicite est représentée par une transition vers un état d’échec (illustré par une frimousse10 triste). Les interdictions explicites, présentes dans OrBAC, permettent souvent d’exprimer des règles plus claires qu’une simple absence de permission. En particulier, cela permet d’exprimer des exceptions à des règles de permissions, ou de limiter la propagation des permissions dans les hiérarchies de rôles. Dans notre modèle, la transition vers un état d’échec correspond à la détection d’une action interdite (supposée malveillante), pour laquelle on peut définir un traitement d’exception destiné à contrer l’action malveillante ou à corriger les dégâts qu’elle pourrait avoir causés. Le non-respect d’une interdiction pourra aussi conduire à imposer les pénalités à l’organisation responsable de l’action interdite (voir 3.4.1).

3.4.2.3 Expression des obligations

Dans les politiques-contrats, les obligations correspondent à des actions qui sont nécessaires dans un certain contexte. Du point de vue logique, l’obligation est équivalente à une “interdiction de ne pas faire” et le non-respect d’une obligation est donc équivalent à une action interdite, et en tant que telle peut conduire à un traitement d’exception. Comme une obligation est nécessairement autorisée (une action peut ne pas être à la fois obligatoire et interdite), l’obligation doit être représentée par une transition dans l’automate temporisé. Toutefois, comme les obligations sont sémantiquement plus fortes que les permissions, il faut ajouter d'autres symboles pour décrire cette sémantique et pour faire la distinction entre ce qui est

10 Le terme est approuvé par la Commission générale de terminologie et de néologie, Journal officiel du 16

79

obligatoire et ce qui est simplement autorisé mais pas obligatoire. Les obligations sont donc représentées par des transitions auxquelles sont associées des échéances temporelles (time-outs) sur des transitions et des invariants d’états : si la transition n’est pas activée avant l’échéance, une autre transition est déclenchée automatiquement vers un état d’échec, qui peut conduire à un traitement d’exception. Dans cette sémantique, l’obligation correspond à une action qui doit être réalisée dans un temps donné, la non-réalisation dans les temps étant équivalente à une interdiction. Ceci est schématisé dans la Figure 30, où k est un compteur de temps, d est l’échéance temporelle, b est l’action obligatoire, a est l’action déclenchée par l’échéance, conduisant au traitement d’exception A2. L’état à partir duquel l’action b est obligatoire possède un invariant (k <= d).

3.4.2.4 Identification des situations de conflits

Comme on vient de le voir, quand une interdiction explicite est violée ou lorsqu’une obligation n'est pas remplie, l’automate atteint un état d’échec. Cette situation ne survient que si l’une des deux parties, le client ou le fournisseur du service Web, ne respecte pas les règles de la politique-contrat. La représentation par automate temporisé aide à identifier la partie responsable de cette violation de politique, par l’analyse de la séquence états-transitions qui a conduit à l’état d’échec.

Figure 30 : Modélisation des obligations. Figure 31 : Modélisation des situations de conflits.

Cette modélisation des différends (situations de conflit) permet donc non seulement d'identifier les anomalies et les abus (violations de droits), mais aussi d’identifier les activités (succession d'actions et d'interactions) qui ont conduit à ces situations, d’en déduire le responsable de l’anomalie (celui qui a réalisé une action explicitement interdite, ou n’a pas réalisé une action obligatoire dans les temps prévus), et donc de lui imposer les pénalités prévues au contrat. De plus, comme les conséquences peuvent être de gravités différentes et conduire à des pénalités graduées, ceci peut être représenté dans l’automate par des étiquettes sur les états d’échec.

80