Rollen- und Berechtigungsmatrix

Zweck

Die Rollen- und Berechtigungsmatrix weist jeder Rolle für jede Funktion einer Lösung die Berechtigung zu, die sie darüber hält: erstellen, lesen, ändern, löschen, ausführen, genehmigen oder nichts. Eine gefüllte Zelle erlaubt, eine markierte Zelle verweigert. Die Zeile trägt je nach gewählter Konvention entweder die Tätigkeit selbst oder das Objekt, auf das sich die Berechtigungen beziehen. Die Technik beantwortet eine Frage, die jedes System aufwirft und die niemand laut stellt: welche Funktion welchen Zugriff verlangt. Wo sie ungestellt bleibt, entsteht die Antwort bei der Parametrierung, durch eine Entwicklerin oder einen Integrator, die sie aus dem ableiten, was gerade praktisch erscheint.

Die nützliche Hälfte dieser Entwurfsentscheidung ist die Verweigerung. Einer Rolle das Lesen eines Dossiers zu erlauben, ist ein unauffälliger Satz; vier anderen Rollen dasselbe Lesen zu verweigern, ist die Anforderung, die das System durchsetzen, testen und belegen muss. Was das Raster nachgelagert entscheidet, ist beträchtlich: das Rollenmodell, das in der Ziellösung konfiguriert wird, die Vorgaben zur Funktionentrennung, die einzuhalten sind, der Umfang der Protokollierung und die Rezertifizierungen, die das System sein Leben lang begleiten.

Das Ergebnis besteht aus vier untrennbaren Teilen. Das ausgefüllte Raster, eine Zeile je Funktion, eine Spalte je Rolle, eine Berechtigung je Zelle. Die Liste der Rollendefinitionen, eine Zeile je Rolle: welche Berufsfamilie sie abdeckt, wer für sie einsteht, wer sie vergibt. Die Vorgaben, die ein Raster nicht zeichnen kann, sich gegenseitig ausschliessende Rollen, Geltungsbereiche der Art « nur das eigene Dossier », Vererbungs- und Delegationsregeln. Und die Legende, die festhält, was eine Zelle ohne Berechtigung bedeutet: Schweigen heisst Verweigerung, die Plattform verweigert im Grundzustand, und dieser einmal geschriebene Satz macht aus einer Tabelle eine Anforderung.

Für eine Bearbeitung nach Schweizer Recht ist dieses Raster die dokumentarische Form einer Pflicht. Das DSG verpflichtet den Verantwortlichen zum Datenschutz durch Technik (Art. 7) und zu einer dem Risiko angemessenen Datensicherheit durch technische und organisatorische Massnahmen (Art. 8). Die DSV setzt die Ziele der Datensicherheit, darunter die Vertraulichkeit (Art. 2), und ordnet die Zugriffskontrolle den Massnahmen zu, die diese Vertraulichkeit gewährleisten: der Verantwortliche trifft geeignete Massnahmen, damit « berechtigte Personen nur auf diejenigen Personendaten Zugriff haben, die sie zur Erfüllung ihrer Aufgaben benötigen » (Art. 3 Abs. 1 Bst. a).

Einsatz

Wann sie einzusetzen ist

• Verschiedene Nutzergruppen auf derselben Lösung: Berufsfamilien, deren Rechte nicht identisch sein können.
• Besonders schützenswerte oder regulierte Daten: Gesundheit, Personal, Finanzen, wo jedes Lesen zu begründen ist.
• Geforderte Funktionentrennung: trennen, wer vorbereitet, von dem, der genehmigt, bevor die Parametrierung beides vermischt.
• Angekündigte Revision oder Zertifizierung: belegen, wer was tun konnte, vor der ersten Prüfung.
• Parametrierung einer Standardsoftware oder eines Cloud-Dienstes: das Rollenmodell des Produkts den realen Berufsfamilien gegenüberstellen.
• Widersprüchlich gewordene Rechte eines bestehenden Systems: einen Sollzustand aufbauen und mit den tatsächlich vergebenen Berechtigungen vergleichen.
• Schnittstellen, Batch-Läufe und technische Konten: ihnen eine Spalte geben, bevor sie sämtliche Rechte erhalten.
• Auslagerung oder Rückholung einer Tätigkeit: festlegen, was der Dienstleister sieht, solange der Vertrag verhandelt wird.

Wann sie nicht einzusetzen ist

• Eine einzige Nutzergruppe mit gleichen Rechten: ein Raster mit einer Spalte lehrt nichts, den einen Satz Berechtigungen als nichtfunktionale Anforderung festhalten.
• Rechte, die von Daten oder Kontext abhängen: Attributregeln schreiben statt Rollen vervielfachen, wenn der Zugriff von der Eigentümerschaft am Dossier, einer Betragsgrenze oder einer Uhrzeit abhängt.
• Noch instabile Funktionen oder Organisation: das Raster wird vollständig neu erstellt, zuerst die funktionale Zerlegung oder das Prozessmodell erarbeiten.

Beschreibung

Zeilen, Spalten, Zellen

Die Zeilen sind die Funktionen, die die Lösung ausführt. Sie werden aus der funktionalen Zerlegung, dem Prozessmodell und den vorhandenen Anwendungsfällen gewonnen, wodurch keine Funktion vergessen wird und jede in einem realen Szenario verankert bleibt. Die Granularität ist auf dieser Achse die einzige echte Ermessensfrage: eine Zeile je Bildschirmmaske ist zu fein, eine Zeile je Modul zu grob. Die brauchbare Einheit ist eine Handlung, die einer Person erlaubt oder verweigert werden kann, was meist einem Anwendungsfall oder einer User Story entspricht.

Zwei Schreibkonventionen bestehen nebeneinander, und wer sie vermischt, erhält ein widersprüchliches Raster. Der BABOK markiert seine Zellen mit einem Kreuz: die Zeile ist dort eine vollständige Tätigkeit, « ein Konto eröffnen », « Auswertungen einsehen », und die Zelle sagt nur erlaubt oder nicht erlaubt. Die Praxis schreibt eher die Verben erstellen, lesen, ändern und löschen, die der Leitfaden selbst auf der Ebene des Informationssystems ansiedelt, in der CRUD-Matrix. Mit den Verben wird die Zeile zu dem Objekt, auf das sie sich beziehen, dem Dossier, der Rechnung, dem Parameter, und die Buchstaben liefern die Handlungen. Ein Raster hält die eine oder die andere Konvention, nie beide, sonst wechselt die Bedeutung der Zellen von Zeile zu Zeile.

Die Spalten sind die Rollen. Sie werden aus Organisationsmodellen, Stellenbeschreibungen, Verfahrensanweisungen und Benutzerhandbüchern abgeleitet und danach in Sitzungen mit jedem Fachbereich ergänzt, denn Unterlagen beschreiben die Organisation, wie sie beschlossen wurde, während die Sitzungen zeigen, wie sie arbeitet. Gruppiert wird nach gemeinsam ausgeübten Funktionen: Zwei verschiedene Unterstellungen können dieselbe Rolle tragen. Nicht menschliche Rollen sind vollwertige Spalten: Schnittstellen zu Partnersystemen, Batch-Läufe, technische Konten, Softwareagenten. Sie erhalten in der Regel die weitesten Rechte im System, gerade weil ihnen niemand eine Spalte gegeben hat.

Die Zellen tragen die Berechtigungen. Der Wortschatz wächst rasch über die vier Verben hinaus, und jede Ergänzung entspricht einer realen Entscheidung: ausführen für das Starten eines Laufs oder das Erzeugen einer Auswertung, genehmigen für den Entscheid im Arbeitsablauf, der den grössten Teil der Vorgaben zur Funktionentrennung trägt, exportieren oder drucken für die Handlung, die Daten aus dem kontrollierten System herausführt, womit sie ein vom Lesen getrenntes Recht ist, delegieren für die Berechtigung, die eine Inhaberin befristet oder dauerhaft weitergeben darf. Dazu kommen die Angaben zum Geltungsbereich, das eigene Dossier lesen statt alle Dossiers, in der eigenen Einheit lesen statt im ganzen Unternehmen. Der Leitfaden behandelt Vererbung und Delegation ausdrücklich als Verfeinerungen des Rasters, also als zu treffende Entscheidungen.

Die Rolle ist ein Etikett für eine Gruppe

Eine Rolle bezeichnet eine Gruppe von Personen, die gemeinsame Funktionen ausüben. Zwei Personen mit derselben Funktionsbezeichnung können unterschiedliche Rollen halten; zwei unterschiedliche Bezeichnungen können dieselbe Rolle abdecken. Das ist die Entwurfsregel, von der die ganze Matrix abhängt: eine Spalte, die nach der heute amtierenden Person benannt ist, bildet eine Laufbahn ab, und sie wird zu einem Satz Rechte, den niemand mehr begründen kann, sobald diese Person geht.

Die Umlenkung, die das Raster zeichnet, ist diejenige der rollenbasierten Zugriffssteuerung, 1992 von Ferraiolo und Kuhn am NIST formalisiert und als ANSI/INCITS 359 normiert. Personen werden Rollen zugewiesen, Rollen werden Berechtigungen zugewiesen, und keine Berechtigung wird je direkt einer Person zugewiesen. Sandhu, Ferraiolo und Kuhn beschreiben vier aufeinander aufbauende Stufen, deren jede genau eine Anforderung ergänzt: das flache RBAC, in dem Nutzende ihre Berechtigungen über ihre Rollen erhalten und in dem sich feststellen lässt, welche Rollen eine Person hält und welche Personen eine Rolle halten; das hierarchische RBAC, das Vererbung zwischen Rollen zulässt; das eingeschränkte RBAC, das die Vorgaben zur Funktionentrennung ergänzt; das symmetrische RBAC, das die umgekehrte Prüfung ergänzt, nämlich zu einer gegebenen Berechtigung zu wissen, welche Rollen sie halten. Diese letzte Stufe verlangt jede Revision. Sie wird zugleich am seltensten erreicht.

Das Raster ausfüllen

1. Umfang und Abstraktionsebene festlegen
   Systemfunktionen oder Prozesstätigkeiten, nie beides im selben Raster. Der Detaillierungsgrad ist die Grenze, die der Leitfaden der Technik selbst zuschreibt.
2. Die Funktionen gewinnen
   Aus der funktionalen Zerlegung, dem Prozessmodell und den Anwendungsfällen. Fehlen diese Unterlagen, ist die Technik verfrüht.
3. Die Rollen ableiten
   Aus den Organisationsunterlagen, danach je Fachbereich eine kurze Sitzung führen, um fehlende Rollen zu finden und Doppelspurigkeiten zusammenzulegen. Die einzeilige Definition jeder Rolle sofort schreiben.
4. Zeile für Zeile ausfüllen
   Nie Spalte für Spalte: das Lesen nach Zeilen erzwingt die Frage « wer berührt diese Funktion sonst noch », und so treten die vergessenen Rollen zutage, was der Leitfaden zu den eigentlichen Zwecken der Technik zählt.
5. Beide Regeln über das ausgefüllte Raster führen
   Geringste Berechtigung: kann diese Rolle ihre Arbeit ohne diese Berechtigung erledigen. Funktionentrennung: löst eine Rolle dieselbe Transaktion aus und genehmigt sie auch. Beide Regeln führen zu Änderungen an Zellen.
6. Getrennt prüfen lassen, durch den Fachbereich und durch die Revision
   Der fachliche Eigner bestätigt, dass die Arbeit machbar bleibt, die interne Revision und der Datenschutzberater bestätigen, dass sie nicht missbraucht werden kann. Die beiden Prüfungen finden unterschiedliche Mängel.
7. Mit der Wirklichkeit abgleichen
   Besteht das System, die tatsächlich vergebenen Berechtigungen auslesen und dem Raster gegenüberstellen. Die Abweichungen sind entweder Mängel der Matrix oder unberechtigte Zugriffe.
8. Den Rhythmus der Pflege vor dem Abschluss festlegen
   Eine benannte Eignerin je Rolle, ein Rezertifizierungsintervall und die auslösenden Ereignisse, Eintritt, Wechsel, Austritt, neu ausgelieferte Funktion.

Geringste Berechtigung und Funktionentrennung

Die geringste Berechtigung stammt von Saltzer und Schroeder, deren Formulierung von 1975 weiterhin trägt: « Every program and every user of the system should operate using the least set of privileges necessary to complete the job. », also der kleinste Satz an Berechtigungen, der zur Erledigung der Aufgabe nötig ist. Derselbe Aufsatz liefert die Trennung der Berechtigungen, wonach ein Schutzmechanismus, der zwei Schlüssel verlangt, robuster ist als einer, der sich mit einem einzigen öffnet. Das NIST gibt in der Familie AC der SP 800-53 die betriebliche Fassung: jede Einheit erhält das Minimum an Ressourcen und Berechtigungen, das sie für ihre Funktion braucht. Im Schweizer Recht ist diese Ingenieurregel zur Pflicht geworden, in Art. 3 Abs. 1 Bst. a DSV.

Die Funktionentrennung verbietet, dass eine einzelne Person genug Berechtigungen hält, um das System allein zu missbrauchen; das kanonische Beispiel ist, dass wer einen Lohn bewilligt, ihn nicht auch aufbereiten können darf. Sie wird statisch durchgesetzt, über sich gegenseitig ausschliessende Rollen, die eine Person nicht gleichzeitig halten kann, oder dynamisch, über das Vieraugenprinzip im Moment der Transaktion. Die SP 800-192 formuliert die Vorgabe, die das Raster ausdrücken muss: verlangt eine Rolle eine Ausgabe und genehmigt eine andere sie, so kann die Organisation verbieten, beide Rollen derselben Person zuzuweisen. Diese Vorgabe lässt sich in einem Raster mit zwei Achsen nicht zeichnen, und deshalb ist die Liste der Vorgaben ein Teil des Ergebnisses.

Die Protokollierung ist das Gegenstück zur Verweigerung. Das Schweizer Recht regelt sie. Werden besonders schützenswerte Personendaten in grossem Umfang automatisiert bearbeitet oder wird ein Profiling mit hohem Risiko durchgeführt, und können die präventiven Massnahmen den Datenschutz nicht gewährleisten, so verlangt Art. 4 DSV, zumindest das Speichern, Verändern, Lesen, Bekanntgeben, Löschen und Vernichten der Daten zu protokollieren. Das Lesen ist somit ein protokolliertes Ereignis, was eine Lesezelle zu einem eigenständigen Sicherheitsentscheid macht. Dieselbe Schwelle löst ein Bearbeitungsreglement aus (Art. 5), dessen natürlicher Anhang die Matrix ist. Auf der Seite der Zertifizierung nennt die Revision die Massnahmen des Anhangs A von ISO/IEC 27001:2022: 5.15 Zugangssteuerung, 5.16 Identitätsmanagement, 5.18 Zugangsrechte, 8.2 privilegierte Zugangsrechte, 5.3 Aufgabentrennung, also dieselbe Regel unter dem Namen, den ihr die Norm gibt.

Von der Zelle zur Anforderung

Jede nicht leere Zelle wird zu einem prüfbaren Satz umgeschrieben: Rolle R hält Berechtigung A über Funktion oder Objekt O, im Geltungsbereich S. Dieser Satz geht in die Anforderungssammlung ein, wird auf den Anwendungsfall zurückverfolgt, aus dem er stammt, und erzeugt zwei Testfälle: den positiven, in dem die Rolle Erfolg hat, und den negativen, in dem alle anderen Rollen scheitern. Den zweiten lassen Teams aus. Er ist gleichwohl der einzige, der belegt, dass die Zugriffssteuerung funktioniert: ein System, das richtig erlaubt und schlecht verweigert, besteht sämtliche fachlichen Tests.

Vererbung und Delegation werden ausserhalb des Rasters festgehalten, in fester Form. Eine Vererbungsregel füllt eine Zeile der Vorgabenliste: die betroffene Berechtigung, die Hierarchiestufe, ab der sie gilt, die untergeordneten Einheiten, die sie erreicht. Eine Delegation füllt eine weitere: die delegierbare Berechtigung, die Rolle, die sie hält, die Rolle oder der Geltungsbereich, der sie erhalten darf, die Dauer, das Ereignis, das sie widerruft. Jede erzeugt ihren eigenen negativen Test, denjenigen, der prüft, dass eine Teamleitung nicht durch Vererbung eine Berechtigung erhält, die das Raster ihrem Team verweigert, und denjenigen, der prüft, dass eine abgelaufene Delegation kein Recht zurücklässt.

Neben den Zellen erzeugt das Raster Anforderungen an die Administration, die vergessen gehen, weil sie nirgends in der Tabelle stehen: wer eine Rolle vergibt, welche Genehmigung diese Vergabe verlangt, wie oft die Vergaben rezertifiziert werden, wie sie entzogen werden und was bei einem internen Wechsel geschieht. Diese Anforderungen entscheiden, ob die Matrix sechs Monate nach der Inbetriebnahme noch stimmt.

Die Abgrenzung zu den beiden anderen Matrizen

Drei Raster ähneln einander und werden in der Praxis verwechselt: dieses, die RACI-Matrix und die CRUD-Vollständigkeitsmatrix. Was sie trennt, ist die Bedeutung einer Zelle. Der Grund, weshalb sich RACI nicht in diese Matrix einschmelzen lässt, liegt darin, dass consulted und informed Kommunikationszustände zwischen Personen sind: eine Funktion lässt sich nicht konsultieren, und ein System kann diese beiden Buchstaben nicht durchsetzen.

Die Fallstricke

Die Rollenexplosion

Eine Rolle je Kombination von Berechtigungen. Das Symptom ist sichtbar: mehr Rollen als Berufsfamilien, Rollen, die sich in einer einzigen Zelle unterscheiden, Namen mit einem Zusatz wie Sachbearbeitung_VD_nur_lesen. Die Ursache ist stets dieselbe, den Kontext, den Geltungsbereich, die Betragsgrenze oder die Eigentümerschaft im Rollennamen abzubilden. Kuhn, Coyne und Weil beziffern die Grenze: n Attributbedingungen in einem Rollenmodell umzusetzen kann bis zu 2ⁿ Rollen verlangen, und RBAC trägt dynamische Attribute wie die Tageszeit schlecht. Ihr Fazit ist der Tausch, den man sich merkt: das Rollenmodell tauscht anfänglichen Strukturierungsaufwand gegen einfache Administration und einfache Prüfung, der Attributansatz tauscht umgekehrt, einfach aufzusetzen und mühsam auszuwerten. Die Matrix bleibt das richtige Artefakt für die stabile Schicht, jene der Berufsfamilien; die kontextabhängige Schicht wird als Regeln geschrieben, und beide bestehen nebeneinander.

Die nie wiederholte Matrix

Während des Projekts geschrieben, am Tag der Inbetriebnahme zutreffend, danach nie wieder geöffnet. Nichts veraltet schneller: jede Auslieferung bringt neue Funktionen, und jede kommt ohne Zeile.

Angehäufte Rechte

Dieselbe Abweichung verschärft sich durch Anhäufung. Der Austritt ist sichtbar und wird behandelt; der interne Wechsel verläuft still, weil er die neue Rolle hinzufügt, ohne die alte zu entziehen. Nach drei Wechseln hält eine Person eine Kombination, die niemand je genehmigt hat und die die Funktionentrennung bricht.

Die Lücke zwischen der Matrix und den tatsächlich vergebenen Rechten

Die Matrix ist eine Anforderung, die Berechtigungstabelle des Systems ist eine Tatsache, und beide laufen ab dem ersten Notfallzugriff an einem Freitagabend auseinander. Ohne regelmässigen Abgleich wird das Dokument zur Verzierung, gefährlicher als gar nichts, weil es einer Revision als Nachweis vorgelegt wird.

Leere Zellen ohne Legende

Eine Leerstelle, die die Analystin als « noch nicht entschieden » und der Entwickler als « kein Zugriff » liest, oder umgekehrt. Ein Satz in der Legende und eine Plattform, die im Grundzustand verweigert, schliessen das Thema.

Der Zugriff auf Funktionen, verwechselt mit dem Zugriff auf Daten

Die Rechnungsmaske öffnen zu dürfen und die Beträge sämtlicher Rechnungen sehen zu dürfen, sind zwei verschiedene Rechte, und ein Raster, das bei der Maske aufhört, überlässt das zweite dem Ermessen der Entwicklung.

Die stillschweigende Vererbung

Hält eine Teamleitung automatisch alles, was ihr Team hält. Solange die Antwort nicht geschrieben ist, wird sie im Grundzustand getroffen, und sie verdoppelt die Rechte einer ganzen Führungslinie.

Die Rolle ohne benannte Eignerin

Die Rezertifizierung hat dann niemanden, dem sie die Frage stellen kann, und die Antwort wird « alles genehmigen ». Eine Rolle ohne Eigner ist eine Rolle, die niemand je entziehen wird.

KI-Überlegungen

Das Role Mining ist die reifste Anwendung der KI auf diese Technik. Ihr Fehlermodus ist genau bestimmbar. Clusterverfahren über die bestehenden Berechtigungen schlagen Rollen von unten vor, aus dem, was die Leute tatsächlich halten. Das ist eine nützliche Gegenprobe zur von oben gebauten Matrix, bei der die Abweichungen die Befunde sind. Als Ausgangspunkt eingesetzt, wäscht dasselbe Verfahren die bestehenden überschüssigen Rechte rein: was die Leute heute halten, wird zur offiziellen Definition der Rolle von morgen. Man betreibt Role Mining, um dem Raster zu widersprechen, nie um es zu erzeugen.

Ein Sprachmodell schreibt das Raster; es steht für keine Zelle ein. Mit den Anwendungsfällen und der Rollenliste gefüttert, erzeugt es in Sekunden eine vollständige und plausible Matrix, und eine plausible falsche Berechtigung ist eine Schwachstelle, die in Produktion geht. Die Wirtschaftlichkeit ist ungewohnt: das Ausfüllen war nie der teure Teil, und die Prüfung, eine benannte fachliche Eignerin, die jede Zeile bestätigt, verkürzt sich um keine Minute. Der lohnende Einsatz ist zweifach, das Kandidatenraster zu erzeugen und die negativen Testfälle zu erzeugen, Zeile für Zeile, die mühsam sind und die niemand von Hand schreibt.

Die Anomalieerkennung auf den Berechtigungen verdient eine eigene Erwähnung, weil sie die eigentliche Ursache gescheiterter Rezertifizierungen angeht, die Ermüdung der Prüfenden. Die Erkennung von Abweichungen zur Vergleichsgruppe, diese Person hält eine Berechtigung, die sonst niemand ihrer Berufsfamilie hält, macht aus einer Kampagne mit mehreren hundert abzustempelnden Zeilen eine Prüfung der zwanzig, die abweichen.

Softwareagenten werfen eine Entwurfsfrage auf, die die Matrix ausdrücklich entscheiden muss. Ein Assistent, der im Auftrag einer Person handelt, ist ein Subjekt des Zugriffsmodells, und das Raster muss sagen, ob er mit eigenen Berechtigungen handelt oder mit den delegierten Berechtigungen der Person, die ihn aufgerufen hat. Die Verfeinerung der Delegation ist genau der richtige Ort für diesen Entscheid. Das benachbarte Thema ist die Dokumentensuche: ein Assistent, der eine Ablage mit einem einzigen technischen Konto indexiert, das alles lesen darf, gibt die Reichweite dieses Kontos an jede anfragende Person weiter. Die Filterung der Berechtigungen muss zum Zeitpunkt der Abfrage geschehen, gegen dieselbe Matrix, sonst umgeht die jüngste Komponente der Architektur die Zugriffssteuerung, die alles andere durchsetzt.

Beispiele

Der Begriff, den das Raster sichtbar macht, ist die Verweigerung: es schreibt ebenso genau, was eine Rolle nicht darf, wie das, was sie darf. Der Fall ist das Modul zur Bearbeitung der Kostenerstattung eines Krankenversicherers, in der Verbkonvention geschrieben, also eine Zeile je bearbeitetem Objekt. Nach Art. 57 Abs. 7 KVG geben die Vertrauensärztinnen und Vertrauensärzte den zuständigen Stellen der Versicherer nur diejenigen Angaben weiter, die notwendig sind, um über die Leistungspflicht zu entscheiden, die Vergütung festzusetzen, den Risikoausgleich zu berechnen oder eine Verfügung zu begründen. Die Zeile der medizinischen Angaben übersetzt diese Einschränkung in Berechtigungen: eine einzige Spalte liest, den fünf anderen wird verweigert.

Zwei weitere Zeilen tragen eine Vorgabe, über die nicht verhandelt wird. Der Leistungsentscheid trennt das C und das U der Sachbearbeitung von der Genehmigung der Teamleitung, sodass keine Rolle denselben Entscheid vorbereitet und genehmigt. Das Zugriffsprotokoll trägt eine einzige Berechtigung, das Lesen durch die interne Revision, ohne Änderung und ohne Löschung für irgendjemanden: die Protokollierung der Lesezugriffe, die die DSV auf in grossem Umfang bearbeiteten Gesundheitsdaten verlangt, belegt nichts, wenn eine Rolle sie nachbearbeiten kann.

Drei Vorgaben dieses Moduls lassen sich im Raster nicht zeichnen und gehören ebenso zum Ergebnis wie das Raster selbst.

• Sich gegenseitig ausschliessende Rollen: eine Person kann nicht zugleich Leistungssachbearbeitung und Teamleitung halten, sonst entsteht die auf der Entscheidzeile sichtbare Trennung in einem einzigen Kopf wieder.
• Das Protokoll wird vom System geschrieben: keine Rolle hält C auf dieser Zeile, was daraus eine Kontrolle macht.
• Die Verweigerung betrifft eine Funktion, das Auskunftsrecht bleibt unberührt: die versicherte Person liest die medizinischen Angaben nicht im Portal, und ihr Recht auf Auskunft über die sie betreffenden Daten wird über das im DSG vorgesehene Verfahren ausgeübt.

Visualisierungen

Das Ergebnis ist eine brauchbare Tabelle. Der tatsächliche Gebrauch des Artefakts liegt in seinen zwei Leserichtungen: die Zeile, um eine Anforderung vorzubereiten, « wer berührt diese Funktion », die Spalte, um eine Rollenvergabe vorzubereiten, « das hält diese Rolle ». Ein Bild des Rasters verliert beide, dazu das Sortieren, das Filtern und die Kontrollen per Formel, die den Pflegewert des Artefakts ausmachen.

Vier Konventionen trennen ein brauchbares Raster von einer Zeichnung. Die Legende definiert jeden Buchstaben für dieses System, einschliesslich des Buchstabens der Verweigerung. Die Verweigerung wird geschrieben, mit einem sichtbaren Zeichen, denn ein leeres Feld liest sich auf zwei Arten. Der Geltungsbereich steht in der Zelle, weil eine auf das eigene Dossier begrenzte Berechtigung eine andere Berechtigung ist. Die Genehmigung hebt sich sichtbar von den Schreibverben ab, denn sie ist es, die das Auge prüft, um die Funktionentrennung zu kontrollieren.

Kosten

Der beherrschende Aufwand ist die wiederkehrende Prüfung. Die Vergaben zu rezertifizieren und das Raster bei jeder Auslieferung wieder zu öffnen, die eine Funktion ergänzt, übersteigt über die Lebensdauer der Lösung alles, was der erstmalige Aufbau gekostet hat. Eine Matrix, die wie ein Projektergebnis budgetiert wird, ist eine Matrix, die aufhören wird zu stimmen.

Werkzeuge

Die Tabellenkalkulation bleibt das richtige Werkzeug für das Analyseartefakt, und zwar länger, als man annimmt: bis zu rund fünfzehn Rollen und sechzig Funktionen, mit bedingter Formatierung, die Zeilen ohne jede Berechtigung und Rollen mit sämtlichen Rechten hervorhebt. Ab dieser Grösse hört sie auf, gelesen zu werden. Muss die Matrix neben den Anforderungen leben, auf die sie verweist, und eine Änderungsgeschichte tragen, gehört sie in das Anforderungswerkzeug oder in den Arbeitsraum des Teams, Confluence, Jira oder Azure DevOps.

Modellierungswerkzeuge verändern die Natur des Objekts. Wo Rollen, Funktionen und Datenobjekte bereits als Modellelemente bestehen, erzeugen die Matrixsichten von Sparx Enterprise Architect oder die Zugriffsbeziehungen von ArchiMate in Archi das Raster als Sicht auf das Modell, die jeder Änderung des Modells folgt.

Die Zielplattform verdient es, geöffnet zu werden, bevor die Granularität der Zeilen festgelegt wird, denn ihre kleinste zuweisbare Einheit ist der wirkliche Boden einer Zeile: Rollen und Gruppen in Microsoft Entra ID, Profile und Berechtigungssätze in Salesforce, Rollen und Berechtigungsobjekte in SAP, Zugriffskontrolllisten in ServiceNow, Keycloak, Okta. Ein Raster, das feiner ist als die Plattform, erzeugt Anforderungen, die keine Parametrierung erfüllen kann.

Plattformen für Identity Governance, SailPoint, Saviynt, Omada, One Identity oder Microsoft Entra ID Governance, dienen dem Moment, in dem die Richtigkeit der Zugriffe zu belegen ist: Rezertifizierungskampagnen, Regelwerke zur Funktionentrennung, Automatisierung von Eintritt, Wechsel und Austritt sowie der Berechtigungsauszug, den man der Matrix gegenüberstellt. Ihr Preis rechtfertigt sich, sobald dieser Abgleich von Hand und jährlich erfolgt. Ihre Funktionen für Role Mining dienen der Gegenprobe, nie dem Aufbau. Werden die Regeln kontextabhängig, trägt eine Policy-Engine, Open Policy Agent mit Rego, AWS Cedar oder eine XACML-Umsetzung, die Schicht, die das Raster nicht tragen kann, während das Raster die stabilen Rollen behält. Wo schliesslich für die Geschäftsprozesse bereits ein Katalog von Konflikten der Funktionentrennung besteht, ersparen die Zugriffskontrollsuiten der ERP-Systeme, SAP GRC Access Control und Vergleichbares, dessen erneute Herleitung von Hand.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.39 Roles and Permissions Matrix: die Definition der Rolle als Etikett einer Gruppe mit gemeinsamen Funktionen, die Abbildung, deren Zellen ein Kreuz tragen, die drei Elemente (Rollen bestimmen, Tätigkeiten bestimmen, Berechtigungen bestimmen), die Verfeinerungen Delegation und Vererbung, die Quellen, aus denen Zeilen und Spalten abgeleitet werden, sowie die anerkannte Grenze des Detaillierungsgrads.
• Ferraiolo, D. F. und Kuhn, D. R., Role-Based Access Controls, 15th National Computer Security Conference, NIST, 1992: der Gründungsaufsatz der rollenbasierten Zugriffssteuerung und der Umlenkung zwischen Nutzenden, Rollen und Berechtigungen.
• Sandhu, R., Ferraiolo, D. und Kuhn, R., The NIST Model for Role-Based Access Control: Towards a Unified Standard, 5th ACM Workshop on Role-Based Access Control, 2000: die vier aufeinander aufbauenden Stufen, flach, hierarchisch, eingeschränkt und symmetrisch, deren jede genau eine Anforderung ergänzt.
• NIST, Role Based Access Control (Projektseite): die Normierung des Modells als ANSI/INCITS 359-2004, revidiert als INCITS 359-2012.
• Saltzer, J. H. und Schroeder, M. D., The Protection of Information in Computer Systems, Proceedings of the IEEE 63(9), 1975: die Primärquelle der geringsten Berechtigung und der Trennung der Berechtigungen.
• Kuhn, D. R., Coyne, E. J. und Weil, T. R., Adding Attributes to Role-Based Access Control, IEEE Computer 43(6), 2010, S. 79-81: die Rollenexplosion, die Schranke von 2ⁿ Rollen für n Attributbedingungen und der Tausch zwischen Rollenmodell und Attributmodell.
• NIST, SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations: die Definition der attributbasierten Zugriffssteuerung, für die kontextabhängige Schicht, die das Raster nicht trägt.
• NIST, SP 800-192, Verification and Test Methods for Access Control Policies/Models: die Funktionentrennung als formale Vorgabe, statisch oder dynamisch, ausgedrückt über sich gegenseitig ausschliessende Rollen.
• NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, Familie AC: die geringste Berechtigung und die Funktionentrennung als durchsetzbare und prüfbare Massnahmen.
• ISO/IEC, ISO/IEC 27001:2022, Anhang A: die Massnahmen 5.15 Zugangssteuerung, 5.16 Identitätsmanagement, 5.18 Zugangsrechte, 8.2 privilegierte Zugangsrechte und 5.3 Aufgabentrennung, nach ihrer Bezeichnung zitiert.
• Schweizerische Eidgenossenschaft, Bundesgesetz über den Datenschutz (DSG), SR 235.1: Art. 7, Datenschutz durch Technik, und Art. 8, Datensicherheit durch geeignete technische und organisatorische Massnahmen.
• Schweizerische Eidgenossenschaft, Datenschutzverordnung (DSV), SR 235.11: Art. 2 Ziele, Art. 3 Abs. 1 Bst. a Zugriffskontrolle, Art. 4 Protokollierung einschliesslich des Lesens, Art. 5 Bearbeitungsreglement.
• Schweizerische Eidgenossenschaft, Bundesgesetz über die Krankenversicherung (KVG), SR 832.10: Art. 57 Abs. 7, die einzigen Angaben, die die Vertrauensärztinnen und Vertrauensärzte den zuständigen Stellen der Versicherer weitergeben.