Vom Logging zur Schaltung: Was hinter SAP SACF steckt

Warum neue Prüfungen zum Risiko werden

SAP liefert neue Berechtigungsprüfungen fortlaufend aus, über Security Notes oder im Rahmen von Upgrades. Früher hieß das: Sobald die Prüfung im System war, griff sie sofort. Fehlte einer Rolle das passende Objekt, brach der Prozess ab, oft mitten im Tagesgeschäft und ohne Vorwarnung.

Für Unternehmen bedeutete das eine unangenehme Wahl. Entweder blieb die Sicherheitslücke offen oder der Patch riss ein neues Loch in den Betrieb. Klassische Berechtigungsprüfungen kennen nämlich nur zwei Zustände: aktiv oder gar nicht vorhanden. Einen Zwischenschritt, in dem man erst beobachten und dann entscheiden kann, gab es nicht.

Genau diesen Zwischenschritt liefert SACF. Eine neue Prüfung wird zwar ausgeliefert, entfaltet ihre blockierende Wirkung aber erst, wenn der Kunde sie aktiv schaltet. SAP liefert die Prüfung. Der Kunde entscheidet, wann sie in seiner Systemlandschaft tatsächlich greift.

Szenario Definition am Praxisbeispiel: AP_MD_BUPA_SENSITIVITY

Nehmen wir ein konkretes Szenario aus dem Unternehmensalltag: Der Schutz von vertraulichen Mitarbeiter- und Geschäftspartnerdaten (z. B. Privatadressen oder Bankverbindungen, die im Hintergrund über Bausteine wie BUPA_PADR_ALLOWED_GET verarbeitet werden).

SAP liefert hierfür das Szenario AP_MD_BUPA_SENSITIVITY aus. Szenarien werden in zwei Varianten ausgeliefert:

• Status P (Inaktiv ausgeliefert): Eine Empfehlung oder Korrektur. Die Prüfung wird erst wirksam, wenn Sie im Zielsystem explizit ein produktives Szenario anlegen.

• Status D (Aktiv ausgeliefert): Verbindliche Prüfungen (oft bei neuen Hauptreleases), die sofort greifen und im Zielsystem nur noch hinsichtlich der Protokollierung angepasst werden können.

Schaut man in die Transaktion SACF, sieht man, welche Prüfungen z.B. AP_MD_BUPA_SENSITIVITY in gebündelt sind:

Die in der Abbildung enthaltenen Objekte erfüllen dabei spezifische Aufgaben:

• B_BUPA_ADR:
  Steuert die Sichtbarkeit von GP- und Mitarbeiter-Privatadressen.
• B_BUPA_BNK:
  Regelt den Zugriff auf sensible Bankverbindungen.
• S_TABU_NAM:
  Schützt den direkten Tabellenzugriff auf Tabellenebene über generische Standardtools
• S_ADMI_FCD:
  Prüft administrative Systemfunktionen.
• S_PROGRAM:
  Regelt Berechtigungen für Programmabläufe und Ausführungen.

Setzt man das Szenario auf Logging (Status L), greift der Sicherheitsmechanismus von SACF:
Die Berechtigungsprüfung wird im Hintergrund laufen. Das Auswertungsergebnis an den aufrufenden Prozess ist jedoch immer erfolgreich, der Endanwender spürt keine Einschränkungen und kann ungestört weiterarbeiten.

Damit Berechtigungsfehler ohne Blockade sichtbar werden, nutzt SACF das Security Audit Log (SAL). Über den Parameter SAL-Status wird das Verhalten gesteuert:

• N (Keine Aufzeichnung):
  Standardfall ohne SAL-Einträge.
• E (Fehler aufzeichnen):
  Zeichnet fehlgeschlagene Prüfungen auf (Ereignis DUP).
• A (Alle Prüfungen aufzeichnen):
  Protokolliert sowohl Erfolge (DUO) als auch Fehler (DUP).

Voraussetzung: Das Security Audit Log muss aktiv sein und in der Transaktion SM19 entsprechende Filter für die Meldungen DUP/DUO enthalten.

Um das Verhalten zu demonstrieren, simulieren wir die Prüfung über die Transaktion SE38 mit dem Testprogramm SACF_TEST_CASE für das Szenario AP_MD_BUPA_SENSITIVITY.

Im Test wird unter anderem das Objekt S_PROGRAM abgeprüft, für das der ausführende Anwender in seinen PFCG-Rollen keine Berechtigung besitzt.

Durch den Logging-Modus meldet der Report: S_PROGRAM – Authority check passed. Im Produktivbetrieb bedeutet das: Kein Prozessabbruch, keine Fehlermeldung für den Fachbereich.

Während der Anwender ungestört weiterarbeiten kann, sammelt das System die tatsächlichen Berechtigungslücken. Über die Auswertungs-Transaktion RSAU_READ_LOG (Security Audit Log) lassen sich diese Daten gezielt analysieren.

Im Audit Log wird transparent sichtbar, welche Objekte im Ernstfall blockiert hätten. Das Berechtigungsteam kann nun passgenau die Rollen via Transaktion PFCG nachpflegen, bevor das Szenario aktiv geschaltet wird.

Analyse, Logging, Schaltung: Der Ablauf in der Praxis

Für ein einzelnes SACF-Szenario läuft die Einführung in vier Schritten ab:

1. Analyse:
   Nach einem Update oder Upgrade werden die neu ausgelieferten, schaltbaren Szenarien identifiziert.
2. Logging-Modus:
   Das Szenario ist aktiv, blockiert aber niemanden, während im Hintergrund Zugriffsdaten gesammelt werden. Zwei bis vier Wochen sollte ein Szenario aktiv bleiben, damit auch Monats- oder Quartalsabschlüsse erfasst werden.
3. Rollenanpassung:
   Auf Basis der Log-Daten werden fehlende Berechtigungen in die betroffenen Rollen ergänzt.
4. Schaltung:
   Die Prüfung wird auf „Aktiv“ umgestellt und ist damit produktiv wirksam.

Für die Datenerhebung in Schritt zwei gibt es zwei Werkzeuge mit unterschiedlichen Aufgaben. Das SACF-Logging läuft über Wochen im Hintergrund und erzeugt dabei kaum Systemlast, ideal für den laufenden Betrieb. STAUTHTRACE liefert deutlich genauere Details, aber nur für kurze, gezielte Tests, weil es die Systemlast spürbar erhöht.

Vom Überblick zum Systemabgleich

Die Transaktion SACF selbst dient vor allem der Status-Prüfung. In großen Systemen kann das schnell mehrere hundert Szenarien betreffen.

Nach einem Releasewechsel oder einem neuen Support-Package-Stack lohnt sich ein Abgleich mit SACF_COMPARE. Der Report zeigt, wo sich der Sollzustand der Szenarien zwischen Systemen oder Versionsständen unterscheidet, damit neue oder angepasste Sicherheitsrichtlinien nicht im eigenen Berechtigungskonzept untergehen.

Für den Transport zwischen Systemen gibt es SACF_TRANSFER. Ein Szenario, das im Entwicklungssystem definiert und getestet wurde, lässt sich exportieren und über eine Datei in andere Systeme importieren, etwa nach Test oder Produktion. Das eignet sich auch, um lokale Sicherungskopien wichtiger Szenarien anzulegen.

Und in der Public Cloud?

In der SAP Public Cloud sieht die Aufgabenteilung anders aus. Dort schaltet SAP im Hintergrund technische Prüfungen für sensible Bereiche wie Tabellenzugriffe oder RFC automatisch aktiv, nach dem Prinzip „Secure by Default“. Solange Kunden mit den Standardkatalogen arbeiten, bekommen sie von diesen Umstellungen kaum etwas mit, keine Abbruchmeldungen, keine unerwarteten Unterbrechungen im laufenden Betrieb.

Was am Ende dabei herauskommt

Der Monatsabschluss läuft weiter, während im Hintergrund geklärt wird, wer wirklich buchungskreisübergreifend zugreifen muss. Für Revision und Audit lässt sich außerdem lückenlos zeigen, wann und warum eine Berechtigung verschärft wurde, was bei Prüfungen regelmäßig gefragt wird. Und weil die Rollenanpassung auf echten Zugriffsdaten aus dem Betrieb beruht, statt auf Vermutungen, sinkt gleichzeitig der Aufwand für die Berechtigungsadministration.

Am Ende ist die Sicherheitslücke nicht nur formal durch das Einspielen der Note geschlossen, sondern im Zielzustand tatsächlich wirksam.