Qu'est-ce qu'une liste de contrôle d'accès (ACL) ?

Une liste de contrôle d’accès est une liste attachée à une ressource qui nomme les utilisateurs ou rôles pouvant y accéder et ce que chacun a le droit de faire. Tout tient dans le rattachement : là où les systèmes de rôles accrochent les permissions aux personnes, une ACL les accroche à l’objet — chaque enregistrement a sa propre liste d’invités, chaque entrée (une entrée de contrôle d’accès, ou ACE) associe un sujet à ses droits. C’est l’une des plus anciennes constructions de sécurité de l’informatique, et dans les backends applicatifs, c’est ce qui transforme “seuls Ada et les éditeurs peuvent toucher ce document” en un champ plutôt qu’en une feature.

Points clés

La liste d’invités d’un objet

Document "Q3 roadmap" — ACL
┌────────────────────────┬─────────┬──────────┐
│ sujet                  │ lecture │ écriture │
├────────────────────────┼─────────┼──────────┤
│ user usr-8fk2 (Ada)    │   oui   │   oui    │   ← propriétaire
│ user usr-2mq7 (Bob)    │   oui   │    —     │   ← accordé individuellement
│ role editors           │   oui   │   oui    │   ← un rôle, une seule entrée
│ public (tout le monde) │    —    │    —     │   ← par défaut : fermé
└────────────────────────┴─────────┴──────────┘

Sous forme de données, sur l'enregistrement lui-même :
{ "title": "Q3 roadmap",
  "ACL": { "usr-8fk2": { "read": true, "write": true },
           "usr-2mq7": { "read": true },
           "role:editors": { "read": true, "write": true } } }

Écrire cette liste d’invités dans le code de l’application :

// JavaScript / Node.js — Back4app JS SDK
// A per-object ACL: this document's own guest list
const doc = new Parse.Object('Document');
doc.set('title', 'Q3 roadmap');

const acl = new Parse.ACL(currentUser);   // owner: read + write
acl.setReadAccess(reviewerId, true);      // one user: read only
acl.setRoleWriteAccess('editors', true);  // a role as an entry
acl.setPublicReadAccess(false);           // everyone else: nothing
doc.setACL(acl);

await doc.save(); // enforced server-side on every future request

// Flutter / Dart — Back4app Flutter SDK
// A per-object ACL: this document's own guest list
final doc = ParseObject('Document')..set('title', 'Q3 roadmap');

final acl = ParseACL(owner: currentUser);              // owner: read + write
acl.setReadAccess(userId: reviewerId, allowed: true);  // one user: read only
acl.setRoleWriteAccess('editors', true);               // a role as an entry
acl.setPublicReadAccess(allowed: false);               // everyone else: nothing
doc.setACL(acl);

await doc.save(); // enforced server-side on every future request

// iOS / Swift — Back4app Swift SDK
// A per-object ACL: this document's own guest list
var doc = Document()
doc.title = "Q3 roadmap"

var acl = ParseACL()
acl.setReadAccess(user: currentUser, value: true)    // owner: read…
acl.setWriteAccess(user: currentUser, value: true)   // …and write
acl.setReadAccess(objectId: reviewerId, value: true) // one user: read only
acl.setWriteAccess(roleName: "editors", value: true) // a role as an entry
acl.publicRead = false                               // everyone else: nothing
doc.ACL = acl

try await doc.save() // enforced server-side on every future request

// Android / Kotlin — Back4app Android SDK
// A per-object ACL: this document's own guest list
val doc = ParseObject("Document")
doc.put("title", "Q3 roadmap")

val acl = ParseACL(ParseUser.getCurrentUser()) // owner: read + write
acl.setReadAccess(reviewerId, true)            // one user: read only
acl.setRoleWriteAccess("editors", true)        // a role as an entry
acl.publicReadAccess = false                   // everyone else: nothing
doc.acl = acl

doc.save() // enforced server-side on every future request

Les trois sens de “ACL”

La plupart des explications en choisissent un sans le dire ; le terme désigne en réalité trois mécanismes :

Elles partagent la forme — une liste d’entrées sujet-permission qui garde une ressource — et diffèrent sur tout le reste. Cet article traite du troisième sens : les listes de permissions par enregistrement des backends applicatifs, le moins documenté et, pour les développeurs produit, le plus utilisé.

Comment une requête est évaluée : le modèle à deux portes

Les couches sont la manière dont les systèmes matures concilient contrôle grossier et contrôle fin : les permissions au niveau de la classe énoncent la politique de toute la catégorie (“utilisateurs authentifiés uniquement ; seuls les modérateurs suppriment”), et l’ACL par objet tranche pour chaque enregistrement. Une requête doit franchir les deux portes — autrement dit, une ACL oubliée ne peut pas ouvrir ce que la règle de classe a fermé, et une règle de classe généreuse ne peut pas non plus exposer un objet verrouillé. La même logique de couches se retrouve un niveau plus bas avec la sécurité au niveau des lignes, quand la base de données applique elle-même le prédicat de ligne.

ACL vs. RBAC vs. ABAC

La réponse honnête, c’est la composition, pas la concurrence : les rôles gèrent l’accès qui suit la fonction ; les ACL gèrent les décisions par objet que les rôles ne savent pas exprimer (“ce brouillon, ces deux relecteurs”) ; les règles d’attributs prennent le relais quand le contexte compte (heure, tenant, état). La charnière pratique entre les deux premiers est l’ACE de rôle — une ligne d’ACL dont le sujet est un rôle —, qui conserve le contrôle au niveau de l’objet tout en déléguant le va-et-vient des membres au système de rôles.

Le problème du passage à l’échelle — et les paliers d’atténuation

Des ACL par objet naïves croissent en N objets × M sujets : un million de documents listant chacun des utilisateurs individuels, et chaque embauche, départ ou réorganisation revient à modifier des listes dispersées dans tout le jeu de données — le “difficile à gérer” que citent tous les manuels, rendu concret. Les paliers d’atténuation, dans l’ordre où les gravir : les entrées de rôle (une seule ACE couvre une population qui évolue ; l’appartenance se met à jour en un seul endroit) ; les ACL par défaut (chaque nouvel objet naît avec lecture/écriture pour le propriétaire et les bonnes entrées de rôle — l’équivalent applicatif des ACL par défaut POSIX sur les répertoires) ; des règles au niveau de la classe pour le cas courant, en réservant les listes par objet aux exceptions ; et, à grande échelle et avec beaucoup de relations, l’autorisation fondée sur un graphe (ReBAC), qui déduit l’accès des relations au lieu de stocker des listes. Les systèmes qui sautent ces paliers n’abandonnent pas les ACL — ils s’y noient.

Application des règles : côté serveur ou pas du tout

Une ACL appliquée dans le client n’est qu’une suggestion. Masquer des boutons, filtrer des listes en JavaScript ou compter sur l’application pour n’envoyer que des ID autorisés échouent tous de la même façon : l’attaquant modifie la requête, pas l’interface — il remplace /documents/41 par /documents/42 et lit l’enregistrement de quelqu’un d’autre. Cette classe de faille — broken object-level authorization, en tête de la liste de sécurité des API de l’OWASP — est précisément ce que les ACL par objet existent pour fermer, et le guide de l’OWASP est sans détour : les contrôles d’autorisation s’exécutent côté serveur, à chaque requête, pour chaque objet ; avoir accès à un type d’objet n’implique jamais l’accès à tous les objets de ce type. L’évaluation a sa place dans la couche de données, là où aucun chemin client ne peut la contourner.

Cas d’usage courants

• Contenu généré par les utilisateurs — chaque publication, fichier ou note appartient à son créateur et se partage enregistrement par enregistrement.
• Collaboration documentaire — listes de lecteurs/éditeurs par document ; la boîte de dialogue de partage est un éditeur d’ACL habillé d’UX.
• Enregistrements multi-utilisateurs avec exceptions — le cas RH : la personne concernée lit sa fiche, son manager la modifie, le rôle des auditeurs lit tout.
• Cloisonnement par tenant et par équipe — des entrées de rôle par équipe sur les classes partagées, avec des droits par objet pour les exceptions inter-équipes.
• Applications privées par défaut — messagerie, santé, finance : chaque objet est fermé à sa création et ne s’ouvre que par des entrées explicites.

Devriez-vous utiliser des ACL ou des rôles ? Matrice de décision

Limites et trade-offs

• La prolifération est la trajectoire par défaut. Sans entrées de rôle ni valeurs par défaut, les listes par objet deviennent des confettis impossibles à auditer ; les paliers d’atténuation ne sont pas optionnels à grande échelle.
• “À quoi cet utilisateur a-t-il accès ?” est la requête coûteuse. Les ACL optimisent l’audit par objet ; l’inventaire par sujet exige de tout parcourir ou des index secondaires.
• De mauvaises valeurs par défaut sont des fuites silencieuses. Un objet créé en lecture publique reste public jusqu’à ce que quelqu’un s’en aperçoive ; les ACL par défaut méritent la même revue que le code.
• La performance dépend du contrôle. Chaque lecture filtre selon l’ACL ; l’évaluation doit être indexée et appliquée dans la couche de données, pas greffée endpoint par endpoint.
• Les ACL autorisent ; elles n’authentifient pas. La liste ne vaut que ce que vaut l’identité qu’on lui présente — les sessions et les tokens en sont la dépendance en amont.

Les ACL sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. L’ACL y est un champ de premier plan : chaque objet en porte une, les onglets de code ci-dessus constituent l’API complète — valeurs par défaut du propriétaire, droits par utilisateur, entrées de rôle, indicateurs publics — et Back4app l’applique à chaque requête REST, GraphQL et Live Query, si bien que les abonnements temps réel respectent les mêmes listes d’invités que les requêtes. Le modèle à deux portes est livré tel quel : les permissions au niveau de la classe fixent la politique de la catégorie dans le dashboard, les ACL par objet l’affinent enregistrement par enregistrement, et un réglage d’ACL par défaut rend les nouveaux objets privés, réservés à leur propriétaire, dès leur création. Les paliers de passage à l’échelle sont intégrés — les rôles sont des objets que vous gérez comme n’importe quelle autre donnée —, ce qui vous laisse les décisions de conception, et non la machinerie d’application des règles, comme part du travail.