IAM-Projekte – Kennzahlen statt ROI

Privilegierte Accounts

Derzeit wächst in vielen Unternehmen das Bewusstsein, dass privilegierte Accounts ein Sicherheitsrisiko darstellen. Nicht nur in regulierten Branchen erkennt man, dass Administratoren-Accounts, die von mehreren Personen genutzt werden nicht mehr existieren dürfen: Jeder Administrator muss zukünftig mit personalisierten Accounts arbeiten. Oft werden dezidierte Privileged Account/Access Management (PAM) Produkte eingeführt, die den privilegierten Usern eigene Sessions bereitstellen und sie damit sogar davon entlasten, sich komplexe Admin-Passwörter zu merken. Allerdings ist es auch möglich, das Management der Accounts selbst im IdM abzubilden.

In jedem Fall ist es sinnvoll, Kennzahlen für eine initiale Bestandsaufnahme sowie für die Formulierung von kurz- und langfristigen Zielen zu erheben. Für die folgenden Accountarten sollten die Anzahl erhoben werden und der Anteil gemanagter Accounts – unabhängig davon ob das mit einem PAM-Produkt oder dem IdM-System erfolgt:

• Admin-Accounts: Hier unterstellen wir, dass diese Accounts bereits auf personengebundene Accounts „umgestellt“ wurden. Sonst müsste auch gezählt werden, wie viele Personen mit geteilten Admin-Accounts arbeiten.
• System Accounts: Bei diesen Accounts, die meistens von Applikationen verwendet werden, muss mindestens ein Verantwortlicher hinterlegt sein. Das kann eine Person oder auch eine Rolle sein. Dabei muss sichergestellt sein, dass beim Ausscheiden einer verantwortlichen Person immer ein Nachfolger bzw. Stellvertreter bekannt ist.
• Emergency oder Firefighter Accounts: Diese werden prinzipiell nur zeitlich befristet vergeben um akute Probleme zu lösen.
• Externe: Hierbei handelt es sich um privilegierte Zugänge von externen Partnern, also von IT-Dienstleistern oder auch Produktherstellern die im Supportfall auf Systeme zugreifen müssen.

Bild 5: Der Reifegrad des Managements privilegierter Zugriffe kann für jeden Accounttyp gesondert geplant werden.

Für jeden dieser Account-Typen können in einer Roadmap kurz- und mittelfristige Ziele vorgegeben werden, die geprägt werden von den Sicherheitsanforderungen sowie den Aufwand. Der rein technische Aufwand ist dabei oft vergleichsweise klein. Häufig verzögern historisch gewachsene und schlecht dokumentierte Strukturen bei den Systemaccounts ein durchgängiges «Management» und muss durch einen organisatorischen Prozess begleitet werden.

Businessrollen machen Sinn – aber nicht zuviele davon!

Immer mehr Unternehmen führen Geschäftsrollen ein, die möglichst viele Einzelberechtigungen aus unterschiedlichen Applikationen beinhalten. Das fördert die Transparenz und reduziert den Verwaltungsaufwand. In stark regulierten Branchen, beispielsweise Banken erzwingen mittlerweile die Aufsichtsbehörden die Einführung von Geschäftsrollen. Ein gängiges Missverständnis dabei ist: In keinem Fall wird gefordert dass ausnahmslos alle Berechtigungen über Geschäftsrollen vergeben werden: Diese Forderung würde nämlich zu einer «Explosion» der Anzahl von Geschäftsrollen führen und die Transparenz sogar verschlechtern anstatt zu verbessern.

Ohne an dieser Stelle auf Details der Einführung von Geschäftsrollen einzugehen unterscheiden wir die folgenden Zuweisungswege, über die Benutzer Berechtigungen erhalten (haben):

1. Direktzuweisung ohne klare Prozesse, das heißt Zuweisung auf «Zuruf» oder über Freitextbestellungen, die dann ohne festgelegte Regeln von einem Adminteam o.ä. umgesetzt werden. Dieser Zuweisungsweg ist bei Weitem der schlechteste, spiegelt in vielen Organisationen allerdings den aktuellen Status quo wider.
2. Einzelzuweisungen über einen klar geregelten Antragsprozess: Berechtigungen werden beantragt, bei Bedarf genehmigt und dann manuell oder automatisch zugewiesen.
3. Geschäftsrollen: Möglichst viele Einzelberechtigungen werden durch Geschäftsrollen gebündelt und dann entweder über Regeln zugewiesen oder über Anträge bzw. Bestellungen. Die Regeln können sich auf Organisationszugehörigkeiten, Standorten, Funktionen etc. beziehen. Grundsätzlich empfehlen wir Geschäftsrollen über beide Wege zuweisbar zu machen.
4. Regeln / Policies: Dabei werden Berechtigungen direkt in Abhängigkeit von Organisationszugehörigketen o.ä. vergeben. Beispielsweise kann die automatische Zuweisung von Abteilungslaufwerken über Regeln erfolgen.

Ein optimaler Zielzustand ist derjenige, der möglichst viele Berechtigungen über Regeln und Geschäftsrollen zuweist und gleichzeitig die Anzahl dieser Regeln und Geschäftsrollen nicht zu sehr wachsen lässt.

Bild 6 zeigt daher einen möglichen Fahrplan der Reifung von Berechtigungszuweisungen: Initial sind bereits einige Regeln umgesetzt, ansonsten ist allerdings nicht nachvollziehbar, wer warum und wann welche Berechtigung erhalten hat. In einer Pilotphase wird ein Teil der Berechtigungen über ein strukturiertes Verfahren «bestellbar» gemacht. In Phase 3 erfolgt der Ausbau des Bestellsystems und gleichzeitig die Pilotierung von Geschäftsrollen. Im Zuge der Reifung der Prozesse wird sowohl das Rollenmanagement sowie das Regelwerk werden ausgebaut und idealerweise alle anderen Berechti-gungen über einen gut dokumentierten Antragsprozess geführt.

Bild 6: Der Reifegrad des Managements privilegierter Zugriffe kann für jeden Accounttyp gesondert geplant werden.