Attestierung und Rezertifizierung

<Hier kommt der Titel rein> Whitepaper Attestierung und Rezertifizierung copyright:23.11.2008. www.activeentry.com Attestierung & Rezertifizierung 1 Inhalt 1 INHALT 2 2 MOTIVATION 3 3 ATTESTIERUNG & REZERTIFIZIERUNG 4 4 BEST PRACTICES 5 4.1 REIFEGRADE DER PROZESSE 5 4.2 TECHNISCHE UMSETZUNG 6 5 DASHBOARD FÜR REZERTIFIZIERUNGSPROJEKTE 8 6 ZUSAMMENFASSUNG 9 copyright: 17.09.2009. www.activeentry.com 2 copyright: 23.11.2008. www.activeentry.com Attestierung & Rezertifizierung 2 Motivation Im Rahmen wachsender Transparenzanforderungen wächst der 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 Rezertifizierungsprozesse etablieren müssen. Diese sollen hier mit den zugehörigen Best Practices detailliert vorgestellt werden. copyright: 17.09.2009. www.activeentry.com 3 copyright: 23.11.2008. www.activeentry.com Attestierung & Rezertifizierung 3 Attestierung & Rezertifizierung Zwei Begriffe – eine Bedeutung? Im Umfeld von Identity Management und User Provisioning Projekten werden Attestierung und Rezertifizierung häufig vermischt. Deshalb beginnen wir hier mit einer Definition, bevor wir Best Practices für die zugehörigen Prozesse beschreiben. Attestierung bezeichnet zunächst nur einmal den Vorgang der Bestätigung, dass ein Sachverhalt korrekt ist. Beispiele aus der IT sind: • Die Zuordnung von Zugriffsberechtigungen an einzelne Personen. Solche Berechtigungen können AD-Gruppenmitgliedschaften, SAP-Rollen und Sammelrollen sein. • Die Zuordnung technischer Rollen bzw. Zugriffsberechtigungen zu solchen Rollen oder Gruppen, z.B. 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-Regel (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 Attestierung vorzunehmen, bezeichnet man als Rezertifizierung, weil dabei in festgelegten Zeitabständen bereits attestierte bzw. genehmigte Zuweisungen neu bestätigt werden. In aktuellen GRC-Projekten hat die Rezertifizierung hohe Priorität, 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. copyright: 17.09.2009. www.activeentry.com 4 copyright: 23.11.2008. www.activeentry.com Attestierung & Rezertifizierung 4 Best Practices 4.1 Reifegrade der Prozesse Im Folgenden wollen wir die „Reifegrade“ von Rezertifizierungspolicies in 4 Stufen unterteilen: Stufe 0: Keine Rezertifizierung, kein regelmäßiges Account Reporting Stufe 1: Rezertifizierung als regelmäßig wiederkehrendes Projekt Typischerweise werden hierbei z.B. ein Mal jährlich Reports erstellt, z.B. wer hat welche Berechtigung in welchem System? Dabei erhält jeder Abteilungsleiter die Berechtigungsreports aller ihm zugeordneten Mitarbeiter und bestätigt diese bzw. korrigiert sie. Damit sind zunächst Minimalanforderungen an Transparenz- und Dokumentationspflichten erfüllt. Trotzdem hat dieses Verfahren mehrere 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 verantwortlichen Mitarbeitern zugeleitet. Durch die Rezertifizierung 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 rein technische Bezeichnungen haben. Dadurch steigt die Versuchung, pauschal alle Berechtigungen zu bestätigen, ohne zu wissen, was sie bedeuten. • Die Rezertifizierung erfolgt auf Grundlage einer Momentaufnahme der Berechtigungen. Kritische Berechtigungskombinationen, die ein Mitarbeiter temporär seit der letzten Rezertifizierung hatte, werden dabei nicht erfasst. Stufe 2: Rezertifizierung von Einzelberechtigungen über automatisierte Prozesse und Antrags- und Genehmigungsworkflows Eine weitestgehende Kontrolle über die Korrektheit der Zuweisung von Berechtigungen wird nur mit durchgängigen Prozessen erreicht, bei denen die initiale Rechtevergabe über einen gut dokumentierten Antrags- und Genehmigungsworkflow legitimiert wird, das „Behalten“ der Berechtigungen über Rezertifizierungen. Das wird am besten durch den Einsatz eines Identity Management Systems erreicht, das über eine Workflowkomponente verfügt. Dabei kann die Rezertifizierung über dasselbe Workflowsystem abgewickelt werden wie die Rechtevergabe. copyright: 17.09.2009. www.activeentry.com 5 copyright: 23.11.2008. www.activeentry.com Attestierung & Rezertifizierung Auf dieser Entwicklungsstufe können einige Nachteile von Stufe 1 ausgeglichen werden: Jede Berechtigungsvergabe erfolgt über einen definierten und dokumentierten Prozess, wodurch die Stichtagsproblematik überwunden wird. Die Automatisierung der Berechtigungsverwaltung schafft gleichzeitig eine valide Datenbasis für beliebig getaktete Überwachungsmaßnahmen. Lediglich die Transparenz, dass ein Vorgesetzter auch versteht, was er genehmigt bzw. attestiert, wird dadurch noch nicht geschaffen, ebenso wenig wie eine Bedienerfreundlichkeit, da weiterhin sehr hohe Zahlen von Einzelberechtigungen verwaltet werden müssen. Stufe 3: Durchgängige Rezertifizierung auf mehreren Ebenen über Business Rollen Erst die Schaffung mehrerer Abstraktionsebenen für die Berechtigungsvergabe kann die Usability der Rezertifizierung verbessern. Dafür sind Rollenkonzepte der Königsweg: Die dabei entstehenden Business-Rollen beschreiben dann nur noch Funktionen bzw. 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 Fachspezialisten zuständig, die wissen, welche Berechtigungen zu welcher Business-Rolle gehören. Damit werden nicht nur transparentere Vergabemodelle für größere Organisationseinheiten geschaffen, sondern auch die Informationsflut für diejenigen, die rezertifizieren müssen, verdichtet sich. Gleichzeitig ist es einfacher, organisatorische oder technische Änderungen konsistent für alle Betroffenen wirksam zu machen. Gegebenenfalls kann auch die Definition der Businessrollen selbst den Rezertifizierungsworkflows unterworfen sein. Stufe 4: Ausdifferenzierte Rezertifizierungen nach Gefährdungspotenzialen Aufbauend auf den Möglichkeiten aus Stufe 3 ist es dann vergleichsweise einfach möglich, ein sehr differenziertes System zur Risikobeherrschung zu etablieren, das beispielsweise Attestierungspolicies in Abhängigkeit von Gefährdungspotenzialen vorsieht: Zum Beispiel müssen alle SAP_ALL Berechtigungen bzw. die zugehörigen Fachrollen sehr viel engmaschiger bestätigt werden, als Standardberechtigungen. 4.2 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, das ist im Prinzip ein interaktiver Report für den Attestierungspflichtigen und eine Attestation Policy. In der Attestation Policy wird festgelegt, copyright: 17.09.2009. www.activeentry.com 6 copyright: 23.11.2008. www.activeentry.com Attestierung & Rezertifizierung • welches Objekt • unter welchen Bedingungen • wie und von wem attestiert werden muss. Der Vorteil dieses Vorgehens ist, dass die klassische Rezertifizierung einen Sonderfall von Attestation Policies darstellt, bei denen • Berechtigungen von Personen • in bestimmten Zeitabständen • z.B. vom Abteilungsleiter und/oder Ressourceowner attestiert werden.