Brevet FR2864657A1 — publié le 20050701

La présente invention concerne un procédé pour le contrôle paramétrable de la sécurité de systèmes informatiques, ce procédé étant utilisable, mais non exclusivement, pour des systèmes informatiques disposant de faibles ressources matérielles. Un tel procédé permet au système informatique en question de réagir en cas de violation de certaines règles de sécurité par exemple, et de façon non limitative, en émettant certains signaux visuels ou sonores, en bloquant le système informatique ou en le faisant passer dans un état spécifique tout en empêchant l'action en cours. D'une façon générale on sait que l'usage de systèmes informatiques portatifs tels que les assistants numériques personnels (PDA), les terminaux de type téléphone cellulaire, les terminaux de paiement bancaire, les terminaux de paiement portatif, se développe de manière extrêmement rapide. Ces systèmes informatiques offrent des services sous une forme compacte et imposent de capacités de stockage et de puissance de traitement limitées. Certains de ces systèmes informatiques portatifs sont équipés de manière à pouvoir communiquer par une liaison sans fil sur des distances limitées avec d'autres systèmes informatiques en utilisant des signaux infrarouges ou radio. De nombreux systèmes informatiques portatifs peuvent également émettre et recevoir du courrier électronique et accéder à Internet. 2864657 2 En termes de risques, plusieurs remarques doivent être prises en considération: - compte tenu de leur petite taille, les systèmes informatiques portatifs peuvent être égarés, sans surveillance particulière, ou être volés, - l'authentification de l'utilisateur peut être désactivée, permettant la divulgation des informations contenues dans le système informatique à toute personne ayant accès physique audit système informatique, - même si l'authentification de l'utilisateur est prévue, le mécanisme d'authentification peut être fragile ou facilement contourné, - la facilité avec laquelle des systèmes informatiques portatifs peuvent être interconnectés sans fil, combinée avec une authentification faible ou inexistante des parties concernées, fournit de nouvelles voies pour l'introduction des virus ou d'autres types de code délictueux. Les risques deviennent plus importants quand le système informatique portatif est utilisé comme point d'entrée vers un réseau d'entreprise ou comme fournisseur de services offerts par un opérateur de télécommunication. Dans le meilleur des cas, une entreprise ou un agent de sécurité voudrait pouvoir exprimer, surveiller, et imposer un contrôle de sécurité afin de réduire les risques sur le système informatique. Les systèmes informatiques portatifs existants manquent notamment de moyens de contrôle suffisants pour imposer l'utilisation de mécanismes disponibles selon une procédure de sécurité prescrite. Un contrôleur de sécurité devrait permettre à l'utilisateur de définir ses propres règles sur son système informatique sans l'autoriser à contourner les règles générales définies par l'agent de sécurité. A titre d'exemple non limitatif, les règles de sécurité peuvent être utilisées, pour: interdire l'utilisation d'un service qui, en cas d'abus, pourrait infliger des dégâts ou des pertes à l'utilisateur du système infoi natique, à l'entreprise ou à l'opérateur, 2864657 3 - interdire l'utilisation d'un service sensible du système d'exploitation à toute application pour le réserver aux composants du système d'exploitation lui-même, - interdire l'installation d'une application qui accéderait à un service sans autorisation explicite de l'utilisateur, - réserver l'utilisation d'un service à des utilisateurs privilégiés, En plus des interdictions d'effectuer certaines actions, ce contrôleur peut déclencher des actions permettant de signaler la tentative de violation de la procédure de sécurité, comme, par exemple, l'émission de signaux visuels ou sonores, le blocage complet du système informatique ou l'indisponibilité de certaines fonctions, le changement d'état interne du système informatique, etc. Deux contraintes majeures doivent être prises en considération dans le 15 contexte décrit précédemment: - la nécessité de personnalisation (ou paramétrage) d'un contrôleur de sécurité par différents acteurs (par exemple l'agent de sécurité, l'opérateur, l'utilisateur, etc.): un contrôleur n'offrant pas cette possibilité serait trop rigide pour être utilisable en pratique. - la nécessité de mettre en oeuvre le contrôleur de sécurité de manière efficace sur de petits systèmes informatiques disposant de ressources limitées. Deux techniques principales ont été exploitées pour satisfaire le besoin de personnalisation d'un contrôleur de sécurité: - la personnalisation par des interfaces dédiées qui peuvent être exploitées par les différents acteurs (agent de sécurité, utilisateur, etc.) pour définir (ou paramétrer) une procédure de sécurité par exemple en choisissant des éléments dans une liste ou en cochant des cases dans un tableau; ce mode de personnalisation est trop simple pour pouvoir prendre en compte les exigences variées des différents acteurs concernés par les systèmes informatiques portatifs (agent de sécurité, utilisateur, opérateur, etc.) ; 2864657 4 - la définition des procédures de sécurité en utilisant un langage dédié ; les langages dédiés existants, trop riches, ne sont pas appropriés aux systèmes informatiques portatifs dont les ressources matérielles sont limitées. L'invention a donc plus particulièrement pour but de supprimer ces inconvénients. A cet effet, elle propose un procédé pour le contrôle paramétrable de la sécurité des systèmes informatiques, applicable notamment, mais non exclusivement, à des systèmes informatiques portatifs ou embarqués disposant de faibles ressources matérielles, comprenant: la définition d'une procédure de sécurité à l'aide d'un langage permettant de définir des règles de sécurité, faisant intervenir des sujets représentant les entités actives dudit système informatique capables d'effectuer des actions sur des objets représentant les entités passives dudit système informatique, et un traitement dudit langage permettant d'appliquer les dites règles de sécurité dans les susdits systèmes informatiques comprenant une compilation du susdit langage en des représentations internes, et une exploitation desdites représentations internes à des fins de contrôle de sécurité. La procédure de sécurité comprend une pluralité de règles de contrôle qui indiquent des autorisations pour des sujets (ou acteurs) d'accéder à des objets (ou ressources, biens) pour exécuter une action particulière sur ces objets. L'action peut consister, par exemple, et d'une manière non limitative, en la lecture, la création ou la modification de l'objet concerné. La procédure de sécurité comprend également des traitements spécifiques, dits d'exception, en cas de tentative d'infraction à une règle de sécurité. Ces traitements d'exception peuvent consister, par exemple en l'émission de signaux visuels 2864657 5 ou sonores, le blocage complet de l'appareil ou l'indisponibilité de certaines fonctions, le changement d'état interne du système, etc. On considère des ensembles prédéfinis de sujets, d'objets et de types de 5 services. Une procédure de sécurité comporte les déclarations suivantes: - Déclarations des groupes de sujets (optionnel). Une telle déclaration consiste à attribuer un identificateur à un ensemble de sujets. Ce type de déclaration permet ensuite d'associer des règles de contrôle à un ensemble de sujets. Un sujet est représenté par un identificateur, et, sur option, des attributs de sécurité (indiquant, par exemple, si le sujet a été authentifié et par qui). Ceci permet ensuite de définir des règles d'accès dépendant de l'origine d'un sujet. - Déclarations des groupes d'objets (optionnel). Une telle déclaration comprend la définition d'un groupe d'objets et, sur option, de sous-groupes d'objets. Une définition de groupe d'objets présente un nom de groupe qui servira à classer des objets selon certaines propriétés. Certains groupes peuvent être pré-définis dans le système. Une déclaration de sous-groupe permet de classer des objets en sous-ensembles plus spécialisés. - Déclarations des services (optionnel). Une telle déclaration se compose d'un attribut indiquant le type du service, un identificateur de service (unique), les ressources auxquelles s'applique le 25 service et l'ensemble des fonctions supportées par le service. - Déclaration des règles de contrôle. Des règles positives et des règles négatives de contrôle d'accès peuvent être définies. Une règle positive de contrôle autorise s à réaliser a, où * s est un sujet ou un groupe de sujets, 2864657 6 * a est une action ou un ensemble d'actions sur des ressources, où - une action est un type de service, ou un identificateur de service, ou un identificateur d'une fonction de service. - une ressource est un objet ou un groupe d'objets. Une règle négative de contrôle interdit à s de réaliser a, où s et a sont définis comme cidessus. De plus, une règle négative peut être associée (de manière optionnelle) à un traitement adéquat (par exemple: passage dans un état spécifique, émission d'un signal, blocage partiel ou total de l'appareil, etc.), dit traitement d'exception . Le traitement d'exception par défaut est l'interdiction de l'action indiquée dans la règle. Chaque règle peut également être associée (de manière optionnelle) à des attributs, dits de sécurité, comme, par exemple, le niveau de responsabilité de l'acteur (agent de sécurité, opérateur, utilisateur, etc.) ayant introduit la règle. Ces attributs de sécurité peuvent être utilisés par la procédure de traitement d'incohérence en cas d'incompatibilité entre plusieurs règles de sécurité. Ceci permet notamment d'assurer que les règles définies par l'agent de sécurité l'emporteront sur toutes celles qui sont introduites par l'utilisateur. Une hiérarchie est implicitement associée aux actions. Une action TS1, par exemple, où TS1 est un type particulier de service, doit être comprise comme englobant chaque fonction de chaque service fourni par le type de service TS1. D'une manière analogue, l'action TS1.S1 doit être comprise comme englobant toutes les fonctions fournies par le service S1 de type TS1. On utilisera le symbole Une procédure de sécurité selon l'invention permet donc d'indiquer pour un sujet donné plusieurs règles d'accès. La définition d'une règle positive et d'une 2864657 -7- règle négative de contrôle pour un même sujet et une même action sur une ressource donnée amène à un conflit. Une stratégie de résolution des conflits peut être définie pour chaque type de conflit. Cette stratégie peut exploiter par exemple les attributs de sécurité associés aux règles afin de garantir qu'une règle introduite par un acteur prioritaire (agent de sécurité par exemple) l'emporte sur une règle définie par l'utilisateur. Un mode d'exécution de l'invention sera décrit ci-après, à titre d'exemple non limitatif, avec référence aux dessins annexés: É la figure 1 illustre un exemple de déclaration d'une procédure de contrôle de sécurité pour la téléphonie mobile, É la figure 2 illustre la traduction de la procédure de sécurité et de l'information atomique de ladite procédure de sécurité. Dans cet exemple, comme représenté sur la figure 1, la procédure de contrôle déclare un groupe de sujets G, trois groupes d'objets: "NationalNumber", "InternationalNumber" et "FreeNumber", chacun d'eux étant une spécialisation d'un groupe prédéfini d'objets 20 "PhoneNumbers", et deux règles (l'une positive, l'autre négative) pour le groupe G ainsi qu'une règle (positive) pour le sujet prédéfini "my_application". La notation [0-9] * représente une suite de chiffres de longueur quelconque. Le traitement d'exception associé à la règle négative est l'émission d'un signal sonore spécifique. La mise en oeuvre d'une procédure de contrôle de sécurité consiste à examiner les règles de la procédure, lors de toute tentative d'accès à une ressource par un sujet, afin de décider si la permission d'accéder à la ressource est accordée au sujet et, dans la négative, d'effectuer le traitement d'exception associé à la 2864657 8 règle négative concernée. L'ensemble de ces opérations est effectué par le processeur du système informatique. Par conséquent, dans le cas où le processeur est limité en terme de ressources (stockage, calcul), il est extrêmement important que la procédure de sécurité puisse être enregistrée de manière compacte dans le système informatique et qu'il soit possible de mettre en application un calcul efficace des règles de décision (calcul qu'on appellera opération de décision par la suite). Selon l'invention une mise en oeuvre efficace d'une procédure de contrôle de sécurité peut être réalisée à l'aide des deux étapes suivantes: (1) vérification de la cohérence de l'ensemble de règles de contrôle: il s'agit de vérifier que les règles de contrôle d'accès définies dans la procédure ne sont pas contradictoires et associent les sujets, les actions et les ressources de manière adéquate. Une procédure défectueuse est, par exemple, une procédure qui indique une règle de contrôle d'accès pour un sujet qui n'est ni prédéfini, ni explicitement déclaré par ailleurs. Un autre exemple est celui concernant une règle de contrôle pour une action a sur un certain objet o tel que o n'est pas un objet sur lequel l'action peut être exécutée. La vérification de cohérence d'une procédure de sécurité préalablement à sa traduction offre les avantages suivants: * elle permet de prévenir dans une première étape des erreurs qui 25 pourraient provoquer le défaut de fonctionnement de la traduction de la procédure. * elle permet de simplifier la définition de l'opération de décision: si, par hypothèse, on sait que cette opération ne sera effectuée que sur des procédures conformes, il n'est pas nécessaire de vérifier dynamiquement (à l'exécution) la cohérence de la procédure. Ceci améliorera de manière significative l'efficacité de l'opération de décision d'accès. 2864657 9 (2) la traduction de la procédure de sécurité dans une représentation interne compacte permettant un accès efficace à ses règles de contrôle. Une procédure de sécurité est formée de quatre composants principaux: les groupes de sujets, les groupes d'objets, les services (qui permettent de définir les actions) et les règles de contrôle d'accès. Les règles de contrôle d'accès sont le plus souvent examinées. Les règles de contrôle d'une procédure de sécurité peuvent être considérées comme des relations liant les sujets (et groupes de sujets), les actions et les objets. Le procédé selon l'invention permet différentes structures de données pour représenter ces informations. Le choix parmi des structures candidates dépend des facteurs suivants: É les accès à la structure exigés par l'opération de décision (de façon à permettre une mise en oeuvre efficace de cette opération), et É l'espace requis par l'implémentation de chaque structure. La représentation interne d'une procédure peut elle-même être traduite (ou compilée) en code natif, c'est-à-dire, en un code supporté par la plate-forme du système informatique. L'avantage de séparer la génération de la représentation interne de la compilation en code natif est que la première traduction permet d'obtenir une version optimisée de la procédure indépendante de la plate- folme sur laquelle elle sera exécutée. La vérification de cohérence d'une procédure de sécurité, sa traduction en une représentation interne optimisée et l'exploitation de cette représentation pour effectuer l'opération de décision sont les trois étapes essentielles du procédé selon l'invention qui permettent la mise en oeuvre efficace d'une procédure de sécurité paramétrée sur des systèmes informatiques disposant de ressources (mémoire, calcul) limitées. Ces trois étapes sont décrites successivement: La vérification de cohérence d'une procédure de sécurité inclut les étapes suivantes: - Etape 1: vérifier la cohérence des déclarations de groupes de sujets. Ceci revient à vérifier que, pour chaque déclaration de groupe de sujets: * tous les membres du groupe sont des sujets distincts prédéfinis, et * l'identificateur attaché au groupe n'existe pas déjà. - Etape 2: vérifier la cohérence des déclarations de groupes d'objets. Ceci revient à vérifier que, pour chaque déclaration de groupe 15 d'objets: * tous les membres du groupe sont des objets distincts prédéfinis, et * l'identificateur attaché au groupe n'existe pas déjà. - Etape 3: vérifier la cohérence des services. Ceci revient à vérifier que: * la définition des ressources de chaque service est bien formée. Les ressources d'un service étant définies comme des groupe d'objets, il s'agit de vérifier la cohérence de ces groupes comme indiqué ci-dessus. * la définition des fonctions du service est bien formée. Ceci revient à vérifier que: o les identificateurs de fonctions sont tous distincts, et o pour chaque fonction, le groupe d'objets, le cas échéant, sur lesquels la fonction peut être appliquée est déjà défini. * l'identificateur attaché au service n'existe pas déjà. - Etape 4: vérifier que les règles de sécurité sont bien formées. Ceci revient à vérifier que: * chaque règle de contrôle d'accès satisfait les critères suivants: o le sujet de la règle est défini (sujet prédéfini ou identificateur d'un des groupes de sujets), et o l'ensemble des paires (action, objet) de la règle est bien formé. Ceci revient à vérifier que: cet ensemble n'est pas vide, - chaque action de cet ensemble appartient à un des services déclarés, et - l'objet associé à chaque action est valide (appartient aux ressources déclarées pour cette action). * si des règles de contrôle sont en conflit, il existe une procédure de résolution des conflits (dite procédure de traitement d'incohérence) qui spécifie les actions à appliquer; cette procédure peut, par exemple, utiliser les attributs de sécurité associés à deux règles de contrôle conflictuelles pour déterminer que l'une des deux l'emporte sur l'autre. Deux règles ri et r2 sont en conflit si: o ri est une règle positive (respectivement négative) et r2 est une règle négative (respectivement positive), et o S I est le sujet de ri, S2 est le sujet de r 2, et S i et S2 sont soit identiques, soit dans une relation d'inclusion (S 1 est inclus dans S2 ou vice-versa) , et 2864657 -12- ri concerne une action al sur un objet o, r2 concerne une action a2 sur le même objet o et al et a2 sont la même action ou sont liés par la relation c'est à dire al Le procédé selon l'invention n'impose pas que les étapes 1 à 4 de la vérification soient exécutées dans cet ordre. La traduction de la susdite procédure de sécurité en représentations internes 10 optimisée comporte les deux étapes suivantes: - Etape 1: la traduction de chaque information atomique de la procédure dans une représentation numérique correspondante. Par information atomique, on entend les différents types d'identificateurs impliqués dans une déclaration de procédure de sécurité, comme, par exemple, ceux des sujets, des groupes de sujets, des groupes d'objets et des services. Un autre type d'information atomique est celui utilisé pour représenter des actions et, en particulier, des fonctions des services. Cette traduction permet d'obtenir une représentation mémoire compacte de la procédure. A titre d'exemple, l'information qui identifie une fonction d'un service, qui comprend la juxtaposition de trois identificateurs, peut être traduite en représentation TSSSFFFF de quatre octets où T est le type de service (1 quartet), SSS est le service (3 quartets), et FFFF est la fonction (4 quartets). Afin d'optimiser l'espace mémoire nécessaire, les différentes occurrences d'une même information atomique peuvent être partagées dans une table de correspondance et accédées à l'aide de références pointant sur l'entrée appropriée de la table. - Etape 2: la traduction des règles de contrôle de la procédure dans une structure de données optimisée. La génération de cette structure de données est 30 optimisée en fonction des types d'accès exigés par l'opération de décision. 2864657 - 13 - L'exploitation des susdites représentations internes pour effectuer l'opération de décision est déclenchée quand une demande d'accès à un service a été détectée. Une demande d'accès peut être caractérisée par une question de la forme: s peut-il exécuter a sur o? dans laquelle s est un (groupe de) sujet(s), a est une action et o est une (un groupe de) ressource(s). Pour l'exemple de la procédure déclarée, représentée sur la figure 1, une demande de décision d'accès concernant la permission d'envoyer un fax à un numéro de téléphone étranger pourrait être formulée comme suit: Fax peut-il exécuter OS.Telephony.Dial sur 005983422358 ? Un mode de résolution d'une demande de décision d'accès concernant une action a, consiste à appliquer les étapes suivantes: ADl) déterminer l'ensemble S de paires ( action , objet ou ensemble d'objets ) déclarés dans la procédure pour le sujet s, puis déterminer le sous- ensemble SA de S qui correspond à l'action a, AD2) vérifier si un des éléments de SA s'applique à l'objet o (c'est à dire si un 20 élément (a,y) de SA est tel que y est égal à o ou inclut o). Par exemple, dans le cas de la procédure de sécurité représentée dans la figure 1 deux règles de contrôle ont été définies pour le sujet Fax (plus précisément pour le groupe G auquel le sujet Fax appartient). Puisque 005983422358 est un numéro de téléphone international, et qu'il existe une règle négative pour l'action "OS.Telephony.Dial" sur les numéros de téléphone internationaux, la demande d'accès est refusée. Ce refus s'accompagne de l'émission du signal sonore spécifique double bip . Etant donné un (groupe de) sujet(s) s et une action a, la procédure AD1) implique les traitements suivants: 2864657 -14- - si s est un sujet prédéfini, déterminer tous les groupes de sujets dans lesquels s apparaît, puis effectuer l'union des ensembles de paires (action, objet) qui ont été déclarées pour ces groupes dans la procédure de sécurité, - si s est un groupe de sujets, effectuer l'union des ensembles de paires (action, objet) qui ont été déclarées pour s, puis - filtrer les paires (a', o') rassemblées et ne garder que celles qui vérifient a La procédure ADl) décrite ci-dessus peut être mise en oeuvre efficacement en appliquant le mode de réalisation suivant pour la traduction des règles de contrôle d'une procédure Les règles de contrôle sont traduites en un tableau dont chaque élément 15 contient (1) la représentation interne d'un sujet pré-défini (ou d'un groupe de sujets) S, (2) un pointeur sur un tableau de valeurs booléennes indiquant pour chaque sujet prédéfini, s'il appartient ou non à s (cette information étant vide dans le cas où S est un sujet pré-défini et non un groupe de sujets), (3) un pointeur sur une structure contenant les représentations internes des actions et des objets associés à s avec un signe (bit) indiquant si la règle de contrôle définit une autorisation ou une interdiction et, en cas de valeur négative, un pointeur (optionnel) sur le code de traitement d'exception associé. La figure 2 illustre, à titre d'exemple, la traduction, décrite ci-dessus, de la procédure de sécurité représentée sur la figure 1. La figure 2 illustre également 30 la traduction de l'information atomique de cette procédure de sécurité. 25 2864657 - 15- Deux types de structures sont à considérer, comme représenté sur la figure 2: 1. Le tableau CRS qui correspond à la traduction des règles de contrôle de la procédure de sécurité, comme représenté sur la figure 1, selon la procédure de traduction décrite ci-dessus. 2. Les tableaux de correspondance qui contiennent les représentations internes des informations atomiques utilisées dans les règles de contrôle. Trois tableaux, TRIS, TRIA, TRIO, associent une représentation numérique à la représentation interne des entités (sujets, actions et objets respectivement) qui participent aux règles de contrôle. Le tableau CRS est un tableau à deux éléments CRS1, CRS2 (qui correspondent aux deux sujets et groupes de sujets pour lesquels des règles ont été définies, comme représenté sur la figure 1). Le premier élément du tableau CRS1 est composé : É de l'indice (4) qui identifie la représentation interne du groupe G dans le tableau TRIS, É d'une référence RefTSG au tableau TSG qui enregistre les sujets pré- définis appartenant au groupe G, et É d'une référence RefLAG au tableau LAG des triplets (signe, action, objet) et quadruplets (signe, action, objet, traitement d'exception) correspondant aux règles de contrôle du groupe G. Le tableau TSG indique que les sujets correspondant aux représentations internes associées aux indices 0, 1, 2 du tableau TRIS (c'est-à-dire, fax, 25 combiné et minitel respectivement) appartiennent au groupe G. Le tableau LAG contient deux triplets et un quadruplet qui correspondent aux règles déclarées, comme représenté sur la figure 1, pour le groupe G. En particulier l'élément (-,0, 2, adresse de double-bip ) indique qu'il est interdit, pour n'importe quel sujet appartenant au groupe G, d'utiliser le service Dial (représenté par l'indice 0 du tableau TRIA) pour effectuer une 2864657 - 16- connexion vers un numéro de téléphone international (représenté par l'indice 2 du tableau TRIO) et qu'une tentative d'infraction sera signalée par un double bip sonore. Le deuxième élément du tableau CRS2 est composé : É de l'indice (3) du tableau TRIS qui identifie la représentation interne du sujet pré-défini my_application , É d'un élément vide EV ( my_application , étant un sujet, cet élément ne comporte pas de définition de groupe de sujet), É d'une référence RefLAMAPP au tableau LAMAPP des triplets (signe, action, objet) correspondant aux règles de contrôle du sujet my_application . Ce tableau contient un seul élément indiquant que le sujet est autorisé à utiliser le service Dial pour effectuer une connexion vers un numéro de téléphone non payant (représenté par l'indice 3 du tableau TRIO). -17-Revendications 1. Procédé pour le contrôle paramétrable de la sécurité des systèmes informatiques, caractérisé en ce qu'il comprend: la définition d'une procédure de sécurité à l'aide d'un langage permettant de définir des règles de sécurité, lesdites règles faisant intervenir des sujets représentant les entités actives dudit système informatique capables d'effectuer des actions sur des objets représentant les entités passives dudit système informatique, et un traitement dudit langage permettant d'appliquer lesdites règles de sécurité, ledit traitement comprenant une compilation du susdit langage en des représentations internes, et une exploitation desdites représentations internes. 2. Procédé selon la revendication 1, caractérisé en ce que ledit langage permettant de définir l'ensemble des règles de sécurité comprend au moins les notions de groupes de sujets et/ou de groupes d'objets et/ou de groupes d'actions, chacun de ces groupes pouvant lui-même être organisé en sous-groupes, l'ensemble formant une hiérarchie de tune arborescente. 3. Procédé selon la revendication 1, caractérisé en ce que ledit langage permettant de définir l'ensemble des règles de sécurité comprend au moins des règles dites positives spécifiant les droits pour certains sujets, ou certains groupes de sujets, d'effectuer certaines actions, ou certains groupes d'actions, sur certains objets, ou certains groupes d'objets. 15 2864657 -18- 4. Procédé selon la revendication 1, caractérisé en ce que ledit langage permettant de définir l'ensemble des règles de sécurité comprend au moins des règles dites négatives spécifiant les interdictions pour certains sujets, ou certains groupes de sujets, d'effectuer certaines actions, ou certains groupes d'actions, sur certains objets, ou certains groupes d'objets. 5. Procédé selon la revendication 1, caractérisé en ce que ledit langage permettant de définir l'ensemble des règles de sécurité comprend à la fois des règles dites positives spécifiant les droits pour certains sujets, ou certains groupes de sujets, d'effectuer certaines actions, ou certains groupes d'actions, sur certains objets, ou certains groupes d'objets, et des règles dites négatives spécifiant les interdictions pour certains sujets, ou certains groupes de sujets, d'effectuer certaines actions, ou certains groupes d'actions, sur certains objets, ou certains groupes d'objets. 6. Procédé selon l'une des revendications 4 et 5, caractérisé en ce que lesdites règles négatives peuvent être, de manière optionnelle, associées à des traitements spécifiques, dits d'exception, qui seront effectués en cas de tentative d'infraction à ces règles. 7. Procédé selon la revendication 6, caractérisé en ce que lesdits traitements d'exception consistent à modifier l'état interne du système informatique et/ou à émettre certains signaux, visuels ou sonores. 8. Procédé selon la revendication 6, caractérisé en ce que lesdits traitements d'exception consistent à rendre indisponibles certaines fonctionnalités du système 2864657 -19- informatique, temporairement ou définitivement, ou à bloquer ledit système informatique lui-même. 9. Procédé selon la revendication 1, caractérisé en ce que ledit traitement du langage comprend une étape de vérification de cohérence des procédures de sécurité et de traitement des incohérences éventuelles, lesdits traitements d'incohérence pouvant être uniques ou différents selon le type d'incohérence détectée. 10. Procédé selon la revendication 9, caractérisé en ce que lesdits traitements d'incohérence utilisent des attributs de sécurité associés aux règles de contrôle pour déterminer les priorités entre ces règles. 11. Procédé selon la revendication 9, caractérisé en ce que ladite étape de vérification de cohérence des règles de sécurité comprend: É la détection d'incohérences logiques ou de malformation des groupes d'objets, de sujets et/ou d'actions, É la détection d'incohérence entre les règles dites positives et les règles dites négatives, chacune de ces détections étant optionnelle. 12. Procédé selon la revendication 1, caractérisé en ce qu'il comprend au moins l'une des opérations suivantes, exécutées dans un ordre quelconque: É une opération de calcul, pour un sujet ou un groupe de sujets donné(s), de l'ensemble des actions ou groupes d'actions sur 2864657 -20- lesquelles ledit sujet, ou groupe de sujets, possède des droits ou des interdictions, É une opération de calcul, pour un sujet ou un groupe de sujets donné(s), de l'ensemble des objets ou groupes d'objets sur lesquels ledit sujet, ou groupe de sujets, possède des droits ou des interdictions, É une opération de calcul, pour une action ou un groupe d'actions donnée(s) de l'ensemble des sujets et/ou groupes de sujets qui possèdent des droits ou des interdictions sur ladite action ou ledit groupe d'actions, É une opération de calcul, pour une action ou un groupe d'actions donnée(s) de l'ensemble des objets et/ou groupes d'objets sur lesquels certains sujets ou groupes de sujets possèdent des droits ou des interdictions sur ladite action ou ledit groupe d'actions, É une opération de calcul, pour un objet ou un groupe d'objets donné(s), de l'ensemble des sujets ou groupes de sujets qui possèdent des droits ou des interdictions sur ledit objet ou groupe d'objets, É une opération de calcul, pour un objet ou un groupe d'objets donné(s), de l'ensemble des actions pour lesquelles certains sujets ou groupes de sujets possèdent des droits ou des interdictions sur ledit objet ou groupe d'objets. 13. Système informatique portatif embarqué caractérisé en ce qu'il comprend des moyens pour la mise en oeuvre du procédé selon l'une des revendications précédentes. 14. Système informatique selon la revendication 13, caractérisé en ce qu'il consiste en un assistant numérique personnel, un terminal de type téléphone cellulaire, un terminal de paiement bancaire, un terminal de paiement portatif, ou une carte à puce.