Contrôle d’accès basé sur les politiques (PBAC) dans les systèmes de fichiers distribués

Par Emmanuel Forgues - 1er septembre 2025

Publié initialement le 1er septembre 2025.

Mis à jour le 25 avril 2026.

Migré vers StratoSentry le 3 mai 2026.

Chapô

Les systèmes de fichiers distribués (DFS) sont le socle du stockage massif utilisé par les clouds, les data‑lakes et les environnements hybrides. Alors que la volumétrie et la diversité des acteurs augmentent, les modèles classiques de contrôle d’accès (RBAC) montrent leurs limites : ils peinent à exprimer des exigences de conformité complexes, à gérer des contextes dynamiques ou à assurer une traçabilité fine. Le Policy‑Based Access Control (PBAC), s’appuyant sur des politiques déclaratives et un moteur d’évaluation centralisé, apparaît comme une réponse technique robuste. Cet article décortique le fonctionnement du PBAC dans les DFS, analyse ses bénéfices, expose ses contraintes opérationnelles et propose un cadre décisionnel pour les DSI, RSSI et responsables de la gouvernance des données.

1. Contexte : pourquoi les systèmes de fichiers distribués sont au cœur de l’entreprise moderne

Les DFS – Google File System (GFS) [1], Hadoop Distributed File System (HDFS) [2] ou Ceph [3] – offrent une scalabilité horizontale, une tolérance aux pannes et un accès concurrent à des pétaoctets de données. Ils sont aujourd’hui intégrés dans :

• les plateformes cloud publiques (ex. Amazon S3, Google Cloud Storage) ;
• les data‑lakes d’entreprise pour l’analytique big data ;
• les solutions de sauvegarde et d’archivage à long terme ;
• les environnements de conteneurs où le stockage persistant est partagé entre multiples services (Kubernetes + CSI).

Dans ces contextes, la sécurité des données ne se limite plus à la question « qui peut lire ? », mais englobe :

• la conformité aux exigences GDPR ou CCPA qui imposent un contrôle granulaire et un audit détaillé ;
• le partage inter‑organisationnel (partenaires, fournisseurs) avec des niveaux d’accès temporaires ;
• les scénarios « Zero Trust » où chaque requête doit être évaluée en fonction du contexte (heure, localisation, type de dispositif).

Le modèle d’autorisation traditionnel RBAC (Role‑Based Access Control) attribue des droits à des rôles statiques. Cette approche s'avère insuffisante pour exprimer des règles telles que : « un analyste peut lire les logs du mois précédent uniquement depuis le réseau interne pendant les heures ouvrées ». Le PBAC répond à ce besoin en séparant qui (identité) de quoi (ressource) et de quand/ où / comment (conditions), via des politiques déclaratives.

2. Principes du PBAC : définition, comparaison avec RBAC et ABAC

Le PBAC s’appuie souvent sur les concepts d’ABAC, mais se distingue par l’utilisation d’un moteur d’évaluation de politiques qui interprète un langage déclaratif (XACML [4], Rego/Open Policy Agent [5]) et renvoie une décision « Permit/Deny/NotApplicable ». Cette architecture permet :

• Séparation des responsabilités – les équipes sécurité rédigent les politiques, les développeurs intègrent le point d’appel du moteur ;
• Réutilisation – la même politique peut s’appliquer à plusieurs services (stockage, bases de données, API) ;
• Extensibilité – ajout de nouveaux attributs (géolocalisation, niveau de sensibilité) sans modifier le code applicatif.

3. Architecture typique d’un DFS et points d’injection du PBAC

+-------------------+          +--------------------+
|   Client / API    | <------> |  Front‑end Gateways |
+-------------------+          +----------+---------+
                                        |
                         +--------------v---------------+
                         |       Policy Engine (OPA)    |
                         +--------------+---------------+
                                        |
               +------------------------+-----------------------+
               |                        |                       |
   +-----------v-----------+  +---------v----------+  +---------v----------+
   | Metadata Service      |  | Object Storage Nodes|  | Authentication IdP |
   +-----------------------+  +--------------------+  +-------------------+

• Front‑end Gateways (ex. S3 API compatible, WebHDFS) reçoivent chaque requête d’accès.
• Avant de transmettre la demande au Metadata Service ou aux Object Storage Nodes, le gateway interroge le Policy Engine en lui transmettant :
• l’identité de l’appelant (extracted from JWT, Kerberos ticket) ;
• les attributs du sujet (role, department, clearance) ;
• la ressource cible (bucket, chemin, objet) et ses métadonnées (classification, propriétaire) ;
• le contexte d’exécution (IP source, heure, type de client).
• Le moteur renvoie Permit ou Deny, éventuellement avec des obligations (ex. journalisation supplémentaire).
• La décision est appliquée : le gateway autorise la lecture/écriture ou renvoie une erreur HTTP 403.

Ce point d’injection centralisé garantit que toutes les opérations – y compris celles initiées par des services internes (Spark, Flink) – sont soumises aux mêmes politiques.

4. Modélisation des politiques : langages et moteurs

4.1 Langage XACML

Le eXtensible Access Control Markup Language (OASIS XACML 3.0) définit un format XML pour les Policy Sets, Policies et Rules. Chaque règle associe une Target (qui, quoi) à une Condition (expression booléenne). Exemple simplifié :

<Rule Effect="Permit" RuleId="allowAnalystRead">
  <Target>
    <Subjects><SubjectMatch MatchId="string-equal"><AttributeValue>analyst</AttributeValue></SubjectMatch></Subjects>
    <Resources><ResourceMatch MatchId="uri-path-match"><AttributeValue>/logs/*</AttributeValue></ResourceMatch></Resources>
    <Actions><ActionMatch MatchId="string-equal"><AttributeValue>read</AttributeValue></ActionMatch></Actions>
  </Target>
  <Condition>
    <Apply FunctionId="and">
      <Apply FunctionId="time-in-range">
        <AttributeDesignator AttributeId="requestTime" DataType="time"/>
        <AttributeValue DataType="time">08:00:00</AttributeValue>
        <AttributeValue DataType="time">18:00:00</AttributeValue>
      </Apply>
      <Apply FunctionId="ip-in-subnet">
        <AttributeDesignator AttributeId="sourceIP" DataType="string"/>
        <AttributeValue>10.0.0.0/8</AttributeValue>
      </Apply>
    </Apply>
  </Condition>
</Rule>

4.2 Rego / Open Policy Agent (OPA)

Rego est un langage déclaratif basé sur des règles et des documents JSON d’entrée. Il est plus lisible que le XML et s’intègre facilement aux pipelines CI/CD. Exemple équivalent :

package storage.access

default allow = false

allow {
    input.subject.role == "analyst"
    startswith(input.resource.path, "/logs/")
    input.action == "read"
    time_in_range(input.request.time, "08:00", "18:00")
    net.cidr_contains("10.0.0.0/8", input.request.ip)
}

4.3 Moteurs d’évaluation

Dans un DFS multi‑cloud ou on‑premise, les organisations privilégient souvent OPA ou un serveur XACML dédié pour rester indépendantes du fournisseur.

5. Cas d’usage réalistes

5.1 Stockage multi‑tenant dans le cloud privé

Une société de services financiers héberge plusieurs filiales sur un cluster Ceph. Chaque filiale possède son bucket : finance-us, finance-eu. Les exigences :

• Isolation stricte – aucun accès transversal ;
• Accès temporaire à des consultants externes pendant 30 jours, limité aux dossiers de projet ;
• Journalisation renforcée pour les accès aux données sensibles (PII).

L'association d'OPA et du Ceph Object Gateway (RGW) permet l'application de la politique suivante :

allow {
    input.subject.tenant == input.resource.bucket
}
allow {
    input.subject.role == "consultant"
    input.action == "read"
    startswith(input.resource.path, "/projects/")
    time.before(input.request.time, now_plus_days(30))
}

Les logs d’audit de RGW incluent la décision OPA (Permit/Deny) et les obligations (ex. log_level = "high"), conformément aux exigences du NIST SP<0xE2><0x80><0xAF>800‑53 AC‑2 et AC‑6.

5.2 Partage inter‑organisationnel pour la recherche médicale

Un consortium de laboratoires utilise HDFS via Hadoop Ranger (module PBAC). Les chercheurs doivent pouvoir :

• Lire les jeux de données génomiques classés Confidentialité = H uniquement depuis le réseau du laboratoire et pendant les heures ouvrées ;
• Écrire des résultats dérivés dans un répertoire dédié, mais sans possibilité de supprimer les originaux.

Ranger stocke les politiques sous forme JSON compatibles avec Apache Sentry. Exemple (extrait) :

{
  "policy": {
    "resource": "/genomics/*",
    "accesses": ["read"],
    "users": ["researcher_*"],
    "conditions": {
      "timeOfDay": {"start":"08:00","end":"18:00"},
      "sourceNetwork": "10.1.0.0/16"
    }
  }
}

Cette approche assure la conformité au RGPD (article<0xE2><0x80><0xAF>32 – sécurité du traitement) et permet une collaboration fluide.

5.3 Application Zero Trust pour les micro‑services

Dans un environnement Kubernetes, chaque pod accède à un volume persistant via le CSI driver d’OpenStack Swift. Le contrôle d’accès est externalisé vers OPA exécuté comme sidecar : chaque requête S3 inclut le JWT du service (identité mTLS). La politique vérifie :

• L’étiquette env=prod du pod ;
• Le label team=analytics pour autoriser l’écriture dans le bucket analytics-prod.

allow {
    input.subject.team == "analytics"
    input.resource.bucket == "analytics-prod"
    input.action == "write"
    input.pod.labels.env == "prod"
}

Le résultat : même si un pod compromis possède les credentials d’accès au bucket, l'écriture reste impossible tant que le label env n'est pas prod, ce qui limite l'impact d'une compromission interne.

6. Implémentations réelles et retours d’expérience

Retour d’expérience – Cas Ceph + OPA

Une grande entreprise de médias a migré son archivage vidéo vers un cluster Ceph en 2022. Avant l’implémentation PBAC, les droits étaient gérés par des listes ACL Unix, source fréquente d’erreurs humaines (accès non intentionnels à du contenu premium). Après le déploiement d’Opa :

• Réduction de 78 % des incidents d’accès non autorisé détectés pendant la première année ;
• Temps moyen de mise à jour d’une politique passé de plusieurs heures (édition manuelle) à quelques minutes via CI/CD (pipeline GitOps) ;
• Impact sur le débit mesuré < 3 % grâce au cache OPA intégré dans chaque gateway.

Ces chiffres proviennent du rapport interne publié par l’équipe SRE, accessible sous NDA<0xE2><0x80><0xAF>[6].

7. Bénéfices attendus d’un PBAC bien implémenté

8. Limites, risques et points de vigilance

8.1 Performance

Le moteur d’évaluation ajoute une latence à chaque appel d’accès. Dans des environnements à latence ultra‑basse (ex. trading haute fréquence), même quelques millisecondes sont inacceptables. Solutions : cache côté gateway, pré‑évaluation de politiques statiques, utilisation de PDP “edge” déployés localement.

8.2 Complexité de gestion des politiques

Des règles imbriquées et un grand nombre d’attributs peuvent conduire à l’effet « policy sprawl » – difficulté à comprendre l’impact global. Bonnes pratiques :

• structurer les policies en Policy Sets hiérarchiques ;
• appliquer le principe du least privilege dès la conception ;
• automatiser la validation (linting, tests unitaires Rego)

Retour au blog