Arrière-plan de rinvention

L'invention se rapporte au domaine général des systèmes informatiques, 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 le contrôle de l'accès par un utilisateur d'une entité cliente du système de cloud Computing (aussi désignée plus simplement par « client » dans la description), via un terminal par exemple, à des ressources informatiques et réseaux mises à la disposition de cette entité cliente par un système de cloud Computing. Par entité cliente ou client du système de cloud Computing, on entend ici un système d'information (ex. système informatique d'une organisation ou d'une entreprise, application, etc.), locataire des ressources mises à disposition par le système de cloud Computing (aussi appelé « tenant » en anglais).

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, ou plus généralement à des clients, d'accéder via un réseau, à la demande et en libre- service, à des ressources informatiques et réseaux telles que par exemple un espace de stockage, de la puissance de calcul, des applications, un accès réseau, des logiciels ou encore des services, qui sont virtualisées (i.e. rendues virtuelles) et mutualisées entre ces clients. Autrement dit, les ressources informatiques ne se trouvent plus sur un serveur local ou sur un poste d'utilisateur, mais sont, conformément au concept de cloud Computing, dématérialisées dans un nuage composé de plusieurs serveurs physiquement distants interconnectés entre eux, et accessibles par les clients et leurs utilisateurs via par exemple une application réseau. Les clients et plus particulièrement leurs 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 Télécommunication 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 de garantir la protection et la sécurisation de l'accès aux ressources, ces ressources étant en effet partagées par plusieurs clients distincts et hétérogènes du système de cloud Computing. On dit également du système de cloud Computing qu'il est multi-entités ou « multi-tenant » en anglais.

Pour garantir la sécurité d'un système informatique en nuage, il est nécessaire de définir, pour chaque client du système informatique en nuage, un modèle de contrôle d'accès et une politique de contrôle d'accès s'appuyant sur ce modèle pour ses utilisateurs et pour les ressources qui lui sont allouées dynamiquement et virtuellement. Une politique de contrôle d'accès est un ensemble de règles qui permet de réguler l'accès des utilisateurs aux ressources du client. Par exemple, une telle politique de contrôle d'accès spécifie via un ensemble de règles les droits des utilisateurs pour accéder à différents fichiers du client stockés sur un disque ; ces règles peuvent indiquer à titre illustratif que l'utilisateur Bob a des droits en lecture sur un fichier Fl.h et que l'utilisateur Alice a des droits en écriture sur un fichier F2.c. Cette politique de contrôle d'accès s'appuie sur un modèle de contrôle d'accès qui définit la façon dont la décision d'autoriser ou non l'accès à la ressource est prise.

Il existe dans l'état de la technique, de nombreux modèles de contrôle d'accès qui permettent d'encadrer l'usage des ressources d'un client : ces modèles sont généralement conçus pour vérifier si une entité active (aussi désigné par sujet) telle un utilisateur via un terminal, peut accéder à une entité passive (aussi désignée par objet) telle une ressource informatique et réseau, en effectuant une opération donnée (aussi désignée par action), et le cas échéant, autoriser l'accès à l'entité passive par l'entité active via ladite opération. Des modèles de contrôle d'accès connus plus ou moins complexes sont par exemple les modèles RBAC (Role-Based Access Control), OrBAC (Organization-Based Access Control), ou encore MLS (MultiLevel Security).

Ces modèles ont été conçus à la base pour gérer le contrôle d'accès dans un système informatique associé à une même entité. Les systèmes informatiques en nuage s'appuient aujourd'hui sur ces modèles, mais en sélectionnent un unique qu'ils imposent de manière uniforme à chacun de leurs clients. En d'autres mots, tous les clients d'un système informatique en nuage définissent leurs politiques de contrôle d'accès en s'appuyant sur le même modèle de contrôle d'accès choisi par l'opérateur du système informatique en nuage, comme par exemple sur le modèle OrBAC ou sur le modèle RBAC.

Une configuration aussi rigide n'est de toute évidence pas bien adaptée au paysage actuel des systèmes d'information et des télécommunications qui promeut l'avènement de multiples acteurs et applications amenés à partager des ressources informatiques et réseaux via des systèmes informatiques en nuage, ces acteurs et applications multiples ayant des besoins distincts en matière de politiques de sécurité et plus particulièrement de politiques de contrôle d'accès. Objet et résumé de l'invention

L'invention permet de remédier notamment à cet inconvénient en proposant un procédé de gestion d'un système informatique en nuage, apte à allouer à une pluralité de clients des ressources informatiques et réseaux, chaque client étant associé à au moins un utilisateur susceptible d'accéder aux ressources informatiques et réseaux allouées au client par le système informatique en nuage, ledit procédé comprenant, pour au moins un client du système informatique en nuage :

— une étape de fourniture, audit client, d'un méta-modèle comprenant une pluralité d'éléments permettant de définir un modèle de contrôle d'accès et une politique de contrôle d'accès pour le client ;

— une étape de réception d'une instance du méta-modèle fournie par le client, ladite instance définissant pour ledit client un modèle de contrôle d'accès et une politique de contrôle d'accès basée sur ce modèle de contrôle d'accès ; et

— une étape d'application de ladite politique de contrôle d'accès pour contrôler un accès d'un utilisateur du client à au moins une ressource allouée au client par le système informatique en nuage.

Corrélativement, l'invention vise aussi un système informatique en nuage apte à allouer à une pluralité de clients des ressources informatiques et réseaux, chaque client étant associé à au moins un utilisateur susceptible d'accéder aux ressources informatiques et réseaux allouées au client par le système informatique en nuage, ledit système comprenant :

— un module de fourniture, configuré pour fournir à au moins un client du système informatique en nuage un méta-modèle comprenant une pluralité d'éléments permettant de définir un modèle de contrôle d'accès et une politique de contrôle d'accès pour le client ;

— un module de réception, apte à recevoir une instance du méta-modèle fournie par le client, ladite instance définissant pour ledit client un modèle de contrôle d'accès et une politique de contrôle d'accès basée sur ce modèle de contrôle d'accès ; et

— un module de sécurité configuré pour appliquer ladite politique de contrôle d'accès pour contrôler un accès d'un utilisateur du client à au moins une ressource allouée au client par le système informatique en nuage.

L'invention propose donc, qu'au lieu d'imposer un même modèle de contrôle d'accès à tous ses clients, le système informatique en nuage leur fournisse un méta-modèle prédéfini permettant à chacun des clients du système informatique en nuage de créer son propre modèle de contrôle d'accès et de baser sa politique de contrôle d'accès sur le modèle ainsi créé.

Ce nouveau paradigme en matière de contrôle d'accès dans un contexte de cloud Computing est particulièrement flexible et permet à chaque client de définir avec plus de liberté une politique de contrôle d'accès qui lui est propre et s'adapte à ses spécificités et à ses besoins en matière de sécurité. Cette définition est faite à la volée (autrement dit de manière dynamique) par le client à partir du méta-modèle fourni par le système informatique en nuage : le méta-modèle définit de manière générique un certain nombre d'éléments permettant de créer un modèle de contrôle d'accès et de spécifier une politique de contrôle d'accès s'appuyant sur ce modèle, que le client vient instancier auprès du système informatique en nuage (autrement dit, il vient renseigner les éléments du méta-modèle pour créer le modèle de contrôle d'accès sur lequel il souhaite baser sa politique de contrôle d'accès).

Ainsi, au lieu de protéger le système informatique en nuage comme un tout via un unique modèle de contrôle d'accès, l'invention permet de limiter et d'adapter l'étendue de la protection à chaque client. Chaque client peut avoir un contrôle personnalisé de l'accès aux ressources qui lui sont allouées dynamiquement et virtuellement par le système informatique en nuage.

On note que cette façon de gérer le contrôle de l'accès aux ressources au niveau du système informatique en nuage est particulièrement bien adaptée au caractère évolutif des ressources et des clients au sein d'un système informatique en nuage. De même qu'un modèle et une politique de contrôle d'accès peuvent être créés à la volée pour un client du système informatique en nuage, ceux-ci peuvent être supprimés à la volée dès lors que ce client n'est plus servi par le système informatique en nuage.

Le nouveau paradigme proposé par l'invention est donc flexible, dynamique, adaptatif et évolutif.

Si l'invention permet de définir une pluralité de modèles et de politiques de contrôle d'accès distincts pour chacun des clients du système informatique en nuage, elle s'appuie néanmoins sur un méta-modèle unique commun à tous les clients, et un contrôle d'accès aux ressources réalisé de façon centralisée par le système informatique en nuage. Ceci permet d'assurer la consistance du contrôle d'accès aux ressources fournies par le système informatique en nuage mis en œuvre et renforce son efficacité. En outre, si les ressources allouées à un client se trouvent distribuées sur une pluralité de centres de données (« data center ») distincts, la même politique de contrôle d'accès est alors appliquée par chacun des centres de données.

Il convient de noter que les clients d'un système informatique en nuage peuvent, via le méta-modèle fourni par le système informatique en nuage, baser leur politique de contrôle d'accès sur un modèle de contrôle d'accès connu. Ainsi, dans un mode particulier de réalisation de l'invention, l'instance du méta-modèle fournie par le client définit un modèle de contrôle d'accès de type RBAC, OrBAC, ACL, DTE, ABAC ou MLS.

L'invention permet également de créer de nouveaux modèles de contrôle d'accès, ou d'adapter les modèles de contrôle d'accès existants en introduisant de nouvelles caractéristiques dans ces modèles (ex. ajout de nouvelles entités aux modèles, définition de nouvelles catégories d'attributs associées à ces entités, introduction de notions dans les modèles de contrôle d'accès connus telles que la notion de session, de délégation, de hiérarchie, de contrôle d'usage, etc.), permettant d'intégrer des fonctionnalité avancées et inédites dans le contrôle d'accès réalisé.

A cet effet, comme mentionné précédemment, le méta-modèle proposé par le système informatique en nuage à ses clients comprend avantageusement une pluralité d'éléments permettant de définir le modèle de contrôle d'accès adopté par le client pour sa politique de contrôle d'accès. Dans un mode particulier de réalisation, la pluralité d'éléments du méta-modèle comprend :

— un périmètre du modèle de contrôle d'accès définissant une pluralité d'entités impliquées dans la politique de contrôle d'accès du client. Par exemple, la pluralité d'entités impliquées comprend au moins un sujet, et/ou un objet et/ou une action ;

— des métadonnées définissant pour chaque entité au moins une catégorie d'attributs associée à cette entité ;

— des données définissant des valeurs possibles pour chaque catégorie d'attributs définie par les métadonnées ;

— au moins une métarègle identifiant au moins une catégorie d'attributs définie par les métadonnées et utilisée pour fournir une instruction conforme à la politique de contrôle d'accès du client ;

— au moins une règle de contrôle d'accès basée sur ladite au moins une métarègle et fournissant une instruction conforme à la politique de contrôle d'accès du client ; et

— un ensemble de valeurs assignées par le client à chaque entité définie pour ce client dans le périmètre du modèle de contrôle d'accès, pour chaque catégorie d'attributs associée à cette entité et comprise dans une métarègle, lesdites valeurs assignées étant choisies parmi les données.

Ces différents éléments forment un méta-modèle générique offrant un cadre flexible permettant de créer des modèles de contrôle d'accès et de définir des politiques de contrôle d'accès très diversifiés.

Ainsi selon un autre aspect, l'invention vise également un fichier informatique comprenant des instructions décrivant un méta-modèle comprenant une pluralité d'éléments permettant de définir un modèle de contrôle d'accès et une politique de contrôle d'accès pour un client d'un système informatique en nuage apte à allouer à une pluralité de clients des ressources informatiques et réseaux, ladite pluralité d'éléments du méta-modèle comprenant :

— un périmètre du modèle de contrôle d'accès définissant une pluralité d'entités impliquées dans la politique de contrôle d'accès du client ;

— des métadonnées définissant pour chaque entité au moins une catégorie d'attributs associée à cette entité ;

— des données définissant des valeurs possibles pour chaque catégorie d'attributs définie par les métadonnées ; — au moins une métarègle identifiant au moins une catégorie d'attributs définie par les métadonnées et utilisée pour fournir une instruction conforme à la politique de contrôle d'accès du client ;

— au moins une règle de contrôle d'accès basée sur ladite au moins une métarègle et fournissant une instruction conforme à la politique de contrôle d'accès du client ; et

— un ensemble de valeurs assignées par le client à chaque entité définie pour ce client dans le périmètre du modèle de contrôle d'accès, pour chaque catégorie d'attributs associée à cette entité et comprise dans une métarègle, lesdites valeurs assignées étant choisies parmi les données.

On note que le méta-modèle proposé par l'invention s'appuie dans ce mode particulier de réalisation sur une spécification basée sur la notion d'attributs. La pertinence de cette approche pour décrire de nombreux modèles de contrôle d'accès a été démontrée, les différentes propriétés des entités (sujet, objet ou action) en matière de sécurité pouvant être considérées comme des attributs associés à ces entités.

Ainsi, dans un mode particulier de réalisation, au moins une catégorie d'attributs définie pour une entité est choisie parmi :

— un niveau de sécurité (ex. niveau de sécurité d'un sujet ou d'un objet) ;

— un rôle (ex. rôle d'un sujet) ;

— un type (ex. type d'objet) ;

— un domaine (ex. domaine auquel a accès un sujet).

Dans un mode particulier de réalisation, au moins une instruction fournie par une règle comprend une autorisation ou un refus d'un accès à une ressource déterminée allouée au client par le système informatique en nuage.

Ainsi, l'invention, par l'intermédiaire du méta-modèle proposé au client, permet à celui- ci de définir une politique de contrôle d'accès classique au moyen de règles autorisant ou refusant l'accès à une ressource en fonction des valeurs des attributs associés à une ou plusieurs entités.

Dans un mode particulier de réalisation, l'instance du méta-modèle est fournie par le client via une interface de configuration du système informatique en nuage commune à la pluralité de clients du système informatique en nuage.

Le méta-modèle proposé par le système informatique en nuage étant commun à tous les clients du système informatique en nuage, il peut avantageusement être instancié via une interface de contrôle unifiée pour tous les clients.

Ainsi, au vu de ce qui précède, l'invention s'appuie sur un méta-modèle fourni par un système informatique à ses clients pour définir leurs propres modèles de contrôle d'accès et sur le système informatique à proprement parler apte à fournir un tel méta-modèle. Elle s'appuie également sur le dispositif utilisé par chaque client pour instancier le méta-modèle proposé par le système informatique en nuage et créer par là-même le modèle de contrôle d'accès qu'il souhaite voir appliquer à ses utilisateurs. Selon un autre aspect, l'invention vise donc aussi un procédé d'instanciation par un client d'un système informatique en nuage apte à allouer à une pluralité de clients des ressources informatiques et réseaux, chaque client étant associé à au moins un utilisateur susceptible d'accéder aux ressources informatiques et réseaux allouées au client par le système informatique en nuage, ledit procédé comprenant :

— une étape d'obtention d'un méta-modèle fourni par le système informatique en nuage et comprenant une pluralité d'éléments permettant de définir un modèle de contrôle d'accès et une politique de contrôle d'accès pour le client ;

— une étape d'instanciation du méta-modèle créant une instance définissant pour ledit client un modèle de contrôle d'accès et une politique de contrôle d'accès basée sur ce modèle de contrôle d'accès ; et

— une étape de fourniture de ladite instance au système informatique en nuage.

Corrélativement, elle concerne un dispositif d'un client d'un système informatique en nuage apte à allouer à une pluralité de clients des ressources informatiques et réseaux, chaque client étant associé à au moins un utilisateur susceptible d'accéder aux ressources informatiques et réseaux allouées au client par le système informatique en nuage, ledit dispositif comprenant :

— un module d'obtention, configuré pour obtenir un méta-modèle fourni par le système informatique en nuage et comprenant une pluralité d'éléments permettant de définir un modèle de contrôle d'accès et une politique de contrôle d'accès pour le client ;

— un module d'instanciation du méta-modèle, configuré pour créer une instance du méta-modèle définissant pour ledit client un modèle de contrôle d'accès et une politique de contrôle d'accès basée sur ce modèle de contrôle d'accès ; et

— un module de fourniture, configuré pour fournir ladite instance au système informatique en nuage.

Le procédé d'instanciation et le dispositif du client du système informatique en nuage bénéficient des mêmes avantages cités précédemment que le procédé de gestion et le système informatique en nuage.

Dans un mode particulier de réalisation, les différentes étapes du procédé de gestion et/ou du procédé d'instanciation 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 œuvre dans un système informatique en nuage ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de gestion tel que décrit ci-dessus. L'invention vise également un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un dispositif d'un client d'un système informatique en nuage ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé d'instanciation tel que décrit ci- dessus.

Chacun de ces programmes 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 ou d'enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci- dessus.

Le support d'informations ou d'enregistrement 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 dise) ou un disque dur.

D'autre part, le support d'informations ou d'enregistrement 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 ou d'enregistrement 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.

L'invention vise également un système comprenant :

— un système informatique en nuage selon l'invention, apte à allouer à une pluralité de clients des ressources informatiques et réseaux, chaque client étant associé à au moins un utilisateur susceptible d'accéder aux ressources informatiques et réseaux allouées au client par le système informatique en nuage; et

— une pluralité de dispositifs des clients du système informatique en nuage conformes à l'invention.

On peut également envisager, dans d'autres modes de réalisation, que le procédé de gestion, le procédé d'instanciation, le système informatique en nuage, le dispositif d'un client du système informatique en nuage et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.

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 un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : — la figure 1 représente, de façon schématique, un système selon l'invention comprenant un système informatique en nuage et des dispositifs clients du système informatique en nuage, conformes à l'invention ;

— la figure 2A représente l'architecture matérielle sur laquelle s'appuie le système informatique en nuage de la figure 1 ;

— la figure 2B représente différents éléments fonctionnels du système informatique en nuage de la figure 1 configurés pour mettre en œuvre le procédé de gestion selon l'invention ;

— la figure 3A représente l'architecture matérielle des dispositifs clients de la figure 1 ;

— la figure 3B représente différents éléments fonctionnels des dispositifs clients de la figure 1 configurés pour mettre en œuvre le procédé d'instanciation selon l'invention ;

— la figure 4 illustre schématiquement les principaux modules logiciels définis par le standard de référence XACML pour réaliser le contrôle d'accès et mis en œuvre par le système informatique en nuage de la figure 1 ; et

— la figure 5 illustre les principales étapes d'un procédé de gestion selon l'invention tel qu'il est mis en œuvre par le système informatique en nuage de la figure 1, et les principales étapes d'un procédé d'instanciation selon l'invention tel qu'il est mis en œuvre par chaque dispositif client de la figure 1.

Description détaillée de l'invention

La figure 1 représente, dans son environnement, un système 1 conforme à l'invention, dans un mode particulier de réalisation.

Dans ce mode de réalisation, le système 1 comprend :

— un système informatique en nuage 2, conforme à l'invention, et apte à allouer à une pluralité de clients CL1, CL2, CLN, N désignant un entier supérieur à 1, des ressources informatiques et réseaux RESS. Aucune limitation n'est attachée à la nature des ressources informatiques et réseaux RESS ; il peut s'agir par exemple d'espace de stockage, de puissance de calcul, d'applications, de connexions réseaux, de logiciels ou encore de services, qui sont virtualisés et mutualisés entre les clients CL1, CL2,...,CLN du système informatique en nuage 2 ; et

— une pluralité de dispositifs 3-1, 3-2, 3-N, associés respectivement à chacun des clients CL1, CL2, CLN du système informatique en nuage 2 et conformes à l'invention. Ces dispositifs communiquent avec le système informatique en nuage 2 via un ou plusieurs réseaux de télécommunications (non représentés) tels que par exemple un réseau WiFI, WLAN, mobile (3G, 4G, 5G, etc.), le réseau public Internet, etc.

Au sens de l'invention, un client CLn, n=l,...,N du système informatique en nuage désigne tout type de système d'information, locataire de ressources Rn mises à disposition dynamiquement et virtuellement par le système informatique en nuage. Un tel client est également appelé « tenant » en anglais. Il peut s'agir par exemple d'un système informatique (IT) d'une organisation ou d'une entreprise, d'une application logicielle, etc. Ce client CLn dispose, de façon connue en soi, pour accéder aux ressources informatiques et réseaux qui lui sont allouées par le système informatique en nuage 2, d'un compte client enregistré auprès du système informatique en nuage. Ce compte client est protégé par un ou plusieurs paramètres d'authentification (ex. identifiant, mot de passe, etc.) permettant au système informatique en nuage 2 d'identifier le client CLn.

Aucune limitation n'est attachée à la nature des clients du système informatique en nuage 2. Chacun de ces clients comprend un ou plusieurs utilisateurs susceptibles d'accéder, via tout type de dispositifs (ex. via un serveur, un terminal tel qu'un ordinateur, un téléphone intelligent (smartphone) ou une tablette numérique, etc.) aux ressources informatiques et réseaux allouées aux clients par le système informatique en nuage 2.

Conformément à l'invention, le contrôle d'accès aux ressources allouées par le système informatique en nuage 2 aux clients CL1, CL2, CLN est assuré par le système informatique en nuage 2. A cet effet, le système informatique en nuage 2 a l'architecture matérielle d'un ordinateur, telle que représentée à la figure 2A. Il comprend notamment un processeur 4, une mémoire morte 5, une mémoire vive 6, une mémoire non volatile 7, ainsi que des moyens de communication 8 avec notamment les dispositifs 3-1, 3-2,...,3-N. Ces moyens de communication 8 intègrent par exemple ici une carte réseau, connue en soi et non détaillée ici, ou tout autre moyen permettant de communiquer sur un réseau de télécommunications. On note que les éléments matériels 4-8 du système informatique en nuage 2 peuvent être localisés sur un unique serveur du système informatique en nuage 2 ou être dispatchés sur plusieurs équipements (ex. plusieurs ordinateurs) du système informatique en nuage 2 communiquant entre eux et ayant chacun l'architecture matérielle illustrée à la figure 2A. Dans le mode de réalisation décrit ici, on suppose que ces éléments matériels sont colocalisés sur un même serveur.

La mémoire morte 5 du système informatique en nuage 2 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 4 et sur lequel est enregistré un programme d'ordinateur PROG1 conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé de gestion conforme à l'invention, décrites ultérieurement en référence à la figure 5 dans un mode particulier de réalisation.

Ce programme d'ordinateur définit, de façon équivalente, des modules fonctionnels du système informatique en nuage 2 qui s'appuient ou commandent les éléments matériels 4-8 du système informatique en nuage 2, et qui comprennent plus précisément, en référence à la figure 2B :

— un module de fourniture 2A, configuré pour fournir aux clients CL1, CLN du système informatique en nuage 2 un méta-modèle META comprenant une pluralité d'éléments permettant à chaque client CLn, n=l,...,N de définir un modèle de contrôle d'accès ACMn et une politique de contrôle d'accès ACPn pour ce client. Le méta-modèle META est décrit sous forme d'instructions dans un fichier informatique FILE stocké ici dans la mémoire non volatile 7 du système informatique en nuage 2 ; — un module de réception 2B, apte à recevoir de chaque client CLn, n=l,...,N une instance du méta-modèle META fournie par le client CLn, cette instance définissant le modèle de contrôle d'accès ACMn et la politique de contrôle d'accès ACPn basée sur ce modèle de contrôle d'accès définies par le client CLn ; et

— un module de sécurité 2C configuré pour appliquer, pour chaque client CLn, la politique de contrôle d'accès ACPn définie par celui-ci pour contrôler un accès d'un utilisateur de ce client à au moins une ressource parmi les ressources Rn qui lui ont été allouées par le système informatique en nuage 2. On note que le module de sécurité 2C peut être dispatché sur un ou plusieurs équipements (ex. centres de données) du système informatique en nuage 2 selon que les ressources Rn allouées au client sont hébergées par un seul ou plusieurs équipements dans le système informatique en nuage 2.

Les modules de fourniture 2A et de réception 2B s'appuient sur une interface dite de contrôle 9 unifiée du système informatique en nuage 2, que celui-ci met à disposition de ses clients pour accéder au méta-modèle META et l'instancier. Une telle interface peut être par exemple une interface de programmation applicative de type API (Application Programming Interface), connue en soi et non décrite en détail ici, qui permet aux clients CLn de manipuler les différents éléments du méta-modèle META fourni par le système informatique 2 et de l'instancier (c'est-à-dire de le renseigner ou encore de le paramétrer ou de le configurer pour créer un modèle de contrôle d'accès et une politique de contrôle d'accès s'appuyant sur ce modèle).

Les fonctions des modules 2A, 2B et 2C sont décrits plus en détail ultérieurement, lors de la description des étapes du procédé de gestion selon l'invention.

Dans le mode de réalisation décrit ici, chaque dispositif 3-n associé à chaque client CLn (aussi appelé dans la description « dispositif client 3-n »), n= l,...,N a également l'architecture matérielle d'un ordinateur, telle que représentée à la figure 3A. Il comprend notamment un processeur 10, une mémoire morte 11, une mémoire vive 12, une mémoire non volatile 13, ainsi que des moyens de communication 14 avec notamment le système informatique en nuage 2. Ces moyens de communication 14 intègrent par exemple ici une carte réseau, connue en soi et non détaillée ici, ou tout autre moyen permettant de communiquer sur un réseau de télécommunications.

La mémoire morte 11 du dispositif 3-n constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 10 et sur lequel est enregistré un programme d'ordinateur PROG2 conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé d'instanciation conforme à l'invention, décrites ultérieurement en référence à la figure 5 dans un mode particulier de réalisation.

Ce programme d'ordinateur définit, de façon équivalente, des modules fonctionnels du dispositif client 3-n qui s'appuient ou commandent les éléments matériels 10-14 du dispositif 3-n, et qui comprennent plus précisément, en référence à la figure 3B : — un module d'obtention 3A, configuré pour obtenir (c'est-à-dire ici accéder via l'interface de contrôle 9) le méta-modèle META fourni par le système informatique en nuage 2 ;

— un module d'instanciation 3B du méta-modèle META, configuré pour créer (générer ou encore construire) une instance du méta-modèle définissant le modèle de contrôle d'accès ACMn et la politique de contrôle d'accès ACPn basée sur ce modèle de contrôle d'accès sélectionnés par le client CLn ; et

— un module de fourniture 3C, configuré pour fournir cette instance (autrement dit pour fournir le modèle de contrôle d'accès ACMn et la politique de contrôle d'accès ACPn) au système informatique en nuage 2, via ici l'interface de contrôle 9 du système informatique en nuage 2.

Les fonctions des modules 3A, 3B et 3C sont décrits plus en détail ultérieurement, lors de la description des étapes du procédé d'instanciation selon l'invention.

Dans le mode de réalisation décrit ici, le système informatique en nuage 2 s'appuie, pour réaliser le contrôle de l'accès aux ressources qu'il met à disposition de ses clients, sur l'architecture de référence XACML (extensible Access Control Markup Language) définie par le standard IETF, illustrée schématiquement à la figure 4.

De façon connue, cette architecture propose un standard pour le déploiement des modules logiciels nécessaires à la mise en œuvre d'un contrôle d'accès dans une infrastructure telle que par exemple le système informatique en nuage 2. Les modules logiciels définis par le standard XACML comprennent notamment un module PDP (pour « Policy Décision Point ») de prise de décision qui applique la politique de contrôle d'accès envisagée aux requêtes d'accès des utilisateurs reçues via un ou plusieurs modules PEP (pour « Policy Enforcement Point) d'exécution. Le module PDP renvoie ici une décision d'autoriser ou non les accès requis (instruction conforme à la politique de contrôle d'accès définie au sens de l'invention). Le module de prise de décision PDP peut à cet effet interroger un module PIP (pour « Policy Information Point ») d'information pour obtenir des informations complémentaires sur les utilisateurs à l'origine de ces requêtes ou toutes autres informations nécessaires à la prise de décision ne figurant pas dans les requêtes. Le standard XACML prévoit également un module logiciel PAP (pour « Policy Administration Point ») d'administration permettant de gérer les politiques d'accès et un répertoire PR (pour « Policy Repository ») dans lequel sont stockées les politiques d'accès à appliquer.

Ces modules logiciels étant définis par le standard XACML, ils ne sont pas décrits en détail ici. Dans le mode de réalisation décrit ici, ces différents modules logiciels sont mis en œuvre par le système informatique en nuage 2. Ils intègrent, pour certains, les modules fonctionnels 2A à 2C du système informatique en nuage 2 décrits précédemment.

Plus particulièrement, les modules fonctionnels 2A et 2B du système informatique en nuage 2 permettant la définition pour chaque client CLn du système informatique en nuage 2 d'un modèle de contrôle d'accès ACMn et d'une politique associée ACPn sont intégrés dans le module PAP. On note que dans le mode de réalisation décrit ici, les catégories d'attributs définies pour chaque modèle de contrôle d'accès ACMn et chaque client CLn sont stockées dans le module PIP, tandis que les règles définissant la politique de contrôle d'accès APCn du client CLn sont stockées dans le répertoire PR.

Le module fonctionnel de sécurité 2C qui est configuré pour appliquer aux requêtes issues d'utilisateurs d'un client CLn la politique de contrôle d'accès ACPn et le modèle de contrôle d'accès ACMn définis pour ce client est intégré dans le module PDP.

Comme mentionné précédemment, le système informatique en nuage 2 s'appuie conformément à l'invention, pour assurer le contrôle d'accès aux ressources RESS qu'il met à disposition de ses clients CL1,...,CLN, sur un méta-modèle META qu'il fournit via ΓΑΡΙ 9 aux clients CL1,...,CLN pour configurer et créer leurs politiques d'accès et les modèles de contrôle d'accès sur lesquels ils souhaitent baser ces politiques. Ce méta-modèle META comprend à cet effet une pluralité d'éléments permettant à chaque client CLn, via l'instanciation du méta-modèle par l'intermédiaire de ΓΑΡΙ 9, de définir son modèle de contrôle d'accès ACMn et sa politique de contrôle d'accès ACPn.

Plus précisément, dans le mode de réalisation décrit ici, le méta-modèle META comprend les éléments suivants :

— le périmètre du modèle de contrôle d'accès : ce périmètre est destiné à définir les différentes entités impliquées dans la politique de contrôle d'accès spécifiée par le client. Ces entités sont typiquement des sujets (ex. utilisateurs), des objets (ex. ressources) et/ou des actions (ex. opérations réalisées par les sujets sur les objets). Souvent en effet, une politique de contrôle d'accès ne peut pas protéger toutes les entités associées à un client, mais se concentre sur un sous-ensemble limité d'entités, spécifié par le client en instanciant le périmètre du modèle de contrôle d'accès ;

— des métadonnées : ces métadonnées sont destinées à définir pour chaque entité identifiée dans le périmètre du modèle de contrôle d'accès une ou plusieurs catégories d'attributs associées à cette entité. Aucune limitation n'est attachée à la nature des catégories d'attributs pouvant être spécifiées dans les métadonnées par un client. Il peut s'agir par exemple d'un niveau de sécurité pour une entité telle un sujet ou une action, d'une action sur un objet, d'un rôle pour un sujet, d'un type pour un objet, etc. ;

— des données : ces données définissent des valeurs possibles pour chaque catégorie ou type d'attributs défini(e) par les métadonnées. Par exemple, pour un niveau de sécurité d'une action, ces données peuvent inclure les niveaux « bas », « moyen », « élevé » ;

— une ou plusieurs métarègles : chaque métarègle est une sorte d'algorithme logique identifiant une ou plusieurs catégories d'attributs définies par les métadonnées et utilisées pour fournir une instruction (typiquement une décision) conforme à la politique de contrôle d'accès souhaitée par le client. Une métarègle vise à définir la ou les catégories d'attributs utilisées pour construire la politique de contrôle d'accès du client et décrit comment ces catégories sont utilisées (c'est-à-dire liées entre elles) pour fournir une instruction conforme à la politique de contrôle d'accès du client (par exemple pour prendre une décision d'autoriser ou non un accès conformément à la politique de contrôle d'accès du client) ;

— une ou plusieurs règles de contrôle d'accès : chaque règle est basée sur (i.e. associée à) une métarègle, et décrit un algorithme impliquant les entités identifiées par cette métarègle et reprenant la politique de contrôle d'accès du client. En d'autres mots, l'ensemble des règles de contrôle d'accès définit la politique de contrôle d'accès du client. Chaque règle fournit une instruction conforme à la politique de contrôle d'accès du client. Une telle instruction est typiquement une autorisation ou un refus d'un accès à une ressource déterminée allouée au client par le système informatique en nuage ; et

— un ensemble de valeurs destinées à être assignées par le client à chaque entité définie pour ce client dans le périmètre du modèle de contrôle d'accès, pour chaque catégorie d'attributs associée à cette entité et comprise dans une métarègle, ces valeurs assignées étant choisies parmi les données.

L'instanciation des métadonnées et des métarègles permet de créer le modèle de contrôle d'accès ACMn. L'instanciation des données, des règles, du périmètre et de l'ensemble de valeurs permet de définir la politique de contrôle d'accès ACPn qui s'appuie sur le modèle de contrôle d'accès ACMn.

Dans le mode de réalisation décrit ici, le méta-modèle META est décrit sous forme d'instructions dans un fichier informatique FILE conforme à l'invention stocké dans la mémoire non volatile 7 du système informatique en nuage 2. Aucune limitation n'est attachée au langage informatique utilisé pour décrire le méta-modèle META dans le fichier FILE. Il peut être décrit par exemple en utilisant les langages connus JSON (JavaScript Object Notation), XML (extensible Markup Language) ou encore YAML (Yet Another Markup Language).

On note que le méta-modèle META, par son caractère générique, permet d'instancier, autrement dit de créer, des modèles de contrôle d'accès très divers. Il peut être utilisé notamment pour instancier des modèles de contrôle d'accès connus comme par exemple un modèle de contrôle d'accès de type RBAC, OrBAC, ACL, DTE, ABAC ou MLS, comme illustré ultérieurement. Le méta-modèle META peut également être utilisé facilement pour instancier d'autres modèles de contrôle d'accès, ou des variantes de modèles de contrôle d'accès connus s'appuyant sur des caractéristiques avancées comme par exemple les notions de session, de délégation, etc.

Nous allons maintenant décrire en référence à la figure 5 comment ce méta-modèle META est utilisé par le système 1 pour assurer le contrôle d'accès aux ressources RESS mises à disposition de ses clients CL1,...,CLN par le système informatique en nuage 2 tout en permettant à chaque client CLn, n=l,...,N de spécifier sa propre politique de contrôle d'accès et son propre modèle de contrôle d'accès pour réaliser le contrôle de l'accès aux ressources Rn parmi les ressources RESS qui lui sont allouées. Plus précisément, la figure 5 représente les principales étapes du procédé de gestion mis en œuvre par le système informatique en nuage 2 pour gérer l'accès à ses ressources RESS par les utilisateurs associés à ses clients CL1,...,CLN, et les principales étapes du procédé d'instanciation mis en œuvre par chaque dispositif client 3-n de chaque client CLn pour spécifier auprès du système informatique en nuage 2, via l'instanciation du méta-modèle META décrit précédemment, sa politique ACPn de contrôle d'accès et le modèle de contrôle d'accès ACMn sur lequel se base cette politique.

Plus précisément, on suppose que suite par exemple à l'enregistrement du client CLn auprès du système informatique en nuage 2, ce dernier lui alloue dynamiquement et virtuellement des ressources Rn parmi ses ressources RESS (étape E10) et l'invite à définir la politique de contrôle d'accès qu'il souhaite appliquer pour contrôler l'accès aux ressources Rn par ses utilisateurs.

A cet effet, le système informatique en nuage 2 fournit au dispositif 3-n du client CLn, via son interface 9 et son module de fourniture 2A (intégrés dans le module XACML PAP du système informatique en nuage 2), le méta-modèle META (étape E20).

Le client CLn, via le module d'instanciation 3B du dispositif 3-n et l'interface 9 mise à disposition par le système informatique en nuage 2, instancie le méta-modèle META obtenu de sorte à créer le modèle de contrôle d'accès ACMn et la politique de contrôle d'accès ACPn basée sur ce modèle qu'il souhaite appliquer aux ressources Rn qui lui sont appliquées (étape E30).

A cet effet, le client CLn renseigne (i.e. paramètre ou encore configure), via le module d'instanciation 3B, les différents éléments du méta-modèle META dans l'interface 9.

Deux exemples sont donnés ci-après à titre illustratif pour montrer comment le client CLn via le module d'instanciation 3B peut configurer les éléments du méta-modèle META pour créer un modèle de contrôle d'accès de type MLS et un modèle de contrôle d'accès de type RBAC.

Selon un premier exemple illustratif, le client CLn instancie le méta-modèle META de la façon suivante pour créer un modèle de contrôle d'accès de type RBAC :

— il définit comme périmètre du modèle ACMn les entités suivantes :

o pour les sujets, deux utilisateurs « userO » et « userl » ;

o pour les objets, une machine virtuelle « vmO » parmi les ressources Rn ;

o pour les actions, une action de démarrage de la machine virtuelle « start » et une action d'arrêt de la machine virtuelle « stop » ;

— il définit comme métadonnées les catégories d'attributs suivantes :

o pour les sujets, une catégorie « rôle » regroupant des attributs de type rôle ;

o pour les objets, une catégorie « id » regroupant des attributs de type identifiants ; o pour les actions, une catégorie « action-type » regroupant des attributs de types d'actions ;

— il définit comme données, c'est-à-dire comme valeurs possibles des catégories d'attributs spécifiées par les métadonnées :

o pour la catégorie « rôle », les valeurs « admin » (administrateur) et « employée » (employé) ;

o pour la catégorie « id », la valeur « vmO » o pour la catégorie « action-type», la valeur « vm-action »

— il définit comme métarègle une métarègle identifiant les catégories d'attributs « rôle », « id » et « action-type » ;

— il définit comme règle de contrôle d'accès pour prendre une décision d'autoriser ou de refuser un accès, la règle suivante : « si la catégorie « rôle » est « admin », la ressource requise est identifiée par « vmO » et la catégorie « action-type » est « vm-action » alors l'instruction est « accès accepté » ». Cette règle fournit une instruction d'autorisation de l'accès ;

— enfin, il assigne les valeurs suivantes à chaque entité définie dans le périmètre du modèle de contrôle d'accès :

o à l'utilisateur userO, la valeur « admin » de la catégorie « rôle » ;

o à l'utilisateur userl, la valeur « employée » de la catégorie « rôle » ;

o à l'objet vmO, la valeur « vmO » de la catégorie « id » ;

o à l'action start, la valeur « vm-action » de la catégorie « action-type » ; et

o à l'action stop, la valeur « vm-action » de la catégorie « action-type ».

Ainsi, dans ce modèle RBAC et la politique de contrôle d'accès créés par le client CLn à partir du méta-modèle META, seul l'utilisateur userO qui a le rôle d'administrateur peut démarrer ou arrêter la machine virtuelle vmO. L'utilisateur userl qui a le rôle d'employé ne peut pas accéder à la machine virtuelle vmO.

Selon un second exemple illustratif, le client CLn instancie le méta-modèle META de la façon suivante pour créer un modèle de contrôle d'accès de type MLS :

— il définit comme périmètre du modèle ACMn les entités suivantes :

o pour les sujets, trois utilisateurs « userO », « userl » et « user2 » ;

o pour les objets, deux machines virtuelles « vmO » et « vml » parmi les ressources Rn; o pour les actions, une action de démarrage « start » et une action d'arrêt « stop » ;

— il définit comme métadonnées les catégories d'attributs suivantes :

o pour les sujets, une catégorie « subject-security-level » regroupant des attributs de type niveau de sécurité sujet ;

o pour les objets, une catégorie « object-security-level » regroupant des attributs de type niveau de sécurité objet ;

o pour les actions, une catégorie « action-type » regroupant des attributs de types d'actions ;

— il définit comme données, c'est-à-dire comme valeurs possibles des catégories d'attributs spécifiées par les métadonnées :

o pour la catégorie « subject-security-level », les valeurs « low » (basse), « médium »

(intermédiaire) et « high » (haute) ;

o pour la catégorie « object-security-level », les valeurs « low » (basse), « médium »

(intermédiaire) et « high » (haute) ;

o pour la catégorie « action-type», les valeurs « vm-action » et « storage-action » ; — il définit comme métarègle, une métarègle identifiant les catégories d'attributs « subject- security-level», « object-security-level» et « action-type » ;

— il définit comme règles de contrôle d'accès pour prendre une décision d'autoriser ou de refuser un accès :

o une première règle rl spécifiant que « si la catégorie « subject-security-level » est

« high», la ressource requise a une catégorie « object-security-level » ayant une valeur « médium », et la catégorie « action-type » d'action sur la ressource est « vm- action » alors l'instruction est « accès accepté » ». Cette première règle rl fournit une instruction d'autorisation de l'accès ;

o une deuxième règle r2 spécifiant que « si la catégorie « subject-security-level » est

« high» ou « médium », la ressource requise a une catégorie « object-security-level » ayant une valeur « low », et la catégorie « action-type » d'action sur la ressource est « vm-action » alors l'instruction est « accès accepté » ». Cette deuxième règle r2 fournit une instruction d'autorisation de l'accès ;

— enfin, il assigne les valeurs suivantes à chaque entité définie dans le périmètre du modèle de contrôle d'accès :

o à l'utilisateur userO, la valeur « high » pour la catégorie « subject-security-level » ; o à l'utilisateur userl, la valeur « médium » pour la catégorie « subject-security-level » ; o à l'objet vmO, la valeur « médium » pour la catégorie « object-security-level » ;

o à l'objet vml, la valeur « low » pour la catégorie « object-security-level » ;

o à l'action start, la valeur « vm-action » de la catégorie « action-type » ; et

o à l'action stop, la valeur « vm-action » de la catégorie « action-type ».

Ainsi, dans ce modèle MLS et la politique de contrôle d'accès créés par le client CLn à partir du méta-modèle META, seuls les utilisateurs ayant un niveau de sécurité intermédiaire ou élevé ont le droit de démarrer ou d'arrêter les machines virtuelles. L'utilisateur userO peut manipuler les machines virtuelles vmO et vml, et l'utilisateur userl peut manipuler la machine vml seulement.

Bien entendu, ces exemples ne sont donnés qu'à titre illustratif et d'autres modèles de contrôle d'accès peuvent être créés par le client CLn à partir du méta-modèle META comme mentionné précédemment.

Le modèle de contrôle d'accès ACMn et la politique de contrôle d'accès ACPn définis par le module d'instanciation 3B du dispositif 3-n constituent une instance du méta-modèle META au sens de l'invention. Ils sont fournis par le module de fourniture 3C du dispositif 3-n via l'interface 9 au système informatique en nuage 2 (étape E40). Ils sont reçus par son module de réception 2B (intégré dans le module XACML PAP du système informatique en nuage 2) et stockés dans sa mémoire non volatile 7 par exemple (dans les modules PIP et PR définis par l'architecture XACML décrits précédemment). Dès lors, le système informatique en nuage 2 est apte à appliquer, par l'intermédiaire de son module de sécurité 2C (intégré dans son module XACML PDP), la politique de contrôle d'accès ACPn définie par le client CLn à toute requête provenant d'un utilisateur du client CLn visant à accéder à une ressource choisie parmi les ressources Rn allouées au client CLn (étape E50). Le module de sécurité 2C s'appuie à cet effet sur les modules logiciels PIP et PR décrits précédemment de l'architecture XACML.

Le système informatique en nuage 2 procède de la même façon préférentiellement pour chacun de ses clients CLn, n=l,...,N. De cette sorte il peut appliquer pour chacun de ses clients une politique de contrôle d'accès spécifiée par celui-ci et propre à celui-ci.