ObjectOS
KonfigurierenBerechtigungen

Berechtigungen

Identität, Rollen, Berechtigungssätze, Datensatzzugriff und Feldsicherheit — das gesamte Zugriffsmodell auf einer Seite.

Berechtigungen

ObjectOS verfügt über ein mehrschichtiges Zugriffsmodell, das aus dem Vorgehen übernommen wurde, das sich in Unternehmenssoftware seit zwei Jahrzehnten bewährt hat: Identität → Rollen → Berechtigungssätze → Datensatzzugriff → Feldsicherheit. Jede Schicht beantwortet eine andere Frage, und Sie können diejenigen ignorieren, die Sie nicht benötigen.

Das Modell in einem Diagramm

Authentication       Who is the caller?

Identity             Which user/org/membership is active?

Roles                Where do they sit in the hierarchy?

Permission sets      What CAN they do — apps, objects, fields, system?

Record access        WHICH records can they touch?

Field security       For those records, which FIELDS are readable / writable?

Jede Schicht wird vom Security-Plugin durchgesetzt. Für einfache Apps können Sie ausschließlich Berechtigungssätze verwenden (keine Rollen, keine Freigaberegeln) und den Rest hinzufügen, sobald die Anforderung auftaucht.

Schicht 1 — Identität

Identitätsobjekte befinden sich in Ihrer Projektdatenbank. Die wichtigsten davon:

ObjektWas es repräsentiert
sys_userEine Person oder ein Dienstkonto, das sich authentifizieren kann
sys_organizationMandanten-/Workspace-Grenze (mandantenfähige Apps)
sys_memberDie Mitgliedschaft eines Benutzers in einer Organisation (Rolle pro Mitgliedschaft zugewiesen)
sys_department, sys_teamOptionale Organisationsstruktur für Freigaberegeln
sys_invitationAusstehende Einladung, die auf Annahme wartet
sys_sessionAktive authentifizierte Sitzung
sys_api_keyLanglebige programmatische Anmeldeinformationen, die an einen Benutzer gebunden sind

In einer mandantenfähigen Bereitstellung:

  • Benutzer sind auf die Projektdatenbank beschränkt.
  • Sitzungen sind auf den Projekt-Hostnamen beschränkt.
  • Prüfungen auf Zeilenebene verwenden die Organisation und die Berechtigungen des aktuellen Benutzers.
  • Control-Plane-Benutzer sind nicht automatisch Geschäftsbenutzer — sie müssen über Plattform-SSO oder explizite Bereitstellung zugeordnet werden.

Sie erstellen/verwalten diese zur Laufzeit über die Console (/_console/) oder seeden sie in objectstack.config.ts für neue Umgebungen.

Schicht 2 — Rollen

Rollen modellieren das Organigramm (CFO → Finance Manager → Analyst). Sie existieren in erster Linie, damit Freigaberegeln und Berichte Dinge ausdrücken können wie "der Vorgesetzte des Datensatzeigentümers". Verwenden Sie Rollen, wenn Sie hierarchischen Zugriff benötigen; verzichten Sie auf sie bei flachen Teams.

Siehe Roles.

Schicht 3 — Berechtigungssätze

Berechtigungssätze sind die primäre Methode, um Fähigkeiten zu gewähren. Sie werden Benutzern direkt oder über Rollen zugewiesen.

Was sie gewähren

TypBeispiele
AnwendungszugriffCRM öffnen, das Support-Portal öffnen
ObjektberechtigungenDatensätze eines Objekts erstellen / lesen / aktualisieren / löschen
FeldberechtigungenBestimmte Felder lesen oder aktualisieren
SystemberechtigungenAuf Console zugreifen, Berichte ausführen, Daten exportieren, Audit-Log anzeigen
IntegrationsberechtigungenAPI-Schlüssel verwenden, Webhooks konfigurieren, Admin-Aktionen ausführen

Flags für Objektberechtigungen

Dies sind die exakten Flag-Namen, die das Security-Plugin prüft:

FlagBedeutung
allowReadDatensätze lesen, die der Benutzer über den Datensatzzugriff sehen kann
allowCreateNeue Datensätze erstellen
allowEditDatensätze aktualisieren, die der Benutzer sehen kann
allowDeleteDatensätze löschen, die der Benutzer sehen kann
viewAllRecordsJeden Datensatz des Objekts lesen, unter Missachtung der Datensatzzugriffsregeln
modifyAllRecordsJeden Datensatz aktualisieren/löschen; impliziert viewAllRecords

viewAllRecords und modifyAllRecords sind mandantenweite Superuser-Berechtigungen für das jeweilige Objekt. Reservieren Sie sie für explizite administrative Berechtigungssätze und halten Sie sie aus jeder benutzerseitigen Rolle heraus.

Siehe Permission Sets.

Schicht 4 — Datensatzzugriff

Für Benutzer ohne viewAllRecords: Welche Zeilen können sie sehen?

Das Modell unterstützt:

  • Implizites Eigentum (Zeilen, die der Benutzer erstellt hat oder besitzt)
  • Freigaberegeln (deklarativ — "Team A sieht die Datensätze von Team A")
  • Explizite Freigaben (sys_record_share-Zeilen — einmalige Freigaben)
  • Organisationsbereich (das organization_id der Zeile stimmt mit der Organisation des Benutzers überein)

Siehe Record Access.

Schicht 5 — Feldsicherheit

Selbst wenn ein Benutzer einen Datensatz sehen kann, können einzelne Felder sein:

  • Ausgeblendet — das Feld wird aus API- und UI-Antworten entfernt.
  • Schreibgeschützt — das Feld wird zurückgegeben, aber beim Schreiben abgelehnt.

Feldsicherheit gilt pro Objekt + pro Berechtigungssatz. Typische Verwendung:

  • salary auf sys_user für alle außerhalb der Personalabteilung ausblenden.
  • external_account_id für Support-Mitarbeiter lesbar, aber nicht bearbeitbar machen.

Sie wird im selben Evaluator wie die Objektberechtigungen durchgesetzt, sodass sie einheitlich über REST, ObjectQL und Console hinweg gilt.

Wo Sie anfangen sollten

Wenn Sie etwas erstellen …Verwenden Sie
Ein internes Tool für ein einzelnes TeamNur Berechtigungssätze
Eine teamübergreifende App, in der Manager Berichte sehenRollen + Berechtigungssätze
Eine mandantenfähige SaaS-artige AppOrganisationsbereich + Berechtigungssätze
Eine regulierte App mit PIIFeldsicherheit obendrauf hinzufügen
Eine komplexe App im CRM-StilDer vollständige Stack

Diagnose & Audit

  • /_console/ zeigt die effektiven Berechtigungen eines beliebigen Benutzers, so wie sie ausgewertet werden.
  • Das Audit-Log (sys_audit_log) erfasst berechtigungsrelevante Änderungen — Gewährungen, Rollenzuweisungen, Bearbeitungen von Berechtigungssätzen.
  • Abgelehnte Anfragen protokollieren die fehlgeschlagene Regel (Objektberechtigung vs. Datensatzzugriff vs. Feldsicherheit), sodass der Support schnell die Frage "Warum kann ich das nicht sehen?" beantworten kann.

On this page