Was sind Zugriffskontrolllisten (ACL)?

Eine Zugriffskontrollliste ist eine Liste an einer Ressource, die benennt, welche Nutzer oder Rollen darauf zugreifen dürfen und was jeder tun darf. Alles hängt an dieser Zuordnung: Wo Rollensysteme Berechtigungen an Personen hängen, hängt eine ACL sie an das Objekt – jeder Datensatz mit eigener Gästeliste, jeder Eintrag (ein Access Control Entry, kurz ACE) ein Subjekt samt seinen Rechten. Sie ist eine der ältesten Sicherheitskonstruktionen der Informatik, und in Anwendungs-Backends ist sie das, was aus “nur Ada und die Redakteure dürfen dieses Dokument anfassen” ein Feld macht statt ein Feature.

Das Wichtigste in Kürze

Die Gästeliste eines Objekts

Dokument "Q3 roadmap" — ACL
┌─────────────────────┬───────┬───────────┐
│ Subjekt             │ Lesen │ Schreiben │
├─────────────────────┼───────┼───────────┤
│ user usr-8fk2 (Ada) │  ja   │    ja     │   ← Eigentümer
│ user usr-2mq7 (Bob) │  ja   │     —     │   ← einzeln gewährt
│ role editors        │  ja   │    ja     │   ← eine Rolle als ein Eintrag
│ public (alle)       │   —   │     —     │   ← Standard: geschlossen
└─────────────────────┴───────┴───────────┘

Als Daten, auf dem Datensatz selbst:
{ "title": "Q3 roadmap",
  "ACL": { "usr-8fk2": { "read": true, "write": true },
           "usr-2mq7": { "read": true },
           "role:editors": { "read": true, "write": true } } }

Diese Gästeliste im Anwendungscode schreiben:

// 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

Die drei Bedeutungen von “ACL”

Die meisten Erklärungen greifen sich stillschweigend eine heraus; der Begriff benennt tatsächlich drei Mechanismen:

Sie teilen die Form – eine Liste von Subjekt-Berechtigungs-Einträgen, die eine Ressource bewacht – und unterscheiden sich in allem anderen. Dieser Artikel behandelt die dritte Bedeutung: die Berechtigungslisten pro Datensatz in Anwendungs-Backends, die am wenigsten beschriebene und, für Produktentwickler, die meistgenutzte.

Wie eine Anfrage ausgewertet wird: das Zwei-Tore-Modell

Schichten sind die Art, wie reife Systeme grobe und feine Kontrolle versöhnen: Klassenberechtigungen legen die Richtlinie für die ganze Kategorie fest (“nur authentifizierte Nutzer; nur Moderatoren löschen”), und die ACL pro Objekt entscheidet über den einzelnen Datensatz. Eine Anfrage muss beide Tore passieren – das heißt, eine vergessene ACL kann nicht öffnen, was die Klassenregel geschlossen hat, und eine großzügige Klassenregel kann trotzdem kein gesperrtes Objekt preisgeben. Dieselbe Schichtenlogik taucht eine Ebene tiefer als zeilenbasierte Sicherheit auf, wenn die Datenbank das Zeilenprädikat selbst durchsetzt.

ACL vs. RBAC vs. ABAC

Die ehrliche Antwort heißt Komposition, nicht Konkurrenz: Rollen regeln Zugriff, der der Funktion folgt; ACLs regeln die Entscheidungen pro Objekt, die Rollen nicht ausdrücken können (“dieser Entwurf, diese beiden Prüfer”); Attributregeln springen ein, wenn der Kontext zählt (Zeit, Tenant, Zustand). Das praktische Scharnier zwischen den ersten beiden ist der Rollen-ACE – eine ACL-Zeile, deren Subjekt eine Rolle ist –, der die Kontrolle auf Objektebene behält und den Wechsel der Mitglieder an das Rollensystem delegiert.

Das Skalierungsproblem – und die Leiter der Gegenmaßnahmen

Naive ACLs pro Objekt wachsen mit N Objekte × M Subjekte: Eine Million Dokumente, die jeweils einzelne Nutzer aufführen, bedeutet, dass jede Einstellung, jeder Austritt und jede Umstrukturierung Listen ändert, die über den gesamten Datenbestand verstreut sind – das “schwer zu verwalten” aus jedem Lehrbuch, konkret geworden. Die Leiter der Gegenmaßnahmen, in der Reihenfolge, in der man sie erklimmt: Rolleneinträge (ein ACE deckt eine sich ändernde Personengruppe ab; die Mitgliedschaft wird an einer Stelle gepflegt); Standard-ACLs (jedes neue Objekt kommt mit Lese- und Schreibrecht für den Eigentümer und den richtigen Rolleneinträgen zur Welt – das Anwendungs-Pendant zu POSIX-Standard-ACLs auf Verzeichnissen); Klassenregeln für den Normalfall, wodurch Listen pro Objekt nur noch Ausnahmen abdecken; und, bei beziehungslastiger Größenordnung, graphbasierte Autorisierung (ReBAC), die Zugriff aus Beziehungen ableitet, statt überhaupt Listen zu speichern. Systeme, die diese Sprossen überspringen, geben ACLs nicht auf – sie ertrinken darin.

Durchsetzung: serverseitig oder gar nicht

Eine im Client durchgesetzte ACL ist ein Vorschlag. Buttons auszublenden, Listen in JavaScript zu filtern oder darauf zu vertrauen, dass die App nur erlaubte IDs sendet, scheitert immer gleich: Der Angreifer verändert die Anfrage, nicht die Oberfläche – aus /documents/41 wird /documents/42, und schon liest er den Datensatz eines anderen. Genau diese Fehlerklasse – Broken Object Level Authorization, der Spitzenreiter der API-Sicherheitsliste der OWASP – sollen ACLs pro Objekt schließen, und die OWASP-Leitlinie wird deutlich: Autorisierungsprüfungen laufen serverseitig, pro Anfrage, pro Objekt; Zugriff auf einen Typ von Objekt bedeutet niemals Zugriff auf jedes Objekt dieses Typs. Die Auswertung gehört in die Datenschicht, wo kein Client-Pfad sie umgehen kann.

Typische Anwendungsfälle

• Nutzergenerierte Inhalte – jeder Beitrag, jede Datei, jede Notiz gehört ihrem Ersteller und wird Datensatz für Datensatz geteilt.
• Zusammenarbeit an Dokumenten – Leser-/Bearbeiterlisten pro Dokument; der Teilen-Dialog ist ein ACL-Editor im UX-Gewand.
• Datensätze mit mehreren Nutzern und Ausnahmen – der HR-Fall: Die betroffene Person liest ihre Akte, ihre Führungskraft schreibt sie, die Rolle der Prüfer liest alles.
• Abgrenzung nach Tenant und Team – Rolleneinträge pro Team auf gemeinsamen Klassen, mit Freigaben pro Objekt für teamübergreifende Ausnahmen.
• Standardmäßig private Apps – Messaging, Gesundheit, Finanzen: Jedes Objekt ist bei der Erstellung geschlossen und öffnet sich nur durch explizite Einträge.

ACLs oder Rollen? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Wildwuchs ist der Normalverlauf. Ohne Rolleneinträge und Standardwerte werden Listen pro Objekt zu unprüfbarem Konfetti; die Leiter der Gegenmaßnahmen ist ab einer gewissen Größe nicht optional.
• “Worauf hat dieser Nutzer Zugriff?” ist die teure Abfrage. ACLs optimieren die Prüfung pro Objekt; die Bestandsaufnahme pro Subjekt verlangt einen vollen Durchlauf oder Sekundärindizes.
• Falsche Standardwerte sind stille Datenlecks. Ein öffentlich lesbar angelegtes Objekt bleibt öffentlich, bis es jemandem auffällt; Standard-ACLs verdienen dieselbe Prüfung wie Code.
• Die Performance hängt an der Prüfung. Jeder Lesezugriff filtert nach der ACL; die Auswertung muss indiziert und in der Datenschicht durchgesetzt werden, nicht Endpoint für Endpoint angeflanscht.
• ACLs autorisieren; sie authentifizieren nicht. Die Liste taugt nur so viel wie die Identität, die ihr vorgelegt wird – Sessions und Tokens sind die vorgelagerte Abhängigkeit.

ACLs mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die ACL ist hier ein Feld erster Klasse: Jedes Objekt trägt eine, die Code-Tabs oben sind die vollständige API – Standardrechte des Eigentümers, Freigaben pro Nutzer, Rolleneinträge, öffentliche Flags – und Back4app setzt sie bei jeder REST-, GraphQL- und Live-Query-Anfrage durch, sodass Echtzeit-Abonnements dieselben Gästelisten respektieren wie Abfragen. Das Zwei-Tore-Modell kommt unverändert mit: Klassenberechtigungen setzen die Richtlinie der Kategorie im Dashboard, ACLs pro Objekt verfeinern sie Datensatz für Datensatz, und eine Einstellung für die Standard-ACL macht neue Objekte von Geburt an privat und dem Eigentümer vorbehalten. Die Skalierungsleiter ist eingebaut – Rollen sind Objekte, die Sie wie jede andere Datenklasse verwalten –, sodass Ihnen die Entwurfsentscheidungen bleiben, nicht die Maschinerie der Durchsetzung.