Berechtigungssystem

Die Mirox-Plattform steuert den Zugriff über ein mehrschichtiges, rollenbasiertes Berechtigungsmodell, das Ihnen präzise Kontrolle darüber gibt, wer welche Anlagen sehen und ändern darf — ohne dass Sie einzelne Rechte mühsam einzeln verwalten müssen. Die Rollen übernehmen die Gruppierung, die Hierarchie übernimmt die Vererbung.

Berechtigungsphilosophie

Das Berechtigungssystem basiert auf einigen Grundsätzen, die den Zugriff sowohl sicher als auch leicht nachvollziehbar halten:

Hierarchische Vererbung — Der Zugriff folgt der natürlichen Hierarchie von Ressourcen und Organisationen: einmal weit oben vergeben, und er fließt nach unten.
Least Privilege — Jede Rolle trägt nur die Rechte, die ihre Aufgabe tatsächlich benötigt.
Trennung der Zuständigkeiten — Organisatorische Stellung und Ressourcenzugriff sind zwei voneinander getrennte Achsen, sodass Sie jemandem eine leitende Organisationsrolle geben können, ohne jede Anlage offenzulegen — und umgekehrt.
Explizite Zuweisung — Zugriff wird bewusst gewährt, niemals vorausgesetzt.
Kontextbewusstsein — Dieselbe Person kann auf unterschiedlichen Anlagen unterschiedliche Rechte haben.

Zusammen sorgen diese Prinzipien für einen sicheren und zugleich flexiblen Ansatz zur Verwaltung von Zugriffen über die gesamte Mirox-Plattform hinweg.

Berechtigungsschichten

Eine Anfrage durchläuft eine Abfolge von Prüfungen. Jede Schicht beantwortet eine Frage; alle relevanten Schichten müssen zustimmen, bevor der Zugriff gewährt wird.

Hinweis: Die API-Schicht gilt nur für Anfragen, die mit einem API-Token authentifiziert werden; interaktive Sitzungen gelangen direkt zur Systemschicht.

Die Schichten:

API-Schicht (orange) — Nur für Anfragen mit API-Token. Sie validiert den Token und wendet dessen Berechtigungsgruppe an, die das, was der Token-Inhaber ohnehin schon durfte, immer nur einschränken kann.
Systemschicht (rot) — Das erste Tor für jede Anfrage. Sie legt die plattformweite Stellung fest (normaler Benutzer vs. Plattformadministrator) und schützt systemkritische Operationen unabhängig von allen anderen Schichten.
Organisationsschicht (blau) — Bestätigt, dass Sie zu der Organisation gehören, der die Ressource gehört, und wendet Ihre Organisationsrolle an.
Funktionsschicht (grün) — Die granularste Prüfung: Sie entscheidet, was Sie auf einer bestimmten Anlage oder einem bestimmten Portfolio tun dürfen.

Das folgende Diagramm zeigt die häufigsten Kombinationen. Organisationsweite Daten erfordern die Organisationsprüfung; eine einzelne Anlage erfordert die Funktionsprüfung; viele Anfragen erfordern beides.

Systemberechtigungsschicht

Die Systemschicht ist das erste Sicherheitstor. Sie unterscheidet Plattformadministratoren von normalen Benutzern und schützt systemweite Operationen:

Plattformadministratoren können systemweite Operationen durchführen.
Normale Benutzer können keine Aktionen ausführen, die die Plattform selbst betreffen.
Diese Schicht bewertet keinen funktionsbezogenen Zugriff (etwa die Berichtserstellung) — das geschieht weiter unten.

Die Systemintegrität bleibt geschützt, selbst wenn eine feiner granulierte Prüfung fehlerhaft konfiguriert ist.

Organisationsberechtigungsschicht

Jeder Benutzer gehört zu genau einer Organisation, die das Tor zu den Ressourcen darstellt:

Organisationen besitzen Ressourcen (Portfolios und Parks).
Ihren Basiszugriff erhalten Sie über Ihre Organisationsrolle.
Organisationen können Kooperationsvereinbarungen eingehen, um bestimmte Ressourcen über die Organisationsgrenze hinweg zu teilen.

Diese Schicht setzt die Organisationsgrenzen durch: Sie erreichen nur Ressourcen, die Ihrer Organisation gehören oder ihr über eine Kooperation zugänglich gemacht wurden.

Ressourcen- (Funktions-)Berechtigungsschicht

Die granularste Ebene steuert, was Sie auf einer einzelnen Anlage oder einem einzelnen Portfolio tun können. Der Zugriff wird hier als Funktionsrolle ausgedrückt (siehe unten):

Ihre Organisationsrolle stellt auf jeder eigenen Ressource eine Standard-Funktionsrolle bereit.
Organisationen können diesen Standard überschreiben, indem sie Ihnen eine bestimmte Funktionsrolle auf einer bestimmten Ressource zuweisen — weiter gefasst oder enger als Ihr Standard.
Eine direkte Zuweisung setzt sich immer gegen den vererbten Standard durch, sodass Ausnahmen einfach umzusetzen sind.

Diese Schicht ermöglicht eine präzise Steuerung pro Anlage, ohne die Organisationsrolle einer Person zu ändern.

API-Token-Berechtigungsschicht

Eine optionale Schicht für Automatisierung und Integrationen:

API-Tokens werden von Benutzern erstellt, um Skripte und externe Systeme zu steuern.
Ein Token kann niemals die Berechtigungen des Benutzers überschreiten, der ihn erstellt hat — er kann nur einschränken.
Ein Token ist an eine Berechtigungsgruppe gebunden, die ihn auf einen Funktionsbereich beschränkt (siehe API-Berechtigungsgruppen).
Ein Token wird nie nach einem zweiten Faktor gefragt, und die Regeln zur Anmeldedauer beenden es nicht. Eine Regel gibt es: Ein Benutzer ohne zweiten Faktor kann kein neues Token erstellen, solange seine eigene Organisation die Zwei-Faktor-Authentifizierung (2FA) verlangt.

So bleibt die Automatisierung sicher und respektiert zugleich das Least-Privilege-Prinzip. Weitere Einzelheiten finden Sie in der Funktionsdokumentation zu API-Tokens.

2FA-Pflicht zusätzlich zu den Rollen

Rollen entscheiden, welche Anlagen Sie erreichen dürfen. Eine Organisation kann eine Bedingung hinzufügen: Sie kann für den Zugriff auf ihre Anlagen die Zwei-Faktor-Authentifizierung (2FA) verlangen.

Eine Rolle gewährt die Anlage. Die Pflicht entscheidet, ob sie Ihnen angezeigt wird. Wenn die Organisation, der eine Anlage gehört, 2FA verlangt und Ihr Konto keinen zweiten Faktor (Authenticator-App oder Passkey) hat, sehen Sie die Anlagen dieser Organisation nicht — egal welche Rolle Sie auf ihnen haben.
Es wird nichts entzogen. Ihre Rollen und Zuweisungen bleiben, wie sie sind. Sie bleiben angemeldet, und ein Hinweis in der Kopfzeile fordert Sie auf, 2FA zu aktivieren. Sobald Sie 2FA aktivieren, sind die Anlagen wieder da.
Der Eigentümer der Anlage entscheidet. Die Pflicht gilt für alle, die die Anlage erreichen: die eigenen Mitglieder der Organisation und die Benutzer eines Kooperationspartners.

Wer die Pflicht festlegt und was genau ausgeblendet wird, ist auf der Seite Sicherheitsrichtlinie der Organisation beschrieben.

System der rollenbasierten Zugriffskontrolle

Mirox verwendet die rollenbasierte Zugriffskontrolle (RBAC) mit vordefinierten Rollen auf drei Achsen: einer plattformweiten Systemrolle, einer Organisationsrolle und ressourcenbezogenen Funktionsrollen.

Systemrollen

Systemrollen definieren die plattformweite Stellung:

Administrator — Plattformpersonal mit Zugriff auf systemweite Operationen und Konfiguration.
Benutzer — Die Standardrolle für alle, die die Plattform nutzen; keine administrativen Rechte.

Demo-Konten

Für Evaluierungskonten existiert zusätzlich eine eingeschränkte Demo-Rolle. Sie verhält sich wie ein normaler Benutzer mit reduzierten Rechten und wird nicht von Ihnen selbst zugewiesen.

Organisationsrollen

Ihre Organisationsrolle ist Ihre Standardstellung innerhalb Ihrer Organisation. Die beiden Manager-Rollen bilden den Kern der aktuellen Berechtigungsstruktur: Sie ermöglichen es Ihnen, leitende Verantwortung zu delegieren, ohne die volle Moderator-Kontrolle abzugeben.

Organisationsrolle	Für wen sie gedacht ist
Admin	Verwaltet jeden Aspekt der Organisation — Mitglieder, Kooperationen, Abrechnung und alle Ressourcen.
Moderator	Führt das Team und die Partnerbeziehungen gemeinsam mit dem Admin — lädt Mitglieder ein und ändert deren Rolle (jede Rolle, auch Admin), verwaltet Kooperationen — sowie alle Ressourcen; nur das Löschen der Organisation selbst bleibt dem Admin vorbehalten.
Asset Manager (Technisch)	Technischer Asset Manager. Führt die Anlagen auf der technischen Seite — Konfiguration, Komponenten, Ereignisse, Tickets und die Anlagennetze per Fernzugriff. Sieht das Team, verwaltet es aber nicht.
Asset Manager (Kaufmännisch)	Kaufmännischer Asset Manager. Führt die Anlagen auf der kaufmännischen Seite — Verträge, Abrechnung, Erlöse und Tarife — mit derselben Konfigurations-, Ereignis- und Ticketbearbeitung wie der technische Manager, aber ohne Fernzugriff auf die Anlagennetze. Sieht das Team, verwaltet es aber nicht.
Mitglied	Standardmitglied mit Lesezugriff auf die Ressourcen der Organisation.
Extern	Eingeschränkte Stellung ohne standardmäßigen Ressourcenzugriff; erreicht Ressourcen nur über explizite Zuweisungen.

Die beiden Manager-Rollen sind gleichrangig — Peers unterhalb des Moderators, einer technisch und einer kaufmännisch. Diese Aufteilung erlaubt es einer einzigen Organisation, die technische Verantwortung sauber von der Verantwortung für Verträge und Abrechnung zu trennen.

Gemeinsame Inhalte der Organisation. Admins, Moderatoren und beide Asset-Manager-Rollen legen die Berichtsvorlagen, Kapitel und Metriken der Organisation, ihre Vorlagen und Formeln im Datenexport sowie die Regeln, Empfänger, Vorlagen und Stummschaltungen des Alarm Managers an, duplizieren, ändern und löschen sie; Mitglieder sehen und nutzen sie. Ein als Privat markiertes Element ändern nur die Person, die es angelegt hat, ein Admin oder ein Moderator — siehe Berichte und Alarm Manager. Direktvermarkter bleiben bei Admins und Moderatoren.

Wer das Team verwaltet

Die Mitgliedschaft verwalten ausschließlich Admins und Moderatoren. Beide laden Mitglieder ein und vergeben jede Rolle — ein Moderator darf auch einen neuen Admin einladen oder befördern. Die beiden Manager-Rollen, Mitglieder und Externe sehen das Team, können aber niemanden einladen, keine Rolle ändern und keine Anlagenberechtigungen vergeben. Admins und Moderatoren sind auch die einzigen, die eine Kooperation anlegen, annehmen, pausieren oder beenden. Nur sie legen die Sicherheitsrichtlinie der Organisation fest.

Funktionsbasierte Ressourcenberechtigungen

Funktionsrollen definieren, was ein Benutzer auf einer bestimmten Anlage oder einem bestimmten Portfolio tun kann, unabhängig von seiner Organisationsrolle:

Funktionsrolle	Zugriff
Betreiber (`operator`)	Vollständiger operativer Zugriff: alles, was die beiden Manager-Rollen haben, plus die dem Eigentümer vorbehaltenen destruktiven Aktionen — Löschen von Komponenten und Tickets.
Technische Betriebsführung (`tom`)	Technische Befugnis über eine Ressource: Konfiguration, Komponenten, Ereignisse (einschließlich Löschen), Tickets und die Netze der Anlage per Fernzugriff.
Kaufmännische Betriebsführung (`com`)	Kaufmännische Befugnis: dieselbe Konfigurations-, Ereignis- und Ticketbearbeitung, plus Erlöszahlen und Tarifeinstellungen — aber kein Fernzugriff auf die Netze der Anlage.
Betrachter (`viewer`)	Schreibgeschützter Zugriff auf die Daten und Leistungskennzahlen einer Ressource.
Sicherheitsbeauftragter (`security_officer`)	Nur Zugriff auf Netzsegmente. Erreicht per Fernzugriff die Netzwerkgeräte der freigegebenen Segmente (Netzwerk-Infrastruktur, Kameras, Sicherheitstechnik) und liest das Zugriffsprotokoll der Anlage. Keine Produktions-, Leistungs- oder kaufmännischen Daten und niemals ein Netz der Anlagensteuerung. Siehe Netzsegmentierung.
Auftraggeber (`observer`)	Nur Betriebsdaten, aktuell und historisch: Produktion, Batterie, Turbinen, Analyse, das Dashboard, Prognose und Marktpreise. Keine Ereignisse, Tickets, Berichte, Exporte, Kontakte, Dateien, Netze oder Finanzdaten und keine Push-Benachrichtigungen zur Anlage. Eine Stufe unter Betrachter.
Keine	Kein Zugriff.

Sicherheitsbeauftragter wird nur direkt vergeben. Keine Organisationsrolle bildet darauf ab — niemand wird durch den Beitritt zu einer Organisation zum Sicherheitsbeauftragten. Die Rolle wird bewusst pro Anlage oder pro Portfolio vergeben oder über eine Kooperation geteilt.

Auftraggeber wird ebenfalls nur direkt vergeben — und ist die einzige Rolle, deren Vergabe ein Konto verengen kann: Vergaben addieren sich, ein Mitglied mit einer Auftraggeber-Vergabe behält also den Betrachter-Zugriff des Mitglieds. Die eingeschränkte Sicht wirkt nur für ein externes Mitglied oder eine Kooperationsfreigabe. Eine Auftraggeber-Vergabe kann ein Ablaufdatum tragen.

Der Bezeichner in Klammern ist die Kennung, die in API-Zuweisungen und Kooperationsfreigaben verwendet wird; überall in der Oberfläche sehen Sie die ausführliche Bezeichnung.

API-Berechtigungsgruppen

API-Tokens werden genau einer Berechtigungsgruppe zugewiesen, die einschränkt, worauf der Token zugreifen kann:

Full Access — Dieselben Berechtigungen wie der erstellende Benutzer, innerhalb seines Geltungsbereichs.
Metric Export — Beschränkt auf das Lesen des Datenexports: Metriken als Zeitreihe, Exportvorlagen, der Metrikkatalog, Anlageninformationen und Ereignisse. Er kann nichts ändern.
Timeseries Database — Zugriff auf die Zeitreihen-Endpunkte zum Lesen der rohen Messreihen.

Anwendungsfälle und Beispiele finden Sie in der Funktionsdokumentation zu API-Tokens.

Berechtigungsvererbung

Der Zugriff fließt die Ressourcenhierarchie hinab, sodass Sie weit oben gewähren und weiter unten verfeinern:

Organisation
├── Organisationsrolle (Ihre Standardstellung)
│
├── Portfolio 1
│   ├── Erbt Zugriff auf Organisationsebene
│   ├── Portfolio-spezifische Zuweisungen (optional)
│   │
│   ├── Park A
│   │   ├── Erbt Portfolio-Zugriff
│   │   └── Park-spezifische Zuweisungen (optional)
│   │
│   └── Park B
│       ├── Erbt Portfolio-Zugriff
│       └── Park-spezifische Zuweisungen (optional)
│
└── Portfolio 2
    └── Park C
        └── Erbt Portfolio-Zugriff

Dieses Vererbungsmodell bedeutet:

Der Zugriff aus Ihrer Organisationsrolle gilt für alle Portfolios und Parks, die Ihrer Organisation gehören.
Eine Zuweisung auf Portfolioebene gilt für jeden Park in diesem Portfolio.
Eine Zuweisung auf einem einzelnen Park verfeinert den Zugriff nur für diesen Park und überschreibt den vererbten Standard.

Zuordnung von Organisationsrolle zu Funktionsrolle

Wenn Sie auf eine Ressource zugreifen, bestimmt Ihre Organisationsrolle automatisch Ihre Standard-Funktionsrolle:

Organisationsrolle	Standard-Funktionsrolle
Admin	Betreiber (vollständige Ressourcenverwaltung)
Moderator	Betreiber (vollständige Ressourcenverwaltung)
Asset Manager (Technisch)	Technische Betriebsführung (technische Befugnis)
Asset Manager (Kaufmännisch)	Kaufmännische Betriebsführung (kaufmännische Befugnis)
Mitglied	Betrachter (schreibgeschützter Zugriff)
Extern	Keine (kein standardmäßiger Ressourcenzugriff)

Diese Trennung hält Ressourcenberechtigungen (Funktionsrollen) von der organisatorischen Stellung getrennt. Ihre Organisationsrolle legt den Standard fest, aber explizite ressourcenbezogene Zuweisungen können ihn für jede einzelne Anlage anheben oder absenken.

Kaufmännische vs. technische Befugnis

Die beiden Manager-Rollen werden zwei verschiedenen Funktionsrollen zugeordnet, die auf derselben Stufe stehen. Beide konfigurieren die Anlage, bearbeiten Ereignisse (einschließlich Löschen) und arbeiten an Tickets — erstellen, bearbeiten, schließen, wieder öffnen. Was sie unterscheidet: Die Technische Betriebsführung erreicht die Netze der Anlage per Fernzugriff (VPN, Browser-Proxy) und bearbeitet Grafana-Dashboards; die Kaufmännische Betriebsführung sieht Erlöszahlen und bearbeitet Tarif- und Markteinstellungen. Keine der beiden löscht Komponenten oder Tickets — das bleibt beim Betreiber, also bei Admins und Moderatoren.

Organisationskooperation

Organisationen können Kooperationsvereinbarungen eingehen, um bestimmte Ressourcen über die Organisationsgrenze hinweg zu teilen:

Zwei Organisationen schließen eine formelle Kooperation.
Die ressourcenbesitzende Organisation gewährt bestimmten Zugriff über Funktionsrollen.
Was auf Kooperationsebene geteilt wird, begrenzt das, was die empfangende Organisation anschließend an ihre eigenen Mitglieder delegieren kann.
Jeder Zugriff bleibt nachvollziehbar und kann vom Ressourcenbesitzer jederzeit widerrufen werden.

Automatischer Zugriff nur für den Admin

Nur ein Admin der empfangenden Organisation erreicht geteilte Ressourcen automatisch. Alle anderen in dieser Organisation — Moderatoren, die beiden Asset-Manager-Rollen, Mitglieder und Externe — erreichen eine geteilte Anlage erst, nachdem dieser Admin sie an sie delegiert hat. Ein Mitglied mit einer solchen Delegation arbeitet auf der geteilten Anlage, mit der Rolle, die es erhalten hat.

Verlangt die Organisation, der eine geteilte Anlage gehört, 2FA, gilt das auch für den empfangenden Admin und für jedes delegierte Mitglied — siehe 2FA-Pflicht zusätzlich zu den Rollen.

Die vollständigen Regeln dazu, wie geteilter Zugriff begrenzt und delegiert wird, finden Sie unter Kooperationsbeschränkungen.

Bewährte Vorgehensweisen

Für eine effektive Berechtigungsverwaltung in Mirox:

Verwenden Sie die Standardrollen — Die vordefinierten Organisations- und Funktionsrollen decken die große Mehrheit der realen Situationen ab.
Passen Sie den Manager zur Verantwortung an — Verwenden Sie die Rolle Asset Manager (Technisch) für die technische Verantwortung und die Rolle Asset Manager (Kaufmännisch) für die Verantwortung über Verträge und Abrechnung.
Weisen Sie auf der höchsten geeigneten Ebene zu — Gewähren Sie auf Organisations- oder Portfolioebene, wenn der Zugriff weitreichend gelten soll; verfeinern Sie nur bei echten Ausnahmen auf Parkebene.
Überprüfen Sie regelmäßig — Auditieren Sie Mitgliederrollen und ressourcenbezogene Zuweisungen in regelmäßigen Abständen und setzen Sie Ablaufdaten für zeitlich befristeten Zugriff.
Verifizieren Sie den Zugriff — Bestätigen Sie eine Konfiguration, indem Sie prüfen, was ein bestimmtes Mitglied tatsächlich erreichen kann, bevor Sie sich darauf verlassen.

Praktische Beispiele

Verwaltung mehrerer Standorte

Eine Organisation, die mehrere Solarparks verwaltet, könnte Folgendes einrichten:

Einen operativen Leiter als Admin mit voller Kontrolle über die Organisation.
Einen technischen Verantwortlichen als Asset Manager (Technisch), der über alle Anlagen hinweg den Komponentenzustand, Ereignisse und Tickets betreut.
Einen Finanzverantwortlichen als Asset Manager (Kaufmännisch), der Verträge, Abrechnung und Tarife verwaltet, ohne jeglichen Fernzugriff auf die Anlagennetze.

Dienstleisterzugriff

Ein von außen eingeladener Wartungsdienstleister könnte Folgendes erhalten:

Eine Organisationsrolle Extern mit einer Funktionsrolle Technische Betriebsführung oder Betrachter auf den konkreten Parks, die er betreut.
Eine ressourcenbezogene Zuweisung, die nur auf diese Anlagen beschränkt ist.
Ein Ablaufdatum, sodass der Zugriff automatisch endet, wenn der Auftrag endet.

Investorentransparenz

Investoren können Folgendes erhalten:

Eine Organisationsrolle Mitglied oder Extern mit einer Funktionsrolle Betrachter auf bestimmten Portfolios.
Lesezugriff auf Leistungs- und Berichtsdaten, ohne Verwaltungsfunktionen.