IT-Compliance für SAP-Umgebungen: lästig, aber notwendig

Wer eine Runde von IT-Manager ein wenig aufmischen muss nur das Wort „Compliance“ fallen lassen: Je nach Disposition der Teilnehmer werden sich in der Runde Unbehagen, Nervosität oder Ärger einstellen. Schnell wissen die meisten Teilnehmer auch eine einschlägige Anekdote zu erzählen. Wobei die eigene IT natürlich stets regelkonform arbeitet – trotz allerlei unsinniger Anforderungen. Aber ist das wirklich so?

Tatsache ist, dass die Unternehmens-IT, insbesondere die ERP-/SAP-Anwendung als Dreh- und Angelpunkt der Unternehmensprozesse, eine Vielzahl von Risiken birgt. Schnell hat man gegen Richtlinien verstoßen. Fallstricke und Stolpersteine sind in jeder Phase der Nutzung zu erwarten.

Was Compliance erreichen soll

In groben Zügen umschrieben bedeutet IT-Compliance, dass alle relevanten gesetzlichen, innerbetrieblichen und vertraglichen Regeln eines Unternehmens, die die Software, deren Nutzung und die dazugehörigen IT-Prozesse betreffen, erfüllt werden müssen. Im Kern geht es um die vier Themenbereiche Informationssicherheit, Verfügbarkeit, Aufbewahrung und Datenschutz.

Ralph K. Treitz, der Autor dieses Gastbeitrags für ZDNet, ist Gründer und Vorstand der VMS AG, einem Spezialisten für die Messung der SAP-Systemnutzung (Bild: VMS AG)

Pragmatisch formuliert soll IT-Compliance gewährleisten, dass ausschließlich berechtigte Personen im erlaubten Maß mit sicher verwalteten Daten arbeiten dürfen. In ihrer Allgemeinheit klingt diese Vorgabe höchst vernünftig. In der praktischen Umsetzung erweist sie sich mitunter als sperrig und kontraproduktiv: Schuld sind Komplexität, Widersprüche einzelner Regelungen sowie lückenhafte Formulierungen, insbesondere hinsichtlich neuer Technologien und Verfahren. Die Folge sind Unklarheit, Intransparenz und nicht selten eben der Schritt über die Grenze des Erlaubten – trotz bester Absichten.

Von Herstellerseite dürfen die Unternehmen nur bedingt Hilfestellung erhoffen. ERP-Software bietet von Hause aus keine automatisierte Sperre gegen alles, was nicht „compliant“ ist. Die Programme aus Walldorf stellen in dieser Hinsicht keine Ausnahme dar.

Zahlreiche Stolpersteine

Bereits in der Frage der rechtmäßigen Nutzung der Software werden die Unternehmen alleine gelassen. SAP überlässt die Verantwortung über die Zuordnung von Lizenzkennzeichen zu den jeweiligen Nutzern vollständig der Verantwortung ihres Kunden. Nutzt der mehr Funktionalität als erworben, muss er dies gemäß Lizenzvereinbarung anzeigen und bezahlen.

Das scheint zunächst recht kundenfreundlich und flexibel zu sein. Eine klare Antwort auf die Frage, ob wirklich, wann, wie viel und was nachgekauft werden muss, fällt aber bei zunehmender Komplexität des Lizenzmodells immer schwerer. Tatsächlich, so belegen Projekterfahrungen mit dem Lizenz-Check-Verfahren der VMS AG, genügt es häufig, die verfügbaren Lizenzen besser an der tatsächlichen Arbeitsweise auszurichten. Bei entsprechend sanktionierten Drohungen der hausinternen Compliance-Wächter wird oft lieber einmal mehr nachgekauft. Sicher ist sicher, denkt sich mancher – treibt aber damit die IT-Kosten unnötig in die Höhe.

Einen automatisierten Compliance-Check für das Customizing der Anwendungen sucht man vergeblich. So lässt sich im SAP-Standard problemlos für den gleichen Nutzer die Berechtigung für die „Anlage von Bestellungen“ und für „Rechnungsfreigabe“ zuordnen.

Wenigstens eine automatische Warnung wäre hier sinnvoll. Die einschlägige Gesetzgebung verpflichtet Unternehmen nämlich, tragfähige Kontrollmechanismen einzuführen, um den potenziellen Missbrauch durch solche Ballung von Benutzerrechten zu unterbinden. Dabei steht es ihnen frei, die Umsetzung eher organisatorisch oder mit der Einführung weitreichender Tool-Umgebungen wie SAP BO GRC, vormals Virsa, anzugehen. Der Kauf dieser Tools ist aber teuer und die Einführung aufwändig, weil die Regelwerke vom Kunden beziehungsweise dessen Berater zu schaffen und zu pflegen sind.

Aber auch mit Tool-Unterstützung stellt die Vergabe und Pflege von Rollen und Berechtigungen oder die Definition der Prüfregeln eine hochkomplexe, umfangreiche Tätigkeit dar. Und leider gibt es keine Lösung, die für alle Probleme gleichermaßen geeignet ist: unterschiedliche Perspektiven fordern unterschiedliche Lösungen.

Während aus Compliance-Sicht ein feinziseliertes System extrem eingeschränkter Rechte sinnvoll wäre, fühlen sich Anwender davon schnell in der täglichen Arbeit behindert. Sind Berechtigungen zu kleinteilig angelegt, nimmt die Zahl der Helpdesk-Tickets sprungartig zu, da die Anwender zusätzliche Rechte im täglichen Kampf um jede Einzelberechtigung einfordern.

Im Eifer der täglichen Änderungen treten dann Fehler auf: Da wird schnell vergessen, neben der Schreib-/Lese-Berechtigung gleichzeitig die reine Leseberechtigung für eine Transaktion einzurichten. Die unliebsame Folge ist, dass der Mitarbeiter immer die lizenztechnisch kostspieligere Variante der Schreib-/Lese-Berechtigung nutzt oder nutzen muss, selbst wenn er in seiner Rolle nur kurze Sichtprüfungen durchführen möchte. Und das ist noch eines der harmloseren Szenarien.

Datenschutz

Natürlich sind auch IT-Prozesse selbst in hohem Maße Compliance-relevant. Insbesondere die Auslagerung von Prozessen oder Daten in eine Cloud-Lösung wird höchst kontrovers diskutiert. Hier spielt in erster Linien der Datenschutz eine Rolle, der hohe Anforderungen an die Genehmigungsverfahren für die Auslagerung von personenbezogenen Daten stellt, oder die Lagerung zum Beispiel außerhalb der EU faktisch verbietet.

Aber auch beim Verbleib der Daten im deutschen Rechenzentrum können SAP-Verantwortliche schnell mit dem Datenschutz in Konflikt kommen. In einer typischen SAP-Umgebung werden neben der Produktion auch Systeme für Entwicklung, Qualitätssicherung, Abnahme und Schulung betrieben. Diese Systeme benötigen realistische, konsistente Testdaten. Konkret heißt das meist: Die Tests werden mit Hilfe einer Kopie der Originaldaten durchgeführt.

Diese Vorsysteme sind aber meist nicht in gleichem Umfang geschützt wie die Produktionssysteme. Und es ist der Normalfall, dass auf diese Systeme wiederum Berater und Beratungsfirmen Zugriff haben. Auch wenn man den Berater vor Ort mit Hilfe entsprechender datenschutzrechtlicher Verpflichtungen in die Compliance-Regelungen einbinden kann, sind technische Regelungen vorzuziehen, zum Beispiel die Pseudonymisierung von personenbezogenen oder vertraulichen Daten durch entsprechende Tools.

Schließlich wird auch mitten im Projektablauf, bei Verzug, die Werkbank schnell einmal bis Indien verlängert, was bekanntlich außerhalb der EU liegt. Und gerade solche unter Zeitdruck im Rahmen von Projekten getroffenen Entscheidungen unterfliegen dann schnell das gut aufgestellte Compliance-Radar im Unternehmen.

Manchmal müssen auch wirtschaftlich sehr attraktive Ansätze des Offshorings umstandslos beerdigt werden, wenn zum Beispiel das Datenmodell zwar einfache Pseudonymisierungen für Kundennamen und Adressen erlaubt, aber komplexere Beziehungen nicht umgeschlüsselt werden können. In einem aktuellen Fall konnten sprechende Schlüssel für Kundennummern nicht verändert werden. Ein wenig Social Engineering hätte genügt, um über die Kundennummer und einen Anruf im Callcenter die Originaldaten zu ermitteln. Das wäre das Ende der Vertraulichkeit der Kundendaten gewesen.

Fazit

Unter dem Strich ist das Herstellen und Bewahren von IT-Compliance eine eher undankbare aber notwendige Aufgabe. Das gilt umso mehr, als die Dynamik der Anforderungen an die IT, den einmal erreichten Qualitätsgrad gefährdet. Compliance kostet Geld und Zeit ohne einen direkt messbaren Nutzen für das Unternehmen zu stiften. Es geht eben „nur“ um Schadensverhinderung. Im Gegenteil: Ein Nichtbeachten kann sogar zu einem vermeintlichen „Gewinn“ führen, wenn ein Projektleiter etwa durch das Aussetzen der Anonymisierung von Testdaten seinen Zeitplan retten kann.

Für Unternehmen und die verantwortlichen Personen kann solches Handeln aber erhebliche rechtliche Konsequenzen nach sich ziehen. Die Rechtsnormen des Datenschutzes sind mit drakonischen Strafen versehen, was gerne übersehen wird, weil es eher selten zu deren umfassendem Vollzug kommt. Auch die Rechtevergabe in Systemen muss den von Jahr zu Jahr schärfer gefassten Regelungen von Transparenz, Verhinderung von Vorteilsgewährung oder Geldwäschegesetzen nachkommen.

Bei Lizenzvergehen stehen Geschäftsführer und Vorstände sogar in Gefahr, persönlich wirtschaftlich und strafrechtlich zur Verantwortung gezogen zu werden, denn selbst eine D&O-Versicherung deckt Lizenzvergehen nicht ab, weil sie als wissentliche Pflichtverletzung gilt.

Die Kommunikation der Compliance-Problematik einschließlich der Entwicklung und Umsetzung von Lösungskonzepten ist daher unerlässlich und bedarf professioneller Begleitung, da der Schritt von „lästiger Pflichterfüllung“ zu „strafbewehrter Pflichtverletzung“ oft nur sehr klein ist.