Zugangskontrolle im Cloud-Zeitalter
Attribute statt Rollen
Angesichts neuer Herausforderungen im Identity-Management erweist sich die herkömmliche rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) als zu starr. Die Orientierung an Attributen statt an Rollen (Attribute-Based Access Control, ABAC) ermöglicht dynamische Lösungen, die sicherer und effizienter sind.Früher war vielleicht nicht alles besser, aber doch viel einfacher und übersichtlicher. Beim Zugriff auf Unternehmensinformationen musste man eigentlich nur zwischen zwei Gruppen unterscheiden: diejenigen, die dazugehörten - und alle anderen. Wer ein Mitarbeiter war und das Zauberwort kannte, dem wurde Einlass gewährt, er war als berechtigter Nutzer identifiziert. Etwas komplizierter wurde es, als nicht mehr jeder Eingelassene berechtigt war, alles zu sehen, und erst recht, als man solche Unterschiede nicht mehr direkt an einzelnen Personen, sondern an deren Rollen und damit implizit an Funktionen in den Geschäftsprozessen knüpfte. Mit diesen Rollen kann eine Person an unterschiedlichen Berechtigungsprofilen teilhaben, und eine Rolle kann von einer anderen Rechte erben. Ein derartiges rollenbasiertes Berechtigungswesen ist in der Regel so komplex, dass es nur im Rahmen eines Identity-Managements effizient funktioniert. Aber wenigstens war noch immer klar, wer dazugehörte und wer nicht. Das hat sich in den letzten Jahren geändert: Digitalisierung, Cloud Computing und mobile Geräte haben alles noch unübersichtlicher gemacht. Schon das Drinnen und Draußen lässt sich heute nicht mehr so richtig abgrenzen: Da sind zum Beispiel Geschäftspartner, die bestimmte betriebliche Funktionen übernehmen und dafür einen entsprechenden Datenzugriff brauchen. Manche Dienstleister arbeiten sogar in den Räumen eines Unternehmens, sollen aber trotzdem nicht Zugang zu allen Informationen erhalten. Kunden wollen und sollen ebenfalls auf bestimmte Funktionen und Informationen zugreifen. Und dann sind da noch die Mitarbeiter, die unterwegs oder im Home Office arbeiten: Sie sind draußen und doch immer auch drinnen, während die erwähnten Dienstleister drinnen sind, aber doch eher draußen. Es ist heute also gar nicht so einfach, Identitäten zu bestimmen. Zuletzt hat das Thema Mobility die Lage verschärft: Jetzt wollen die Nutzer ihren Zugang mit verschiedenen Geräten von verschiedenen Standorten - und Unternehmen müssen prüfen, ob derjenige, der heute ein bestimmtes Gerät nutzt, immer noch derselbe ist, der es gestern ganz zu Recht benutzt hatte. Das Identity-Management (IDM) muss sich neu aufstellen. Denn das herkömmliche RBAC-Konzept erweist sich angesichts der neuen Herausforderungen als zu starr: Es reicht nicht mehr aus, um alles abzudecken. Strikte Regelungen - wen wir nicht kennen, den lassen wir auch nicht herein - schaffen zwar Sicherheit, erweisen sich aber meist als zu restriktiv. So werden beispielsweise Konsumenten und Interessenten unnötigerweise ausgeschlossen; sie stehen vor einer "Identitätsgrenze", weil sie nicht über eine richtige Rolle verfügen, obwohl das Unternehmen ihnen doch den Zugang ermöglichen will. Eine Rolle "Interessent" wäre aber viel zu grob, darauf könnte man auch ganz verzichten. Differenzierte Rollenzuweisungen für einzelne Interessentengruppen einzurichten wäre jedoch zu aufwändig. Die bisher fehlende Flexibilität bringt das Konzept der Attribute-Based Access Control (ABAC). Dieses beruht auf der Überlegung: Es nicht in jedem Fall nötig, die Identität der Benutzer zu kennen, sondern man kann Berechtigungen auch aus festgestellten Attributen ermitteln. Wichtig ist dabei, diese Attribute dynamisch zu vergeben: Berechtigungen werden den Nutzern nicht wie im RBAC-Modell statisch zugewiesen; vielmehr können sie sich aufgrund von Informationen, die auch aus dem Kontext stammen können, laufend verändern. Dabei ist der Unterschied zwischen den beiden Konzepten gar nicht so groß: ABAC ergänzt RBAC und ist flexibler. Denn in dem Augenblick, in dem eine Identität Berechtigungen anfordert, prüft eine ABAC-fähige IDM-Lösung zusätzlich zu definierten Rollen die aktuelle Situation und trifft auf dieser Basis die Entscheidung. Ein klassisches RBAC-Modell ist hingegen statisch, was bedeutet, dass alle möglichen Situationen vordefiniert sein müssen; eine Entscheidung über den Zugang fällt dann entsprechend der Übereinstimmung mit der so vordefinierten Rolle. Ein Beispiel kann den Unterschied verdeutlichen: Wird in einem Finanzsystem eine Transaktion angefragt, so muss sich der Anfragende üblicherweise authentifizieren, etwa durch Eingabe von PIN und TAN. Ist diese Prozedur erfolgreich, wird die Transaktion durchgeführt - das wäre klassisches RBAC. Würde nun eine weitere Transaktion angefragt, die jedoch aus einem anderen Land käme, so wäre diese Transaktion im RBAC-Modell wie die vorherige zulässig: Im Rollenprofil ist die Berechtigung zur Durchführung von Transaktionen vorgesehen - geprüft werden hier nur Identität und Rechte des Nutzers. ABAC kann weiter gehen und damit mehr Sicherheit schaffen: Es könnte als zusätzliches Anfragekriterium oder -attribut den Standort des Anfragenden auswerten. Man kann in aller Regel nicht aus Land A anfragen und wenig später aus Land B - Schlussfolgerung: Da stimmt was nicht; die Transaktion wird daher zunächst einmal nicht zugelassen. Diesen Fall könnte man natürlich auch im RBAC-Modell abbilden, indem der Standort als Merkmal der Rolle definiert wird. Aber bei RBAC bliebe die Sache statisch: Sie würde, zwar erweitert, so und nicht anders bis zur nächsten Änderung bestehen bleiben. Dies hätte für den Nutzer dann unter Umständen Einschränkungen zur Folge: Womöglich ist er ja tatsächlich grenzübergreifend unterwegs und kann nun nicht über sein Geld verfügen, weil das System einen Verdachtsfall unterstellt. Im ABAC-Modell lassen sich hingegen mit geringem Aufwand weitere Kriterien und Attribute einführen, sodass sich das Modell immer weiter verfeinern lässt. Über diese Attribute sind dann auch Kontextinformationen auswertbar, im angenommenen Beispiel vielleicht so: Hat der Anfragende beispielsweise kürzlich im selben System eine Transaktion für eine Flugbuchung ausgeführt, so wäre die Transaktion doch wieder zulässig. Außerdem könnte eine ABAC-Lösung beim Reisebüro nachprüfen, ob eine Reise in die entsprechende Region gebucht wurde. Zusätzlich könnte sie GPS-Daten auswerten oder auch Social-Media-Informationen. Dies gilt natürlich nicht nur für Finanztransaktionen. Auf ähnliche Weise lassen sich beispielsweise Interessenten differenziert behandeln: Man könnte ihnen eingeschränkte Rechte einräumen, entsprechend bestimmter Attribute, beispielsweise Alter und Wohnort, oder auf der Basis verfügbarer Kontextinformationen. Natürlich lassen sich alle diese Anforderungen auch im klassischen Modell lösen. Externe Mitarbeiter haben andere Rollen als interne, und oft richten Unternehmen für Kunden und Mitarbeiter separate Identifizierungssysteme ein, die dann konsequenter auf verschiedenen Anwendungen laufen. Doch mit jeder Variante, mit jedem Sonderfall wird die Sache komplizierter, das Geflecht der Rollen und Rechte wird größer und unübersichtlicher. Versucht man die Dynamik in einem statischen Modell - ansatzweise - nachzubilden, so würde dies zu einer unüberschaubaren Menge von Regeln führen; diese könnten die möglichen Anwendungsfälle aber doch nicht komplett abdecken und damit Einschränkungen für den Anwender bedeuten. Zudem kann die IT eine große Menge von Regeln nicht mehr überschauen und warten. Bedingt durch die hohe Komplexität treten darüber hinaus Sicherheitslücken oder unbeabsichtigte Rechtekombinationen auf. ABAC ist durch sein dynamisches Konzept besonders für Anwender geeignet, die sich in einer Cloud-Umgebung oder im Internet of Things flexibel bewegen und eine wechselnde Anzahl von Geräten und Zugriffsmethoden mit unterschiedlichen Möglichkeiten nutzen. Dennoch ist RBAC damit nicht obsolet: Es bleibt ein guter und verlässlicher Ansatz für die klassische IT-Umgebung, die auf statischen Geschäftsprozessen beruht. Doch auch solche Geschäftsprozesse werden sich in Zukunft verändern, viele werden sich an die Dynamik der Anwender anpassen müssen. Dies wird sich auch auf das Management der damit verbundenen Identitäten auswirken. Langfristig wird RBAC im ABAC-Modell mehr oder weniger aufgehen.
Lesen Sie mehr zum Thema
