Le mécanisme de validation des droits d’accès peut se diviser en trois parties qui sont l’instan- ciation de l’ontologie, l’écriture de la politique de sécurité de l’entreprise en une ou plusieurs requêtes DL-query et l’appel a un raisonneur pour vérifier la cohérence des droits d’accès
P DP policies ::= P olicySet | P olicy
P olicySet ::= < POLICYSET P Sheader > [Description] T argets P olicies [Obligation] [Advice] < / POLICYSET >
P olicy ::= < POLICY P header > [Description] T argets Rules [Obligation] [Advice] < / POLICY >
P olicies ::= P olicy | P olicy P olicies
Rules ::= < RULE Rheader > [Description] [T argets] [Condition] [Obligation] [Advice] < / RULE >
P Sheader ::= PolicySetId = string Version = number PolicyCombiningAlgId = P alg
P header ::= PolicyeId = string Version = number RuleCombiningAlgId = Ralg
Rheader ::= RuleId = string Effect = REf f ect
P alg ::= only-one-applicable | Ralg Ralg ::= deny-overrides | permit-overrides | first-applicable | ordered-permit-overrides
REf f ect ::= Permit | Deny
T argets ::= < TARGET > [M atchAny] < / TARGET >
M atchAny ::= < AnyOf > matchAll < / AnyOf >
|< AnyOf > matchAll < / AnyOf > M atchAny
M atchAll ::= < AllOf > M atches < / AnyOf >
|< AnyOf > M atches < / AllOf > M atchAll
M atches ::= M atch | M atch M atches
M atch ::= < Match MatchID = M atchId >
< AttrValue > value < / AttrValue >
< AttributeDesignator ADHeader / > < / Match > M atchId ::= string-equal | integer-equal | string-regexp-match | integer-greater-than | . . .
ADHeader ::= Category= Subject AttributeId = AttSubject DataType= type MustBePresent= boolean
| Category= resource AttributeId = AttResource DataType= type MustBePresent= boolean | Category= action AttributeId = AttAction DataType= type MustBePresent= boolean | Category= environment AttributeId = AttEnv DataType= type MustBePresent= boolean
Subject ::= access-subject | recipient-subject | intermediary-subject . . . AttSubject ::= subject-id | subject-id-qualifier | key-info | authentication-time . . . AttResource ::= resource-id | target-namespace AttAction ::= action-id | implied-action | action-namespace AttEnv ::= current-time | current-date | current-dateTime type ::= x500Name | rfc822Name | ipAddress | dnsName | xpathExpression | string | boolean | double | time | date | dateTime | anyURI | hexBinary | base64Binary
Condition ::= < Condition > BooleanExpression < / Condition >
instanciés suivant la politique de sécurité. – Instanciation de l’ontologie :
Cette étape permet de peupler l’ontologie par les données récupérées via les outils de provisionning. Il est effectué d’une manière automatique par l’API de gestion de l’on- tologie. En effet, en utilisant des parseurs XML, les droits d’accès sont affectés à leur classe respective avec les propriétés qui les caractérisent. Cette opération peut prendre beaucoup de temps d’où la pertinence de le faire cette opération une fois et par la suite d’identifier juste les instances qui ont été modifiées pour mettre à jour notre ontologie. On peut remarquer que l’ontologie nous sert en même temps de base de donnée, car elle permet de stocker les droits d’accès déjà récupérer dans les différents systèmes de l’entreprise. Cet aspect est intéressant, car elle peut permettre de voir l’évolution de l’implémentation de la politique de sécurité dans les différents systèmes au fil du temps et d’avoir des points de comparaison pour des opérations d’audit.
– Écriture des requêtes de la politique de la sécurité :
La politique de sécurité de l’entreprise est généralement décrite dans un document texte qui est compréhensible des cadres et autres personnels de l’entreprise. Ainsi, il est in- dispensable de réécrire ce document pour une exploitation informatique. On peut repré- senter la politique de sécurité d’une manière précise et complète avec un langage comme XACML. De plus, il est nécessaire d’exploiter cette politique pour générer un certain nombre de requêtes qui nous permettront d’interroger automatiquement l’ontologie. En effet, les requêtes sont une série de questions que l’on pose à l’ontologie pour vérifier la validité ou nons des droits d’accès. Pour ce faire, prenons un exemple simple de politique de sécurité qui stipule que le groupe des administrateurs ont accès juste en lecture à un fichier test.txt et que le super utilisateur root de chaque machine seul a le droit d’écriture sur le fichier test.txt. Il est possible de générer une requête DL-Querry pour identifier tous les droits d’accès qui ne respectent pas cette politique. Ainsi on a :
– les éléments que l’on doit retrouver comme instance pour notre ontologie :
– Action Atominque : read, write , execute (pour lecture, écriture et exécution) ; – Utilisateur : root ;
– Groupe : root ;
– Permission : accept, deny ; – Rôle : néan ;
– Resource : test.txt ;
– Appel à la commande ls -l de Linux pour visualiser les droits d’accès sur le fichier test.txt :
# ls -l
– Réécriture de la politique en une requête DL-Query :
Groupe has(root,ApourRole(Role has(,ApourPermission(Prermision
has(Access,PermissionSurRessource(Ressource
has(test.txt)) and FaireAction (Action has(Read))))and Permision
has(Deny,PermissionSurResource (Ressource has(test.txt)) and FaireAction (Action has(Execute) and Action has(Write))))))
and
Utilisateur has(root,ApourRole(Role has(,ApourPermission(Prermision
has(Access,PermissionSurRessource(Ressource has(test.txt)) and FaireAction (Action
has(Read) and Action has(Write))))and Permision has(Deny,PermissionSurResource (Ressource
has(test.txt)) and FaireAction (Action has(Execute))))))
Ainsi, le résultat de cette requête sera composé d’instances qui doivent être qu’un uti- lisateur root pour le droit d’écriture, le reste des utilisateurs pour le droit de lecture et aucun utilisateur pour le droit d’exécution du fichier.
– Appel à un raisonneur :
Le raisonneur permet de faire l’analyse de conformité des instances de l’ontologie et de générer tous les liens possibles entre toutes les instances de l’ontologie. Ainsi, l’ontologie se dote d’une intelligence par laquelle, d’une manière autonome, elle peut répondre aux différentes interrogations que les requêtes provenant de la politique de sécurité nous ont fournies.
Une fois, les trois étapes ont été réalisées, un rapport est généré pour donner la liste des droits d’accès valide et la liste des droits d’accès non valident.
Nous verrons dans la section qui suit un exemple pour mettre en évidence toute le processus de l’outil.