Attestierung und Re-Zertifizierung: Bald Pflichtübung – nicht nur für Banken

Im Rahmen wachsender Transparenzanforderungen entsteht ein immer stärkerer Bedarf den Status Quo der IT-Berechtigungen regelmäßig zu überprüfen. Heute sind davon vor allem stark regulierte Branchen wie Banken und Versicherungen betroffen.

Zukünftig werden auch weitere Wirtschaftsbereiche Attestierungs- und Re-Zertifizierungsprozesse etablieren müssen. In der aktuellen Diskussion fehlt häufig ein systematischer Ansatz. Deshalb werden in diesem Beitrag zunächst Begriffsklärungen vorgenommen, bevor Best Practices vorgestellt werden.

Begriffsklärungen

Zwei Begriffe – eine Bedeutung? Im Umfeld von Identity Management und User Provisioning Projekten werden Attestierung und Re-Zertifizierung häufig vermischt, weshalb hier zunächst Definitionen vorgenommen  werden sollen.
Attestierung bezeichnet zunächst nur einmal den Vorgang der Bestätigung, dass ein Sachverhalt korrekt ist. Im gegebenen Kontext wird darunter zumeist verstanden:

• Die Zuordnung von Zugriffsberechtigungen an einzelne Personen. Solche Berechtigungen können AD-Gruppenmitgliedschaften, SAP-Rollen und Sammelrollen sein.
• Die Zuordnung technischer Rollen beziehungsweise Zugriffsbe-rechtigungen zu solchen Rollen oder Gruppen, zum Beispiel die einer AD-Gruppe zugeordneten ACLs oder Transaktionen und Berechtigungscodes, die einer SAP-Rolle zugeordnet sind.
• Die Zuordnung von Systemrollen zu definierten Business-Rollen.
• Die Zuordnung von Personen zu Business-Rollen.

Darüber hinaus ist es möglich, den Prozess der Attestierung weiter zu fassen und beispielsweise auf die folgenden Sachverhalte zu beziehen:

• Bestätigung der Gültigkeit einer Compliance-Regeln (Segregation of Duties bzw. Unverträglichkeitsregel),
• Bestätigung der Gültigkeit eines Genehmigungsworkflows für bestimmte IT-Ressourcen.
• Bestätigung, dass ein Mitarbeiter Teil einer Organisationsstruktur ist.

Den Prozess, regelmäßig eine derartige Attestierung vorzunehmen, bezeichnet man als Re-Zertifizierung, weil dabei in festgelegten Zeitabständen bereits einmal attestierte beziehungsweise genehmigte Zuweisungen neu bestätigt werden. In aktuellen GRC-Projekten hat
die Re-Zertifizierung hohe Priorität, und zwar vor allem in stark regulierten Branchen wie Banken und Versicherungen. Hier besteht zusätzlich hoher Handlungsbedarf, weil bereits etablierte manuelle und papiergebundene Prozesse sehr aufwändig sind.

Best Practices – Reifegrade der Prozesse

Im Folgenden werden die „Reifegrade“ von Re-Zertifizierungspolicies in 5 Stufen unterteilt:

• Stufe 0: Keine Re-Zertifizierung, kein regelmäßiges Account Reporting: „Jeder macht was wer will, und keinem fällt es auf.“
• Stufe 1: Re-Zertifizierung als regelmäßig wiederkehrendes Projekt

Typischerweise werden hierbei zum Beispiel ein Mal jährlich Reports erstellt: Wer hat welche Berechtigung in welchem System? Dann erhält typischerweise jeder Abteilungsleiter die Berechtigungsreports aller ihm zugeordneten Mitarbeiter und bestätigt oder korrigiert sie.
Damit sind zunächst Minimalanforderungen an Transparenz- und Dokumentationspflichten erfüllt. Trotzdem haben diese Verfahren etliche Nachteile:

• Der Aufwand zur Erstellung der Reports ist häufig sehr hoch. Nicht selten werden dazu Export-Dateien aus einzelnen IT-Systemen manuell in Excel-Tabellen konsolidiert und im Extremfall als Ausdruck den Re-Zertifizierungspflichtigen Mitarbeitern zugeleitet. Durch die Re-Zertifizierung identifizierte Änderungen an der Berechtigungsstruktur verursachen einen hohen manuellen Nachbereitungsaufwand.
• Mangelhafte Transparenz: Der Vorgesetzte kann die Reports oft kaum verstehen, da die Einzelberechtigungen in der Regel für ihn kryptische weil rein technische Bezeichnungen haben. Dadurch steigt die Versuchung, pauschal alle Berechtigungen zu bestätigen, ohne zu wissen, was sie bedeuten.
• Die Re-Zertifizierung erfolgt auf Grundlage einer Momentaufnahme der Berechtigungen. Kritische Berechtigungskombinationen, die ein Mitarbeiter temporär seit der letzten Re-Zertifizierung hatte, werden dabei nicht erfasst.
• Stufe 2: Re-Zertifizierung von Einzelberechtigungen über automatisierte Prozesse und Antrags- und Genehmigungsworkflows

Eine weitestgehende Kontrolle über die Korrektheit der Zuweisung von Berechtigungen wird nur durch durchgängige Prozesse erreicht, bei
denen die initiale Rechtevergabe über einen wohldokumentierten Antrags- und Genehmigungsworkflow legitimiert wird, und das „Behalten“
über Re-Zertifizierungen. Das wird am besten durch den Einsatz eines Identity Management Systems erreicht, das über eine Workflowkomponente verfügt. Dabei kann die Re-Zertifizierung über dasselbeWorkflowsystem abgewickelt werden, wie die Rechtevergabe.

Auf dieser Entwicklungsstufe können einige Nachteile von Stufe 1 ausgeglichen werden: Jede Berechtigungsvergabe erfolgt über einen wohl definierten und dokumentierten Prozess, wodurch die Stichtagsproblematik überwunden wird. Die Automatisierung der Berechtigungsverwaltung schafft gleichzeitig eine valide Datenbasis für beliebig getaktete Überwachungsmaßnahmen.
Nachteile sind allerdings: Der Vorgesetzte versteht in der Regeln nicht, was er genehmigt beziehungsweise attestiert. Auch ist die Bedienerfreundlichkeit mangelhaft, da weiterhin sehr hohe Zahlen von Einzelberechtigungen verwaltet werden müssen.

• Stufe 3: Durchgängige Re-Zertifizierung auf mehreren Ebenen über Business Rollen

Erst die Schaffung mehrerer Abstraktionsebenen für die Berechtigungsvergabe kann die Usability der Re-Zertifizierung verbessern. Dafür sind Rollenkonzepte der Königsweg: Die dabei entstehenden Business-Rollen beschreiben dann nur noch Funktionen oder Aufgaben von Mitarbeitern auf der Sprachebene, die für einen Vorgesetzten nachvollziehbar und verständlich ist. Für die Rollenpflege selbst sind dann wiederum die Fach-Spezialisten zuständig, die wissen, welche Berechtigungen zu welcher Business-Rolle gehören.
Damit schafft man nicht nur transparentere Vergabemodelle für größere Organisationseinheiten, sondern verdichtet auch die Informationsflut für diejenigen, die rezertifizieren müssen. Gleichzeitig ist es einfacher, organisatorische oder technische Änderungen konsistent für alle Betroffenen wirksam zu machen.
Selbstredend ist auch die Definition und Pflege der Businessrollen selbst den Re-Zertifizierungsworkflows unterworfen,

• Stufe 4: Ausdifferenzierte Re-Zertifizierungen nach Gefährdungspotenzialen

Aufbauend auf den Möglichkeiten aus Stufe 3 ist es dann vergleichsweise einfach, ein sehr differenziertes System zur Risikobeherrschung
zu etablieren, das beispielsweise Attestierungspolicies in Abhängigkeit von Gefährdungspotenzialen vorsieht: Dass beispielsweise alle SAP_ALL Berechtigungen sehr viel engmaschiger bestätigt werden müssen, als Standardberechtigungen des daily business.
Stufe 3 und 4 haben nur einen Nachteil: Sie setzen eine vergleichsweise hohe organisatorische Reife des Unternehmens voraus: Business-
Rollen müssen erst einmal definiert und gelebt werden und auch das Risikomanagement muss in einen Dialog mit den Fach- und Ressourcenverantwortlichen getreten sein.

Best Practices – Technische Umsetzung

Um alle Reifegrade und Security-Anforderungen durch Toolunterstützung bedienen zu können, wurde ein generelles Konzept entwickelt, das im Kern aus zwei Komponenten besteht: Einem Attestation Object, im Prinzip ein interaktiver Report für den Attestierungspflichtigen,
und eine Attestation Policy. In der Attestation Policy wird festgelegt,

• Welches Objekt
• unter welchen Bedingungen
• wie und von wem

attestiert werden muss. Der elegante Vorteil dieses Vorgehens ist, dass die klassische Re-Zertifizierung einen Sonderfall von Attestation Policies darstellt, bei denen

• Berechtigungen von Personen
• In bestimmten Zeitabständen
• etwa vom Abteilungsleiter und/oder Ressourcenowner attestiert werden.

Allerdings können damit auch wesentlich komplexere Sachverhalte abgedeckt werden:

• Objekte können auch sein: Prozesse, Personalstatus, Antrags- und Genehmigungsworkflows, Zusammensetzungen von Business Rollen, Artikel in IT-Shops, Versionen von Web-Frontends, Complianceregeln etc.
• Trigger können neben der Zeitsteuerung sein: Neuanlage, Änderungen, Versetzungen, Löschung oder Deaktivierung.

Damit wurde in ActiveEntry ein generelles Konzept implementiert, das neben den reinen Re-Zertifizierungsaufgaben alle möglichen Arten der Verwaltung von „Lebenszyklen“ abdeckt: Für Identitäten und Rollen ebenso wie für Prozesse und Konfigurationsdaten.

Das Attestation Object ist das Formular, über das die Attestierung vorgenommen wird. Da es eine Mischform aus Report und statischem Formular ist, wird es auch als „interaktiven Report“ bezeichnet. Das Design dieser interaktiven Reports erweist sich durchaus als nicht trivial: Er muss einerseits dem Attestierungspflichtigen alle für ihn relevanten Informationen darstellen, ohne dabei an Übersichtlichkeit zu verlieren. Zu klären ist vor allem, wie mit „Massen-Attestierungen“ umzugehen ist, die entweder durch umfangreiche Reorganisationen oder durch Re-Zertifizierungen großer Berechtigungsbestände erforderlich werden. Die allgemein üblichen „accept all“ Buttons werden den Anforderungen einer reflektierten Entscheidungsfindung nicht gerecht, bleiben bis auf Weiteres jedoch als „Notlösung“ erhalten.

Wesentlich intelligenter sind organisatorische Ansätze, die eine mehrstufige Attestierung über einsauberes Geschäftsrollenmodell vorsehen. Bei Ihnen muss zum Beispiel der Abteilungsleiter nur noch die Zugehörigkeit von Mitarbeitern zu Rollen (etwa „Einkäufer DACH“) attestieren, ohne die dahinter liegenden Einzelberechtigungen kennen zu müssen.

Dashboard für Re-Zertifizierungsprojekte

Unabhängig davon, ob Attestierung und Re-Zertifizierung als kontinuierlicher Prozess ablaufen, oder eher einen „Einzelprojektcharakter“ haben, sind Dashboards zum Monitoring sehr hilfreich um eine wirksame Statusüberwachung vorzunehmen. Dabei sind Statistiken zum aktuellen Abarbeitungsstatusgenau so wichtig, wie zeitliche Verläufe: Wie hoch ist die eigene Bearbeitungsquote, wie hat sie sich entwickelt, wie stellt sie sich in Vergleich zur Gesamtorganisation beziehungsweise eigenen Organisationsstruktur dar?"

Damit wird nicht nur für den Einzelnen Transparenz geschaffen, sondern die Dashboards helfen auch säumige Prozessbeteiligte zu „incentivieren“.

Resumee

Erhöhte Anforderungen an die Nachvollziehbarkeit der IT-Berechtigungen in Unternehmen und Organisationen machen die Etablierung von Attestierungs- und Re-Zertifizierungsverfahren nötig, für die esunterschiedliche Reifegrade gibt. Um gleichzeitig die Verständlichkeit und damit die Korrektheit der Prozesse zu gewährleisten bietet es sich an, mehrstufige Prozeduren auf der Basis von Businessrollen zu etablieren, die zugleich die Arbeitsbelastung der einzelnen Beteiligten minimiert. Effiziente und sichere Verfahren setzen allerdings auch einen hohen organisatorischen Reifegrad der Organisation voraus, in dem Rollenkonzepte und Risikomanagement harmonisiert sind. Da man das praktisch nirgendwo voraussetzen kann, wird es immer Mischformen unterschiedlicher Reifegrade innerhalb der Organisation geben.

Peter Weierich

Diesen Artikel finden Sie auch in der Ausgabe 2-2009 der it security.