Unternehmen sind heute mehr denn je auf agile Applikationen und Systeme angewiesen, um sich auf immer neue Herausforderungen einstellen und neue Chancen nutzen zu können. IT-Abteilungen in Unternehmen sind gefordert, IT-Ressourcen schnell und nahtlos bereitzustellen, sobald sie von den Anwendern benötigt werden. Im Gegensatz zu diesem Wunsch nach Agilität stehen allerdings reale Sicherheitsprobleme, deren Anzahl in den letzten Jahren deutlich zugenommen hat.
Organisationen jeder Größenordnung verwenden unterschiedlichste Ansätze und Systeme zur Identitätsverwaltung und -bereitstellung über den gesamten Lebenszyklus digitaler Identitäten hinweg. Traditionell betrachten Unternehmen diesen Prozess von innen heraus. Durch die rasche Zunahme von (Self-Service-) Portalen, Remote- und Homeoffice-Arbeitsplätzen sowie BYOD-Konzepten sind immer mehr Unternehmen gefordert, auch externen Benutzern und Geräten den Zugriff auf interne Systeme und Applikationen zur Verfügung zu stellen. Die Erfahrung zeigt, dass die Anzahl der zu verwaltenden Identitäten schnell zunimmt, was zu einem Dilemma führt: Ist die gegenwärtige Infrastruktur zur Verwaltung der internen Identitäten in der Lage, die für die Registrierung und Pflege externer Identitäten erforderlichen Interaktionen zu bewältigen? Und: Sind die etablierten Rollen- und Rechte-Konzepte flexibel genug, um diesen steigenden Erwartungen gerecht zu werden?
DAC, MAC, RBAC und ABAC: Was eignet sich für wen?
Die zunehmend komplexen Beziehungen zwischen Identitäten und Ressourcen definieren die Sicherheit ganz neu und lassen uns auf ganz unterschiedliche Weise über Zugriffsverwaltung nachdenken. Sicherheit beginnt damit, dass ein Subjekt (ein Mitarbeiter oder ein Programm) Zugriff auf eine Ressource (eine Anwendung, ein System oder eine Datei) über Zugriffskontrollen erhält. Zugriffskontrollen sind die Beschränkungen auf Systemebene, die sicherstellen, dass ausschließlich die richtigen Identitäten den richtigen Zugang zu den festgelegten Ressourcen haben.
Die meisten Identity und Access Management Produkte bieten eine Vielzahl von Methoden zur Implementierung und Überwachung der Zugriffsteuerung, wobei unterschiedliche Terminologien zur Beschreibung dieser Methoden verwendet werden. Alle Formen der Zugriffskontrolle lassen sich jedoch letztlich auf eines von vier klassischen Modellen zurückführen:
- Discretionary Access Control (DAC)
- Mandatory Access Control (MAC)
- Role Based Access Control (RBAC)
- Attribute Based Access Control (ABAC)
Auch wenn sich dieser Artikel primär auf die RBAC- und ABAC-Modelle konzentriert, möchten wir die ersten beiden der Vollständigkeit halber kurz beschreiben.
MAC – Mandatory Access Control
MAC beschreibt eine Regel-basierte Zugriffskontrolle. Die Entscheidungen über Zugriffsberechtigungen werden nicht nur auf der Basis der Benutzer-Identität und der Ressource, auf die zugegriffen werden soll gefällt, sondern aufgrund zusätzlicher Regeln und Eigenschaften.
Die beiden o.g. Methoden, einem Benutzer direkt Rechte und Zugriffe auf Ressourcen zu geben, haben sich durch die steigende Zahl von Benutzern schnell als unübersichtlich und daher fehlerträchtig herausgestellt. Die auf Benutzerrollen basierende Role Based Access Control soll die Verwaltung von Zugriffsrechten abstrahieren und so vereinfachen.
DAC – Discretionary Access Control
DAC ist ein Sicherheitskonzept für IT-Systeme bei dem die Entscheidung, ob auf eine Ressource zugegriffen werden darf, allein auf der Identität des Akteurs basiert. Das heißt, die Zugriffsrechte auf Ressourcen werden pro Identität festgelegt. Beispielsweise kann ein Administrator einem anderen Benutzer nach eigenem Ermessen manuell Zugriff auf eine Datei oder Anwendung gewähren.
RBAC – Role Based Access Control
RBAC steuert den Zugriff auf der Grundlage der Rollen, die Benutzer innerhalb des Systems haben, und der Regeln, die festlegen, welcher Zugriff für welche Benutzer in bestimmten Rollen erlaubt ist. In modernen IAM-Lösungen ist typischerweise „eine Rolle“ auch „eine Gruppe“. Eine Rolle ist eine logische Gruppierung von einem oder mehreren Benutzern mit gemeinsamen Zugehörigkeiten, wie bspw. die gleiche Abteilung, Klasse, Alter, physischer Standort oder Benutzertyp.
Der große Vorteil von RBAC im Vergleich zu DAC und MAC ist, dass über das Rollen-/Rechtekonzept einzelnen Identitäten sehr leicht (Gruppen-) Rechte zugewiesen werden können.
Der Nachteil dieser Flexibilität liegt auf der Hand: An eine Rolle sind typischerweise 1 bis n Gruppenzugehörigkeiten gebunden. So ist bspw. ein Gruppenleiter im Personalbereich Mitglied in den Gruppen „Personal“, „Gruppenleiter“, „Standort xyz“, „Fachapplikation Personal“, usw.
In der Praxis ist jeder Benutzer Mitglied in mehreren Gruppen. Hat ein Unternehmen 20 Abteilungen mit jeweils 15 organisatorischen Rollen je Abteilung, müssen beim RBAC-Ansatz 20 x 15 = 300 Gruppen eingerichtet und gepflegt werden. Dieses Beispiel verdeutlicht, wie schnell die Anzahl an Gruppen bereits bei mittelständischen Unternehmen wächst.
Die Folge: Eine Zugriffssteuerung per RBAC kann insbesondere bei größeren Unternehmen schnell unübersichtlich werden. Erschwerend kommt hinzu, dass bei diesem Ansatz sowohl die Benutzer, die Ressourcen und die Administratoren Zugang zum gleichen Verzeichnisdienst benötigen, in dem die Identitäten verwaltet werden. Dies ist eine deutliche Einschränkung in einer zunehmend Cloud-orientierten Welt, in der die Organisation der Benutzer eine andere ist, als die des Serviceproviders.
ABAC – Attribute Based Access Control
Bei ABAC wird der Zugriff auf eine Ressource anhand von Attributen der Identität, der Ressource, dem Zustand der Systemumgebung sowie weiteren Attributen gesteuert.
Zuerst wird die Identität mit einem Identity und Access Management System validiert und authentifiziert. Anschließend werden dem Client die entsprechenden Attribute bereitgestellt und mittels einer digitalen Signatur beglaubigt. Wenn eine Identität auf eine Ressource zugreifen möchte, werden sowohl die Signatur als auch die bereitgestellten Identitäten überprüft. Sind diese gültig, wird anhand der auf die Attribute anzuwendenden Sicherheitsregeln überprüft, ob der Zugriff auf die Ressource zulässig ist.
Ein Beispiel für ABAC wäre, dass nur Benutzer, die type=Mitarbeiter sind und eine department=HR haben, Zugang zum HR/Payroll-System haben, und zwar nur während der Geschäftszeiten innerhalb der gleichen Zeitzone wie das Unternehmen.
Im Kern ermöglicht ABAC eine feingranulare Zugriffskontrolle, die deutlich mehr Parameter/Attribute in eine Zugriffskontrollentscheidung einbezieht. Jedes verfügbare Attribut im Verzeichnis kann allein oder in Kombination mit einem anderen verwendet werden, um den richtigen Zugriff auf eine Ressource zu definieren.
ABAC ist nicht nur das flexibelste und leistungsfähigste der vier Zutrittskontrollmodelle, sondern auch das komplexeste. Die attributbasierte Zugriffskontrolle kommt insbesondere bei neuen Verfahren wie OAuth und OpenID zum Einsatz.
RBAC vs. ABAC
1. ABAC eignet sich besser für feingranulare Zugangskontrollen
Wenn Sie auf feingranulare Zugriffskontrollen verzichten können, ist RBAC eine gute Wahl. Bspw. wenn Sie allen Mitarbeitern den Zugriff auf Google oder allen Vertragspartnern Zugriff auf E-Mails gewähren möchten.
Wenn Sie mehr Granularität benötigen, ist ABAC die bessere Wahl. Bspw. wenn Sie nur Mitarbeitern in einer bestimmten Lokation und nur zu bestimmten Uhrzeiten den Zugriff auf Google gewähren möchten. Ein Rollenattribut beinhaltet den Namen einer Rolle, die Zuteilungsinformation und einen (oder mehrere) optionale Parameter. Das Ergebnis ist eine feingranulare Definition der Zugriffsrechte und verhindert eine Explosion von Rollen, wie in dem o.g. Beispiel.
2. ABAC skaliert besser
Als Verzeichnisdienst, in dem die Identitäten gespeichert werden, kommt häufig ein LDAP-Server zum Einsatz. Beim Zugriff eines Benutzers auf eine Ressource nach dem RBAC-Prinzip muss der LDAP-Server die Zugriffskontrollen in allen Gruppen parsen, in denen der Benutzer Mitglied ist. Bei größeren Organisationen mit vielen Benutzern und Gruppen kann dies die Performance negativ beeinflussen.
3. Weniger ist mehr
Wenn Sie viele sehr komplexe RBAC- und/oder ABAC-Filter erstellen, machen Sie wahrscheinlich etwas falsch. Eine IAM-Strategie kann Ihnen helfen, Ihre Verzeichnisdaten so zu strukturieren, dass die Notwendigkeit, komplexe Filter/Abfragen zu entwickeln, minimiert wird.
4. Teilen und herrschen
Sie können RBAC und ABAC gemeinsam in einem hierarchischen Ansatz verwenden. Zum Beispiel können Sie mittels RBAC steuern, wer auf welche Anwendungen überhaupt zugreifen kann. Mit ABAC können Sie feingranular die Berechtigung innerhalb der Anwendung steuern.
Agiles Rollenmanagement mit SecuRole®
SecuRole® basiert auf ABAC und ist ein innovativer Ansatz, um die Limitierungen von RBAC zu überwinden und ein agiles Rollenmanagement zu ermöglichen.
SecuRole® – Rollenmanagement in 4 Schritten
- Eine Rolle wird durch ein Attribut in einem Benutzerobjekt definiert. Dadurch können Benutzerobjekte sehr viel einfacher und schneller verarbeitet werden, als lange Mitgliederlisten in vielen Gruppen. SecuRole® ist schneller und skaliert besser.
- Ein Rollenattribut beinhaltet den Namen einer Rolle, die Zuteilungsinformation und optionale Parameter. SecuRole® vereinfacht die Festlegung feingranularer Zugriffsrechte deutlich.
- Jedes Rollenattribut ist als JSON-Objekt definiert und kann sehr leicht ergänzt werden, wie bspw. um das Gültigkeitsdatum oder den Genehmiger einer Rolle. SecuRole® basiert auf Standard JSON-Objekten und ist einfach zu implementieren.
- Jedes JSON-Objekt wird digital signiert und kann als JSON-Web Token genutzt werden. Dies ermöglicht eine sehr hohe Sicherheit, weil die Rolleninformationen vertrauenswürdig sind. Jeder, der der Signatur vertraut, vertraut auch der Zuweisung. SecuRole® steigert die Sicherheit.
DAC, MAC, RBAC, ABAC, SecuRole, Login-Master, inTension, syntlogo, Rollenmanagement,
RBAC and beyond – Access Management für agile Unternehmen. Quelle: Login-Master
Weitere Informationen zu SecuRole® finden Sie HIER.