Nutzung von Secure Network Communication
Customizing der Benachrichtigungen gemäss Kundenwunsch
Neue Risiken in SAP HANA: Neben den bekannten Risiken bestehen auch neue Risiken durch die Verwendung von SAP HANA. Ein sehr gutes Beispiel sind häufig verwendete Webanwendungen, die etwas neues im SAP Bereich darstellen. HANA Systeme bestehen im Gegensatz zu einem SAP ERP System hauptsächlich aus Webanwendungen, die in den vorherigen Versionen eher als optional zu betrachtet wurden. Diese Webanwendungen können durch diverse Suchmaschinen im Internet aufgefunden werden. Das gilt übrigens auch für das SAP Portal oder Netweaver. Es gibt URL-Schemata die zum Auffinden des Systems beitragen. Dies gilt auch für andere SAP Systeme, die Webanwendungen verwenden. Damit ist auch die neue Technologie für typische Webangriffe verwundbar. Zu nennen sind hier SQL Injection, ABAP Code Injection oder XSS. Alle Risiken, die für ein normales SAP System bekannt sind, gelten auch für ein SAP-HANA System. Die Daten werden unverschlüsselt im RAM abgelegt. Erst dadurch gewinnt das System diesen Geschwindigkeitsvorteil. Hieraus resultieren Risiken wie ein auslesen durch Memory-scrapingmalware. Diese greifen Daten im Arbeitsspeicher ab. Verschlüsselung kostet Performance, daher wird diese standardmäßig nicht verwendet. Gerade während einer Migration läuft HANA in einem Parallelsystem, daher kommt zu Ihrer Landschaft mindestens ein neues System dazu. Beachten Sie darüber hinaus: HANA hat eigene Tools und eigene Einstellmöglichkeiten die gekannt und konfiguriert werden müssen. Unterm Strich muss beim Betrieb des Systems einfach mehr beachtet werden. Viele Einstellmöglichkeiten resultieren nicht selten in mehr Fehlern. Drei - Punkte - Plan zur HANA Sicherheit 1) Rollen und Berechtigungen Im einem bisherigen SAP System zählen Rollen und Berechtigungen sicherlich auch zu den Hauptsäulen eines sicheren Systems. Rollen und Berechtigungen funktionieren aber anders in einem HANA System. Es gibt zwei Nutzertypen: 1) Standard (eingeschränkt): Mit diesem Nutzertyp gibt es verschiedene Zugriffsmethoden auf die Datenbank. Hier werden beispielsweise die Technologien JDBC oder HTTP verwendet, um zwei Beispiele zu nennen.
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.
SAP Script
Im weiteren Verlauf des Projekts holen Sie ein oder mehrere Angebote von Hardwarepartnern ein. Die Hardwarepartner erstellen das Hardware-Sizing, da nur sie die Leistungsfähigkeit ihrer Hardware bewerten können. Sofern nötig, greifen die Hardwarepartner über ihre SAP Competence Center auf die entsprechenden Sizing-Experten der SAP zurück. Um den Sizing-Prozess zu vereinfachen, hat SAP folgendes Standardverfahren definiert: Legen Sie zu Ihrem Einführungsprojekt ein Sizing-Projekt im Quick Sizer im SAP Support Portal an. Dort legen Sie die für das Sizing notwendigen Daten ab. Unterstützt der Quick Sizer das Sizing für die ausgewählten Prozesse nicht, verwenden Sie die entsprechenden Sizing-Guidelines. Anschließend gewähren Sie den Hardwarepartnern, von denen Sie ein Sizing-Angebot wünschen, Zugriff auf dieses Sizing-Projekt im SAP Support Portal, indem Sie ihnen das Kennwort für das entsprechende Projekt mitteilen. Die Links zu den jeweiligen Internetseiten der Hardwarepartner finden Sie ebenfalls im Quick Sizer. Die Hardwarepartner erstellen nun aufgrund der von Ihnen hinterlegten Daten ein konkretes Hardwareangebot.
Die Performance der Dialoganwendungen und der Hintergrundanwendungen sind in der Regel unabhängig voneinander zu bewerten. Zur Performanceüberwachung gehört die bedarfsgerechte Ressourcenzuteilung, wenn beide Arten von Anwendungen auf einem technischen IT-System laufen (was normalerweise der Fall ist). In der Regel wird man Dialoganwendungen höhere Priorität einräumen als Hintergrundanwendungen. Ausnahmen bestätigen dagegen die Regel: Hintergrundanwendungen mit einer festen Deadline beanspruchen wiederum die höchste Priorität. Ein Beispiel dafür ist der Druck von Lieferunterlagen (Lieferscheine, Adressaufkleber, Rechnungen etc.). Wenn diese nicht zu einem bestimmten Zeitpunkt fertig sind, ergibt sich unter Umständen eine Lieferverzögerung von 24 Stunden (Postausgang!).
Etliche Aufgaben der SAP Basis können mit "Shortcut for SAP Systems" einfacher und schneller erledigt werden.
Dazu muss eine geeignete Verkehrsinfrastruktur (1), in diesem Fall befahrbare Straßen, vorhanden sein.
Kurzzeitig auftretende Wartesituationen auf Datenbanksperren sind daher nicht als Performanceproblem zu werten.