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

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 (IUI-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, I'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. II 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-username . Le terme username 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,
I'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, I'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. II 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 "username" 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 username .

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. II 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, I'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 i représente un exemple d'un système informatique SYS. Sur cette figure, on a représenté trois groupes GPl, 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 GPl, GP2 et GP3 inclut un utilisateur respectif UT1, UT2 et UT3. Les commandes privilégiées incluent, comme indiqué dans l'introduction, I'é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 IUi, IU2 et IU3. L'identificateur d'utilisateur est 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 UTI, 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 UTI 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 IUi 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 1U1 de l'utilisateur UT1 est répertorié dans les tables. Si l'identificateur de l'utilisateur lui 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, I'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,
L'é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.

II 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
I'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, I'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, I'identificateur IU1-lU3 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 UTl-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 UTI 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 UTI 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 UTI
UT3, comme défini précédemment. Dans l'exemple illustré, I'utilisateur UTI 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 APPI. 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 connu de l'homme du métier. Un ensemble de couches logicielles, non illustré, s'interpose entre un noeud Nl-N3 et le réseau RES. Cet ensemble de couches logicielles repose sur le modèle OSI (sigle anglo-saxon signifiant interconnexion de systèmes ouverts) d'architecture en couche de l'ISO (sigle anglais signifiant Organisation internationale de standardisation 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 serveur 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 API1, AP12 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 serveur 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,
I'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 Nl-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 serveurs 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,
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,
on renseigne chaque noeud Nl-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 app 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 etlou 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, I'utilisateur UT1 du noeud NI 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, I'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 UTI n'a pas l'autorisation d'exécution de commandes privilégiées. Le résultat 1 siginifie que
I'utilisateur est autorisé à exécuter la commande privilégiée. Dans l'exemple illustré, I'utiJisateur UT1 du noeud Ni 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 connue GSS-API.

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 (sigle anglais signifiant environnement informatique distribué) de l'organisation dite OSF, connus 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 serveur 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 Ni. 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. II 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 inclu 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é, I'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, I'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, I'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 GPl-
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-lU3 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 IUi-1U3.

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-lU3 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é.

II 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-username 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, I'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 le standard d'environnement dit CDE (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 (14)

1. 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-lU3) 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-lU3)

   REVENDICATIONS
2. 2- Procédé selon la revendication 1, caractérisé en ce qu'il est activé par la requête (REQ), I'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. 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-lU3) 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. 4- Procédé selon l'une des revendications i à 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. 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. 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. 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. 8- Procédé selon l'une des revendications i à 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. 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. 10- Procédé selon l'une des revendications i à 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. 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. 12- système informatique (SYS) comprenant au moins un groupe (GPl- . go3) 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 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. 13- Système selon la revendication 12, caractérisé en ce que le mécanisme comprend des tables incluant les identificateurs des utilisateurs (IU1-lU3) autorisés à exécuter des commandes privilégiées et les droits d'exécution de commandes privilégiées correspondantes.
14. 14- Système informatique selon la revendication 12 ou 13, caractérisé en ce qu'il a un environnement de type local ou distribué.