IT-Infrastruktur
Hinweise implementieren
Gerade nach Sicherheitsvorfällen kann es notwendig sein herauszufinden, welche (technischen) User sich zu welchem Zeitpunkt eingeloggt haben. Einen ersten Einstiegspunkt bietet dafür die Tabelle USR02. In der Spalte TRDAT können Sie für den gewünschten User das letzte Anmeldedatum finden. Eine Historie über die vorherigen Anmeldungen ist in dieser Tabelle jedoch nicht zu finden. In solchen Fällen hilft der Security Auditlog oder kurz SAL. Vorbereitung Damit Sie auf die gewünschten Daten zugreifen können, müssen diese zuvor auch gespeichert worden sein. Im Security Auditlog können Sie über verschiedene Filter bestimmen, für welche User auf welchen Mandanten welche Informationen geloggt werden. Der Security Auditlog speichert, je nach Konfiguration, Anmeldungen, RFC-Aufrufe und weitere Aktionen für bestimmte User. Diese Einstellungen können Sie in der Transaktion SM19 vornehmen. Hinweis: Das Loggen von Useraktivitäten muss den betroffenen Usern bewusst sein! Konfigurieren Sie die SAL daher nur für technische User oder in Absprache mit Usern / Betriebsrat / etc. Es lässt sich dort ua einsehen, wann der SAL aktiviert und zuletzt bearbeitet wurde (1). Sie können hier außerdem die verschiedenen Filter auswählen (2), die Filter einzeln aktivieren (3), Mandanten und Benutzer bestimmen (4) sowie festlegen, welche Aktivitäten geloggt werden (5). Statische Konfiguration in der SM19 Unter der Dynamischen Konfiguration lässt sich außerdem einsehen, ob SAL aktuell für das System aktiv ist. Status des SAL ermitteln Auswertung des SAL Wenn der Security Auditlog aktiv ist, wechseln Sie in die SM20 Auswertung des Security Auditlog. Wählen sie die gewünschten User und den Mandanten aus sowie das passende Zeitfenster. Für die Anmeldungen reicht die Option Dialoganmeldungen aus. Starten Sie anschließend die Analyse über AuditLog neu einlesen. Auswertung starten Sie erhalten eine Übersicht der Anmeldungen des Users an den gewählten Mandanten des Systems.
Es ist von großer Wichtigkeit, das Wissen von SAP Basis Experten im Unternehmen transparent zu halten. Eine Möglichkeit ist natürlich das “über die Schulter schauen” oder den Experten direkt zu fragen. Das ist jedoch sehr zeitintensiv und beansprucht den Experten auch selber.
Identische Selects
Sowohl auf dem Datenbankserver als auch auf den Applikationsservern muss überprüft werden, ob ausreichend Hardware (CPU und Hauptspeicher) zur Verfügung steht, um die anstehende Last zu bewältigen. Darüber hinaus muss sichergestellt werden, dass die Betriebssystem- und Netzwerkparameter optimal eingestellt sind, um eine gute Hardwareperformance zu erreichen. Zu diesem Punkt möchten wir Sie auch auf die Werkzeuge und die Literatur der Hardwarehersteller verweisen.
Die zuvor beschriebenen Aufgaben, die in eher unregelmäßigen Abständen anfallen und auf Grund der fehlenden Routine oder des fehlenden Prozess-Know-hows eine gewisse Komplexität mit sich bringen, sollten dahin gehend geprüft werden, ob diese von einem externen Dienstleister effizienter erbracht werden können. Eine Frage, die es zu beantworten gilt, ist, ob es erforderlich ist, das notwendige Wissen im Unternehmen vorzuhalten, um ggf schneller als der externe Dienstleister reagieren zu können. Beispielsweise bei unternehmenskritischen Systemen. Auch zu beachten sind Aspekte der Sicherheit, da externe Personen Zugriff auf das System erhalten. Fortführend müssen die durch Outtasking erbrachten Leistungen regelmäßig kontrolliert und auf deren Qualität und Dokumentation hin überprüft werden. Eine vollständige Abhängigkeit vom externen Partner darf nicht entstehen.
Einige fehlende SAP Basis Funktionen im Standard werden durch die PC-Anwendung "Shortcut for SAP Systems" nachgeliefert.
Die Applikationsschicht kommuniziert sowohl mit der Datenbankschicht als auch mit der Präsentationsschicht.
Dies wird über den Parameter rstr/accept_remote_trace konfiguriert, der auf true gesetzt sein muss.