Modell zur Erfassung generischer IAM-Prozesse

Angelehnt an die Gartner Group wird ein Modell zur Identifikation und Gruppierung aller für das IAM relevanter Prozesse vorgeschlagen. Gartner definiert für die Gruppierung von IAM-Prozessen drei verschiedene Gruppen, die für das vorliegende Modell übernommen wurden.

Gruppen

Access Model:
Das Access Model beschreibt den Rahmen, das Framework für ein IAM System. Zentrale Objekte dieser Gruppe sind Rechte, Rollen, Gruppen und Policies.
Workflow Model:
Rechte, Zugänge etc. müssen kontrolliert vergeben werden. Die entsprechenden Vergabeprozesse werden im Workflow Model gruppiert. Das zentrale Objekt ist demnach ein Request, also eine Anfrage.
Identity Model:
Hier werden alle Prozesse bezüglich konkreter Identitäten gruppiert. Folglich ist das zentrale Objekt dieser Prozessgruppe die Identität bzw. Ressource. IAM-Suiten leisten hier die größte Unterstützung. Sie versuchen eine Großzahl der hier angesiedelten Prozesse zu implementieren.

Elementare Prozesse

Die elementaren Prozesse werden mit der nebenstehenden Grafik veranschaulicht. Es handelt sich um die bekannten Operationen bezüglich der zentralen Objekte der jeweiligen Kategorie.

Erstellen

Der Erstellen-Prozess befasst sich mit der strukturierten Erstellung eines neuen Objekts der jeweiligen Kategorie. Im Falle des Access Models werden hier die Prozesse definiert, die die Erstellung des Access Models beinhalten. Häufig ist hier die Erstellung eines Role-based Access (RBAC) Models gemeint. Möglich sind aber auch andere Modelle, wie zum Beispiel eine Role-based Management Matrix.
Ganz unterschiedliche Tools unterstützen die verschiedenen Workflows in Unternehmen. Gerade die Vergabe von Rechten und Rollen ist in vielen Unternehmen ein komplexer Workflow, der etliche Prüffunktionen beinhalten kann. Es ist daher unbedingt erforderlich diese Workflows zu definieren, zu modellieren und innerhalb des Unternehmens zu kommunizieren. Demzufolge wird hier festgelegt, wie mit konkreten Anfragen bezüglich Rechten, Rollen, Zugängen etc. umgegangen wird.
Die Ertellung konkreter Identitäten ist nicht weniger komplex. Hier wird der Output des Access Models (die definierten und im System angelegten Rechte, Rollen, Gruppen etc.) und des Workflow Models verarbeitet. Konkret beschäftigen sich diese Prozesse mit dem erstmaligen Mapping von Teilen des Access Models.

Ändern

Selbstverständlich müssen in einer dynamischen Umgebung die erstellten Objekte auch geändert werden können.
So wird für jedes Objekt des Access Models festgelegt, unter welchen Umständen es zu ändern ist. Ebenso müssen Workflows von Zeit zu Zeit geändert werden. Workflows werden häufig dann geändert, wenn sie die Organisation des Unternehmens ändert. Dies kann beispielsweise durch Zukäufe, Out- und Insourcing oder aber auch durch interne organisatorische Änderungen der Fall sein. Die sicherlich am häufigsten frequentierten Prozesse dieser Kategorie sind alle Änderungsprozesse bezüglich Identitäten. Die Gründe für Änderungen der Attribute sind sehr vielfältig. Beispielsweise müssen Rechte und Rollen einer bestehenden Identität gewährt oder verweigert werden. Anderseits bedarf es häufig auch Änderungen bezüglich der weiteren Attribute einer Identität, wie z. B. Addressdaten oder Kontoverbindungen.

Nutzen

Workflows werden immer dann genutzt, wenn Anfragen bearbeitet werden. Durch den Einsatz der erstellten und definierten Workflows werden diese Anfragen entweder positiv oder negativ beantwortet.
Für jegliche Interaktion mit Informationssystemen werden Identitäten genutzt. Häufig zeigt sich die Nutzung von Idenitäten in Form von Authentifizierungen gegenüber EDV Systemen oder Autorisierungsprüfungen durch die Systeme. Identitätsinformationen können von verschiedensten Systemen aber auch direkt genutzt werden. Man denke hier beispielsweise an Bezahlvorgänge, die mit Idenitäten ausgeführt werden können. Die Identität hält in diesem Fall Informationen zur Bezahlung, wie Kontoverbindung oder Kreditkartennummer, vor.

Berichten

Den größten Stellenwert für Prozesse bezüglich Compliance und Auditing hat das Logging. In einem IAM-System müssen alle Events, Aktionen und Vorgänge in einem möglichst zentral gehaltenen Speicher protokolliert werden. Daraus ergibt sich die Forderung, dass alle angesprochenen Aktionen und Prozesse bereits bei deren Definition und Modellierung sämtliche Ereignisse loggen. Nur so ist Auditing und Monitoring möglich. Aufgrund der Loggingdaten können dann automatisch vom System Warnmeldungen und Ähnliches generiert werden. Angriffe auf das IAM-System bzw. Fehlnutzungen können so schneller erkannt werden.
Reports spiegeln dabei immer die Aktuelle Situation bei der Erstellung des Reports wieder. So ein Snapshot zeigt z. B. den aktuellen Status des Access Models. Aus ihm kann dann entnommen werden welche Regeln, Rollen, Gruppen und Policies aktuell definiert sind und wie sie genau ausschauen. Der Administrator bekommt so schnell einen Überblick ohne dabei konkrete Identitäten betrachten zu müssen. Diese Informationen werden von Reports bezüglich des Identity Models bereitgestellt. Hier kann der Administrator prüfen, welche Rechte konkret im System vorhandene Identitäten besitzen und wann sie das letzte mal von diesen Rechten gebrauch gemacht haben. (Authentifizierung und Autorisierung werden ebenfalls geloggt.)
Grundlage zur Einschätzung des Service Level Agreements (SLA) bilden Reports der Workflow Prozessgruppe. Sie geben Aufschluss darüber, wie häufig Workflows frequentiert wurden und wie die einzlnen Anfragen behandelt wurden. Es kann festgestellt werden, an welchen Stellen das SLA verbessert werden muss.

Putting all together

Damit ergibt sich das oben stehende Schaubild. Alle Events, die innerhalb von IAM-Prozessen auftreten werden in einem Loggingspeicher protokolliert. Dieser bildet die Basis für Auditing-Prozesse. Alle für das IAM relevanten Prozesse können den einzelnen Gruppen zugeordnet werden und damit eindeutig zugeordnet werden. Zur Erfassung und Modellierung der Prozesse müssen die Prozesse selbst auch strukturiert erfasst werden. Für die Modellierung wird das Konzept der ereignisgesteuerten Prozessekette (EPK) vorgeschlagen. Aus dem COBIT Framework wurde ein Rahmen zur Prozessdefinition extrahiert.

Prozessidentifikation

Zur geordneten Prozessidentifikation müssen die Prozesse mit eindeutigen IDs versehen werden. Über die IDs können die Prozesse den Kategorien zugeordnet werden. Dabei erhält jeder der drei Kategorien einen eindeutigen Bezeichner, der aus den Initialen der Gruppe gebildet wird.

AM steht für Access Model
WM steht für Workflow Model
IM steht für Identity Model

Prozesse innerhalb der Kategorien werden mit zwei Ziffern durchnummeriert. Dabei setzt sich ein Prozessidentifikator immer aus der zugeordneten Kategorie und der Prozessnummer zusammen. Demzufolge besteht kann jeder Prozess über den vierstelligen Bezeichner identifiziert werden. Zwei Buchstaben geben die Kategorie an und zwei Ziffern verweisen auf den Prozess. Das oben stehende Schaubild beinhaltet bereits die Initialen für jede Gruppe.

Eine weitere Strukturierung von IAM-Prozessen zeigt Die Architektur des generischen Prozessmodells.