Überblick

Der Zugriff in niotix beantwortet drei Fragen: was getan werden darf, wo das gilt und wer es hält. Vier Bausteine decken diese Fragen ab:

• Berechtigung – eine Aktion auf einem Objekttyp, technisch geschrieben als Objekttyp.aktion (z. B. VirtualDevice.read). Installationsweit definiert.
• Zugriffsbereich – die Position in der Objektstruktur, für die eine Berechtigung gilt, einschließlich alles darunter. Gehört zu genau einem Konto und einem Digitalen Zwilling.
• Rolle – ein benanntes Paket von Berechtigungen, je Konto gepflegt.
• Zugriffsobjekt – die Zuweisung selbst: ein Benutzer, ein Zugriffsbereich, eine Menge von Rollen.

Eine Aktion gelingt nur, wenn beides passt: Eine Rolle enthält die nötige Berechtigung, und das Zugriffsobjekt liegt auf einem Bereich, der das betroffene Objekt abdeckt. Rechte werden deshalb nie je Objekt gepflegt, sondern je Position in der Struktur – das hält große Strukturen beherrschbar und setzt das Prinzip der minimalen Rechte um.

Der Zugriffsbereich ist das Scharnier: Er ist die einzige Stelle, an der die Objektstruktur links und die Zuweisung rechts zusammentreffen.

Schritt-für-Schritt-Anleitungen zu Modulen, Rollen-Editor und Standard-Rollen-Wizard finden sich unter Berechtigungen; das Objektmodell ist unter Datenmodell & Definitionen beschrieben.

Berechtigungen

Eine Berechtigung beschreibt immer zwei Dinge: worauf sie sich bezieht – einen Objekttyp in der Plattform, etwa Digitaler Zwilling, Virtuelles Gerät oder Benutzerverwaltung – und was damit erlaubt ist, also die Aktion (lesen, auflisten, schreiben, verwalten und ähnlich). Die technischen Bezeichnungen verbinden beides als Objekttyp.aktion, zum Beispiel VirtualDevice.read oder DigitalTwin.manage.

Welche Kombinationen es gibt, ist einmal für die gesamte Installation festgelegt – das pflegt kein Konto selbst. Ein Konto entscheidet lediglich, wie diese Bausteine zu Rollen gebündelt und wo sie vergeben werden. Das ist wichtig zu wissen, denn es bedeutet: Eine Berechtigung, die in der Oberfläche nirgends sichtbar ist, existiert im System dennoch und kann in eine Rolle aufgenommen werden.

Zu beachten:

• Nicht jede Berechtigung entspricht einem Menüpunkt. Manche steuern nur Hintergrundfunktionen oder den Zugriff für andere Module (z. B. Listen ohne volle Detailansicht).
• Kombinationen zählen. Ob eine Ansicht oder Aktion möglich ist, ergibt sich oft aus mehreren Berechtigungen gleichzeitig (z. B. Leseberechtigungen auf verschiedenen Ebenen).

Objekttypen, Aktionen und Platzhalter

Zwei Platzhalter halten die Zahl der Kombinationen überschaubar:

• all als Objekttyp umfasst jeden vorhandenen Objekttyp. Der Platzhalter lässt sich mit jeder Aktion verbinden, all.read ist also Lesezugriff auf alles, all.write Schreibzugriff auf alles.
• manage als Aktion umfasst jede Aktion auf diesem Objekttyp.

DigitalTwin.manage erlaubt somit alles an Digitalen Zwillingen, während all.manage die vollständige Kontrolle über alles gewährt – innerhalb des Bereichs, auf dem die Berechtigung vergeben wurde. Deshalb sollte all.manage der Administration vorbehalten bleiben: Es ist nicht „ein wenig mehr als manage“, sondern jeder heutige und künftige Objekttyp zugleich.

Über die Platzhalter hinaus schließen einige Aktionen einander ein. Das ist beim Zusammenstellen einer Rolle relevant, weil die engere Berechtigung dann nicht zusätzlich aufgenommen werden muss:

UserManagement.impersonate erlaubt, in der Plattform als anderer Benutzer zu handeln. Die Berechtigung ist deshalb nicht in UserManagement.manage enthalten: Wer Benutzer administriert, erhält nicht automatisch die Möglichkeit, unter deren Identität zu arbeiten. Sie muss ausdrücklich vergeben werden oder kommt mit all.manage.

Zugriffsbereiche

Ein Zugriffsbereich begrenzt, wo eine Berechtigung wirkt. Ohne passenden Bereich gilt selbst eine vorhandene Berechtigung nicht für die betroffenen Daten. In der Oberfläche erscheint das Konzept als Zugriffsbereich am Digitalen Zwilling und als Hauptberechtigungsbereich beim Anlegen eines Benutzers.

Alle Zugriffsbereiche einer Installation bilden einen Baum. Jeder Bereich hat genau einen übergeordneten Bereich – das ist die Voraussetzung für die Vererbung.

Root-Bereich
├── Acme Utilities                   (Kontobereich)
│   ├── Wasser                       (Zwillingsbereich)
│   │   └── Wasserwerk Süd           (Zwillingsbereich, optionale feinere Trennung)
│   ├── Wärme                        (Zwillingsbereich)
│   └── Acme Metering                (Kontobereich eines Unterkontos)
│       └── Messstellen Ost          (Zwillingsbereich)
└── Zweite Firma                     (Kontobereich eines fremden Kontos)

So ist der Baum zu lesen:

• Eine Rolle auf Wasser gilt für Wasser und Wasserwerk Süd, aber nicht für Wärme.
• Eine Rolle auf Acme Utilities gilt für Wasser und Wärme – reicht aber nur mit all.manage in Acme Metering hinein, siehe Unterkonten unterbrechen die Vererbungskette.
• Digitale Zwillinge ohne eigenen Bereich erscheinen hier nicht. Sie gehören zum nächsthöheren Bereich über ihnen, weshalb ein vielstufiger Zwillingsbaum trotzdem einen sehr flachen Bereichsbaum ergeben kann.

Warum Zugriffsbereiche an Digitalen Zwillingen hängen

Ein Bereich ist kein eigenständiges Objekt, das sich unabhängig modellieren ließe. Zwei Eigenschaften definieren ihn:

• Ein Bereich gehört zu genau einem Konto.
• Ein Bereich hat immer einen Digitalen Zwilling an sich hängen und übernimmt von diesem seinen Namen.

Das ist der Grund, warum es keine Verwaltungsmaske für Bereiche gibt: Ein Bereich hat ohne den Teil der Struktur, den er repräsentiert, keine Bedeutung. Einen Bereich anzulegen bedeutet, einen Digitalen Zwilling zum Einstiegspunkt eines Berechtigungsraums zu erklären – also gehört die Aktion an den Zwilling und nicht auf eine eigene Seite. Es erklärt auch die Benennung: Weil der Bereich nach seinem Zwilling heißt, sind die später im Benutzer-Wizard angebotenen Einträge als Teile der Struktur erkennbar und nicht als abstrakte Bezeichner.

Die Folge ist, dass die Struktur der Digitalen Zwillinge das Berechtigungsmodell ist. Wer plant, wer was sehen darf, plant in Wahrheit den Zwillingsbaum – deshalb beginnt das Abteilungsbeispiel weiter unten mit der Struktur und nicht mit den Benutzern.

Kontobereich und Zwillingsbereich

Es gibt zwei Arten von Bereichen, die der Bereichsbaum in der Oberfläche mit unterschiedlichen Symbolen kennzeichnet:

• Kontobereich (im Bereichsbaum Konto Berechtigungsbereich) – der Root-Bereich eines Kontos. Er entsteht mit dem Konto und deckt das Konto und alles darunter ab. Konfiguration auf Kontoebene (Konnektoren, Integrationsflows, Smarte Gruppen, Kontoeinstellungen) wird ausschließlich gegen diesen Bereich geprüft.
• Zwillingsbereich (im Bereichsbaum Zwillings Berechtigungsbereich) – der Sicherheitskontext eines Digitalen Zwillings und alles, was darunter hängt: Unterzwillinge, die den Bereich mitnutzen, die Virtuellen Geräte darunter, deren Datenpunkte und deren Alarmprotokolle.

Ein Virtuelles Gerät hat nie einen eigenen Bereich. Es liegt immer im Bereich des Digitalen Zwillings, dem es zugeordnet ist. Genau dieser Mechanismus trägt das ganze Konzept: Um zu steuern, wer ein Gerät sieht, wird das Gerät unter den passenden Zwilling gehängt.

Wie ein Zwillingsbereich entsteht

Es gibt genau zwei Wege, einen Zwillingsbereich anzulegen, und beide führen über einen Digitalen Zwilling:

1. Beim Anlegen eines Digitalen Zwillings – der Anlagedialog bietet die Option Übergeordneten Bereich verwenden („Dadurch wird der Bereich des übergeordneten Objektes wiederverwendet und kein neuer Berechtigungsbereich erzeugt.“). Wird das Kontrollkästchen entfernt, erhält der neue Zwilling einen eigenen Bereich.
2. An einem bestehenden Digitalen Zwilling – den Zwilling öffnen, Tab Metainformationen, und dort den Button Zugriffsbereich erstellen verwenden („Erstelle einen eigenen Zugriffsbereich für diesen Zwilling. Dies ist nur notwendig, wenn die Berechtigungen sich unterscheiden sollen von einem übergeordneten Objekt.“). Der Button wird nur für Zwillinge angeboten, die noch keinen eigenen Bereich besitzen, und setzt DigitalTwin.manage voraus.

Ein neu angelegter Zwillingsbereich wird immer unter dem Bereich des übergeordneten Zwillings eingehängt. Der Bereichsbaum spiegelt damit den Zwillingsbaum, aber nur auf den Ebenen, auf denen tatsächlich ein Bereich angelegt wurde. Alles dazwischen gehört einfach zum nächsthöheren Bereich.

Der Bereich übernimmt seinen Namen vom Titel des Zwillings, der ihn besitzt. Wird dieser Zwilling umbenannt, ändert sich auch der Name des Bereichs, sodass beide zusammenpassen.

Vererbung entlang des Bereichsbaums

Zugriff wird auf einem Bereich vergeben und gilt für diesen Bereich und alle Bereiche darunter. Eine Rolle auf dem Bereich Wasser deckt damit auch jeden Unterzwilling, jedes Virtuelle Gerät und jeden Datenpunkt unterhalb von Wasser ab – einschließlich der Bereiche, die dort erst später entstehen. Die Vererbung nach unten ist der Sinn des Baums: Sie lässt das Modell eine wachsende Struktur überdauern, ohne dass Berechtigungen erneut angefasst werden müssen.

Es gibt genau eine Stelle, an der die Vererbung endet: an der Grenze eines Unterkontos. Siehe Unterkonten unterbrechen die Vererbungskette.

Benutzer, Zugriffsobjekte und primäre Bereiche

Benutzer gehören nicht in dem Sinne zu einem Konto, wie Digitale Zwillinge oder Konnektoren es tun. Ein Benutzer ist eine plattformweite Identität, die Zugriff in beliebig vielen Bereichen an beliebiger Stelle des Bereichsbaums halten kann – auch in Bereichen unterschiedlicher Konten. Was einen Benutzer an ein Konto bindet, ist kein Zugehörigkeitsfeld, sondern die Menge der Bereiche, in denen er Zugriff hält.

Jede dieser Bindungen ist ein Zugriffsobjekt: ein Benutzer, ein Bereich und die Rollen, die dort gelten. Zugriffsobjekte sind die Einheit, auf der alles Weitere aufbaut – jede Prüfung in Oberfläche und API läuft darauf hinaus: „Gibt es ein Zugriffsobjekt auf einem Bereich, der dieses Objekt abdeckt, und trägt es die nötige Berechtigung?“

Diese Freiheit stellt eine Frage, die die Plattform beantworten muss: Wenn ein Benutzer überall Zugriff halten kann, wer darf diesen Benutzer administrieren? Die Antwort ist das Konzept der primären Zugriffsobjekte.

Ein Zugriffsobjekt eines Benutzers ist primär, wenn es kein weiteres Zugriffsobjekt desselben Benutzers auf einem höher gelegenen Bereich gibt. Anders gesagt: Die primären Bereiche sind die höchsten Punkte, an denen der Benutzer in den Baum einsteigt. Ein Benutzer kann mehrere davon haben, und die Plattform berechnet sie automatisch neu, sobald Zugriff vergeben oder entzogen wird – es ist kein Feld, das gepflegt wird.

Ein Beispiel: Ein Benutzer hält Zugriff auf Wasser, auf Wasserwerk Süd und auf Wärme. Da Wasserwerk Süd unter Wasser liegt, ist es nicht primär. Die primären Bereiche sind Wasser und Wärme.

Für die Administration von Benutzern bedeutet das:

• Damit ein Benutzer in der Benutzerliste erscheint, benötigt eine administrierende Person UserManagement.read (bzw. .manage für Änderungen) für die primären Bereiche dieses Benutzers – entweder auf diesen Bereichen selbst oder auf einem gemeinsamen übergeordneten Bereich, zum Beispiel dem Kontobereich.
• Zusätzlich gilt für die Liste: Liegt auch nur ein Zugriffsobjekt des Benutzers außerhalb der eigenen Bereiche, wird der Benutzer überhaupt nicht angezeigt. Das verhindert die teilweise Sichtbarkeit von Konten, in denen keine Rechte bestehen.
• Rollen können nur auf Bereichen vergeben werden, auf denen selbst Zugriff besteht. Rechte lassen sich nicht über die eigene Reichweite hinaus verteilen.

Im Benutzer-Wizard erzeugt das Feld Hauptberechtigungsbereich das erste Zugriffsobjekt des Benutzers – das in diesem Moment sein einziger und damit primärer Bereich ist. Jeder später ergänzte Bereich kann verändern, welche Zugriffsobjekte primär sind.

Rollen

Technisch fügen Rollen nichts hinzu, was einzelne Berechtigungen nicht ausdrücken könnten – sie sind eine Benennungsschicht. Ihr Wert ist praktisch: Zuweisungen erfolgen im Vokabular der Organisation und nicht in dem des Systems. „Facility Manager“ vermittelt seine Absicht, die gleichwertige Liste DigitalTwin.list, DigitalTwinStates.read, UserManagement.manage nicht – und sie muss für jeden einzelnen Benutzer korrekt reproduziert werden. Rollen ermöglichen außerdem, die Zuweisung an Personen zu delegieren, die die einzelnen Berechtigungen nicht kennen müssen.

Eine Rolle ist demnach eine benannte Sammlung von Berechtigungen – vergleichbar mit einer Vorlage (z. B. nur Lesen oder Verwaltung der Integrationen). Anders als Berechtigungen, die installationsweit existieren, werden Rollen pro Konto gepflegt: Eine Rolle ist nur für das Konto sichtbar und nutzbar, für das sie angelegt wurde – nicht in übergeordneten Konten und nicht in Unterkonten. Eine Rolle, die mehrere Konten brauchen, muss in jedem davon angelegt werden.

Benutzern und API-Schlüsseln werden Rollen je Zugriffsbereich zugewiesen. Derselbe Benutzer kann in verschiedenen Bereichen verschiedene Rollen halten (z. B. volle Rechte in einer Abteilung, nur Lesen in einer anderen).

Standardrollen legen fest, welche Rollen neue Benutzer für einen gewählten Bereich erhalten, wenn beim Anlegen keine abweichende Auswahl getroffen wird. Im Auslieferungszustand sind die Standardrollen eines Kontos die beiden „Lister“-Rollen (DigitalTwinLister, VirtualDeviceLister) auf dem Kontobereich – das genügt, um durch die Struktur zu navigieren, aber nicht, um Daten zu sehen. Standardrollen lassen sich je Bereich mit dem Standard-Rollen-Wizard konfigurieren, siehe Berechtigungen.

Zu den mit jedem Konto ausgelieferten Rollen gehören unter anderem:

Module unter Einstellungen → Berechtigungen sind eine weitere Schicht über den Rollen: Wird ein Modul aktiviert, kommen dessen vordefinierte Standardrollen hinzu; wird es deaktiviert, werden sie wieder entfernt.

Beispiel: Trennung der Abteilungen Wasser und Wärme

Ein Konto, Acme Utilities, betreibt zwei Abteilungen in einem Konto: Wasser und Wärme. Jede Abteilung hat eigene Mitarbeitende, und sie dürfen die Objekte der jeweils anderen nicht sehen. Beide Abteilungen sollen dieselbe Konfiguration auf Kontoebene weiternutzen (Konnektoren, Integrationsflows, Gerätetreiber).

Zielbild

Zwillingsstruktur

Die Struktur braucht einen Digitalen Zwilling je Abteilung, direkt unter dem Root-Zwilling des Kontos, und jeden davon mit eigenem Zugriffsbereich. Alles unterhalb eines Abteilungszwillings kann den Abteilungsbereich dann mitnutzen.

Schritte in der Oberfläche:

1. Digitale Zwillinge öffnen und den Zwilling Wasser mit dem Root-Zwilling des Kontos als übergeordnetem Objekt anlegen. Die Option Übergeordneten Bereich verwenden dabei entfernen, damit der Zwilling einen eigenen Zugriffsbereich erhält.
2. Für Wärme wiederholen.
3. Alles unterhalb einer Abteilung (Standorte, Gebäude, Anlagen) mit aktivierter Option Übergeordneten Bereich verwenden anlegen. Diese Zwillinge gehören dann zum Abteilungsbereich, und Berechtigungen müssen nicht je Ebene gepflegt werden.
4. Einen weiteren eigenen Bereich nur dort anlegen, wo eine noch feinere Trennung wirklich nötig ist – etwa wenn ein externer Dienstleister ausschließlich Wasserwerk Süd sehen darf. Jeder zusätzliche Bereich ist zusätzlicher Pflegeaufwand.

Virtuelle Geräte zuordnen

Virtuelle Geräte lassen sich keinem Bereich direkt zuordnen – sie erben den Bereich ihres übergeordneten Digitalen Zwillings. Ein Gerät einer Abteilung zuzuordnen bedeutet deshalb, es unter einen Zwilling dieser Abteilung zu hängen oder dorthin zu verschieben:

• Neue Geräte: Das Gerät unterhalb des richtigen Abteilungszweigs anlegen (unter einem beliebigen Zwilling, dessen Bereich der Abteilungsbereich ist). Es erhält den Abteilungsbereich automatisch.
• Bestehende Geräte: Das übergeordnete Objekt des Geräts ändern. In der Liste der Virtuellen Geräte können mehrere Geräte ausgewählt und in einer Massenbearbeitung gemeinsam umgehängt werden.

Regeln beim Verschieben eines Geräts:

• Das Ziel muss ein Digitaler Zwilling sein; ein Virtuelles Gerät kann nicht übergeordnetes Objekt eines anderen Geräts sein.
• Das Konto darf sich nicht ändern – ein Gerät kann nur innerhalb seines Kontos verschoben werden.
• Wer verschiebt, benötigt VirtualDevice.write (oder .manage) im Bereich des Zielzwillings, nicht nur im Quellbereich.
• Nach dem Verschieben trägt das Gerät den Bereich des neuen übergeordneten Objekts, und mit ihm alle Datenpunkte und Alarmprotokolle.

Alarmprotokolle

Alarmprotokollen wird kein eigener Bereich zugewiesen. Sie werden über das Objekt gefiltert, das sie erzeugt hat:

• Alarme zum Gesundheitszustand eines Virtuellen Geräts werden gegen den Bereich dieses Geräts geprüft und benötigen VirtualDevice.read. Im Beispiel sehen die Mitarbeitenden von Wasser damit automatisch nur Alarme aus Wasser – ohne zusätzliche Konfiguration.
• Alarmberichte setzen VirtualDevice.manage auf dem Kontobereich voraus – für Anlegen, Bearbeiten, Testen und Löschen einer Berichtsdefinition gleichermaßen. VirtualDevice.manage auf einem Abteilungsbereich genügt dafür nicht.

Benutzer für einen Bereich anlegen

Unter Einstellungen → Konten → Tab Benutzer wird ein neuer Benutzer in zwei Schritten angelegt:

1. Hauptberechtigungsbereich – den Abteilungsbereich aus dem Bereichsbaum wählen, z. B. Wasser. Das erzeugt das erste Zugriffsobjekt des Benutzers und damit seinen primären Bereich: Er entscheidet, welche administrierenden Personen diesen Benutzer überhaupt sehen. Wasser statt des Kontobereichs zu wählen ist die Voraussetzung dafür, dass die Abteilungsleitung Wasser die eigenen Mitarbeitenden administrieren kann.
2. Berechtigungen – die Standardrollen des gewählten Bereichs sind vorbelegt und können ersetzt werden. Über weitere Zeilen lassen sich Rollen in zusätzlichen Bereichen vergeben.

Welche Rollen gewählt werden, entscheidet darüber, was die Mitarbeitenden der Abteilung in ihrem Bereich tatsächlich tun können:

Ein Benutzer kann in mehreren Bereichen unterschiedliche Rollen halten. Eine abteilungsübergreifend tätige Servicekraft erhält etwa DigitalTwinReader + VirtualDeviceManager auf Wasser und DigitalTwinLister + VirtualDeviceReader auf Wärme, während eine Abteilungsleitung zusätzlich UserManager nur für die eigene Abteilung bekommt.

Derselbe Wizard wird für API-Schlüssel genutzt, sodass sich eine Schnittstelle auf genau dieselbe Weise auf eine Abteilung begrenzen lässt. Die Liste der API-Schlüssel einzusehen erfordert allerdings all.manage – eine Abteilungsleitung kann die Schlüssel der eigenen Abteilung also nicht selbst verwalten.

Gegenprobe

Mit dieser Einrichtung gilt für einen Benutzer mit DigitalTwinReader und VirtualDeviceReader auf dem Bereich Wasser:

• Er sieht den Zweig Wasser mit allen Zwillingen und Geräten darunter, auch mit später ergänzten Objekten.
• Er sieht keine Zwillinge aus Wärme, keine Geräte aus Wärme, deren Werte oder deren Alarme zum Gesundheitszustand.
• Er sieht keine Benutzer, deren primärer Bereich in Wärme liegt.
• Er hat keinen Zugriff auf Konnektoren, Integrationsflows oder Smarte Gruppen, da diese gegen den Kontobereich geprüft werden.

Wird DigitalTwinReader aus dieser Kombination entfernt, verschiebt sich das Bild in einer Weise, die bewusst geprüft werden sollte: Die Gerätelisten des Zweigs Wasser, deren Werte und deren Alarmprotokolle bleiben sichtbar, während die Zwillingsstruktur aus der Navigation verschwindet. Das ist eine gültige Konfiguration für reines Gerätemonitoring, aber selten das, was mit „Zugriff auf die Abteilung Wasser“ gemeint ist.

Eine Abteilungsleitung Wasser mit UserManager auf dem Bereich Wasser sieht in der Benutzerliste alle Benutzer, deren Zugriff vollständig innerhalb von Wasser liegt – aber nicht eine abteilungsübergreifend tätige Servicekraft, die auch Zugriff in Wärme hält, weil eines ihrer Zugriffsobjekte außerhalb der Reichweite der Abteilungsleitung liegt. Der Zugriff auf einen einzelnen Benutzer über die API ist weiter gefasst: Dort genügt es, dass sich mindestens einer der primären Bereiche dieses Benutzers mit den eigenen Bereichen überschneidet.

Grenzen des Bereichskonzepts

Objekte ohne Bereichsbezug

Das Konzept reicht nur so weit wie der Zwillingsbaum. Objekte ohne Position in diesem Baum – weil sie dem Konto als Ganzem dienen und nicht einem Zweig davon – lassen sich nicht über einen Bereich abgrenzen. Ein Konnektor nimmt Daten entgegen, bevor bekannt ist, zu welchem Zwilling sie gehören, und eine Smarte Gruppe spannt sich bewusst über die Struktur; beides lässt sich nicht an einem einzelnen Punkt darin verankern.

Solche Objekte existieren nur je Konto und tragen keinen Bereich. Der Zugriff auf sie wird immer gegen den Kontobereich geprüft. Wer mit ihnen arbeiten muss, braucht deshalb eine Rolle auf dem Hauptkonto – was im Gegenzug Sicht auf das gesamte Konto gewährt:

Unterkonten unterbrechen die Vererbungskette

Wird ein Unterkonto angelegt, wird dessen Kontobereich unter dem Bereich des übergeordneten Kontos eingehängt – der Bereichsbaum ist ein Baum über die gesamte Installation. Wörtlich genommen würde die Vererbung nach unten bedeuten, dass jede Rolle auf dem Hauptkonto automatisch in jedem Unterkonto gilt, was getrennte Konten als Grenze sinnlos machen würde.

Die Plattform behandelt diesen einen Schritt deshalb anders: Bereiche von Unterkonten werden nur einbezogen, wenn die auf dem Kontobereich des übergeordneten Kontos vergebene Rolle all.manage enthält. Die Administration reicht in Unterkonten hinein, eine abteilungs- oder objektbezogene Rolle nicht.

Praktische Folgen:

• Um einem Benutzer Rechte in einem Unterkonto zu geben, ohne ihn zur Administration zu machen, wird ihm eine Rolle direkt auf einem Bereich innerhalb dieses Unterkontos vergeben, statt auf die Vererbung von oben zu setzen.
• Wer all.manage auf dem Kontobereich des Hauptkontos hält, erreicht alles, einschließlich aller Unterkonten. Ein Dazwischen gibt es nicht.
• Die Regel betrifft vererbte Rechte, nicht die Benutzerverwaltung. Eine Benutzerverwaltung auf dem Kontobereich des Hauptkontos kann weiterhin einen Benutzer administrieren, dessen Zugriff in einem Unterkonto liegt – dort aber keine Berechtigungen vergeben, da Rechte nur auf Bereichen verteilt werden können, auf denen selbst Zugriff besteht.

Verhalten, das zu beachten ist

• Übergeordneten Bereich verwenden ist standardmäßig aktiv. Neue Digitale Zwillinge nutzen den Bereich des übergeordneten Zwillings mit, solange die Option nicht entfernt wird. Strukturen, die ohne Beachtung dieser Option gewachsen sind, enden mit einem einzigen Bereich.
• Das Löschen eines Digitalen Zwillings löscht seinen Bereich – zusammen mit den Benutzerzuweisungen auf diesem Bereich und auf den Bereichen darunter. Sind direkt an dem Zwilling Virtuelle Geräte angehängt, wird das Löschen abgewiesen; diese Geräte müssen vorher umgehängt oder gelöscht werden. Geräte, die tiefer in der Struktur unter dem Zwilling hängen, werden dagegen unter den Root-Zwilling des Kontos verschoben und erhalten damit den Kontobereich, wo sie eine deutlich größere Gruppe von Benutzern sehen kann. Das Löschen eines Abteilungszwillings weitet den Zugriff auf dessen Geräte also unbemerkt aus.
• Das Umbenennen eines Zwillings benennt seinen Bereich um. Nützlich für die Lesbarkeit, aber es ist zu beachten, dass der Bereich auch im Benutzer-Wizard eine andere Bezeichnung erhält.
• In der Benutzerliste sind Benutzer nur über ihre primären Bereiche sichtbar, und nur, wenn alle ihre Zugriffsobjekte innerhalb der eigenen Bereiche liegen – siehe Benutzer, Zugriffsobjekte und primäre Bereiche. Einem Benutzer Zugriff in einer zweiten Abteilung zu geben nimmt ihn damit aus der Liste beider Abteilungsleitungen heraus.
• Das Verschieben von Zwillingen verschiebt Bereiche. Wird ein Digitaler Zwilling einem anderen übergeordneten Objekt zugeordnet, wandert sein Bereich innerhalb des Bereichsbaums mit, was verändert, wer Zugriff darauf erbt.
• Berechtigungsprüfungen werden zwischengespeichert, mit einer Lebensdauer von 10 Minuten. Beim Anlegen, Verschieben und Löschen von Bereichen, beim Ändern von Rollen und beim Vergeben oder Entziehen von Zugriff werden die betroffenen Zwischenspeicher jedoch sofort verworfen, und eine fehlgeschlagene Prüfung wird zusätzlich einmal ohne Zwischenspeicher wiederholt. Änderungen wirken deshalb in der Regel unmittelbar.

Wann stattdessen Unterkonten sinnvoll sind

Beides lässt sich kombinieren: Unterkonten für die harte Trennung, Zugriffsbereiche innerhalb jedes Unterkontos für die Objektstruktur.

Konfiguration in der Oberfläche

• Digitale Zwillinge → Zwilling anlegen: Option Übergeordneten Bereich verwenden; Zwilling → Tab Metainformationen: Zugriffsbereich und Zugriffsbereich erstellen.
• Virtuelle Geräte → Liste: das übergeordnete Objekt ändern, einzeln oder per Massenbearbeitung.
• Einstellungen → Konten: Benutzer und API-Schlüssel anlegen und bearbeiten, Hauptberechtigungsbereich setzen und Rollen je Zugriffsbereich zuweisen.
• Einstellungen → Berechtigungen: Module, Rollen-Editor, Standard-Rollen-Wizard – siehe Berechtigungen.

Verwandte Seiten

• Berechtigungen (Einstellungen: Module, Rollen-Editor, Listen)
• Konten (Benutzer, API-Schlüssel, Bereichs-Wizard, Unterkonten)
• Datenmodell & Definitionen