Politique globale et politiques locales

Nous allons tout d’abord récapituler certains critères essentiels que nous devons prendre en compte dans la structure du schéma-cadre PolyOrBAC. Dans notre contexte, nous avons besoin d'un modèle de contrôle d'accès qui assure la collaboration entre les différentes organisations appartenant à l’IIC, sachant que chaque organisation définit sa propre politique de sécurité, met en place ses propres règles de fonctionnement pour ses utilisateurs, et héberge des ressources informatiques hétérogènes qui peuvent être complexes et distribuées sur des réseaux

72

interconnectés multiples. Le type de collaboration qu’on souhaite consiste à permettre à chaque organisation (et à ses utilisateurs) d’accéder de manière sécurisée aux ressources appartenant à d’autres organisations de l’infrastructure.

Pour cela, il faut mettre en place des mécanismes de contrôle d’accès sur les interactions entre organisations, donc au niveau des services Web, en fonction d’une politique de contrôle d’accès globale, commune aux organisations concernées. Il faut donc que la politique locale à chaque organisation prenne en compte les services Web fournis par cette organisation ainsi que ceux qu’elle utilise, la fourniture et l’utilisation de ces services obéissant à la politique globale. Il faut aussi que les politiques locales et globale soient compatibles et cohérentes en termes de sémantique et syntaxe, et qu’elles ne créent pas de contradiction ou de conflits entre elles.

La politique globale, quant à elle, doit gérer trois éléments primordiaux : l’interopérabilité, l’interconnexion et éventuellement l’interdépendance entre organisations. On pourrait imaginer de définir une politique globale à une IIC qui s’imposerait à toutes les organisations membres de l’infrastructure, mais outre que définir une telle politique globale serait un exercice difficile dès que l’infrastructure est d’une complexité significative, ceci serait nécessairement en contradiction avec les besoins d’autonomie des organisations, et d’évolutivité et d’extensibilité (au sens scalability) des infrastructures. Il est donc préférable de définir la sécurité des interactions au niveau de chaque service Web, ce qui ne réduit pas la généralité puisque toutes les interactions se font par des services Web. Il est aussi plus facile de gérer la compatibilité et la cohérence avec les politiques locales, puisque l’on doit considérer pour chaque service Web que deux organisations : le prestataire et le client.

Cette approche garantit l’autonomie de chaque organisation, puisque celle-ci peut librement décider de collaborer avec une autre organisation de son choix par service Web, ou au contraire de créer en interne le service dont elle a besoin ou de garder pour elle l’usage exclusif de ses ressources. Enfin, l’évolutivité et l’extensibilité de l’infrastructure sont favorisées, puisque l’adhésion d’une nouvelle organisation ou la séparation d’une organisation de l’infrastructure n’ont de conséquence que sur les organisations interagissant directement avec elles. La Figure 25 représente une configuration simple des interconnexions entre différentes organisations (cliente et prestataire) collaborant au moyen de services Web.

Par souci de simplification, nous avons supposé que tous les utilisateurs appartenant à l’organisation cliente sont connectés à une seule interface de Service Web, de l’autre coté, nous avons supposé que tous les services proposés par l’organisation prestataire sont accessibles de l’extérieur à travers une seule interface Web. En réalité, il existe plusieurs interfaces service Web pour les différents services Web offerts par un même prestataire, et il existe plusieurs interfaces service Web pour les différents utilisateurs d’une même organisation cliente. De plus les utilisateurs ne sont probablement pas connectés directement à cette interface, mais seulement à travers d’autres systèmes informatiques appartenant à l’organisation A.

73

Figure 25 : Collaboration entre les différentes organisations.

La politique globale de sécurité de l’infrastructure d’information critique s’exprime par des règles définies sur chaque service Web en commun entre le client et le prestataire, plutôt que par une super-organisation imposant une politique unique à toutes les organisations. Nous verrons par la suite que ces règles font partie d’un contrat [Abou El Kalam et al., 2008], négocié entre les deux organisations, client et prestataire du service Web. On appellera donc

politique-contrat l’ensemble des règles de sécurité qui s’appliquent entre les deux organisations

interagissant par un service Web. Pour un même service Web, il y a autant de politiques-contrats différentes que d’organisations clientes du service, et ces politiques-contrats peuvent différer selon les particularités de chaque contrat. Pour faciliter la vérification de cohérence syntaxique et sémantique entre la politique-contrat et les politiques locales du client et du prestataire, ces règles et ces politiques sont exprimées dans un même formalisme, compatible avec le modèle OrBAC présenté au chapitre précédent.

Dans PolyOrBAC, la politique globale de sécurité de l’infrastructure est donc constituée par l’ensemble des politiques-contrats en cours dans l’infrastructure, facilitant ainsi l’évolutivité et l’extensibilité de l’IIC. Quand une organisation rejoint l’infrastructure, il suffit d’établir une politique-contrat pour chaque service Web que la nouvelle organisation offre à une autre organisation de l’IIC et pour chaque service Web offert par une autre organisation à la nouvelle organisation. De même quand une organisation quitte l’infrastructure, il suffit d’éliminer les politiques-contrats qui liaient cette organisation aux autres ; pour les services Web qui étaient fournis par l’organisation quittant l’IIC, il peut être nécessaire que les clients établissent de nouvelles politiques-contrats avec d’autres organisations de l’IIC qui fournissent des services équivalents.

Dans cette vision de PolyOrBAC, chaque organisation gère ses propres ressources indépendamment, avec sa propre politique de sécurité locale, même si certaines de ces ressources peuvent être utilisées par des services Web s’exécutant localement pour le compte d’autres

74

organisations, conformément aux politiques-contrats. Chaque organisation est aussi responsable des actions de ses utilisateurs, actions qu’elle doit contrôler par sa politique locale, même si certaines de ces actions consistent à invoquer des services Web fournis par d’autres organisations, conformément aux politiques-contrats. Chaque organisation doit donc aussi authentifier chacun de ses propres utilisateurs, avec des mécanismes d’une force adaptée au risque d’usurpation d’identité et aux conséquences des abus que pourraient commettre ces utilisateurs. En revanche, il n’est pas utile qu’une organisation connaisse les utilisateurs appartenant à une autre organisation, ce serait même nuisible du point de vue de la confidentialité et de la vie privée.

Par rapport à une politique de sécurité, exprimée grâce à OrBAC, pour une organisation isolée, PolyOrBAC impose que la politique locale d’une organisation participant à une IIC tienne compte des interactions par services Web, pour contrôler l’exécution locale de ces services lorsqu’ils sont invoqués par une autre organisation, et pour contrôler l’invocation par ses propres utilisateurs de services offerts par d’autres organisations. Il faut donc étendre les fonctionnalités d’OrBAC pour prendre en compte ces services Web, et ceci est l’objet de la sous-section suivante.