Brevet FR3016227A1 — publié le 20150710

Arrière plan de l'invention L'invention se rapporte au domaine général des télécommunications, et notamment aux systèmes informatiques dits « en nuage », connus également sous le nom de systèmes de « cloud computing ». Elle concerne plus particulièrement l'accès par un utilisateur à des ressources informatiques mises à la disposition de cet utilisateur par un système de cloud computing. Selon la définition donnée par le National Institute of Standards and Technology (NIST), l'informatique en nuage ou « cloud computing » est un modèle permettant à des utilisateurs d'accéder via un réseau, à la demande et en libre-service, à des ressources informatiques et réseaux comme un espace de stockage, de la puissance de calcul, des applications, des logiciels ou encore des services, qui sont virtualisées (i.e. rendues virtuelles) et mutualisées. Autrement dit, les ressources informatiques et réseaux ne se trouvent plus sur un serveur local d'une entité ou sur un poste d'un utilisateur, mais sont, conformément au concept de cloud computing, dématérialisées dans un nuage composé de plusieurs serveurs distants interconnectés entre eux, et accessibles par les utilisateurs via une application réseau. Les utilisateurs peuvent ainsi accéder de manière évolutive à ces ressources, sans avoir à gérer l'infrastructure sous-jacente de gestion de ces ressources qui est souvent complexe. Le concept de « cloud computing » est décrit plus en détails dans le document édité par l'ITU (International Telecommunication Union) intitulé « FG Cloud TR, version 1.0 - Part 1 : Introduction to the cloud ecosystem : définitions, taxonomies, use cases and high-level requirements », février 2012. De façon connue, le « cloud computing » bénéficie de nombreux avantages : flexibilité et diversité des ressources qui sont mutualisées et quasiment illimitées, évolutivité possible des ressources, fournies à la demande, - administration simple et automatisée des infrastructures informatiques et réseaux des entreprises, et réduction des coûts d'administration, - etc. Un enjeu majeur du concept de « cloud computing » est toutefois de garantir la protection et la sécurisation de l'accès aux ressources. En effet, passer d'un environnement informatique traditionnel, sécurisé et fermé, à une infrastructure dans un nuage, ouverte et mutualisée, sur laquelle l'utilisateur ou l'entreprise n'a aucun contrôle, et qui est accessible via un réseau de télécommunications tel que le réseau public Internet, particulièrement vulnérable et sans cesse sujet aux attaques et aux piratages informatiques, n'est pas sans susciter quelques inquiétudes chez les potentiels utilisateurs en termes de sécurité. Le contrôle d'accès apparait donc aujourd'hui pour l'ITU comme un moyen fondamental pour sécuriser l'accès à des systèmes informatiques en nuage. De nombreux mécanismes existent dans l'état de la technique actuel pour contrôler (et sécuriser) l'accès à un système informatique (ou de façon équivalente, à un système d'information) d'entités ou d'organisations telles une entreprise. Ces mécanismes se basent essentiellement sur deux éléments, à savoir : - la définition d'une politique en matière de droits d'accès formulée selon une approche sujet-objet-action, i.e. tel sujet a la permission ou non de réaliser telle action sur tel objet, et - la mise en oeuvre de cette politique sur réception d'une requête d'un utilisateur souhaitant accéder aux ressources offertes par le système informatique, via un contrôle des droits d'accès de l'utilisateur à ces ressources. De tels mécanismes sont par exemple les modèles de contrôle d'accès RBAC (Role-Based Access Control) et OrBAC (Organization-Based Access Control), décrits respectivement dans les documents de R-S. Sandhu et al., « Role-Based Access Control Models », IEEE Computer 29(2), pages 38-47, 1996, et de A. Abou El Kalam et al., « Organization Based Access Control », 4th IEEE International Workshop on Policies for Distributed Systems and Networks, 2003. Le modèle OrBAC s'appuie sur un concept d'organisation, et permet de modéliser une variété de politiques de sécurité définies pour et par cette organisation pour l'accès à ses ressources. Ainsi, plus précisément, le modèle OrBAC introduit les notions de rôles, d'activités et de vues pour permettre de définir une politique de sécurité associée à une organisation, où : - un rôle est un ensemble de sujets sur lequel les mêmes règles de sécurité sont appliquées ; - une activité est un ensemble d'actions sur lequel les mêmes règles de sécurité sont appliquées ; et - une vue est un ensemble d'objets sur lequel les mêmes règles de sécurité sont 30 appliquées. Le modèle OrBAC définit notamment huit ensembles d'entités : - Org : ensemble d'organisations ; - S : ensemble de sujets ; - A : ensemble d'actions ; 35 - 0 : ensemble d'objets ; - R : ensemble de rôles ; - Act : ensemble d'activités ; V: ensemble de vues ; et C: ensemble de contextes. Le modèle OrBAC définit également les prédicats: - « Empower » (Habiliter) sur les domaines Org xSxR: Si org est une organisation, s un sujet et r un rôle, alors Empower(org, s, r) signifie que org habilite le sujet s dans le rôle r. - « Consider » (Considérer) sur les domaines Org x A x Act : Si org est une organisation, a une action et act une activité, alors Consider(org, a, act) signifie que org considère l'action a comme une activité act. « Use» (Utiliser) sur les domaines Org x O x V : Si org est une organisation, o un objet et v une vue, alors Use(org, o, v) signifie que org utilise l'objet o dans la vue v. « Hold » (Tenir) sur les domaines Org xSxAx0xC: Si org est une organisation, s un sujet, a une action, o un objet et c un contexte, alors Ho/d(org, s, a, o, c) signifie que dans l'organisation org, le contexte c est satisfait entre le sujet s, l'action a et l'objet o. « Permission » (Permission) sur les domaines Org x R x Act x V x C: Si org est une organisation, r un rôle, act une activité, v une vue et c un contexte, alors Permission(org, r, act, y, c) signifie que dans l'organisation org, le rôle r a la permission d'effectuer l'activité act sur la vue v dans le contexte c. Le modèle OrBAC est un modèle auto-administré qui adopte une approche orientée-objet. "AdOrBAC", l'administration du modèle OrBAC, est notamment décrite dans le document "Administration Model for Or-BAC' de F. Cuppens et A. Miège - On The Move to Meaningful Internet Systems 2003 : OTM 2003 Workshops (pp. 754-768), Springer Berlin Heidelberg, janvier 2003. Ce modèle d'administration est défini comme une extension du modèle OrBAC et utilise les concepts du modèle OrBAC. Dans ce modèle, on ne manipule pas les permissions directement, mais des objets d'administration (en anglais « administrative objects ») dotés d'une sémantique spécifique et appartenant à des vues spécifiques, appelées vues d'administration (en anglais « administrative views »). Chaque objet d'administration possède un identifiant qui identifie de façon unique l'objet et l'ensemble d'attributs décrivant cet objet. La vue License est utilisée pour spécifier et gérer les permissions des utilisateurs. L'existence d'une permission dans une vue License est interprétée par la règle suivante : Permission(org, r, act, Use(org, I, license), Organization org), Role(I, r), Activity(I, act), View(/,, y), Context(I, c) Autrement dit, une permission pour permettre dans une organisation org, d'effectuer l'activité act sur la vue v dans le contexte c est équivalent à utiliser l'objet / dans la vue kense. L'objet / comporte un ensemble d'attributs mémorisant respectivement l'information sur l'organisation, le rôle, l'activité, la vue et le contexte. Corrélativement, pour spécifier un rôle Admin autorisé à gérer les permissions, il suffit de créer une permission (c'est-à-dire un objet d'administration de la licence) qui autorise ce rôle à « gérer » (en anglais « manage ») la vue License. On note : Permission(org, Admin, manage, License, default context) Il apparaît que la permission d'administration qui autorise un rôle à réaliser des actions d'administration a la même sémantique que les permissions classiques. Les permissions d'administration sont ainsi gérées comme les autres permissions. L'invention se situe plus particulièrement dans le contexte des systèmes en nuage à multiples locataires (en anglais « multi tenants ») dans lesquels une seule instance d'un système informatique en nuage est partagée par plusieurs organisations clientes (locataires ou en anglais « tenants »). Un locataire peut ainsi être défini comme un contenant atomique auquel on attribue un ensemble d'utilisateurs et une partition virtuelle de ressources. Dans la pratique, un locataire peut permettre de modéliser une entreprise, un service d'une entreprise, ou un projet. Si dans la plupart des cas les systèmes à multiples locataires sont définis au sein d'un service en nuage, il faut rappeler qu'un locataire n'est pas nécessairement défini au sein d'un nuage. Un locataire peut en effet être un contenant virtuel contenant un ensemble d'utilisateurs et un ensemble de ressources fournies par plusieurs systèmes en nuage. Par souci de simplicité, on considèrera dans ce document que les locataires sont propres à un nuage. Actuellement, dans la plupart des systèmes en nuage à plusieurs locataires, les ressources de chacun des locataires sont cloisonnées dans des domaines indépendants et étanches, chaque locataire gérant indépendamment sa politique de contrôle d'accès. Des utilisateurs possédant des droits privilégiés d'administration peuvent définir les règles de sécurité qui s'appliquent pour le locataire. Cette isolation est intéressante lorsqu'un client détient un seul locataire dans le nuage, le client voulant pouvoir définir sa propre politique de sécurité sans interférer sur celles des autres locataires du nuage. En référence à la figure 1, nous allons maintenant décrire un exemple de système de contrôle d'accès conforme au modèle de référence XACML (eXtensible Access Control Markup Language) définie par l'IETF (Internet Engineering Task Force), un tel système pouvant notamment être utilisé par le modèle de contrôle d'accès OrBAC. Le modèle XACML se base, comme de façon connue, sur cinq types de blocs fonctionnels, à savoir : Un bloc de contrôle d'accès PEP (en anglais « Policy Enforcement Point »), apte à envoyer, au bloc PDP défini ci-après, une demande de permission au format XACML, à recevoir une décision d'autorisation ou de refus, et à appliquer cette décision. Un bloc de décision PDP (en anglais « Policy Decision Point ») apte à déterminer, sur réception d'une demande XACML de permission émise par le bloc PEP, en fonction de la politique applicable, si la permission doit être autorisée ou refusée, et à délivrer en conséquence une décision d'autorisation ou de refus au bloc PEP; lorsque des valeurs d'attributs nécessaires au bloc PDP pour prendre sa décision ne sont pas présentes dans la requête XACML, le bloc PDP peut interroger le bloc PIP défini ci-après en vue de les obtenir. - Un bloc PIP (en anglais « Policy Information Point ») apte, sur requête du bloc PDP, à lui fournir des valeurs d'attributs lorsque celles-ci ne sont pas présentes dans la requête XACML envoyée au bloc PDP par le bloc PEP. - Un bloc PAP (en anglais « Policy Administration Point ») dont la fonction principale est de créer et gérer les politiques des différents locataires. Dans cet exemple on utilise en outre une pluralité de zones de stockage (en anglais Policy Repository ») Ti, Tn chacune pour stocker la politique de sécurité du locataire de même nom T1, ...Tn ; Nous supposons ici que l'authentification d'utilisateurs a déjà été réalisée, soit par un module du nuage, soit par un fournisseur d'identité de confiance. Au cours d'une étape El, l'utilisateur d'un locataire envoie une requête d'accès au bloc PEP de contrôle d'accès. A l'étape E2, le bloc PEP de contrôle d'accès consulte le bloc de décision PDP pour que celui-ci détermine si l'accès peut être autorisé ou s'il doit être interdit. A l'étape E3, le bloc PDP consulte le bloc PIP pour obtenir au besoin des informations complémentaires. Il obtient ces informations au cours d'une étape E4. A l'étape E5, le bloc de décision PDP obtient la politique du locataire à partir de la zone de stockage correspondante. A l'étape E6, le bloc de décision PDP prend une décision d'autorisation ou d'interdiction d'accès et communique cette décision au bloc PEP de contrôle d'accès. Si l'accès est autorisé, le bloc PEP permet l'accès à l'étape E7. On note que dans ce mécanisme de contrôle d'accès, les droits des utilisateurs d'un locataire sont régis par la politique de contrôle d'accès propre à ce locataire. Le bloc d'administration PAP est le bloc par lequel les administrateurs des différents locataires gèrent les politiques de sécurité propres aux locataires, le bloc PAP autorisant ou non un administrateur à gérer la politique de sécurité du locataire. Dans l'état actuel de la technique, du fait du cloisonnement précédemment décrit, l'administrateur d'un locataire A n'est pas autorisé à administrer un autre locataire B. Nous allons maintenant décrire les principales étapes Fl à F5 d'un procédé d'administration du système de la figure 1. Au cours d'une étape F1, un utilisateur administrateur envoie au bloc d'administration PAP, une requête pour effectuer une action d'administration pour modifier la politique de contrôle d'accès d'un locataire T1. Le bloc PAP reçoit cette requête, et au cours d'une étape F2 consulte le bloc PDP pour que celui-ci vérifie si cet utilisateur a le droit d'effectuer cette action d'administration. Au cours d'une étape F3, le bloc PDP interroge la zone de stockage du locataire Ti pour vérifier si l'utilisateur administrateur dispose de l'autorisation d'administration correspondante, les autorisations d'administration étant stockées au même titre que les autres autorisations d'accès. Nous supposerons dans cet exemple qu'au cours d'une étape F4, le bloc PDP fournit une réponse positive au bloc d'administration PAP et que le bloc d'administration PAP exécute l'action d'administration pour modifier la politique de contrôle d'accès du locataire Ti au cours d'une étape F5 non représentée. Avec l'adoption croissante des services en nuage, il est maintenant fréquent qu'une organisation détienne plusieurs locataires dans un même nuage. Par exemple, une organisation peut créer un locataire pour chacun de ses services. De même, un département peut créer un locataire pour chacun de ses projets en cours. Le fait qu'une organisation possède plusieurs locataires pose de nouveaux défis pour la gestion des politiques de sécurité des locataires. En effet, du fait des contraintes de cloisonnement évoquées précédemment, comme chaque locataire gère sa propre politique de sécurité, seuls les utilisateurs administrateur référencés auprès d'un locataire peuvent accéder à et gérer la politique de sécurité de ce locataire. Ainsi, le responsable sécurité d'une organisation qui souhaite pouvoir gérer la sécurité de tous les locataires de son organisation doit être dûment référencé auprès de tous les locataires. Ces contraintes de cloisonnement qui ne permette d'obtenir qu'une vue partielle de la politique de sécurité de l'organisation peuvent engendrer des conflits dans la gestion de cette politique. Par exemple, si un utilisateur et des ressources sont présents dans deux locataires, il peut se produire que cet utilisateur ait accès auxdites ressources dans un des locataires mais pas dans l'autre. L'invention propose un mécanisme pour faciliter et automatiser la gestion de la politique de sécurité d'une organisation possédant plusieurs locataires dans un même nuage. Objet et résumé de l'invention Ainsi, et selon un premier aspect, l'invention concerne un procédé de gestion des politiques de sécurité d'une pluralité de locataires appartenant à un même nuage, ce procédé comportant : - une étape pour définir une hiérarchie entre les locataires ; une étape pour autoriser tout administrateur de la politique de sécurité d'un quelconque desdits locataires, à accéder à la politique de sécurité des locataires de niveau hiérarchique inférieur au niveau hiérarchique dudit locataire; et - une étape pour interdire à tout administrateur de la politique de sécurité d'un quelconque desdits locataires, d'accéder à la politique de sécurité des locataires de niveau hiérarchique supérieur au niveau hiérarchique dudit locataire. Corrélativement, l'invention concerne un système de gestion des politiques de sécurité d'une pluralité de locataires appartenant à un même nuage, le système comportant : - un module pour définir une hiérarchie entre les locataires ; - un module de décision apte à autoriser tout administrateur de la politique de sécurité d'un quelconque desdits locataires, à accéder à la politique de sécurité des locataires de niveau hiérarchique inférieur au niveau hiérarchique de ce locataire; et à interdire à tout administrateur de la politique de sécurité d'un quelconque desdits locataires, d'accéder à la politique de sécurité des locataires de niveau hiérarchique supérieur au niveau hiérarchique de ce locataire. Conformément à l'invention, on définit une hiérarchie entre les locataires d'une organisation appartenant à un même nuage. Soit T l'ensemble de ces locataires et TT la relation hiérarchique sur le domaine x T, on utilise la notation ti tj pour représenter que le locataire tj est hiérarchiquement supérieur au locataire ti, autrement dit que le locataire tj domine le locataire ti. La relation hiérarchique étant réflexive, transitive et anti-symétrique on obtient, pour tous locataires ti, tj, tk : ti Lorsque A --.. B , on dit aussi que « A est un descendant de B », que « B est un parent de A » ou que « B domine A ». Dans un mode particulier de réalisation, la relation hiérarchique de dominance peut être complète ou limitée à certaines prérogatives. On dira par la suite que la hiérarchie est : - « complète » si l'administrateur du locataire B peut administrer entièrement le locataire A qu'il domine ; « restreinte à l'attribution des rôles » (URA - User Role Assignment) si l'administrateur du locataire B peut uniquement modifier l'attribution des rôles du locataire A qu'il domine ; - « restreinte à l'attribution des permissions » (PRA - Permission Role Assignment) si l'administrateur du locataire B peut uniquement modifier l'attribution des permissions du locataire A qu'il domine. Dans un mode particulier de réalisation, le système de gestion selon l'invention comporte: - un bloc d'administration PAP comportant le module de définition ; - un bloc de décision PDP comportant le module de décision, les blocs PAP, PDP étant conformes à l'architecture de référence XACML (eXtensible Access Control Markup Language) utilisée par le modèle de contrôle d'accès OrBAC. L'utilisation d'un mécanisme de contrôle d'accès conforme au modèle OrBAC permet de proposer un modèle hiérarchique de gestion de la sécurité de l'information d'une organisation particulièrement flexible, apte à reproduire l'organisation hiérarchique de l'organisation elle-même. Ce mécanisme est particulièrement efficace en ce qu'il permet d'offrir à chaque entité de l'organisation, pour la gestion de la sécurité de ces informations, un degré d'autonomie propre qui peut refléter le degré d'autonomie de l'entité dans l'organisation, chaque entité hiérarchiquement supérieure ayant une vision claire et une possibilité de contrôle de la politique de sécurité des entités qui lui sont inférieures dans la hiérarchie. Dans un mode particulier de réalisation, les différentes étapes du procédé de gestion des politiques de sécurité sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre du procédé de gestion des politiques de sécurité tels que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des dessins D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description qui suit, faite en référence aux dessins annexés dans lesquels : - la figure 1 déjà décrite illustre un système de contrôle d'accès conforme à l'art antérieur; - la figure 2 représente l'organigramme d'un exemple d'organisation ; - la figure 3 illustre un système et un procédé conformes à un mode particulier de réalisation de l'invention pour gérer les politiques de sécurité de l'organisation de la figure 2. - la figure 4 illustre un système conforme à un deuxième mode particulier de réalisation de l'invention ; et - la figure 5 illustre un procédé conforme au deuxième mode particulier de réalisation de l'invention. 20 Description détaillée d'un mode de réalisation La figure 2 représente l'organigramme d'une organisation ORG, telle qu'une entreprise, cette organisation comportant une direction DIR, un département de développement DEV, un département de comptabilité ACC, le département de développement DEV gérant deux projets P1, 25 P2. La figure 3 illustre un système SYS de gestion des politiques de sécurité de l'organisation de la figure 2. Dans le mode de réalisation décrit, l'organisation crée dans un nuage un locataire pour chacune des entités de l'organisation, chaque locataire DIR, DEV, ACC, P1, P2 ayant une zone de 30 stockage du même nom dans lequel l'administrateur mémorise sa politique de sécurité. Les zones de stockage DIR, DEV, ACC, P1, P2, le bloc de contrôle d'accès PEP (« Policy Enforcement Point »), le bloc de décision PDP (« Policy Decision Point »), le bloc d'information PIP (« Policy Administration Point ») et le bloc d'administration PAP (« Policy Administration Point ») sont identiques à ceux décrits en référence à la figure 1 et ne seront pas décrits ici. 35 Ce système est en revanche remarquable en ce qu'il comporte : une zone de stockage des relations hiérarchiques SRH ; un module de vérification des relations hiérarchiques VRH, ce module étant apte à recevoir une requête pour vérifier si un locataire en domine un autre et à renvoyer au demandeur une réponse booléenne en fonction du résultat de la vérification ; - un module de gestion des relations hiérarchiques GRH permettant de gérer les relations hiérarchiques entre les locataires de l'organisation. La zone de stockage des relations hiérarchiques SRH comporte une base de données qui mémorise toutes les relations hiérarchiques, autrement dit toutes les relations d'ordre entre les locataires de la figure 2. Cette base de données peut être représentée comme suit : Descendant Parent Type de hiérarchie DEV DIR URA ACC DIR PRA P1 DEV URA P2 DEV URA P1 DIR URA P2 DIR URA Dans cet exemple, l'administrateur du locataire correspondant à la direction DIR peut uniquement modifier l'attribution du locataire correspondant au département de développement DEV (hiérarchie de type « URA »). De même et en particulier, l'administrateur du locataire correspondant au département de développement DEV peut uniquement modifier l'attribution des permissions au sein des locataires correspondant aux projets P1, P2. Il apparaît dans cette base de données que le locataire DIR correspondant à la direction de l'organisation domine les projets P1 et P2 en raison du caractère transitif de la relation hiérarchique. Les références de la figure 3 s'interprètent comme suit : Au cours d'une étape G10, le gestionnaire du nuage (par exemple le responsable sécurité) de l'entreprise envoie une requête pour gérer les relations hiérarchique entre les locataires. Au cours d'une étape G20, le gestionnaire de relation hiérarchique GRH modifie les relations hiérarchiques dans la zone de stockage des relations hiérarchiques SRH. Cette étape constitue une étape pour définir la hiérarchie entre les locataires au sens de l'invention. Un message de succès est retourné à l'étape G30. Les étapes H10 à H80 illustrent un exemple d'administration de la politique de sécurité de l'organisation de la figure 2. Dans cet exemple, on suppose que l'utilisateur U1 du locataire DEV émet, à l'étape H10 une requête pour gérer la politique de sécurité du locataire P2, avec P2 -. DEV . A l'étape H20, le bloc d'administration PAP interroge le bloc de décision PDP pour vérifier si U1 est autorisé à effectuer cette opération. A l'étape H30, le bloc de décision PDP vérifie dans un premier temps si la zone de stockage du locataire DEV comporte une permission permettant à l'utilisateur U1 de gérer la politique du locataire P2. A l'étape H40 le bloc de décision PDP interroge le module VRH de vérification des relations hiérarchiques vérifie si le locataire DEV domine le locataire P2 (hiérarchie complète ou restreinte). A l'étape H50, le module VRH de vérification des relations hiérarchiques consulte la zone SRH de stockage des relations hiérarchiques pour vérifier si P2 DEV. A l'étape H60, le module VRH de vérification des relations hiérarchiques retourne une réponse positive au bloc de décision PDP. A l'étape H70, le bloc PDP retourne une réponse positive au bloc d'administration PAP. A l'étape H80, le bloc d'administration PAP modifie la politique de sécurité du locataire P2 selon la demande de l'utilisateur U1. Dans le premier mode de réalisation décrit ci-dessus, le type de contrôle d'accès mis en oeuvre dans le nuage n'était pas précisé. Nous présentons maintenant un mode de réalisation de l'invention dans lequel on utilise un contrôle d'accès conforme au modèle OrBAC. On suppose que l'organisation comporte deux locataires T1, T2, chacun comportant un rôle de même nom Admin. On considère tout d'abord à l'administration de la politique de sécurité au sein du locataire T1 et on suppose que le rôle Admin dispose de l'autorisation d'affecter des utilisateurs à des rôles de T1, à savoir Autorisation (T1, Admin, Manage , Role Assignment , default context ). De retour à la figure 3, nous décrivons comment un utilisateur administrateur U1 attribue à un utilisateur U2 un rôle de développement DEV dans le locataire T1. Au cours de l'étape H10, l'utilisateur U1 envoie une demande d'habilitation au bloc d'administration PAP Empower(T1 ,U2 ,DEV ) Au cours de l'étape H20, le bloc PAP interroge le bloc PDP pour vérifier si une telle action d'administration peut être effectuée. Au cours de l'étape H30, le bloc PDP interroge la zone de stockage de la politique de T1 pour vérifier si U1 a le rôle d'administrateur Admin et si ce rôle Admin possède l'autorisation : Permission(T1 , Admin, Manage, Role Assignment , default context) Les étapes H40 à H60 sont omises pour une administration de la sécurité au sein d'un locataire. Au cours de l'étape H70, le bloc de décision PDP renvoie une réponse positive au bloc d'administration PAP. Au cours de l'étape H80, le bloc d'administration PAP habilite l'utilisateur U1 : Empower (T1, Ul , DEV). Nous décrivons maintenant l'administration entre locataires en supposant que le locataire T2 domine T1 de manière restreinte à l'attribution des rôles, et que le rôle d'administrateur Admin de T2 a le droit de gérer l'attribution des rôles du locataire X dominé par T2 : Autorisation (T2, Admin, Manage, X : : Role Assignment , default context ) expression dans laquelle « X :: Role_Assignment » identifie de manière unique la vue Role_Assignment du locataire dominé X. Nous considérons maintenant qu'un utilisateur U3 ayant le rôle Admin du locataire T2 souhaite attribuer à un utilisateur U2 un rôle de développement DEV du locataire T1: Au cours de l'étape H10, l'utilisateur U3 envoie une demande d'habilitation au bloc d'administration PAP Empower(T1 ,U2 ,DEV ) Au cours de l'étape H20, le bloc PAP interroge le bloc PDP pour vérifier si une telle action d'administration peut être effectuée. Au cours de l'étape H30, le bloc PDP interroge la zone de stockage de la politique de T2 pour vérifier si U3 a le rôle d'administrateur Admin et si ce rôle Admin possède l'autorisation : Permission(T2 , Admin, manage, X Assignment , default context) Au cours des étapes H40 à H60, le bloc de décision PDP interroge le module VRH de vérification de relations hiérarchiques pour vérifier si T2 domine T1 (dans cet exemple, la relation de domination est restreinte à l'attribution des rôles). Au cours de l'étape H70, le bloc de décision PDP renvoie une réponse positive au bloc d'administration PAP. Au cours de l'étape H80, le bloc d'administration PAP effectue une habilitation inter-locataire pour l'utilisateur U3 : Empower (T1, U2, DEV). Le procédé selon l'invention peut aussi être par exemple être mis en oeuvre par un ordinateur tel que représenté à la figure 4. Cet ordinateur 100 comporte un processeur 110, une mémoire morte de type RAM 112, une mémoire morte de type ROM 114 et des moyens de communication 116. La mémoire morte de type ROM constitue un support d'enregistrement au sens de l'invention. Elle mémorise un programme d'ordinateur PG conforme à l'invention dont l'exécution par le processeur 110 permet la mise en oeuvre des étapes représentées à la figure 5 : définition (K10) d'une hiérarchie entre les locataires de l'organisation ; sur réception (K20) d'une demande RQ émise par l'administrateur d'un premier locataire pour accéder à la politique de sécurité d'un deuxième locataire, comparaison (K30) des niveaux hiérarchiques des locataires ; autorisation (K40) d'accès si le premier locataire domine le deuxième locataire ; refus de l'accès (K50) si le deuxième locataire domine le premier locataire. REVENDICATIONS1. Procédé de gestion des politiques de sécurité d'une pluralité de locataires appartenant à un même nuage, ledit procédé comportant : une étape (G20) pour définir une hiérarchie entre lesdits locataires ; une étape (H70) pour autoriser tout administrateur de la politique de sécurité d'un quelconque desdits locataires, à accéder à la politique de sécurité des locataires de niveau hiérarchique inférieur au niveau hiérarchique dudit locataire; et une étape pour interdire à tout administrateur de la politique de sécurité d'un quelconque desdits locataires, d'accéder à la politique de sécurité des locataires de niveau hiérarchique supérieur au niveau hiérarchique dudit locataire. 2. Procédé de gestion selon la revendication 1, caractérisée en ce que ladite hiérarchie est : - complète si l'administrateur du locataire de niveau hiérarchique supérieur peut administrer entièrement le locataire de niveau hiérarchique inférieur; ou - restreinte si l'administrateur du locataire de niveau hiérarchique supérieur possède un nombre limité de prérogatives pour administrer le locataire de niveau hiérarchique inférieur. 3. Système de gestion des politiques de sécurité d'une pluralité de locataires appartenant à un même nuage, ledit système comportant : un module pour définir une hiérarchie entre lesdits locataires ; un module de décision apte à autoriser tout administrateur de la politique de sécurité d'un quelconque desdits locataires, à accéder à la politique de sécurité des locataires de niveau hiérarchique inférieur au niveau hiérarchique dudit locataire; et à interdire à tout administrateur de la politique de sécurité d'un quelconque desdits locataires, d'accéder à la politique de sécurité des locataires de niveau hiérarchique supérieur au niveau hiérarchique dudit locataire. 4. Système de gestion selon la revendication 3, caractérisé en ce qu'il comporte : un bloc d'administration PAP comportant ledit module de définition ; - un bloc de décision PDP comportant ledit module de décision, lesdits blocs PAP, PDP étant conformes à l'architecture de référence XACML (eXtensible Access Control Markup Language) utilisée par le modèle de contrôle d'accès OrBAC. 5. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de gestion des politiques de sécurité selon l'une quelconque des revendications 1 à 2, lorsque ledit programme est exécuté par un ordinateur. 6. Support d'enregistrement (114) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG) comprenant des instructions pour l'exécution des étapes du procédé de gestion des politiques de sécurité selon l'une quelconque des revendications 1 à 2.