--- title: "Rollen und Berechtigungen" description: "Wie Orbit rollenbasierte und bedingungsbasierte Zugriffskontrolle verbindet: managed Rollen, Custom Rollen, Berechtigungen und warum manche Nutzer durch die Einschränkung weniger Datensätze sehen." url: "https://support.pr-5.orbit.do/de/advanced-features/roles-and-permissions" locale: "de" apps: ["mission"] lastReviewed: "2026-10-26" --- # Rollen und Berechtigungen Wie Orbit rollenbasierte und bedingungsbasierte Zugriffskontrolle verbindet: managed Rollen, Custom Rollen, Berechtigungen und warum manche Nutzer durch die Einschränkung weniger Datensätze sehen. ## Überblick In Orbit ist eine gute Verwaltung der Nutzerzugriffe wichtig. Die Funktion „Rollen“ ist ein Kernstück des Systems: Mit ihr passen Sie die Zugriffskontrolle genau und flexibel an. Sie legen damit fest, wer in Orbit was tun darf, damit Ihr Betrieb reibungslos und sicher läuft. Rollen und Berechtigungen in Orbit sind auf größtmögliche Flexibilität und Kontrolle ausgelegt. Sie verbinden rollenbasierte Zugriffskontrolle (RBAC) mit den feineren Möglichkeiten der attributbasierten Zugriffskontrolle (ABAC). Im Bereich „Rollen“ der Einstellungen von Orbit MissionControl legen Nutzer die Zugriffskontrolle für die meisten Objekte im Orbit-System fest und passen sie an. **Das Wichtigste im Überblick** * **Managed Rollen**: Orbit bietet eine Reihe vorkonfigurierter Rollen für übliche betriebliche Anforderungen. Diese vordefinierten managed Rollen bilden eine Grundlage mit Standard-Zugriffsmustern für häufige Nutzertypen. Sie dienen als Ausgangspunkt und decken die grundlegenden Anforderungen des Betriebs ab. * **Custom Rollen**: Für besondere Anforderungen passen Sie mit Custom Rollen die Zugriffskontrolle an. Sie können diese Rollen von Grund auf neu anlegen oder auf bestehenden managed Rollen aufbauen und so genau festlegen, was ein Nutzer tun darf. * **Bedingungen**: Mit „Bedingungen“ in Berechtigungen steuern Sie den Zugriff genau. Passen Sie Berechtigungen an bestimmte Fälle an, zum Beispiel indem Sie Aktionen auf `Vehicle` nach Gewicht einschränken oder den Zugriff auf Webhooks vom Inhalt der URL abhängig machen. > **Warning:** **Wichtig**: Mit dieser Funktion kann jede Organisation Orbit an ihre eigenen Anforderungen anpassen. Die große Flexibilität hat aber eine Kehrseite: Eine falsche Konfiguration kann ungewollt Zugriffe sperren oder vertrauliche Informationen offenlegen. Gehen Sie bei Änderungen an diesen Einstellungen sehr vorsichtig vor. Prüfen Sie Ihre Änderungen gründlich und verstehen Sie ihre Auswirkungen, bevor Sie speichern. ## Wichtige Begriffe und Funktionen ### **Nutzer, Rollen und Berechtigungen** Um Zugriffe in Orbit richtig einzurichten und zu verwalten, müssen Sie Nutzer, Rollen und Berechtigungen unterscheiden. * **Nutzer**: Das sind Personen (Shipper, Operator und Carrier), die im Orbit-System arbeiten. Operator-Nutzer erhalten standardmäßig managed Administrator-Rollen. Diese geben ihnen umfassenden Lese- und Schreibzugriff in ganz Orbit. * **Rollen**: Rollen werden Nutzern zugewiesen und legen ihre Zugriffsstufe fest. Die managed Rolle „Operator Administrator“ gibt zum Beispiel weitreichenden Zugriff. Mit anderen Rollen passen Sie die Berechtigungen genauer an die Aufgaben eines Nutzers oder an seine Nutzergruppe (zum Beispiel Shipper) an. * **Berechtigungen**: Das sind bestimmte Aktionen, die Rollen auf Orbit-Entitäten ausführen dürfen oder nicht, etwa Daten anlegen, ansehen oder ändern. Jede Rolle umfasst eine Reihe von Berechtigungen. Diese legen fest, was der Nutzer mit dieser Rolle tun kann. ### **Rollen** #### **Managed Rollen** Managed Rollen stellt Orbit bereit. Es sind fest eingerichtete Rollen mit vordefinierten Berechtigungen für übliche betriebliche Anforderungen. Sie können nicht bearbeitet werden, damit das System stabil bleibt. Sie können aber als Ausgangspunkt für Custom Rollen dienen, die zu den Anforderungen Ihrer Organisation passen. Orbit pflegt die managed Rollen und aktualisiert sie automatisch, damit sie mit Systemupdates und neuen Funktionen zusammenpassen. Orbit stellt sieben managed Rollen für Nutzer bereit. Sie decken die häufigsten Anforderungen der drei Parteien ab: des Logistik-Operators, seiner Shipper und seiner Carrier. * **Operator Administrator**: voller Zugriff, um den Betrieb zu führen und Einstellungen, Nutzer und andere Operator zu verwalten. * **Operator Member**: Zugriff für das Tagesgeschäft, ohne die Möglichkeit, Einstellungen oder die Rollen anderer Operator zu ändern. * **Shipper Administrator**: verwaltet eine Shipper-Organisation und ihre Nutzer und sieht die eigenen Buchungen dieses Shippers. * **Shipper Member**: bucht und verfolgt Transporte für den eigenen Shipper, mit engerem Zugriff als der Administrator. * **Carrier Administrator**: verwaltet eine Carrier-Organisation, ihr Team, ihre Fahrer und ihre Fahrzeuge und bearbeitet die Touren, die diesem Carrier angeboten werden. Er darf Fahrer des eigenen Carriers anlegen sowie Fahrzeuge des Carriers anlegen und ändern; ein Fahrzeug stellt er auf inaktiv, löschen kann er es nicht. * **Carrier Member**: bearbeitet die zugewiesenen Touren und Angebote eines Carriers, einschließlich des eigenen Preises des Carriers. * **Driver**: die engste Rolle. Sie führt eine zugewiesene Tour aus (ihre Stopps (`Stop`), Ladungen (`Load`) und die Erfassung der Nachweise), ohne Angebote, Preise oder Kundendaten zu sehen. Außerdem stellt Orbit vier managed Rollen bereit, die nur für API-Keys gedacht sind: **Operator API Key Full Access**, **Operator API Key Read Only**, **Carrier API Key Full Access** und **Carrier API Key Read Only**. In den Rolleneinstellungen von Orbit MissionControl sind sie mit „Nur API-Keys“ markiert. Sie können keinem Nutzer zugewiesen werden, und keine Rollenauswahl für Nutzer bietet sie an. Ein Carrier-Key mit **Carrier API Key Full Access** kann die Fahrer und Fahrzeuge des eigenen Carriers anlegen und ändern, nie die eines anderen Carriers. Die Rolle eines Keys wählen Sie beim Erstellen und können sie später ändern, siehe [API-Keys](https://support.pr-5.orbit.do/de/advanced-features/api-keys). Ein Key kann auch eine Ihrer eigenen Rollen haben, wenn die Rolle für die Nutzerart des Keys gedacht ist und keine Bedingung enthält, die einen einzelnen Nutzer oder ein Team nennt. Die Orbit-API prüft jede Anfrage gegen die Rolle ihres Keys. **Operator API Key Full Access** hat alle Rechte des Operator Administrators, und jeder Key, der vor den Key-Rollen angelegt wurde, hat diese Rolle. **Operator API Key Read Only** liest dieselben Daten und erhält bei jeder Änderung den Status 403. #### **Custom Rollen** Custom Rollen bieten eine persönlich angepasste Zugriffskontrolle. Sie können sie von Grund auf neu anlegen oder auf bestehenden Rollen aufbauen. Um eine bestehende Rolle als Ausgangspunkt zu nutzen, klicken Sie sie in Orbit MissionControl mit der rechten Maustaste an und wählen **Als Vorlage verwenden**. Mit Custom Rollen bilden Sie in Orbit genau die Aufgaben und Zuständigkeiten Ihrer Organisation ab. Jede Rolle im Orbit-System, ob managed oder custom, enthält die folgenden Felder: * **Bezeichnung**: Ein eindeutiger, gut erkennbarer Name für Ihre Rolle. * **Beschreibung (optional)**: Eine kurze Erklärung, wofür die Rolle gedacht ist. Sie hilft beim Verständnis. * **Geeignete Nutzergruppe (optional)**: Gibt den passenden Nutzertyp für die Rolle an, zum Beispiel shipper-user, operator-user oder carrier-user. Das Feld kann leer bleiben oder mehrere Typen enthalten, wenn die Rolle für verschiedene Nutzer gedacht ist. Es hilft dem Administrator, Nutzern in Orbit MissionControl Rollen zuzuweisen. Außerdem grenzt es die Rollen ein, die für bestimmte Nutzertypen zur Wahl stehen. Wenn Sie zum Beispiel Carrier-Nutzer in die Anwendung Orbit Dispatch einladen, können Sie nur Rollen wählen, deren geeignete Nutzergruppe carrier-user enthält. Orbit prüft diese Empfehlung bei jeder neuen Zuweisung, auch über die API von Orbit: Eine Rolle, deren geeignete Nutzergruppe den Typ des Nutzers nicht enthält, kann diesem Nutzer nicht zugewiesen werden. Eine Rolle ohne geeignete Nutzergruppe können Sie über die API von Orbit weiterhin jedem Nutzer zuweisen. * **Status**: Zeigt den aktuellen Zustand der Rolle, entweder aktiv oder inaktiv. Ein inaktiver Status entzieht allen Nutzern mit dieser Rolle sämtliche Zugriffsrechte. #### Rollen bearbeiten und zuweisen Rollen lassen sich ändern, wenn sich die Anforderungen Ihrer Organisation ändern. Sie können Berechtigungen hinzufügen oder entfernen, Bedingungen anpassen oder die Angaben und den Aktivstatus der Rolle überarbeiten. Beachten Sie: Für diese Änderungen braucht Ihr Nutzer die nötigen Berechtigungen für die Entität „Role“. Orbit protokolliert alle Änderungen, und Sie können sie im Status-Log der Rolle nachsehen. Um einem Nutzer eine Rolle zuzuweisen, gehen Sie in Orbit MissionControl zu Einstellungen → Nutzer und wählen den Nutzer, den Sie ändern möchten. Wie bei den Rollen braucht Ihr Nutzer dafür Berechtigungen für die Entität „OperatorUser“. #### Berechtigungen Rollen steuern den Zugriff über Berechtigungen. Nutzer können einer Rolle beliebig viele Berechtigungen geben. Jede Berechtigung besteht aus: * **Befugnis:** Gibt an, ob die Rolle eine Aktion auf einer Entität ausführen darf („kann“) oder nicht darf („kann nicht“). Als bewährte Regel gilt: Direkte Logik ist leichter nachzuvollziehen, nutzen Sie also so oft wie möglich positive Regeln („kann“)! So bleiben die Berechtigungen sauber und lesbar, und das Risiko sinkt, den falschen Nutzern die falschen Berechtigungen zu geben. > **Geben Sie Berechtigungen, statt sie zu entziehen** * **Aktion**: Aktionen sind die Tätigkeiten, die eine Rolle ausführen darf: anlegen, betrachten, bearbeiten oder löschen. Eine Rolle mit der Befugnis „kann anlegen“ für `Vehicles` kann zum Beispiel in Orbit MissionControl neue `Vehicles` anlegen. * **Entität**: Das Ziel der Aktion (zum Beispiel `Vehicle`, `CarrierUser` (Fahrer, `Driver`), `Region`). Diese Liste wächst laufend, damit sich fast alle Objekte im Orbit-System in Rollen erfassen lassen. Die aktuelle Liste der Entitäten: * `APIKey` * `Callout` * `Carrier` * `CarrierUser` * `CarrierTeam` * `Insights` * `LoadType` * `OperatorTeam` * `OperatorUser` * `OperatorUserInvite` * `Order` * `PropertyDefinition` * `Region` * `Role` * `Shipment` * `Shipper` * `ShipperAddress` * `ShipperTeam` * `ShipperUser` * `ShipperUserInvite` * `Shop` * `ShopApp` * `ShopSignUpConfig` * `Tour` * `TourPrice` * `Vehicle` * `VehicleClass` * `Voucher` * `Webhook` * `WorkbenchSetting` * **Bedingung** (optional): Bedingungen machen Berechtigungen feiner. Mit ihnen legt eine Rolle fest, unter welchen Umständen eine Berechtigung gilt. Welche Bedingungen möglich sind, hängt von der Art der Entität ab. Eine Bedingung für eine Berechtigung auf `Vehicle` könnte zum Beispiel Aktionen auf `Vehicles` mit einer Nutzlast über 1000 kg beschränken. Eine Berechtigung auf Webhooks könnte dagegen prüfen, ob eine bestimmte Zeichenfolge in der URL des Endpunkts steht. ## Anwendungsbeispiel ### Fuhrparkleitung in Tokio * **Rollenname**: *Fleet Manager Tokyo* * **Berechtigung**: `can create Vehicle` * **Bedingung**: Kennzeichen beginnt mit ‚TKA‘ Mit dieser Konfiguration können Nutzer mit der Rolle „Fleet Manager Tokyo“ `Vehicles` anlegen, deren Kennzeichen mit den Buchstaben ‚TKA‘ beginnt. Alles andere auf der Plattform dürfen diese Nutzer weder tun noch sehen, weil jede Berechtigung ausdrücklich vergeben werden muss. ### Abgeschlossene Orders sperren Spaceport Shipping Co. übergibt jede abgeschlossene `Order` an sein Buchhaltungssystem. Ist eine Order erledigt, soll das Operations-Team in Lyon sie nicht mehr ändern; korrigieren sollen sie nur die Administratoren Julia und Max. Julia richtet für das Team eine Rolle ein: 1. **Rolle kopieren** Öffnen Sie in Orbit MissionControl **Einstellungen** → **Nutzerverwaltung** → **Rollen**, klicken Sie mit der rechten Maustaste auf **Operator Member** und wählen Sie **Als Vorlage verwenden**. Nennen Sie die neue Rolle *Operations Lyon*. 2. **Order sperren** Fahren Sie mit der Maus über die Zeile `Order` und wählen Sie **Bedingung hinzufügen**. Wählen Sie **kann nicht** und **bearbeiten**, setzen Sie die Bedingung auf Status **gleich** `Abgeschlossen` und speichern Sie. 3. **Löschen sperren** Fügen Sie in der Zeile `Order` eine zweite Bedingung hinzu: **kann nicht**, **löschen**, Status **gleich** `Abgeschlossen`. Gehen Sie in der Zeile `Tour` genauso vor: **kann nicht**, **löschen**, Status **gleich** `Abgeschlossen`. 4. **Rolle zuweisen** Weisen Sie *Operations Lyon* den Mitgliedern des Teams zu. Die Rolle behält alle Berechtigungen von **Operator Member** und erhält drei zusätzliche Regeln: | Entität | Regel | Bedingung | | ------- | ----------------------------- | --------------------------------- | | `Order` | **kann nicht** **bearbeiten** | Status **gleich** `Abgeschlossen` | | `Order` | **kann nicht** **löschen** | Status **gleich** `Abgeschlossen` | | `Tour` | **kann nicht** **löschen** | Status **gleich** `Abgeschlossen` | Welche Regeln Sie setzen, hängt davon ab, was nach dem Abschluss noch geändert werden darf. Im Beispiel sperrt Julia die Order und verbietet das Löschen abgeschlossener Orders und Touren; die Tour selbst bleibt bearbeitbar. Wer auch die Tour einfrieren will, fügt an der Zeile `Tour` dieselbe Regel mit **bearbeiten** hinzu. Dieses Beispiel nutzt Regeln mit **kann nicht**, obwohl positive Regeln die bessere Gewohnheit sind. Für einen Status bietet der Bedingungseditor nur **gleich** an, eine Regel mit **kann** kann also nicht „jeder Status außer `Abgeschlossen`“ ausdrücken. Eine Regel mit **kann nicht** und Bedingung kommt zur Berechtigung **bearbeiten** oder **löschen** der Rolle hinzu, statt sie zu ersetzen. So bearbeitet und löscht das Team Orders und Touren in jedem anderen Status weiter. Öffnet ein Nutzer mit dieser Rolle eine abgeschlossene `Order` in Orbit MissionControl, zeigt die Order-Seite **Nur Lesezugriff** mit dem Text „Diese Order ist abgeschlossen und für Ihre Rolle gesperrt.“ Ist eine Buchhaltungsintegration aktiv, folgt „Korrekturen erfolgen im Buchhaltungssystem oder durch einen Nutzer, dessen Rolle abgeschlossene Orders bearbeiten darf.“ Sonst folgt „Änderungen nimmt ein Nutzer vor, dessen Rolle abgeschlossene Orders bearbeiten darf.“ Was das Team an einer abgeschlossenen Order weiterhin tun kann: * **Shipments:** die Stopps und Daten der Shipments der Order ändern, solange der Order-Preis (und, falls so eingerichtet, der Tour-Preis) erhalten bleibt. Wählen Sie für die Order (und, falls so eingerichtet, für die Tour) **Beibehalten**, wenn Orbit MissionControl fragt, wie der Product-Preis angepasst werden soll. Eine Änderung, die eine gesperrte Order (oder, falls so eingerichtet, Tour) **Neu berechnen** würde, wird als Ganzes abgelehnt, und nichts wird gespeichert. * **Dokumente und Kommentare:** Kommentare zur Order schreiben und Dokumente hochladen, wenn die Rolle die **Dokument**-Berechtigungen hat. Die Sperre betrifft sie nicht; **Operator Member** hat von vornherein keine Dokument-Berechtigungen, eine davon kopierte Rolle kann also an keiner Order Dokumente hochladen. * **Tour-Review:** bei einer Tour im Status `Review nötig` **Review abschließen** wählen. Die Tour und ihre Order werden wie gewohnt abgeschlossen. Was die Rolle an einer abgeschlossenen Order sperrt: * **Angaben der Order:** den Kunden, den Rechnungsempfänger, die Kundenreferenz, die Felder Kundenkommentar und Interner Kommentar, den Preis und die Eigenschaften. * **Aktionen der Order:** die Aktionen im Menü der Order, auch das Übertragen der Order an das Buchhaltungssystem von Hand und das erneute Übertragen einer fehlgeschlagenen Übertragung. Auch das Abbrechen einer ausstehenden Übertragung ist gesperrt. * **Die Tour:** das Löschen der abgeschlossenen `Tour`; alles andere an der Tour bleibt wie bei jeder anderen Tour. **Automatisch übertragen, wenn eine Order abgeschlossen wird** funktioniert weiter. Orbit überträgt die Order selbst, sobald sie abgeschlossen ist, unabhängig von der Rolle des Nutzers, der das Review abgeschlossen hat. Nutzer mit **Operator Administrator** bearbeiten abgeschlossene Orders weiterhin, deshalb übernehmen Julia und Max die Korrekturen. Jede andere Rolle ohne diese Bedingungen kann das ebenso. > **Ein Schalter hebt die Sperre auf:** Um die Sperre aufzuheben, löschen Sie die Bedingung über ihr Löschsymbol. Auch der Schalter **bearbeiten** oder **löschen** in der Zeile `Order` oder `Tour` entfernt sie: Er ersetzt jede Regel **bearbeiten** beziehungsweise **löschen** dieser Zeile, Bedingungen eingeschlossen. Prüfen Sie beide Zeilen, nachdem Sie einen Schalter geändert haben. > **Warum eine Kollegin weniger Datensätze sieht als Sie:** Weil der Zugriff nach Rolle und Bedingung eingeschränkt ist, können zwei Personen dieselbe Liste öffnen und unterschiedlich viel sehen. Eine kürzere Liste, ein ausgeblendeter Preis oder ein Datensatz, den ein bestimmter Nutzer nicht sieht: Hier wendet Orbit die Rolle dieses Nutzers so an, wie sie eingerichtet ist. Das ist so gewollt, kein Fehler und keine fehlenden Daten. Wenn jemand mehr sehen muss, passen Sie seine Rolle an, statt einen Umweg zu suchen. ## FAQ **Q: Kann ein Nutzer mit gesperrter Rolle eine abgeschlossene Order weiterhin an die Buchhaltung übertragen?** Nein. Eine Order von Hand zu übertragen ist eine Änderung an der Order, deshalb gilt die Sperre dafür, ebenso für das erneute Übertragen einer fehlgeschlagenen und das Abbrechen einer ausstehenden Übertragung. **Automatisch übertragen, wenn eine Order abgeschlossen wird** ist nicht betroffen: Orbit überträgt die Order selbst. Eine fehlgeschlagene Übertragung überträgt ein Nutzer erneut, dessen Rolle abgeschlossene Orders bearbeiten darf, zum Beispiel **Operator Administrator**. **Q: Was passiert, wenn ein Nutzer mit gesperrter Rolle den Preis einer abgeschlossenen Order neu berechnet?** Orbit MissionControl lehnt die Änderung ab und speichert nichts. Das gilt, wenn eine Änderung an einem Shipment den Preis der abgeschlossenen Order (oder, falls so eingerichtet, ihrer abgeschlossenen Tour) **Neu berechnen** würde. Dieselbe Änderung mit **Beibehalten** für jeden gesperrten Preis wird gespeichert.