SM19 Security-Audit
Größenberechnung des SAP Extended Memorys
Diese Zugriffsmethode hängt ausschließlich von den Rechten ab, die dem Nutzer zugewiesen sind. Systemuser: Nutzer dieser Nutzergruppe sind vergleichbar mit SAP*. Sie fungieren im System als Administrator. Daher sollten sie schnellstmöglich deaktiviert / auf inaktiv gesetzt werden, sobald der Systembetrieb sichergestellt ist. Die Behebung dieses Sicherheitsrisikos sollte Ihnen noch aus dem SAP ERP Umfeld bekannt sein. In einem HANA-System gibt es Privilegien statt Berechtigungen. Der Unterschied besteht erst einmal in der Begrifflichkeit. Trotzdem werden die Berechtigungen auch anders zugeordnet (direkt / indirekt) über die Zuordnungen von Rollen. Diese sind somit Ansammlungen von Privilegien. Wie in älteren SAP-Systemen müssen die Systemuser deaktiviert werden und bestimmte Rollen die schon bestehen eingeschränkt werden. Im Vergleich zu einem SAP ERP System werden statt große Anwendungen kleine Apps berechtigt. Hier sollte auf jeden Fall auf eine individuelle Berechtigungsvergabe geachtet werden. Für die Nutzer sollte es selbstverständlich sein, sichere Passwortregeln implementiert zu haben. Einstellungen Eine Absicherung des Systems bringt auch die Absicherung der darunter liegenden Infrastruktur mit sich. Vom Netzwerk bis zum Betriebssystem des Hosts muss alles abgesichert werden. Bei der Betrachtung der Systemlandschaft fällt auf, dass die neue Technologie viele Verbindungen mit bringt, die abzusichern sind. Auch das SAP Gateway, welches für die Verbindung zwischen Backend und Frontend zuständig ist, ist ein Sicherheitsrisiko und muss betrachtet werden. Alle Sicherheitseinstellungen der bisherigen und zukünftigen Komponenten müssen auf HANA Kompatibilität validiert werden. Sichere Kommunikation der Verbindungen erhalten Sie dann, wenn Sie den Zugriff einschränken wo möglich. Verschlüsselung der Daten eines HANA Systems ist standardmäßig deaktiviert. Achten Sie darauf, dass sie sensiblen Daten trotzdem verschlüsseln. Vor allem Daten, die archiviert werden. Wenn ein Angriff auf Ihr System erfolgt, sollten forensische Analysen gefahren werden können, daher sollten Sie das Audit Log aktivieren. Darüber hinaus sollten nur wenig Nutzer Zugriff darauf haben.
Je nachdem, ob der Nutzer die Tabelle bearbeiten oder nur anzeigen soll, kann hier entweder "UPDATE" oder "SHOW" genutzt werden. Tragen Sie als Wert ein X ein. Wichtig ist, dass entweder"'SHOW" oder "UPDATE" genutzt wird, da eine Kombination beim Aufruf der Parametertransaktion zu einem Fehler führt. Außerdem muss in der Tabelle die View gesetzt werden, die aufgerufen werden soll. Dafür ist das Feld "VIEW" zu benutzen. Schließlich kann die Parametertransaktion über die "Speichern" Schaltfläche angelegt werden. Wie gewohnt muss sie einem Paket und einem Workbenchauftrag zugewiesen werden, damit sie verfügbar wird. Wenn der Rolle einer Person nun die Berechtigung für diese Parametertransaktion zugewiesen wird, kann diese genau die angegebene View darüber öffnen und hat nicht die Möglichkeit in der SM30 alle möglichen Views einzugeben.
Tabellenpufferung und Indizierung
Das Verteilungskonzept für Webanfragen unterscheidet sich von dem für Dialoganfragen aus dem SAP GUI. Bei SAP-GUI-Anfragen werden die Anfragen eines Benutzers ohne weiteren Dispatching-Schritt von der Applikationsinstanz bearbeitet, auf die der Benutzer beim Anmelden einmal verwiesen wurde. Beim Dispatchen von Webanfragen wird nur für eine Transaktion die Bearbeitung durch dieselbe Instanz garantiert, eine neue Transaktion kann schon wieder auf einer anderen Instanz ausgeführt werden, ebenso werden Anfragen ohne transaktionalen Kontext, die man als stateless bezeichnet, immer neu verteilt.
Die Webseite www.sap-corner.de bietet viele nützliche Informationen zum Thema SAP Basis.
Die Erfahrung zeigt, dass die Performance drastisch einbricht, wenn der SAP Extended Memory erschöpft ist. Ein produktives Arbeiten mit Instanzen ist in einer derartigen Situation in der Regel nicht mehr möglich. Die Überwachung des SAP Extended Memorys muss daher höchste Priorität haben. Grundsätzlich sollten Sie Extended Memory eher verschwenderisch allokieren. Nicht verwendeter Extended Memory wird vom Betriebssystem ausgelagert. Als grobe Faustregel gilt: Mindestens 6 bis 10 MB Extended Memory sollten pro Benutzer allokiert werden. Etwa 70 bis 120 % des physischen Hauptspeichers des Rechners können als Extended Memory allokiert werden. Diese Faustregeln sind natürlich stark release- und applikationsabhängig. Sie müssen allerdings dafür sorgen, dass der vorhandene Auslagerungsspeicher des Betriebssystems (Swap Space) groß genug ist und das Betriebssystem die gewünschte Größe an Speicher überhaupt verwalten kann. Weitere Informationen dazu finden Sie in Kapitel 6, »Speicherkonfiguration«.
Mit "Shortcut for SAP Systems" steht ein Tool zur Verfügung, das einige Aufgaben im Bereich der SAP Basis erheblich erleichtert.
Viele Firmen, die ein SAP-Basis System einsetzen oder einsetzen möchten, lassen sich von externen Dienstleistern beraten oder lagern die Administration des Systems komplett aus.
So viele Informationen... wie kann man die aufheben, so dass man sie bei Bedarf wiederfindet? Scribble Papers ist ein "Zettelkasten", mit dem das sehr einfach möglich ist.
Die Parameter abap/heap_area_total, abap/heap_area_dia und abap/heap_area_nondia bestimmen eine obere Grenze für den privaten Speicher.