WO2018193190A1 - Procédé de gestion d'un système informatique à allocation dynamique de ressources - Google Patents

Procédé de gestion d'un système informatique à allocation dynamique de ressources Download PDF

Info

Publication number
WO2018193190A1
WO2018193190A1 PCT/FR2018/050941 FR2018050941W WO2018193190A1 WO 2018193190 A1 WO2018193190 A1 WO 2018193190A1 FR 2018050941 W FR2018050941 W FR 2018050941W WO 2018193190 A1 WO2018193190 A1 WO 2018193190A1
Authority
WO
WIPO (PCT)
Prior art keywords
access control
client
model
primary
access
Prior art date
Application number
PCT/FR2018/050941
Other languages
English (en)
Inventor
Ruan HE
Xiao HAN
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2018193190A1 publication Critical patent/WO2018193190A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database

Definitions

  • the invention relates to the general field of access control, by a terminal or client, to resources managed dynamically by a computer system.
  • a major challenge of the access control of such a system is to guarantee the protection and security of access to computing resources and networks made available to a customer by a system, these resources possibly being shared by several different customers, even heterogeneous.
  • the invention therefore applies in particular, but in a nonlimiting manner, to so-called “cloud computing” systems, also known as “cloud computing” systems with multi-entity or “multi-tenant” cloud computing systems. " in English.
  • client entity or client of the cloud computing system we mean here an information system (eg an organization's or a company's IT system, application, etc.), tenant of resources made available by the cloud computing system (also called “tenant” in English).
  • an information system eg an organization's or a company's IT system, application, etc.
  • tenant of resources made available by the cloud computing system (also called “tenant” in English).
  • cloud computing is a model that allows users, or more generally customers, to access via a network.
  • demand and self-service computer resources and networks such as storage space, computing power, applications, network access, software or services, which are virtualized (ie made virtual) and shared between these customers.
  • IT resources are no longer located on a local server or on a user station, but are, in accordance with the cloud computing concept, dematerialized in a cloud composed of several physically remote servers interconnected with each other, and accessible by the users.
  • customers and their users via, for example, a network application.
  • Customers, and especially their users can gain access to these resources in a scalable manner without having to manage the underlying infrastructure for managing these resources, which is often complex.
  • cloud computing has many advantages: - flexibility and diversity of resources that are shared and virtually unlimited, - possible scalability of resources, provided on demand,
  • An access control policy is a set of rules that regulates user access to the client's resources. For example, such an access control policy specifies via a set of rules the rights of users to access different client files stored on a disk; these rules can indicate by way of illustration that the user Bob has read rights on a file Fl.h and that the user Alice has write rights on a file F2.c.
  • This access control policy relies on an access control model that defines how the decision to allow or deny access to the resource is made.
  • access control models that provide a framework for the use of a client's resources: these models are usually designed to check whether an active entity (also referred to as a subject) such a user via a terminal, can access a passive entity (also referred to as an object) such as a computer and network resource, by performing a given operation (also referred to as an action), and if necessary, allow access to the passive entity by the active entity via said operation.
  • More or less complex known access control models are, for example, the Role-Based Access Control (RBAC) model, the Organization-Based Access Control (OrBAC) model, or the MultiLevel Security (MLS) model.
  • RBAC Role-Based Access Control
  • OrBAC Organization-Based Access Control
  • MLS MultiLevel Security
  • the invention overcomes this drawback by proposing a method for managing a computer system, capable of dynamically allocating computer and network resources to a plurality of clients, each client being associated with at least one user who is able to access the computer resources and networks allocated to the customer by the computer system.
  • This method comprises, for at least one client of the computer system:
  • a method for managing a computer system capable of dynamically allocating computer and network resources to a plurality of clients, each client being associated with at least one user likely to access the computing resources. and networks allocated to the customer by the computer system. This method comprises, for at least one client of the computer system:
  • the invention also relates to a computer system capable of dynamically allocating computer and network resources to a plurality of clients, each client being associated with at least one user likely to access the computer resources and networks allocated to the client by the computer system.
  • This system includes:
  • a reception module able to receive, from said client, a primary access control model and a primary access control policy based on this primary access control model, said reception module being furthermore able to receive from said client, at least one secondary access control model and a secondary access control policy based on this secondary access control model;
  • a security module configured to apply said primary and secondary access control policies to at least one access request sent by said client to control access of a user of the client to at least one resource allocated to the client by the client; computer system, the primary access control policy being defined by an instance of a meta-model including an instruction to redirect the request to the secondary policy when access is denied.
  • a computer system capable of dynamically allocating computer and network resources to a plurality of clients, each client being associated with at least one user able to access the computing resources and networks allocated to the client by the computer system.
  • This system includes:
  • a reception module able to receive, from the client, a primary access control model and a primary access control policy based on this primary access control model, this reception module being furthermore adapted to receive from said client, at least one secondary access control model and a secondary access control policy based on this secondary access control model, this secondary policy being able to be implemented by said primary policy access control;
  • a security module configured to apply said primary and secondary access control policies to at least one access request sent by said client to control access of a user of the client to at least one resource allocated to the client by the client; computer system.
  • An access control policy is called "primary” when it implements another policy, namely a so-called “secondary” policy and a “secondary” policy, when it is implemented by another policy. , namely a so-called "primary” policy.
  • a policy can be both a primary and a secondary policy if it can both implement another policy and be implemented by another policy.
  • the invention thus proposes a method and a system making it possible to define simple access models and policies and to link them together. It thus prevents users from having to design autonomous, unrelated access policies that are more complex to define and maintain.
  • the primary access control policy and several secondary access control policies can be cascaded.
  • a secondary policy of Access control can itself be chained with the primary access control policy or with another secondary access control policy that precedes it in the chain.
  • the access control policy chain thus defined may have any topology. It can in particular be linear, have a branched form (when a primary or secondary policy is chained with more than one policy), and possibly contain one or more loops.
  • the invention is particularly applicable in the context of a computer system in which the resources are allocated dynamically, but also virtually, for example in a cloud computing system.
  • the management method of a computer system according to the invention is remarkable in that it comprises:
  • Said primary access control model and said primary access control policy are defined by a first instance of said meta-model; and in that
  • Said at least one secondary access control model and said secondary access control policy based on this model are defined by a second instance of said metamodel.
  • the invention therefore proposes that instead of imposing the same access control model on all its customers, the computer system provides them with a predefined meta-model allowing each of the clients of the computer system create their own access control models and base their access control policies on the models created.
  • Computing is particularly flexible and allows each customer to define with greater freedom their own access control policies and to adapt to their specificities and security needs.
  • the meta-model generically defines a number of elements to create a control model access and specify access control policies based on this model, that the client comes to instantiate with the computer system (in other words, it comes to inform the elements of the metamodel to create the primary and secondary models of access control on which he wishes to base his access control policies).
  • the invention makes it possible to limit and adapt the extent of the protection to each client.
  • Each customer can have a personalized control of the access to the resources that are allocated to him dynamically and virtually by the computer system.
  • the new paradigm proposed by the invention is therefore flexible, dynamic, adaptive and evolutive.
  • this embodiment of the invention makes it possible to define a plurality of models and separate access control policies for each of the clients of the computer system, it nevertheless relies on a single meta-model common to all the clients, and resource access control centrally performed by the computer system. This ensures the consistency of access control resources provided by the computer system implemented and enhances its effectiveness.
  • the instance of the meta-model provided by the client defines an access control model of RBAC, OrBAC, ACL, Domain Type Enforcement (DTE) type, ABAC (" Attribute Based Access Control ”) or MLS.
  • the invention also makes it possible to create new access control models, or to adapt the existing access control models by introducing new features into these models (eg adding new entities to the models, defining new categories attributes associated with these entities, introduction of concepts in known access control models such as the notion of session, delegation, hierarchy, usage control, etc.), to integrate advanced features and unpublished in access control realized.
  • new features eg adding new entities to the models, defining new categories attributes associated with these entities, introduction of concepts in known access control models such as the notion of session, delegation, hierarchy, usage control, etc.
  • introduction of concepts in known access control models such as the notion of session, delegation, hierarchy, usage control, etc.
  • the meta-model proposed by the computer system to its customers in this embodiment of the invention advantageously comprises a plurality of elements making it possible to define the access control model adopted by the client. for its access control policy.
  • the plurality of elements of the meta-model comprises:
  • a perimeter of the access control model defining a plurality of entities involved in the client's access control policy.
  • the plurality of entities involved comprises at least one subject, and / or an object and / or an action;
  • - metadata defining for each entity at least one attribute category associated with that entity;
  • At least one metarregule identifying at least one attribute category defined by the metadata and used to provide at least one instruction conforming to the client's access control policy
  • At least one access control rule based on said at least one metarule and providing an instruction in accordance with the client's access control policy
  • Said instruction comprising:
  • the instruction comprises an update of at least one attribute of said access request, the updated request being redirected to an access control policy.
  • the invention also provides a computer file comprising instructions describing a meta-model comprising a plurality of elements making it possible to define an access control model and an access control policy for a client.
  • a computer system capable of dynamically allocating computer and network resources to a plurality of clients, said plurality of elements of the meta-model comprising: a perimeter of the access control model defining a plurality of entities involved in the policy customer access control;
  • At least one metarregule identifying at least one attribute category defined by the metadata and used to provide at least one instruction conforming to the client's access control policy; At least one access control rule based on said at least one metarule and providing an instruction in accordance with the client's access control policy; and
  • Said instruction comprising:
  • meta-model proposed by the invention is based in this particular embodiment on a specification based on the notion of attributes.
  • the relevance of this approach to describing many access control models has been demonstrated, as the different security properties of entities (subject, object or action) can be considered as attributes associated with these entities.
  • At least one attribute category defined for an entity is chosen from:
  • security level (example: security level of a subject or an object);
  • this embodiment of the invention through the meta-model proposed to the client, allows the latter to define a conventional access control policy by means of rules allowing or denying access to a resource based on attribute values associated with one or more entities
  • the instance of the meta-model is provided by the client via a configuration interface of the computer system common to the plurality of clients of the computer system.
  • the meta-model proposed by the computer system is common to all the customers of the computer system, it can advantageously be instantiated via a unified control interface for all the clients.
  • the invention also provides a method implemented by a client to define access control policies in a computer system capable of dynamically allocating computer and network resources to a plurality of clients, each client being associated at least one user likely to access the computer resources and networks allocated to the client by the computer system.
  • This process comprises:
  • this method of defining access control policies is remarkable in that it comprises:
  • Said primary access control model and said primary access control policy are defined by a first instance of said metamodel; and in that
  • said at least one secondary access control model and said secondary access control policy based on this model are defined by a second instance of said metamodel.
  • the invention relates to a device of a client of a computer system capable of dynamically allocating computer and network resources to a plurality of clients, each client being associated with at least one user likely to access computing resources and networks. allocated to the customer by the computer system.
  • This device comprises:
  • At least one module for defining at least one secondary access control model and a secondary access control policy based on this access control model
  • a provisioning module configured to supply said primary and secondary access control models and said primary and secondary access control policies to said computer system, said policies being intended to be applied to access requests issued by said client to control an access of a user of said client to at least one of said resources.
  • this device comprises:
  • At least one module for defining at least one secondary access control model and a secondary access control policy based on this access control model
  • a provisioning module configured to supply said primary and secondary access control models and said primary and secondary access control policies to said computer system, said policies being intended to be applied to access requests issued by said client to control an access of a user of said client to at least one of said resources.
  • this device is characterized in that it comprises:
  • a obtaining module configured to obtain a meta-model provided by the computer system and comprising a plurality of elements making it possible to define an access control model and an access control policy for the client; and in that
  • said primary access control model and said primary access control policy are defined by a first instance of said metamodel; and in that
  • said at least one secondary access control model and said secondary access control policy based on this model are defined by a second instance of said metamodel.
  • the method of setting access control policies and the device of the computer system client have the same advantages mentioned above as the management method and the computer system.
  • the various steps of the management method and / or the method of defining access control policies are determined by instructions of computer programs.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a computer system or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a management method as described above.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a device of a client of a computer system or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of an access control policy definition method as described above.
  • Each of these programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any form what other form is desirable.
  • the invention also relates to a computer readable information or recording medium, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information or recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention also relates to a system comprising:
  • a computer system as described above able to allocate computer and network resources to a plurality of clients, each client being associated with at least one user likely to access the computing resources and networks allocated to the client by the computer system;
  • FIG. 1 shows schematically a system according to the invention comprising a computer system and client devices of the computer system, according to the invention
  • FIG. 2A represents the hardware architecture on which the computer system of FIG. 1 is based;
  • FIG. 2B represents various functional elements of the computer system of FIG. 1 configured to implement the management method according to the invention
  • FIG. 3A represents the hardware architecture of the client devices of FIG. 1;
  • FIG. 3B represents various functional elements of the client devices of FIG. 1 configured to implement the method of defining access policies according to the invention
  • FIG. 4 schematically illustrates the main software modules defined by the XACML reference standard for performing access control and implemented by the cloud computing system of FIG. 1;
  • FIG. 5 illustrates the main steps of a management method according to the invention as it is implemented by the cloud computing system of FIG. 1, and the main steps of a method for defining policies of FIG. access according to the invention as implemented by each client device of Figure 1;
  • FIG. 6 illustrates the mechanism for chaining security policies in a particular embodiment of the invention.
  • FIG. 1 represents, in its environment, a system 1 according to the invention, in a particular embodiment.
  • the system 1 comprises:
  • a cloud computing system 2 in accordance with the invention, and capable of allocating to a plurality of clients CL1, CL2, CLN, N designating an integer greater than 1, computer resources and RESS networks.
  • No limitation is attached to the nature of IT resources and networks RESS; it can be for example storage space, computing power, applications, network connections, software or services, which are virtualized and shared between CL1, CL2 clients, ..., CLN the cloud computing system 2; and
  • telecommunications networks such as, for example, a WiFI, WLAN, mobile (3G, 4G, 5G, etc.) network, the public Internet network, etc.
  • Such a client is also called "tenant" in English. This may be for example an IT system of an organization or a company, a software application, etc.
  • This client CLn has, in a manner known per se, to access the computer resources and networks allocated to it by the cloud computing system 2, a customer account registered with the cloud computing system. This client account is protected by one or more authentication parameters (eg identifier, password, etc.) enabling the cloud computing system 2 to identify the client CLn.
  • authentication parameters eg identifier, password, etc.
  • Each of these clients includes one or more users who can access, via any type of device (eg via a server, a terminal such as a computer, smartphone (smartphone) or digital tablet, etc.) to computing resources and networks allocated to clients by the cloud computing system 2.
  • a server e.g., a server, a terminal such as a computer, smartphone (smartphone) or digital tablet, etc.
  • smartphone smarttphone
  • digital tablet e.g., etc.
  • the cloud computing system 2 has hardware architecture of a computer, as shown in Figure 2A. It comprises in particular a processor 4, a read-only memory 5, a random access memory 6, a non-volatile memory 7, as well as communication means 8 with, in particular, the devices 3-1, 3-2,..., 3-N.
  • These communication means 8 integrate for example here a network card, known per se and not detailed here, or any other means for communicating over a telecommunications network.
  • the hardware elements 4-8 of the cloud computing system 2 can be located on a single server of the cloud computing system 2 or be dispatched on several pieces of equipment (for example several computers) of the cloud computing system 2 communicating with each other and each having the hardware architecture illustrated in Figure 2A. In the embodiment described here, it is assumed that these hardware elements are collocated on the same server.
  • the read-only memory 5 of the cloud computing system 2 constitutes a recording medium in accordance with the invention, readable by the processor 4 and on which is recorded a computer program PROG1 according to the invention, comprising instructions for the execution of the steps of a management method according to the invention, described later with reference to Figure 5 in a particular embodiment.
  • This computer program defines, in an equivalent manner, functional modules of the cloud computing system 2 which support or control the hardware elements 4-8 of the computer system.
  • cloud computing system 2 and which more specifically include, with reference to FIG. 2B:
  • the meta-model META is described in the form of instructions in a FILE computer file stored here in the nonvolatile memory 7 of the cloud computing system 2;
  • a security module 2C configured to apply, for each client CLn, primary policies ACPPn and secondary ACPSn access control defined by it to control access of a user of this client to at least one a resource among the resources Rn allocated to it by the cloud computing system 2.
  • the security module 2C can be dispatched to one or more equipment (for example in a data center) of the cloud computing system 2 according to the Rn resources allocated to the client are hosted by one or more devices in the cloud computing system 2.
  • the delivery 2A and reception 2B modules rely on an interface called the unified control interface 9 of the cloud computing system 2, which it makes available to its customers to access the meta-model META and instantiate it.
  • an interface may be, for example, an Application Programming Interface (API), known per se and not described in detail here, which allows CLn clients to manipulate the various elements of the META meta-model provided by the system. 2 and to instantiate it (that is to say to inform it or to configure or configure it to create an access control model and an access control policy based on this model ).
  • API Application Programming Interface
  • modules 2A, 2B and 2C are described in more detail later, when describing the steps of the management method according to the invention.
  • each device 3-n associated with each client CLn also called in the description "client device 3-n"
  • means of communication 14 include for example here a network card, known per se and not detailed here, or any other means for communicating over a telecommunications network.
  • the read-only memory 11 of the device 3-n constitutes a recording medium in accordance with the invention, readable by the processor 10 and on which is recorded a computer program PROG2 according to the invention, comprising instructions for execution. steps of a method of defining access control policies according to the invention, described later with reference to Figure 5 in a particular embodiment.
  • This computer program similarly defines functional modules of the client device 3-n which support or control the hardware elements 10-14 of the device 3-n, and which more specifically include, with reference to FIG. 3B :
  • a obtaining module 3A configured to obtain (that is to say here access via the unified control interface 9) the meta-model META provided by the cloud computing system 2;
  • a definition module 3B configured to instantiate (generate or construct) the meta-model META so as to create:
  • At least one second instance of the meta-model defining a secondary access control model ACMSn and a secondary ACPSn access control policy based on this access control model
  • a provisioning module 3C configured to supply these instances (that is, to provide the primary access control model ACMPn, the primary access control policy ACPPn, the secondary access control model (s) ASMSn and the or secondary access control policies ACPSn) to the cloud computing system 2, via here the control interface 9 of the cloud computing system 2.
  • modules 3A, 3B and 3C are described in more detail later, when describing the steps of the method of defining access control policies according to the invention.
  • the cloud computing system 2 relies on the reference architecture XACML (Extensible Access Control Markup) to control access to the resources it makes available to its clients. Language) defined by the IETF standard, schematically illustrated in Figure 4.
  • XACML Extensible Access Control Markup
  • this architecture proposes a standard for the deployment of the software modules necessary for the implementation of access control in an infrastructure such as, for example, the cloud computing system 2.
  • the software modules defined by the XACML standard include a Decision Decision Point (PDP) module that applies the intended access control policy to access requests users received via one or more PEP modules (for "Policy Enforcement Point") execution.
  • PDP Decision Decision Point
  • the PDP module here returns a decision to authorize or not the required accesses (instruction conforming to the access control policy defined in the meaning of the invention).
  • the PDP decision-making module can for this purpose interrogate a PIP ("Information Information Point") information module to obtain additional information on the users who originated these requests or any other information necessary for making the request. decision not included in the applications.
  • the XACML standard also provides a PAP (Policy Administration Point) software module for managing access control policies and a PR directory (for "Policy Repository”) in which the control policies are stored. access to apply.
  • these software modules are defined by the XACML standard, they are not described in detail here. In the embodiment described here, these different software modules are implemented by the cloud computing system 2. They integrate, for some, the functional modules 2A to 2C of the cloud computing system 2 described above.
  • the functional modules 2A and 2B of the cloud computing system 2 making it possible to define for each client CLn the cloud computing system 2 of a primary access control model ACMPn, of an associated primary policy ACPPn, of at least one secondary access control model ACMSn and an associated secondary policy ACPPn are integrated into the PAP module.
  • the attribute categories defined for each access control model ACMPn, ACMSn and each client CLn are stored in the PIP module, while the rules defining the control policies of APCPn access and APCSn CLn client are stored in the PR directory.
  • the security functional module 2C which is configured to apply to requests from users of a client CLn, the access control policies ACPPn, ACPSn and the access control models ACMPn and ACMSn defined for this client is integrated in the PDP module.
  • the cloud computing system 2 relies, for the purpose of controlling access to the RESS resources that it makes available to its CL1, ..., CLN clients, on a meta-model. META that it provides via CL1, ..., CLN clients to configure and create their primary and secondary access control policies and the primary and secondary access control models on which they want to base these policies.
  • this meta-model META comprises a plurality of elements allowing each client CLn, via the instantiation of the meta-model via ⁇ 9, to define its access control models ACMPn, ACMSn and its ACPPn Access Control Policies, ACPSn.
  • access control models conform to existing models such as RBAC, ORBAC, MLS, and so on.
  • the meta-model META comprises the following elements: - the perimeter of the access control model: this scope is intended to define the different entities involved in the access control policy specified by the client. These entities are typically subjects (eg users), objects (eg resources) and / or actions (eg operations performed by subjects on objects). Often, an access control policy can not protect all the entities associated with a client, but focuses on a limited subset of entities, specified by the client by instantiating the perimeter of the control model. access;
  • this metadata is intended to define for each entity identified in the perimeter of the access control model one or more categories of attributes associated with this entity.
  • categories of attributes There is no limitation on the nature of the categories of attributes that can be specified in metadata by a client. For example, it can be a security level for an entity such as a subject or an action, an action on an object, a role for a subject, a type for an object, and so on. ;
  • these data define possible values for each category or type of attributes defined by the metadata. For example, for a security level of an action, this data may include the "low”, “medium”, “high” levels;
  • each metarule is a sort of logical algorithm identifying one or more categories of attributes defined by the metadata and used to provide at least one instruction conforming to the access control policy desired by the client.
  • a metarule is used to define the attribute category or categories used to construct the client's access control policy and describes how these categories are used (ie linked to each other) to provide at least one compliant instruction the customer's access control policy (for example, to make a decision whether to allow access in accordance with the customer's access control policy);
  • each rule is based on (i.e. associated with) a metarule and describes an algorithm involving the entities identified by this metarule and taking over the client's access control policy.
  • the set of access control rules defines the client's access control policy.
  • Each rule is defined to provide at least one instruction developed based on the client's access control policy.
  • Each rule provides an instruction consistent with the client's access control policy; and a set of values to be assigned by the client to each entity defined for that client in the perimeter of the access control model, for each attribute category associated with that entity and included in a metarule, these assigned values being selected from the data.
  • an instruction derived from a rule or a metreference comprises:
  • the instantiation of the metadata and metarules allows the creation of the ACMPn primary model and ACMSn secondary access control model.
  • the instantiation of the data, the rules, the perimeter and the set of values makes it possible to define the primary ACPPn and secondary ACPSn access control policies which are based on these access control models ACMPn and ACMSn.
  • the meta-model META is described in the form of instructions in a computer file FILE according to the invention stored in the non-volatile memory 7 of the cloud computing system 2.
  • FILE computer file
  • meta-model META by its generic character, makes it possible to instantiate, in other words to create, very different primary or secondary models of access control. It can be used in particular to instantiate known access control models such as for example an access control model of RBAC, OrBAC, ACL, DTE, ABAC, MLS, session or delegation type as illustrated later.
  • the meta-model META can also be easily used to instantiate other access control models, or variants of known access control models based on advanced features such as the notions of session, delegation etc.
  • FIG. 5 represents the main steps of the management method implemented by the cloud computing system 2 to manage the access to its RESS resources by the users associated with its clients CL1, ..., CLN, and the main steps of the method of defining the access control policies implemented by each client device 3-n of each client CLn to specify with the cloud computing system 2, via the instantiation of the meta-model META described above, its primary ACPPn and secondary (s) ACPSn access control and ACMPn primary and secondary ACMn access control ACMSn models on which these policies are based.
  • step E10 the latter allocates dynamically and virtually Rn resources among its RESS resources (step E10) and invites it to define access control policies that it wishes to apply to control access to resources Rn by its users.
  • the cloud computing system 2 provides to the device 3-n of the client CLn, via its interface 9 and its delivery module 2A (integrated into the XACML PAP module of the cloud computing system 2) the meta-model META (step E20).
  • the client CLn via the definition module 3B of the device 3-n and the interface 9 made available by the cloud computing system 2, instantiates the meta-model META obtained so as to create the primary model of access control ACMPn and the ACPPn primary ACPn access control policy based on this model that it wishes to apply to the Rn resources allocated to it (step E30). Then, the client CLn, via the definition module 3B, instantiates the meta-model META so as to create one or more ACMSn secondary access control models, and the secondary control policy (s) ACPSn. ACPn access based on these templates (step E35).
  • the client CLn informs (i.e. parameter or configure), via the definition module 3B, for each primary or secondary model the different elements of the meta-model META in the interface 9.
  • This third rule provides an instruction for redirecting an access control request to the secondary delegation policy
  • the values "activate” and “desactivate” define it as metarègle, a metarègle identifying the categories of attributes "subjectid”, “role” and "session-action”;
  • This rule defines a first rule: "if the category” subjectid "is” userO ", the role is” admin “(administrator) and the category” session-action "is” activate "then the instruction is to add the role for the user in the query and send the request to the RBAC primary policy.
  • This rule provides an instruction for updating at least one attribute of the access control request and an instruction for redirecting an access control request to the RBAC primary policy;
  • This rule defines a second rule: "if the category” subjectid “is” userl ", the role is” employed "(employee) and the category” session-action "is” desactivate "then the instruction is to remove the role for the user in the query and send the query to the primary RBAC policy.
  • This rule provides an instruction for updating at least one attribute of the access control request and an instruction for redirecting an access control request to the RBAC primary policy;
  • this Session model and the access control policy created by the CLn client from the meta-model META temporarily enable and disable the role of the user.
  • o for subjects a category "subjectid” grouping attributes of type subject; o for objects, a “delegated” category grouping role-type attributes; o for actions, a "delegation-action” category grouping action type attributes;
  • metarégle a metarégle identifying the categories of attributes "subjectid”, "delegated” and "delegated-action";
  • this delegation model and the access control policy created by the client CLn from the meta-model META temporarily establish a relationship of trust between two users, the first user temporarily delegating his role to the second user.
  • these examples are given for illustrative purposes only and other access control models can be created by the client CLn from the meta-model META as mentioned above.
  • the primary access control model ACMPn and the primary ACPPn access control policy defined by the definition module 3B of the device 3-n constitute an instance of the meta-model META within the meaning of the invention.
  • each ACMSn secondary access control model and the associated secondary access control policy ACPSn defined by the definition module 3B of the device 3-n constitute an instance of the meta-model META within the meaning of the invention. They are provided by the delivery module 3C of the device 3-n via the interface 9 to the cloud computing system 2 (step E40). They are received by its reception module 2B (integrated in the XACML PAP module of the cloud computing system 2) and stored in its nonvolatile memory 7 for example (in the PIP and PR modules defined by the XACML architecture described above).
  • the cloud computing system 2 is able to apply, through its 2C security module (integrated in its XACML PDP module), primary and secondary access control policies ACPPn, ACPSn defined by the client CLn to any request from a CLn client user to access a selected resource from the resources Rn allocated to the customer CLn (step E50).
  • the security module 2C relies on the previously described PIP and PR software modules of the XACML architecture.
  • the PDP defines the primary access control policy type RBAC and the two secondary policies of access control type Session and Delegation type described above.
  • the PEP sends to the PDP, during a step F1, a request by which the user user of type "employed" asks to start a virtual resource vmO.
  • the PDP receives the request from the PEP, applies the primary access control policy type RBAC by inserting the attributes ⁇ subject, object, action ⁇ :
  • the vmO identifier of the virtual resource concerned for the object, the vmO identifier of the virtual resource concerned;
  • the PDP then checks (step F2) based on the RBAC primary policy rules if the userl user has permission to start the vmO virtual resource. If this action was allowed, the PDP would return a positive response to the PEP (step F3). But in this example, the application of the first rule of the access control policy RBAC refuses the start of the vmO virtual machine by the user userl because for userl, the value "used” was assigned in the perimeter of the Access control model and according to the first access control rule defined, the instruction is "access accepted” only if the category "role” is "admin". The request is therefore transferred (step F4) for processing by the first secondary policy, namely, the Session policy.
  • the first secondary policy namely, the Session policy.
  • the PDP checks (step F5) by applying the Session policy if the "employee" role has been enabled for the userl user. If this is the case, by applying the rules of this policy, the request is modified by removing the role "employed” (step F6), then redirected (step F7) to the PDP for application of the primary control policy d RBAC type access.
  • the PDP checks (step F8) by applying the RBAC access control primary policy based on the modified access request if permission can now be given to the userl user to start the vmO virtual machine. Since this is not the case, the request is therefore transferred (step F9) for processing by the second secondary policy, namely, the Delegation policy. According to the rule of this policy, if the delegation action has been enabled, the request is modified (step F10) to add the userO role for the userl user so that userO temporarily delegates its rights to userl. The updated request is redirected (Fil step) for application of the RBAC primary policy which can finally allow the vmO virtual machine to be started by userl according to the rights assigned to userO.
  • the primary and secondary access control models and the primary and secondary access control policies are obtained by instantiation of the same meta-model.
  • the invention is not limited to this characteristic, the primary and secondary access control models and the primary and secondary access control policies can be obtained or defined independently of one another. , by instantiations of different metamodels, or directly, without going through a meta-model.
  • the primary access control policy is of the RBAC type and the secondary access control policies are of the Session and Delegation type, namely advanced features in the sense of RBAC.
  • the primary access control policy can also be an advanced characteristic in the sense of RBAC, for example of the session or delegation type, and the secondary security policy or policies can be of RBAC, OrBAC, ACL, DTE, ABAC or MLS type.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de gestion d'un système informatique en nuage (2), apte à allouer dynamiquement à une pluralité de clients (CL1,…,CLN) des ressources informatiques et réseaux (RESS), chaque client (CLn) é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. Ce procédé comprend, pour au moins un client du système informatique : une étape de réception (E40), en provenance dudit client, d'un modèle primaire de contrôle d'accès et d'une politique primaire de contrôle d'accès basée sur ce modèle primaire de contrôle d'accès; une étape de réception (E40), en provenance dudit client, d'un modèle secondaire de contrôle d'accès et d'une politique secondaire de contrôle d'accès basée sur ce modèle secondaire de contrôle d'accès; et une étape d'application (E50) desdites politiques primaire et secondaire de contrôle d'accès à au moins une requête d'accès émise par ledit client pour contrôler un accès d'un utilisateur du client à au moins une ressource allouée au client par le système, la politique primaire de contrôle d'accès étant définie par une instance d'un méta-modèle comprenant une instruction pour rediriger la requête vers la politique secondaire lorsque l'accès est refusé.

Description

Procédé de aestion d'un svstème informatiaue à allocation dvnamiaue de ressources
Arrière-plan de rinvention
L'invention se rapporte au domaine général du contrôle de l'accès, par un terminal ou client, à des ressources gérées dynamiquement par un système informatique.
Un enjeu majeur du contrôle d'accès d'un tel système est de garantir la protection et la sécurisation de l'accès à des ressources informatiques et réseaux mises à la disposition d'un client par un système, ces ressources pouvant éventuellement être partagées par plusieurs clients distincts, voire hétérogènes.
L'invention s'applique en conséquence notamment, mais de façon non limitative, aux systèmes informatiques dits « en nuage », connus également sous le nom de systèmes de « cloud Computing » aux systèmes de cloud Computing multi-entités ou « multi-tenant » en anglais.
Dans le contexte du 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.
Pour garantir la sécurité d'un système informatique dans lequel les ressources allouées aux clients sont gérées dynamiquement, par exemple un système informatique en nuage, il est nécessaire de définir, pour chaque client du système informatique, 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 éventuellement 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 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, 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, 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, apte à allouer dynamiquement à 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. Ce procédé comprend, pour au moins un client du système informatique :
— une étape de réception, en provenance dudit client, d'un modèle primaire de contrôle d'accès et d'une politique primaire de contrôle d'accès basée sur ce modèle primaire de contrôle d'accès ;
— une étape de réception, en provenance dudit client, d'au moins un modèle secondaire de contrôle d'accès et d'une politique secondaire de contrôle d'accès basée sur ce modèle secondaire de contrôle d'accès; et
— une étape d'application desdites politiques primaire et secondaire de contrôle d'accès à au moins une requête d'accès émise par ledit client pour contrôler un accès d'un utilisateur du client à au moins une ressource allouée au client par le système informatique, la politique primaire de contrôle d'accès étant définie par une instance d'un méta-modèle comprenant une instruction pour rediriger la requête vers la politique secondaire lorsque l'accès est refusé. Dans un mode de réalisation particulier, il est proposé un procédé de gestion d'un système informatique apte à allouer dynamiquement à 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 . Ce procédé comprend, pour au moins un client du système informatique :
— une étape de réception, en provenance du client, d'un modèle primaire de contrôle d'accès et d'une politique primaire de contrôle d'accès basée sur ce modèle primaire de contrôle d'accès ; — une étape de réception, en provenance du client, d'un modèle secondaire de contrôle d'accès et d'une politique secondaire de contrôle d'accès basée sur ce modèle secondaire de contrôle d'accès, cette politique secondaire pouvant être mise en œuvre par ladite politique primaire de contrôle d'accès ; et
— une étape d'application des politiques primaire et secondaire de contrôle d'accès à au moins une requête d'accès émise par ledit client pour contrôler un accès d'un utilisateur du client à au moins une ressource allouée au client par le système informatique .
Corrélativement, l'invention vise aussi un système informatique apte à allouer dynamiquement à 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. Ce système comprend :
— un module de réception, apte à recevoir, en provenance dudit client, un modèle primaire de contrôle d'accès et une politique primaire de contrôle d'accès basée sur ce modèle primaire de contrôle d'accès, ledit module de réception étant en outre apte à recevoir en provenance dudit client, au moins un modèle secondaire de contrôle d'accès et une politique secondaire de contrôle d'accès basée sur ce modèle secondaire de contrôle d'accès ; et
— un module de sécurité configuré pour appliquer lesdites politiques primaire et secondaire de contrôle d'accès à au moins une requête d'accès émise par ledit client pour contrôler un accès d'un utilisateur du client à au moins une ressource allouée au client par le système informatique, la politique primaire de contrôle d'accès étant définie par une instance d'un méta-modèle comprenant une instruction pour rediriger la requête vers la politique secondaire lorsque l'accès est refusé.
Dans un mode de réalisation particulier, il est proposé un système informatique apte à allouer dynamiquement à 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. Ce système comprend :
— un module de réception, apte à recevoir, en provenance du client, un modèle primaire de contrôle d'accès et une politique primaire de contrôle d'accès basée sur ce modèle primaire de contrôle d'accès, ce module de réception étant en outre apte à recevoir en provenance dudit client, au moins un modèle secondaire de contrôle d'accès et une politique secondaire de contrôle d'accès basée sur ce modèle secondaire de contrôle d'accès, cette politique secondaire pouvant être mise en œuvre par ladite politique primaire de contrôle d'accès ; et
— un module de sécurité configuré pour appliquer lesdites politiques primaire et secondaire de contrôle d'accès à au moins une requête d'accès émise par ledit client pour contrôler un accès d'un utilisateur du client à au moins une ressource allouée au client par le système informatique .
L'invention ne pose aucune limite quant aux types des politiques primaire et secondaire(s) de contrôle d'accès. Une politique de contrôle d'accès est dite « primaire » lorsqu'elle met en œuvre une autre politique, à savoir une politique dite « secondaire » et une politique est dite « secondaire », lorsqu'elle est mise en œuvre par une autre politique, à savoir une politique dite « primaire ».
En particulier, une politique peut être à la fois qualifiée de politique primaire et de politique secondaire, si elle peut d'une part mettre en œuvre une autre politique et d'autre part être mise en œuvre par une autre politique.
De façon équivalente, on peut dire que les politiques primaire et secondaire au sens de l'invention sont chaînées.
L'invention propose ainsi un procédé et un système permettant de définir des modèles et des politiques d'accès simples et de les chaîner. Elle évite ainsi aux utilisateurs d'avoir à concevoir des politiques d'accès autonomes, sans relation entre elles, et donc plus complexes à définir et à maintenir.
Au sens de l'invention, la politique primaire de contrôle d'accès et plusieurs politiques secondaires de contrôle d'accès peuvent être chaînées en cascade. Une politique secondaire de contrôle d'accès peut elle-même être chaînée avec la politique primaire de contrôle d'accès ou avec une autre politique secondaire de contrôle d'accès qui la précède dans la chaîne.
La chaîne de politiques de contrôle d'accès ainsi définie peut avoir une topologie quelconque. Elle peut en particulier être linéaire, présenter une forme ramifiée (lorsqu'une politique primaire ou secondaire est chaînée avec plus d'une politique), et éventuellement contenir une ou plusieurs boucles.
L'invention s'applique en particulier dans le contexte d'un système informatique dans lequel les ressources sont allouées dynamiquement, mais aussi virtuellement, par exemple dans un système informatique en nuage.
Dans un mode particulier de réalisation, le procédé de gestion d'un système informatique selon l'invention est remarquable en ce qu'il comporte :
— une étape de fourniture, au 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 basée sur ce modèle ; en ce que
— ledit modèle primaire de contrôle d'accès et ladite politique primaire de contrôle d'accès sont définis par une première instance dudit méta-modèle ; et en ce que
— ledit au moins un modèle secondaire de contrôle d'accès et ladite politique secondaire de contrôle d'accès basée sur ce modèle sont définis par une deuxième instance dudit méta- modèle.
Dans ce mode de réalisation, 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 leur fournisse un méta- modèle prédéfini permettant à chacun des clients du système informatique de créer ses propres modèles de contrôle d'accès et de baser ses politiques de contrôle d'accès sur les modèles ainsi créés.
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é des politiques de contrôle d'accès qui lui sont propres 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 : 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 des politiques de contrôle d'accès s'appuyant sur ce modèle, que le client vient instancier auprès du système informatique (autrement dit, il vient renseigner les éléments du méta-modèle pour créer les modèles primaire et secondaire de contrôle d'accès sur lequel il souhaite baser ses politiques de contrôle d'accès).
Ainsi, au lieu de protéger le système informatique 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.
On note que cette façon de gérer le contrôle de l'accès aux ressources au niveau du système informatique est particulièrement bien adaptée au caractère évolutif des ressources et des clients au sein d'un système informatique. 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, ceux-ci peuvent être supprimés à la volée dès lors que ce client n'est plus servi par le système informatique.
Le nouveau paradigme proposé par l'invention est donc flexible, dynamique, adaptatif et évolutif.
Si ce mode de réalisation de 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, il 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 . Ceci permet d'assurer la consistance du contrôle d'accès aux ressources fournies par le système informatique mis en œuvre et renforce son efficacité.
Il convient de noter que les clients d'un système informatique peuvent, via le méta- modèle fourni par le système informatique , 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 (Domain Type Enforcement), ABAC (« Attribute Based Access Control ») 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és avancées et inédites dans le contrôle d'accès réalisé. Pour plus de renseignements sur les notions de session et de délégation notamment, l'homme du métier peut se reporter au document « D.F Ferraiolo, R. Sandhu, S. Gavrila D.R.Kuhn R.Chandramouli. Proposed nist standard for role-based access control. ACM Transactions on Information and System Security, 2001 ».
A cet effet, comme mentionné précédemment, le méta-modèle proposé par le système informatique à ses clients dans ce mode de réalisation de l'invention 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 au moins 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,
— ladite instruction comprenant :
— une autorisation ou un refus d'un accès à une ressource déterminée allouée au client par le système informatique ; ou
— une redirection de ladite requête d'accès vers une politique de contrôle d'accès.
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. En particulier, les instructions de redirection permettent de chaîner les politiques de sécurité.
Dans un mode de réalisation particulier, l'instruction comprend une mise à jour d'au moins un attribut de ladite requête d'accès, la requête mise à jour étant redirigée vers une politique de contrôle d'accè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 apte à allouer dynamiquement à 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 au moins 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,
— ladite instruction comprenant :
— une autorisation ou un refus d'un accès à une ressource déterminée allouée au client par le système informatique ; ou
— une redirection de ladite requête vers une politique de contrôle d'accès.
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é (exemple : niveau de sécurité d'un sujet ou d'un objet) ;
— un rôle (exemple : rôle d'un sujet) ;
— un type (exemple : type d'objet) ;
— un domaine (exemple : domaine auquel a accès un sujet).
Ainsi, ce mode de réalisation de 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 commune à la pluralité de clients du système informatique.
Le méta-modèle proposé par le système informatique étant commun à tous les clients du système informatique, il peut avantageusement être instancié via une interface de contrôle unifiée pour tous les clients.
Selon un autre aspect, l'invention vise aussi un procédé mis en œuvre par un client pour définir des politiques de contrôle d'accès dans un système informatique apte à allouer dynamiquement à 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. Ce procédé comprend :
— une étape de définition d'un modèle primaire de contrôle d'accès et d'une politique primaire de contrôle d'accès basée sur ce modèle de contrôle d'accès pour ledit client ; — une étape de définition d'au moins un modèle secondaire de contrôle d'accès et d'au moins une politique secondaire de contrôle d'accès basée sur ce modèle secondaire de contrôle d'accès pour ledit client ; et
— une étape de fourniture desdits modèles primaire et secondaire de contrôle d'accès et desdites politiques primaire et secondaire de de contrôle d'accès audit système informatique, lesdites politiques étant destinées à être appliquées aux requêtes d'accès émises par ledit client pour contrôler un accès d'un utilisateur dudit client à au moins une desdites ressources, la politique primaire de contrôle d'accès étant définie par une instance d'un méta-modèle comprenant une instruction pour rediriger la requête vers la politique secondaire lorsque l'accès est refusé. Dans un mode de réalisation particulier, il est proposé un procédé mis en œuvre par un client pour définir des politiques de contrôle d'accès dans un système informatique apte à allouer dynamiquement à 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. Ce procédé comprend :
— une étape de définition d'un modèle primaire de contrôle d'accès et d'une politique primaire de contrôle d'accès basée sur ce modèle de contrôle d'accès pour ledit client ;
— une étape de définition d'au moins un modèle secondaire de contrôle d'accès et d'au moins une politique secondaire de contrôle d'accès basée sur ce modèle secondaire de contrôle d'accès pour ledit client, ladite politique secondaire de contrôle d'accès pouvant être mise en œuvre par ladite politique primaire de contrôle d'accès ; et
— une étape de fourniture desdits modèles primaire et secondaire de contrôle d'accès et desdites politiques primaire et secondaire de de contrôle d'accès audit système informatique , lesdites politiques étant destinées à être appliquées aux requêtes d'accès émises par ledit client pour contrôler un accès d'un utilisateur dudit client à au moins une desdites ressources.
Dans un mode de réalisation, ce procédé de définition de politiques de contrôle d'accès est remarquable en ce qu'il comporte :
une étape d'obtention d'un méta-modèle fourni par le système informatique 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 ; et en ce que
■ ledit modèle primaire de contrôle d'accès et ladite politique primaire de contrôle d'accès sont définis par une première instance dudit méta-modèle ; et en ce que
ledit au moins un modèle secondaire de contrôle d'accès et ladite politique secondaire de contrôle d'accès basée sur ce modèle sont définis par une deuxième instance dudit méta- modèle.
Corrélativement, l'invention concerne un dispositif d'un client d'un système informatique apte à allouer dynamiquement à 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 . Ce dispositif comprend :
— un module de définition d'un modèle primaire de contrôle d'accès et d'une politique primaire de contrôle d'accès basée sur ce modèle de contrôle d'accès,
— au moins un module de définition d'au moins un modèle secondaire de contrôle d'accès et d'une politique secondaire 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 lesdits modèles primaire et secondaire de contrôle d'accès et lesdites politiques primaire et secondaire de contrôle d'accès audit système informatique, lesdites politiques étant destinées à être appliquées aux requêtes d'accès émises par ledit client pour contrôler un accès d'un utilisateur dudit client à au moins une desdites ressources.
Dans un mode de réalisation particulier, ce dispositif comprend :
— un module de définition d'un modèle primaire de contrôle d'accès et d'une politique primaire de contrôle d'accès basée sur ce modèle de contrôle d'accès,
— au moins un module de définition d'au moins un modèle secondaire de contrôle d'accès et d'une politique secondaire 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 lesdits modèles primaire et secondaire de contrôle d'accès et lesdites politiques primaire et secondaire de contrôle d'accès audit système informatique , lesdites politiques étant destinées à être appliquées aux requêtes d'accès émises par ledit client pour contrôler un accès d'un utilisateur dudit client à au moins une desdites ressources.
Dans un mode particulier de réalisation, ce dispositif est caractérisé en ce qu'il comporte :
— un module d'obtention configuré pour obtenir un méta-modèle fourni par le système informatique 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 ; et en ce que
ledit modèle primaire de contrôle d'accès et ladite politique primaire de contrôle d'accès sont définis par une première instance dudit méta-modèle ; et en ce que
ledit au moins un modèle secondaire de contrôle d'accès et ladite politique secondaire de contrôle d'accès basée sur ce modèle sont définis par une deuxième instance dudit méta- modèle.
Le procédé de définition de politiques de contrôle d'accès et le dispositif du client du système informatique bénéficient des mêmes avantages cités précédemment que le procédé de gestion et le système informatique.
Dans un mode particulier de réalisation, les différentes étapes du procédé de gestion et/ou du procédé de définition de politiques de contrôle d'accès 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 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 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 définition de politiques de contrôle d'accès 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 tel que décrit précédemment, 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 ; et
— une pluralité de dispositifs des clients du système informatique tels que décrits précédemment.
On peut également envisager, dans d'autres modes de réalisation, que le procédé de gestion, le procédé de définition de politiques de contrôle d'accès, le système informatique, le dispositif d'un client du système informatique 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 et des dispositifs clients du système informatique, conformes à l'invention ;
— la figure 2A représente l'architecture matérielle sur laquelle s'appuie le système informatique de la figure 1 ;
— la figure 2B représente différents éléments fonctionnels du système informatique 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é de définition de politiques d'accès 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 ;
— 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é de définition de politiques d'accès selon l'invention tel qu'il est mis en œuvre par chaque dispositif client de la figure 1 ; et
— la figure 6 illustre le mécanisme de chaînage des politiques de sécurité dans un mode particulier de réalisation de l'invention.
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 (par exemple 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 au moins un modèle de contrôle d'accès
ACMn et au moins 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 première instance du méta-modèle META fournie par le client CLn, cette première instance définissant un modèle primaire de contrôle d'accès ACMPn et une politique primaire de contrôle d'accès ACPPn basée sur ce modèle primaire de contrôle d'accès définies par le client CLn et au moins une deuxième instance du méta-modèle META fournie par le client CLn, cette deuxième instance définissant un modèle secondaire de contrôle d'accès ACMSn et une politique secondaire de contrôle d'accès ACSPn basée sur ce modèle secondaire de contrôle ; et
— un module de sécurité 2C configuré pour appliquer, pour chaque client CLn, les politiques primaire ACPPn et secondaire(s) ACPSn de contrôle d'accès définies 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 (par exemple dans un centre 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 interface unifiée de contrôle 9 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é de définition de politiques de contrôle d'accès 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 unifiée de contrôle 9) le méta-modèle META fourni par le système informatique en nuage 2 ;
— un module de définition 3B, configuré pour instancier (générer ou encore construire) le méta- modèle META de manière à créer :
o une première instance du méta-modèle définissant un modèle primaire de contrôle d'accès ACMPn et une politique primaire de contrôle d'accès ACPPn basée sur ce modèle de contrôle d'accès sélectionnés par le client CLn et ;
o au moins une deuxième instance du méta-modèle définissant un modèle secondaire de contrôle d'accès ACMSn et une politique secondaire de contrôle d'accès ACPSn basée sur ce modèle de contrôle d'accès; et
— un module de fourniture 3C, configuré pour fournir ces instances (autrement dit pour fournir le modèle primaire de contrôle d'accès ACMPn, la politique primaire de contrôle d'accès ACPPn, le ou les modèles secondaires de contrôle d'accès ASMSn et la ou les politiques secondaires de contrôle d'accès ACPSn) 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é de définition de politiques de contrôle d'accès 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 de contrôle d'accès et un répertoire PR (pour « Policy Repository ») dans lequel sont stockées les politiques de contrôle 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 primaire de contrôle d'accès ACMPn, d'une politique primaire associée ACPPn, d'au moins un modèle secondaire de contrôle d'accès ACMSn et d'une politique secondaire associée ACPPn 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 ACMPn, ACMSn et chaque client CLn sont stockées dans le module PIP, tandis que les règles définissant les politiques de contrôle d'accès APCPn et APCSn 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 les politiques de contrôle d'accès ACPPn, ACPSn et les modèles de contrôle d'accès ACMPn et ACMSn définis pour ce client est intégré dans le module PDP.
Dans le mode de réalisation décrit ici, le système informatique en nuage 2 s'appuie, 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 primaire et secondaire(s) de contrôle d'accès et les modèles primaire et secondaire(s) 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 ses modèles de contrôle d'accès ACMPn, ACMSn et ses politiques de contrôle d'accès ACPPn, ACPSn. Les modèles de contrôle d'accès sont par exemple conformes à des modèles existants tels que RBAC, ORBAC, MLS, etc.
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 au moins une instruction 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 au moins 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 est définie de sorte à fournir au moins une instruction élaborée en fonction de 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 ; 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.
Conformément à l'invention, une instruction issue d'une règle ou d'une métarègle comprend :
— suite à une requête d'accès, une autorisation ou un refus d'un accès à une ressource déterminée allouée au client par le système informatique ; ou — une mise à jour d'au moins un attribut de ladite requête d'accès et de redirection de ladite requête d'accès mise à jour vers une politique de contrôle d'accès pour permettre le chaînage des politiques.
L'instanciation des métadonnées et des métarègles permet de créer les modèles primaire ACMPn et secondaire(s) ACMSn de contrôle d'accès. L'instanciation des données, des règles, du périmètre et de l'ensemble de valeurs permet de définir les politiques primaire ACPPn et secondaires ACPSn de contrôle d'accès qui s'appuient sur ces modèles de contrôle d'accès ACMPn et ACMSn.
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 primaires ou secondaires 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, MLS, session ou délégation 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 dans ce mode de réalisation de l'invention 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 ses propres modèles de contrôle d'accès, de définir et de chaîner ses propres politiques de contrôle d'accès et 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é de définition des politiques de contrôle d'accès 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, ses politiques primaire ACPPn et secondaire(s) ACPSn de contrôle d'accès et les modèles primaire ACMPn et secondaire(s) ACMSn de contrôle d'accès ACMn sur lesquels se basent ces politiques.
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 les politiques 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 de définition 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 primaire de contrôle d'accès ACMPn et la politique primaire ACPPn de contrôle d'accès ACPn basée sur ce modèle qu'il souhaite appliquer aux ressources Rn qui lui sont allouées (étape E30). Puis, le client CLn, via le module de définition 3B, instancie le méta-modèle META de sorte à créer un ou plusieurs modèles secondaires de contrôle d'accès ACMSn, et la ou les politique(s) secondaire(s) ACPSn de contrôle d'accès ACPn basées sur ces modèles (étape E35).
A cet effet, le client CLn renseigne (i.e. paramètre ou encore configure), via le module de définition 3B, pour chaque modèle primaire ou secondaire les différents éléments du méta- modèle META dans l'interface 9.
Trois exemples sont donnés ci-après à titre illustratif pour montrer comment le client CLn via le module de définition 3B peut configurer les éléments du méta-modèle META pour créer un modèle primaire de contrôle d'accès de type RBAC et deux modèles secondaires de contrôle d'accès de type session et délégation.
On considère tout d'abord que 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 primaire de type RBAC :
— il définit comme périmètre du modèle ACMPn 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 type action ;
— 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 première 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 ;
— lorsque l'accès n'est pas autorisé, il définit comme deuxième règle la règle suivante : « si la catégorie « rôle » est « employée », la ressource requise est identifiée par « vmO » et la catégorie « action-type » est « vm-action » alors l'instruction est de vérifier si une caractéristique Session du modèle RBAC est non activée pour l'utilisateur et alors d'envoyer la requête à la politique secondaire Session. Si une caractéristique Session est activée pour l'utilisateur dans la requête, alors le traitement se poursuit avec la règle suivante. Cette deuxième règle fournit une instruction de redirection d'une requête de contrôle d'accès vers la politique secondaire Session ;
— si l'accès est toujours refusé, il définit comme troisième règle la règle suivante : « quelle que soit la valeur de la catégorie « rôle », la ressource requise est identifiée par « vmO » et la catégorie « action-type » est « vm-action » alors l'instruction est de vérifier si une caractéristique Délégation du modèle RBAC est non activée pour l'utilisateur dans la requête et alors d'envoyer la requête à la politique secondaire Délégation. Si une caractéristique
Délégation est activée pour l'utilisateur dans la requête, alors l'accès est refusé. Cette troisième règle fournit une instruction de redirection d'une requête de contrôle d'accès vers la politique secondaire Délégation ;
— 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, sauf en cas de délégation de l'utilisateur userO.
On considère ensuite que le client CLn instancie le méta-modèle META de la façon suivante pour créer un premier modèle de contrôle d'accès secondaire « Session » de type session :
— il définit comme périmètre du modèle Session les entités suivantes : o pour les sujets, deux utilisateurs « userO » et « userl » ;
o pour les objets, deux rôles « admin » (administrateur) et « employée » (employé) ; o pour les actions, une action « activate » d'activation de rôle et une action « desactivate » de désactivation de rôle ;
il définit comme métadonnées les catégories d'attributs suivantes :
o pour les sujets, une catégorie « subjectid» regroupant des attributs de type sujet ; o pour les objets, une catégorie « rôle » regroupant des attributs de type rôle;
o pour les actions, une catégorie « session-action » regroupant des attributs de type action ;
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 « subjectid», les valeurs userO et userl ;
o pour la catégorie « rôle », les valeurs « admin » (administrateur) et « employée » (employé) ;
o pour la catégorie « session-action », les valeurs « activate » et « desactivate » il définit comme métarègle, une métarègle identifiant les catégories d'attributs « subjectid », « rôle » et « session-action » ;
il définit une première règle suivante : « si la catégorie « subjectid » est « userO», le rôle est « admin » (administrateur) et la catégorie « session-action» est « activate» alors l'instruction est d'ajouter le rôle pour l'utilisateur dans la requête et d'envoyer la requête à la politique primaire RBAC. Cette règle fournit une instruction de mise à jour d'au moins un attribut de la requête de contrôle d'accès et une instruction de redirection d'une requête de contrôle d'accès vers la politique primaire RBAC ;
il définit une deuxième règle suivante : « si la catégorie « subjectid » est « userl», le rôle est « employée » (employé) et la catégorie « session-action» est « desactivate» alors l'instruction est de retirer le rôle pour l'utilisateur dans la requête et d'envoyer la requête à la politique primaire RBAC. Cette règle fournit une instruction de mise à jour d'au moins un attribut de la requête de contrôle d'accès et une instruction de redirection d'une requête de contrôle d'accès vers la politique primaire RBAC ;
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 userO de la catégorie SubjectID ;
o à l'utilisateur userl, la valeur userl de la catégorie SubjectID ;
o à l'objet admin, la valeur « admin» de la catégorie « rôle » ;
o à l'objet employée, la valeur « employée» de la catégorie « rôle » ;
o à l'action activate, la valeur « activate» de la catégorie « session-action » ; et
o à l'action desactivate, la valeur « desactivate» de la catégorie « session-action ». Ainsi, ce modèle Session et la politique de contrôle d'accès créés par le client CLn à partir du méta-modèle META permettent d'activer et de désactiver temporairement le rôle de l'utilisateur.
On considère enfin que le client CLn instancie le méta-modèle META de la façon suivante pour créer un deuxième modèle de contrôle d'accès secondaire « Délégation » de type délégation:
— il définit comme périmètre du modèle Délégation les entités suivantes :
o pour les sujets, l'utilisateur « userl » ;
o pour les objets, le rôle « userO » ;
o pour les actions, une action « delegate» de délégation de rôle ;
— il définit comme métadonnées les catégories d'attributs suivantes :
o pour les sujets, une catégorie « subjectid» regroupant des attributs de type sujet ; o pour les objets, une catégorie « delegated » regroupant des attributs de type rôle; o pour les actions, une catégorie « delegation-action » regroupant des attributs de type action ;
— 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 « subjectid», la valeur « userl » ;
o pour la catégorie « delegated », la valeur « userO » ;
o pour la catégorie « delegation-action », la valeur « delegate » ;
— il définit comme métarègle, une métarègle identifiant les catégories d'attributs « subjectid », « delegated » et « delegated-action » ;
— il définit une règle suivante : « si la catégorie « subjectid » est « userl», la catégorie « delegated » est « userO » et la catégorie « delegation-action» est « delegate» alors l'instruction est d'ajouter le rôle de userO pour l'utilisateur userl dans la requête et d'envoyer la requête à la politique primaire RBAC. Cette règle fournit une instruction de mise à jour des paramètres de la requête de contrôle d'accès et une instruction de redirection d'une requête de contrôle d'accès vers la politique primaire RBAC ;
— 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 userO de la catégorie Delegated ;
o à l'utilisateur userl, la valeur userl de la catégorie SubjectID ;
o à l'action delegate, la valeur delegate de la catégorie « delegation-action».
Ainsi, ce modèle Délégation et la politique de contrôle d'accès créés par le client CLn à partir du méta-modèle META permettent d'établir temporairement une relation de confiance entre deux utilisateurs, le premier utilisateur délégant temporairement son rôle au deuxième utilisateur. 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 primaire de contrôle d'accès ACMPn et la politique primaire de contrôle d'accès ACPPn définis par le module de définition 3B du dispositif 3-n constituent une instance du méta-modèle META au sens de l'invention. De même, chaque modèle secondaire de contrôle d'accès ACMSn et la politique secondaire de contrôle d'accès ACPSn associée définis par le module de définition 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), les politiques primaire et secondaire(s) de contrôle d'accès ACPPn, ACPSn définies 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.
En référence à la figure 6, nous allons maintenant décrire un exemple de mise en œuvre d'un chaînage de politiques de sécurité. Dans cet exemple, on considère que le PDP définit la politique primaire de contrôle d'accès de type RBAC et les deux politiques secondaires de contrôle d'accès de type Session et de type Délégation décrites précédemment.
On considère dans cet exemple que le PEP envoie au PDP, au cours d'une étape Fl, une requête par laquelle l'utilisateur userl de type « employée » demande à démarrer une ressource virtuelle vmO.
Le PDP reçoit la requête du PEP, applique la politique primaire de contrôle d'accès de type RBAC en y insérant les attributs {sujet, objet, action} :
pour le sujet, le rôle de userl à savoir « employée » ;
pour l'objet, l'identifiant vmO de la ressource virtuelle concernée ;
pour l'action, la valeur « start ».
Le PDP vérifie alors (étape F2) sur la base des règles de la politique primaire RBAC si l'utilisateur userl a l'autorisation de démarrer la ressource virtuelle vmO. Si cette action était autorisée, le PDP renverrait une réponse positive au PEP (étape F3). Mais dans cet exemple, l'application de la première règle de la politique de contrôle d'accès RBAC refuse le démarrage de la machine virtuelle vmO par l'utilisateur userl car pour userl, la valeur « employée » a été assignée dans le périmètre du modèle de contrôle d'accès et conformément à la première règle de contrôle d'accès définie, l'instruction est « accès accepté » uniquement si la catégorie « rôle » est « admin ». La requête est par conséquent transférée (étape F4) pour traitement par la première politique secondaire, à savoir, la politique Session.
Le PDP vérifie (étape F5) en appliquant la politique Session si le rôle « employée » a été activé pour l'utilisateur userl. Si c'est le cas, par application des règles de cette politique, la requête est modifiée en y retirant le rôle « employée » (étape F6), puis redirigée (étape F7) vers le PDP pour application de la politique primaire de contrôle d'accès de type RBAC.
Le PDP vérifie (étape F8) en appliquant la politique primaire de contrôle d'accès RBAC sur la base de la requête d'accès modifiée si l'autorisation peut maintenant être donnée à l'utilisateur userl de démarrer la machine virtuelle vmO. Comme ce n'est pas le cas, la requête est par conséquent transférée (étape F9) pour traitement par la deuxième politique secondaire, à savoir, la politique Délégation. Conformément à la règle de cette politique, si l'action de délégation a été activée, la requête est modifiée (étape F10) pour ajouter le rôle de userO pour l'utilisateur userl de sorte à ce que userO délègue temporairement ses droits à userl. La requête mise à jour est redirigée (étape Fil) pour application de la politique primaire RBAC qui peut finalement autoriser le démarrage de la machine virtuelle vmO par userl selon les droits attribués à userO.
Dans le mode de réalisation décrit précédemment, les modèles primaire et secondaire(s) de contrôle d'accès et les politiques primaire et secondaire(s) de contrôle d'accès sont obtenus par instanciation d'un même méta-modèle.
L'invention n'est cependant pas limitée à cette caractéristique, les modèles primaire et secondaire(s) de contrôle d'accès et les politiques primaire et secondaire(s) de contrôle d'accès peuvent être obtenus ou définis indépendamment les uns des autres, par instanciations de méta- modèles différents, ou directement, sans passer par un méta-modèle.
Dans le mode de réalisation décrit précédemment, la politique primaire de contrôle d'accès est de type RBAC et les politiques secondaires de contrôle d'accès sont de type Session et Délégation à savoir des caractéristiques avancées au sens de RBAC.
II ne s'agit que d'un exemple, car comme dit précédemment l'invention ne pose aucune limite quant aux types des politiques primaire et secondaire(s) de contrôle d'accès. La politique primaire de contrôle d'accès peut aussi être une caractéristique avancée au sens de RBAC par exemple de type session ou délégation et la ou les politiques secondaires de sécurité peuvent être de type RBAC, OrBAC, ACL, DTE, ABAC, MLS.

Claims

REVENDICATIONS
1. Procédé de gestion d'un système informatique (2), apte à allouer dynamiquement à une pluralité de clients (CL1,...,CLN) des ressources informatiques et réseaux (RESS), chaque client (CLn) é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, ledit procédé comprenant, pour au moins un client du système informatique :
— une étape de réception (E40), en provenance dudit client, d'un modèle primaire de contrôle d'accès et d'une politique primaire de contrôle d'accès basée sur ce modèle primaire de contrôle d'accès ;
— une étape de réception (E40), en provenance dudit client, d'au moins un modèle secondaire de contrôle d'accès et d'une politique secondaire de contrôle d'accès basée sur ce modèle secondaire de contrôle d'accès; et
— une étape d'application (E50) desdites politiques primaire et secondaire de contrôle d'accès à au moins une requête d'accès émise par ledit client pour contrôler un accès d'un utilisateur du client à au moins une ressource allouée au client par le système informatique, la politique primaire de contrôle d'accès étant définie par une instance d'un méta-modèle comprenant une instruction pour rediriger la requête vers la politique secondaire lorsque l'accès est refusé.
2. Procédé de gestion d'un système informatique (2) selon la revendication 1, ledit procédé étant caractérisé en ce qu'il comporte :
— une étape de fourniture (E20), audit client, d'un méta-modèle (META) 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 basée sur ce modèle ; en ce que
— ledit modèle primaire de contrôle d'accès et ladite politique primaire de contrôle d'accès sont définis par une première instance dudit méta-modèle ; et en ce que
— ledit au moins un modèle secondaire de contrôle d'accès et ladite politique secondaire de contrôle d'accès basée sur ce modèle sont définis par une deuxième instance dudit méta- modèle.
3. Procédé de gestion selon la revendication 2 dans lequel 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 ;
— 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 une ou plusieurs catégories d'attributs définies par les métadonnées et utilisées pour fournir au moins 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,
— ladite instruction comprenant :
— une autorisation ou un refus d'un accès à une ressource déterminée allouée au client par le système informatique ; ou
— une redirection de ladite requête d'accès vers une politique de contrôle d'accès.
4. Procédé selon la revendication 3 dans lequel ladite pluralité d'entités comprend au moins un sujet, et/ou au moins un objet, et/ou au moins une action.
5 Procédé selon la revendication 3 ou 4 dans lequel au moins une catégorie d'attributs définie pour une entité est choisie parmi :
— un niveau de sécurité ;
— un rôle ;
— un type ; et
— un domaine.
6. Procédé mis en œuvre par un client pour définir des politiques de contrôle d'accès
(CL1,...,CLN) dans un système informatique (2) apte à allouer dynamiquement à une pluralité de clients (CL1,...,CLN) des ressources informatiques et réseaux (RESS), 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 , ledit procédé comprenant :
— une étape (E30) de définition d'un modèle primaire de contrôle d'accès et d'une politique primaire de contrôle d'accès basée sur ce modèle de contrôle d'accès pour ledit client ;
— une étape (E35) de définition d'au moins un modèle secondaire de contrôle d'accès et d'au moins une politique secondaire de contrôle d'accès basée sur ce modèle secondaire de contrôle d'accès pour ledit client ; et
— une étape de fourniture (E40) desdits modèles primaire et secondaire de contrôle d'accès et desdites politiques primaire et secondaire de de contrôle d'accès audit système informatique, lesdites politiques étant destinées à être appliquées aux requêtes d'accès émises par ledit client pour contrôler un accès d'un utilisateur dudit client à au moins une desdites ressources, la politique primaire de contrôle d'accès étant définie par une instance d'un méta-modèle comprenant une instruction pour rediriger la requête vers la politique secondaire lorsque l'accès est refusé.
7. Procédé de définition de politiques de contrôle d'accès selon la revendication 6, ledit procédé étant caractérisé en ce qu'il comporte :
— une étape d'obtention (E20) d'un méta-modèle (META) fourni par le système informatique 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 ; et en ce que
— ledit modèle primaire de contrôle d'accès et ladite politique primaire de contrôle d'accès sont définis par une première instance dudit méta-modèle ; et en ce que
— ledit au moins un modèle secondaire de contrôle d'accès et ladite politique secondaire de contrôle d'accès basée sur ce modèle sont définis par une deuxième instance dudit méta- modèle.
8. Procédé de définition de politiques de contrôle d'accès selon la revendication 7 dans lequel 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 ;
— 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 au moins une instruction conforme à la politique de contrôle d'accès du client ;
— au moins une règle de contrôle d'accès définissant 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,
— ladite instruction comprenant :
— une autorisation ou un refus d'un accès à une ressource déterminée allouée au client par le système informatique ; ou
— une redirection de ladite requête d'accès vers une politique de contrôle d'accès.
9. Programme d'ordinateur (PROGl,PROG2) comportant des instructions pour l'exécution des étapes du procédé de gestion selon l'une quelconque des revendications 1 à 5 ou du procédé de définition de politiques de contrôle d'accès selon l'une quelconque des revendications 6 à 8 lorsque ledit programme est exécuté par un ordinateur.
10. Système informatique (2) apte à allouer dynamiquement à une pluralité de clients (CL1,...,CLN) des ressources informatiques et réseaux (RESS), chaque client (CLn) é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 , ledit système comprenant :
— un module de réception (2B), apte à recevoir, en provenance dudit client, un modèle primaire de contrôle d'accès et une politique primaire de contrôle d'accès basée sur ce modèle primaire de contrôle d'accès, ledit module de réception étant en outre apte à recevoir en provenance dudit client, au moins un modèle secondaire de contrôle d'accès et une politique secondaire de contrôle d'accès basée sur ce modèle secondaire de contrôle d'accès ; et
— un module de sécurité (2C) configuré pour appliquer lesdites politiques primaire et secondaire de contrôle d'accès à au moins une requête d'accès émise par ledit client pour contrôler un accès d'un utilisateur du client à au moins une ressource allouée au client par le système informatique, la politique primaire de contrôle d'accès étant définie par une instance d'un méta-modèle comprenant une instruction pour rediriger la requête vers la politique secondaire lorsque l'accès est refusé.
11. Système informatique (2) selon la revendication 10, caractérisé en ce qu'il comporte:
- un module de fourniture (2A), configuré pour fournir audit client, un méta-modèle (META) 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 ; en ce que
ledit modèle primaire de contrôle d'accès et ladite politique primaire de contrôle d'accès sont définis par une première instance dudit méta-modèle ; et en ce que
ledit au moins un modèle secondaire de contrôle d'accès et ladite politique secondaire de contrôle d'accès basée sur ce modèle sont définis par une deuxième instance dudit méta- modèle.
12. Dispositif (3-l,...,3-N) d'un client (CL1,...,CLN) d'un système informatique (2) apte à allouer dynamiquement à une pluralité de clients des ressources informatiques et réseaux (RESS), 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, ledit dispositif comprenant : — un module de définition (3B) d'un modèle primaire de contrôle d'accès et d'une politique primaire de contrôle d'accès basée sur ce modèle de contrôle d'accès,
— au moins un module de définition (3B) d'au moins un modèle secondaire de contrôle d'accès et d'une politique secondaire de contrôle d'accès basée sur ce modèle de contrôle d'accès ; et — un module de fourniture (3C), configuré pour fournir lesdits modèles primaire et secondaire de contrôle d'accès et lesdites politiques primaire et secondaire de contrôle d'accès audit système informatique, lesdites politiques étant destinées à être appliquées aux requêtes d'accès émises par ledit client pour contrôler un accès d'un utilisateur dudit client à au moins une desdites ressources.
13. Dispositif selon la revendication 12, ledit dispositif étant caractérisé en ce qu'il comporte :
— un module d'obtention (3A) configuré pour obtenir un méta-modèle (META) fourni par le système informatique 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 ; et en ce que
ledit modèle primaire de contrôle d'accès et ladite politique primaire de contrôle d'accès sont définis par une première instance dudit méta-modèle ; et en ce que
ledit au moins un modèle secondaire de contrôle d'accès et ladite politique secondaire de contrôle d'accès basée sur ce modèle sont définis par une deuxième instance dudit méta- modèle.
14. Système (1) comprenant :
un système informatique (2) selon la revendication 10 ou 11, apte à allouer dynamiquement à 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 ; et
une pluralité de dispositifs des clients (3-l,...,3-N) du système informatique conformes à la revendication 12 ou 13.
15. Fichier informatique (FILE) 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 apte à allouer dynamiquement à 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é 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,
— ladite instruction comprenant :
— une autorisation ou un refus d'un accès à une ressource déterminée allouée au client par le système informatique ; ou
— une redirection de ladite requête vers une politique de contrôle d'accès.
PCT/FR2018/050941 2017-04-21 2018-04-13 Procédé de gestion d'un système informatique à allocation dynamique de ressources WO2018193190A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1753497A FR3065555B1 (fr) 2017-04-21 2017-04-21 Procede de gestion d'un systeme informatique a allocation dynamique de ressources
FR1753497 2017-04-21

Publications (1)

Publication Number Publication Date
WO2018193190A1 true WO2018193190A1 (fr) 2018-10-25

Family

ID=59649819

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2018/050941 WO2018193190A1 (fr) 2017-04-21 2018-04-13 Procédé de gestion d'un système informatique à allocation dynamique de ressources

Country Status (2)

Country Link
FR (1) FR3065555B1 (fr)
WO (1) WO2018193190A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8813174B1 (en) * 2011-05-03 2014-08-19 Symantec Corporation Embedded security blades for cloud service providers
EP2819052A1 (fr) * 2013-06-25 2014-12-31 Orange Procédé et serveur de traitement d'une requête d'accès d'un terminal à une ressource informatique

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8813174B1 (en) * 2011-05-03 2014-08-19 Symantec Corporation Embedded security blades for cloud service providers
EP2819052A1 (fr) * 2013-06-25 2014-12-31 Orange Procédé et serveur de traitement d'une requête d'accès d'un terminal à une ressource informatique

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
D.F FERRAIOLO; R. SANDHU; S. GAVRILA; D.R.KUHN; R.CHANDRAMOULI: "Proposed nist standard for role-based access control", ACM TRANSACTIONS ON INFORMATION AND SYSTEM SECURITY, 2001
SALIM KHAMADJA ET AL: "Designing flexible access control models for the cloud", SECURITY OF INFORMATION AND NETWORKS, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, 26 November 2013 (2013-11-26), pages 225 - 232, XP058036026, ISBN: 978-1-4503-2498-4, DOI: 10.1145/2523514.2527005 *

Also Published As

Publication number Publication date
FR3065555A1 (fr) 2018-10-26
FR3065555B1 (fr) 2019-12-06

Similar Documents

Publication Publication Date Title
US10848520B2 (en) Managing access to resources
EP2819052B1 (fr) Procédé et serveur de traitement d'une requête d'accès d'un terminal à une ressource informatique
EP3612970A1 (fr) Procédé de gestion d'un système informatique en nuage
EP3008872B1 (fr) Procédé d'authentification d'un terminal par une passerelle d'un réseau interne protégé par une entité de sécurisation des accès
US20190013995A1 (en) Defining configurable characteristics of a product and associating configuration with enterprise resources
US20140317697A1 (en) System and method of secure sharing of resources which require consent of multiple resource owners using group uri's
US20190108359A1 (en) Use case driven granular application and browser data loss prevention controls
Kaluvuri et al. SAFAX–an extensible authorization service for cloud environments
EP2881886B1 (fr) Procédé d'établissement d'une relation de confiance pour le partage de ressources entre deux locataires dans un réseau en nuage
WO2006100409A1 (fr) Systeme et procede de transmission de messages pour un ensemble de dispositifs de communication
EP3772844B1 (fr) Dispositif d'interopérabilité pour interconnecter plusieurs réseaux de communication, système et procédé associés
WO2018193190A1 (fr) Procédé de gestion d'un système informatique à allocation dynamique de ressources
US20230179634A1 (en) Secure policy distribution in a cloud environment
FR3103990A1 (fr) Procédés et applications de contrôle d’accès distribué à un réseau de télécommunications
WO2020016504A1 (fr) Dispositifs et procedes de gestion d'un attachement d'un dispositif de communication a un reseau d'un operateur
EP2961130B1 (fr) Procede de gestion de controle d'acces dans un reseau en nuage
FR3007865A1 (fr) Systeme et procede de controle d'acces a un ensemble de ressources d'un systeme informatique en nuage
US20230269229A1 (en) Protecting Organizations Using Hierarchical Firewalls
FR3016227A1 (fr) Procede de gestion des politiques de securite d'une pluralite de locataires appartenant a un meme nuage
EP2038797B1 (fr) Unite et procede de gestion d'au moins un canal dans une session d'acces a un service dans un reseau
FR3131674A1 (fr) Système de dissémination de contenus dans une fédération de réseaux ; Procédé de dissémination et produit programme d'ordinateur associés
White et al. Context driven, user-centric access control for smart spaces
WO2018234662A1 (fr) Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration
WO2008135692A1 (fr) Gestion d'acces a des ressources d'un systeme d'exploitation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18720333

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18720333

Country of ref document: EP

Kind code of ref document: A1