Berechtigungsprüfung jenseits SAP: 8 Systeme, eine Plattform

Wenn der Abschlussprüfer einen „Bestätigungsvermerk mit Einschränkung" andeutet, weil acht Ihrer geschäftskritischen Systeme keinen Berechtigungsprüfungsprozess haben, dann haben Sie kein Compliance-Problem. Sie haben ein GuV-Problem.

Dies ist die Geschichte, wie eine große polnische Telco-Media-Gruppe smartReview über SAP hinaus ausweitete, um acht Nicht-SAP-Systeme abzudecken, in denen der Rest ihrer Buchhaltungs- und Kundendaten verarbeitet wird. Sechs Monate Konzeption und Integration, vier verworfene Architekturalternativen, ein plattformneutrales GRC-Adaptermuster und eine Audit-Verteidigung, die endlich nicht mehr jedes Jahr Dutzende Personentage gekostet hat.

Der Auslöser war konkret. Der externe Abschlussprüfer der Gruppe hatte in zwei aufeinanderfolgenden Jahresabschlussprüfungen denselben Sachverhalt vorgebracht: SAP unterlag einer periodischen Berechtigungsprüfung (mit smartGRC bereits seit mehreren Jahren), aber acht weitere geschäftskritische Systeme, in denen wesentliche Buchhaltungs-, Billing- und Kundendaten verarbeitet werden, taten dies nicht. Während der Prüfung 2019 überschritt das Thema fast die Schwelle zu einem Bestätigungsvermerk mit Einschränkung im Jahresabschluss. Interne Teams verbrachten Dutzende Personentage mit der Erbringung kompensierender Nachweise – Reports ziehen, Stichprobenpopulationen verteidigen, Berechtigungen auf Hauptbuchbuchungen abbilden – für Feststellungen, die eine echte Berechtigungsprüfung von vornherein verhindert hätte.

Die Entscheidung, vor der die Gruppe Mitte 2020 stand, lautete nicht „sollen wir Berechtigungsprüfungen auf Nicht-SAP-Systemen durchführen". Die Entscheidung lautete wie, angesichts des Zeitdrucks des nächsten Audit-Zyklus, der organisatorischen Komplexität und eines parallel laufenden IDM-Auswahlprojekts, das bereits beschlossen hatte, die GRC-Funktionen nicht in seinen Scope aufzunehmen.

Dies ist eine Darstellung, wie diese Entscheidung ablief, was wir bewerteten, was wir verwarfen, was wir bauten und was uns das Engagement über die Grenzen jeder anderen Architektur in dieser Kategorie gelehrt hat. Namen, exakte Kennzahlen und identifizierende Systembezeichnungen wurden anonymisiert; strukturelle Muster und Größenordnungen sind unverändert. Fünf Enterprise-Kunden, darunter eine börsennotierte Gruppe, betreiben smartReview heute produktiv jenseits von SAP.

Die Ausgangslage

Warum Nicht-SAP-Berechtigungsprüfung nie stattfindet

Die Frage ist nicht, warum eine komplexe Organisation Berechtigungsprüfungen will. Die Frage ist, warum sie in der Praxis für SAP stattfinden und für den Rest des Anwendungsportfolios fast nie. Die Antwort ist eine vierseitige Verantwortungslücke und eine entsprechende Werkzeuglücke.

Die interne Revision beaufsichtigt den Kontrollrahmen, betreibt ihn aber nicht. Die IT versteht Rollen und Datenbank-Grants, versteht aber selten die geschäftliche Konsequenz einer bestimmten Berechtigung in einer bestimmten Anwendung. Administratoren von Fachanwendungen kennen oft das technische Detail, aber sie sind die Population, die die Prüfung untersuchen soll, also können sie nicht die Prüfer sein. Der Geschäftsbereichsverantwortliche einer Kundendatenanwendung, eines Data Warehouse oder einer Billing-Plattform hat üblicherweise weder das technische Vokabular, um Rollendefinitionen zu lesen, noch das organisatorische Mandat, um nach den Erkenntnissen zu handeln. Die Position, die periodische Reviews auf einem Nicht-SAP-System durchführen sollte, existiert im Organigramm häufig nicht.

Die Werkzeuglücke spiegelt die Verantwortungslücke. GRC-Plattformen sind historisch aus der SAP-Audit-Praxis hervorgegangen – sie sprechen SAP, sie liefern SoD-Bibliotheken, die auf SAP-Transaktionen kalibriert sind, und ihre Konnektoren zielen primär auf SAP-ERP. IDM-Plattformen operieren auf einer ganz anderen Ebene: Sie verwalten den Lebenszyklus von Konten in technischer Sprache („Rolle AA_KSIEGOWANIE_130"), was nicht die Sprache ist, in der ein fachlicher Prüfer entscheiden kann. Das Ergebnis ist, dass die siebzig-plus Prozent des Berechtigungsrisikos eines Unternehmens, die außerhalb von SAP liegen – Billing-Plattformen, Data Warehouses, CRM, Buchhaltungs-Nebenbücher, Eigenentwicklungen – in ein Niemandsland fallen, in dem weder das GRC- noch das IDM-Werkzeug die offensichtliche Antwort ist.

Genau diese Lücke sollte dieses Engagement schließen.

Die vier Varianten, die wir geprüft haben – in zunehmender Ernsthaftigkeit

Jede sinnvolle Veränderung in einem regulierten Umfeld beginnt mit der Disziplin, die Alternativen aufzulisten. Die Gruppe bewertete vier Optionen, bevor sie sich für die entschied, die funktionierte.

Die Entscheidung fiel Mitte Juni 2020. Der Anbieter verpflichtete sich zur Einsatzbereitschaft bis Ende Oktober. Der erste Nicht-SAP-Review-Zyklus lief noch im selben Jahr.

Die acht angebundenen Systeme

Acht Systeme reichen aus, um jedes interessante Integrationsmuster sichtbar zu machen, das in einem typischen Enterprise-Anwendungsportfolio existiert. Die Matrix unten beschreibt sie anonymisiert, grob nach Integrationsschwierigkeit geordnet:

Systemtyp	Benutzerzahl	Technische Komplexität	Fachliche Komplexität
Telco-Billing-Plattform (Sybase/VMS/S2K-Backend)	~2.600	Hoch	Mittel
Billing-Kundenservice-UI (AD-nativ)	~2.000	Niedrig	Niedrig
Enterprise Data Warehouse (Teradata)	~1.200	Sehr hoch	Sehr hoch
Billing-Datenübertragungs-Backend (MS SQL)	~30	Hoch	Mittel
Telemarketing-CRM (Mehr-Anwendungs-System)	~8.000	Mittel	Hoch
Buchhaltungs-Nebenbuch (Webanwendung)	~30	Mittel	Niedrig
Konsolidierter Kundendatei-Buchhaltungs-Overlay	<20	Niedrig	Niedrig
DTH-Billing-Abstimmungs-App	~1.000	Mittel	Niedrig

Über diese acht Systeme hinweg begegneten wir jedem Identität-zu-Konto-Bindungsmuster, das ein Enterprise-Integrationsteam wiedererkennt:

• Active-Directory-Direktbindung – der einfache Fall. Die Anwendung authentifiziert gegen AD, der AD-Login ist die Identität, die Zuordnungstabelle ist implizit.
• AD plus Admin-Zuordnungstabelle – die meisten Benutzer sind AD-nativ, Administratoren haben dedizierte technische Konten, die eine separate Zuordnung aus einer Seitentabelle benötigen.
• NTLM-Cross-Domain-Authentifizierung – Login wird gegen die Heimatdomäne des Benutzers validiert, aber die Anwendung liegt in einer anderen; das Attribut EmployeeNumber überbrückt die beiden.
• EmployeeNumber-Brücke zwischen zwei Domänen – die Anwendung ist älter als die AD-Föderation; die Identität muss durch Verknüpfen von HR-System-Attributen mit zwei AD-Bäumen rekonstruiert werden.
• Externe Zuordnung für technische Konten – das System hat Kontokategorien user_##, exp_*, load_*, apl_*, von denen nur einige auf menschliche Identitäten abbilden; der Rest sind Service-Konten, die eine getrennte Behandlung benötigen.

Wenn Ihr Portfolio in etwa so aussieht wie ein Portfolio, das durch fünfzehn Jahre Akquisitionen und Re-Plattformierungen gewachsen ist, dann haben Sie alle fünf.

Die vier Berechtigungsmodell-Archetypen

Berechtigungsmodelle sind der Bereich, in dem sich Systeme am stärksten unterscheiden – und in dem die Abstraktionen einer GRC-Plattform die meiste Arbeit leisten müssen, um diesen Unterschied vor dem fachlichen Prüfer zu verbergen.

Profilbasiert mit beratendem IDM – die Anwendung hat Benutzerkonten und granulare Berechtigungen auf Datenbankebene; eine IDM-Schicht definiert „Profile" als Bündel dieser granularen Berechtigungen; aber das Profil im IDM ist beratend, nicht bindend. Der Administrator des Quellsystems kann beliebig vom Profil abweichen, und die Abweichung ist in der IDM-Sicht nicht sichtbar. Eine Prüfung des IDM sagt Ihnen, was wahr sein sollte. Eine Prüfung des darunter liegenden Systems sagt Ihnen, was wahr ist. Nur die zweite ist für ein Audit brauchbar.

Nur AD-Gruppen – die Anwendung autorisiert über Mitgliedschaft in einer kleinen Anzahl von AD-Gruppen. Die Prüfung ist sauber: Benutzer auflisten, Gruppenmitgliedschaften auflisten, entscheiden, ob jedes Benutzer-Gruppen-Paar noch angemessen ist.

Datenbankrolle mit Vererbung – die Anwendung ist ein Thin Client auf einer Datenbank, und die Datenbank hat Rollen, plus explizite Grants pro Tabelle oder Sicht zusätzlich zu Rollen, plus Rollenvererbungshierarchien. Berechtigungen werden zur Abfragezeit dynamisch berechnet. Die Zahl der unterschiedlichen „effektiven Berechtigungen", die ein Benutzer halten kann, ist kombinatorisch, und die meisten werden nie ausgeübt. Ein naiver Report listet pro Benutzer Tausende von Berechtigungszeilen; ein audit-tauglicher Report listet das Dutzend Berechtigungen, die zählen, und zeigt, ob der Benutzer eine davon hat.

Atomare Berechtigungen plus Standortkontext – der schwierigste Fall. Berechtigungen sind granulare Operationen („Auftrag anlegen", „Vertrag upgraden", „verkaufen"), aber die Operation ist nur im Kontext eines Organisationsstandorts sinnvoll („Auftrag anlegen, für Filiale #4781, für Kundenkategorie X"). Die Prüfungsfrage lautet nicht „kann dieser Benutzer einen Auftrag anlegen", sondern „kann dieser Benutzer einen Auftrag an diesem Standort für diese Kundenkategorie anlegen". Das Datenmodell muss diese Konditionierungsebene unterstützen, und die Prüferoberfläche muss sie in Geschäftssprache sichtbar machen. Ohne das produziert das Review Volumen ohne Signal.

Das universelle Muster: ein XSD-beschriebener XML-Adapter

Die architektonische Entscheidung, die das Engagement termin- und budgetgerecht lieferbar machte, lautete: baue nicht N systemspezifische Konnektoren. Baue ein gut definiertes Aufnahmeschema und verpflichte jedes System, dieses zu produzieren.

Das Schema beschrieb für jedes Quellsystem: die Benutzerpopulation (mit Metadaten zur Identitätsbindung), den Berechtigungskatalog (atomar und zusammengesetzt), die Benutzer-zu-Berechtigung-Zuordnungen, die Zuordnungszeitstempel und -status, die optionalen Risikoklassen-Tags. Ein XSD machte das Schema durchsetzbar und selbstdokumentierend. Jedes Quellsystem, das überzeugt werden konnte, eine XML-Datei in diesem Schema zu schreiben, konnte eingelesen werden.

Das hatte drei praktische Konsequenzen. Erstens war die Engineering-Arbeit für jedes neue System gescoped: XML-Datei im Schema erzeugen, gegen das XSD validieren, übergeben. Keine maßgeschneiderte Konnektorlogik auf der GRC-Seite, keine Protokollverhandlung, kein Warten auf die Abstimmung von IT-Kalendern. Zweitens sollte dasselbe Schema später von der neuen IDM-Plattform befüllt werden, sobald sie ausgerollt war; die manuelle Upload-Phase war Phase 1, der automatisierte IDM-Feed war Phase 2, und die GRC-Aufnahmelogik musste zwischen den Phasen nicht neu geschrieben werden. Drittens gab das Schema jedem System-Eigentümer eine präzise Spezifikation dessen, was sein System zum Review-Prozess beitragen sollte – was sich als der schnellste Weg erwies, Entdeckungen vom Typ „dieses Attribut ist in unserem System tatsächlich leer" sichtbar zu machen.

Das plattformneutrale Primitiv, auf dem ein GRC-System operiert, ist über jede Anwendung hinweg dasselbe: ein Benutzer, eine Berechtigung, ein Geschäftsrisiko, ein Prüfer, ein Urteil, eine Nachweisspur. Alles andere ist Integrationsklebstoff.

Was smartReview hinzufügen musste

Die Erweiterung eines bestehenden Werkzeugs beinhaltet immer ein Featureset, das das bestehende Werkzeug noch nicht hat. Für smartReview waren die Deltas:

Mehrere parallele Review-Zyklen. Das SAP-Review lief einmal jährlich. Acht Nicht-SAP-Systeme bedeuteten Zyklen, die über den Kalender gestaffelt waren, manchmal überlappend, manchmal durch Ad-hoc-Ereignisse (Joiner, Mover, regulatorische Änderungen) ausgelöst. Das Datenmodell und die Prüfer-Warteschlange mussten mehrere aktive Zyklen unterstützen, die unterschiedliche Systempopulationen gleichzeitig adressieren, ohne ineinander zu laufen.

Nicht-SAP-Risikodefinitionen in Geschäftssprache. SAP-SoD-Bibliotheken beschreiben Risiken in Transaktionscodes. Ein Nicht-SAP-Risikokatalog beschreibt Risiken in Aktionen („eine Bankabstimmungsbuchung anlegen", „eine Kreditanpassung über €X genehmigen", „die Rechnungsanschrift eines Kunden ändern"). Die Risikodefinitionen mussten pro System verfasst werden, dann in der Prüferoberfläche in der Sprache ausgedrückt werden, die die Rolle des Prüfers erwartete.

Audit-freundliche Nachweisspur. Jede Prüferentscheidung musste eine saubere Aufzeichnung hinterlassen: wer geprüft hat, wann, was angezeigt wurde, was entschieden wurde, welche Nachweise angehängt waren. Der Abschlussprüfer prüfte die Nachweisspur beim nächsten Audit; hielt die Spur einer kritischen Prüfung nicht stand, hielt auch der Review-Prozess selbst keiner kritischen Prüfung stand. Hier haben wir bewusst überinvestiert.

Was wir gelernt haben

Drei Lektionen reisten mit uns in jedes folgende „Jenseits-SAP"-Engagement.

Sechzig-Minuten-Systemklassifikation, bevor irgendetwas gescoped wird. Die Komplexitätsmatrix oben ist kein Schreib-Artefakt; es ist ein realer Klassifikationsschritt, der zu Beginn jeder neuen Systemintegration durchgeführt wird. Die beiden Dimensionen – technische Komplexität des Exports, fachliche Komplexität der Abbildung des Exports auf die Risikosprache – erlauben dem Team, sich mit Vertrauen auf einen Kalender festzulegen. Überspringt man die Klassifikation, beziffert das Engagement 6 Wochen und liefert in 5 Monaten.

Der System-Eigentümer ist im Raum, oder das System wird nicht integriert. Drei der acht Systeme in diesem Engagement wären beinahe abgerutscht, weil der ursprüngliche Eigentümer weitergezogen war, der neue Eigentümer nicht formal benannt worden war und das technische Team keine Befugnis hatte, sich auf ein Datenexportformat festzulegen. Wir haben gelernt, die Arbeit zu verweigern, bis ein namentlich benannter, aktueller System-Eigentümer beim Kick-off anwesend war.

Manche Systeme sollten zurückgestellt, nicht erzwungen werden. Zwei Systeme der ursprünglichen Zehn-System-Liste schafften es nicht in den ersten Review-Zyklus. Eines hatte eine Identitätsbindung, die so kaputt war, dass deren Auflösung ein eigenständiges Projekt gewesen wäre; eines war innerhalb von zwölf Monaten zur Stilllegung eingeplant und hätte einen Review-Zyklus an Wert zum Preis eines vollständigen Integrationsaufwands geliefert. „Später" oder „gar nicht" zu sagen ist ein legitimes Ergebnis des Klassifikationsschritts.

Das größere Bild

Die Standarderzählung über GRC-Plattformen lautet, dass sie existieren, um SAP zu überwachen. Diese Erzählung ist fünfzehn Jahre alt. Die buchführungs- und auditrelevanten Daten in einem modernen Unternehmen sind in Billing-Plattformen, Data Warehouses, Kundendateien, CRM, Buchhaltungs-Overlays und Eigenentwicklungen abgewandert, die nie in SAP waren und nie sein werden. SAP ist in vielen Gruppen deutlich weniger als die Hälfte der Berechtigungs-Risikofläche.

Eine GRC-Plattform, die bei SAP aufhört, löst einen Bruchteil des Problems, zu dem der Prüfungsausschuss eine Bestätigung abgeben soll. Die Entscheidung, die die Gruppe getroffen hat – das SAP-Review weiter auf smartReview laufen lassen, dasselbe smartReview auf die acht Nicht-SAP-Systeme ausweiten, einen plattformneutralen XML-Adapter bauen, den das künftige IDM später automatisiert befüllen kann – war kein cleverer Workaround. Es war die Architektur, die diese Kategorie schon vor zehn Jahren hätte haben sollen. Jeder weitere Kunde, der smartReview jenseits SAP betrieben hat, hat dasselbe bestätigt: Das Engineering ist nicht der schwierige Teil, die Verantwortung und die Risikosprache sind es. Sobald die Plattform neutral ist, verlagert sich das Gespräch dorthin, wo der Wert liegt.

Der Abschlussprüfer hat das Thema Berechtigungsprüfung im Folgejahr nicht mehr aufgebracht. Das interne Auditteam hat aufgehört, Dutzende Personentage für kompensierende Nachweise auszugeben. Die IT-Teams, die die acht Systeme betreiben, gewannen erstmals einen klaren Jahresrhythmus für die Rezertifizierungsarbeit, die zuvor ad hoc und teilweise erledigt worden war. Der Prüfungsausschuss gewann eine verteidigungsfähige Antwort auf eine Frage, die er ein Jahrzehnt lang falsch beantwortet hatte.

Fünf Kunden, darunter eine börsennotierte europäische Gruppe, betreiben smartReview jenseits SAP heute produktiv. Das Muster ist übertragbar. Wenn Ihr Prüfungsausschuss dieselbe Frage stellt und Ihre GRC-Plattform bei SAP aufhört, dann sieht die Antwort wie die oben beschriebene Architektur aus.

Über das Engagement. Das in diesem Artikel beschriebene Muster wurde vom smartGRC LAB der GRC Advisory während eines Engagements 2020 bei einer großen polnischen Telco-Media-Gruppe entwickelt, hier in Übereinstimmung mit Vertraulichkeitspflichten anonymisiert. Spezifische Benutzerzahlen, Systemnamen, Identitäts-Bindungsdetails und Risikokataloge wurden angepasst, um identifizierende Details zu entfernen; strukturelle Muster und Größenordnungen sind unverändert. Wenn Sie ein Mehr-System-Unternehmen betreiben, in dem der größte Teil des Berechtigungsrisikos außerhalb SAP liegt, und ein vergleichbares Engagement auf Ihrem eigenen Portfolio besprechen möchten, finden Sie Kontaktdaten und eine Live-UX-Vorschau auf smartgrc.eu.