Entwurf einer anwendungsunabhängigen Zugriffskontrolle mittels ...

Zugriffskontrollverfahren und AOP
Eine Weiterentwicklung zum „Core RBAC“ Modell ist das „Hierarchical RBAC“ (vgl.
[FSG01] S. 234 ff.). Es führt hierarchische Rollen ein, so dass eine Rolle die
Eigenschaften einer anderen Rolle erben kann. So kann man erreichen, dass die
Managerrolle alle Eigenschaften der Vertriebsleiterrolle erbt. Allerdings muss darauf
geachtet werden, dass nicht die Kombination zweier Rollen dazu führt, dass man Rechte
erhält, die außerhalb der Zuständigkeit der Rollen liegen. Beispielsweise darf die
Kombination der Rollen „Betriebsprüfer“ und „Sachgebiet 1“ nicht dazu führen, dass
man plötzlich schreibenden Zugriff auf das Sachgebiet 1 erhält. Um dies zu verhindern,
wurde das Modell zum „Constrained RBAC” Modell erweitert. Dieses erlaubt die
Modellierung von Zuständigkeiten, die nicht verletzt werden dürfen.
Ein solches rollenbasiertes Zugriffsmodell kann in Form eines Frameworks entworfen
werden, das ein „Application Programming Interface“ (API) anbietet. Mittels dieses
API kann man die Zugriffsfunktionalität im Anwendungsprogramm nutzen, indem man
die Funktionen zur Verwaltung der Rollen und für die Zugriffsprüfungen in das
Anwendungsprogramm programmiert (vgl. [Fis02] S. 139). Für eine anwendungsunabhängige
Sicherheitslösung ist die Nutzung eines solchen Frameworks aber nicht
geeignet, da Änderungen (oder der Austausch) an der Sicherheitslösung auch
Änderungen am Anwendungscode verursachen.
3.1.5 Policy-basierte Zugriffskontrollverfahren
3.1.5.1 Autorisierungs-Policies
Ein sehr flexibler Ansatz ist der Einsatz von Policies. Autorisierungs-Policies werden
verwendet, um zu festzulegen, auf welche Dienste oder Ressourcen ein Benutzer
zugreifen kann (vgl. [DBS02] S. 3). Sie entsprechen Zugriffsregeln, d.h. sie definieren
Aktivitäten die ein Subjekt mit einem Software Objekt durchführen darf oder auch
nicht. Solche Policies eignen sich sehr gut für den Zugriffsschutz in verteilten
Systemen, in denen die Zugriffskontrolle in einer Vielzahl von heterogenen
Komponenten implementiert ist (vgl. [DBS02] S. 1 ff.).
Anstelle des Benutzers kann auch eine Benutzerrolle definiert werden, so dass man
diesen Ansatz mit einem rollenbasiertem System kombinieren könnte.
22