Was sind Klassenberechtigungen (CLP)?

Eine Klassenberechtigung ist eine Regel im Klassenschema, die steuert, welche Nutzer oder Rollen jede Operation dieser Klasse überhaupt ausführen dürfen. Sie ist das äußerste Tor der Sicherheit in der Datenschicht: Bevor irgendeine Prüfung pro Zeile stattfindet, entscheidet die Klasse selbst, ob dieser Aufrufer hier suchen, anlegen, ändern oder löschen darf – eine Regel, die ganze Tabelle, zuerst geprüft.

Das Wichtigste in Kürze

Das Klassentor, deklariert und erlebt

Eine CLP ist Schemakonfiguration – hier als REST-Payload, das eine Klasse Config auf öffentliches Lesen und serverseitiges Schreiben festlegt:

PUT /schemas/Config
{
  "classLevelPermissions": {
    "find":   { "*": true },              // jeder darf abfragen
    "get":    { "*": true },
    "create": {},                         // niemand von der Client-Seite
    "update": { "role:admin": true },     // nur Admins
    "delete": {},
    "addField": {}                        // Schema eingefroren
  }
}

Was Clients erleben, ist das Tor bei der Arbeit – Lesezugriffe laufen durch, Schreibzugriffe sterben an der Klassengrenze, bevor auch nur ein Datum angefasst wird:

// JavaScript / Node.js — Back4app JS SDK
// The class gate in action: Config is read-only for clients (CLP),
// so reads succeed and writes never reach the data
const config = await new Parse.Query('Config').first(); // ✓ public read

const c = new Parse.Object('Config');
c.set('flag', true);
try {
  await c.save(); // ✗ CLP blocks client writes to this class entirely
} catch (e) {
  console.log(e.code); // 119: operation forbidden by class-level permissions
}

// Flutter / Dart — Back4app Flutter SDK
// The class gate in action: reads allowed, client writes blocked by CLP
final config = ParseObject('Config')..set('flag', true);
final response = await config.save();
if (!response.success) {
  print(response.error?.code); // 119: forbidden by class-level permissions
}

// iOS / Swift — Back4app Swift SDK
// The class gate in action: reads allowed, client writes blocked by CLP
var config = Config()
config.flag = true
config.save { result in
  if case .failure(let error) = result {
    print(error) // operation forbidden by class-level permissions
  }
}

// Android / Kotlin — Back4app Android SDK
// The class gate in action: reads allowed, client writes blocked by CLP
val config = ParseObject("Config").apply { put("flag", true) }
config.saveInBackground { e ->
  if (e != null) {
    Log.d("CLP", "blocked: ${e.code}") // forbidden by class-level permissions
  }
}

Wie Klassenberechtigungen und ACLs zusammenwirken

Die Granularitätsleiter: CLP vs. ACL vs. Pointer Permissions vs. geschützte Felder

Daraus folgt die Entwurfsregel: grobe Linien im Schema, feines Korn in den Zeilen. Klassen mit einheitlicher Zugriffsregel (Konfiguration, Kataloge, Logs) brauchen nur das Klassentor; Klassen mit Daten pro Nutzer ergänzen darunter ACLs oder Pointer Permissions.

Dasselbe Tor in anderen Engines

-- PostgreSQL: Tabellenprivilegien sind CLPs unter anderem Namen
GRANT SELECT ON films TO PUBLIC;
GRANT INSERT, UPDATE ON films TO role_editor;
REVOKE ALL ON launch_codes FROM PUBLIC;

Dokumentdatenbanken bilden es mit Rollen ab, die auf Aktionen einer Collection beschränkt sind – eine Rolle mit find und insert auf genau einer Collection. Das Konzept ist universell; was sich unterscheidet, ist die Ergonomie: SQL-GRANTs und Rollendokumente werden im Code verwaltet, während BaaS-Plattformen dieselbe Matrix als Schalter im Dashboard anbieten.

Empfohlene Einstellungen nach Inhaltstyp

Diese Tabelle ist die Checkliste, die die meisten Markteinführungen tatsächlich brauchen – beachten Sie die Konstante in der letzten Spalte und ihre Schwesterregel: clientseitige Klassenerstellung in Produktion aus, damit sich das Schema nur absichtlich ändert.

Typische Anwendungsfälle

• Produktionsschemas einfrieren. Add field überall aus; Klassen tauchen nicht mehr durch Client-Verkehr auf und verändern sich nicht mehr dadurch.
• Referenzdaten nur zum Lesen. Kataloge und Einstellungen öffentlich lesbar, beschreibbar nur durch Servercode – das Config-Muster von oben.
• Postfächer nur zum Schreiben. Klassen für Feedback und Telemetrie, in die Clients anlegen, aber niemals lesen dürfen – das umgekehrte Tor, das Code in der Anwendungsschicht gern vergisst.
• Adminbereiche nach Rollenstufen. Update und delete einer Admin-Rolle vorbehalten, während die App frei liest.
• Abwehr des klassischen Datenabzugs. Der berüchtigte Einzeiler – ein curl mit einer App-ID gegen eine offene User-Klasse – stirbt am find-Tor, sobald die Klasse Authentifizierung verlangt.

Klassentor oder Servercode? Eine Entscheidungsmatrix

Beides ergänzt sich: Das gehärtete Muster für wirklich sensible Klassen sperrt die CLPs vollständig und stellt serverseitige Funktionen als einzige Tür bereit – das Klassentor garantiert, dass niemand um den Engpass herumläuft.

Grenzen und Trade-offs

• Klassengranularität ist per Definition grob. Alles pro Zeile gehört zu ACLs und Pointer Permissions; alles Bedingte gehört in serverseitige Validierung – CLPs kontrollieren, sie schlussfolgern nicht.
• Die Standardwerte sind für die Entwicklung großzügig. Neue Klassen kommen offen zur Welt, damit Prototypen schnell entstehen; der Durchgang vor dem Start, der die obige Tabelle umsetzt, ist Disziplin, kein Automatismus.
• Der Master Key ignoriert alles. Jedes Tor in diesem Artikel ist wirkungslos, wo dieser Schlüssel hinkommt – deshalb lebt er ausschließlich serverseitig, wird pro Operation eingesetzt und niemals ausgeliefert.
• Die Durchsetzungsfläche muss vollständig sein. Echtzeit-Abonnements und Spezial-Endpoints hatten in der Vergangenheit Lücken in der Durchsetzung – halten Sie die Plattform aktuell und testen Sie die Tore von einem echten Client aus, nicht nur aus dem Dashboard.
• Auch Schalter brauchen eine Durchsicht. Deklarative Sicherheit ist nur dann prüfbare Sicherheit, wenn jemand sie prüft – die Einstellungsmatrix gehört in Ihre Startcheckliste, nicht in mündlich überliefertes Wissen.

Klassenberechtigungen 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. Klassenberechtigungen sind die sichtbar gemachte Oberfläche ihrer Schema-Sicherheit: Jede Klasse im Dashboard trägt die Operationsmatrix als Häkchen – öffentlich, requiresAuthentication, pro Rolle – dazu Pointer Permissions und geschützte Felder, serverseitig bei jeder Anfrage durchgesetzt, über SDKs, REST und GraphQL gleichermaßen. Darunter sitzen die ACLs pro Objekt, darüber Cloud-Code-Trigger für die Regeln, die Logik brauchen. Die Sicherheitsrichtlinien führen durch den vollständigen Durchgang vor dem Start – die Einstellungsmatrix aus diesem Artikel, Klick für Klick angewendet.