Prozesse
Sehr gute Informatikkenntnisse – speziell SAP-Lösungen
Hierdurch wird der technische User zum Dialog-User und eine Anmeldung im SAP System ist uneingeschränkt möglich. Also meldet sich Johannes mit dem bekannten Passwort des RFC Users im Produktivsystem an. Dank sehr weitreichender Berechtigungen hat er fortan Zugriff auf allerlei kritische Tabellen, Transaktionen und Programme in Produktion. Mit der Identität des RFC Users beginnt Johannes mit der technischen Kompromittierung des Produktivsystems… RFC Sicherheit: Alles nur erfunden – oder alltägliche Bedrohung? Ob nun eine simple Verkleidung, veränderte biometrische Eigenschaften oder ein gekaperter, technischer User im SAP System: die Grundlage der Kompromittierung ist dieselbe. Eine Person nutzt eine andere Identität, um Zugang und Berechtigungen zu geschützten Bereichen zu bekommen. Außerdem hätte das Übel in allen drei Geschichten durch Pro-Aktivität verhindert werden können. Wann haben Sie sich das letzte Mal Gedanken über die Sicherheit Ihrer RFC Schnittstellen gemacht? Können Sie mit Sicherheit sagen, dass alle Ihre technischen RFC User nur die Berechtigungen besitzen, die sie auch tatsächlich benötigen? Und wissen Sie eigentlich wer genau die Passwörter dieser User kennt? Können Sie zu 100% ausschließen, dass nicht jetzt in diesem Moment ein SAP User mit falscher Identität Ihre Produktivsysteme infiltriert? Change now: Es geht um Pro-Aktivität! Doch bevor Sie jetzt beginnen und sich auf die Suche nach dem „Identitäten-Wandler“ begeben (was ich wirklich nicht empfehlen möchte!), schlage ich vor, dass Sie die Wurzel des Übels fassen und Ihre RFC Sicherheit proaktiv stärken. Wenn Sie also mehr erfahren möchten, habe ich hier folgende 3 Tipps für Sie: 1) Unser E-Book über SAP RFC-Schnittstellen 2) Unser kostenloses Webinar zum Thema RFC-Schnittstellen bereinigen 3) Blogbeitrag über unser Vorgehen zur Optimierung von RFC Schnittstellen Wie immer freue ich mich auf Ihr Feedback und Ihre Kommentare direkt unterhalb dieser Zeilen!
Liegen die Werte deutlich über den Richtwerten, liegt ein potenzielles Performanceproblem im entsprechenden Bereich (z. B. auf der Datenbank) vor. Beachten Sie, dass es sich auch hier nur um Erfahrungswerte handelt, die in speziellen SAP-Lösungen abweichen können.
SMICM ICM Monitor vom Server
Alle geplanten und ungeplanten Ausfallzeiten müssen mit Angabe der Ursache des Ausfalls in den Service Level Report aufgenommen werden. Das Service Level Agreement sollte die Verantwortlichkeiten für Sicherungen und Wiederherstellungen von Datenbanken und, falls nötig, von Dateisystemen festhalten (Backup und Recovery). Legen Sie also den Umfang der durchzuführenden Sicherungen fest. Definieren Sie ein Prozedere für die ordnungsgemäße Wiederherstellung von Datenbanken und Dateisystemen im Fehlerfall. Die dazu maximal notwendige Zeit ergibt sich aus der maximal erlaubten Ausfallzeit für ungeplante Ausfälle.
Zu jedem Lauf des Programms RSCOLL00 werden Protokolle geschrieben, anhand derer Sie mögliche Fehler feststellen können. Das Protokoll können Sie im Workload-Monitor über den Menüpfad Kollektor und Perf. Datenbank > Systemlast-Kollektor > Protokoll einsehen. Ausführliche Erläuterungen zur Funktionsweise und zur Einstellung des Kollektors finden Sie in der SAP-Onlinehilfe sowie in den SAP-Hinweisen, die in Anhang E zusammengestellt sind.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
Dennoch werden Sie bei dieser Konfiguration hohe Datenbankzeiten beobachten, da ein Prozessor zur Bearbeitung der Datenbankanfragen in einem System mit fünf Rechnern in der Regel zu klein sein wird.
Die SAP-Basis ist das Fundament eines jeden SAP-Systems. Viele nützliche Informationen dazu finden Sie auf dieser Seite: www.sap-corner.de.
Hierbei sind sowohl 32 als auch 64-Bit Versionen nutzbar.