{"id":4183,"date":"2024-10-29T10:56:41","date_gmt":"2024-10-29T14:56:41","guid":{"rendered":"https:\/\/www.indigoconsulting.ca\/?p=4183"},"modified":"2024-12-05T15:52:29","modified_gmt":"2024-12-05T20:52:29","slug":"demystification-de-lautorisation-votre-passerelle-vers-un-acces-securise","status":"publish","type":"post","link":"https:\/\/www.indigoconsulting.ca\/fr\/french-blog\/demystification-de-lautorisation-votre-passerelle-vers-un-acces-securise\/","title":{"rendered":"D\u00e9mystification de l’autorisation : votre passerelle vers un acc\u00e8s s\u00e9curis\u00e9"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Cet article pr\u00e9sente les concepts de base sur l’autorisation dans la gestion des identit\u00e9s et des acc\u00e8s (GIA). Son objectif est d’introduire les mod\u00e8les de contr\u00f4le d’acc\u00e8s couramment utilis\u00e9s aujourd’hui, avec une exploration plus approfondie du mod\u00e8le de contr\u00f4le d’acc\u00e8s bas\u00e9 sur les attributs (<\/span>attribute based access control <\/span><\/i>– ABAC). Ce mod\u00e8le qui gagne de plus en plus de popularit\u00e9 dans l’industrie est souvent mal compris.<\/span><\/p>

Avant de commencer, voici quelques concepts cl\u00e9s r\u00e9f\u00e9renc\u00e9s tout au long de l’article.<\/span><\/p>

Sujet<\/b><\/p>

L’entit\u00e9 qui acc\u00e8de \u00e0 un objet. Le sujet peut \u00eatre, par exemple, un utilisateur ou un processus automatique.<\/span><\/p>

Object<\/b><\/p>

La ressource qui est acc\u00e9d\u00e9e. Cela peut inclure un fichier dans un syst\u00e8me d’exploitation, un champ dans un dossier personnel, une API, etc.<\/span><\/p>

Mod\u00e8les de contr\u00f4le d’acc\u00e8s<\/span><\/strong><\/h2>

\"\"<\/p>

Cette section couvre les principaux mod\u00e8les de contr\u00f4le d’acc\u00e8s que l’on peut rencontrer dans les solutions d’autorisation.<\/span><\/p>

Liste de contr\u00f4le d’acc\u00e8s (access control list – ACL)<\/span><\/h3>

Ce mod\u00e8le de contr\u00f4le d’acc\u00e8s fut l’un des premiers qui fut con\u00e7u. La premi\u00e8re impl\u00e9mentation de ce mod\u00e8le remonte \u00e0 1965 avec le syst\u00e8me d’exploitation Multics.<\/span><\/p>

Dans ce mod\u00e8le, le propri\u00e9taire d’une ressource maintient une liste des sujets (des utilisateurs, des comptes, etc.) qui peuvent acc\u00e9der \u00e0 ses ressources et les actions qu’ils sont autoris\u00e9s \u00e0 effectuer.<\/span><\/p>

Ce mod\u00e8le est utilis\u00e9 dans divers contextes. Par exemple, dans un syst\u00e8me d’exploitation, un fichier est associ\u00e9 \u00e0 une liste de sujets. Ces sujets qui peuvent lire le fichier, le modifier ou le supprimer. Dans un annuaire LDAP, une ACL d\u00e9finit comment un sujet peut interagir avec les objets de l’annuaire.<\/span><\/p>

Contr\u00f4le d’acc\u00e8s bas\u00e9 sur les r\u00f4les (role-based access control – RBAC)<\/span><\/h3>

Ce mod\u00e8le, d\u00e9velopp\u00e9 par des chercheurs du NIST en 1992, introduit une distinction cl\u00e9 par rapport au mod\u00e8le ACL en rompant la relation directe entre sujets et objets.<\/span><\/p>

Dans le mod\u00e8le RBAC, les permissions ne sont pas directement attribu\u00e9es aux sujets. Les sujets sont plut\u00f4t assign\u00e9s \u00e0 des r\u00f4les. Ces r\u00f4les se voient ensuite accorder des permissions sur des objets sp\u00e9cifiques.<\/span><\/p>

Ces r\u00f4les peuvent repr\u00e9senter plusieurs concepts, tels que la fonction du sujet ou son d\u00e9partement dans une organisation. Un r\u00f4le peut \u00eatre utilis\u00e9 pour regrouper les sujets et les privil\u00e8ges, simplifiant ainsi leur gestion. Cependant, en pratique, la plupart des organisations sont confront\u00e9es \u00e0 une “explosion des r\u00f4les”. Cette situation survient lorsqu\u2019une multitude de r\u00f4les distincts est cr\u00e9\u00e9e pour tenir compte de chaque exception ou nuance dans les privil\u00e8ges. Ceci complique consid\u00e9rablement la gestion des r\u00f4les.<\/span><\/p>

Contr\u00f4le d’acc\u00e8s bas\u00e9 sur les attributs (attribute based access control – ABAC)<\/span><\/h3>

ABAC peut \u00eatre consid\u00e9r\u00e9 comme une g\u00e9n\u00e9ralisation plus flexible du mod\u00e8le RBAC. Dans le mod\u00e8le RBAC, les privil\u00e8ges d’un sujet sur un objet sont d\u00e9termin\u00e9s par les r\u00f4les qui lui sont assign\u00e9s. En revanche, avec le mod\u00e8le ABAC, les privil\u00e8ges peuvent d\u00e9pendre de n’importe quel attribut du sujet, et pas seulement de son r\u00f4le. Parmi les exemples d’attributs, on peut inclure l’unit\u00e9 commerciale du sujet, son niveau de s\u00e9niorit\u00e9 dans une organisation, son niveau d’habilitation de s\u00e9curit\u00e9, etc.<\/span><\/p>

Le mod\u00e8le ABAC incorpore \u00e9galement la notion d\u2019attributs d\u2019objets et d\u2019attributs contextuels. Les attributs d\u2019objets d\u00e9finissent les ressources accessibles, tandis que les attributs contextuels d\u00e9finissent le contexte dans lequel une demande d’autorisation est effectu\u00e9e. Ces trois niveaux d’attributs permettent d’\u00e9tablir des politiques complexes et flexibles. Par exemple, une politique pourrait \u00eatre :<\/span><\/p>

Un employ\u00e9 d\u2019une banque travaillant \u00e0 la succursale de Montr\u00e9al peut acc\u00e9der aux comptes d’un client VIP, uniquement lors des heures de bureau et uniquement si la demande est effectu\u00e9e depuis l’Am\u00e9rique du Nord.<\/span><\/i><\/p>

Il est important de noter que nous consid\u00e9rons ABAC et le contr\u00f4le d’acc\u00e8s bas\u00e9 sur les politiques (policy-based access control – PBAC) comme synonymes. PBAC est parfois utilis\u00e9 comme un terme alternatif pour les solutions qui impl\u00e9mentent en fait le mod\u00e8le ABAC. Les solutions ABAC et PBAC permettent la cr\u00e9ation de politiques d’autorisation bas\u00e9es sur les attributs des sujets, des objets et du contexte.<\/span><\/p>

Contr\u00f4le d’acc\u00e8s bas\u00e9 sur les relations (relationship-based access control – ReBAC)
<\/span><\/h3>

L’id\u00e9e d’un mod\u00e8le d’autorisation bas\u00e9 sur les relations a \u00e9t\u00e9 formalis\u00e9e pour la premi\u00e8re fois en 2006 dans le contexte du partage d’informations dans les r\u00e9seaux sociaux. Une des applications de ce mod\u00e8le est de permettre \u00e0 un individu de partager diverses informations avec d’autres individus en fonction de leur relation.<\/span><\/p>

Le mod\u00e8le ReBAC est similaire \u00e0 ABAC en ce sens que les deux peuvent d\u00e9finir des politiques d’autorisation complexes et granulaires. La principale diff\u00e9rence entre les deux mod\u00e8les r\u00e9side dans la mani\u00e8re dont les politiques sont con\u00e7ues et \u00e9valu\u00e9es. Dans le mod\u00e8le ABAC, les attributs du sujet, de l’objet et du contexte sont \u00e9valu\u00e9s. Dans le mod\u00e8le ReBAC, ce qui est \u00e9valu\u00e9 est la relation entre le sujet et l’objet.<\/span><\/p>

Par exemple, dans le mod\u00e8le ReBAC, un document pourrait avoir une relation d’\u00e9diteur avec un sujet sp\u00e9cifique. Si ce sujet tente de modifier le document, le syst\u00e8me ReBAC v\u00e9rifie que la relation d’\u00e9diteur existe entre le sujet et l’objet. Si une telle relation n’existe pas, la demande de modification est refus\u00e9e.<\/span><\/p>

Mod\u00e8le ABAC
<\/span><\/h2>

Cette section se concentre sur l’architecture et les composants du mod\u00e8le ABAC.<\/span><\/p>

Architecture ABAC<\/span><\/h3>

Les divers composants d’une architecture ABAC ont \u00e9t\u00e9 initialement d\u00e9finis dans le cadre d’autorisation AAA (RFC 2904), publi\u00e9 en 2000. Ce RFC a \u00e9tabli les bases des politiques distribu\u00e9es qui sont d\u00e9sormais utilis\u00e9es dans les solutions ABAC modernes.<\/p>

Voici un sch\u00e9ma illustrant les diff\u00e9rents composants du mod\u00e8le ABAC et la mani\u00e8re dont ils interagissent entre eux.<\/p>

\"\"<\/span><\/p>

Le d\u00e9roulement d\u2019une requ\u00eate suit les \u00e9tapes suivantes :<\/span><\/p>

  1. Une requ\u00eate est envoy\u00e9e \u00e0 un syst\u00e8me pour un objet (ressource), tel que la r\u00e9cup\u00e9ration de dossiers dans une base de donn\u00e9es ou l’appel d’une API. Cette requ\u00eate est intercept\u00e9e par le point d\u2019application de politiques (Policy Enforcement Point – PEP), qui fait g\u00e9n\u00e9ralement partie du syst\u00e8me qui retourne la r\u00e9ponse \u00e0 la requ\u00eate. Le PEP peut prendre diff\u00e9rentes formes : un plugin de base de donn\u00e9es, un sidecar pour un service mesh, du code int\u00e9gr\u00e9 \u00e0 l’application, etc.<\/span><\/li>
  2. Le PEP transf\u00e8re la requ\u00eate au point de d\u00e9cision des politiques (Policy Decision Point – PDP). Le PDP est charg\u00e9 de prendre la d\u00e9cision d\u2019autorisation. Le PEP peut \u00e9galement fournir des informations suppl\u00e9mentaires pertinentes qui n\u2019\u00e9taient pas incluses dans la requ\u00eate initiale. Ces informations suppl\u00e9mentaires peuvent \u00eatre sp\u00e9cifiques \u00e0 l\u2019application ou provenir du contexte dans lequel la requ\u00eate a \u00e9t\u00e9 effectu\u00e9e.<\/span>
    <\/span>Le PDP est un composant qui peut facilement \u00eatre centralis\u00e9 et potentiellement d\u00e9ploy\u00e9 en infonuagique. Une strat\u00e9gie de d\u00e9ploiement valide consiste \u00e0 avoir plusieurs PEP d\u00e9ploy\u00e9s dans des applications m\u00e9tiers sur site. Tous ces PEP peuvent ensuite se connecter \u00e0 un seul PDP d\u00e9ploy\u00e9 en infonuagique.<\/span><\/li>
  3. Le PDP peut s’appuyer sur des sources de donn\u00e9es suppl\u00e9mentaires pour prendre une d\u00e9cision d\u2019autorisation. Ceci est n\u00e9cessaire lorsque le PDP ne dispose pas de suffisamment d\u2019informations avec la seule requ\u00eate d\u2019autorisation ou des informations suppl\u00e9mentaires fournies par le PEP. Lorsque le PDP a besoin d’informations suppl\u00e9mentaires, il peut interroger un ou plusieurs points d’information de politiques (Policy Information Point – PIP). Un PIP est un composant qui se connecte \u00e0 diverses sources de donn\u00e9es (bases de donn\u00e9es, LDAP, etc.) afin de fournir des informations au PDP pour qu\u2019il puisse prendre une d\u00e9cision d\u2019autorisation. Les informations fournies par un PIP peuvent \u00eatre relatives au sujet effectuant la requ\u00eate ou \u00e0 l’objet auquel le sujet souhaite acc\u00e9der.<\/span><\/li>
  4. Une fois que le PDP dispose de toutes les informations n\u00e9cessaires, il \u00e9value les politiques pertinentes afin de prendre une d\u00e9cision d\u2019autorisation.<\/span><\/li>
  5. Le PDP retourne ensuite la d\u00e9cision d\u2019autorisation au PEP, qui est charg\u00e9 d’appliquer cette d\u00e9cision.\u00a0<\/span><\/li>
  6. Le PEP applique la d\u00e9cision d\u2019autorisation. Cette \u00e9tape d\u00e9pend de l\u2019impl\u00e9mentation et de l’objet auquel le sujet tente d’acc\u00e9der. Par exemple, si un sujet souhaite effectuer une requ\u00eate GET sur une API, le PEP peut autoriser ou refuser la requ\u00eate. Si un sujet souhaite ex\u00e9cuter une requ\u00eate SQL SELECT sur une base de donn\u00e9es, le PEP peut filtrer les lignes et colonnes auxquelles le sujet a acc\u00e8s.<\/span><\/li>
  7. Si l’acc\u00e8s est accord\u00e9 au sujet, le PEP retourne l’objet demand\u00e9.<\/span><\/span><\/li><\/ol>

    En parall\u00e8le \u00e0 la requ\u00eate effectu\u00e9e par les sujets sur les objets, des t\u00e2ches administratives sont \u00e9galement effectu\u00e9es dans le syst\u00e8me.<\/p>

    1. Un administrateur utilise le point d\u2019administration des politiques (Policy Administration Point – PAP) pour g\u00e9rer les diff\u00e9rentes politiques du syst\u00e8me. Comme le PDP, le PAP est un composant qui peut facilement \u00eatre centralis\u00e9.<\/li>
    2. Le PAP, le PDP et les politiques g\u00e9r\u00e9es et lues par ces deux composants peuvent \u00eatre d\u00e9ploy\u00e9s en un lieu centralis\u00e9.
      Le PAP met \u00e0 jour les politiques qui sont lues par le PDP lors de son processus d’\u00e9valuation des politiques.<\/li><\/ol>

      Politiques de contr\u00f4le d’acc\u00e8s ABAC et meilleures pratiques<\/span><\/strong><\/h2>

      Format des politiques<\/span><\/h3>

      Les politiques dans le mod\u00e8le ABAC suivent le format suivant :<\/p>

      \"\"<\/span><\/h3>

      \u00a0<\/h2>

      Qui<\/b><\/p>

      Le sujet effectuant la requ\u00eate. Le sujet peut repr\u00e9senter un compte utilisateur, un employ\u00e9, un client, un syst\u00e8me non humain, etc.<\/span><\/p>

      Quoi<\/b><\/p>

      L’objet ou la ressource \u00e0 laquelle on acc\u00e8de. Une ressource peut \u00eatre une API, une colonne dans une base de donn\u00e9es, un microservice, etc. La partie “quoi” d’une politique d\u00e9crit \u00e9galement les actions qui peuvent \u00eatre effectu\u00e9es sur l’objet. Par exemple, la partie “quoi” de la politique peut sp\u00e9cifier qu’un sujet donn\u00e9 peut effectuer un GET sur une API pour r\u00e9cup\u00e9rer un document, mais ne peut pas effectuer un POST sur cette m\u00eame API pour ce m\u00eame document.<\/span><\/p>

      Quand
      <\/b><\/p>

      Le contexte dans lequel la demande peut \u00eatre effectu\u00e9e. Les facteurs contextuels peuvent inclure l’heure et la date de la demande, la g\u00e9olocalisation d’o\u00f9 provient la requ\u00eate, ou toute autre information contextuelle que le PEP peut fournir au PDP lors de la demande d’\u00e9valuation de la politique.<\/span><\/p>

      Meilleures pratiques pour la cr\u00e9ation de politiques<\/span><\/h3>

      Voici une vue d\u2019ensemble du processus de cr\u00e9ation d’une politique ABAC suit ces \u00e9tapes :<\/span><\/p>

      1. D\u00e9finir les actifs et les ressources \u00e0 prot\u00e9ger. Dans le mod\u00e8le ABAC, il s’agit des objets \u00e0 prot\u00e9ger et ils repr\u00e9sentent le <\/span>quoi<\/span><\/i> des politiques en cours de conception. Il est recommand\u00e9 de commencer par d\u00e9finir les objets plut\u00f4t que les sujets. Commencer en d\u00e9finissant les sujets peut entra\u00eener des d\u00e9finitions de sujets non pertinents ou qui se chevauchent.<\/span><\/li>
      2. Identifier les divers attributs d\u2019objets qui sont pertinents lors de la prise d’une d\u00e9cision d’autorisation. Il est \u00e9galement important d’identifier la source de ces attributs. La source pourrait \u00eatre dans la demande elle-m\u00eame, provenir d’un PEP, ou l’attribut pourrait \u00eatre stock\u00e9 dans un PIP.<\/span><\/li>
      3. Identifier les actions et les cas d’utilisation des diff\u00e9rents objets. Ceci inclut la conception et la mise en \u0153uvre de l’autorisation en se concentrant sur le parcours utilisateur, en tenant compte de l’infrastructure d’authentification et des d\u00e9pendances de donn\u00e9es inh\u00e9rentes \u00e0 l’\u00e9cosyst\u00e8me de s\u00e9curit\u00e9 prot\u00e9geant l’acc\u00e8s aux objets.<\/span><\/li>
      4. Une fois les actions sur les objets et les cas d’utilisation d\u00e9finis, d\u00e9terminer quels sujets devraient pouvoir les effectuer.<\/span><\/li>
      5. Identifier les attributs de sujets qui peuvent \u00eatre utilis\u00e9s pour les identifier correctement. Comme pour les attributs des objets, il est \u00e9galement important de d\u00e9terminer la source des attributs des sujets (la demande, des informations suppl\u00e9mentaires du PEP ou du PIP).<\/span><\/li>
      6. Identifier tout attribut contextuel suppl\u00e9mentaire qui devrait \u00eatre pris en compte lorsqu’un sujet effectue une action sur un objet. Des exemples d’informations contextuelles suppl\u00e9mentaires peuvent inclure : seulement pendant les heures d’ouverture, seulement en Am\u00e9rique du Nord, etc.<\/span><\/li>
      7. Apr\u00e8s avoir rassembl\u00e9 toutes les donn\u00e9es n\u00e9cessaires, il est possible de concevoir des politiques ABAC appropri\u00e9es. Pour ce faire, il faut identifier les points de contr\u00f4le entre les utilisateurs et les ressources o\u00f9 les donn\u00e9es de contexte et d’attributs se croisent avec suffisamment d’informations pour prendre des d\u00e9cisions d’autorisation efficaces.<\/span><\/li><\/ol>

        Principes de conception des politiques<\/span><\/h3>

        Voici quelques principes \u00e0 prendre en consid\u00e9ration lors de l’\u00e9laboration des politiques. Tous ces principes ne sont pas applicables \u00e0 tous les contextes, mais il est bon de les garder \u00e0 l’esprit.<\/span><\/p>