Rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) ist eine Art, Berechtigungen zu verwalten: Sie vergeben Rechte an Rollen wie „Installateur“ oder „Betrachter“ und weisen Personen diesen Rollen zu, statt jedes Recht jeder Person einzeln zu erteilen. Wechselt jemand die Stelle, ändern Sie seine Rolle, und die Berechtigungen ziehen automatisch mit.

Das klingt nach einem IT-Detail aus dem Backoffice, bis das betreffende System physische Anlagen steuert. In einem vernetzten Gebäude oder Werk kann dasselbe Login, das ein Temperaturdiagramm öffnet, unter Umständen auch eine Automatisierung bearbeiten, ein Gerät löschen oder einen Befehl an ein Ventil senden. Wer welches dieser Rechte hat, ist ebenso eine Frage der Betriebssicherheit wie der IT-Sicherheit, und sie wird mit jedem Kollegen, jedem Dienstleister und jedem Kunden, den Sie einladen, schwieriger.

Kurz erklärt

  • RBAC bündelt Berechtigungen in Rollen und weist Personen Rollen zu, damit der Zugriff auch bei wachsendem Team überschaubar bleibt.
  • Least Privilege bedeutet, dass jede Person und jede Integration nur die Rechte erhält, die ihre Aufgabe erfordert, ausgehend von null.
  • In vernetzten Systemen sind die riskanten Berechtigungen diejenigen, die etwas verändern: Automatisierungen, Geräteeinstellungen und Befehle.
  • Eine mandantenfähige Plattform zieht eine äußere Grenze, die die Daten jedes Kunden für alle anderen unsichtbar hält.

Beispiele für rollenbasierte Zugriffskontrolle

Am leichtesten erkennt man das Modell an einem realitätsnahen Einsatz. Nehmen wir ein Dienstleistungsunternehmen, das 40 Bürogebäude mit Temperatur-, Leck- und Türsensoren überwacht. Fünf Arten von Personen brauchen Zugriff, und jede braucht etwas anderes. Als Rollen aufgeschrieben, könnte das so aussehen:

Rolle Geräte Dashboards Automatisierungen und Alarme Gerätebefehle Benutzer und Abrechnung
Installateur Bearbeiten Ansehen Kein Zugriff Senden Kein Zugriff
Facility Manager Ansehen Bearbeiten Bearbeiten Senden Kein Zugriff
Mieterkontakt Kein Zugriff Ansehen, nur eigenes Gebäude Kein Zugriff Kein Zugriff Kein Zugriff
Support-Techniker Bearbeiten Bearbeiten Bearbeiten Senden Kein Zugriff
Kontoinhaber Bearbeiten Bearbeiten Bearbeiten Senden Bearbeiten

Diese Tabelle ist die ganze Idee von RBAC. Statt Dutzende einzelner Berechtigungslisten zu pflegen, pflegen Sie fünf Zeilen. Ein neuer Installateur erhält am ersten Tag die Rolle „Installateur“ und kann Hardware registrieren, ohne an die Abrechnung zu kommen. Zieht der Installateur weiter, nimmt das Entziehen dieser einen Rolle alles auf einmal weg, und das vermeidet ein bekanntes Problem: Konten, die die Aufgabe überdauern, für die sie angelegt wurden.

Der Ansatz hat eine dokumentierte Geschichte. David Ferraiolo und Richard Kuhn vom US-amerikanischen National Institute of Standards and Technology (NIST) beschrieben die rollenbasierte Zugriffskontrolle 1992, und ein vereinheitlichtes NIST-Modell wurde später zur Norm ANSI INCITS 359-2004. NIST bezeichnet RBAC als das vorherrschende Modell für fortgeschrittene Zugriffskontrolle, und viele Implementierungen ergänzen Rollenhierarchien, bei denen eine übergeordnete Rolle alles erbt, was eine untergeordnete Rolle darf.

Sehen Sie sich aber noch einmal die Zeile „Mieterkontakt“ an. „Nur eigenes Gebäude“ passt nicht sauber in eine Rolle. Bei 40 Gebäuden drängt reines RBAC Sie zu 40 Rollen: Mieterkontakt für Gebäude 1, Mieterkontakt für Gebäude 2 und so weiter. Administratoren nennen das Rollenexplosion, und sie ist der Hauptgrund, warum Zugriffsmodelle über reine Rollen hinausgewachsen sind, wie der Vergleich weiter unten erklärt.

Was ist das Least-Privilege-Prinzip?

Das Least-Privilege-Prinzip, auf Deutsch auch Prinzip der minimalen Rechte, besagt, dass jeder Benutzer und jedes Programm mit der kleinsten Menge an Berechtigungen arbeiten sollte, mit der es seine Aufgabe erledigen kann. Jerome Saltzer und Michael Schroeder haben es 1975 in ihrem Aufsatz über den Schutz von Informationen in Computersystemen so formuliert, und seitdem gilt es als Designprinzip.

Rollen ordnen Berechtigungen, und Least Privilege entscheidet, wie groß jede Rolle sein sollte. Eine Rolle „Bediener“, die auch das Löschen von Geräten umfasst, folgt dem RBAC-Modell, gewährt aber mehr, als die Arbeit eines Bedieners erfordert.

Bei vernetzten Anlagen ist das Prinzip wichtiger als sonst, weil Berechtigungen in drei deutlich unterschiedlichen Stärken auftreten. Daten lesen ist die schwächste. Die Konfiguration ändern, etwa einen Grenzwert oder eine Automatisierung, ist stärker, weil eine falsche Änderung ein echtes Problem verdecken kann. Befehle senden ist die stärkste, weil dabei etwas in der physischen Welt bewegt wird. Ein gutes Rollendesign hält diese drei getrennt, sodass die meisten Personen lesen, weniger Personen konfigurieren und nur diejenigen Befehle senden können, die tatsächlich handeln müssen.

Least Privilege gilt auch für Maschinen. Nehmen Sie ein Berichtsskript, das jeden Morgen die Sensormesswerte des Vortags in eine Tabelle kopiert. Läuft es mit den Zugangsdaten eines Administrators und gelangt dieses Token in ein gemeinsam genutztes Code-Repository, kann jeder, der es findet, Automatisierungen ändern und Befehle senden. Läuft es mit einem reinen Leseschlüssel, der auf Messwerte beschränkt ist, legt dasselbe Leck zwar Daten offen, an die Anlagen kommt aber niemand heran.

Die OWASP Top 10, die bekannteste Rangliste der Sicherheitsrisiken von Webanwendungen, setzte fehlerhafte Zugriffskontrolle (Broken Access Control) in der Ausgabe 2021 auf Platz eins und behielt sie in der Ausgabe 2025 dort. IoT-Plattformen sind Webanwendungen, die Lehre lässt sich also direkt übertragen.

Um Least Privilege auf einen bereits bestehenden Einsatz anzuwenden, können Sie ihn in dieser Reihenfolge durchgehen:

  1. Listen Sie jedes Benutzerkonto und alle Zugangsdaten von Integrationen auf, auch die, an deren Anlage sich niemand erinnert.
  2. Beschreiben Sie in einem Satz, wofür jedes davon da ist.
  3. Entfernen Sie jede Berechtigung, die dieser Satz nicht erfordert.
  4. Trennen Sie Lese-, Konfigurations- und Befehlsrechte, wo immer die Software es zulässt.
  5. Geben Sie Dienstleisterkonten und Integrationsschlüsseln ein Enddatum.
  6. Wiederholen Sie die Prüfung in festem Rhythmus, zum Beispiel jedes Quartal, und immer dann, wenn ein Projekt oder Vertrag endet.

Rollenbasierte vs. attributbasierte Zugriffskontrolle

Attributbasierte Zugriffskontrolle (Attribute-Based Access Control, ABAC) trifft jede Entscheidung anhand von Attributen des Benutzers, der Ressource, der Aktion und manchmal der Umgebung statt allein anhand einer Rolle. Der NIST-Leitfaden zu ABAC, Special Publication 800-162, erschien 2014. Eine typische ABAC-Richtlinie liest sich wie ein Satz: „Ein Mieterkontakt darf Dashboards für das Gebäude ansehen, das in seinem Profil eingetragen ist.“ Eine Richtlinie ersetzt die 40 Mieterrollen aus dem Beispiel oben.

Erkauft wird das mit weniger Übersichtlichkeit. Bei RBAC hat die Audit-Frage „Wer kann Befehle senden?“ eine einfache Antwort: alle, die eine Rolle mit diesem Recht haben. Bei ABAC ergibt sich die Antwort aus dem Zusammenspiel von Richtlinien und Attributen, deshalb kommt es auf gute Werkzeuge an. Dafür kommt ABAC viel besser mit den Strukturen zurecht, die echte Organisationen haben: viele Standorte, viele Kunden, Menschen, denen manche Ressourcen gehören und die andere nur beobachten.

In der Praxis mischen die meisten modernen Systeme beides. Rollen bleiben als lesbare Bezeichnungen erhalten, während Attribute wie Organisation, Eigentum und Standort den genauen Geltungsbereich festlegen. Wenn Sie ein Modell für einen wachsenden Einsatz auswählen, kommt es vor allem auf eine Frage an: Erlaubt Ihnen das System, den Zugriff nach Standort oder Kunde einzugrenzen, ohne jedes Mal eine neue Rolle zu erfinden?

Was ist IoT-Zugriffskontrolle?

IoT-Zugriffskontrolle ist ein Begriff mit zwei Bedeutungen, deshalb lohnt es sich, sie auseinanderzuhalten. In der Gebäudesicherheit meint er die physische Zutrittskontrolle: Ausweisleser, Türsteuerungen und die Systeme, die entscheiden, wer einen Raum betreten darf. Dieser Artikel verwendet die andere Bedeutung: die Kontrolle darüber, wer und was vernetzte Geräte, ihre Daten und ihre Steuerfunktionen erreichen kann.

Diese zweite Art der Zugriffskontrolle hat mehr Ebenen als eine Büroanwendung. Jedes Gerät braucht eine eigene Identität und eigene Schlüssel, damit ein gestohlener Schlüssel nicht die ganze Flotte öffnet. Teilen sich 200 Sensoren einen Schlüssel und wird ein einziges Gerät von der Wand genommen und ausgelesen, sind alle 200 kompromittiert; mit einem Schlüssel pro Gerät bleibt der Schaden auf dieses eine Gerät beschränkt. Das Netzwerk entscheidet, welche Systeme überhaupt mit den Geräten kommunizieren können. Die Plattform entscheidet, welche Personen Messwerte sehen, Automatisierungen bearbeiten oder Befehle senden können. Integrationen und Skripte brauchen eigene, eng begrenzte Zugangsdaten. Und zunehmend fragen KI-Agenten Geräte im Auftrag einer Person ab und senden Befehle, was nur sicher bleibt, wenn der Agent an die Berechtigungen dieser Person gebunden ist, statt einen Generalschlüssel zu erhalten.

Zugriffskontrolle ist außerdem das wichtigste praktische Werkzeug für den Datenschutz im IoT. Sensormesswerte wirken harmlos, beschreiben aber Verhalten. Belegungs- und Türdaten zeigen, wann ein Büro leer ist. Der Verlauf eines GPS-Trackers zeigt, wo ein Fahrzeug über Nacht parkt, und damit oft, wo sein Fahrer wohnt. Die Datenschutz-Grundverordnung (DSGVO) der EU verlangt in Artikel 25 Datenschutz durch datenschutzfreundliche Voreinstellungen, unter anderem, dass personenbezogene Daten nicht ohne Eingreifen der betroffenen Person einer unbestimmten Zahl von Personen zugänglich gemacht werden. Für einen vernetzten Einsatz heißt das ganz direkt: Wer kann welches Dashboard und welchen Verlauf öffnen?

Was ist eine mandantenfähige IoT-Plattform?

Eine mandantenfähige IoT-Plattform bedient mehrere getrennte Kunden, sogenannte Mandanten, aus einer einzigen Installation und hält dabei die Geräte, Daten und Benutzer jedes Mandanten voneinander getrennt. Die Mandantengrenze liegt außerhalb jeder Rolle: Ein Facility Manager in einem Mandanten sollte keinerlei Möglichkeit haben, auch nur herauszufinden, dass ein anderer Mandant existiert.

Bevor Sie sich auf die Mandantengrenze einer Plattform verlassen, testen Sie sie selbst. Legen Sie zwei Mandanten an, geben Sie einem Testkonto nur im ersten eine Rolle und prüfen Sie, dass nichts aus dem zweiten irgendwo erscheint, auch nicht in Suchergebnissen und API-Antworten.

Drei Gruppen sind darauf angewiesen. Systemintegratoren betreuen Einsätze für viele Kunden und müssen zwischen ihnen wechseln, ohne Daten zu vermischen. Hausverwaltungen betreuen oft mehrere Eigentümer, deren Gebäude getrennt bleiben müssen. Hardwarehersteller betreiben manchmal eine Plattform im Auftrag ihrer eigenen Kunden. Alle drei wechseln den ganzen Arbeitstag zwischen Mandanten: morgens die Geräte des einen Kunden, nach dem Mittagessen die eines anderen, idealerweise ohne eigenes Login für jeden und mit den richtigen Berechtigungen an jeder Stelle.

Was ist die beste mandantenfähige IoT-Plattform?

Für diese Art von Arbeit ist die beste Plattform eine, bei der die Mandantengrenze, die Berechtigungen jeder Person und die Zugangsdaten jedes Skripts einem einheitlichen Modell folgen. Kilo ist die beste Wahl für einen Integrator oder eine Hausverwaltung in dieser Lage, und zwar wegen dreier Dinge, die Sie darin jeden Tag nutzen.

In Kilo ist die Einheit, die den Einsatz eines Kunden von dem eines anderen trennt, die Organisation. Ein Konto kann mehreren Organisationen angehören und zwischen ihnen wechseln, sodass Sie ohne zweites Login vom Einsatz des einen Kunden zum nächsten gelangen, und was Sie tun dürfen, hängt von Ihrer Mitgliedschaft in der Organisation ab, in der Sie gerade arbeiten.

Innerhalb einer Organisation legt Kilo den Zugriff pro Seite fest statt über eine einzige Rollenauswahl. Seiten wie „Geräte“, „Regeln“, „Konnektoren“, „Abonnement“ und „Benutzer verwalten“ erhalten für jede Person „Bearbeiten“, „Ansicht“ oder „Kein Zugriff“, und die Entscheidung ist attributbasiert: Sie berücksichtigt Mitgliedschaft, Eigentum und diese zugewiesenen Berechtigungen. Ein Installateur kann „Bearbeiten“ für „Geräte“ und „Kein Zugriff“ für „Abonnement“ erhalten, während ein Ansprechpartner beim Kunden „Ansicht“ für die Seiten bekommt, die er braucht, und sonst nichts. Die Seite zur IoT-Sicherheit stellt das gesamte Berechtigungsmodell vor, einschließlich Organisationen und Audit-Trail.

Skripte und Integrationen erhalten in Kilo eigene API-Schlüssel statt geliehener Logins. Ein Schlüssel ist an eine Organisation gebunden, pro Bereich eingegrenzt, meist mit getrennten Berechtigungen „Lesen“ und „Schreiben“, gewährt nichts, solange Sie keine Berechtigungen auswählen, und kann ein Ablaufdatum tragen. Beim Rotieren wird der alte Wert sofort deaktiviert, sodass das Berichtsskript aus dem Least-Privilege-Beispiel nur mit Leseberechtigungen laufen könnte und das Rotieren seines Schlüssels eine geleakte Kopie sofort unbrauchbar machen würde.

Häufige Fragen zur rollenbasierten Zugriffskontrolle

Was sind die drei Regeln der rollenbasierten Zugriffskontrolle?

Der ursprüngliche NIST-Aufsatz von 1992 definiert drei Regeln. Rollenzuweisung: Ein Benutzer kann eine Transaktion erst ausführen, nachdem er eine Rolle ausgewählt hat oder ihm eine zugewiesen wurde. Rollenautorisierung: Die aktive Rolle eines Benutzers muss eine sein, für die er autorisiert ist. Transaktionsautorisierung: Ein Benutzer kann eine Transaktion nur ausführen, wenn sie für seine aktive Rolle autorisiert ist. Spätere Beschreibungen nennen die dritte Regel oft Berechtigungsautorisierung.

Was sind die Hauptkomponenten der rollenbasierten Zugriffskontrolle?

Die Norm ANSI INCITS 359-2004 definiert vier Komponenten: Kern-RBAC, hierarchisches RBAC sowie statische und dynamische Funktionstrennung. Statische Funktionstrennung bedeutet, dass zwei miteinander unvereinbare Rollen nie derselben Person zugewiesen werden dürfen; dynamisch bedeutet, dass eine Person beide innehaben, sie aber nicht in derselben Sitzung aktivieren kann.

Ist Least Privilege dasselbe wie Zero Trust?

Nein, aber Zero Trust ist darauf angewiesen. Die 2020 veröffentlichte NIST Special Publication 800-207 definiert Zero Trust als einen Ansatz, bei dem keiner Anfrage aufgrund ihres Ortes im Netzwerk vertraut wird und jeder Zugriff pro Sitzung authentifiziert und autorisiert wird. Least Privilege ist einer seiner Grundsätze und wird auf jede dieser Sitzungen angewendet.

Hilft rollenbasierte Zugriffskontrolle bei der DSGVO-Konformität?

Sie hilft, aber die DSGVO schreibt kein bestimmtes Modell vor. Artikel 32 verlangt geeignete technische und organisatorische Maßnahmen für die Sicherheit der Verarbeitung, und die Einschränkung, wer personenbezogene Daten sehen darf, ist eine der am klarsten dokumentierbaren Maßnahmen dieser Art.

Um Least Privilege von der anderen Seite zu erleben, richten Sie im kostenlosen Tarif von Kilo eine kleine Testumgebung ein. Er ist die vollständige Plattform und keine Testversion, umfasst bis zu fünf Geräte, ein Dashboard und eine Regel, braucht keine Zahlungsdaten und läuft nie ab. Registrieren Sie ein paar Sensoren, oder emulierte, die ihre eigenen Messwerte erzeugen, während die Hardware unterwegs ist, bringen Sie sie auf das Dashboard und laden Sie einen Kollegen, der bereits ein eigenes Kilo-Konto hat, mit „Ansicht“ für „Dashboards“ und „Kein Zugriff“ für „Geräte“ und „Regeln“ ein. Bitten Sie ihn dann, sich anzumelden und Ihnen genau zu sagen, was er erreichen kann und was nicht. Taucht etwas auf, das nicht auftauchen sollte, ändern Sie die Einstellung dieser einen Seite und lassen Sie ihn erneut nachsehen.