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:

1. Hierarchische Vererbung — Der Zugriff folgt der natürlichen Hierarchie von Ressourcen und Organisationen: einmal weit oben vergeben, und er fließt nach unten.
2. Least Privilege — Jede Rolle trägt nur die Rechte, die ihre Aufgabe tatsächlich benötigt.
3. 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.
4. Explizite Zuweisung — Zugriff wird bewusst gewährt, niemals vorausgesetzt.
5. 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).

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

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.

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.

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.

Funktionsbasierte Ressourcenberechtigungen

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

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.
• Reporting — Beschränkt auf Berichtsfunktionen: Berichte erstellen und Daten exportieren.
• Timeseries Database — Zugriff auf die Zeitreihen-Endpunkte für den programmatischen Datenabruf mit MiroxQL.

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:

1. Der Zugriff aus Ihrer Organisationsrolle gilt für alle Portfolios und Parks, die Ihrer Organisation gehören.
2. Eine Zuweisung auf Portfolioebene gilt für jeden Park in diesem Portfolio.
3. 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:

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.

Organisationskooperation

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

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

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:

1. Verwenden Sie die Standardrollen — Die vordefinierten Organisations- und Funktionsrollen decken die große Mehrheit der realen Situationen ab.
2. 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.
3. 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.
4. Ü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.
5. 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 und Abrechnung verwaltet, ohne die technische Konfiguration anzufassen.

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.

Verwandte Funktionen

• Kooperationsbeschränkungen — wie geteilter Zugriff zwischen kooperierenden Organisationen begrenzt wird
• Kooperationen — Anlagen und Portfolios über die Organisationsgrenze hinweg teilen
• Einladungen — Mitglieder einladen und ihnen ihre Organisationsrolle zuweisen
• API-Tokens — eingeschränkte Tokens für Automatisierung und Integrationen
• Audit-Log — wer wann auf welche Anlagengeräte zugegriffen hat
• Tickets — die menschliche Arbeitsverwaltungsschicht, die durch die Funktionsrolle gesteuert wird