FR3007865A1 - Systeme et procede de controle d'acces a un ensemble de ressources d'un systeme informatique en nuage - Google Patents

Abstract

Ce procédé de contrôle d'accès à un ensemble de ressources d'un système informatique en nuage (1) comporte : - une étape (E10) pour définir de façon centralisée une politique de contrôle d'accès à haut niveau (HLP) pour ledit nuage ; - une étape (E20) de traduction de ladite politique (HLP) en une pluralité de politiques de contrôle d'accès de bas niveau (LLPi), chacune étant définie pour un domaine de contrôle d'accès (DACi) apte à contrôler l'accès à au moins une desdites ressources; - une étape (E30, E52) de distribution d'au moins une politique de contrôle d'accès de bas niveau (LLPi) au domaine de contrôle d'accès (DACi) pour laquelle elle a été définie ; - une étape (E40, E54) de génération d'un ensemble (RULi) de règles traduisant ladite politique de contrôle d'accès de bas niveau (LLPi), lesdites règles étant interprétables par ledit domaine (DACi) ; et - sur réception (E50) d'une requête d'accès à une ressource, une étape (E60) de contrôle d'accès à ladite ressource par le domaine d'accès (DACi) contrôlant l'accès à ladite ressource.

Description

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 et réseaux 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 telles 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 par exemple 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étail 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 (RoleBased 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 permettent 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 appliquées. L'IETF (Internet Engineering Task Force) a défini une architecture de référence XACML (eXtensible Access Control Markup Language) qui peut être utilisée par le modèle de contrôle d'accès OrBAC, pour l'implémentation du contrôle d'accès dans les systèmes d'information. Cette architecture XACML se base en effet, de façon connue en soi, sur cinq types de blocs fonctionnels, à savoir : un bloc chargé d'appliquer une politique de contrôle d'accès, ou bloc PEP (Policy Enforcement Point) ; un bloc chargé de prendre une décision en matière d'accès, ou bloc PDP (Policy Decision Point) ; un répertoire contenant les politiques de contrôle d'accès (Policy Repository) ; un bloc chargé de la gestion des informations en relation avec les politiques d'accès, ou bloc PIP (Policy Information Point) ; et un bloc responsable de l'administration des politiques d'accès, ou bloc PAP (Policy Administration Point), qui spécifie et gère les politiques d'accès. D'une façon générale, l'implémentation pratique de cette architecture XACML dans un nuage pose un certain nombre de difficultés. En premier lieu, il est très difficile pour un administrateur de définir précisément la politique de contrôle d'accès à chacune des ressources, en raison notamment de l'hétérogénéité des ressources et de leur caractère changeant. Par ailleurs, il est important de veiller à limiter le trafic nécessaire au contrôle d'accès lui-même, ce trafic pouvant être important, notamment pour la mise à jour du bloc PIP, dès lors que ce dernier se trouve relativement éloigné des différentes ressources.

Il existe donc un besoin pour un système de contrôle d'accès aux ressources d'un système informatique en nuage simple à administrer et dans lequel le trafic induit par le contrôle lui-même est relativement limité. Objet et résumé de l'invention L'invention répond notamment à ce besoin en proposant un procédé de contrôle d'accès à un ensemble de ressources d'un système informatique en nuage. Ce procédé comprend : une étape pour définir de façon centralisée une politique de contrôle d'accès à haut niveau pour le nuage ; une étape de traduction de cette politique en une pluralité de politiques de contrôle d'accès de bas niveau, chacune étant définie pour un domaine de contrôle d'accès apte à contrôler l'accès à au moins une desdites ressources; une étape de distribution d'au moins une politique de contrôle d'accès de bas niveau au domaine de contrôle d'accès pour laquelle elle a été définie ; une étape de génération d'un ensemble de règles traduisant cette politique de contrôle d'accès de bas niveau, ces règles étant interprétables par le domaine de contrôle d'accès ; et sur réception d'une requête d'accès à une ressource, une étape de contrôle d'accès à cette ressource par le domaine de contrôle d'accès contrôlant l'accès à cette ressource. Corrélativement, l'invention vise un système de contrôle d'accès à un ensemble de ressources d'un système informatique en nuage, ce système comprenant : un module centralisé comportant des moyens pour définir de manière centralisée une politique de contrôle d'accès à haut niveau pour le nuage et des moyens de traduction de cette politique en une pluralité de politiques de contrôle d'accès de bas niveau, chacune étant définie pour un domaine de contrôle d'accès apte à contrôler l'accès à au moins une de ces ressources, et des moyens de distribution d'au moins une politique de contrôle d'accès de bas niveau au domaine de contrôle d'accès pour laquelle cette politique a été définie ; ledit au moins un domaine de contrôle d'accès, ce domaine comportant des moyens de génération d'un ensemble de règles traduisant la politique de contrôle d'accès de bas niveau, ces règles étant interprétables par le domaine de contrôle d'accès, des moyens de réception d'une requête d'accès à une ressource et des moyens pour contrôle d'accès à ladite ressource. Ainsi, et d'une façon générale, l'invention propose un mécanisme de contrôle d'accès qui présente à la fois les avantages des mécanismes centralisés et des mécanismes distribués.

Plus précisément, l'invention permet ainsi à l'administrateur de définir de façon centralisée une politique de contrôle d'accès de haut niveau, cette politique étant traduite en politiques de bas niveau distribuées aux différents domaines de contrôle d'accès. De façon très avantageuse, l'administrateur n'a pas besoin de connaître les politiques de bas niveau de chacun des domaines dans leurs détails.

Par ailleurs, la mise en oeuvre du contrôle d'accès étant in fine distribuée dans les différents domaines de contrôle d'accès, celle-ci n'est pas affectée par une panne ou tout problème impactant le module central. Le système selon l'invention est donc plus robuste qu'un système totalement centralisé. De plus, chaque domaine de contrôle d'accès gère localement les informations en relation avec les politiques d'accès à son domaine de sorte que l'on diminue le flot d'informations échangées dans le nuage pour assurer le contrôle. Dans un mode particulier de réalisation, la politique de contrôle d'accès de bas niveau est distribuée spontanément par le module centralisé au domaine de contrôle d'accès, sans que celui-ci n'émette de demande à cet effet.

Dans un mode particulier de réalisation, la politique de contrôle d'accès de bas niveau est distribuée par le module centralisé au domaine de contrôle d'accès, sur demande de ce dernier, pour répondre à la requête d'accès à la ressource, émise par l'utilisateur. Ce mécanisme de distribution en mode pull augmente la sécurité du système puisque seule une petite partie de la politique de contrôle d'accès est stockée dans le nuage. Ainsi, une attaque visant le nuage ne peut permettre d'appréhender la politique de sécurité dans son ensemble. Dans un mode particulier de réalisation de l'invention, le domaine de contrôle d'accès est conforme à 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 ; le domaine de contrôle d'accès comporte : un bloc d'administration apte à recevoir la politique de contrôle d'accès de bas niveau en provenance du module centralisé et à générer les règles ; un bloc PEP apte à appliquer la politique de contrôle d'accès de bas niveau ; un bloc PDP apte à prendre une décision en matière d'accès ; un répertoire LPR contenant la politique de contrôle d'accès de bas niveau ; et un bloc PIP apte à gérer les informations en relation avec la politique de contrôle d'accès de bas niveau. Dans un mode particulier de réalisation, les politiques de contrôle d'accès de haut niveau et de bas niveau sont définies, comme dans la représentation OrBAC, pour un triplet (abstraction de sujet, abstraction d'action, abstraction d'objet) et le domaine de contrôle d'accès utilise une table d'abstraction de sujets, une table d'abstraction d'actions et une table d'abstraction d'objets pour traduire la politique de contrôle d'accès de bas niveau en ensemble de règles. Dans un mode particulier de réalisation, les différentes étapes du procédé de contrôle d'accès sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise un programme d'ordinateur sur un support d'informations, ce programme comportant des instructions pour l'exécution desdites étapes de définition, de traduction et de distribution d'un procédé de contrôle d'accès tel que mentionné ci-dessus, lorsque ces instructions sont exécutées par un module centralisé d'un système de contrôle d'accès tel que mentionné ci-dessus. L'invention vise aussi un programme d'ordinateur sur un support d'informations comportant des instructions pour l'exécution desdites étapes de génération de règles, de réception d'une requête d'accès et de contrôle d'accès, d'un procédé de contrôle d'accès tel que mentionné ci-dessus lorsque ces instructions sont exécutées par un domaine de contrôle d'accès d'un système de contrôle d'accès tel que mentionné ci-dessus. Ces programmes peuvent 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 eut ê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 la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : - la figure 1 représente, de façon schématique, un système de contrôle d'accès conforme à l'invention, dans un mode particulier de réalisation ; - la figure 2 illustre, sous forme d'organigramme, les principales étapes d'un procédé de contrôle d'accès conforme à un mode particulier de réalisation de l'invention.

Description détaillée de l'invention La figure 1 représente de façon schématique un système 10 de contrôle d'accès conforme à l'invention. Ce système de contrôle l'accès à des ressources informatiques et réseaux est mis à la disposition d'utilisateurs 3 par un système informatique en nuage 1, cet ensemble de ressources étant susceptible de varier dans le temps. On suppose que les utilisateurs 3 sont équipés de terminaux informatiques leur permettant d'accéder aux ressources et de les exploiter. Ces ressources concernent notamment des ressources virtuelles telles que de la puissance de calcul, des ressources de stockage, des services de connectivité réseau comme des VLAN ou des pare-feu, des ressources physiques comme des disques et des serveurs, des ressources informatiques et réseaux, telles que des ressources logicielles ou applicatives de type SaaS. Ce système comporte un module central 20 de gestion de la politique de contrôle d'accès de haut niveau HLP pour l'ensemble du nuage comportant une pluralité de domaines de contrôle d'accès DACi, chacun étant apte à gérer la politique de contrôle d'accès de bas niveau LLPi au sein de son domaine. On rappelle qu'au sens de l'invention, un domaine de contrôle d'accès désigne un système, un service ou une application apte à autoriser l'accès à une ressource informatique ou réseau.

Dans l'exemple de réalisation décrit ici, le nuage 1 comporte trois domaines de contrôle d'accès DACi définis respectivement pour un service de stockage, un service réseau, et un service de type SaaS (Software as a Service). On notera que dans l'exemple de réalisation décrit ici le module 20 de gestion de la politique de contrôle d'accès de haut niveau HLP n'est pas implémenté dans le nuage 1 lui-même mais sous la forme d'un service extérieur appelé par les différentes plateformes du nuage. En variante, le module 20 pourrait faire partie du nuage 1. Dans le mode de réalisation décrit ici, le module 20 comporte un module d'administration centralisé PAP permettant à un administrateur 4 de définir la politique de contrôle d'accès de haut niveau HLP, un répertoire centralisé de politiques CPR (Central Policy Repository en anglais) dans lequel sont stockées les politiques de haut niveau crées par le module PAP, et un traducteur TRAD apte à traduire les politiques de contrôle d'accès de haut niveau HLP en politiques de contrôle d'accès de bas niveau LLPi des domaines DACi, et un module de distribution DIST apte à fournir les politiques de contrôle d'accès de bas niveau LLPi aux différents domaines de contrôle d'accès DACi. Cette distribution peut se faire : - soit en mode push, dans lequel les politiques de contrôle d'accès de bas niveau sont envoyées spontanément du module 20 aux domaines de contrôle d'accès DACi ; - soit en mode pull, dans lequel les domaines de contrôle d'accès DACi demandent les politiques de contrôle d'accès de bas niveau au module 20 en fonction des requêtes de contrôle d'accès que ces domaines DACi ont à traiter ; - soit en mode mixte, certaines politiques de contrôle d'accès étant distribuées en mode push, les autres en mode pull.

Dans le mode de réalisation décrit ici, le module d'administration centralisé PAP est apte à fournir à l'administrateur une abstraction des utilisateurs, des actions et des objets des plateformes du nuage, maintenue à jour par un mécanisme de synchronisation. Dans le mode de réalisation décrit ici, le traducteur TRAD comporte un module PARSE d'analyse grammaticale apte à traduire une politique de contrôle d'accès de haut niveau HLP en données structurées et à fournir ces données à un module MAP apte à définir les politiques de contrôle d'accès de bas niveau LLPi pour chacun des domaines de contrôle d'accès DACi à partir d'un profil PROFi associé à chacun de ces domaines de contrôle d'accès DAC. Dans le mode de réalisation décrit ici, chaque domaine de contrôle d'accès DACi comporte un module d'administration local LPAP (Local Policy Administration Point) apte à recevoir les politiques de contrôle d'accès de bas niveau LLPi fournies par le module de distribution DIST du module 20 et à les stocker dans un répertoire LPR, ce module d'administration locale LPAP étant en outre apte à traduire une politiques de contrôle d'accès de bas niveau LLPi en un ensemble de règles RULi. Dans le mode de réalisation décrit ici, le module d'administration locale LPAP utilise, aux fins de traduction, une table d'abstraction de sujets TS, une table d'abstraction d'actions TA, et une table d'abstraction d'objets TO, de manière à traduire chaque politique de contrôle d'accès de bas niveau LLPi en un ensemble de règles RULi, ces règles étant stockées dans un répertoire de règles RULE_REP. Par ailleurs, et conformément à l'architecture XACML déjà décrite, chaque domaine de contrôle d'accès DACi comporte : un bloc chargé d'appliquer une politique de contrôle d'accès, ou bloc PEP (Policy Enforcement Point) ; un bloc chargé de prendre une décision en matière d'accès, ou bloc PDP (Policy Decision Point) ; et un bloc chargé de la gestion des informations en relation avec les politiques d'accès, ou bloc PIP (Policy Information Point). La figure 2 représente, sous forme d'organigramme les principales étapes d'un procédé de contrôle d'accès conforme à l'invention.

Conformément à l'invention, l'administrateur définit, au cours d'une étape E10, une politique de contrôle d'accès de haut niveau HLP pour le système en nuage. La politique de contrôle d'accès de haut niveau HLP est interprétable par un utilisateur et décrit d'une façon générale comment les accès doivent être contrôlés dans le nuage.

Dans le mode de réalisation décrit ici, les politiques de contrôle d'accès de haut niveau selon l'invention sont définies conformément à la représentation utilisée dans le modèle OrBAC, chaque politique étant définie pour un triplet (abstraction de sujet, abstraction d'action, abstraction d'objet). Par exemple, la politique Permission(Manager, Lecture, Ressources Sécurité Faible) signifie que les sujets de type « Manager » sont autorisés à lire les ressources étiquetées avec un niveau de sécurité faible. Conformément à l'invention, toute politique de contrôle d'accès de haut niveau HLP est traduite, au cours d'une étape E20, en une pluralité de politiques de contrôle d'accès de bas niveau LLPi, chacune étant associée à un domaine de contrôle d'accès DAC pour définir les contrôles d'accès à ce domaine.

A cet effet, le traducteur TRAD du module 20 utilise les profils PROFi associés aux domaines de contrôle d'accès DACi , ces profils décrivant la sémantique permettant de traduire les politiques de haut niveau de contrôle d'accès HLP de ce domaine en politiques de contrôle d'accès bas niveau LLPi des différents domaines. Dans le mode de réalisation décrit ici, les politiques de contrôle d'accès de bas niveau LLPi sont également définies pour un triplet (abstraction de sujet, abstraction d'action, abstraction d'objet). Par exemple, la politique Permission(Manager, SSH, Instances Sécurité Faible) signifie que les sujets de type « Manager » sont autorisés à effectuer une action de type SSH sur les instances étiquetées avec un niveau de sécurité faible. Dans le mécanisme de distribution en mode push, les politiques de contrôle d'accès de bas niveau sont distribuées aux différents domaines DACi au cours d'une étape E30. Conformément à l'invention, pour chaque domaine de contrôle d'accès, chaque politique de contrôle d'accès de bas niveau LLPi est interprétée par le module LPAP d'un domaine DACi, au cours d'une étape E40, pour fournir un ensemble de règles RULi interprétables par un ordinateur, chaque règle définissant, pour un triplet (sujet, action, objet) de ce domaine, si un sujet peut effectuer une action sur un objet. Le domaine DACi mémorise la politique de contrôle d'accès de bas niveau LLPi dans le répertoire LPR et les règles dans le répertoire RULE_REP. Par exemple, la règle de bas niveau Permission(Manager, Network Access, Instances Sécurité Faible) peut être traduite en quatre règles Permission(Manager John, SSH, Instance A), Permission(Manager John, SSH, Instance B), Permission(Manager Lily, SSH, Instance A), Permission(Manager Lily, SSH, Instance B), les sujets John et Lily étant tous les deux identifiés à partir de la table d'abstraction de sujets TS, Instance_A et Instance_B étant deux instances étiquetées avec une sécurité basse, identifiées à partir de la table d'abstraction d'objets TO. Dans cet exemple, la règle Permission(Manager John, SSH, Instance A) signifie que le sujet Manager _John est autorisé à effectuer une action de type Network Access sur l'instance Instance_A. Conformément à l'invention, la politique de contrôle d'accès est gérée localement dans chacun des domaines DACi, toute requête reçue d'un utilisateur (étape E50) étant évaluée par le bloc PEP du domaine de contrôle d'accès DACi en charge d'appliquer la politique de contrôle d'accès de ce domaine (étape E60).

A cet effet, lorsque le système de distribution selon l'invention est en mode pull, si la politique de contrôle d'accès de bas niveau nécessaire au traitement de cette requête n'est pas stockée dans le répertoire LPR, le module PEP requiert l'obtention d'une politique de contrôle de bas niveau auprès du module 20 (étape E52), la traduit en règles (étapes E54), utilise ces règles pour traiter la requête, et mémorise la politique dans le répertoire LPR et les règles dans le répertoire RULE_REP.

Claims (10)

1. REVENDICATIONS1. Procédé de contrôle d'accès à un ensemble de ressources d'un système informatique en nuage (1), ce procédé comprenant : une étape (E10) pour définir de façon centralisée une politique de contrôle d'accès à haut niveau (HLP) pour ledit nuage ; une étape (E20) de traduction de ladite politique (HLP) en une pluralité de politiques de contrôle d'accès de bas niveau (LLPi), chacune étant définie pour un domaine de contrôle d'accès (DACi) apte à contrôler l'accès à au moins une desdites ressources; une étape (E30, E52) de distribution d'au moins une politique de contrôle d'accès de bas niveau (LLPi) au domaine de contrôle d'accès (DACi) pour laquelle elle a été définie ; une étape (E40, E54) de génération d'un ensemble (RULi) de règles traduisant ladite politique de contrôle d'accès de bas niveau (LLPi), lesdites règles étant interprétables par ledit domaine (DACi) ; et sur réception (E50) d'une requête d'accès à une ressource, une étape (E60) de contrôle d'accès à ladite ressource par le domaine de contrôle d'accès (DACi) contrôlant l'accès à ladite ressource.
2. 2. Procédé selon la revendication 1 caractérisé en ce que ladite politique de contrôle d'accès de bas niveau est distribuée spontanément (E30) audit domaine (DACi) de contrôle d'accès, sans que celui-ci, n'émette de demande à cet effet.
3. 3. Procédé selon la revendication 1 caractérisé en ce que ladite politique de contrôle d'accès de bas niveau (LLPi) est distribuée (E52) audit domaine (DACi) de contrôle d'accès, sur demande de ce dernier, pour répondre à ladite requête d'accès.
4. 4. Système de contrôle d'accès à un ensemble de ressources d'un système informatique en nuage (1), ce système comprenant : un module centralisé (20) comportant des moyens (PAP) pour définir de manière centralisée une politique de contrôle d'accès à haut niveau (HLP) pour ledit nuage et des moyens (TRAD) de traduction de ladite politique (HLP) en une pluralité de politiques de contrôle d'accès de bas niveau (LLPi), chacune étant définie pour un domaine de contrôle d'accès (DACi) apte à contrôler l'accès à au moins une desdites ressources, et des moyens (DIST) de distribution d'au moins une politique de contrôle d'accès de bas niveau (LLPi) au domaine de contrôle d'accès (DACi) pour laquelle ladite politique a été définie ; ledit au moins un domaine de contrôle d'accès (DACi), ce domaine comportant des moyens (LPAP) de génération d'un ensemble (RULi) de règles traduisant ladite politique de contrôled'accès de bas niveau (LLPi), lesdites règles étant interprétables par ledit domaine (DACi), des moyens (COM) de réception (E50) d'une requête d'accès à une ressource, et des moyens (PEP) pour contrôle d'accès à ladite ressource.
5. 5. Système de contrôle d'accès selon la revendication 4, caractérisé en ce que ledit domaine de contrôle d'accès (DACi) est conforme à 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, ledit domaine de contrôle d'accès comportant : un bloc d'administration (LPAP) apte à recevoir ladite politique de contrôle d'accès de bas niveau en provenance du module centralisé (20) et à générer lesdites règles (RULi) ; un bloc (PEP) apte à appliquer ladite politique de contrôle d'accès de bas niveau (LLPi) ; un bloc (PDP) apte à prendre une décision en matière d'accès ; un répertoire (LPR) contenant ladite politique de contrôle d'accès de bas niveau (LLPi) ; et un bloc (PIP) apte à gérer les informations en relation avec ladite politique de contrôle d'accès (LLPi).
6. 6. Système de contrôle d'accès selon la revendication 4 ou 5, caractérisé en ce que lesdites politiques de contrôle d'accès de haut niveau (HLP) et de bas niveau (LLPi) sont définies pour un triplet (abstraction de sujet, abstraction d'action, abstraction d'objet) et en ce que ledit domaine de contrôle d'accès (DACi) utilise une table d'abstraction de sujets (TS), une table d'abstraction d'actions (TA) et une table d'abstraction d'objets (TO) pour traduire ladite politique de contrôle d'accès de bas niveau (LLPi) en ledit ensemble de règles (RULi).
7. 7. Programme d'ordinateur comportant des instructions pour l'exécution desdites étapes (E10) de définition, (E20) de traduction et (E30, E52) de distribution d'un procédé selon l'une quelconque des revendications 1 à 3 lorsque ces instructions sont exécutées par un module centralisé d'un système conforme à l'une quelconque des revendications 4 à 6.
8. 8. Programme d'ordinateur comportant des instructions pour l'exécution desdites étapes (E40) de génération de règles, (E50) de réception d'une requête d'accès et (E60) de contrôle d'accès d'un procédé selon l'une quelconque des revendications 1 à 3 lorsque ces instructions sont exécutées par un domaine de contrôle d'accès (DACi) d'un système conforme à l'une quelconque des revendications 4 à 6.
9. 9. Support d'enregistrement lisible par un module centralisé (20) d'un système conforme à l'une quelconque des revendications 4 à 6 sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution desdites étapes (E10) de définition,(E20) de traduction et (E30, E52) de distribution d'un procédé selon l'une quelconque des revendications 1 à 3.
10. 10. Support d'enregistrement lisible par un domaine de contrôle d'accès (DACi) d'un système conforme à l'une quelconque des revendications 4 à 6 sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution desdites étapes (E40) de génération de règles, (E50) de réception d'une requête d'accès et (E60) de contrôle d'accès d'un procédé selon l'une quelconque des revendications 1 à 3.10