1. Der Gesetzgeber, der dies zum Teil sehr unverbindlich (Prüfbarkeit, Nachvollziehbarkeit) und zum Teil sehr konkret (Radierverbot) vorgibt.
2. Ihr Unternehmen selbst, das in der Regel weiß, was unbedingt zu schützen ist. Die daraus abgeleiteten Anforderungen sind im Normfall nicht deckungsgleich.

• Bilanzklarheit, Richtigkeit und Willkürfreiheit, Vollständigkeit, Bilanzkontinuität, Wesentlichkeit, Einzelbewertung, Unternehmensfortführung, Anschaffungswertprinzip, Periodisierungsprinzip, Vorsichtsprinzip, Realisationsprinzip, Imparitätsprinzip

GoBS, Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme ergänzen die GoB.


• Datensicherheit, Dokumentation und Prüfbarkeit, Aufbewahrungsfristen, sachlicher und zeitlicher Nachweis, Nachvollziehbarkeit usw.

HGB, Handelsgesetzbuch


• Radierverbot nach § 239 Abs. 3 HGB, Nachvollziehbarkeit § 238ff. HGB
• Das Aufdecken von Intransparenzen und Prüfung auf die Einhaltung des "Vieraugenprinzips" an den kritischen Zugriffspositionen. Ferner trägt das SAP R/3 Risiken in sich selbst, die minimiert werden können (ausführen von Befehlen aus OS-Ebene, Transportwesen, Entwicklung, usw.).

KonTraG, Gesetz zur Kontrolle und Transparenz im Unternehmen


• Ein Ausgangspunkt ist, dass der Vorstand / die Geschäftsführung gemäß KonTraG und dem Bundesdatenschutzgesetz (BDSG) persönlich für die Umsetzung angemessener Schutzmaßnahmen im Unternehmen haftbar ist. Er ist damit verpflichtet, Sicherheit im Unternehmen inklusive eines zugehörigen Risikoüberwachungssystems (KIS) zu etablieren und zu delegieren. Das KonTraG fordert die Umsetzung konkreter Maßnahmen wie die vollständige Erfassung aller Risiken als Teil eines regelmäßigen Konzernlageberichts (§§ 298, 315 HGB), den Aufbau eines unternehmensweiten Risikofrüherkennungs- und Überwachungssystems (§ 91 AktG und § 317 HGB) und es verstärkt die Pflichten und die Haftung der Aufsichtsgremien in Aktiengesellschaften (§§319, 321 ff HGB).

AO, Abgabenordnung


• Hiernach können Buchführungsdaten auf Datenträgern geführt werden.

KIS/IKS, Internes Kontrollsystem, Teil der GoBs
BDSG, Bundesdatenschutzgesetz
BetrVG, Betriebsverfassungsgesetz - daraus entstandene Betriebsvereinbarungen, BAG, Bundesarbeitsgericht - daraus entstandene Urteile
SOX, Sarbanes Oxley Act


• Der größte Unterschied liegt wohl darin, dass an die Börsenaufsicht zeitnah zu berichten ist. Ansonsten sind die Unterschiede aus der Sicht des SAP R/3 Berechtigungswesen zu den vielen deutschen Gesetzen eher als gering zu bewerten, wenn die lokalen Bilanzierungsrichtlinien berücksichtigt bleiben.

AktG, Aktiengesetz
StGB, Strafgesetzbuch


• § 203, für Heilberufe, Patientendaten, Freiheitsstrafe bis zu zwei Jahren oder Geldstrafe

usw.

Intern zu schützende Daten:


• Gehaltsdaten
• personenbezogene Daten im HR sowie Debitoren- und Kreditorenstammsätze
• Verkaufspreise
• Rabatte
• Einkaufspreise
• Patente
• Arbeitsverfahren
• Betriebsvereinbarungen
• Patientenakten in Krankenhäusern
• usw.


Aus den gesetzlichen und firmenspezifischen Anforderungen lässt sich der Personenkreis / die Personengruppen ableiten, die an einem SAP R/3 Berechtigungswesen aus unserer Sicht Interesse haben:



• Die Geschäftsführung / -leitung
• Der Datenschutzbeauftragte
• Die interne Revision
• Die Wirtschaftsprüfer
• Der Betriebsrat
• Die Freigeber von Rechten, Fachabteilung
• Das CCC
• Die IT, Abteilung Berechtigungen


Haben Sie sich schon einmal gefragt, wer verantwortlich ist, wer haftet, wer wird in Regress genommen, wenn Daten aus dem SAP R/3 durch Vorsatz oder Unwissenheit manipuliert oder unberechtigt weitergegeben werden?
Kann in solch einem Zusammenhang der Vorsatz und die grobe Fahrlässigkeit ausgeschlossen werden, reduziert sich das persönliche Risiko jeder betroffenen Person schon deutlich.

Das SAP R/3 kann je nach Release z. B. mit über 100.000 Transaktionen, über 2.000 Objekten und den damit verbundenen Feldern und Feldwerten aufwarten. Die Berechtigungselemente der Rollen können sich in einem System mit 2.500 Usern leicht auf 2,5 Millionen einzelne Werte / Attribute addieren. Dies stellt ein massives Massenproblem dar. Mit den unterschiedlichsten Interessen der betroffenen Personengruppe gepaart mit den Gesetzen und firmenspezifischen Anforderungen, tritt unmittelbar auch ein Wissensproblem ein. Als Sahnehäubchen ist das Berechtigungswesen auch unter den betriebswirtschaftlichen Gesichtspunkten zu betrachten.

Hier beginnt nun die Quadratur des Kreises im SAP R/3 Berechtigungswesen!

Folgende Anforderungen können nun von den einzelnen Personengruppen an ein SAP R/3 Berechtigungswesen gestellt werden. Viele der folgenden Punkte, z. B. geringe Prüfaufwände, sind immer aus der Sicht der betroffenen Persongruppe auch mehrfach zu betrachten.

1. Gesetze und gesetzesähnliche Vorschriften


• Einhaltung aller Gesetze und gesetzesähnlichen Vorschriften
• Einhaltung der Grundsätze ordnungsgemäßer Buchführung
• Kein unberechtigter Zugriff auf personenbezogene Daten, nicht nur im HR sondern auch bei Kreditoren- und Debitorenstammsätzen
• Keine Manipulationen an Buchhaltungsdaten (FI, MM), Radierverbot
• Keine Überwachung der Mitarbeiter/innen
• Keine Verhaltenskontrolle der Mitarbeiter/innen
• Keine personenbezogenen Auswertungen besonderer Mitarbeiter/innen
• Prüfbarkeit und Nachvollziehbarkeit
• Vollständigkeit und Richtigkeit der Dokumentation
• Zuweisung der Rechte nach dem Minimalprinzip
• 4-Augenprinzip
• usw.


2. Betriebswirtschaftlich


• geringe Erstellungs- und geringe laufende Kosten
• geringer Prüfaufwand, bedeutet geringere Kosten
• Investitionssicherheit, Nachhaltigkeit, nicht wieder in 3-5 Jahren komplett überarbeiten
• Mögliche Umschichtung von Manpower in Software, in Summe geringere Kosten für das Unternehmen bei qualitativ höherem Output
• planbarer Aufwand, planbare Kosten
• aus Kostengründen alles selbst machen, oder soll ein praxiserprobtes, zuverlässiges, wertbeständiges Konzept nebst Vorgehensweise eingekauft werden?


3. SAP R/3 spezifisch
Allgemein


• Entlastung von eintöniger und unnötiger Arbeit
• weniger Arbeit mit den Berechtigungen, der Userzuweisung, Passwort zurücksetzen, sperren und entsperren von Usern
• Änderungen müssen schnell, transparent, nachvollziehbar und dokumentiert sein
• flexible, schnelle Anpassung an organisatorische Änderungen, z. B. neuer BUKRS, Änderungen müssen in allen Rollen mit einer Eingabe möglich sein
• keine Ansammlung von Prozesskettenberechtigungen in den Rollen
• ein Infosystem, das Antworten liefert und keine neuen Fragen aufwirft
• kein "Trace" der Transaktionen von Usern und / oder ganzen Abteilungen, in der Regel findet keine Verbesserung statt
• zeitsparende Realisierung und Prüfung durch Templates
• keine Rolle für sich selbst genommen trägt Verstöße in sich
• keinen "Overhead" erzeugen, der dann noch geprüft werden muss

Systemtechnisch


• Integration mit dem HR-Organisationsmanagement, einem LDAP (active directory) oder einer frei erstellten Tabelle, um die Zuordnung User / Rolle eineindeutig zu gestalten
• geringe Releaseabhängigkeit zur Vereinfachung des Berechtigungswesens
• zentrale Verwaltung von N-Systemen (ERP, APO, BW, HR, SolMng usw.) in einer N-Systemlandschaft (Test, Qualitätssicherung, Produktion, usw.)
• mehrsprachig, UNICODE - fähig
• das System muss sich selbst dokumentieren und zwar so, dass ALLES sehr leicht wiederzufinden und zu rekonstruieren ist
• einheitliche und nachvollziehbare Beschreibung der Rollen- Namenkonventionen

Freigabe


• durchgängiges und einheitliches Antrags- und Freigabewesen direkt im SAP R/3 oder über WebDynpro
• einfaches, integriertes, flexibles Antrags- und Freigabeverfahren mit der Möglichkeit, N-Freigeber zu unterschiedlichen Attributen zu definieren (z. B. Abteilung, Rolle, Rollengruppe, User, Usergruppe)
• mögliche Verlagerung der Zuweisung (Antrag und Freigabe) von Rollen zu Usern in die Fachabteilung


4. Prüfen


• Auditsystem für Berechtigungen
• Auskunftsfähigkeit auf jeder Ebene
• für Dritte mit geringem Aufwand nachvollziehbar und überprüfbar
• schneller Überblick durch integrierten Audit mit definierbaren firmenspezifischen Prüfungen
• schnelles Informationssystem über diverse Berechtigungsobjekte, z. B. P_ORGIN
• 100 %ige Dokumentation
• Transparenz durch klare Strukturen und eingehaltene Konventionen
• wer hat welche Rechte welchem User wann zugewiesen
• individuelle Pflege von Revisionskommentaren zu einzelnen Transaktionen / Rollen oder Kombinationen, die beim User nachvollziehbar sind
• Sicherheit über den gesamten Prozess der Berechtigungen, Zwischen- und Endprüfungen

5. Berechtigungsaudit

Technische Anforderungen an den Audit
Der Audit muß:

• in ABAP geschrieben sein und ab 4.6c auf allen ABAP - Plattformen laufen.
• alle R/3 Systeme (Audit ab 4.6c) ob Lokal über RFC, oder Extern über RFC oder Extern über einen Datentransport auditieren können.
• mehrere Systeme übergreifend in Summe auditieren können, z.B. ERP2005 mit CRM und APO.
• Unicode- und nicht Unicodesysteme auditieren können.
• genauso einzelne User, Rollen, Rollenkombinationen, Sammelrollen sowie Rollenzuweisungen zu einem User online auditieren können.
• Änderungen am Audit überprüfen können und die Ergebnisse müssen schnell zur Verfügung stehen.
• eine „online tauglich“ Performance haben.
• Änderungen an Audit relevanten Abfragen schnell und einfach zulassen.
• und auch seine Abfragen, auch von SAP Laien, leicht zu ändern und neue Abfragen leicht zu erstellen sein.
• Ergebnisse liefern, die zu unterschiedlichen Zeitpunkten erstellt wurden und diese müssen miteinander Vergleichbar sein.
• Kennzahlen liefern wie z.B. die Anzahl der Rollen zu einem Verstoß, die Anzahl der möglichen Kombinationen dieser Rollen, die Anzahl der User die diesen Verstoß ausüben können, die Anzahl der wirklich zugewiesen Rollen und Rollenkombinationen. Über Kennzahlen kann die Sinnhaftigkeit des Audits transparent dargestellt werden.
• die Verstöße in Kategorien einzustufen können (01 - absoluter Verstoß - darf auf keinen Fall sein, 02 - Verstoß der zu begründen und zu erklären ist, 03 - leichter Verstoß der zu vermeiden ist, 04 - nur zur Information, 05 - Erklärungen in Textform). Die Anzahl der Kategorien ist auf 2 Stellen, 1444 Werte, alphanumerisch beschränkt.
• alle Auditergebnisse online am Bildschirm anzeigen können. Auf diese Ergebnisse muß beliebig gefilter und sortiert werden können.
• alle Auditergebnisse online am Bildschirm anzeigen können. Diese Ergebnisse müssen in die gängigen SAP Formate exportiert werden können.
• mangamenttaugliche Auswertungen haben.
• über das Customizing so einzustellen sein, das darüber entschieden werden kann wo der integrierte Audit zur Verfügung steht (bei der Rollenerstellung, bei der Sammelrollenerstellung, bei der Zuweisung von Rollen zu Usern).
• per Customizing für einen Verstoß für zu auditierende Teilbereiche ein- / ausblenden sein können.
• über das Customizing nur sinnige Abfragen zu Gunsten der Performance zulassen. z.B. sollte er mögliche 15 Millionen Rollenkombinationen zu einem Verstoß ermitteln, aber nicht das unsinnige Ergebnis auf die Datenbank schreiben. Eine weitere Verprobung dieses Ergebnisses gegen alle User im System sollte zu unterbinden sein.

Wirtschaftliche Anforderungen

• Die Einführungszeiten für den Audit sollten sich maximal auf 2 Tage beschränken. Danach sollte der Kunde in der Lage sein, den Audit selbständig weiter auszuführen und zu verbessern.
• Nur ein integrierter Audit ist ein guter Audit der den Kunden die Vorteile liefert die er im gesamten Berechtigungsprozeß zur insgesamten Verbesserung dringend benötigt. Inselanwendungen und Schnittstellen sind Brüche die mögliche Vorteile direkt wieder zu Nichte machen.
• Die Lizenzkosten, insbesondere das Preis- / Leistungsverhältnis, sollten in einem gesunden Verhältnis zueinander stehen.

Das Berechtigungswesen ist keine Black - Box und es wird nie eine Black - Box werden. Um unser definiertes Ziel zu erreichen, muss das Berechtigungswesen jederzeit prüfbar, transparent, nachvollziehbar, dokumentiert sein.
Auf Grund der vielen Transaktionen im SAP R/3, der vielen Objekte, Felder und Feldwerte, den gesetzlichen und firmenspezifischen Anforderungen kann die Überprüfung nur automatisiert, standardisiert durchgeführt werden. Jeder andere Versuch einer Prüfung würde an der Masse der Daten und deren logischen Abhängigkeiten, sowie an der zur Verfügung stehenden Zeit und damit verbundenen Geldressourcen scheitern.
Um automatisiert und standardisiert prüfen zu können, muss das Berechtigungswesen selbst Standards aufweisen. Dies beginnt bei den standardisierten Namenskonventionen für den Rollenkey und die Rollenbezeichnung. Werden diese Namenskonventionen nicht eingehalten, ist eine spätere automatisierte Prüfung so gut wie ausgeschlossen.
Alle Rollen müssen in ihrem Aufbau und ihrer Zuweisung einer bestimmten Konvention entsprechen. Trifft dies nicht zu, so ist eine spätere automatisierte Prüfung so gut wie unmöglich.
Am Ende der Kette steht dann der User mit seinen Rechten, transparent und nachvollziehbar für jeden Dritten. Welche Rollen wurden dem User wann und durch wen zugewiesen? Welche Transaktionen, Objekte, Felder und Feldwerte hat er? Wie steht der einzelne User zu den vorher definierten Verstößen im Widerspruch?