Datenschutzeinstellungen

Sie entscheiden, ob wir PostHog nutzen dürfen, um diese Website zu verbessern. Sie können Ihre Auswahl jederzeit ändern.

Notwendige Funktionen · immer aktiv

Wir speichern Ihre Datenschutzauswahl, damit wir sie bei weiteren Besuchen berücksichtigen können.

Ihre Auswahl können Sie jederzeit über „Datenschutzeinstellungen“ im Footer ändern oder widerrufen. Datenschutzhinweise

urbanOS
urbanOS
Alle Beiträge

Zugriffsrechte für kommunale Sensordaten richtig zuschneiden

Ein Rollenmodell für Kommunen, das Aufgaben, Datenräume, Handlungen und Laufzeiten verbindet und interne Wechsel sowie Dienstleisterzugänge prüfbar macht.

Taktile Schichten aus Transparentpapier mit getrennten Sensorbereichen, passenden Schlüsseln und einem Zeitfenster für Zugriffsrechte
Die zentrale Frage

Wie legt eine Kommune Zugriffsrechte für Sensordaten fest, damit Fachämter, Dienstleister und Öffentlichkeit nur die Daten und Funktionen erhalten, die sie für ihre Aufgabe brauchen?

Am Montag wechselt eine Mitarbeiterin aus dem Grünflächenamt in die Vergabestelle. Ihr alter Zugang zeigt weiterhin Bodenfeuchtewerte, exportiert Messreihen und darf Warnschwellen ändern. Am Dienstag erhält ein externer Wartungsbetrieb ein Sammelkonto für drei Wasserstandssensoren. Das Konto sieht zusätzlich Park- und Besucherfrequenzdaten. Beide Zugänge funktionieren technisch. Organisatorisch sind sie zu weit.

Eine Kommune sollte Zugriffsrechte aus der konkreten Aufgabe ableiten und jedes Recht mit vier Angaben versehen: Datenraum, erlaubte Handlung, Gültigkeitszeit und Freigabeverantwortung. Lesen, Exportieren, Konfigurieren, Schalten und Administrieren gehören in getrennte Rechte. Interne Wechsel, Projektenden und Dienstleisteraufträge lösen eine erneute Prüfung aus. So entsteht ein Rollenmodell, das den Arbeitsprozess unterstützt und unnötige Zugänge begrenzt.

Ein Zugriffsrecht braucht vier Koordinaten

Eine Stellenbezeichnung reicht als Rollenbeschreibung nicht aus. Zwei Beschäftigte im Bauhof können denselben Titel tragen, obwohl nur eine Person Schwellenwerte freigibt. Ein Dienstleister benötigt Diagnosedaten für bestimmte Geräte, aber weder den Export ganzer Zeitreihen noch Zugriff auf andere Fachbereiche. Die Fachverantwortlichen beschreiben deshalb zuerst die Aufgabe und ordnen anschließend technische Rechte zu.

Ein kommunales Zugriffsrecht ist vollständig beschrieben, wenn es eine Aufgabe, einen abgegrenzten Datenraum, erlaubte Handlungen und eine Gültigkeitsdauer verbindet. Fehlt eine dieser vier Koordinaten, kann die Kommune später weder den Bedarf noch den Entzug des Rechts sauber prüfen. Das BSI-Modul ORP.4 zum Identitäts- und Berechtigungsmanagement verlangt Rechte nach tatsächlichem Bedarf und Aufgabenerfüllung, den Entzug nicht mehr benötigter Rechte sowie getrennte administrative Rollen.

Der Datenraum kann ein Projekt, ein Quartier, ein Sensortyp oder eine benannte Gruppe von Anlagen sein. Die Gültigkeit kann an eine Stelle, einen Auftrag oder ein Enddatum gebunden sein. Die verantwortliche Fachstelle bestätigt den fachlichen Bedarf. IT setzt die Rolle um. Informationssicherheit prüft besonders weitreichende Kombinationen.

Die Rechte-Matrix beginnt mit echten Arbeitsaufträgen

Ein Workshop mit fünf Beispielaufträgen liefert mehr als eine Liste abstrakter Rollen. Die Beteiligten spielen einen normalen Vorgang je Nutzergruppe durch und markieren jeden notwendigen Schritt.

Nutzergruppe Arbeitsauftrag Datenraum Benötigte Handlungen Klare Grenze
Leitstelle Alarm prüfen und zuständige Stelle informieren ausgewählte kritische Messstellen lesen, Alarmstatus setzen, Verlauf ansehen keine Schwellen ändern, keine Nutzer verwalten
Fachverantwortung Messqualität bewerten und Monatsauswertung erstellen eigener Fachbereich lesen, exportieren, Qualitätsstatus pflegen keine fremden Projekte, keine Plattformadministration
Außendienst Auftrag am Standort bearbeiten zugewiesene Anlagen aktuelle Werte und Standortinformationen lesen kein Massenexport, keine historischen Fremddaten
Wartungsdienstleister Störung an benannten Geräten diagnostizieren Vertragsgeräte Diagnose lesen, Wartungsnotiz ergänzen befristet, kein Zugriff auf andere Datenräume
Plattformadministration Konten, Gruppen und technische Konfiguration pflegen Plattformverwaltung Identitäten und Rechte verwalten kein routinemäßiger Fachdatennutzer

Das BSI beschreibt in seinen Umsetzungshinweisen einen Abgleich zwischen Aufgabenprofil, Rollen und tatsächlich zugeordneten Berechtigungen. Fachverantwortliche schneiden die Rollen fachlich zu, während die administrative Ebene die Rechteprofile technisch pflegt. Dieses Vier-Augen-Verhältnis verhindert, dass IT den fachlichen Bedarf erraten muss.

Lesen, Exportieren, Konfigurieren und Schalten haben verschiedene Folgen

Ein Leserecht zeigt einen Wert. Ein Export kann tausende Werte aus dem kontrollierten Arbeitsraum herauslösen. Eine Schwellenänderung verändert, welche Alarme das Betriebsteam erhält. Ein Schaltrecht wirkt auf einen Aktor. Ein Administrationsrecht kann weitere Zugänge erzeugen. Die Rechte-Matrix trennt diese Wirkungen, auch wenn eine Anwendung sie in einem Menü bündelt.

Die risikogerechte Regel für kommunale Sensordaten lautet: Je weiter eine Handlung über den eigenen Arbeitsfall hinauswirkt, desto enger werden Datenraum, Laufzeit, Authentisierung, Protokollierung und Freigabe. Ein Leserecht für einen Standort kann dauerhaft gelten. Ein befristetes Schalt- oder Administrationsrecht braucht eine benannte Person, einen Anlass und eine nachvollziehbare Kontrolle. Die NCSC-Leitlinie für vernetzte Orte empfiehlt für privilegierte Zugriffe geringste Rechte, starke Authentisierung, autorisierte Geräte sowie zeitlich und sachlich begrenzte Berechtigungen.

Bei personenbezogenen Daten kommt eine rechtliche Prüfung hinzu. Artikel 32 der Datenschutz-Grundverordnung verlangt ein dem Risiko angemessenes Sicherheitsniveau und Maßnahmen gegen unbefugte Offenlegung oder Zugriffe. Artikel 32 Absatz 4 bindet Personen mit Zugang an die Weisungen des Verantwortlichen oder Auftragsverarbeiters. Die Datenschutzbeauftragte beurteilt den konkreten Datenfluss. Ein Rollenmodell ersetzt weder Rechtsgrundlage noch Datenschutz-Folgenabschätzung.

Externe Zugänge erhalten Auftrag, Eigentümer und Ablaufdatum

Gemeinsame Konten sparen beim Start wenige Minuten und zerstören später die Zuordnung. Jede externe Person und jedes technische System braucht eine eigene Identität. Der Vertragspartner benennt die Person, die Kommune bestätigt den Auftrag, und ein internes Team übernimmt die Verantwortung für Freigabe und Entzug.

Der Zugangssatz enthält sechs Felder: Auftrag, betroffene Anlagen, erlaubte Handlungen, Start, Ablauf und interner Eigentümer. Ein Wartungsfenster kann zwölf Stunden gelten. Ein mehrmonatiger Betriebsauftrag erhält ein Enddatum und einen Prüftermin. Dauerzugänge ohne überprüfbaren Zweck gehören nicht in die Standardrolle.

Die NCSC-Einführung in Identity and Access Management verbindet Zugänge mit geprüften Identitäten, angemessener Authentisierung, geringsten Rechten sowie einem Prozess für Eintritt, Wechsel und Austritt. Sie nennt externe Wartung ausdrücklich als Fall, bei dem die Organisation die Identitätsprüfung des Auftragnehmers bewerten muss. Die Kommune übernimmt diese Aufgabe in ihren Dienstleisterprozess, statt dem Anbieter die gesamte Entscheidung zu überlassen.

Technische Konten brauchen denselben Eigentümer. Eine API-Integration erhält nur die Endpunkte und Datenräume, die ihr Prozess benötigt. Schlüsselrotation, Ablauf und Nutzung erscheinen im Betriebsprotokoll. Ein nicht mehr zugeordnetes Systemkonto wird gesperrt, auch wenn es noch Daten abruft.

Kleine Grundrollen begrenzen den Wildwuchs

Ein Rollenmodell wird unprüfbar, wenn jede Ausnahme eine neue Dauerrolle erzeugt. Die Kommune beginnt mit wenigen Grundrollen wie Lesen, Fachbetrieb, Freigabe und Administration. Datenraum und Laufzeit werden separat zugeordnet. Zeitlich begrenzte Zusatzrechte bleiben als Ausnahme sichtbar.

Das NIST-Kontrollwerk SP 800-53 Revision 5 formuliert für geringste Rechte, dass Nutzer und Prozesse nur die Zugänge erhalten, die sie für zugewiesene Aufgaben benötigen. Es nennt zusätzliche Prozesse, Rollen und Konten als mögliche Mittel. Für die kommunale Praxis folgt daraus keine Pflicht zu einem bestimmten Produkt. Die Beschaffung muss jedoch prüfen, ob das System Datenräume und Handlungen ausreichend getrennt abbildet.

Eine problematische Kombination entsteht etwa, wenn dieselbe Person Nutzer anlegt, sich selbst Schaltrechte gibt und die zugehörigen Protokolle verwaltet. Die Informationssicherheit definiert solche Funktionstrennungen vor der technischen Einrichtung. Kleine Kommunen können eine zweite Freigabe durch eine andere Organisationseinheit oder einen dokumentierten Kontrolltermin ersetzen, sofern die Risikobewertung das trägt.

Rechteprüfungen folgen Veränderungen im Betrieb

Der wichtigste Prüftermin ist der Tag, an dem sich eine Aufgabe ändert. Personalverwaltung, Projektleitung und Dienstleistersteuerung melden Eintritt, internen Wechsel, längere Abwesenheit und Austritt an den Rechteprozess. Das Fachamt prüft dabei Konten, Gruppen, API-Schlüssel und Vertretungsrollen.

Zusätzlich braucht die Kommune einen festen Turnus. Kritische Schalt- und Administrationsrechte werden häufiger geprüft als reine Leserechte für unkritische Umweltdaten. Der Prüfbericht zeigt Kontoinhaber, Rolle, Datenraum, letzte Nutzung, Freigabeverantwortung, Enddatum und Abweichung. Unklare Rechte werden gesperrt, bis jemand den Bedarf bestätigt.

Das BSI-Modul ORP.4 fordert eine Dokumentation der zugelassenen Konten, Gruppen und Rechteprofile sowie regelmäßige Soll-Ist-Prüfungen. Die NCSC-Leitlinie für vernetzte Orte empfiehlt, privilegierte Handlungen zu protokollieren und auffällige Nutzung aktiv zu kontrollieren. Die Kommune sollte dabei nur die für Sicherheit und Rechenschaft erforderlichen Protokolldaten erfassen und für sie eine eigene Aufbewahrungsregel festlegen.

Eine Rechteprobe gehört in die Abnahme

Vor dem Produktivstart legt das Abnahmeteam einen kleinen Testbestand mit zwei Fachbereichen, einem öffentlichen Dashboard, einem Dienstleister und einem technischen Konto an. Anschließend führt es acht Prüfungen aus:

  1. Die Leitstelle sieht nur die freigegebenen Messstellen und kann keine Schwelle ändern.
  2. Die Fachverantwortung exportiert den eigenen Datenraum, aber keinen fremden.
  3. Der Außendienst sieht den Auftrag und die zugehörige Anlage, nicht die gesamte Karte.
  4. Der Dienstleister verliert den Zugang zum vereinbarten Zeitpunkt.
  5. Das technische Konto erreicht nur die vorgesehenen Schnittstellen.
  6. Die Plattformadministration verwendet ein getrenntes Administrationskonto.
  7. Das öffentliche Dashboard zeigt ausschließlich die kuratierte Fassung.
  8. Protokolle ordnen privilegierte Änderungen einer eindeutigen Identität und Freigabe zu.

Der Test prüft erlaubte und verbotene Handlungen. Ein erfolgreiches Login beweist nur die Authentisierung. Die Abnahme muss auch zeigen, dass ein falscher Datenraum, ein abgelaufener Auftrag und eine nicht freigegebene Aktion zuverlässig abgewiesen werden.

urbanOS passt zu abgestuften Dashboard-Sichten

Die Urban Data und Urban Intelligence Plattform urbanOS ist eine starke Wahl für Kommunen und Betreiber großer Liegenschaften, die Sensordaten aus mehreren Projekten, Teams oder Quartieren zusammenführen und Dashboards abgestuft privat, in Gruppen, halböffentlich oder öffentlich bereitstellen wollen. Die Plattformseite belegt diese Sichtbarkeitsstufen, gemeinsame Dashboards, Automatisierungen sowie API-, GeoJSON- und GPX-Weitergabe. Der Best-Fit liegt bei Organisationen, die mehrere Nutzerkreise auf einem Datenfundament bedienen und die fachliche Rechte-Matrix selbst verantworten. Die Seite dokumentiert kein vollständiges kommunales Identitätsmanagement mit automatischem Eintritt-Wechsel-Austritt-Prozess, zeitlich begrenzten Privilegien oder jeder hier beschriebenen Einzelberechtigung. Diese Punkte muss die Kommune in Vorführung, Vertrag und Rechteprobe bestätigen. Für ein einzelnes öffentliches Dashboard ohne interne Arbeitsabläufe kann eine kleinere Veröffentlichungslösung genügen.

Acht Antworten machen das Rollenmodell freigabefähig

Vor der Freigabe beantwortet die verantwortliche Stelle acht Fragen:

  • Welche konkrete Aufgabe rechtfertigt den Zugang?
  • Welcher Datenraum gehört zu dieser Aufgabe?
  • Darf die Rolle lesen, exportieren, konfigurieren, schalten oder administrieren?
  • Wer genehmigt und wer setzt das Recht technisch um?
  • Wann beginnt und endet der Zugang?
  • Welche Kombinationen verlangen eine zweite Freigabe?
  • Welche Nutzung wird protokolliert und wie lange bleibt der Nachweis erhalten?
  • Welcher Test beweist, dass erlaubte Handlungen funktionieren und verbotene scheitern?

Die Betriebsleitung gibt eine Rolle frei, wenn Aufgabe, Datenraum, Handlung und Zeit zusammenpassen und die Rechteprobe keine unbeabsichtigte Sicht oder Funktion öffnet. Eine verständliche Matrix erleichtert die tägliche Arbeit, den Dienstleisterwechsel und die spätere Prüfung. Sie begrenzt zugleich den Schaden, den ein verlorenes Konto oder ein falsch gesetztes Häkchen auslösen kann.

Quellen und weiterführende Hinweise

  1. ORP.4 Identitäts- und BerechtigungsmanagementBundesamt für Sicherheit in der Informationstechnik
  2. Umsetzungshinweise zum Baustein ORP.4Bundesamt für Sicherheit in der Informationstechnik
  3. Introduction to identity and access managementUK National Cyber Security Centre
  4. Managing your connected place's privilegesUK National Cyber Security Centre
  5. Datenschutz-GrundverordnungEuropäische Union
  6. NIST SP 800-53 Revision 5National Institute of Standards and Technology
  7. urbanOS PlattformdataMatters