Qu’est-ce que le contrôle d’accès basé sur les attributs (ABAC) ?
ABAC est un modèle de Contrôle d'accès qui utilise des attributs pour prendre des décisions de contrôle d’accès. Ces attributs peuvent inclure divers facteurs, tels que :
- Attributs utilisateur : par exemple, rôles, département, localisation, etc.
- Attributs de ressource : par exemple, niveau de sensibilité, propriétaire, type, etc.
- Attributs environnementaux : par exemple, heure d’accès, localisation, appareil, etc.
En évaluant ces attributs et en les passant à travers un ensemble de règles, l’ABAC peut déterminer si un sujet (par exemple, utilisateur, service) doit se voir accorder l’accès à une ressource. Cette approche permet un contrôle d’accès fin et une application dynamique des politiques en fonction du contexte.
Comment fonctionne l’ABAC ?
L’ABAC utilise une approche basée sur des politiques pour le contrôle d’accès. Une politique ABAC typique se compose de :
- Sujet : L’entité demandant l’accès (par exemple, utilisateur, service, appareil).
- Action : L’opération effectuée sur la ressource (par exemple, lire, écrire, supprimer).
- Ressource : L’entité à laquelle on accède (par exemple, fichier, base de données, API).
- Environnement : Le contexte dans lequel l’accès est demandé (par exemple, heure, localisation, appareil).
- Attributs : Les propriétés du sujet, de la ressource et de l’environnement qui sont évaluées pour prendre des décisions d’accès.
- Politiques : Un ensemble de règles qui définissent les conditions sous lesquelles l’accès est accordé ou refusé.
Les politiques ABAC sont plus complexes que les modèles traditionnels de contrôle d’accès comme le Contrôle d'accès basé sur les rôles (RBAC) . En revanche, l’ABAC offre plus de flexibilité et de granularité dans les décisions de contrôle d’accès.
Exemple de politiques ABAC
Par exemple, un système a plusieurs politiques ABAC :
-
Politique 1 : Autoriser l’accès si :
- (Sujet) Le rôle du sujet est
manager
. - (Attribut) Le niveau de sensibilité de la ressource est
high
. - (Environnement) La localisation est
internal
. - (Action) Toute action.
- (Environnement) L’heure est entre 9h et 17h (heures de bureau).
- (Sujet) Le rôle du sujet est
-
Politique 2 : Refuser l’accès si :
- (Sujet) Le rôle du sujet n’est pas
manager
. - (Attribut) Le niveau de sensibilité de la ressource est
high
. - (Environnement) Toute localisation.
- (Action) Toute action.
- (Environnement) Toute heure.
- (Sujet) Le rôle du sujet n’est pas
-
Politique 3 : Autoriser l’accès si :
- (Sujet) Le rôle du sujet est
employee
oumanager
. - (Attribut) Le niveau de sensibilité de la ressource est
low
. - (Environnement) Toute localisation.
- (Action) Action
read
. - (Environnement) Toute heure.
- (Sujet) Le rôle du sujet est
Le moteur d’évaluation des politiques vérifiera ces politiques dans l’ordre, et la première politique qui correspondra aux conditions déterminera la décision d’accès. Pendant ce temps, une politique par défaut de refus est appliquée si aucune autre politique ne correspond.
Passons en revue quelques scénarios pour comprendre comment fonctionne l’ABAC :
Scénario 1. Un utilisateur souhaite accéder (effectuer l’action
read
) à un document (ressource) de niveau de sensibilité élevé en dehors du bureau (environnement). Le rôle de l’utilisateur estmanager
enregistré dans le système.
Décision : L’accès est refusé car l’utilisateur est en dehors du bureau (la localisation n’est pas internal
).
Scénario 2. Un utilisateur souhaite accéder (effectuer l’action
read
) à un document (ressource) de niveau de sensibilité élevé pendant les heures de bureau (environnement) dans le réseau bureautique (localisation=internal
). Le rôle de l’utilisateur estmanager
.
Décision : L’accès est accordé car toutes les conditions de la Politique 1 sont remplies.
Scénario 3. Toutes les conditions du scénario 2 sont les mêmes, mais le rôle de l’utilisateur est
employee
au lieu demanager
.
Décision : L’accès est refusé car le rôle de l’utilisateur ne correspond pas aux conditions de la Politique 1.
Scénario 4. Un utilisateur souhaite accéder (effectuer l’action
read
) à un document (ressource) de niveau de sensibilité faible. Le rôle de l’utilisateur estemployee
.
Décision : L’accès est accordé car toutes les conditions de la Politique 3 sont remplies.
Scénario 5. Un utilisateur souhaite supprimer (effectuer l’action
delete
) un document (ressource) de niveau de sensibilité faible. Le rôle de l’utilisateur estemployee
.
Décision : L’accès est refusé car il n’existe aucune politique qui autorise l’action delete
sur les documents de niveau de sensibilité faible.
Vous remarquerez que tous les attributs ne sont pas nécessaires dans chaque politique. Cette flexibilité permet un mécanisme de contrôle d’accès plus dynamique et sensible au contexte.
Langage de Marquage Extensible pour le Contrôle d’Accès (XACML)
XACML est une norme basée sur XML pour exprimer des politiques de contrôle d’accès. Bien qu’il ne définisse pas de modèle de contrôle d’accès spécifique, XACML est souvent utilisé pour implémenter des politiques ABAC. Voyons un exemple non normatif de la manière dont XACML peut être utilisé pour représenter les politiques ABAC de l’exemple précédent :
<PolicySet PolicySetId="ABAC_Policies" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides">
<Description>ABAC Policies</Description>
<Policy PolicyId="Policy1" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides">
<Description>Employees can read data</Description>
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"
/>
</Match>
</AllOf>
</AnyOf>
</Target>
<Rule RuleId="Rule1" Effect="Permit">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">employee</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"
/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<Rule RuleId="Rule2" Effect="Deny">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">user</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"
/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
</Policy>
<!-- ...other policies... -->
</PolicySet>
Pour plus d’informations sur XACML, consultez eXtensible Access Control Markup Language (XACML) .
Considérations d’implémentation
Bien que l’ABAC offre une manière puissante de gérer le contrôle d’accès, il comporte également certaines considérations d’implémentation :
- Complexité du système : Les politiques ABAC peuvent devenir complexes à mesure que le nombre d’attributs et de règles augmente. Une gestion et un test appropriés des politiques prennent plus de temps que les modèles de contrôle d’accès simples.
- Performance : L’évaluation de politiques ABAC complexes peut avoir un impact sur la performance du système. Les techniques de mise en cache et d’optimisation peuvent aider à atténuer ce problème.
- Conflits de politique : Les politiques conflictuelles peuvent entraîner des décisions d’accès imprévisibles. Un examen régulier des politiques et la résolution des conflits devraient faire partie du processus de gestion des politiques.
ABAC vs. RBAC
Comparer l’ABAC avec le Contrôle d'accès basé sur les rôles (RBAC) peut vous aider à comprendre les différences entre les deux modèles :
RBAC | ABAC | |
---|---|---|
Politique de contrôle d’accès | Basée sur des rôles | Basée sur des attributs |
Granularité | Grossière | Fine-grained |
Flexibilité | Limitée | Très flexible |
Complexité | Plus simple | Plus complexe |
Impact sur la performance | Minimal | Peut être significatif |
Gestion des accès | Gestion des rôles | Gestion des politiques |
Idéal pour | Structures de permission bien définies | Contrôle d’accès dynamique et sensible au contexte |