[go: up one dir, main page]

WO1999035552A1 - Procede d'autorisation d'acces a des droits d'execution de commandes privilegiees - Google Patents

Procede d'autorisation d'acces a des droits d'execution de commandes privilegiees Download PDF

Info

Publication number
WO1999035552A1
WO1999035552A1 PCT/FR1998/002889 FR9802889W WO9935552A1 WO 1999035552 A1 WO1999035552 A1 WO 1999035552A1 FR 9802889 W FR9802889 W FR 9802889W WO 9935552 A1 WO9935552 A1 WO 9935552A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
privileged
request
command
commands
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/FR1998/002889
Other languages
English (en)
Inventor
Gérard Selles
Gérard Sitbon
François Urbain
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
Original Assignee
Bull SAS
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
Priority claimed from FR9716698A external-priority patent/FR2773235B1/fr
Application filed by Bull SAS filed Critical Bull SAS
Priority to EP98963639A priority Critical patent/EP0961961A1/fr
Publication of WO1999035552A1 publication Critical patent/WO1999035552A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1483—Protection against unauthorised use of memory or access to memory by checking the subject access rights using an access-table, e.g. matrix or list
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • the present invention relates to a method for authorizing access to commands or objects on a computer system.
  • the computer system can be a system whose environment is of the distributed or local type.
  • the system includes a plurality of users who own privileges to execute privileged commands.
  • the rights include writing, reading from a file and executing a command.
  • the invention is particularly applicable to three categories of users:
  • the invention applies to any kind of operating system.
  • the UNIX (registered trademark) operating system is currently the preferred mode of implementing the invention.
  • a file access protection system uses a three-dimensional table, known as a protection matrix, and includes the user, the action, and the purpose of the action. Each element of the array indicates whether or not the user has the right to perform a certain action on a certain object. Privileged commands are assigned to a user.
  • objects are files.
  • the administrator is responsible for the administration and the smooth running of the system. He is responsible for security backups, file access management. It is also responsible for giving each user a name, a user identifier, and a set of privileges, such as privileges to execute privileged commands on files, etc. Privileges correspond to these responsibilities: he has unrestricted access to all directories and files, to all privileged commands, etc.
  • the rights include writing, reading from a file and executing a command.
  • a user has, at a minimum, a name or number, usually called a password, which he gives when he accesses the system.
  • a user can activate commands contained in a file owned by another user.
  • the basic UNIX (Trademark) mechanism known to those skilled in the art, which allows a user to execute a command with the rights of another user is the "su-usemame" command.
  • the term "usemame” is the password or user name identifier of the user whose rights they want to use on privileged orders. During the execution of this command, the real user is no longer the actual user. The user who owns the file becomes the effective user. The user, by invoking the "su-username" command, will have to provide the password of the user who owns the file.
  • Such a mechanism presents another problem when one wants to withdraw rights on privileged commands granted to a user.
  • Such a maneuver involves periodically changing the passwords of each of the file owner or group owners. Changing this password has repercussions which in no way facilitate its memorization by users, especially when the password is shared by several people. Memorizing a password therefore becomes practically impossible.
  • a first object of the invention is to be able to grant users the right to execute privileged commands in a transparent manner while being selective about the allocation of privileges to execute privileged commands.
  • a second aim is to design a process that does not involve any modification of the software components contained in the system.
  • a third aim is to improve the security of access to privileged commands.
  • a fourth aim is the simplicity of use of the method of the invention.
  • the subject of the invention is a method of accessing privileges for executing privileged commands in a computer system, said system comprising at least one group owning privileged commands, said group comprising at least one user having both a password for logging into the system and a user identifier assigned by an administrator, said user issuing requests including at least one command, characterized in that it consists, for a user, in accessing a command privileged of another user through his own user identifier.
  • a computer system comprising at least one group owning the right to execute at least one privileged command, said group comprising at least one user characterized in that it includes a software mechanism for authorizing access to the commands.
  • privileged implementing the method.
  • FIG. 1 is a block diagram of the architecture of a computer system on which the method according to the invention can be applied;
  • Figure 2a is an algorithm illustrating an embodiment of the method for allocating privileges for executing privileged commands in the computer system shown in Figure 1;
  • FIG. 2b is a schematic view of a request and its main parameters according to the present invention.
  • FIG. 3 is a table authorizing access to a file illustrating a variant of the method for authorizing privileges to execute privileged commands
  • FIG. 4 is a block diagram of the architecture of a computer system whose environment is distributed on which the method according to the invention can be applied;
  • FIG. 5 is a view of the links existing between each node
  • FIG. 6 is a view of an authorization table for access to privileged commands.
  • FIG. 1 shows an example of a SYS computer system.
  • three groups GP1, GP2 and GP3 are represented, owners of privileged commands
  • the invention is not limited to three owner groups but applies to any number. It will be assumed, in the following description, that an owner group comprises at least one user.
  • each group GP1 , GP2 and GP3 includes a respective user UT1, UT2 and UT3
  • the privileged commands include, as indicated in the introduction, writing, reading a file and executing a command
  • This system includes an ADM administrator, as defined in the introduction. This administrator assigns rights to privileged commands as well as access rights to files or directories to these different users UT1, UT2 and UT3
  • Each user UT1 -UT3 has a respective user identifier IU1, IU2 and IU3
  • the user identifier is assigned by the ADM administrator of the system and allows the system to recognize implicitly the user connected to the system Users are also assigned a password PW1, PW2 and PW3 for connection to the system without which the user cannot access the system.
  • a user for example UT1 connects to the SYS system by means of his password PW1
  • PW1 Once the connection established, the system authenticates this same user UT1 by means of its user identifier IU1
  • the user UT1 has, from this moment, the possibility of launching a request REQ.
  • This request includes parameters as well as CON content including a request to execute DCP privileged commands
  • the problem is the difficulty for the user UT1 owner or belonging to a group owner of privileged commands to access commands belonging to another group owner than his. Indeed, the mechanisms existing are poorly adapted in terms of memorizing passwords and complicate the task of user UT1 who wishes to use the rights privileged commands from a file owner, for example UT2. In addition, the confidentiality of a password shared by several people is problematic.
  • the method according to the invention consists in that a user, for example UT1, accesses a privileged command from another user, for example UT2, by means of his own user identifier IU1.
  • the method of the invention is implemented by means of a software mechanism for authentication and authorization to access privileges for executing privileged commands, the operation of which appears clearly from the figure. 2a.
  • the method conventionally begins in a step 10 in which a user, for example UT ⁇ , initiates a REQ request.
  • a user for example UT ⁇
  • the REQ request originating from a user is intercepted.
  • the method of the invention consists in verifying, in step 30, that the request REQ sent by the user UT1 is a request for execution of privileged commands DCP.
  • a characteristic of the invention is that each REQ request comprises a parameter PRC characteristic of a request for execution of privileged commands as illustrated in FIG. 2b.
  • the process is activated via the PRC parameter.
  • Activation consists in verifying that the REQ request contains the information necessary to authorize user UT1 to access a privileged command.
  • the method consists in processing only the requests whose content is a request for execution of privileged commands.
  • the method results in a step 40.
  • the method remains inactive and does not process the request REQ.
  • Step 40 indicates the end of the process.
  • the REQ request includes the PRC parameter
  • the process continues and consists in verifying that this REQ request includes the information necessary to authorize a user to access the privileged commands of another user.
  • the method consists in breaking down the request REQ in step 50 and in extracting therein the request for execution of a privileged command DCP which the user UT1 wishes to acquire.
  • the mechanism furthermore implicitly knows the user identifier IU1 of the user UT1.
  • the mechanism includes tables in which we find the identifier of the users authorized to execute privileged commands.
  • the mechanism also includes tables comprising all of the commands for authorizing the execution of privileged commands.
  • the method consists in verifying, in step 70, that the user identifier IU1 of the user UT1 is listed in the tables. If the identifier of the user IU1 is not listed in the tables, the user is not authorized to execute privileged commands and the method consists in transmitting an error message, in step 60, to report on the situation. This error message is unique in order to give no indication of the cause of the failure during an attempted intrusion by any individual and especially by a malicious individual. Otherwise, corresponding to step 80, that is to say when the user identifier is listed in the tables, another analysis is performed.
  • step 90 we have all the information necessary to authorize a user, UT1, to access the privileged commands of another user.
  • the method consists in authorizing, in a transparent manner, the user UT1 to use rights on privileged commands on the account of another user.
  • a user UT1 can launch privileged commands belonging to an owner with the rights of this owner, for example UT2.
  • step 90 writing and / or reading and / or executing of the file bearing the name of the command is authorized.
  • step 100 the method consists in executing the transformation of the initial request into an actual request.
  • the initial request corresponds to the REQ request issued and which has not undergone any processing through the mechanism.
  • the actual request corresponds to the request that has been processed.
  • steps 70 and 80 are the necessary and sufficient conditions to authorize a user to execute privileged commands belonging to another user.
  • the direction of execution of steps 70 and 80 is indifferent.
  • Figure 2b illustrates the parameters making up an initial REQ request.
  • This request includes in its CON content the request for privileges to execute DCP privileged commands that a user wishes to acquire.
  • the DCP request contains a request to execute a single command.
  • the request thus includes, as mentioned previously, a PRC parameter characteristic of a request for execution of privileged commands.
  • this parameter PRC is preferably a prefix which is added to the other parameters that comprise the request REQ. The purpose of this prefix is to easily identify a request including a request to execute a privileged command and activate the process.
  • FIG. 3 illustrates an exemplary embodiment of the tables used during steps 70 and 80 of FIG. 2a.
  • These tables can, in one example, be represented by a three-dimensional table as defined in the introduction to the description.
  • these tables can have a tree structure with a single node called PRC and which corresponds to the PRC prefix of the request.
  • PRC a single node
  • Each node that is not a leaf in the file system structure is a file directory.
  • Under the PRC directory there are two directories.
  • a first REG directory has the role the recording of privileged orders.
  • the second DIST directory will be described later in the description.
  • privileged command description files Under the REG directory, there are privileged command description files.
  • the description files printA and printB are shown.
  • a privileged command is associated with a description file.
  • Each file contains a data structure which contains the operations to be carried out during the transformation of the initial REQ request into an actual request.
  • the printA and printB description files include parameters, among others. These parameters include the owner group to which the privileged command belongs as well as the users authorized to use this privileged command. The role of these files is to transform the initial REQ request, issued by a user, into an actual request.
  • the operations are inter alia, the acquisition of the required rights, the change or not of environment in the case where the systems belong to different environments, the propagation of environment variables like the variables DISPLAY or LANG, known to the skilled in the art, between the departure and arrival environments, call logging, etc.
  • Another DIST directory is used. The role of this directory is to register users authorized to use privileges to execute privileged commands. This directory is attached to the same unique node
  • the DIST directory contains, for example, the identifier IU1-IU3 of the users authorized to execute privileged commands. In another example, this DIST directory can simply contain the names of the users UT1-UT3 authorized to execute privileged commands. Preferably, the DIST directory is made up of named directories, for example, IU1 or IU2 corresponding to the identifier of the users authorized to execute privileged commands. Finally, each directory bearing the name of a user corresponds to at least one file bearing, for example, the name of the command for which it is authorized to be executed. In the example illustrated, we named a printA file associated with the IU1 directory associated with the user UT1.
  • the presence of the identifier IU1 under the directory DIST means, first of all, that the user UT1 has obtained execution execution rights on privileged commands. Then, the presence of the printA file under the IU1 directory means that it has obtained execution rights for the printA command. From this moment, if the user is authorized to execute privileged commands, the process consists in verifying that this printA command has been saved in the REG directory. If this is the case, the printA file is executed and transforms the initial REQ request into an actual request. The method consists in checking under the REG directory, in the description file corresponding to the printA command, that the user in question UT1 is authorized to execute this command. All these steps are carried out transparently for user UT1. If user UT1 is authorized to execute the printA privileged command, the actual request is launched. From this moment, the real user UT1 is no longer the effective user. The effective user is the user UT2 who owns the rights to execute privileged commands.
  • the present invention is applicable to computer systems whose environment is of the distributed type or of the local type.
  • a computer system whose environment is of the distributed type is an environment which operates by means of at least two operating systems linked together via a local type network of LAN type (Local Area Network) or long distance WAN (Wide Area Network) or internet type.
  • LAN type Local Area Network
  • WAN Wide Area Network
  • internet type a computer system whose environment is of the local type is a computer system which operates by means of a single operating system.
  • the system includes three N1-N3 nodes.
  • Each node N1-N3 can comprise at least one respective owner group GP1-GP3 including at least one respective user UT1-UT3, as defined above.
  • user UT1 can launch an APP1 application.
  • this APP1 application is of the software type.
  • the node N1 comprises an application client which is the application APP1.
  • the node N2 includes an SAP application server.
  • RES network the communication protocol of which can be of the TCP-IP (Transport Control Protocol - Internet Protocol) type known to those skilled in the art.
  • TCP-IP Transmission Control Protocol - Internet Protocol
  • a set of software layers is interposed between a node N1 -N3 and the network RES. This set of software layers is based on the OSI (Open System Interconnection) model of the ISO (International Organization for Standardization) layer architecture or the TCP-IP model, known to those skilled in the art.
  • OSI Open System Interconnection
  • ISO International Organization for Standardization
  • Each node includes specific API type programming interfaces for accessing a service known to those skilled in the art.
  • this programming interface is a set of tools made available to programmers intended to standardize the user interface, program control and control of data sent over a network. Developers, when creating software, will search the API programming interface for names of menus and commands, window and dialog models.
  • An API programming interface is generally associated with a library.
  • access rights management is carried out through a centralized access rights management unit.
  • the tables are included on a single node N3.
  • all the tables are included in a BDD database.
  • This BDD database is linked to a SERV database scent.
  • the APP1 application client, the SAP application server, and the basic SERV server data communicate with the network via the respective programming interfaces APM, API2 and API3 as well as software layers which are interposed between each node and the RES network.
  • Protocol Data Unit Protocol Data Unit
  • a user or client of the database queries the BDD database via the SERV server.
  • the dialog that exists between a user and the BDD database is a client / server type dialog.
  • the application client and the application scent work with the database and carry out a series of transactions.
  • the tables are centralized on a node of the system. This centralization of the tables complies with the security criteria of a transaction.
  • Access to the BDD database will be transactional to ensure data atomicity, consistency, isolation, and durability.
  • atomicity means that a transaction must be completely carried out.
  • Data consistency means that the transaction moves a system from one consistent state to another consistent state.
  • Data isolation means that the transaction is not affected by the processing of other transactions.
  • data durability means that changes due to a completed transaction are permanently guaranteed. Clearly, a given transaction either took place definitively or never existed.
  • each node N1-N3 comprises a respective configuration file CFG1-
  • CFG3 which indicates the location of the associated BDD database including all the tables.
  • These configuration files can be name scents, known to those skilled in the art.
  • the choice of the node on which the database is arbitrary. According to another variant, there can be a single configuration file on any node.
  • FIG. 5 schematically illustrates an example of request for access to a privileged command. This figure represents the exchanges of messages between the different nodes of the computer system. This figure includes uni-directional arrows indicating the direction of execution of an action.
  • this first user fills the database with the list of users having read and write rights on this database.
  • these users are limited to read rights in order to check the criteria mentioned above,
  • each node N1-N3 is informed of the position of the database BDD in the computer system. This position is included in the configuration files CFG1-CFG3.
  • a write request is made by the user UT2 of a PRINTA command associated with an application of which he is the owner.
  • the database can include identical command names and identical application names.
  • the administrator When a user launches an order, the administrator must associate, in the tables included in the database, this order with his respective application.
  • the database gives the possibility to a user to write or read information in the database only if it has a unique application identifier in its possession.
  • the database issues, in return, a unique application identifier ID-PRINTA.
  • ID-PRINTA a unique application identifier
  • the user since the user has the unique application identifier, he can write to or read from the database.
  • An example of writing to the database is given by the table shown in FIG. 6. This table is described in the following description.
  • the user UT1 of the node N1 is authorized to use the PrintA command remotely and remotely with the identity of the user UT2 belonging to the group GP2 of the node N2 between 12 noon and 1 pm.
  • the database is updated to update.
  • the user UT1 can launch a request for authorization to execute DDE of a privileged command belonging to a user present on any node of the network.
  • User UT1 wishes to execute the PrintA command of which user UT2 is the owner.
  • the SAP application server is responsible for consulting the BDD database. For this, it accesses the database with the name of the PrintA command accompanied by its unique identifier for ID-PrintA applications for the reasons mentioned above.
  • the DDE request is made.
  • This result can be of binary type "0" or "1” depending on the spatial or temporal constraints associated with a user.
  • the “0” means that the user UT1 does not have the authorization to execute privileged commands.
  • the result “1” means that the user is authorized to execute the privileged command.
  • the user UT1 of the node N1 is authorized to use the PrintA command remotely and remotely with the identity of the user UT2 belonging to the group GP2 of the node N2 between 12 noon and 1 pm. If user UT1 respects the 12-13h calendar, the execution request is authorized. From then on, the command is executed.
  • the network is perfectly secure via a programming interface of the GSS-API type (Generic Security Service - Application Program Interface).
  • GSS-API type programming interface provides security during a transaction between any node and the BDD database. This type of interface provides applications with the possibility of securing their exchanges by offering them mutual authentication, integrity and confidentiality.
  • This programming interface can rely on various security mechanisms such as the DCE (Distributed Computing Environment) mechanism of the organization called OSF (Open Software Foundation), known to those skilled in the art.
  • OSF Open Software Foundation
  • the connection between an SAP application server and the BDD database is secured by means of such a programming interface. Access to the information that flows between the SAP application scent and the BDD database is impossible. A fraudster cannot therefore read or modify the information circulating between the SAP server and the database.
  • the position of the database BDD can be envisaged as a function of the distance which separates the nodes N1-N3.
  • This BDD database can be replicated on a node and be used in reading and not in writing to comply with the criteria of a transaction.
  • the database can be, for example, replicated on node N1.
  • this BDD database is used only for reading. During a replication of the database, it is necessary to modify the configuration files of the nodes concerned.
  • the tables include usage constraints other than the spatial type constraints as defined above. There may be other constraints in the database which aim to contribute to and improve the security of access to said privileged commands. Tables can include time constraints. These constraints are described in connection with FIG. 6 and are explained in the following description. These constraints are added to the spatial constraints of step 30 of FIG. 2a.
  • a table can materialize by means of a two-dimensional table.
  • this table there are several columns:
  • a first column identifies the users whose administrator assigns all or part of the rights to at least one privileged order.
  • This second column includes sub-columns associated with these different rights:
  • a first sub-column includes the name of the user UT2 who belongs to the GP2 group itself undue in the node N2, and who is the owner of the commands which the user UT1, present in the first column, wishes to use.
  • a third sub-column includes the name of the printA command associated with the APP2 application of which the user UT2 is the owner and that the user UT1 is authorized to use.
  • the semantics given to an order are specific to an application thanks to the unique identifier for applications.
  • At least one other sub-column includes a time constraint.
  • constraints may consist in authorizing access to a privileged order for a period of time defined by the administrator.
  • a constraint is noted “calendar”.
  • the application authorizes the user UT1 to use the command associated with the application APP whose owner is the user UT2 belonging to the owner group GP2 of the node N2 between 12 noon and 1 pm. If a request to use a privileged order is made outside of the calendar hours, it is refused and considered a fraudulent request.
  • the administrator completes each row and each column of the table.
  • the ADM administrator intervenes in the allocation of execution rights for privileged orders.
  • This administrator can assign or withdraw rights.
  • the tree structure, defined above, is not, for this purpose, frozen in time, but can instead evolve over time. This evolution consists either of adding branches or deleting branches in the tree structure. In other words, this development corresponds to authorizing, or withdrawing at any time, access rights to privileged orders.
  • the invention allows It is up to a user to directly activate commands and to dynamically acquire the authorization to execute privileged commands without hindering access authorization requests from other users.
  • user UT3 can launch a request including a request for authorization to execute privileged commands.
  • the method consists in removing or granting rights to another user. In other words, the method offers the possibility of solving or avoiding the problems posed by the simultaneous access of several users.
  • the choice of a password PW of a user is the responsibility of the user holder of the password.
  • its renewal is the responsibility of the associated user. Regular renewal is strongly recommended because the longer the period of password use, the greater the risk of being known by third parties.
  • the subject of the invention is a method of accessing privileges for executing privileged commands in a SYS computer system, said system comprising at least one GP1- GP3 group owning privileged commands. , said group comprising at least one respective user UT1-UT3 having both a respective password PW1-PW3 for connection to the SYS system and a respective user identifier IU1-IU3 assigned by an administrator, said user issuing requests REQ including at least one order.
  • the method consists, for a user UT1-UT3, of accessing a privileged command of another user via his own respective user identifier IU1-IU3.
  • the method is activated by the request REQ.
  • Activation consists in verifying that the REQ request contains the information necessary to authorize a user U1-U3 to access a command privileged of another user.
  • the verification of the necessary information consists in verifying in privilege tables of execution of privileged commands granted, both if the user identifier IU1 - IU3 is authorized to use a privileged command and if the user is authorized to execute the privileged command resulting from the REQ request.
  • the activation of the method consists in including a parameter PRC in the request REQ characteristic of a request for execution of privileged command.
  • this additional parameter can be a PRC prefix associated with the REQ request.
  • an administrator can intervene in the system in the allocation of execution rights for privileged orders and that the method consists in granting and / or withdrawing the right to execute a privileged order. to a user UT1 -UT3 through an administrator.
  • the method consists in dynamically acquiring, for a user UT1 -UT3, the right to execute a privileged command.
  • the method consists in acquiring and / or withdrawing the right to execute a privileged command from a user without interfering with a request for execution of the right to execute a privileged command from another user.
  • the method consists in granting and executing the request or in rejecting it with a single error message so as to give no indication of the cause of the failure.
  • the tables are, for example, included in a BDD database.
  • the constraints have a semantics specific to each application and also have a meaning specific to each application.
  • the subject of the invention is a computer system comprising at least one GP1-GP3 group which owns execution rights for at least one privileged command, said group comprising at least one respective user UT1-UT3, characterized in that that it includes a software mechanism for authorizing access to privileged commands implementing the method defined above.
  • the software mechanism according to the invention comprises tables including the identifiers of the users IU1-IU3 authorized to execute privileged commands and the rights to execute corresponding privileged commands.
  • the present invention is applicable in a computer system which has a local or distributed type environment.
  • the invention offers numerous advantages. It allows a user to easily access privileged commands via their own user identifier. A user simply needs to know their own password for logging into the system. The "su-usemame" command no longer needs to exist. In the invention, a request for execution of privileged commands therefore no longer requires the integration of a password in the request. This characteristic complies with the confidentiality and security criteria. In addition, the invention offers the advantage of being selective in the allocation of privileges to execute privileged orders. Indeed, a request concerns only one and only order. In addition, using a file tree allows the mechanism to focus only on processing orders.
  • the administrative part of granting or withdrawing rights to such or such user is easily carried out using a file manager like those proposed by WINDOWS (Trademark) or CDE (Common Desktop Environment) (Trademark).
  • the deletion or addition of rights does not imply the modification of software components contained in the system. This deletion or the addition of rights does not imply either the modification of the associated password.
  • the process is therefore simple to use.
  • the invention also offers the advantage of allowing any computer application to manage in a personalized manner (the semantics granted to an order in the tables is specific to each application) and fine access to privileged orders. It also offers the advantage of homogeneity of use (use of API-type programming interfaces) and administration provided by centralizing information relating to these accesses.

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)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Dans un système informatique (SYS) comportant au moins un groupe (GP1-GP3) propriétaire de commandes privilégiées, ledit groupe comportant au moins un utilisateur respectif (UT1-UT3) possédant à la fois un mot de passe respectif (PW1-PW3) pour la connexion au système (SYS) et un identificateur d'utilisateur respectif (IU1-IU3) attribué par un administrateur (ADM), un utilisateur émet une requête (REQ) incluant au moins une commande et accède à une commande privilégiée d'un autre utilisateur par l'intermédiaire de son propre identificateur d'utilisateur respectif (IU1-IU3).

Description

Titre : Procédé d'autorisation d'accès à des droits d'exécution de commandes privilégiées Domaine technique
La présente invention a pour objet un procédé d'autorisation d'accès à des commandes ou à des objets sur un système informatique.
Le système informatique peut être un système dont l'environnement est de type distribué ou local.
Ce système comprend une pluralité d'utilisateurs propriétaires de droits d'exécution de commandes privilégiées. Les droits incluent l'écriture, la lecture sur un fichier et l'exécution d'une commande. L'invention s'applique particulièrement à trois catégories d'utilisateurs :
- le propriétaire d'un fichier,
- le groupe d'utilisateurs auquel appartient le propriétaire que l'on nomme groupe propriétaire,
- les autres utilisateurs, c'est-à-dire tout le monde. Ces autres utilisateurs peuvent avoir des droits sur l'exécution de commandes privilégiées et appartiennent donc à d'autres groupes propriétaires,
- et un administrateur.
L'invention s'applique à toute sorte de système d'exploitation. Le système d'exploitation UNIX (Marque déposée) est à l'heure actuelle le mode préféré de mise en oeuvre de l'invention.
L'art antérieur
D'une manière générale, un système de protection d'accès à un fichier utilise un tableau à trois dimensions, que l'on nomme matrice de protection, et comporte l'utilisateur, l'action, et l'objet de l'action. Chaque élément du tableau indique si oui ou non l'utilisateur a le droit d'effectuer une certaine action sur un certain objet. On attribue à un utilisateur des commandes privilégiées. Dans un système tel qu'UNIX (Marque déposée), les objets sont des fichiers.
L'administrateur est chargé de l'administration et de la bonne marche du système. Il est chargé des sauvegardes de sécurité, de la gestion des accès aux fichiers. Il est aussi chargé de donner à chaque utilisateur, un nom, un identificateur d'utilisateur, et un ensemble de privilèges, tels que des droits d'exécution de commandes privilégiées sur des fichiers, etc. A ces responsabilités correspondent des privilèges : il a accès sans contrôle à tous les répertoires et fichiers, à toutes les commandes privilégiées, etc.
Pour protéger l'accès aux fichiers, il faut pouvoir identifier le demandeur lorsqu'il lance une requête, et confronter sa demande avec les droits qu'il a sur un fichier. Les droits incluent l'écriture, la lecture sur un fichier et l'exécution d'une commande. Un utilisateur a, au minimum, un nom ou un numéro, que l'on nomme généralement mot de passe, qu'il donne lorsqu'il accède au système. Dans un autre registre, un utilisateur peut activer des commandes contenues dans un fichier dont le propriétaire est un autre utilisateur. Par exemple, le mécanisme UNIX (Marque déposée) de base, connu de l'homme de l'art, qui permet à un utilisateur d'exécuter une commande avec les droits d'un autre utilisateur est la commande « su-usemame». Le terme « usemame » est le mot de passe ou l'identifiant de nom de l'utilisateur dont on souhaite utiliser les droits sur des commandes privilégiées. Durant l'exécution de cette commande, l'utilisateur réel n'est plus l'utilisateur effectif. C'est l'utilisateur propriétaire du fichier qui devient l'utilisateur effectif. L'utilisateur, en invoquant la commande « su-username » aura à fournir le mot de passe de l'utilisateur propriétaire du fichier.
Le problème majeur dans une telle situation est que, si un utilisateur souhaite utiliser les droits d'un autre utilisateur, il aura à connaître non seulement son propre mot de passe pour la connexion au système, mais aussi le mot de passe de cet autre utilisateur. D'une manière générale, un utilisateur doit connaître une multitude de mots de passe. La mémorisation d'un mot de passe est donc très difficile. De plus, dans certains systèmes, l'utilisateur est forcé de se doter de mots de passe suffisamment longs et dépourvus de sens pour qu'ils soient difficiles à deviner. La mémorisation d'un mot de passe est encore plus difficile.
Un tel mécanisme présente un autre problème lorsque l'on veut retirer des droits sur des commandes privilégiées accordées à un utilisateur. Une telle manoeuvre entraîne la modification de façon périodique des mots de passe de chacun des propriétaires ou groupes propriétaire de fichier. Le fait de modifier ce mot de passe a des répercutions qui ne facilitent en rien sa mémorisation par les utilisateurs, surtout lorsque le mot de passe est partagé par plusieurs personnes. La mémorisation d'un mot de passe devient donc pratiquement impossible.
Ce mécanisme présente un autre problème non négligeable. La commande « su-username» ne peut être utilisée dans un script de commande. En effet, un script de commande apparaît en clair, donc lisible, ce qui signifie que tout homme du métier peut en comprendre la sémantique en lisant le texte sur un support quelconque, papier, écran de terminal informatique, par exemple. Il serait contraire au principe de confidentialité d'intégrer dans un script le mot de passe de l'utilisateur à qui appartient le droit d'exécution de commandes privilégiées, en ce sens qu'un intrus malveillant pourrait se procurer ce mot de passe et utiliser sans difficulté les commandes privilégiées de l'utilisateur propriétaire. La seule solution apportée par l'art antérieur est d'intégrer le mot de passe de "usemame" dans la commande par l'intermédiaire du clavier et uniquement par la personne autorisée à l'intégrer. La conséquence d'une telle solution est l'impossibilité de lancer le script de commande en l'absence de l'utilisateur autorisé. De plus, la commande « su-username» a le défaut de donner à un utilisateur de cette commande le droit d'exécuter toutes les commandes privilégiées, sans sélection sur les commandes de la part du propriétaire associé au mot de passe « usemame ».
II existe, à l'heure actuelle d'autres solutions aux problèmes de sécurité d'accès. En particulier, un mécanisme de base utilisé pour protéger l'accès aux fichiers est, entre autres, celui connu sous le nom de serveur de sécurité « Accessmaster » (Marque déposée). Les applications ou fonctions de ce serveur assurent une administration centrale et cohérente de sécurité pour l'audit et pour une gestion effective des droits des utilisateurs. L'administration cohérente a pour but de contrôler tous les utilisateurs et leurs droits d'accès. Ce serveur contient une description complète de tous les utilisateurs et de leurs attributs et privilèges. Il permet l'identification et l'authentification des utilisateurs par l'intermédiaire d'un mot de passe ou carte à puce, contrôlant l'accès à la station de travail en fonction des droits définis. Dans ce type de mécanisme, le gestionnaire de base de données qui reçoit une requête émanant d'un utilisateur va interroger le serveur de sécurité. Pour cela, on utilise une interface logicielle nommée API (Application Program Interface) ou interface de programmation fournie par le serveur de sécurité.
Le problème rencontré avec ce type de mécanisme est qu'il existe un mécanisme d'authentification mutuelle entre interfaces. Ces interfaces sont prises en compte au moment de la conception des composants de l'application en question. En fonction des besoins, il arrive d'enrichir les commandes privilégiées. Ce mécanisme a donc l'inconvénient d'imposer une modification des composants logiciels impliqués. Sommaire de l'invention
Un premier but de l'invention est de pouvoir accorder à des utilisateurs le droit d'exécuter des commandes privilégiées de manière transparente tout en étant sélectif sur l'attribution des droits d'exécution de commandes privilégiées.
Un deuxième but visé est de concevoir un procédé n'impliquant aucune modification des composants logiciels contenus dans le système.
Un troisième but visé est d'améliorer la sécurité d'accès à des commandes privilégiées.
Un quatrième but visé est la simplicité d'utilisation du procédé de l'invention.
A cet effet, l'invention a pour objet un procédé d'accès à des droits d'exécution de commandes privilégiées dans un système informatique, ledit système comportant au moins un groupe propriétaire de commandes privilégiées, ledit groupe comportant au moins un utilisateur possédant à la fois un mot de passe pour la connexion au système et un identificateur d'utilisateur attribué par un administrateur, ledit utilisateur émettant des requêtes incluant au moins une commande, caractérisé en ce qu'il consiste, pour un utilisateur, à accéder à une commande privilégiée d'un autre utilisateur par l'intermédiaire de son propre identificateur d'utilisateur.
II en résulte un système informatique comprenant au moins un groupe propriétaire de droit d'exécution d'au moins une commande privilégiée, ledit groupe comprenant au moins un utilisateur caractérisé en ce qu'il inclut un mécanisme logiciel d'autorisation d'accès aux commandes privilégiées mettant en oeuvre le procédé.
L'invention sera mieux comprise à la lecture de la description qui suit donnée à titre d'exemple et faite en référence aux dessins annexés. Dans les dessins:
- la figure 1 est une vue synoptique de l'architecture d'un système informatique sur lequel peut s'appliquer le procédé conforme à l'invention ;
- la figure 2a est un algorithme illustrant un mode de réalisation du procédé d'attribution des droits d'exécution de commandes privilégiées dans le système informatique représenté sur la figure 1 ;
- la figure 2b est une vue schématique d'une requête et de ses principaux paramètres conformément à la présente invention; et
- la figure 3 est une table d'autorisation d'accès à un fichier illustrant une variante du procédé d'autorisation des droits d'exécution de commandes privilégiées ;
- la figure 4 est une vue synoptique de l'architecture d'un système informatique dont l'environnement est distribué sur lequel peut s'appliquer le procédé conforme à l'invention ;
- la figure 5 est une vue des liens existants entre chaque noeud ;
- la figure 6 est une vue d'une table d'autorisation d'accès à des commandes privilégiées.
Pour simplifier la description, dans les dessins les mêmes éléments portent les mêmes références.
Description d'un exemple de réalisation
La figure 1 représente un exemple d'un système informatique SYS. Sur cette figure, on a représenté trois groupes GP1 , GP2 et GP3 propriétaires de commandes privilégiées L'invention ne se limite pas à trois groupes propriétaires mais s'applique à un nombre quelconque On admettra, dans la suite de la description, qu'un groupe propriétaire comporte au moins un utilisateur Dans l'exemple illustré, chaque groupe GP1 , GP2 et GP3 inclut un utilisateur respectif UT1 , UT2 et UT3 Les commandes privilégiées incluent, comme indiqué dans l'introduction, l'écriture, la lecture d'un fichier et l'exécution d'une commande
Ce système comporte un administrateur ADM, tel que défini dans l'introduction Cet administrateur attribue des droits sur des commandes privilégiées ainsi que des droits d'accès à des fichiers ou des répertoires à ces différents utilisateurs UT1 , UT2 et UT3 Chaque utilisateur UT1 -UT3 a un identificateur d'utilisateur respectif IU1 , IU2 et IU3 L'identificateur d'utilisateur esi attribué par l'administrateur ADM du système et permet au système de reconnaître implicitement l'utilisateur connecté au système On attribue aussi aux utilisateurs un mot de passe respectif PW1 , PW2 et PW3 pour la connexion au système sans lequel l'utilisateur ne peut accéder au système. En d'autres termes, c'est la connaissance du mot de passe qui autorise la connexion au système De manière concrète, un utilisateur, par exemple UT1 , se connecte au système SYS par l'intermédiaire de son mot de passe PW1 Une fois la connexion établie, le système authentifie ce même utilisateur UT1 par l'intermédiaire de son identificateur d'utilisateur IU1 L'utilisateur UT1 , a, dès ce moment, la possibilité de lancer une requête REQ. Cette requête inclut des paramètres ainsi qu'un contenu CON dont une demande d'exécution de commandes privilégiées DCP
Le problème, tel que mentionné en introduction de la description, est la difficulté pour l'utilisateur UT1 propriétaire ou appartenant à un groupe propriétaire de commandes privilégiées d'accéder à des commandes appartenant à un autre groupe propriétaire que le sien En effet, Les mécanismes existant sont mal adaptés en terme de mémorisation des mots de passe et compliquent la tâche de l'utilisateur UT1 qui souhaite utiliser les droits de commandes privilégiées d'un propriétaire de fichiers, par exemple UT2. De plus, la confidentialité d'un mot de passe partagé par plusieurs personnes est problématique.
Le procédé conforme à l'invention consiste en ce qu'un utilisateur, par exemple UT1 , accède à une commande privilégiée d'un autre utilisateur, par exemple UT2, par l'intermédiaire de son propre identificateur d'utilisateur IU1. A cet effet, le procédé de l'invention est mis en oeuvre par l'intermédiaire d'un mécanisme logiciel d'authentification et d'autorisation d'accès à des droits d'exécution de commandes privilégiées dont le fonctionnement apparaît clairement de la figure 2a.
On décrira maintenant, en référence aux figures 2a et 2b, un algorithme comportant les différentes étapes du procédé conformément à la présente invention, et une vue schématique des principaux paramètres que comporte une requête REQ.
Le procédé commence de façon classique en une étape 10 dans laquelle un utilisateur, par exemple UTÏ , lance une requête REQ. Lors d'une étape 20, la requête REQ issue d'un utilisateur est interceptée. Le procédé de l'invention consiste à vérifier, à l'étape 30, que la requête REQ émise par l'utilisateur UT1 est une demande d'exécution de commandes privilégiées DCP. A cet effet, une caractéristique de l'invention est que chaque requête REQ comporte un paramètre PRC caractéristique d'une demande d'exécution de commandes privilégiées comme illustré sur la figure 2b. Le procédé est activé par l'intermédiaire du paramètre PRC. L'activation consiste à vérifier que la requête REQ contient les informations nécessaires pour autoriser l'utilisateur UT1 à accéder à une commande privilégiée. Le procédé consiste à ne traiter que les requêtes dont le contenu est une demande d'exécution de commandes privilégiées. Dans le cas d'une requête ne contenant pas le paramètre PRC, le procédé aboutit à une étape 40. Lors de cette étape 40, le procédé reste inactif et ne traite pas la requête REQ. L'étape 40 indique alors la fin du procédé. Si la requête REQ comporte le paramètre PRC, le procédé se poursuit et consiste à vérifier que cette requête REQ comporte les informations nécessaires pour autoriser un utilisateur à accéder aux commandes privilégiées d'un autre utilisateur. A cette fin, le procédé consiste à décomposer la requête REQ à l'étape 50 et à y extraire la demande d'exécution d'une commande privilégiée DCP que souhaite acquérir l'utilisateur UT1. Le mécanisme connaît en outre et de manière implicite l'identificateur d'utilisateur IU1 de l'utilisateur UT1.
Le mécanisme comporte des tables dans lesquelles on trouve l'identificateur des utilisateurs autorisés à exécuter des commandes privilégiées. Le mécanisme comporte également des tables comportant l'ensemble des commandes d'autorisation d'exécution de commandes privilégiées. Le procédé consiste à vérifier, à l'étape 70, que l'identificateur d'utilisateur IU1 de l'utilisateur UT1 est répertorié dans les tables. Si l'identificateur de l'utilisateur IU1 n'est pas répertorié dans les tables, celui-ci n'est pas autorisé à exécuter des commandes privilégiées et le procédé consiste à transmettre un message d'erreur, à l'étape 60, pour rendre compte de la situation. Ce message d'erreur est unique afin de ne donner aucune indication sur la cause de l'échec lors d'une tentative d'intrusion d'un individu quelconque et surtout d'un individu malveillant. Dans le cas contraire, correspondant à l'étape 80, c'est-à-dire lorsque l'identificateur d'utilisateur est répertorié dans les tables, une autre analyse est effectuée. Lors de cette analyse, on vérifie que la commande DCP issue de la requête REQ est répertoriée dans les tables. Si la commande n'est pas répertoriée, un message d'erreur identique à celui de l'étape 60 est émis en direction de l'utilisateur. Dans le cas contraire, à l'étape 90, on dispose de toutes les informations nécessaires pour autoriser un utilisateur, UT1 , à accéder aux commandes privilégiées d'un autre utilisateur. Dès cet instant, le procédé consiste à autoriser, de façon transparente, l'utilisateur UT1 à utiliser des droits sur des commandes privilégiées sur le compte d'un autre utilisateur. Un utilisateur UT1 peut lancer des commandes privilégiées appartenant à un propriétaire avec les droits de ce propriétaire, par exemple UT2. En d'autres termes, à l'étape 90, écriture et/ou la lecture et/ou l'exécution du fichier portant le nom de la commande est autorisée. A l'étape 100, le procédé consiste à exécuter la transformation de la requête initiale en une requête réelle. La requête initiale correspond à la requête REQ émise et qui n'a subi aucun traitement par l'intermédiaire du mécanisme. La requête réelle correspond à la requête ayant subi le traitement.
Il est à noter que les deux étapes 70 et 80 sont les conditions nécessaires et suffisantes pour autoriser un utilisateur à exécuter des commandes privilégiées appartenant à un autre utilisateur. Le sens d'exécution des étapes 70 et 80 est indifférent.
La figure 2b illustre les paramètres constitutifs d'une requête initiale REQ. Cette requête inclut dans son contenu CON la demande de droits d'exécution de commandes privilégiées DCP que souhaite acquérir un utilisateur. De préférence, la demande DCP contient une demande d'exécution d'une seule et unique commande. La requête inclut ainsi, tel que mentionné précédemment, un paramètre PRC caractéristique d'une demande d'exécution de commandes privilégiées. Selon une variante du procédé de l'invention, ce paramètre PRC est, de préférence, un préfixe que l'on ajoute aux autres paramètres que comporte la requête REQ. Ce préfixe a pour fonction d'identifier facilement une requête incluant une demande d'exécution d'une commande privilégiée et d'activer le procédé.
La figure 3 illustre un exemple de réalisation des tables utilisées lors des étapes 70 et 80 de la figure 2a. Ces tables peuvent, dans un exemple, être représentées par un tableau à trois dimensions tel que défini dans l'introduction de la description. De préférence, ces tables peuvent avoir une structure arborescente avec un noeud unique appelé PRC et qui correspond au préfixe PRC de la requête. Chaque noeud qui n'est pas une feuille de la structure du système de fichier est un répertoire de fichiers. Sous le répertoire PRC, on trouve deux répertoires. Un premier répertoire REG a pour rôle l'enregistrement des commandes privilégiées. Le deuxième répertoire DIST sera décrit ultérieurement dans la description.
Sous le répertoire REG, on trouve des fichiers de description de commandes privilégiées. Dans l'exemple illustré, on a représenté les fichiers de descriptions printA et printB. De préférence, une commande privilégiée est associée à un fichier de description. Chaque fichier comporte une structure de données qui contiennent les opérations à effectuer lors de la transformation de la requête REQ initiale en requête réelle. Les fichiers de description printA et printB comportent entre autres des paramètres. Ces paramètres incluent le groupe propriétaire auquel appartient la commande privilégiée ainsi que les utilisateurs autorisés à utiliser cette commande privilégiée. Le rôle de ces fichiers est de transformer la requête REQ initiale, émise par un utilisateur, en requête réelle. Les opérations sont entre autres, l'acquisition des droits requis, le changement ou non d'environnement dans le cas où les systèmes appartiennent à des environnements différents, la propagation de variables d'environnement comme les variables DISPLAY ou LANG, connues de l'homme de l'art, entre les environnements de départ et celui d'arrivée, la journalisation des appels, etc.
Un autre répertoire DIST est utilisé. Ce répertoire a pour rôle l'enregistrement des utilisateurs autorisés à utiliser des droits d'exécution de commandes privilégiées. Ce répertoire est rattaché au même noeud unique
PRC. Le répertoire DIST contient, par exemple, l'identificateur IU1-IU3 des utilisateurs habilités à exécuter des commandes privilégiées. Dans un autre exemple, ce répertoire DIST peut contenir, tout simplement, le nom des utilisateurs UT1-UT3 habilités à exécuter des commandes privilégiées. De préférence, on fait correspondre au répertoire DIST des répertoires nommés, par exemple, IU1 ou IU2 correspondant à l'identificateur des utilisateurs autorisés à exécuter des commandes privilégiées. Enfin, à chaque répertoire portant le nom d'un utilisateur correspond au moins un fichier portant, par exemple, le nom de la commande pour laquelle on lui autorise l'exécution. Dans l'exemple illustré, on a nommé un fichier printA associé au répertoire IU1 associé à l'utilisateur UT1. En d'autres mots, la présence de l'identificateur IU1 sous le répertoire DIST signifie, tout d'abord, que l'utilisateur UT1 a obtenu des droits d'exécution d'exécution sur des commandes privilégiées. Ensuite, la présence du fichier printA sous le répertoire IU1 signifie qu'il a obtenu des droits d'exécution de la commande printA. Dès cet instant, si l'utilisateur est autorisé à exécuter des commandes privilégiées, le procédé consiste à vérifier que cette commande printA a été enregistrée dans le répertoire REG. Si c'est le cas, le fichier printA est exécuté et transforme la requête initiale REQ en requête réelle. Le procédé consiste à vérifier sous le répertoire REG, dans le fichier de description correspondant à la commande printA, que l'utilisateur en question UT1 est autorisé à exécuter cette commande. Toutes ces étapes s'effectuent de façon transparente pour l'utilisateur UT1. Si l'utilisateur UT1 est autorisé à exécuter la commande privilégiée printA, la requête réelle est lancée. Dès cet instant, l'utilisateur réel UT1 n'est plus l'utilisateur effectif. L'utilisateur effectif est l'utilisateur UT2 à qui appartient les droits d'exécution des commandes privilégiées.
La présente invention est applicable à des systèmes informatiques dont l'environnement est de type distribué ou de type local.
De manière générale, un système informatique dont l'environnement est de type distribué est un environnement qui fonctionne au moyen d'au moins deux systèmes d'exploitation reliés entre eux par l'intermédiaire d'un réseau de type local de type LAN (Local Area Network) ou à grande distance de type WAN (Wide Area Network) ou internet. D'un autre côté, un système informatique dont l'environnement est de type local est un système informatique qui fonctionne au moyen d'un seul système d'exploitation.
Dans un système informatique dont l'environnement est de type distribué, plusieurs noeuds sont reliés les uns aux autres. Un tel système est représenté sur la figure 4. Dans l'exemple illustré, le système comprend trois noeuds N1-N3. Chaque noeud N1-N3 peut comprendre au moins un groupe propriétaire respectif GP1-GP3 incluant au moins un utilisateur respectif UT1- UT3, comme défini précédemment. Dans l'exemple illustré, l'utilisateur UT1 peut lancer une application APP1. Par définition, cette application APP1 est de type logiciel. Dans l'exemple illustré, le noeud N1 comprend un client applicatif qui est l'application APP1. Le noeud N2 comprend un serveur applicatif SAP.
Ces trois noeuds N1-N3 sont reliés entre eux par l'intermédiaire d'un réseau RES dont le protocole de communication peut être du type TCP-IP (Transport Control Protocol - Internet Protocol) connu de l'homme du métier. Un ensemble de couches logicielles, non illustré, s'interpose entre un noeud N1 -N3 et le réseau RES. Cet ensemble de couches logicielles repose sur le modèle OSI (Open System Interconnection) d'architecture en couche de l'ISO (International Organization for Standardization) ou le modèle TCP-IP, connus de l'homme du métier.
Chaque noeud comprend des interfaces de programmation spécifiques de type API d'accès à un service connu de l'homme du métier. Par définition, cette interface de programmation est un ensemble d'outils mis à la disposition des programmeurs destinés à uniformiser l'interface utilisateur, le contrôle des programmes et le contrôle des données envoyées dans un réseau. Les développeurs, en créant un logiciel, vont chercher dans l'interface de programmation API les noms des menus et des commandes, les modèles de fenêtres et de boîte de dialogue. Une interface de programmation API est généralement associée à une librairie.
De préférence, la gestion des droits d'accès est effectuée à travers une unité centralisée de gestion de droit d'accès. Selon cette variante, les tables sont comprises sur un seul et unique noeud N3. Dans l'exemple illustré, l'ensemble des tables sont comprises dans une base de données BDD. Cette base de données BDD est reliée à un senteur de base de données SERV. Le client applicatif APP1 , le serveur applicatif SAP, et le serveur SERV de base de données communiquent avec le réseau par l'intermédiaire des interfaces de programmation respectives APM , API2 et API3 ainsi que des couchent logicielles qui s'interposent entre chaque noeud et le réseau RES.
Chaque composant référencé de ce système informatique échange des messages. Ces messages peuvent être transportés par l'intermédiaire d'une unité de données de protocole PDU (Protocol Data Unit), connu de l'homme du métier.
Un utilisateur ou client de la base de données interroge la base BDD par l'intermédiaire du serveur SERV. Le dialogue qui existe entre un utilisateur et la base de données BDD est un dialogue de type client/serveur.
Le client applicatif et le senteur applicatif travaillent avec la base de données et effectuent une série de transactions. De préférence, les tables sont centralisées sur un noeud du système. Cette centralisation des tables est conforme aux critères de sécurité d'une transaction. Les accès à la base de données BDD seront transactionnelles pour assurer aux données une atomicité, une cohérence, une isolation, et une durabilité. Par définition, l'atomicité signifie qu'une transaction doit être totalement effectuée. La cohérence des données signifie que la transaction fait passer un système d'un état cohérent à un autre état cohérent. L'isolation des données signifie que la transaction n'est pas affectée par le traitement des autres transactions. Et enfin, la durabilité des données signifie que les modifications dues à une transaction terminée sont durablement garanties. En clair, une transaction donnée a soit définitivement eu lieu, soit n'a jamais existé.
Du fait de la centralisation de la base de données relative aux tables, chaque noeud N1-N3 comprend un fichier de configuration respectif CFG1-
CFG3 qui indique l'endroit où se situe la base de données BDD associée incluant l'ensemble des tables. Ces fichiers de configuration peuvent être des senteurs de noms, connus de l'homme du métier. Le choix du noeud sur lequel la base de données est arbitraire. Selon une autre variante, il peut exister un seul et unique fichier de configuration sur un noeud quelconque.
La figure 5 illustre schématiquement un exemple de demande d'accès à une commande privilégiée. Cette figure représente les échanges de messages entre les différents noeuds du système informatique. Cette figure comprend des flèches uni-directionnelles indiquant le sens d'exécution d'une action.
Préalablement à la demande d'accès,
H on crée la base de données avec le nom du premier administrateur ayant tous les droits sur la base de données,
ce premier utilisateur remplit la base de données avec la liste des utilisateurs ayant des droits de lecture et d'écriture sur cette base. De préférence, ces utilisateurs sont limités à des droits de lecture afin vérifier les critères mentionnés ci-dessus,
H on renseigne chaque noeud N1-N3 de la position de la base de données BDD dans le système informatique. Cette position est incluse dans les fichiers de configuration CFG1-CFG3.
A ce stade, une demande d'accès à une commande privilégiée par l'utilisateur UT1 est possible et se déroule comme suit :
Premièrement, une demande d'écriture est effectuée par l'utilisateur UT2 d'une commande PRINTA associée à une application dont il est propriétaire.
La base de données peut inclure des noms de commande identiques et des noms d'application identiques. Lorsqu'un utilisateur lance une commande, l'administrateur doit associer, dans les tables incluses dans la base de données, cette commande à son application respective. A cet effet, la base de données donne la possibilité à un utilisateur d'écrire ou de lire des informations dans la base de données à la seule condition qu'il ait en sa possession un identificateur unique d'application.
Ainsi, deuxièmement, la base de données émet, en retour, un identificateur unique d'application ID-PRINTA. De cette façon, des commandes et/ou des applications dont la sémantique est identique peuvent coexister dans la base de données.
Troisièmement, comme l'utilisateur possède l'identificateur unique d'application, il peut écrire ou lire dans la base de données. Un exemple d'une écriture dans la base de données est donné par le tableau représenté sur la figure 6. Ce tableau est décrit dans la suite de la description. Selon cet exemple, l'utilisateur UT1 du noeud N1 est autorisé à utiliser en différé et à distance la commande PrintA avec l'identité de l'utilisateur UT2 appartenant au groupe GP2 du noeud N2 entre 12 heures et 13 heures.
Quatrièmement, la base de données est mise à jour MAJ.
Cinquièmement, l'utilisateur UT1 peut lancer une demande d'autorisation d'exécution DDE d'une commande privilégiée appartenant à un utilisateur présent sur un noeud quelconque du réseau. Dans l'exemple illustré, L'utilisateur UT1 souhaite exécuter la commande PrintA dont l'utilisateur UT2 est propriétaire. A cet instant, Le serveur applicatif SAP est chargé de consulter la base de données BDD. Pour cela, il accède à la base de données avec le nom de la commande PrintA accompagné de son identificateur unique d'applications ID- PrintA pour les raisons évoquées précédemment. La demande DDE est réalisée.
Sixièmement, la base de données associée à son serveur de fichier SERV émet un résultat. Ce résultat peut être de type binaire « 0 » ou « 1 » en fonction des contraintes spatiales ou temporelles associées à un utilisateur.
Par exemple, le « 0 » signifie que l'utilisateur UT1 n'a pas l'autorisation d'exécution de commandes privilégiées. Le résultat « 1 » siginifie que l'utilisateur est autorisé à exécuter la commande privilégiée. Dans l'exemple illustré, l'utilisateur UT1 du noeud N1 est autorisé à utiliser en différé et à distance la commande PrintA avec l'identité de l'utilisateur UT2 appartenant au groupe GP2 du noeud N2 entre 12 heures et 13 heures. Si l'utilisateur UT1 respecte le calendrier 12-13h, la demande d'exécution est autorisée. Dès lors, la commande est exécutée.
De préférence, le réseau est parfaitement sécurisé par l'intermédiaire d'une interface de programmation du type GSS-API (Generic Security Service - Application Program Interface). Une interface de programmation de type GSS-API assure une sécurité lors d'une transaction entre un noeud quelconque et la base de données BDD. Ce type d'interfaces fournit aux applications la possibilité de sécuriser leurs échanges en leur offrant une authentification mutuelle, une intégrité, une confidentialité. Cette interface de programmation peut s'appuyer sur différents mécanismes de sécurité tels que le mécanisme DCE (Distributed Computing Environment) de l'organisation dite OSF (Open Software Foundation), connu de l'homme du métier. De préférence, la liaison entre un serveur applicatif SAP et la base de données BDD est sécurisée par l'intermédiaire d'une telle interface de programmation. L'accès aux informations qui transitent entre le senteur applicatif SAP et la base de données BDD est impossible. Un fraudeur ne peut donc pas lire ou modifier les informations qui circulent entre le serveur SAP et la base de données.
La position de la base de données BDD peut être envisagée en fonction de la distance qui sépare les noeuds N1-N3. Cette base de données BDD peut être répliquée sur un noeud et être utilisée en lecture et non en écriture pour être conforme au critère d'une transaction. La base de données peut être, par exemple, répliquée sur le noeud N1. Selon une variante, si les noeuds NO et N1 sont rapprochés l'un de l'autre et que le noeud N3 leur est à distance, il peut être intéressant de répliquer la base de données pour diminuer le temps de réponse de la base de données. Pour des raisons de propriétés transactionnelles, cette base de données BDD est utilisée uniquement en lecture. Lors d'une réplication de la base de données, il est nécessaire de modifier les fichiers de configurations des noeuds concernés.
Selon une autre variante, les tables comprennent des contraintes d'utilisation autres que les contraintes de type spatial telles que définies précédemment. Il peut exister dans la base de données d'autres contraintes qui ont pour but de contribuer et d'améliorer la sécurité d'accès auxdites commandes privilégiées. Les tables peuvent inclure des contraintes d'ordre temporel. Ces contraintes sont décrites en rapport avec la figure 6 et sont explicitées dans la suite de la description. Ces contraintes s'ajoutent aux contraintes d'ordre spatial de l'étape 30 de la figure 2a.
Selon l'exemple illustré sur la figure 5, une table peut se matérialiser par l'intermédiaire d'un tableau bi-dimensionnelle. Dans ce tableau, on distingue plusieurs colonnes :
- une première colonne, nommée « utilisateur », identifie les utilisateurs dont l'administrateur attribue tout ou partie des droits sur au moins une commande privilégiée.
- une deuxième colonne, dite « droits », qui définit l'ensemble des droits, définis précédemment, qu'un utilisateur de la colonne. Cette deuxième colonne inclut des sous-colonnes associées à ces différents droits :
- une première sous-colonne comprend le nom de l'utilisateur UT2 qui appartient au groupe GP2 lui-même indu dans le noeud N2, et qui est le propriétaire des commandes dont l'utilisateur UT1 , présent dans la première colonne, souhaite utiliser .
- une deuxième sous-colonne comprend le nom de l'application
APP2 dont l'utilisateur UT2 est propriétaire et que l'utilisateur UT1 est autorisé à utiliser. - une troisième sous-colonne comprend le nom de la commande printA associée à l'application APP2 dont l'utilisateur UT2 est propriétaire et que l'utilisateur UT1 est autorisé à utiliser. La sémantique accordée à une commande est propre à une application grâce à l'identificateur unique d'applications.
Au moins une autre sous-colonne comprend une contrainte d'ordre temporel. De telles contraintes peuvent consister en une autorisation d'accès à une commande privilégiée pendant une période de temps définie par l'administrateur. Sur la figure 6, une contrainte est notée « calendrier ». Dans l'exemple illustré, l'application autorise l'utilisateur UT1 à utiliser la commande associée à l'application APP dont le propriétaire est l'utilisateur UT2 appartenant au groupe propriétaire GP2 du noeud N2 entre 12 heures et 13 heures. Si une demande d'utilisation d'une commande privilégiée est faite en dehors des horaires du calendrier, elle est refusée et considérée une demande frauduleuse.
Les tables incluses dans la base de données ne sont pas figées mais au contraire sont extensibles. D'autres contraintes peuvent donc être définies ultérieurement suivant les besoins des applications. La signification des contraintes dépend de chaque application.
L'administrateur complète chaque ligne et chaque colonne du tableau.
Selon une autre variante, l'administrateur ADM intervient dans l'attribution des droits d'exécution des commandes privilégiées. Cet administrateur peut attribuer ou retirer des droits. La structure arborescente, définie précédemment, n'est pas, à cette fin, figée dans le temps, mais peut au contraire évoluer dans le temps. Cette évolution consiste soit à ajouter des branches ou supprimer des branches dans la structure arborescente. En d'autres mots, cette évolution correspond, à autoriser, ou à retirer à tout moment, des droits d'accès à des commandes privilégiées. L'invention permet à un utilisateur d'activer directement des commandes et d'acquérir dynamiquement l'autorisation d'exécution de commandes privilégiées sans gêner les demandes d'autorisation d'accès émanant d'autres utilisateurs. Par exemple, l'utilisateur UT3 peut lancer une requête incluant une demande d'autorisation d'exécution de commandes privilégiées. Pendant le traitement de cette requête, le procédé consiste à supprimer ou accorder des droits à un autre utilisateur. En d'autres termes, le procédé offre la possibilité de régler ou d'éviter les problèmes posés par l'accès simultané de plusieurs utilisateurs.
Selon une autre variante, le choix d'un mot de passe PW d'un utilisateur est à la charge de l'utilisateur titulaire du mot de passe. De même, son renouvellement est à la charge de l'utilisateur associé. Le renouvellement régulier est fortement conseillé car plus la période de temps d'utilisation de mot de passe est longue, plus le risque d'être connu par des tiers devient important.
D'une manière générale, on peut dire que l'invention a pour objet un procédé d'accès à des droits d'exécution de commandes privilégiées dans un système informatique SYS, ledit système comportant au moins un groupe GP1- GP3 propriétaire de commandes privilégiées, ledit groupe comportant au moins un utilisateur respectif UT1-UT3 possédant à la fois un mot de passe respectif PW1-PW3 pour la connexion au système SYS et un identificateur d'utilisateur respectif IU1-IU3 attribué par un administrateur, ledit utilisateur émettant des requêtes REQ incluant au moins une commande. Le procédé consiste, pour un utilisateur UT1-UT3, à accéder à une commande privilégiée d'un autre utilisateur par l'intermédiaire de son propre identificateur d'utilisateur respectif IU1-IU3.
Dans l'algorithme de la figure 2a, reflétant les différentes étapes du procédé de l'invention, on a vu que le procédé est activé par la requête REQ. L'activation consiste à vérifier que la requête REQ contient les informations nécessaires pour autoriser un utilisateur U1-U3 à accéder à une commande privilégiée d'un autre utilisateur. On a vu que la vérification des informations nécessaires consiste à vérifier dans des tables de droits d'exécution de commandes privilégiées accordées, à la fois si l'identificateur d'utilisateur IU1 - IU3 est autorisé à utiliser une commande privilégiée et si l'utilisateur est autorisé à exécuter la commande privilégiée issue de la requête REQ.
On a vu aussi sur la figure 2b, que l'activation du procédé consiste à inclure un paramètre PRC à la requête REQ caractéristique d'une demande d'exécution de commande privilégiée. Dans un exemple, on a vu que ce paramètre supplémentaire peut être un préfixe PRC associé à la requête REQ.
Dans un autre exemple, on a vu qu'un administrateur peut intervenir dans le système dans l'attribution des droits d'exécution des commandes privilégiées et que le procédé consiste à accorder et/ou retirer le droit d'exécution d'une commande privilégiée à un utilisateur UT1 -UT3 par l'intermédiaire d'un administrateur. Le procédé consiste à acquérir dynamiquement, pour un utilisateur UT1 -UT3, le droit d'exécution d'une commande privilégiée. Selon cette variante, le procédé consiste à acquérir et/ou à retirer le droit d'exécution d'une commande privilégiée à un utilisateur sans gêner une demande d'exécution de droit d'exécution d'une commande privilégiée d'un autre utilisateur.
On a vu aussi que le procédé consiste à accorder et exécuter la requête ou à rejeter avec un message d'erreur unique afin de ne donner aucune indication sur la cause de l'échec.
Selon une variante visant à contribuer et améliorer la sécurité d'accès auxdites commandes privilégiées, il est préférable d'inclure dans les tables au moins une contrainte d'ordre temporelle. Ces tables sont, par exemple, incluses dans une base de données BDD. Dans cette base de données BDD, les contraintes ont une sémantique propre à chaque application et ont également une signification propre à chaque application. Pour être conforme au critère de sécurité d'une transaction, il est préférable de gérer les tables de façon centralisée sur un noeud unique.
On a vu que l'invention a pour objet un système informatique comprenant au moins un groupe GP1-GP3 propriétaire de droit d'exécution d'au moins une commande privilégiée, ledit groupe comprenant au moins un utilisateur respectif UT1-UT3, caractérisé en ce qu'il comprend un mécanisme logiciel d'autorisation d'accès aux commandes privilégiées mettant en oeuvre le procédé défini précédemment. Le mécanisme logiciel selon l'invention comporte des tables incluant les identificateurs des utilisateurs IU1-IU3 autorisés à exécuter des commandes privilégiées et les droits d'exécution de commandes privilégiées correspondantes.
Et enfin, on a vu aussi que la présente invention est applicable dans un système informatique qui a un environnement de type local ou distribué.
Il ressort des exemples illustrés que l'invention offre de nombreux avantages. Elle permet à un utilisateur d'accéder simplement à des commandes privilégiées par l'intermédiaire de son propre identificateur d'utilisateur. Un utilisateur doit simplement connaître son propre mot de passe pour la connexion au système. La commande « su-usemame » n'a plus lieu d'exister. Dans l'invention, une demande d'exécution de commandes privilégiées n'exige donc plus l'intégration d'un mot de passe dans la requête. Cette caractéristique est conforme au critère de confidentialité et de sécurité. De plus, l'invention offre l'avantage d'être sélectif sur l'attribution des droits d'exécution de commandes privilégiées. En effet, une requête ne concerne qu'une seule et unique commande. De plus, le fait d'utiliser une arborescence de fichier permet au mécanisme de se concentrer uniquement sur le traitement des commandes. La partie administrative d'accorder ou de retirer les droits à tel ou tel utilisateur est facilement réalisée à l'aide d'un gestionnaire de fichiers comme ceux proposés par WINDOWS (Marque déposée) ou CDE (Common Desktop Environment) (Marque déposée). La suppression ou l'addition de droits n'implique pas la modification de composants logiciels contenus dans le système. Cette suppression ou l'addition de droits n'implique pas non plus la modification du mot de passe associé. Le procédé est donc simple d'utilisation. L'invention offre aussi l'avantage de permettre à toute application informatique de gérer de façon personnalisée (la sémantique accordée à une commande dans les tables est propre à chaque application ) et fine l'accès aux commandes privilégiées. Elle offre également l'avantage d'une homogénéité d'utilisation (utilisation d'interfaces de programmation de type API) et d'administration procurée par une centralisation des informations relatives à ces accès.

Claims

R E V E N D I C A T I O N S
1 - Procédé d'accès à des droits d'exécution de commandes privilégiées dans un système informatique (SYS), ledit système comportant au moins un groupe (GP1-GP3) propriétaire de commandes privilégiées, ledit groupe comportant au moins un utilisateur respectif (UT1-UT3) possédant à la fois un mot de passe respectif (PW1-PW3) pour la connexion au système (SYS) et un identificateur d'utilisateur respectif (IU1-IU3) attribué par un administrateur (ADM), ledit utilisateur émettant une requête (REQ) incluant au moins une commande, caractérisé en ce qu'il consiste, pour un utilisateur (UT1-UT3), à accéder à une commande privilégiée d'un autre utilisateur par l'intermédiaire de son propre identificateur d'utilisateur respectif (IU1-IU3).
2- Procédé selon la revendication 1 , caractérisé en ce qu'il est activé par la requête (REQ), l'activation consistant à vérifier que la requête (REQ) contient les informations nécessaires pour autoriser un utilisateur (U1-U3) à accéder à une commande privilégiée d'un autre utilisateur.
3- Procédé selon la revendication 1 ou 2, caractérisé en ce que la vérification des informations nécessaires consiste à vérifier dans des tables de droits d'exécution de commandes privilégiées accordées, à la fois si l'identificateur d'utilisateur (IU1-IU3) est autorisé à utiliser une commande privilégiée et si l'utilisateur est autorisé à exécuter la commande privilégiée issue de la requête (REQ),
4- Procédé selon l'une des revendications 1 à 3, caractérisé en ce que l'activation consiste à inclure un paramètre (PRC) à la requête (REQ) caractéristique d'une demande d'exécution de commande privilégiée. 5- Procédé selon l'une des revendications 1 à 4, caractérisé en ce qu'il consiste à accorder et/ou retirer le droit d'exécution d'une commande privilégiée à un utilisateur (UT1 -UT3) par l'intermédiaire de l'administrateur (ADM).
6- Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'il consiste à acquérir dynamiquement, pour un utilisateur (UT1-UT3), le droit d'exécution d'une commande privilégiée.
7- Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'il consiste à acquérir et/ou à retirer le droit d'exécution d'une commande privilégiée à un utilisateur sans gêner une demande de droit d'exécution d'une commande privilégiée d'un autre utilisateur.
8- Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'il consiste à accorder et exécuter la requête ou à rejeter la requête avec un message d'erreur unique afin de ne donner aucune indication sur la cause de l'échec.
9- Procédé selon l'une des revendications 1 à 8, caractérisé en ce qu'il consiste à inclure dans les tables au moins une contrainte d'ordre temporelle.
10- Procédé selon l'une des revendications 1 à 9, caractérisé en ce qu'il consiste à ajouter des contraintes dont la sémantique est propre à chaque application et dont la signification est propre à chaque application.
11- Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il consiste à gérer les tables de façon centralisée sur un noeud unique.
12- système informatique (SYS) comprenant au moins un groupe (GP1- GP3) propriétaire de droit d'exécution d'au moins une commande privilégiée, ledit groupe comprenant au moins un utilisateur respectif (UT1-UT3), caractérisé en ce qu'il inclut un mécanisme logiciel d'autorisation d'accès aux commandes privilégiées mettant en oeuvre le procédé défini par l'une des revendications 1 à 11.
13- Système selon la revendication 12, caractérisé en ce que le mécanisme logiciel comprend des tables incluant les identificateurs des utilisateurs (IU1-IU3) autorisés à exécuter des commandes privilégiées et les droits d'exécution de commandes privilégiées correspondantes.
14- Système informatique selon la revendication 12 ou 13, caractérisé en ce qu'il a un environnement de type local ou distribué.
PCT/FR1998/002889 1997-12-30 1998-12-28 Procede d'autorisation d'acces a des droits d'execution de commandes privilegiees Ceased WO1999035552A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP98963639A EP0961961A1 (fr) 1997-12-30 1998-12-28 Procede d'autorisation d'acces a des droits d'execution de commandes privilegiees

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FR97/16698 1997-12-30
FR9716698A FR2773235B1 (fr) 1997-12-30 1997-12-30 Procede d'autorisation d'acces a des droits d'execution de commandes privilegiees
FR98/12021 1998-09-25
FR9812021A FR2773236B1 (fr) 1997-12-30 1998-09-25 Procede d'autorisation d'acces a des droits d'execution de commandes privilegiees

Publications (1)

Publication Number Publication Date
WO1999035552A1 true WO1999035552A1 (fr) 1999-07-15

Family

ID=26234039

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR1998/002889 Ceased WO1999035552A1 (fr) 1997-12-30 1998-12-28 Procede d'autorisation d'acces a des droits d'execution de commandes privilegiees

Country Status (3)

Country Link
EP (1) EP0961961A1 (fr)
FR (1) FR2773236B1 (fr)
WO (1) WO1999035552A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110770731A (zh) * 2017-06-28 2020-02-07 苹果公司 授权系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0398645A2 (fr) * 1989-05-15 1990-11-22 International Business Machines Corporation Système pour contrôler des privilèges d'accès
EP0561509A1 (fr) * 1992-03-17 1993-09-22 International Computers Limited Sécurité pour système d'ordinateur
US5664098A (en) * 1993-09-28 1997-09-02 Bull Hn Information Systems Inc. Dual decor capability for a host system which runs emulated application programs to enable direct access to host facilities for executing emulated system operations

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0398645A2 (fr) * 1989-05-15 1990-11-22 International Business Machines Corporation Système pour contrôler des privilèges d'accès
EP0561509A1 (fr) * 1992-03-17 1993-09-22 International Computers Limited Sécurité pour système d'ordinateur
US5664098A (en) * 1993-09-28 1997-09-02 Bull Hn Information Systems Inc. Dual decor capability for a host system which runs emulated application programs to enable direct access to host facilities for executing emulated system operations

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"EXTENSIBLE ACCESS CONTROL LIST MECHANISM", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 34, no. 7B, 1 December 1991 (1991-12-01), pages 114 - 117, XP000282519 *
THEIMER M M ET AL: "DELEGATION THROUGH ACCESS CONTROL PROGRAMS", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTIN SYSTEMS, YOKOHAMA, JUNE 9 - 12, 1992, no. CONF. 12, 9 June 1992 (1992-06-09), INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, pages 529 - 536, XP000341049 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110770731A (zh) * 2017-06-28 2020-02-07 苹果公司 授权系统
US11663310B2 (en) 2017-06-28 2023-05-30 Apple Inc. Entitlement system
CN110770731B (zh) * 2017-06-28 2023-11-28 苹果公司 授权系统

Also Published As

Publication number Publication date
EP0961961A1 (fr) 1999-12-08
FR2773236A1 (fr) 1999-07-02
FR2773236B1 (fr) 2003-02-21

Similar Documents

Publication Publication Date Title
EP3343425B1 (fr) Système et procédé pour la création et la gestion d'autorisations décentralisées pour des objets connectés
CA2822417C (fr) Procede et dispositif de controle d'acces a un systeme informatique
EP1836636A1 (fr) Support personnel de mémoire de masse portatif et système informatique d'accès sécurisé a un espace utilisateur via un réseau
TWI306203B (en) Processes for controlling access to a host computer via user specific smart cards and for using low-cost memory cards to log onto a host computer and apparatus for performing the same
CN113177198A (zh) 一种通过软件自动解锁Windows方法
EP3588337A1 (fr) Pilotage d'un dispositif de stockage de donnees
CN101645021B (zh) Java应用服务器下多系统的单点登录整合方法
US20210152624A1 (en) Identifying and Deleting Idle Remote Sessions in a Distributed File System
EP2299644B1 (fr) Traitement de données avec authentification a posteriori
EP0961961A1 (fr) Procede d'autorisation d'acces a des droits d'execution de commandes privilegiees
EP2537114B1 (fr) Procede de verrouillage/deverrouillage a distance d'une machine
FR3147901A1 (fr) Système et procédé de stockage de données, en particulier de données personnelles
EP0900429A1 (fr) Systeme securise de controle d'acces permettant le transfert d'habilitation a produire des cles
WO2020136126A1 (fr) Reseau de communication securisee et tracee
FR2773235A1 (fr) Procede d'autorisation d'acces a des droits d'execution de commandes privilegiees
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
FR2747813A1 (fr) Systeme securise de controle d'acces permettant l'invalidation automatique de cles electroniques volees ou perdues et/ou le transfert d'habilitation a produire des cles
EP2755160B1 (fr) Procédé de traçage de données liées à l'activité d'un utilisateur d'un équipement
FR2759177A1 (fr) Procede et dispositif de traitement de plusieurs applications techniques avec pour chacune d'elles la surete qui lui est propre
EP0969347B1 (fr) Procédé d'authentification pour accès protégés dans un système informatique en réseau
FR3120460A1 (fr) Procédé pour permettre à des utilisateurs de déployer des contrats intelligents dans une chaîne de blocs au moyen d’une plateforme de déploiement
FR3031608A1 (fr) Methode de traitement d'une autorisation de mise en œuvre d'un service, dispositifs et programme d'ordinateur correspondant
FR3038758A1 (fr) Gestion d'identite et d'acces a une infrastructure physique et aux systemes d'information
EP2537314B1 (fr) Procédé et dispositif de propagation d'événements de gestion de session
FR2901381A1 (fr) Systeme informatique a gestion universelle et collaborative de fichiers utilisateurs

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WWE Wipo information: entry into national phase

Ref document number: 1998963639

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 09380301

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 1998963639

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1998963639

Country of ref document: EP