Checklisten und praktische Prüfung zu Kapitel 1

Checklisten und praktische Prüfung

zu Kapitel 1

Kapitel 1, »Umgang mit dem SAP-System und Werkzeuge zur Prüfung«, enthält keine

Checklisten.

1


zu Kapitel 2

2.1 SAP NetWeaver und SAP-Komponenten

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle CVERS anzeigen. Hier fin-

den Sie die Softwarekomponenten, den jeweiligen Releasestand und das Patch-Level.

2.2 Der technische Aufbau eines SAP-Systems

2.2.1 Betriebssystem

Rufen Sie den Menüpfad System • Status auf. Im Bereich Rechnerdaten finden Sie das

Betriebssystem.

Thema Risiko Fragestellung

Vorgabe oder Erläuterung

SAP-Komponenten 3 Welche SAP-Komponenten sind installiert?

Informativer Punkt für nachfolgende Prüfungen. Ein-

zelne Aspekte der Sicherheit können je nach eingesetz-

ten Komponenten variieren.



SAP-Systemaufbau 3 Auf welchem Betriebssystem laufen die SAP-Server?

Informativer Punkt für nachfolgende Prüfungen. Die

Sicherheit variiert je nach eingesetztem Betriebssystem.

3

2 Checklisten und praktische Prüfung zu Kapitel 2

2.2.2 Datenbank

Rufen Sie den Menüpfad System • Status auf. Im Bereich Datenbankdaten finden Sie

die Datenbank.

2.2.3 Applikationsserver

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle TPFID anzeigen. Im Feld

HOST (Host-Name) werden die Server aufgelistet.

2.3 Systemlandschaften

2.3.1 Art der Systemlandschaft



SAP-Systemaufbau 3 Welche Datenbank wird eingesetzt?


Sicherheit variiert je nach eingesetzter Datenbank.



SAP-Systemaufbau 3 Wie viele Applikationsserver werden eingesetzt?


Absicherung der Betriebssystemebene erfolgt pro Appli-

kationsserver.



Systemlandschaften 3 Welche Art der Systemlandschaft wird eingesetzt?


Sicherheit der einzelnen SAP-Systeme variiert je nach

eingesetzter Systemlandschaft.

4

2.3 Systemlandschaften

Rufen Sie Transaktion STMS auf, und klicken Sie auf die Schaltfläche Transportwege.

Ihnen werden alle Systeme der Systemlandschaft mit den eingerichteten Transport-

wegen angezeigt.

2.3.2 Produktive Daten im Qualitätssicherungssystem

Melden Sie sich am Qualitätssicherungssystem an. Überprüfen Sie stichprobenartig

die vorhandenen Daten. Rufen Sie hierzu Transaktion SE16 auf, und lassen Sie sich

die gewünschten Daten anzeigen, z. B.:

� Kreditorenstammdaten (LFA1, LFB1, LFBK)

� Debitorenstammdaten (KNA1, KNB1, KNBK)

� Buchhaltungsbelege (BKPF, BSEG, BSEC)

� Mitarbeiterdaten (PA0002, PA0009, usw.)

2.3.3 Produktive Daten im Entwicklungssystem



Systemlandschaften 2 Sind im Qualitätssicherungssystem produktive Daten

vorhanden?

Bei der Nutzung produktiver Daten im Qualitätssiche-

rungssystem müssen die Berechtigungen analog dem

Produktivsystem vergeben sein.

Hier besteht das Risiko, dass dem Benutzer im Qualitäts-

sicherungssystem durch erweiterte Rechte ein Zugriff

auf sensible Daten möglich ist.



Systemlandschaften 1 Sind im Entwicklungssystem produktive Daten vorhan-

den?

Produktive Daten dürfen im Entwicklungssystem nicht

genutzt werden.

Hier besteht das Risiko, dass ein großer Personenkreis

von Entwicklern, Customizing-Benutzern und Beratern

uneingeschränkt auf produktive Daten zugreifen kann.

5


Melden Sie sich im Entwicklungssystem an. Überprüfen Sie stichprobenartig die vor-

handenen Daten. Rufen Sie hierzu Transaktion SE16 auf, und lassen Sie sich die

gewünschten Daten anzeigen, z. B.:

� Kreditorenstammdaten (LFA1, LFB1, LFBK)

� Debitorenstammdaten (KNA1, KNB1, KNBK)

� Buchhaltungsbelege (BKPF, BSEG, BSEC)

� Mitarbeiterdaten (PA0002, PA0009, usw.)

2.4 Das Mandantenkonzept

2.4.1 Vorhandene Mandanten

Rufen Sie Transaktion SCC4 auf. Alternativ können Sie sich Tabelle T000 über Trans-

aktion SE16 anzeigen lassen.

2.4.2 Letzte Änderung



Mandantenkonzept 1 Welche Mandanten existieren im Produktivsystem? Ent-

sprechen diese Mandanten den Vorgaben zu den not-

wendigen Mandanten im System?

Es dürfen nur die Mandanten der Vorgabe existieren.

Hier besteht das Risiko, dass der Produktivmandant von

anderen Mandanten aus manipuliert werden kann (z. B.

durch Änderungen mandantenübergreifender Tabellen).



Mandantenkonzept 3 Wurde die letzte Änderung der Mandanten (wann und

von wem) dokumentiert?

Die letzte Änderung muss dokumentiert sein.

Hier besteht das Risiko, dass nicht nachvollziehbare

Änderungen vorgenommen werden, z. B. ein Freischal-

ten des Produktivmandanten für das Customizing.

6

2.4 Das Mandantenkonzept

Rufen Sie Transaktion SCC4 auf. Durch einen Doppelklick auf einen Mandanten wer-

den Ihnen das Änderungsdatum und der Änderer angezeigt.

Alternativ können Sie sich Tabelle T000 über Transaktion SE16 anzeigen lassen. Das

Feld CHANGEUSER (Autor der letzten Änderung) zeigt den Änderer; das Feld CHANGEDATE

(Datum der letzten Änderung) zeigt das Änderungsdatum.

2.4.3 Protokollierung

Sie müssen zwei Prüfungen ausführen:

1. Rufen Sie Transaktion SE13 auf. Tragen Sie Tabelle T000 ein, und klicken Sie auf die

Schaltfläche Anzeigen. Der Eintrag Datenänderungen protokollieren muss akti-

viert sein.

2. Rufen Sie Transaktion RSPFPAR auf. Geben Sie in der Selektionsmaske den Para-

meternamen rec/client an. Der Parameter muss den Wert »ALL« oder die Man-

dantennummer(n) enthalten.

2.4.4 Benutzer



Mandantenkonzept 1 Wird die Tabelle der Mandanten (T000) protokolliert?

Tabelle T000 muss protokolliert werden.

Hier besteht das Risiko, dass z. B. das Anlegen neuer

Mandanten oder das Freischalten des Produktivmandan-

ten für das Customizing nicht nachvollziehbar ist.



Mandantenkonzept 1 Welche Benutzer existieren in den Mandanten 000 und

066?

Es dürfen nur die Standardbenutzer sowie Administra-

torkonten existieren.

Hier besteht das Risiko, dass Benutzer von diesen Man-

danten aus Einstellungen des Systems nicht nachvoll-

ziehbar ändern.

7


Zur Prüfung dieser Fragestellung stehen Ihnen zwei Möglichkeiten zur Verfügung:

1. Überprüfen Sie zusammen mit einem Administrator in beiden Mandanten die

Benutzer, indem Sie sich jeweils Tabelle USR02 anzeigen lassen. Alternativ nutzen

Sie die Auswertungen in Transaktion SUIM:

– Benutzer nach Adressdaten

– Benutzer nach komplexen Selektionskriterien

2. Nur bis SAP NetWeaver 7.40: Rufen Sie den Report RSUVM005 auf. Dieser Report

zeigt zu allen Benutzern in allen Mandanten die Benutzervermessungsdaten an.

Der Report hat den Nebeneffekt, dass ein Überblick über alle Benutzer des Systems

möglich ist.

2.4.5 Mandantenkopien

Rufen Sie Transaktion SCC3 auf, und klicken Sie auf die Schaltfläche Alle Mandanten.

Transaktion SCC3 muss in dem System aufgerufen werden, in das die Daten kopiert

wurden (in der Regel das Qualitätssicherungs- und Entwicklungssystem).

Vergleichen Sie die Mandantenkopierprotokolle mit der Dokumentation. Lassen Sie

sich Unstimmigkeiten von den Verantwortlichen erläutern.



Mandantenkopien 1 Welche Daten wurden zu welchem Zeitpunkt aus dem

Produktivmandanten herauskopiert?

Wurden Mandantenkopien erstellt, die nicht dokumen-

tiert sind?

Jede Kopie muss dokumentiert sein.

Hier besteht das Risiko, dass Produktivdaten unberech-

tigt in andere Mandanten bzw. Systeme kopiert wurden.



Mandantenkopien 1 Existieren Vorgaben zur Dokumentation von Mandan-

tenkopien?

Es müssen Vorgaben zur Dokumentation definiert sein.

Hier besteht das Risiko, dass Mandantenkopien und

deren Umfang nicht nachvollzogen werden können

(z. B. Kopien in das Entwicklungssystem).

8

2.5 Sicherheit im Mandanten 000

Prüfen Sie, ob diese Dokumentation existiert und ausreichend ausgeprägt ist.


2.5.1 Benutzer

Rufen Sie im Mandanten 000 Transaktion SE16 auf, und lassen Sie sich Tabelle USR02

anzeigen. Alternativ nutzen Sie die Auswertungen in Transaktion SUIM:

� Benutzer nach Adressdaten

� Benutzer nach komplexen Selektionskriterien

2.5.2 Zugriff auf Produktivdaten

Rufen Sie Transaktion SUIM auf, und wählen Sie den Menüpfad Benutzer • Benutzer

nach komplexen Selektionskriterien • Benutzer nach komplexen Selektionskriterien.

Tragen Sie dort auf der Registerkarte Berechtigungen im Bereich Selektion nach Wer-

ten die in der folgenden Tabelle aufgeführten Berechtigungsobjekte und Werte ein.



Sicherheit in

Mandant 000

1 Welche Benutzer existieren im Mandanten 000?

Es dürfen nur administrative Benutzer existieren.

Hier besteht das Risiko, dass vom Mandanten 000 aus

kritische Aktionen ausgeführt werden oder auf Produktiv-

daten zugegriffen wird.



Sicherheit in

Mandant 000

1 Wer besitzt die Berechtigung zum Zugriff auf Produktiv-

daten vom Mandanten 000 aus?

Berechtigungen zum Zugriff auf Produktivdaten sollten

im Mandanten 000 nicht vergeben werden.

Hier besteht das Risiko, dass vom Mandanten 000 aus

auf Produktivdaten zugegriffen wird.

9


Abbildung 2.1 zeigt ein Beispiel für die Ausprägung des Berechtigungsobjekts

S_DBCON; Abbildung 2.2 zeigt ein Beispiel für das Berechtigungsobjekt S_TABU_SQL. Die

rot umrandeten Felder befüllen Sie mit den unternehmenseigenen Werten gemäß

Abschnitt 2.2, »Der technische Aufbau eines SAP-Systems«.

Abbildung 2.1 Berechtigung für das Objekt S_DBCON

Berechtigungsobjekt Feld Wert

S_DBCON ACTVT(Aktivität)

03 (Anzeigen)

DBA_DBHOST(Servername)

<Servername>

DBA_DBSID(Datenbankname)

<Datenbankname>

DBA_DBUSER(Datenbankbenutzer)

<Datenbankbenutzer>

S_TABU_SQL ACTVT(Aktivität)

33 (Lesen)

DBSID(Datenbankverbindung)

<Datenbankverbindung>

TABLE(Tabelle)

*

TABOWNER(Besitzer in der Datenbank)

<Datenbankbenutzer>

10


Abbildung 2.2 Berechtigung für das Objekt S_TABU_SQL

2.5.3 Pflege von Systemeinstellungen




ten nacheinander die Berechtigungsobjekte und Werte aus der folgenden Tabelle ein.



Sicherheit in

Mandant 000

2 Wer besitzt die Berechtigung zur Pflege von Systemein-

stellungen im Mandanten 000?

Berechtigungen zum Pflegen von Systemeinstellungen

dürfen im Mandanten 000 nur dem Rechenzentrum

bzw. der Basisadministration zugeordnet werden.

Hier besteht das Risiko, dass Berechtigungen, mit denen

das System beeinflusst werden kann, falsch zugeordnet

wurden.


Einstellen der Systemänderbarkeit

S_CTS_ADMI oder

S_CTS_SADMS_ADMI_FCD(Systemadministrations-

funktion)

SYSC

11


Anlegen neuer Mandanten

S_ADMI_FCD CTS_ADMFCT(Administrationsaufgabe)

T000

Konfiguration des Security Audit Logs (bis SAP NetWeaver 7.40)

S_ADMI_FCD S_ADMI_FCD(Systemadministrationsfunk-

tion)

AUDA

Konfiguration des Security Audit Logs (ab SAP NetWeaver 7.50)

S_SAL SAL_ACTVT(Security Audit Log – Aktivitä-

ten)

EDIT_CONFS

EDIT_CONFD

EDIT_PARAM

Pflege von RFC-Verbindungen

S_RFC_ADM ACTVT(Aktivität)

01 (Anlegen)

02 (Ändern)

06 (Löschen)

Pflege von Trusted Systems

S_RFC_TT ACTVT(Aktivität)

01 (Anlegen)

02 (Ändern)

06 (Löschen)

Konfiguration der an SAP Enterprise Threat Detection zu übertragenden Protokolle

S_TABU_DIS ACTVT(Aktivität)

02 (Ändern)

DICBERCLS(Berechtigungsgruppe)

SECM

S_TABU_NAM ACTVT(Aktivität)

02 (Ändern)

TABLE(Tabelle)

SECM_LOGS


12


2.5.4 Entwicklerberechtigung




ten das Berechtigungsobjekt und die Werte aus der folgenden Tabelle ein (die weite-

ren Felder bleiben leer).

Übertragung der Konfiguration an SAP Enterprise Threat Detection

S_SEC_MON ACTVT(Aktivität)

70 (Administrieren)

SECM_LOG(zu übertragende Protokolle)

*



Sicherheit in Man-

dant 000

1 Wer besitzt Entwicklerberechtigungen im Mandan-

ten 000?

Entwicklerberechtigungen dürfen in keinem Man-

danten des Produktivsystems vergeben werden.

Hier besteht das Risiko, dass durch die Vergabe von

Entwicklerberechtigungen gegen gesetzliche Aufla-

gen verstoßen werden kann.


S_DEVELOP ACTVT(Aktivität)

01 (Anlegen) oder

02 (Ändern)

OBJTYPE(Objekttyp)

PROG oder

DEBUG


13


2.5.5 Löschen von Protokollen




ten Berechtigungsobjekte und Werte aus der folgenden Tabelle ein.



Sicherheit in

Mandant 000

1 Wer besitzt Berechtigungen zum Löschen von Proto-

kollen im Mandanten 000?

Berechtigungen zum Löschen von Protokollen dürfen

in keinem Mandanten des Produktivsystems verge-

ben werden.

Hier besteht das Risiko, dass durch die Vergabe dieser

Berechtigungen aufbewahrungspflichtige Protokolle

des Produktivmandanten gelöscht werden können.


Löschen von Tabellenänderungsversionen (S_TABU_DIS)

(§ 257 Aufbewahrung von Unterlagen)


02 (Ändern)


SA

S_TABU_CLI CLIIDMAINT(Kennzeichen)

X

Löschen von Tabellenänderungsversionen (S_TABU_NAM)

(§ 257 Aufbewahrung von Unterlagen)


02 (Ändern)

TABLE(Tabelle)

DBTABLOG


X

14


zu Kapitel 3

3.1 Grundlagen für die Prüfung der Systemsicherheit

3.1.1 SAP-Release

Rufen Sie den Menüpfad System • Status auf, und klicken Sie auf die Schaltfläche

Details. Die Komponente SAP_BASIS beinhaltet den ABAP-Stack von SAP NetWeaver.

Hier finden Sie auch das Release und das Support-Package-Level (siehe Abbildung

3.1).

Abbildung 3.1 Installierte Softwarekomponentenversionen



SAP-Release 3 Welches SAP-Release wird eingesetzt? Wie ist der aktuelle

Stand der Support Packages?

Informativer Punkt für nachfolgende Prüfungen. Einzelne

Aspekte der Sicherheit können je nach Release-/Support-

Package-Stand variieren.

15


3.1.2 Vorgaben für Systemparameter

Lassen Sie sich die Vorgaben für die im Folgenden beschriebenen Prüfungen aushän-

digen.

Rufen Sie Transaktion RSPFPAR auf. Lassen Sie die Selektionsmaske leer. Es werden

alle Parameter angezeigt. Gleichen Sie die aktuellen Werte mit den Vorgaben ab. Um

die aktuellen Werte zu ermitteln, lesen Sie diese zeilenweise von links nach rechts.

Der erste Wert ist der aktuelle Wert. In Abbildung 3.2 lautet der aktuelle Wert für den

Parameter auth/auth_user_trace »F«, und für auth/check/calltransaction beträgt

der Wert »2«.



Systemparameter 1 Existieren Vorgaben für die Einstellungen der Systempa-

rameter?

Es müssen Vorgaben für die Einstellungen der relevantes-

ten Systemparameter vorliegen.

Hier besteht die Gefahr, dass die Parameter durch feh-

lende Vorgaben falsch konfiguriert werden.



Systemparameter 1 Entsprechen die aktuellen Parameterwerte den Unter-

nehmensvorgaben?

Die aktuellen Einstellungen müssen den Vorgaben ent-

sprechen. Abweichungen müssen dokumentiert und

begründet sein.

Hier besteht die Gefahr, dass durch eine falsche Parame-

trisierung Sicherheitslücken entstehen.

16

3.1 Grundlagen für die Prüfung der Systemsicherheit

Abbildung 3.2 Systemparameter anzeigen

3.1.3 Kontrolle nach Upgrades

Lassen Sie sich diese Vorgaben aushändigen. Überprüfen Sie, ob laut Vorgabe nach

jedem Releasewechsel, Kernel-Update usw. eine Nachkontrolle erfolgen muss.



Systemparameter 1 Existieren Vorgaben für die Kontrolle der Parameterein-

stellungen nach Releasewechseln, Kernel-Updates usw.?

Es müssen Vorgaben und Verantwortlichkeiten zur nach-

gelagerten Kontrolle der Systemparameter nach dem Ein-

spielen von Updates existieren.

Hier besteht die Gefahr, dass Parameter durch Updates

falsche oder ungültige Werte enthalten bzw. auf den

Standardwert zurückgesetzt wurden.

17


3.1.4 Geänderte Parameterwerte

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle TPFHT anzeigen. Zwei Fel-

der sind relevant:

� MUSR (Benutzer): letzter Änderer von Parameterwerten

� GUSR (Generierer): letzter Generierer des Profils

In den meisten Fällen sind die Benutzer in beiden Feldern gleich. Gleichen Sie die

Benutzernamen mit den berechtigten Administratoren ab.

3.1.5 Zentrale oder instanzbezogene Parameterwerte

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle TPFET anzeigen. In der

Datei werden zum Default-Profil und zu den Instanzprofilen alle Versionen mit den

Parameterwerten gespeichert. Lassen Sie sich zum Default-Profil sowie zu den einzel-

nen Instanzprofilen jeweils die höchste Version anzeigen. Gleichen Sie ab, ob Para-

meter in den Instanzprofilen aktiv sind, die auch im Default-Profil gesetzt sind.



Systemparameter 1 Wurden Änderungen an Parameterwerten nur von

berechtigten Personen durchgeführt?

Änderungen an Parametern dürfen ausschließlich von

berechtigten Administratoren durchgeführt werden.

Hier besteht die Gefahr, dass unberechtigte Personen

Parameter ändern und dadurch die Systemstabilität und

-sicherheit gefährden.



Systemparameter 1 Wurden Parameter sowohl im Instanz- als auch im

Default-Profil gesetzt?

Parameter sind entweder zentral zu definieren oder pro

Instanz.

Hier besteht die Gefahr, dass Parameterwerte inkonsis-

tent definiert sind.

18

3.2 Anmeldesicherheit

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle TPFET anzeigen. In der

Datei werden zu den Instanzprofilen alle Versionen mit den Parameterwerten

gespeichert. Lassen Sie sich zu den einzelnen Instanzprofilen jeweils die höchste Ver-

sion anzeigen. Gleichen Sie ab, ob Parameter in den Instanzprofilen unterschiedliche

Werte haben.


3.2.1 Kennwörter

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle USR40 anzeigen. Gleichen

Sie diese mit den unternehmensspezifischen Vorgaben ab.



Systemparameter 1 Wurden für Parameter auf verschiedenen Instanzen

unterschiedliche Werte gesetzt?

Parameter sind auf den verschiedenen Instanzen gleich-

zusetzen. Ausnahmen müssen dokumentiert werden.

Hier besteht die Gefahr, dass Parameterwerte inkonsis-

tent über die Instanzen definiert sind.



Anmeldesicherheit 3 Wurden in Tabelle USR40 unzulässige Kennwörter einge-

tragen?

Unzulässige Kennwörter (Firmenname usw.) müssen in

diese Tabelle eingetragen werden.

Hier besteht das Risiko, dass Benutzer triviale Kennwörter

nutzen, die leicht zu hacken sind.

19


Lassen Sie sich diese Vorgaben aushändigen.

3.2.2 Benutzerkonten

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle USR41_MLD anzeigen. Im

Feld COUNTER (Zähler) wird angezeigt, wie oft ein Benutzer bereits mehrfach parallel

angemeldet war (siehe Abbildung 3.3). Prüfen Sie, ob hier hohe Einträge vorhanden

sind. Falls ja, überprüfen Sie, ob diese Benutzerkonten eventuell von mehreren An-

wendern genutzt werden und damit gegen den Lizenzvertrag verstoßen wird.



Anmeldesicherheit 1 Existieren Vorgaben für die Komplexität von Kennwör-

tern?

Es müssen Vorgaben bezüglich der Komplexität von

Kennwörtern für die Benutzer existieren.


benutzen, die leicht zu knacken sind.



Anmeldesicherheit 1 Werden Benutzerkonten von mehreren Anwendern paral-

lel genutzt?

Eine Mehrfachnutzung von Benutzerkennungen ent-

spricht standardmäßig nicht dem SAP-Lizenzvertrag.

Hier besteht das Risiko, dass gegen die Lizenzvereinbarun-

gen mit SAP verstoßen wird.

20


Abbildung 3.3 Mehrfachanmeldungen von Benutzern in Tabelle USR41_MLD

3.2.3 Anmeldeparameter

Rufen Sie Transaktion RSPFPAR auf, und lassen Sie sich die Anmeldeparameter anzei-

gen. Vergleichen Sie diese mit den Unternehmensvorgaben.



Anmeldesicherheit 1 Wie wurden die Anmeldeparameter des SAP-Systems ein-

gestellt?

Die Anmeldeparameter müssen gemäß den Vorgaben

und Sicherheitsrichtlinien eingestellt sein.

Hier besteht das Risiko, dass der Anmeldevorgang nicht

gemäß den Unternehmensrichtlinien abgesichert ist.

21


3.2.4 Sicherheitsrichtlinien



Geben Sie dort auf der Registerkarte Logondaten im Feld Sicherheitsrichtlinie das

Selektionskriterium Ungleich ( ) ein (siehe Abbildung 3.4).

Abbildung 3.4 Nutzung von Sicherheitsrichtlinien prüfen



Anmeldesicherheit 2 Werden Sicherheitsrichtlinien genutzt?

Die Sicherheitsrichtlinien müssen gemäß den Vorgaben

und Unternehmensrichtlinien eingestellt sein.

Hier besteht das Risiko, dass die Anmelderestriktionen

durch die Sicherheitsrichtlinien umgangen werden.

22


3.2.5 Kennwort-Hash-Werte




ten nacheinander die Berechtigungsobjekte und Werte aus der folgenden Tabelle ein.



Anmeldesicherheit 1 Wurden Berechtigungen zur Anzeige der Tabellen mit den

Kennwort-Hash-Werten vergeben?

Berechtigungen zur Anzeige der Tabellen mit den Kenn-

wort-Hash-Werten dürfen nicht vergeben werden.

Hier besteht das Risiko, dass Kennwort-Hash-Werte aus-

gelesen und gehackt werden können.


S_TCODE TCD(Transaktion)

SE16 oder eine in Abschnitt 1.3

des Buches, »Anzeigen von

Tabellen«, beschriebene Trans-

aktion


03 (Anzeigen)


SPWD (Kennwort-Hash-Werte)

oder


SE16 oder Transaktion gemäß

Abschnitt 1.3 des Buches,

»Anzeigen von Tabellen«


03 (Anzeigen)

TABLE(Tabelle)

USH02

USH02_ARC_TMP

USR02

USRPWDHISTORY

VUSER001

VUSR02_PWD

23


3.3 Das Notfallbenutzerkonzept

3.3.1 Existenz des Notfallbenutzers

Erkundigen Sie sich bei der Administration nach dem Notfallbenutzer. Überprüfen

Sie, ob diese Angaben mit der Dokumentation übereinstimmen. Rufen Sie Trans-

aktion SU01 auf, und lassen Sie sich die Eigenschaften des Benutzers anzeigen. Kon-

trollieren Sie insbesondere die folgenden Einstellungen:

� Es darf kein Ablaufdatum angegeben sein.

� Der Benutzer muss der Gruppe der Administratoren (standardmäßig der Gruppe

SUPER) zugeordnet sein.

� Der Benutzer darf nicht gesperrt sein.

� Dem Benutzer sollte das Profil SAP_ALL oder ähnliche Rechte zugeordnet sein.

3.3.2 Vier-Augen-Prinzip

Diese Kontrolle kann nur durch ein Interview mit den Administratoren erfolgen.



Notfallbenutzer 2 Existiert ein Notfallbenutzer in den einzelnen Mandan-

ten?

Es muss ein Notfallbenutzer in den einzelnen Mandanten

vorhanden sein.

Hier besteht das Risiko, dass kritische Zugriffsrechte für

einen Notfall an aktive Benutzer vergeben werden, die

diese Rechte jederzeit einsetzen können.



Notfallbenutzer 2 Wurde das Kennwort des Notfallbenutzers nach dem

Vier-Augen-Prinzip vergeben?

Das Kennwort muss nach dem Vier-Augen-Prinzip verge-

ben werden.

Hier besteht das Risiko, dass der Notfallbenutzer von ein-

zelnen Personen genutzt und damit anonym Aktionen

durchgeführt werden können.

24

3.3 Das Notfallbenutzerkonzept


Rufen Sie Transaktion RSAU_CONFIG_SHOW auf (oder Transaktion SM19, falls die

ältere Security-Audit-Log-Variante genutzt wird). Überprüfen Sie, ob der Benutzer

dort eingetragen wurde und alle seine Aktionen protokolliert werden (siehe Abbil-

dung 3.5).

Abbildung 3.5 Konfiguration des Security Audit Logs prüfen



Notfallbenutzer 1 Wird der Benutzer über das Security Audit Log protokol-

liert?

Der Notfallbenutzer muss über das Security Audit Log

protokolliert werden.

Hier besteht das Risiko, dass mit diesem Benutzer nicht

nachvollziehbare Aktionen durchgeführt werden können.

25


Gleichen Sie die Protokolle mit den Einträgen des Security Audit Logs ab.

3.3.4 Dokumentation

Lassen Sie sich die Vorgaben zur Dokumentation der Nutzung aushändigen.

3.3.5 Letzte Anmeldung



Notfallbenutzer 1 Werden alle Protokolle über die Aktionen des Notfallbe-

nutzers nach dessen Nutzung gespeichert und aufbe-

wahrt?

Nach der Nutzung des Notfallbenutzers müssen alle Pro-

tokolle über seine Tätigkeiten gespeichert und aufbe-

wahrt werden.

Hier besteht das Risiko, dass die durchgeführten Aktionen

ohne diese Protokolle nicht nachvollzogen werden kön-

nen.



Notfallbenutzer 1 Wird die Nutzung des Notfallbenutzers inhaltlich doku-

mentiert?

Die Nutzung des Notfallbenutzers muss inhaltlich doku-

mentiert werden.

Hier besteht das Risiko, dass nicht nachvollzogen werden

kann, wer den Notfallbenutzer genutzt hat.



Notfallbenutzer 1 Wann war der Notfallbenutzer das letzte Mal angemel-

det, warum, und wurde dies dokumentiert?

Die letzte Anmeldung muss inhaltlich dokumentiert sein.

Hier besteht das Risiko, dass der Notfallbenutzer unbe-

rechtigt genutzt wurde.

26

3.4 Sperren von Transaktionscodes

Rufen Sie Transaktion SUIM auf, und wählen Sie den Menüpfad Benutzer • nach

Anmeldedatum und Kennwortänderung. Geben Sie im Feld Benutzer den Namen

des/der Notfallbenutzer an, und führen Sie den Report aus. Gleichen Sie die Doku-

mentation (siehe Abschnitt 3.3.4, »Dokumentation«) mit dem Datum ab (siehe Abbil-

dung 3.6).

Abbildung 3.6 Letzte Anmeldung der Notfallbenutzer

3.4 Sperren von Transaktionscodes

3.4.1 Richtlinien

Lassen Sie sich die Vorgaben für die zu sperrenden Transaktionen aushändigen.



Transaktion 3 Existiert eine Vorgabe, welche Transaktionen zu sperren

sind?

Die zu sperrenden Transaktionen sind als Soll zu doku-

mentieren.

Hier besteht das Risiko, dass die zu sperrenden Transakti-

onen nicht im Berechtigungskonzept beachtet werden.

27


3.4.2 Vorhandene Sperren

Rufen Sie Transaktion RSAUDITC_BCE auf, und lassen Sie sich die gesperrten Trans-

aktionen anzeigen (siehe Abbildung 3.7).

Abbildung 3.7 Gesperrte Transaktionen anzeigen



Transaktion 3 Sind die Transaktionen im System gesperrt?

Die Vorgaben zur Sperrung müssen umgesetzt worden

sein.

Hier besteht das Risiko, dass die aus Sicherheits- oder

betriebswirtschaftlichen Gründen zu sperrenden Transak-

tionen nicht gesperrt sind und von Benutzern aufgerufen

werden können.

28

3.5 Logische Betriebssystemkommandos

3.5 Logische Betriebssystemkommandos

3.5.1 Vorhandene Betriebssystemkommandos

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle SXPGCOSTAB (unterneh-

menseigene Betriebssystemkommandos) anzeigen.

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle SXPGHISTOR (Historie zu

Betriebssystemkommandos) anzeigen. Vergleichen Sie Einträge, die hinzugefügt

(Eintrag »C« im Feld MODIFICATI – Art der Modifikation) und kurze Zeit später wieder

gelöscht wurden (Eintrag »D« im Feld MODIFICATI).



Logische

Betriebssystem-

kommandos

2 Welche logischen Betriebssystemkommandos sind im

System vorhanden?

Es dürfen nur die tatsächlich genutzten Betriebssystem-

kommandos vorhanden sein.

Hier besteht das Risiko, dass kritische Kommandos (z. B.

del oder rm) definiert wurden.



Logische

Betriebssystem-

kommandos

1 Wurden logische Betriebssystemkommandos angelegt

und kurze Zeit danach wieder gelöscht?

Das Anlegen und Löschen muss dokumentiert werden.

Hier besteht das Risiko, dass über solche Kommandos

nicht nachvollziehbare Aktionen im Betriebssystem

durchgeführt werden können.

29


3.5.2 Report »RSBDCOS0«

Rufen Sie Transaktion SM21 auf, und schränken Sie im Feld Meldungs-ID auf die Mel-

dungsnummer »LC0« ein.

3.6 Drucken und Speichern

3.6.1 Benutzerspezifische Einstellungen

Rufen Sie Transaktion SQVI auf, und legen Sie einen neuen QuickView an (siehe

Abschnitt 1.7.3 »Erstellen eines QuickViews mit einer logischen Datenbank« im

Buch):

� Name: ZSPO_AUTH (oder gemäß Ihrer Namenskonventionen)

� Titel: Benutzer mit Druckerberechtigungen

� Datenquelle: Tabellen-Join

Fügen Sie die folgenden Tabellen ein:

� AGR_USERS

� AGR_1251

Wählen Sie die Listen- und Selektionsfelder, wie in Abbildung 3.8 gezeigt, aus.



logische

Betriebssystem-

kommandos

1 Wird häufig der Report RSBDCOS0 genutzt?

Der Report sollte nicht genutzt werden.

Hier besteht das Risiko, dass nicht nachvollziehbare Aktio-

nen im Betriebssystem durchgeführt werden können.



Drucken 3 Wurde für jeden Benutzer festgelegt, auf welchem Dru-

cker er drucken darf?

Für jeden Benutzer müssen die Drucker definiert werden,

auf denen er drucken darf (Berechtigungsobjekt S_SPO_DEV).

Hier besteht das Risiko, dass sensible Daten auf Druckern

falscher Abteilungen gedruckt werden.

30


Abbildung 3.8 Query zur Abfrage der Benutzer mit Druckerberechtigungen erstellen

Setzen Sie beim Ausführen die in Abbildung 3.9 gezeigten Selektionskriterien. Im

Feld Datum der Gültigkeit geben Sie das aktuelle Datum an.

Abbildung 3.9 Aktuelle Benutzer mit Druckerberechtigungen abfragen

Ihnen werden die Benutzer mit den ihnen zugeordneten Druckern angezeigt. Prüfen

Sie hier, ob Benutzer eine Sternberechtigung (= alle Drucker) erhalten haben und ob

die zugeordneten Drucker korrekt sind (eventuell stichprobenartig).

Die Liste aller Drucker können Sie sich mit Tabelle TSP03 anzeigen lassen (siehe Abbil-

dung 3.10).

31


Abbildung 3.10 Benutzer mit Druckerberechtigungen

3.6.2 Zugriff auf Druckaufträge

Ob die Druckaufträge durch Berechtigungen geschützt werden, sollte in einem Kon-

zept definiert sein. Am System prüfen Sie, ob für Benutzer, die mit sensiblen Daten

arbeiten (z. B. die Personalabteilung) im Stammsatz bereits eine Berechtigungs-

gruppe für Spool-Aufträge hinterlegt ist. Rufen Sie hierzu Transaktion SE16 auf, und

lassen sich Tabelle USR05 anzeigen. Geben Sie als Selektionskriterium im Feld Parame-

ter-Id den Wert »SAU« (Spool-Berechtigung) ein (siehe Abbildung 3.11).



Drucken 2 Werden Druckaufträge durch die Angabe einer Berechti-

gung geschützt?

Besonders Druckaufträge mit sensiblen Daten (z. B. in SAP

ERP HCM) sollten durch eine Angabe im Feld Berechti-

gung beim Drucken geschützt werden.

Hier besteht das Risiko, dass unberechtigte Zugriffe auf

Druckaufträge mit sensiblen Daten möglich sind.

32


Abbildung 3.11 Berechtigungsgruppen in Benutzerstammsätzen für Spool-Aufträge abfra-

gen

Rufen Sie Transaktion SQVI auf, und nutzen Sie wieder die Query ZSPO_AUTH (siehe

Abschnitt 3.6.1, »Benutzerspezifische Einstellungen«). Erweitern Sie die Listen- und

Selektionsfelder um das Feld Feldname einer Berechtigung, indem Sie die entspre-

chenden Haken setzen (siehe Abbildung 3.12).



Drucken 2 Wurden die Berechtigungen für die geschützten Druck-

aufträge entsprechend restriktiv vergeben?

Besonders für die geschützten Druckaufträge müssen die

Berechtigungen sehr restriktiv vergeben werden.



33


Abbildung 3.12 Listen- und Selektionsfelder der Query ZSPO_AUTH erweitern

Setzen Sie beim Ausführen die Selektionskriterien, wie in Abbildung 3.13 gezeigt. Im

Feld Datum der Gültigkeit geben Sie das aktuelle Datum an.

Abbildung 3.13 Benutzer mit Spool-Berechtigungsgruppen anzeigen

Ihnen werden alle Benutzer mit den ihnen zugeordneten Berechtigungen für Spool-

Berechtigungsgruppen angezeigt.

34


3.6.3 Zugriff auf Inhalte von Druckaufträgen




ten und dort im Bereich Berechtigungsobjekt 1 das Berechtigungsobjekt »S_SPO_

ACT« ein (siehe Abbildung 3.14).

Abbildung 3.14 Benutzer mit Berechtigungen für Druckauftragsinhalte abfragen

3.6.4 Änderung von Berechtigungswerten für Druckaufträge



Drucken 3 Wer besitzt die Berechtigung, Inhalte von Druckaufträgen

anzusehen?

Besonders für sensible Daten darf die Berechtigung zum

Lesen des Druckauftrags nur dem Benutzer zugeordnet

werden, der diese Daten druckt.





Drucken 2 Wer darf die Berechtigungswerte für die Druckaufträge

ändern?

Das Ändern der Berechtigungswerte sollte nur dem Besit-

zer des Druckauftrags möglich sein.



35





ten und dort im Bereich Berechtigungsobjekt 1 das Berechtigungsobjekt »S_SPO_

ACT« ein (siehe Abbildung 3.15).

Abbildung 3.15 Berechtigung zum Ändern der Berechtigungsgruppe für Druckaufträge

3.6.5 Löschen von Druckaufträgen

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle USR01 anzeigen. Das Feld

SPDA (Löschen nach Ausgabe) zeigt die Einstellungen für die Benutzer an:

� Wert »D«: Spool-Auftrag wird nach dem Drucken gelöscht.

� Wert »K«: Spool-Auftrag bleibt nach dem Drucken im Spool.



Drucken 2 Wird für Druckaufträge mit sensiblen Daten die Funktion

Löschen nach Ausgabe genutzt?

Druckaufträge mit sensiblen Daten sollten nach dem Aus-

druck aus dem Spool gelöscht werden.

Hier besteht das Risiko, dass Druckaufträge mit sensiblen

Daten im Spool-Auftrag verbleiben und dort eingesehen

werden können.

36


3.6.6 Exportberechtigungen




ten und dort im Bereich Berechtigungsobjekt 1 das Berechtigungsobjekt »S_GUI« ein

(siehe Abbildung 3.16).

Abbildung 3.16 Benutzer mit Datenexportberechtigungen abfragen

Überprüfen Sie diese Frage in Zusammenarbeit mit der Administration.



Exportieren von

Daten

3 Welche Benutzer dürfen Daten in Dateien exportieren?

Es muss festgelegt sein, welche Benutzer Daten speichern

dürfen.

Hier besteht das Risiko, dass Benutzer sensible Daten aus

dem System herunterladen.



Exportieren von

Daten

2 Liegen organisatorische Anweisungen vor, wie mit expor-

tierten Daten zu verfahren ist?

Ein Zugriff auf exportierte Daten muss genauso restriktiv

gehandhabt werden wie der Zugriff im SAP-System

selbst.

Hier besteht das Risiko, dass die sensiblen Daten im Netz-

werk frei zugänglich abgelegt werden.

37


3.7 Batch Input

3.7.1 Vollständigkeit der Datenübertragung

Klären Sie diese Frage in Zusammenarbeit mit dem Administrator des Vorsystems.

3.7.2 Zugriffsrechte auf Servern

Lassen Sie sich von einem Administrator die entsprechenden Verzeichnisse und die

berechtigten Benutzer zeigen.



Batch Input 2 Ist gesichert, dass die Daten aus den Vorsystemen voll-

ständig übertragen werden?

Im Vorsystem muss sichergestellt werden, dass die Map-

pen vollständig übertragen werden.

Hier besteht das Risiko, dass die Daten durch eine unvoll-

ständige Datenübertragung im SAP-System nur lücken-

haft importiert werden können.



Batch Input 2 Wer hat Zugriff auf die Dateien auf den Servern?

Es dürfen nur autorisierte Personen Zugriff auf die Origi-

naldateien haben.

Hier besteht das Risiko, dass Benutzer durch falsche

Zugriffsrechte die Inhalte der Batch-Input-Dateien mani-

pulieren können.

38

3.7 Batch Input

3.7.3 Doppeltes Einlesen von Batch-Input-Mappen

Lassen Sie sich das Verfahren von einem Administrator erläutern.

3.7.4 Zugriffsrechte für Batch-Input-Mappen




ten und dort im Bereich Berechtigungsobjekt 1 das Berechtigungsobjekt »S_BDC_

MONI« nacheinander mit den in Abbildung 3.17 gezeigten Werten ein (1 +2).



Batch Input 1 Wurden Vorkehrungen getroffen, um ein doppeltes Einle-

sen derselben Mappe zu verhindern?

Ein doppeltes Einlesen muss organisatorisch verhindert

werden.

Hier besteht das Risiko, dass Mappen doppelt eingelesen

werden können und dadurch redundante Buchungen ins

System gelangen können.



Batch Input 2 Wer ist berechtigt, Batch-Input-Mappen auszuführen

oder zu analysieren?

Nur die berechtigten Personen dürfen diese Rechte im

SAP-System erhalten.

Hier besteht das Risiko der falschen Autorisierung für

Batch-Input-Mappen, mit der eventuell sensible Daten

eingesehen werden können.

39


Abbildung 3.17 Berechtigungen für Batch-Input-Mappen abfragen

3.7.5 Fehlerhafte Batch-Input-Mappen

Klären Sie diese Frage in Zusammenarbeit mit der Administration. Lassen Sie sich

mit Transaktion SM35 fehlerhafte Mappen anzeigen und überprüfen Sie, wann diese

abgespielt wurden.



Batch Input 1 Wird nach den Batch-Läufen auf fehlerhafte Mappen kon-

trolliert?

Nach jedem Batch-Lauf muss kontrolliert werden, ob Feh-

ler aufgetreten sind, mindestens aber einmal pro Tag.

Hier besteht das Risiko, dass fehlerhafte Mappen nicht

zeitnah nachgearbeitet werden.

40

3.7 Batch Input

3.7.6 Hintergrundbenutzer

Mit Tabelle AGR_1251 können Sie prüfen, welche Benutzer zur Nutzung von BI-Map-

pen in die Rollen eingetragen wurden. Rufen Sie Transaktion SE16 auf, und lassen Sie

sich Tabelle AGR_1251 mit den in Abbildung 3.18 gezeigten Selektionskriterien anzei-

gen.

Abbildung 3.18 Hintergrundbenutzer für Batch-Läufe anzeigen



Batch Input 2 Welche Hintergrundbenutzer werden eventuell für die

Ausführung der Batch-Input-Mappen genutzt?

Falls Hintergrundbenutzer bei Batch-Input-Mappen ein-

gesetzt werden, müssen die Berechtigungen auf die

jeweilige Fachabteilung eingegrenzt werden. Die Berech-

tigung muss jeweils auf die Nutzung der abteilungseige-

nen Hintergrundbenutzer eingegrenzt werden.

Hier besteht das Risiko, dass diese Benutzer über die

Batch-Input-Mappen aufgrund ihrer Berechtigungen

unautorisierte Aktionen außerhalb der jeweiligen Fach-

abteilungen durchführen könnten.

41


3.8 Funktionen von SAP Business Warehouse

3.8.1 Pflege von DataSources




ten die Werte aus der folgenden Tabelle ein.



SAP Business

Warehouse

2 Wer besitzt Berechtigungen zum Pflegen der DataSour-

ces?

Die Berechtigungen zum Pflegen der DataSources dürfen

nur den verantwortlichen Administratoren zugeordnet

werden. Ist kein SAP-BW-System angeschlossen, darf

diese Berechtigung nicht vergeben werden.

Hier besteht das Risiko, dass Inkonsistenzen zum SAP-

BW-System entstehen können.



RSA2

RSA2OLD

RSA6

RSA8

S_RO_OSOA ACTVT(Aktivität)

23 (Pflegen)

OSOAPART(Teilobjekt zur DataSource)

DEFINITION

(Metadaten)

42

3.8 Funktionen von SAP Business Warehouse

3.8.2 Nutzung des Extraktorcheckers





3.8.3 Umgang mit sensiblen Daten



SAP Business

Warehouse

1 Wer besitzt die Berechtigung zur Nutzung des Extraktor-

checkers?

Die Berechtigung zur Nutzung des Extraktorcheckers darf

ausschließlich an die Personen vergeben werden, die die

Schnittstelle zum SAP-BW-System betreuen. Ist kein SAP-

BW-System-System angeschlossen, darf diese Berechti-

gung nicht vergeben werden.

Hier besteht das Risiko, dass sensible Daten ohne expli-

zite Berechtigungsprüfung angezeigt werden können.



RSA2

RSA3

RSA6

RSA8



SAP Business

Warehouse

2 Sind sensible Daten von der Übertragung ins SAP-BW-Sys-

tem ausgeschlossen?

Sensible Daten, die nicht ins SAP-BW-System übertragen

werden sollen, müssen technisch vom Extrakt ausge-

schlossen sein.

Es können sensible Daten ins SAP-BW-System übertragen

werden, für die dort kein expliziter Zugriffsschutz exis-

tiert.

43


Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle ROAUTH anzeigen. Prüfen

Sie, ob die DataSources eingetragen sind, deren Daten nicht übertragen werden dür-

fen. Achten Sie auf das Feld Extraktion ausschließen. Hier muss ein »X« eingetragen

sein.

44


zu Kapitel 4

4.1 Security Audit Log

4.1.1 Richtlinien

Prüfen Sie, ob Vorgaben existieren und ob diese den Anforderungen des Unterneh-

mens entsprechen.

4.1.2 Aktivierung

Rufen Sie Transaktion RSAU_CONFIG_SHOW auf, und prüfen Sie, ob die Einstellun-

gen den Vorgaben entsprechen. In älteren Releaseständen nutzen Sie Transaktion

SM19.



Security Audit Log 2 Existieren Vorgaben zum Einrichten des Security Audit

Logs?

Wird das Auditing verwendet, müssen Vorgaben zur Kon-

figuration erstellt werden.

Hier besteht das Risiko, dass das Security Audit Log nicht

nach Unternehmensanforderungen konfiguriert wird.



Security Audit Log 2 Wurde das Security Audit Log entsprechend den Vorga-

ben aktiviert?

Das Auditing muss gemäß den Vorgaben konfiguriert

und aktiviert sein.

Hier besteht das Risiko, dass die geforderten Aktivitäten

nicht protokolliert werden.

45


4.1.3 Auswertung

Lassen Sie sich die Vorgaben und Verantwortlichkeiten aufzeigen. Prüfen Sie die Doku-

mentationen zu den Auswertungen.

4.1.4 Aufbewahrung

Prüfen Sie das Archivierungskonzept zum Security Audit Log.

4.1.5 Integritätsschutz



Security Audit Log 2 Wird das Audit-Protokoll regelmäßig ausgewertet?

Das Protokoll muss regelmäßig ausgewertet werden.

Hier besteht das Risiko, dass kritische Einträge im Secu-

rity Audit Log nicht zeitnah erkannt werden.



Security Audit Log 3 Für welchen Zeitraum werden die Audit-Log-Dateien auf-

bewahrt?

Der Aufbewahrungszeitraum muss festgelegt sein.

Hier besteht das Risiko, dass die Audit-Log-Dateien vor

Ablauf des vereinbarten Aufbewahrungszeitraums

gelöscht werden.



Security Audit Log 2 Ist der Integritätsschutz für die Dateien des Security

Audit Logs aktiviert?

Bei der Nutzung des Security Audit Logs muss der Integri-

tätsschutz aktiviert werden.

Hier besteht das Risiko, dass Dateien auf der Betriebssys-

temebene manipuliert werden.

46

4.1 Security Audit Log

Rufen Sie Transaktion RSAU_CONFIG_SHOW auf. Das Feld Integritätsschutzformat

zeigt Ihnen die betreffende Information an (siehe Abbildung 4.1).

Abbildung 4.1 Aktivierung des Integritätsschutzes prüfen

4.1.6 Konfigurationsrechte




ten nacheinander die Werte aus den folgenden Tabellen ein.



Security Audit Log 2 Wurden die Berechtigungen zum Konfigurieren des SAL

nur eingeschränkt vergeben?

Die Berechtigungen dürfen nur an SAP-Basisadministra-

toren oder Notfallbenutzer vergeben werden.

Hier besteht das Risiko, dass durch die Änderung der Kon-

figuration nicht die vom Unternehmen geforderten Akti-

vitäten protokolliert werden.

47


Berechtigung zur Pflege der allgemeinen SAL-Parameter

Berechtigung zur Pflege der dynamischen Konfiguration

Berechtigung zur Pflege der statischen Konfiguration


S_TCODE TCD (Transaktion) RSAU_CONFIG

S_SAL SAL_ACTVT (SAL – Aktivitäten) EDIT_PARAM

oder

S_ADMI_FCD S_ADMI_FCD (Systemadminis-

trationsfunktion)

AUDA



S_SAL SAL_ACTVT (SAL – Aktivitäten) EDIT_CONFD

oder


trationsfunktion)

AUDA



S_SAL SAL_ACTVT (SAL – Aktivitäten) EDIT_CONFS

oder


trationsfunktion)

AUDA

48

4.2 Systemprotokollierung

4.1.7 Löschen von Protokolleinträgen





4.2 Systemprotokollierung

4.2.1 Sicherheitsrelevante Einträge



Security Audit Log 1 Wurden die Berechtigungen zum Löschen der Protokoll-

einträge nur eingeschränkt vergeben?

Die Berechtigungen dürfen nur an SAP-Basisadministra-

toren oder Notfallbenutzer vergeben werden.

Hier besteht das Risiko, dass durch das Löschen der Proto-

kolle die vom Unternehmen geforderten Aktivitäten nicht

mehr ausgewertet werden können.


S_TCODE TCD (Transaktion) RSAU_ADMIN

S_SAL SAL_ACTVT (SAL – Aktivitäten) DELE_LOG_F

oder


trationsfunktion)

AUDA



SysLog 2 Sind sicherheitsrelevante Einträge im SysLog vorhanden?

Sicherheitsrelevante Einträge (zu definieren in einer

Sicherheitsstrategie) sind zu hinterfragen.

Hier besteht das Risiko, dass sicherheitsrelevanten Einträ-

gen nicht zeitnah nachgegangen wurde.

49


Rufen Sie Transaktion SM21 auf. Lassen Sie das Feld Erweiterter Instanzname leer, um

die Meldungen aller Instanzen anzuzeigen. Geben Sie im Feld Meldungs-ID über die

Mehrfachselektion die Meldungsnummer ein, wie in Abschnitt 4.2.1, »Sicherheitsre-

levante Einträge«, des Buches beschrieben (siehe Abbildung 4.2). Lassen Sie sich die

Auswertung anzeigen.

Abbildung 4.2 Meldungen im Systemprotokoll anzeigen

4.2.2 Auswertung

Richten Sie diese Fragestellung an die Administration.



SysLog 2 Wird das SysLog regelmäßig auf Sicherheitsmeldungen

hin ausgewertet?

Das SysLog muss täglich auf Sicherheitsmeldungen hin

ausgewertet werden.

Hier besteht das Risiko, dass sicherheitsrelevante Ein-

träge nicht zeitnah erkannt werden.

50

4.3 Protokollierung von Tabellenänderungen


4.3.1 Aktivierung

Rufen Sie Transaktion RSPFPAR auf, und geben Sie als Selektionskriterium den Para-

meter rec/client ein. Als Parameterwert müssen entweder alle Produktivmandan-

ten aufgeführt sein oder der Wert »ALL« (siehe Abbildung 4.3).

Abbildung 4.3 Systemparameter rec/client anzeigen

4.3.2 Protokollierung bei Importen



Tabellenprotokol-

lierung

1 Wurde die Tabellenprotokollierung für das Produktivsys-

tem aktiviert (Systemparameter rec/client)?

Die Protokollierung muss für den Produktivmandanten

aktiviert werden.

Hier besteht das Risiko, dass Änderungen an rechnungs-

legungsrelevanten Tabellen nicht protokolliert werden

und somit gegen § 257 HGB verstoßen wird.



Tabellenprotokol-

lierung

1 Wurde für das Produktivsystem die Protokollierung für

Importe von Tabelleninhalten aktiviert?

Die Protokollierung für Importe von Tabelleninhalten

muss aktiviert werden.

Hier besteht das Risiko, dass Tabellenänderungen über

Transporte eingespielt werden, die nicht über Protokolle

nachzuvollziehen sind.

51


Prüfen Sie, ob der Transportparameter RECCLIENT analog zum Systemparameter rec/

client eingestellt ist. Je nach Berechtigung haben Sie dafür zwei Möglichkeiten:

1. Report RSTMSTPP:

– Rufen Sie Transaktion SA38 auf, und lassen Sie sich den Report RSTMSTPP anzei-

gen.

– Geben Sie in die Selektionsmaske des Reports die dreistellige System-ID des zu

prüfenden Systems ein. Diese erhalten Sie, indem Sie in der Statusleiste Ihres

SAP GUI den Eintrag System auswählen (je nach Releasestand unten rechts oder

oben rechts).

– Suchen Sie in der Ergebnisliste des Reports den Parameter RECCLIENT. Als Para-

meterwert müssen entweder alle Produktivmandanten aufgeführt sein oder

der Wert »ALL«.

2. Transaktion STMS:

– Rufen Sie Transaktion STMS auf und anschließend den Menüpfad Übersicht •

Systeme.

– Klicken Sie hier doppelt auf das zu prüfende System und wählen die Register-

karte Transporttool aus.

– Ist in der Liste der Parameter RECCLIENT nicht aufgeführt, ist er nicht gesetzt

(gleichbedeutend dem Wert »OFF«). Ist er in der Liste enthalten, muss er als

Parameterwert entweder alle Produktivmandanten oder den Wert »ALL« ent-

halten.

4.3.3 Qualitätssicherungssystem


meter rec/client ein. Der Parameterwert muss den unternehmensspezifischen

Anforderungen entsprechen.



Tabellenprotokol-

lierung

3 Wurde die Tabellenprotokollierung für das Qualitäts-

sicherungssystem aktiviert (Systemparameter rec/client)?

Die Protokollierung für das Qualitätssicherungssystem

sollte aktiviert werden.

Hier besteht das Risiko, dass das Freigabeverfahren durch

nicht nachvollziehbare Tabellenänderungen beeinflusst

wird.

52


4.3.4 Ausgangsmandant

Rufen Sie im Entwicklungssystem Transaktion SE16 auf, und lassen Sie sich Tabelle

T000 anzeigen. Mandanten, von denen aus Transporte möglich sind, enthalten im

Feld CCCORACTIV (Transportanschluss/Corrsys) den Wert »1« oder keinen Wert (leer).

4.3.5 Entwicklungssystem


meter rec/client ein. Der Parameterwert muss alle Mandanten enthalten, von denen

aus Transporte möglich sind (siehe Abschnitt 4.3.4, »Ausgangsmandant«).



Tabellenprotokol-

lierung

1 Von welchen Mandanten im Entwicklungssystem sind

Transporte möglich?

Transporte dürfen nur von den Customizing- und Ent-

wicklungsmandanten aus möglich sein.

Hier besteht das Risiko, dass auch von Testmandanten

oder »Spielmandanten« aus Transporte angestoßen wer-

den können und diese Daten bis ins Produktivsystem

durchtransportiert werden.



Tabellenprotokol-

lierung

1 Wurde die Tabellenprotokollierung für das Entwicklungs-

system aktiviert (Systemparameter rec/client)?

Die Protokollierung muss für das Entwicklungssystem für

alle Mandanten aktiviert werden, von denen aus Trans-

porte möglich sind, sowie für den Mandanten 000.

Hier besteht das Risiko, dass Customizing-Einstellungen

nicht aufgezeichnet werden, dadurch nicht nachvollzieh-

bar sind und durch die fehlende Protokollierung gegen

§ 257 HGB verstoßen wird.

53


4.3.6 Rechnungslegungsrelevante Tabellen

Rufen Sie Transaktion RDDPRCHK_AUDIT auf. Geben Sie in das Feld Tabellenname

über die Mehrfachselektion die Tabellen gemäß SAP-Hinweis 112388 ein (siehe

Abschnitt 4.3.3, »Qualitätssicherungssystem«, im Buch). Lassen Sie ansonsten die

Standardselektionskriterien stehen. Es werden alle Tabellen gemäß dem SAP-Hin-

weis angezeigt, die nicht protokolliert werden.

Rufen Sie Transaktion RDDPRCHK_AUDIT auf. Geben Sie in das Feld Tabellenname

über die Mehrfachselektion die Namenskonventionen für unternehmenseigene

Tabellen ein (siehe Abbildung 4.4 und Abschnitt 4.3.5, »Entwicklungssystem«, im

Buch). Es werden alle nicht protokollierten, unternehmenseigenen Tabellen ange-

zeigt. Wie Sie bewerten können, welche Tabellen protokolliert werden müssen, ist

ebenfalls in Abschnitt 4.3.5 des Buches beschrieben.



Tabellenprotokol-

lierung

1 Werden rechnungslegungsrelevante SAP-Standardtabel-

len protokolliert (SAP-Hinweis 112388)?

Alle rechnungslegungsrelevanten Tabellen müssen pro-

tokolliert werden.

Hier besteht das Risiko, dass nicht alle rechnungslegungs-

relevanten Einträge protokolliert werden und dadurch

gegen § 257 HGB verstoßen wird.



Tabellenprotokol-

lierung

1 Werden selbst erstellte Tabellen, die rechnungslegungs-

relevant sind, protokolliert?

Selbst erstellte Tabellen müssen auf ihre Rechnungsle-

gungsrelevanz hin untersucht und entsprechend proto-

kolliert werden.




54


Abbildung 4.4 Tabellenprotokollierung prüfen








Tabellenprotokol-

lierung

1 Wer besitzt das Zugriffsrecht zum Löschen der Tabellen-

änderungsprotokolle im Produktivsystem?

Dieses Zugriffsrecht darf nur nach dem Vier-Augen-Prin-

zip eingesetzt werden.

Hier besteht das Risiko, dass Protokolle, die der Aufbe-

wahrungspflicht unterliegen, unwiderruflich und nicht

nachvollziehbar gelöscht werden.

55


4.3.8 Tabellenprotokollierung ändern







SCU3


X


02 (Ändern)


SA oder &NC&

(Berechtigungsgruppe ist über

Tabelle TDDAT zu ermitteln)

oder


SCC4


X


02 (Ändern)

TABLE(Tabelle)

DBTABLOG



Tabellenprotokol-

lierung

1 Wer besitzt das Zugriffsrecht zum Ändern der Protokollie-

rungsoption für Tabellen im Produktivsystem?

Dieses Zugriffsrecht darf nur nach dem Vier-Augen-Prin-

zip eingesetzt werden.




56

4.4 Protokollierung über Änderungsbelege

4.4 Protokollierung über Änderungsbelege

4.4.1 Löschen von Änderungsbelegen




ten die Werte aus der folgenden Tabelle ein:



SE13


02 (Ändern)

OBJTYPE(Objekttyp)

TABT

OBJNAME(Objektname)

Name einer Tabelle



Änderungsbelege 1 Besitzt im Produktivmandanten jemand das Recht, Ände-

rungsbelege zu löschen?

Dies ist ein gesetzeskritisches Zugriffsrecht und darf im

Produktivmandanten nicht vergeben werden.

Hier besteht das Risiko, dass durch das Löschen von Ände-

rungsbelegen gegen § 257 HGB verstoßen wird.


S_SCD0 oder

S_SCD0_OBJACTVT(Aktivität)

06 (Löschen)

57


4.4.2 Standardänderungsbelegobjekte

Rufen Sie Transaktion RSSCD100 auf, und geben Sie im Feld Objektklasse den Wert

»AENDBELEG« ein. Schränken Sie eventuell die Felder ab Datum und bis Datum auf

einen Prüfungszeitraum ein. Ihnen werden alle Änderungen an Änderungsbelegob-

jekten angezeigt. Wurden keine Änderungen vorgenommen, erhalten Sie die Mel-

dung »Es wurden keine Änderungsbelegpositionen gefunden«.

4.5 Versionsverwaltung

4.5.1 Versionshistorie bei Importen erzeugen

Prüfen Sie, welchen Wert der Transportparameter VERS_AT_IMP enthält:

� ALWAYS: Es werden Versionen beim Import erzeugt.

� NEVER: Es werden keine Versionen beim Import erzeugt.

Je nach Berechtigung haben Sie dafür zwei Möglichkeiten:



Änderungsbelege 1 Wurden Standardänderungsbelegobjekte geändert?

Standardänderungsbelegobjekte dürfen nicht manipu-

liert werden.

Hier besteht das Risiko, dass aufbewahrungspflichtige

Änderungen nicht mehr protokolliert werden.



Versionshistorie 2 Wird durch den Import neuer Programmversionen eine

Versionshistorie im Produktivsystem erzeugt?

Alle Versionen von eigenen Programmen sind aufbewah-

rungspflichtig (gemäß HGB zehn Jahre). Sie können aber

auch im Entwicklungssystem archiviert werden.


Programmversionen nicht archiviert werden.

58

4.5 Versionsverwaltung

1. Report RSTMSTPP:

– Rufen Sie Transaktion SA38 auf, und lassen Sie sich den Report RSTMSTPP anzei-

gen.

– Geben Sie in die Selektionsmaske des Reports die dreistellige System-ID des zu

prüfenden Systems ein. Diese erhalten Sie, indem Sie in der Statusleiste Ihres

SAP GUI den Eintrag System auswählen (je nach Releasestand unten rechts oder

oben rechts).

– Suchen Sie in der Ergebnisliste des Reports den Parameter VERS_AT_IMP.

2. Transaktion STMS:

– Rufen Sie Transaktion STMS auf und anschließend den Menüpfad Übersicht •

Systeme.

– Klicken Sie hier doppelt auf das zu prüfende System, und wählen Sie die Regis-

terkarte Transporttool aus.

– Ist in der Liste der Parameter VERS_AT_IMP nicht aufgeführt, ist er nicht gesetzt

(gleichbedeutend dem Wert »NEVER«).

4.5.2 Löschen der Versionshistorie







Versionshistorie 1 Können die Reports zum Löschen von Versionen genutzt

werden?

Das Löschen der Versionshistorie ist nicht zulässig.

Hier besteht das Risiko, dass Versionen gelöscht werden

und dass damit zum einen gegen geltende Gesetze ver-

stoßen wird und zum anderen keine Nachvollziehbarkeit

über die Programmänderungen gegeben ist.


S_CTS_ADMI oder

S_CTS_SADMCTS_ADMFCT(Administrationsaufgaben im

Change and Transport System)

TABL

59


Der häufigste Schutz vor dem Löschen ist die Zuordnung der Reports (RSVCAD00,

RSVCAD03, RSVCAD04) zu einer Berechtigungsgruppe. Um zu prüfen, ob die Reports

einer Gruppe zugeordnet sind, rufen Sie Transaktion SE16 auf und lassen sich Tabelle

TRDIR anzeigen. Schränken Sie in der Selektionsmaske im Feld Programmname auf

die drei Reportnamen ein. Im Feld SECU (Berechtigungsgruppe) finden Sie die Berech-

tigungsgruppe. Ist eine Gruppe hinterlegt, prüfen Sie, wer darauf Zugriff hat. Rufen

Sie Transaktion SUIM auf, und wählen Sie den Menüpfad Benutzer • Benutzer nach

komplexen Selektionskriterien • Benutzer nach komplexen Selektionskriterien. Tra-

gen Sie dort auf der Registerkarte Berechtigungen im Bereich Selektion nach Werten

die Werte aus der folgenden Tabelle ein.

4.6 Lesezugriffsprotokollierung

4.6.1 Richtlinien

Prüfen Sie das vorhandene Konzept. Eruieren Sie dabei vor allem, ob die zu protokol-

lierenden Dynpros/Funktionsbausteine vollständig die Anforderungen abbilden.


S_PROGRAM P_GROUP

(Berechtigungsgruppe ABAP-

Programm)

<Gruppe gemäß Tabelle TRDIR>

P_ACTION(Benutzeraktion ABAP- Pro-

gramm)

SUBMIT

BTCSUBMIT



Lesezugriffsproto-

kollierung

1 Existieren Vorgaben für den Einsatz der Lesezugriffspro-

tokollierung?

Der Einsatz der Lesezugriffsprotokollierung muss aus-

führlich geplant und dokumentiert werden.

Hier besteht das Risiko, dass bei unzureichender Konzep-

tion nicht alle zu protokollierenden Daten erfasst werden

und dadurch die Protokollierung unvollständig ist.

60


4.6.2 Konfiguration

Rufen Sie Transaktion SRALMANAGER auf, und klicken Sie auf den Menüpunkt Kon-

figuration. Wählen Sie dort im Feld Kanal hintereinander die Kanäle aus, für die Kon-

figurationen gemäß Konzept hinterlegt sein sollen. Klicken Sie anschließend auf die

Schaltfläche Suchen. Ihnen werden unter Suchergebnis die einzelnen Protokollierun-

gen angezeigt. Die Spalte Status zeigt Ihnen, ob ein Eintrag aktiv oder inaktiv ist


Abbildung 4.5 Konfiguration der Lesezugriffsprotokollierung prüfen



Lesezugriffsproto-

kollierung

1 Wurden die Vorgaben korrekt im System umgesetzt?

Die Konfiguration der Lesezugriffsprotokollierung muss

den Vorgaben entsprechen.

Hier besteht das Risiko, dass aufgrund der Komplexität

die technische Umsetzung nicht analog dem Konzept

erfolgt ist.

61


Über die Schaltfläche Konfiguration anzeigen ( ) können Sie sich die Details zu

jedem Eintrag anzeigen lassen (siehe Abbildung 4.6).

Abbildung 4.6 Details anzeigen








Lesezugriffsproto-

kollierung

1 Wurden die Berechtigungen zum Konfigurieren der Lese-

zugriffsprotokollierung korrekt vergeben?

Die Berechtigungen müssen auf einen eingeschränkten

Personenkreis eingegrenzt sein.

Hier besteht das Risiko, dass aufgrund von zu umfang-

reich vergebenen Berechtigungen Manipulationen an der

Konfiguration vorgenommen werden können.

62


4.6.4 Zugriffsrechte







SRALMANAGER

S_RAL_CFG ACTVT(Aktivität)

01 (Anlegen)

02 (Ändern)

06 (Löschen)

RAL_PURPOS(ID der Zweckbestimmung)

gemäß Tabelle SRAL_PURPOSES

SWC(Softwarekomponente)

z. B.:

SAP_BASIS

SAP_ABA

SAP_APPL



Lesezugriffsproto-

kollierung

2 Wurden die Berechtigungen zum Auswerten der Lesezu-

griffsprotokollierung korrekt vergeben?

Die Berechtigungen zur Protokollauswertung müssen auf

einen eingeschränkten Personenkreis eingegrenzt sein.

Hier besteht das Risiko, dass die Protokolle aufgrund von

zu umfangreich vergebenen Berechtigungen unbefugt

eingesehen werden können.

63


4.7 Zugriffsstatistik

4.7.1 Abstimmung mit Arbeitnehmervertretung

Prüfen Sie, ob die Nutzung der Zugriffsstatistik in die Betriebsvereinbarung aufge-

nommen wurde.



SRALMANAGER/

SRALMONITOR

S_RAL_LOG ACTVT(Aktivität)

03 (Anzeigen)

RAL_PURPOS(ID der Zweckbestimmung)

gemäß Tabelle SRAL_PURPOSES

SWC(Softwarekomponente)

z. B.:

SAP_BASIS

SAP_ABA

SAP_APPL

RAL_LENT_T(Typ juristische Person)

MANDT

(Mandantennummer)

RAL_LENT_T(Wert juristische Person)



Zugriffsstatistik 2 Ist die Nutzung der Zugriffsstatistik mit der Arbeitneh-

mervertretung abgestimmt?

Die Auswertung von Benutzeraktionen mittels der

Zugriffsstatistik muss mit der Arbeitnehmervertretung

abgestimmt und in die Betriebsvereinbarung zum Betrieb

des SAP-Systems aufgenommen werden.

Hier besteht das Risiko, dass gegen das Verbot der Leis-

tungs- und Verhaltenskontrolle verstoßen wird.

64

4.7 Zugriffsstatistik

4.7.2 Anzeige von Benutzernamen





4.7.3 Aufbewahrung

Rufen Sie Transaktion ST03N auf. Wählen Sie in der Baumstruktur auf der linken

Seite den Menüpfad Kollektor & Perf. Datenbank • Performance-Datenbank • Moni-

toring Datenbank • Reorganization. Gleichen Sie die Werte mit den Vorgaben ab




Zugriffsstatistik 1 Wurde die Berechtigung zum Auswerten der Zugriffssta-

tistik mit Klarnamen vergeben?

Die Berechtigung darf nur dem in der Betriebsvereinba-

rung bestimmten Personenkreis zugeordnet werden.

Hier besteht das Risiko, dass Nutzerdaten unberechtigt

ausgewertet werden.


S_TOOLS_EX AUTH(Berechtigungsname)

S_TOOLS_EX_A



Zugriffsstatistik 2 Wie lange werden die Daten der Zugriffsstatistik aufbe-

wahrt?

Der Aufbewahrungszeitraum muss dem in der Betriebs-

vereinbarung bestimmten Zeitraum entsprechen.

Hier besteht das Risiko, dass Nutzerdaten zu lange aufbe-

wahrt und für unberechtigte Analysen genutzt werden

können.

65


Abbildung 4.7 Aufbewahrungszeiten der Zugriffsstatistik prüfen

4.8 Weitere Protokollkomponenten

Der Abschnitt 4.8, »Weitere Protokollkomponenten«, des Buches enthält keine

Checklisten.

4.9 Systemüberwachung mit SAP Enterprise Threat Detection

4.9.1 Richtlinien



SAP Enterprise

Threat Detection

2 Existiert ein Konzept zur Nutzung von SAP Enterprise

Threat Detection, in dem die technischen Auswertungen

und deren Kontrolle definiert sind?

Es muss ein Konzept zur Nutzung von SAP Enterprise

Threat Detection vorliegen.

Hier besteht das Risiko, dass nicht alle Risiken durch Aus-

wertungen mit SAP Enterprise Threat Detection abge-

deckt sind bzw. nicht zeitnah aufgedeckt werden.

66


Prüfen Sie, ob ein Konzept existiert und ob es den Anforderungen des Unterneh-

mens entspricht.

4.9.2 Übertragene Protokolle

Führen Sie die folgende Prüfung in allen Systemen durch, die Protokolle an SAP

Enterprise Threat Detection übertragen sollen.

Rufen Sie Transaktion SM30 auf, und lassen sich Tabelle SECM_LOGS anzeigen. Prüfen

Sie, ob alle vereinbarten Protokolle aktiviert sind (Eintrag wahr in Spalte Prot.aktiv,

siehe Abbildung 4.8).

Abbildung 4.8 Übertragung der Protokolle prüfen



SAP Enterprise

Threat Detection

1 Werden alle Protokolle, die für die vereinbarten Auswer-

tungen erforderlich sind, an SAP Enterprise Threat Detec-

tion übertragen?

Es müssen alle Protokolle übertragen werden, die für die

Auswertungen erforderlich sind.

Hier besteht das Risiko, dass kritische Vorgänge durch

SAP Enterprise Threat Detection nicht erkannt werden, da

die Protokolle nicht übertragen werden.

67







Rufen Sie im SAP HANA Studio die SQL-Konsole auf. Klicken Sie dazu mit der rechten

Maustaste auf den Namen des Systems, und wählen Sie den Eintrag Open SQL Con-

sole im Kontextmenü. Geben Sie die folgende SQL-Anweisung ein:



SAP Enterprise

Threat Detection

1 Wurden die Berechtigungen zum Konfigurieren der Pro-

tokollübertragung korrekt vergeben?

Nur die zuständigen Administratoren dürfen diese

Berechtigungen erhalten.

Hier besteht das Risiko, dass bewusst oder versehentlich

die Konfiguration geändert wird und dadurch erforderli-

che Protokolle nicht an SAP Enterprise Threat Detection

übertragen werden.


S_SEC_MON ACTVT(Aktivität)

70 (Administrieren)

SECM_LOG(SECM: Protokolltyp)

*



SAP Enterprise

Threat Detection

1 Ist die Konfiguration von SAP Enterprise Threat Detection

nur den dafür zuständigen Personen möglich?

Im Konzept zum Einsatz von SAP Enterprise Threat Detec-

tion muss festgelegt sein, welche Personenkreise SAP

Enterprise Threat Detection konfigurieren dürfen.

Hier besteht das Risiko, dass unberechtigte Personen auf

sensible personenbezogene Auswertungen zugreifen.

68


SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE = 'sap.secmon::Admin'AND OBJECT_TYPE = 'APPLICATIONPRIVILEGE'

4.9.4 Protokollübertragung

Rufen Sie Transaktion SM37 auf, und geben Sie im Feld Benutzername den Namen

des Benutzers ein, unter dem der Job zur Protokollübertragung läuft (gemäß Doku-

mentation oder in Absprache mit der Administration). Führen Sie die Selektion aus.

Der Job zur Protokollübertragung an SAP Enterprise Threat Detection muss minüt-

lich angezeigt werden (siehe Abbildung 4.9).

Abbildung 4.9 Protokollübertragungsjob prüfen



SAP Enterprise

Threat Detection

1 Ist der Job zur Übertragung der Protokolle an SAP Enter-

prise Threat Detection korrekt eingerichtet und aktiv?

Der Job zur Übertragung der Protokolle muss minütlich

laufen.

Hier besteht das Risiko, dass kritische Vorgänge durch

SAP Enterprise Threat Detection nicht erkannt werden, da

die Protokolle nicht übertragen werden.

69


Zur Anzeige der Jobkonfiguration markieren Sie einen Job und klicken auf die Schalt-

fläche Job-Details. Dort wird u. a. die Wiederholungsperiode angezeigt (siehe Abbil-

dung 4.10).

Abbildung 4.10 Jobdetails anzeigen

Klicken Sie hier auf die Schaltfläche Jobdetails, um sich Details zur Einplanung des

Jobs anzeigen zu lassen (siehe Abbildung 4.11).

Abbildung 4.11 Details der Jobkonfiguration

70


71





SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE = 'sap.secmon::Executes'AND OBJECT_TYPE = 'APPLICATIONPRIVILEGE'

4.9.6 Depseudonymisierung von Benutzernamen




SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE = 'sap.secmon::ResolveUser'AND OBJECT_TYPE = 'APPLICATIONPRIVILEGE'



SAP Enterprise

Threat Detection

2 Ist der Zugriff auf die Auswertungen von SAP Enterprise

Threat Detection nur den zuständigen Personen möglich?

Im Konzept zum Einsatz von SAP Enterprise Threat Detection

muss festgelegt sein, welche Personenkreise auf die Ergeb-

nisse zugreifen dürfen. Hier besteht das Risiko, dass unbe-

rechtigte Personen auf sensible Auswertungen zugreifen.



SAP Enterprise

Threat Detection

1 Ist die Depseudonymisierung von Benutzernamen nur den

dafür zuständigen Personen möglich?

Im Konzept zum Einsatz von SAP Enterprise Threat Detection

muss festgelegt sein, welche Personenkreise Benutzernamen

depseudonymisieren dürfen. Hier besteht das Risiko, dass

bewusst oder versehentlich die Konfiguration geändert wird

und dadurch Ergebnisse falsch oder gar nicht ausgegeben

werden.


zu Kapitel 5

5.1 Funktionsbausteine


Rufen Sie Transaktion RSAU_CONFIG_SHOW auf (altes Security Audit Log: Trans-

aktion SM19). Überprüfen Sie, ob es einen Eintrag mit mindestens den folgenden

Werten gibt:

� Klassen:

– RFC-/CPI-C-Anmeldungen

– RFC-Funktionsaufruf

� Ereignisse:

– nur kritische Ereignisse



Funktionsbausteine 2 Werden Anmeldungen und Funktionsbausteinaufrufe

über RFC protokolliert?

RFC-Falschanmeldungen und fehlgeschlagene Funkti-

onsbausteinaufrufe sind zu protokollieren.

Hier besteht das Risiko, dass Funktionsbausteine ohne

Nachvollziehbarkeit von externen Programmen ausge-

führt werden können und dass Eindringversuche über

RFC unbemerkt bleiben.

73









Funktionsbausteine 1 Wer besitzt das Recht zum Ausführen aller Funktions-

bausteine?

Dieses Zugriffsrecht ist für keinen Benutzer erforderlich.

Hier besteht das Risiko, dass Benutzer über die Funkti-

onsbausteine kritische Aktionen im SAP-System durch-

führen können.



SE37 oder SE80 oder Report

RS_TESTFRAME_CALL


16 (Ausführen)

OBJTYPE(Objekttyp)

FUGR (Funktionsgruppe)

OBJNAME(Objektname)

*

DEVCLASS(Paket)

*

P_GROUP(Berechtigungsgruppe)

*

74

5.1 Funktionsbausteine







Funktionsbausteine 1 Wer besitzt das Recht, mit Transaktion SE37 Funktions-

bausteine auszuführen?

Dieses Zugriffsrecht sollte nur wenigen administrativen

Benutzern zugeordnet werden.

Hier besteht das Risiko, dass Benutzer über RFC-Verbin-

dungen mit hinterlegtem Benutzer und Kennwort

unberechtigten Zugriff auf andere SAP-Systeme erlan-

gen.



SE37 oder SE80 oder Report

RS_TESTFRAME_CALL


16 (Ausführen)

OBJTYPE(Objekttyp)

FUGR (Funktionsgruppe)

OBJNAME(Objektname)

Name der Funktionsgruppe

DEVCLASS(Paket)

Paket der Funktionsgruppe

75


5.2 RFC-Verbindungen

5.2.1 Vorhandene RFC-Verbindungen

Führen Sie die folgende Prüfung in allen Systemen der zu prüfenden Systemland-

schaften durch:

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle RFCDES anzeigen. Alterna-

tiv können Sie auch den Report/Transaktion RSRSDEST nutzen. Tragen Sie in die

Selektionsmaske des Reports keine Selektionskriterien ein. Es werden Ihnen dann

alle RFC-Verbindungen angezeigt.

5.2.2 Dokumentation

Lassen Sie sich die Dokumentationen zu den Schnittstellen aushändigen.



RFC-Verbindungen 1 Welche RFC-Verbindungen existieren in den verschiede-

nen Systemen der SAP-Systemlandschaft?

In allen Systemen der Systemlandschaft dürfen nur RFC-

Verbindungen existieren, die notwendig sind und

genutzt werden.

Hier besteht das Risiko, dass durch RFC-Verbindungen

Schnittstellen zu Systemen aufgebaut werden können,

die nicht mit dem SAP-System verbunden sein sollten.



RFC-Verbindungen 2 Sind die eingerichteten RFC-Verbindungen dokumen-

tiert (außerhalb des SAP-Systems)?

Jede RFC-Verbindung muss so dokumentiert sein, dass

ihr Verwendungszweck eindeutig nachvollziehbar ist.

Hier besteht das Risiko, dass RFC-Verbindungen auf-

grund einer fehlenden Dokumentation falsch genutzt

werden.

76


5.2.3 Hinterlegte Kennwörter

Führen Sie die folgende Prüfung in allen Systemen der zu prüfenden Systemland-

schaften durch:

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle RFCDES anzeigen. Alterna-

tiv können Sie auch den Report/Transaktion RSRSDEST nutzen. Tragen Sie in die

Selektionsmaske der Tabelle bzw. des Reports als Selektionskriterium in das Feld

RFCOPTIONS (Optionen) den Wert »*v=*« ein und im Feld RFCTYPE (Verbindungstyp) den

Wert »3« (für ABAP-Verbindungen, siehe Abbildung 5.1).

Abbildung 5.1 Verbindungen mit hinterlegten Kennwörtern heraussuchen

Es werden alle RFC-Verbindungen angezeigt, in denen Benutzerkennwörter hinter-

legt sind (siehe Abbildung 5.2). Die weiteren Einträge im Feld RFCOPTIONS bedeuten:



RFC-Verbindungen 1 Existieren RFC-Verbindungen, in denen für Dialog- oder

Servicebenutzer Kennwörter hinterlegt sind?

RFC-Verbindungen mit hinterlegten Kennwörtern für

Dialogbenutzer dürfen nicht existieren.

Hier besteht das Risiko, dass durch diese RFC-Verbin-

dungen eine Anmeldung ohne Benutzerkennung und

Kennwort möglich ist.

77


� H=: Server-/IP-Adresse

� S=: Instanznummer

� M=: Mandant

� U=: Benutzername

Abbildung 5.2 Anzeige der Verbindungen mit hinterlegten Kennwörtern

Anhand dieser Daten erkennen Sie die Zielsysteme. Melden Sie sich an diesen Man-

danten an, und prüfen Sie, ob der in der RFC-Verbindung hinterlegte Benutzer (Ein-

trag »U=«) vom Typ Dialog oder Service ist. Rufen Sie dafür im Zielsystem

Transaktion SU01 oder SU01D auf, oder nutzen Sie das Benutzerinformationssystem

(Menüpfad Benutzer • Benutzer nach komplexen Selektionskriterien • Benutzer nach

komplexen Selektionskriterien).

5.2.4 Pflegerechte



RFC-Verbindungen 2 Wer ist berechtigt, RFC-Verbindungen zu pflegen?

Dieses Zugriffsrecht dürfen nur Basisadministratoren

besitzen.

Hier besteht das Risiko, dass unberechtigte Benutzer

RFC-Verbindungen ändern, neue anlegen oder vorhan-

dene löschen.

78






5.2.5 Berechtigung zur Nutzung von RFC-Verbindungen







SM59

S_RFC_ADM ACTVT(Aktivität)

01 (Anlegen)

02 (Ändern)

06 (Löschen)

RFCTYPE(Verbindungstyp)

3 (Verbindung zu einem ABAP-

System)

RFCDEST(Name einer RFC-Verbindung)

<Name einer RFC-Verbindung>

ICF_VALUE(ICF-Wert)

<Berechtigungswert>



RFC-Verbindungen 2 Wer besitzt das Recht, alle RFC-Verbindungen zu nutzen?

Dieses Zugriffsrecht sollten nur Administratoren besit-

zen.

Hier besteht das Risiko, dass Benutzer zu viele RFC-Ver-

bindungen nutzen können und dadurch Zugriff auf

andere SAP-Systeme erhalten.

79


5.3 Trusted Systems

5.3.1 Vorhandene Vertrauensbeziehungen

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle RFCSYSACL anzeigen. Alter-

nativ können Sie auch Transaktion SMT1 nutzen. Tragen Sie in die Selektionsmaske

der Tabelle keine Selektionskriterien ein. Es werden Ihnen dann alle Systeme ange-

zeigt, zu denen Vertrauensbeziehungen eingerichtet wurden.

5.3.2 Berechtigungen für Trusted-Zugriffe


S_ICF ICF_FIELD(ICF-Typ)

DEST

ICF_VALUE(ICF-Wert)

*



Trusted Systems 1 Existieren in Systemen mit sensiblen Daten Vertrauens-

beziehungen zu anderen Systemen?

In allen Systemen dürfen nur Vertrauensbeziehungen

existieren, die notwendig sind und genutzt werden.

Hier besteht das Risiko, dass durch Vertrauensbezie-

hungen ein anonymer Zugriff auf sensible Daten

ermöglicht wird.



Trusted Systems 1 Wurden Berechtigungen vergeben, mit denen Benutzer

aus anderen Systemen heraus für Zugriffe über eine

Trusted-Verbindung genutzt werden können?

Berechtigungen für Trusted-Zugriffe dürfen nur sehr

restriktiv vergeben werden.

Hier besteht das Risiko, dass durch falsch vergebene

Berechtigungen ein anonymer Zugriff auf Daten ermög-

licht wird.

80

5.3 Trusted Systems





5.3.3 Pflegeberechtigungen






S_RFCACL ACTVT(Aktivität)

16 (Ausführen)

RFC_EQUSER(gleiche Benutzerkennung)

Y

RFC_SYSID(System-ID)

<SID des SAP-Systems>

RFC_USER(RFC-Benutzer)

sy-uname oder <leer>



Trusted Systems 2 Existieren Benutzer, die dazu berechtigt sind, neue Ver-

trauensbeziehungen zu Systemen anzulegen?

Es dürfen nur Basisadministratoren dazu berechtigt

sein, Vertrauensbeziehungen zu definieren.

Hier besteht das Risiko, dass durch neue Vertrauensbe-

ziehungen ein anonymer Zugriff auf die Daten des Sys-

tems ermöglicht wird.

81


5.3.4 Kritische Verbindungen

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle RFCDES anzeigen. Geben Sie

als Selektionskriterium in das Feld RFCOPTIONS (Optionen) den Wert »*Q=Y*« ein




SMT1 oder SMT2

S_RFC_TT ACTVT(Aktivität)

01 (Anlegen)

02 (Ändern)

RFC_TT_TYP(Typ in der Trusted-Beziehung)

1: aufzurufendes System

2: aufrufendes System

RFC_SYSID(System-IS)


RFC_INSTNR(Installationsnummer)

<Installationsnummer>



Trusted Systems 1 Existieren RFC-Verbindungen zu Systemen mit sensib-

len Daten, die als Trusted-Verbindung ausgewiesen

sind?

In allen Systemen dürfen nur Trusted-RFC-Verbindun-

gen existieren, die notwendig sind, genutzt werden und

dokumentiert worden sind.

Hier besteht das Risiko, dass durch die Trusted-RFC-Ver-

bindungen ein anonymer Zugriff auf sensible Daten

ermöglicht wird.

82

5.3 Trusted Systems

Abbildung 5.3 Trusted-Verbindungen anzeigen

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle RFCDES anzeigen. Geben Sie

als Selektionskriterium ins Feld RFCOPTIONS (Optionen) den Wert »*U=*Q=Y*« ein.

Ihnen werden alle RFC-Verbindungen angezeigt, die als Trusted-Verbindung ausge-

wiesen sind und in denen ein Benutzername hinterlegt ist. Die weiteren Einträge im

Feld RFCOPTIONS bedeuten:

� H=: Server-/IP-Adresse

� S=: Instanznummer

� M=: Mandant

� U=: Benutzername



Trusted Systems 1 Existieren RFC-Verbindungen zu Systemen mit sensib-

len Daten, die als Trusted-Verbindung ausgewiesen

sind, bei denen eine feste Benutzerkennung hinterlegt

ist und für die im Zielsystem die Berechtigung zum Auf-

ruf über verschiedene Benutzer vergeben ist?

In allen Systemen sollten nur Trusted-RFC-Verbindun-

gen existieren, die eine Anmeldung über denselben

Benutzer im Zielsystem ermöglichen.

Hier besteht die konkrete Möglichkeit, über die Trusted-

RFC-Verbindung anonym auf das Zielsystem zuzugrei-

fen.

83


Anhand dieser Daten erkennen Sie die Zielsysteme. Rufen Sie Transaktion SUIM auf,

und wählen Sie den Menüpfad Benutzer • Benutzer nach komplexen Selektionskrite-

rien • Benutzer nach komplexen Selektionskriterien. Tragen Sie dort auf der Register-

karte Berechtigungen im Bereich Selektion nach Werten die Werte aus der folgenden

Tabelle ein.

5.4 Zugriff von externen Programmen

5.4.1 Remote-Ausführung von Funktionsbausteinen






S_RFCACL ACTVT(Aktivität)

16 (Ausführen)

RFC_EQUSER(gleiche Benutzerkennung)

Y

RFC_SYSID(System-ID)


RFC_USER(RFC-Benutzer)

*



RFC-Berechtigungen 1 Besitzen Benutzer das Recht, alle Funktionsbausteine

auszuführen?

Dieses Zugriffsrecht sollte keinem Benutzer zugeordnet

werden.

Hier besteht das Risiko, dass Benutzer über die Funkti-

onsbausteine von externen Programmen aus kritische

Aktionen im SAP-System durchführen können.

84

5.4 Zugriff von externen Programmen

5.4.2 Konfiguration der RFC-Zugriffe

Rufen Sie Transaktion RSPFPAR auf. Geben Sie ins Feld Profilparameter den System-

parameter auth/rfc_authority_check ein, und führen Sie den Report aus. Der Para-

meter muss einen Wert »>=1« haben.

5.4.3 Funktionsbaustein RFC_ABAP_INSTALL_AND_RUN


S_RFC ACTVT(Aktivität)

16 (Ausführen)

RFC_TYPE(Typ des RFC-Objekts)

FUGR oder FUNC

RFC_SYSID(Name des RFC-Objekts)

*



RFC-Berechtigungen 1 Werden im System Zugriffsrechte für das Objekt S_RFC

überprüft?

Es müssen Zugriffsrechte für das Objekt S_RFC über-

prüft werden.


Berechtigung ausgeführt werden können.



RFC-Berechtigungen 1 Besitzen Benutzer das Recht, den Funktionsbaustein

RFC_ABAP_INSTALL_AND_RUN auszuführen?

Das Zugriffsrecht zum Ausführen dieses Funktionsbau-

steins soll keinem Benutzer zugeordnet werden.

Hier besteht das Risiko, dass Benutzer ABAP-Quellcode

ins System übertragen und ungeprüft ausführen kön-

nen, was u. a. einen Verstoß gegen § 239 HGB (Radier-

verbot) darstellt.

85








SE38

S_RFCRAIAR ACTVT(Aktivität)

16 (Ausführen)


01 (Anlegen)

02 (Ändern)

OBJTYPE(Objekttyp)

PROG

OBJNAME(Objektname)

Z$$$XRFC

DEVCLASS(Paket)

$TMP


16 (Ausführen)


FUGR


SUTL

oder


16 (Ausführen)


FUNC


RFC_ABAP_INSTALL_AND_RUN

86


zu Kapitel 6

6.1 Das Prinzip der Verbuchung

6.1.1 Auswertung

Klären Sie diese Fragestellung mit der Administration.

6.1.2 Datenkonsistenz




Verbuchung 2 Wird die Verbuchung täglich mit Transaktion SM13

oder SM14 ausgewertet, um den aktuellen Stand der

Verbuchung zu kontrollieren?

Die Verbuchung muss täglich kontrolliert werden.

Hier besteht das Risiko, dass Verbuchungsabbrüche

nicht zeitnah erkannt werden und dadurch Belege zu

spät oder überhaupt nicht ins System gebucht werden.



Verbuchung 1 Wird regelmäßig die Konsistenz der Daten überprüft,

z. B. mit Transaktion F.03 (Abstimmanalyse Finanzbuch-

haltung)?

Transaktion F.03 muss mindestens einmal im Monat

ausgeführt werden und das Ergebnis protokolliert wer-

den.

Hier besteht das Risiko, dass Inkonsistenzen in Daten

nicht zeitnah erkannt und bereinigt werden können.

87


Wird zur Konsistenzprüfung Transaktion F.03 bzw. FAGLF03 genutzt, können Sie die

Aufrufe über das Protokoll überprüfen. Selektieren Sie in der Selektionsmaske den

Punkt Historie anzeigen (Transaktion F.03) bzw. Protokoll anzeigen (Transaktion

FAGLF03), und führen Sie den Report aus.

6.1.3 Konfiguration

Rufen Sie Transaktion RSPFPAR auf, und selektieren Sie die Parameter rdisp/vb*.

Überprüfen Sie die Einstellungen der folgenden Parameter:

� rdisp/vb_dispatching

� rdisp/vb_lock_mode

� rdisp/vbdelete

� rdisp/vbmail

� rdisp/vb_mail_user_list

� rdisp/vb_stop_active



Verbuchung 1 Sind die Steuerungsparameter für die Verbuchung

gemäß den Vorgaben eingestellt?

Es müssen Vorgaben für die Steuerungsparameter

erstellt werden und die Parameter entsprechend einge-

stellt sein.

Hier besteht das Risiko, dass durch eine falsche Konfigu-

ration keine Express-E-Mail bei einem Verbuchungsab-

bruch versandt wird und dass abgebrochene

Buchungen zu früh aus dem System gelöscht werden.

88

6.2 Abgebrochene Buchungen

6.2 Abgebrochene Buchungen

6.2.1 Auswertung


6.2.2 Umgang mit abgebrochenen Buchungssätzen




abgebrochene

Buchungen

1 Wird täglich überprüft, ob abgebrochene Buchungs-

sätze aufgetreten sind?

Abgebrochene Buchungssätze sollen nicht auftreten. Es

muss täglich geprüft werden, ob abgebrochene

Buchungssätze aufgetreten sind.

Hier besteht das Risiko, dass Verbuchungsabbrüche

nicht zeitnah erkannt werden und dadurch Belege zu

spät oder gar nicht ins System gebucht werden.



abgebrochene

Buchungen

2 Wie wird mit abgebrochenen Buchungssätzen verfah-

ren?

Das Verfahren muss fest definiert sein.

Hier besteht das Risiko, dass kein festes Verfahren defi-

niert ist und es daher zu Verzögerungen in der Nachbe-

arbeitung kommt.



abgebrochene

Buchungen

1 Ist sichergestellt, dass abgebrochene Buchungen zeit-

nah nachgebucht werden?

Das Verfahren des Nachbuchens muss fest definiert

sein.

Hier besteht das Risiko, dass Buchungen nicht zeitnah

ins System nachgebucht werden.

89



6.2.3 Häufige Buchungsabbrüche

Rufen Sie Transaktion SM21 auf. Löschen Sie alle Standardselektionskriterien, und

geben Sie in das Feld Meldungs-ID den Wert »R65« (Verbuchungsabbrüche) ein.

6.2.4 Abstimmanalyse

Rufen Sie Transaktion F.03 bzw. FAGLF03 (bei der Nutzung des neuen Hauptbuches)

auf. Selektieren Sie in der Selektionsmaske die Option Historie anzeigen (Transaktion

F.03) bzw. Protokoll anzeigen (Transaktion FAGLF03), und führen Sie den Report aus.



abgebrochene

Buchungen

2 Sind in letzter Zeit häufig Buchungsabbrüche vorge-

kommen?

Eine Anhäufung von abgebrochenen Buchungen sollte

nicht vorkommen.

Hier besteht das Risiko, dass die häufigen Abbrüche auf-

grund von Systemfehlern oder falschen Parametrisie-

rungen entstehen.



abgebrochene

Buchungen

1 Die Abstimmanalyse sollte einmal pro Monat ausge-

führt werden.

Hier besteht das Risiko, dass Inkonsistenzen in Daten

nicht zeitnah erkannt und bereinigt werden können.

90

6.3 Die Belegnummernvergabe


6.3.1 Externe Vergabe


6.3.2 Pufferung von Nummernkreisobjekten

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle TNRO anzeigen. Geben Sie

als Selektionskriterium »X« in das Feld Pufferung (BUFFER) ein.



Belegnummern-

vergabe

2 Wird eine externe Belegnummernvergabe genutzt?

Die Lückenlosigkeit der Belegnummern muss im Vorsys-

tem geregelt sein.

Hier besteht das Risiko, dass Belegnummern nicht

lückenlos an SAP übertragen werden.



Belegnummern-

vergabe

2 Welche Nummernkreisobjekte sind gepuffert?

Es dürfen keine Nummernkreise gepuffert sein, für die

eine lückenlose Nummernvergabe erforderlich ist.

Hier besteht das Risiko, dass durch die Pufferung nicht

belegbare Lücken in den Belegnummernkreisen entste-

hen.



Belegnummern-

vergabe

1 Ist speziell das Nummernkreisobjekt RF_BELEG gepuf-

fert?

Das Nummernkreisobjekt RF_BELEG sollte nicht gepuf-

fert sein.

Hier besteht das Risiko, dass durch die Pufferung nicht

belegbare Lücken in den Belegnummernkreisen der

Finanzbuchhaltung entstehen.

91


Rufen Sie Transaktion SNRO auf, und geben Sie in das Feld Objektname den Wert

»RF_BELEG« ein. Klicken Sie auf die Schaltfläche Anzeigen, und wählen Sie anschlie-

ßend die Registerkarte Customizing aus. Das Feld Pufferung muss den Wert »keine

Pufferung« enthalten (siehe Abbildung 6.1).

Abbildung 6.1 Pufferung eines Nummernkreisobjekts prüfen

6.3.3 Lücken in der Belegnummerierung

Rufen Sie Transaktion S_ALR_87012342 auf (alternativ Transaktion SA38 mit Report

RFBNUM00N). Geben Sie den zu prüfenden Buchungskreis und das Geschäftsjahr an. Um

nur die Lücken ab dem zu prüfenden Geschäftsjahr anzuzeigen, setzen Sie die folgen-

den Haken (siehe Abbildung 6.2):

� Nummernlücken erst ab angegebenem Geschäftsjahr anzeigen

� Nur Lücken anzeigen



Belegnummern-

vergabe

1 Existieren Lücken in den Belegnummern?

Es sollten keine Lücken in Belegnummernkreisen exis-

tieren, für die eine lückenlose Nummernvergabe erfor-

derlich ist.

Hier besteht das Risiko, dass diese Lücken zum Jahres-

abschluss nicht vollständig nachvollzogen werden kön-

nen.

92


Abbildung 6.2 Belegnummernlücken anzeigen




Belegnummern-

vergabe

2 Wird regelmäßig kontrolliert, ob Lücken in den Beleg-

nummern aufgetreten sind?

Es ist regelmäßig zu überprüfen, ob Lücken aufgetreten

sind.

Hier besteht das Risiko, dass eventuell auftretende

Lücken nicht zeitnah erkannt und dokumentiert werden.

93


zu Kapitel 7

7.1 Organisatorische Regelungen



organisatorische

Regelungen

1 Liegen Verfahrensanweisungen zum Anlegen und

Ändern von Benutzern vor?

Das Verfahren zum Anlegen und Ändern von Benutzern

muss über eine Verfahrensanweisung definiert sein.

Hier besteht das Risiko, dass ohne eine Verfahrens-

anweisung beliebig Benutzerkonten angelegt werden

können.

organisatorische

Regelungen

3 Werden Informationen über ausgeschiedene Mitarbei-

ter von der Fachabteilung an die Administration ge-

geben?

Diese Informationen müssen der Benutzerverwaltung

mitgeteilt werden, damit die Benutzerkonten gelöscht

oder deaktiviert werden.

Hier besteht das Risiko, dass ausgeschiedene Mitarbei-

ter als aktive Benutzer im System bleiben.

organisatorische

Regelungen

2 Liegen Verfahrensanweisungen zum Löschen von

Benutzern vor?

Das Löschen von Benutzern muss durch eine Ver-

fahrensanweisung definiert sein.

Hier besteht das Risiko, dass ohne eine Verfahrens-

anweisung beliebig Benutzerkonten gelöscht werden

können.

95


organisatorische

Regelungen

2 Liegen Verfahrensanweisungen zum Sperren und Ent-

sperren von Benutzern vor?

Das Sperren und Entsperren von Benutzern muss durch

eine Verfahrensanweisung definiert sein.

Hier besteht das Risiko, dass gesperrte Benutzer telefo-

nisch ohne Genehmigung entsperrt werden können.

organisatorische

Regelungen

3 Wird das System von der Administration regelmäßig

auf Benutzer überprüft, die lange nicht mehr angemel-

det waren?

Diese Prüfung muss die Administration regelmäßig

durchführen (Festlegung im Regelwerk für Administra-

toren).

Hier besteht das Risiko, dass nicht mehr aktive Benutzer

noch aktiv im System vorhanden sind. Für diese Benut-

zer fallen ebenfalls Lizenzgebühren an.

organisatorische

Regelungen

2 Wie wird mit den Rechten von Benutzern verfahren, die

den Verantwortlichkeitsbereich wechseln?

Beim Wechseln des Verantwortlichkeitsbereichs sind

die Rechte neu zuzuordnen.

Hier besteht das Risiko, dass den Benutzern zwar neue

Rechte zugeordnet werden, die alten Rechte aber nicht

entzogen werden und sich so Berechtigungen anhäu-

fen.

organisatorische

Regelungen

1 Wie werden die Initialkennwörter für die Benutzer ver-

geben?

Es muss ein Verfahren genutzt werden, durch das jeder

Benutzer ein anderes Initialkennwort bekommt.

Hier besteht das Risiko, dass durch die Vergabe des

immer gleichen Initialkennworts leicht Anmeldungen

mit noch nie angemeldeten Benutzern möglich sind.



96

7.2 Die SAP-Standardbenutzer

Klären Sie diese Fragen mit der Administration.


7.2.1 Kennwortvergabe


organisatorische

Regelungen

1 Existieren Vorgaben für die Vergabe von Kennwörtern

bezüglich der Komplexität?

Es müssen Vorgaben zur Komplexität existieren.

Hier besteht das Risiko, dass triviale Kennwörter leicht

ausgespäht werden können.

organisatorische

Regelungen

1 Nutzen die Administratoren besonders komplexe Kenn-

wörter?

Die Kennwörter der Administratoren müssen besonders

komplex sein, um deren Hacken zu verhindern.

Hier besteht das Risiko, dass triviale Kennwörter der

Administratoren (die über besondere Systemrechte ver-

fügen) leicht ausgespäht werden können.



SAP-Standard-

benutzer

1 Wie wurden die Kennwörter für die Benutzer SAP*,

DDIC, TMSADM, EARLYWATCH und SAPCPIC vergeben?

SAP* und DDIC benötigen ein Kennwort nach dem Vier-

Augen-Prinzip.

Hier besteht das Risiko, dass einzelnen Personen die

Kennwörter dieser nicht personifizierten Benutzer

bekannt sind.



97


Rufen Sie Transaktion RSUSR003 auf. Es darf für keinen Benutzer der Eintrag »Kenn-

wort XXXXXXXX allgemein bekannt!« vorhanden sein (siehe Abbildung 7.1).

Abbildung 7.1 Kennwörter der Standardbenutzer prüfen



SAP-Standard-

benutzer

1 Wurden für alle Standardbenutzer in allen Mandanten

neue Kennwörter vergeben?

Die Kennwörter aller Standardbenutzer müssen geän-

dert werden.

Hier besteht das Risiko, dass diese Benutzer noch ihre

bekannten Initialkennwörter besitzen und somit eine

Anmeldung mit diesen Benutzern für jeden anonym

möglich ist.

98


7.2.2 Benutzer SAP*

Rufen Sie Transaktion RSUSR003 auf. Für den Benutzer SAP* müssen die Werte aus

der folgenden Tabelle gesetzt sein.

Prüfen Sie außerdem, ob dem Benutzer alle Berechtigungen entzogen wurden. Rufen

Sie hierzu Transaktion SU01 auf, und lassen Sie sich den Benutzer SAP* anzeigen.

Befinden sich auf den Registerkarten Rollen und Profile keine Einträge, sind dem

Benutzer keine Berechtigungen zugeordnet.

Rufen Sie Transaktion SU01 auf. Tragen Sie in das Feld Benutzer »SAP*« ein, und kli-

cken Sie auf die Schaltfläche Anzeigen ( ). Auf der Registerkarte Logondaten kön-



SAP-Standard-

benutzer

1 Welche Verfahrensweise wurde für den Benutzer SAP*

umgesetzt?

Der Benutzer SAP* muss gemäß dem Sicherheitsleitfa-

den abgesichert werden.

Hier besteht das Risiko, dass der Benutzer SAP* nicht

ausreichend gesichert ist und dass Anmeldungen mit

diesem Benutzer anonym möglich sind.

Spalte Wert

Status der Benutzersperre Gesperrt

Kennwortstatus Existiert; Kennwort nicht trivial

Gültig bis <Ein Datum vor dem aktuellen Datum>



SAP-Standard-

benutzer

2 Ist der Benutzer SAP* in allen Mandanten der Benutzer-

gruppe SUPER zugeordnet?

Der Benutzer SAP* muss der Gruppe SUPER zugeordnet

sein.

Hier besteht das Risiko, dass der Benutzer SAP*durch

eine falsche Gruppenzuordnung von zu vielen Benut-

zern verwaltet, insbesondere gelöscht werden kann.

99


nen Sie im Feld Benutzergruppe die Gruppe ermitteln. Wiederholen Sie dies in allen

Mandanten des Systems.

Alternativ können Sie (bei entsprechender Berechtigung) den SQL-Editor nutzen.

Rufen Sie Transaktion DBACOCKPIT auf. Wählen Sie dort den Pfad Diagnose • SQL-

Editor aus. Geben Sie die folgende SQL-Anweisung ein:

SELECT * FROM usr02 WHERE bname = 'SAP*' ORDER BY mandt

Im Feld CLASS wird Ihnen die Gruppe des Benutzers angezeigt (siehe Abbildung 7.2).

Abbildung 7.2 Benutzergruppenzuordnung des Benutzers SAP* prüfen

7.2.3 Benutzer DDIC



SAP-Standard-

benutzer

2 Existiert der Benutzer DDIC in allen Mandanten?

Der Benutzer DDIC sollte in allen Mandanten (außer

066) existieren.

Hier besteht das Risiko, dass beim Einspielen von Sup-

port Packages Fehler auftreten, wenn der Benutzer DDIC

nicht existiert.

100


Rufen Sie Transaktion RSUSR003 auf. Für den Benutzer DDIC darf der Eintrag Existiert

nicht nicht vorkommen (siehe Abbildung 7.3).

Abbildung 7.3 Existenz des Benutzers DDIC prüfen

Rufen Sie Transaktion SU01 auf, und lassen Sie sich den Benutzer DDIC anzeigen.

Überprüfen Sie auf der Registerkarte Logondaten den Benutzertyp.



SAP-Standard-

benutzer

1 Ist der Benutzer DDIC im Produktivmandanten auf den

Benutzertyp System gesetzt?

Der Benutzer DDIC muss im Produktivmandanten auf

den Benutzertyp System gesetzt sein.

Hier besteht das Risiko, dass Anmeldungen mit diesem

anonymen SAP_ALL-Benutzer möglich sind.

101


7.2.4 Benutzer EARLYWATCH

Rufen Sie Transaktion RSUSR003 auf. In der Spalte Status der Benutzersperre sollte

vermerkt sein, dass der Benutzer gesperrt ist. Existiert der Benutzer EARLYWATCH im

Mandanten 066 nicht (die Spalte Kennwortstatus hat den Wert »Existiert nicht«)

bzw. existiert der Mandant 066 nicht, ist dies nicht sicherheitskritisch. Der Mandant

wird nicht mehr benötigt.

7.3 Der Benutzerstammsatz

7.3.1 Dialogbenutzer



Wählen Sie im Feld Benutzertyp den Typ Dialog aus, und führen Sie den Report aus.

In der Überschrift des Reports wird die Anzahl der Benutzer ausgegeben (siehe Abbil-

dung 7.4).



SAP-Standard-

benutzer

2 Wurde der Benutzer EARLYWATCH im Mandanten 066

gesperrt?

Der Benutzer EARLYWATCH ist zu sperren und nur bei

Bedarf freizuschalten.

Hier besteht das Risiko, dass Anmeldungen mit diesem

Benutzer anonym durchgeführt werden können.



Benutzerstammsatz 3 Wie viele Dialogbenutzer existieren in dem Mandan-

ten?

Die Anzahl muss mit den tatsächlichen Anwendern

übereinstimmen.

Hier besteht das Risiko, dass zu viele Benutzerkonten

eingerichtet wurden, die eventuell auch Lizenzgebüh-

ren erzeugen.

102


Abbildung 7.4 Anzahl der Dialogbenutzer in einem Mandanten abfragen

7.3.2 Gültigkeit



Geben Sie das Feld Ablauf Gültigkeit von den Wert »1900« und in das Feld bis das

aktuelle Datum ein. Führen Sie den Report aus. Klicken Sie in der Ergebnisliste auf die

Schaltfläche Profile. Ihnen werden alle Benutzer angezeigt, denen noch Berechtigun-

gen zugeordnet sind (siehe Abbildung 7.5).



Benutzerstammsatz 3 Existieren Benutzer, deren Gültigkeitsdatum abgelau-

fen ist und die noch ihre Berechtigungen haben?

Es sollten keine abgelaufenen Benutzer existieren.

Hier besteht das Risiko, dass diese Benutzer jederzeit

mit ihren Zugriffsrechten und einem neuen Kennwort

wieder aktiviert und genutzt werden können.

103


Abbildung 7.5 Ungültige Benutzer mit Berechtigungen

7.3.3 Nicht genutzte Benutzerkonten


Anmeldedatum und Kennwortänderung aus. Entfernen Sie im Bereich Selektion nach

Anmeldeversuchen alle Haken, außer bei Benutzer ohne Anmeldedatum. Es werden

alle Benutzer angezeigt, die noch nie angemeldet waren.



Benutzerstammsatz 2 Existieren Benutzer, die noch nie angemeldet waren?

Benutzer, die noch nie angemeldet waren, sollten

gesperrt sein und erst bei Bedarf freigeschaltet werden.

Hier besteht das Risiko, dass diese Benutzer noch trivi-

ale Initialkennwörter besitzen.

104



Anmeldedatum und Kennwortänderung. Geben Sie in das Feld Tage seit letzter

Anmeldung den Zeitraum in Tagen an, z. B. »90 Tage«. Es werden alle Benutzer ange-

zeigt, die in diesem Zeitraum nicht angemeldet waren.

7.3.4 Benutzer ohne Gruppenzuordnung


Anmeldedatum und Kennwortänderung. Klicken Sie doppelt in das Feld Gruppe für

Berechtigung, und selektieren Sie die Selektionsoption Einzelwert (siehe Abbildung

7.6).



Benutzerstammsatz 2 Existieren Benutzer, die für einen längeren Zeitraum

nicht angemeldet waren?

Es sollten keine gültigen Benutzer existieren, die für

einen längeren Zeitraum nicht angemeldet waren.

Hier besteht das Risiko, dass diese Benutzer nicht mehr

in der Unternehmung tätig sind, die Konten aber noch

nutzen könnten und diese auch Lizenzgebühren erzeu-

gen.



Benutzerstammsatz 3 Existieren Benutzer, die keiner Gruppe zugeordnet sind?

Es dürfen keine Benutzer ohne Gruppenzuordnung exis-

tieren (abhängig vom Benutzergruppenkonzept).

Hier besteht das Risiko, dass Benutzer von eigentlich

unberechtigten Benutzeradministratoren verwaltet

werden können.

105


Abbildung 7.6 Benutzergruppenzuordnung prüfen

Ihnen werden alle Benutzer angezeigt, die keiner Gruppe zugeordnet sind.

7.4 Referenzbenutzer

7.4.1 Vorhandene Referenzbenutzer



Wählen Sie im Feld Benutzertyp den Typ Referenz aus, und führen Sie den Report aus.

Ihnen werden existierende Referenzbenutzer angezeigt. Werden keine Benutzerkon-

ten angezeigt, existieren auch keine Referenzbenutzer.



Referenzbenutzer 3 Existieren Referenzbenutzer?

Referenzbenutzer dürfen nur existieren, wenn dies im

Berechtigungskonzept vorgesehen ist.

Hier besteht das Risiko, dass durch die Nutzung von

Referenzbenutzern die Nachvollziehbarkeit des Berech-

tigungskonzepts nicht gegeben ist.

106

7.4 Referenzbenutzer




Wählen Sie im Feld Benutzertyp den Typ Referenz aus, und führen Sie den Report aus.

Klicken Sie in der Ergebnisliste auf die Schaltfläche Rollen, um sich die Rollen der

Benutzer anzeigen zu lassen. Über die Schaltfläche Profile werden Ihnen die Profile

der Benutzer angezeigt.

7.4.3 Verwendung



Wählen Sie die Registerkarte Rollen/Profile aus, und klicken Sie doppelt in das Feld

Referenzbenutzer. Wählen Sie die Selektionsoption Ungleich ( ) aus. Ihnen werden

alle Benutzer angezeigt, denen Referenzbenutzer zugeordnet sind.



Referenzbenutzer 2 Welche Zugriffsrechte besitzen die Referenzbenutzer?

Referenzbenutzer sollen nur für die Zuweisung von

unkritischen Zugriffsrechten genutzt werden.

Hier besteht das Risiko, dass den Referenzbenutzern zu

umfangreiche Rechte zugeordnet wurden, die dann auf

die zugeordneten Benutzer übertragen werden.



Referenzbenutzer 1 Welchen Benutzern sind die Referenzbenutzer zugeord-

net, und ist dies dokumentiert?

Es muss eine Dokumentation existieren, welchen

Benutzern welche Referenzbenutzer zuzuordnen sind.

Hier besteht das Risiko, dass die Referenzbenutzer zu

vielen Benutzern zugeordnet sind, und dies nicht nach-

vollziehbar ist.

107


7.4.4 Zuordnung von Nicht-Referenzbenutzern

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle PRGN_CUST anzeigen. Über-

prüfen Sie, ob zum Eintrag REF_USER_CHECK der Wert »E« hinterlegt ist. Ist dies nicht

der Fall oder existiert der Eintrag REF_USER_CHECK nicht, können auch Nicht-Referenz-

benutzer als Referenz zugeordnet werden.

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle USREFUS anzeigen. In der

Selektionsmaske geben Sie für das Feld Referenzbenutzer (REFUSER) die Selektionsop-

tion Ungleich ( ) ein. Gleichen Sie das Ergebnis nun mit der Liste der Referenzbenut-

zer aus der vorangehenden Prüfung ab.



Referenzbenutzer 1 Können auch Nicht-Referenzbenutzer als Referenz

zugeordnet werden?

Diese Möglichkeit der Zuordnung sollte unterbunden

werden.

Hier besteht das Risiko, dass Benutzer mit sehr umfang-

reichen Rechten (z. B. dem Profil SAP_ALL) als Referenz-

benutzer zugeordnet werden.



Referenzbenutzer 1 Wurden Nicht-Referenzbenutzer als Referenz zugeord-

net?

Es sollen nur Referenzbenutzer als Referenz zugeordnet

werden.

Hier besteht das Risiko, dass durch diese Zuordnungen

zu viele Rechte zugeordnet wurden.

108

7.5 Benutzergruppen

7.4.5 Unberechtigte Zuordnungen

Rufen Sie Transaktion SUIM auf, und wählen Sie den Pfad Änderungsbelege • für

Benutzer. Setzen Sie auf der Registerkarte Benutzerattribute einen Haken bei Refe-

renzbenutzer, und schränken Sie Von Datum und Bis Datum auf den Prüfungszeit-

raum ein.

Im Ergebnis wird in der Spalte Typ des Änderungsbelegs der Eintrag Referenzbenut-

zer geändert angezeigt. In der Spalte Alter Wert werden die Referenzbenutzer ange-

zeigt, die aus dem Benutzerstammsatz gelöscht wurden. In der Spalte Neuer Wert

finden Sie die hinzugefügten Referenzbenutzer.

7.5 Benutzergruppen

7.5.1 Benutzer ohne Gruppenzuordnung

Rufen Sie Transaktion SUIM auf, und wählen Sie den Pfad Benutzer • nach Anmelde-

datum und Kennwortänderung aus. Klicken Sie doppelt in das Feld Gruppe für

Berechtigung, und wählen Sie die Selektionsoption Einzelwert aus (siehe Abbildung

7.7).



Referenzbenutzer 1 Wurden unberechtigt Referenzbenutzer zugeordnet?

Unberechtigte Zuordnungen dürfen nicht vorgenom-

men werden.

Hier besteht das Risiko, dass mit den zusätzlichen

Zugriffsrechten unberechtigte Aktionen durchgeführt

werden.



Benutzergruppen 2 Existieren Benutzer, die keiner Gruppe zugeordnet sind?

Es dürfen keine Benutzer ohne Gruppenzuordnung exis-

tieren (abhängig vom Benutzergruppenkonzept).

Hier besteht das Risiko, dass Benutzer von eigentlich

unberechtigten Benutzeradministratoren verwaltet

werden können.

109


Abbildung 7.7 Benutzer ohne Gruppenzuordnung abfragen

Ihnen werden alle Benutzer angezeigt, die keiner Gruppe zugeordnet sind.

7.5.2 Administratorbenutzer

Rufen Sie Transaktion SUIM auf, und wählen Sie den Pfad Benutzer • nach Anmelde-

datum und Kennwortänderung aus. Geben Sie in das Feld Gruppe für Berechtigung

als Selektionskriterium die Administratorgruppe ein. Überprüfen Sie, ob alle Admi-

nistratorbenutzer in dieser Gruppe Mitglied sind.



Benutzergruppen 2 Wurden alle Administratorbenutzer einer eigenen

Gruppe zugeordnet?

Alle Administratorbenutzer müssen einer eigenen

Gruppe zugeordnet sein.

Hier besteht das Risiko, dass die Administratorbenutzer

von eigentlich unberechtigten Benutzeradministrato-

ren gepflegt werden können.

110

7.6 Sammelbenutzer

7.6 Sammelbenutzer

7.6.1 Vorhandene Sammelbenutzer



Geben Sie keine Selektionskriterien ein, und führen Sie den Report aus. Suchen Sie

nach Benutzernamen, die nicht direkt einem Anwender zugeordnet werden können

(z. B. Benutzer mit der Zeichenkette »TEST« im Namen). Stellen Sie fest, ob dies nur

die vereinbarten Sammelkonten sind oder ob noch weitere Sammelkonten existie-

ren.


Rufen Sie Transaktion SM19 bzw. RSAU_CONFIG auf, und überprüfen Sie, ob die Kon-

ten hier eingetragen sind und ob die vereinbarten Aktionen protokolliert werden.



Sammelbenutzer 1 Existieren Sammelbenutzer im System?

Außer den Standardbenutzern und dem Notfallbenut-

zer sollten keine Sammelbenutzer im System existieren.

Hier besteht das Risiko, dass mit diesen Benutzern ano-

nym Aktionen ausgeführt werden können und dass

eventuell gegen das Lizenzmodell von SAP verstoßen

wird.



Sammelbenutzer 1 Werden administrative Sammelbenutzer über das Audi-

ting protokolliert?

Administrative Sammelbenutzer müssen vollständig

über das Security Audit Log protokolliert werden.

Hier besteht das Risiko, dass Aktionen mit diesen ano-

nymen Benutzern nicht nachvollzogen werden können.

111


7.6.3 Dokumentation

Richten Sie diese Fragestellung an die Administration. Sichten Sie außerdem die

Dokumentation.

7.6.4 Vier-Augen-Prinzip




Sammelbenutzer 2 Wird die Nutzung der Sammelbenutzer inhaltlich doku-

mentiert?

Jede Nutzung der Sammelbenutzer muss inhaltlich

dokumentiert werden.

Hier besteht das Risiko, dass mit Sammelbenutzern

beliebige Aktionen durchgeführt werden können, ohne

dass sie inhaltlich nachvollziehbar sind.



Sammelbenutzer 1 Werden administrative Sammelbenutzer nur nach dem

Vier-Augen-Prinzip eingesetzt?

Administrative Sammelbenutzer sollten nur nach dem

Vier-Augen-Prinzip eingesetzt werden.

Hier besteht das Risiko, dass anonyme Benutzer mit

hohen Rechten ohne Vier-Augen-Prinzip genutzt wer-

den können.

112

7.6 Sammelbenutzer

7.6.5 Servicebenutzer



Wählen Sie im Feld Benutzertyp den Typ Service aus, und führen Sie den Report aus.

Ihnen werden existierende Servicebenutzer angezeigt. Werden keine Benutzerkon-

ten angezeigt, existieren keine Servicebenutzer.



Wählen Sie im Feld Benutzertyp den Typ Service aus, und führen Sie den Report aus.

Klicken Sie in der Ergebnisliste auf die Schaltfläche Rollen, um sich die Rollen der

Benutzer anzeigen zu lassen. Über die Schaltfläche Profile werden Ihnen die Profile

der Benutzer angezeigt.



Sammelbenutzer 2 Existieren Benutzerkonten vom Typ Service?

Servicebenutzer dürfen nur existieren, wenn dies im

Berechtigungskonzept vorgesehen ist.

Hier besteht das Risiko, dass durch diese Benutzer ano-

nyme Aktionen im System erfolgen.



Sammelbenutzer 1 Welche Zugriffsrechte besitzen die Servicebenutzer?

Sie dürfen nur unkritische lesende Berechtigungen

besitzen.

Hier besteht das Risiko, dass diese Benutzer zu umfang-

reiche Rechte besitzen und damit eventuell gegen gel-

tende Gesetze (z. B. § 238 HGB) verstoßen könnten.

113


Lassen Sie sich die Dokumentation aushändigen, in der hinterlegt ist, welcher Perso-

nenkreis die Servicebenutzer nutzt.

7.7 Benutzervermessungsdaten

7.7.1 Richtlinien

Prüfen Sie dies im Lizenzvertrag. Rufen Sie Transaktion USMM auf, und wechseln Sie

auf die Registerkarte Preisliste. Überprüfen Sie, ob hier die vertraglich vereinbarte

Preisliste hinterlegt ist. Überprüfen Sie danach auf der Registerkarte Nutzertypen, ob

hier die vertraglich vereinbarten Nutzertypen aktiviert sind.



Sammelbenutzer 2 Wer nutzt diese Servicebenutzer?

Es muss nachvollziehbar sein, wer diese Servicebenut-

zer nutzt.

Hier besteht das Risiko, dass diese Benutzer unberech-

tigt von zu vielen Personen genutzt werden.



Nutzervermessung 3 Welche Nutzertypen sollen laut Vorgabe im System

existieren?

In der Dokumentation bzw. im Lizenzvertrag muss die

Soll-Vorgabe definiert sein.

Hier besteht das Risiko, dass das System nach der fal-

schen Preisliste vermessen wird.

114

7.8 Initialkennwörter und Benutzersperren

7.7.2 Verwendung

Rufen Sie Transaktion SA38 (Menüpfad System • Dienste • Reporting) auf, und lassen

Sie sich den Report RSUVM005 anzeigen. Der Nutzertyp der Benutzer wird in der Ergeb-

nisliste im Feld Vertraglicher Benutzertyp angezeigt.

7.8 Initialkennwörter und Benutzersperren

7.8.1 Vergabe von Initialkennwörtern




Nutzervermessung 2 Wurden diese Vorgaben für die Benutzer des Systems

umgesetzt?

Die Nutzerkonten müssen den richtigen Benutzertypen

zugeordnet sein.

Hier besteht das Risiko, dass Benutzer falschen Nutzer-

typen zugeordnet und dadurch eventuell zu hohe

Lizenzgebühren gezahlt werden.



Initialkennwörter 1 Werden für Benutzer immer benutzerspezifische Initial-

kennwörter von der Administration vergeben?

Die Benutzer des Systems dürfen nicht dieselben Initial-

kennwörter erhalten.

Hier besteht das Risiko, dass die ständige Verwendung

desselben Initialkennworts das Hacken eines Benutzers,

der noch ein Initialkennwort besitzt, ermöglicht.

115


7.8.2 Verwendung


Anmeldedatum und Kennwortänderung aus. Entfernen Sie im Bereich Selektion nach

Status des Kennworts alle Haken außer Benutzer mit Initialkennwort. Ihnen werden

alle Benutzer mit Initialkennwort angezeigt.

7.8.3 Gültigkeit

Rufen Sie Transaktion RSPFPAR auf. Geben Sie in das Feld Profileparameter den Para-

meter »login/password_max_idle_initial« ein, und führen Sie den Report aus. Das

Ergebnis zeigt an, nach wie vielen Tagen ein Initialkennwort ungültig wird. Der Wert

»0« bedeutet, dass Initialkennwörter unbegrenzt gültig sind.



Initialkennwörter 2 Existieren Benutzer im System, die noch ihr Initialkenn-

wort besitzen?

Es dürfen nur wenige oder keine Benutzer existieren,

die noch ein Initialkennwort besitzen.

Hier besteht das Risiko, dass Anmeldungen mit diesen

Benutzern mit einem trivialen Kennwort möglich sind.



Initialkennwörter 1 Laufen Initialkennwörter nach einem vorgegebenen

Zeitraum ab?

Initialkennwörter sollen nach einem Zeitraum von

wenigen Tagen ungültig werden.

Hier besteht das Risiko, dass Initialkennwörter immer

gültig sind und somit potenziell ausgespäht werden

können.

116

7.9 Kennwortverschlüsselung

7.8.4 Falschanmeldungen

Rufen Sie Transaktion SUIM auf, und wählen Sie den Menüpfad Benutzer • mit

Falschanmeldungen.


7.9.1 Art der Verschlüsselung

Rufen Sie Transaktion RSPFPAR auf. Geben Sie in das Feld Profilparameter den Para-

meter login/password_downwards_compatibility ein, und führen Sie den Report aus.

Der Wert »0« bedeutet, dass Kennwörter ausschließlich nach dem aktuellen Ver-

schlüsselungsverfahren gespeichert werden. Bei allen anderen Werten werden

zusätzlich noch die älteren MD5-/SHA-1-Verschlüsselungen gespeichert.



Benutzersperren 2 Existieren Benutzer, die eine hohe Anzahl an Falsch-

anmeldungen aufweisen oder durch Falschanmeldun-

gen gesperrt sind?

Falschanmeldungen von Benutzern sollten überwacht

werden.

Hier besteht das Risiko, dass Eindringversuche unter

dieser Benutzerkennung stattgefunden haben.



Kennwortverschlüs-

selung

1 Werden die Kennwörter ausschließlich nach dem Itera-

ted Salted SHA-1-Hash verschlüsselt?

Kennwörter sollten nur nach dem Iterated Salted

SHA-1-Hash verschlüsselt werden.

Hier besteht das Risiko, dass Kennwörter durch die alte

MD5-/SHA1-Verschlüsselung leicht zu hacken sind.

117


7.9.2 Alte Hash-Werte

Rufen Sie Transaktion SE16 auf, und lassen Sie sich die Selektionsmaske von Tabelle

USR02 anzeigen. Klicken Sie doppelt in das Feld BCODE, und wählen Sie als Selektions-

option Ungleich ( ) aus (siehe Abbildung 7.8).

Abbildung 7.8 Speicherung von Kennwort-Hash-Werten prüfen

Lassen Sie sich die Tabelle anzeigen. Werden keine Einträge angezeigt, sind in diesem

Feld keine Kennwort-Hash-Werte gespeichert. Verfahren Sie ebenso mit den folgen-

den Feldern:

� OCOD1

� OCOD2

� OCOD3



Kennwortverschlüs-

selung

1 Wurden alte Hash-Werte aus Tabelle USR02 gelöscht?

Bei ausschließlicher Nutzung des Iterated Salted SHA-1-

Hashs sollten die alten Hash-Werte gelöscht werden.

Hier besteht das Risiko, dass Kennwörter in MD5-/

SHA-1-Verschlüsselung leicht zu hacken sind.

118


� OCOD4

� OCOD5

� PASSCODE




Wechseln Sie auf die Registerkarte Berechtigungen, und geben Sie die Werte aus der

folgenden Tabelle ein. (Sie müssen den Report mehrmals ausführen, da nicht alle

Werte gleichzeitig abgefragt werden können.)



Kennwortverschlüs-

selung

1 Welche Benutzer besitzen Zugriffsrechte zum Anzeigen

der Tabellen mit Kennwort-Hash-Werten?

Die Berechtigung zur Anzeige der Tabellen mit den

Kennwort-Hash-Werten sollte im Produktivmandanten

nicht vergeben werden.

Hier besteht das Risiko, dass Kennwörter von Benutzern

ausgespäht werden können.



<Transaktionen gemäß

Abschnitt 1.3.1, Anzeigetrans-

aktionen für Tabellen, im Buch


03 (Anzeigen)


SPWD (Kennwort-Hash-Werte)

oder


<Transaktionen gemäß

Abschnitt 1.3.1, Anzeigetrans-

aktionen für Tabellen, im Buch

119


7.10 Angemeldete Benutzer

7.10.1 Verwendete Workstations




03 (Anzeigen)

TABLE(Tabelle)

USH02

USH02_ARC_TMP

USR02

USRPWDHISTORY

VUSER001

VUSR02_PWD



angemeldete Benut-

zer

3 Wird Tabelle USR41 stichprobenartig daraufhin über-

prüft, dass Benutzer nur von zulässigen Workstations

angemeldet sind?

Die erfolgten Anmeldungen müssen stichprobenartig

auf korrekte TCP/IP-Nummern überprüft werden.

Hier besteht das Risiko, dass Anmeldungen oder Anmel-

deversuche über einen fremden TCP/IP-Kreis erfolgen.



angemeldete Benut-

zer

3 Wurde die Tabellenprotokollierung für Tabelle USR41

aktiviert?

Um eine Nachvollziehbarkeit bei Eindringversuchen zu

gewährleisten, kann Tabelle USR41 protokolliert wer-

den.

Hier besteht das Risiko, dass Anmeldungen aus frem-

den TCP/IP-Kreisen nicht nachvollziehbar sind.


120

7.11 Die Änderungshistorie zu Benutzern

Rufen Sie Transaktion SE13 auf. Geben Sie den Tabellennamen USR41 ein, und klicken

Sie auf die Schaltfläche Anzeigen. Ist der Haken zum Punkt Datenänderungen proto-

kollieren gesetzt, werden Änderungen an der Tabelle protokolliert.


7.11.1 Neue Benutzer

Rufen Sie Transaktion SUIM auf, und wählen Sie den Menüpfad Änderungsbelege •

Benutzer • für Benutzer. Geben Sie in die Felder Von Datum und Bis Datum den Prü-

fungszeitraum ein. Setzen Sie einen Haken bei Benutzer angelegt, und führen Sie den

Report aus. Es werden Ihnen alle Benutzer angezeigt, die im Prüfungszeitraum ange-

legt wurden. Gleichen Sie diese Liste (eventuell stichprobenartig) mit den Benutzer-

anträgen ab.

7.11.2 Gelöschte Benutzer



Änderungsbelege 2 Wurden seit der letzten Prüfung neue Benutzer ange-

legt, und wurde dies dokumentiert, z. B. über Benutzer-

anträge?

Das Anlegen neuer Benutzer muss dokumentiert wer-

den.

Hier besteht das Risiko, dass unberechtigt Benutzerkon-

ten angelegt werden.



Änderungsbelege 2 Wurden seit der letzten Prüfung Benutzer gelöscht, und

wurde dies dokumentiert?

Das Löschen von Benutzern muss dokumentiert wer-

den.

Hier besteht das Risiko, dass unberechtigt angelegte

Benutzer nach kurzer Zeit wieder gelöscht wurden.

121




fungszeitraum ein. Setzen Sie einen Haken bei Benutzer gelöscht, und führen Sie den

Report aus. Es werden Ihnen alle Benutzer angezeigt, die im Prüfungszeitraum

gelöscht wurden. Gleichen Sie diese Liste (eventuell stichprobenartig) mit den Benut-

zeranträgen ab.




fungszeitraum ein. Setzen Sie je einen Haken bei Falschanmeldesperre gesetzt und

Falschanmeldesperre aufgehoben, und führen Sie den Report aus. Es werden Ihnen

alle Benutzer angezeigt, die im Prüfungszeitraum durch Falschanmeldungen

gesperrt und entsperrt wurden.

7.11.4 Profil SAP_ALL



Änderungsbelege 3 Wurden seit der letzten Prüfung Benutzer durch Falsch-

anmeldungen gesperrt und wieder entsperrt?

Es dürfen nur vereinzelt Benutzer gesperrt und ent-

sperrt worden sein.

Hier besteht das Risiko, dass unter diesen Benutzerken-

nungen Eindringversuche stattgefunden haben.



Änderungsbelege 1 Wurde seit der letzten Prüfung Benutzern das Profil

SAP_ALL zugeordnet?

Das Profil SAP_ALL darf im Produktivmandanten nur

einem Notfallbenutzer zugeordnet werden.

Hier besteht das Risiko, dass durch Zuordnung dieses

Profils kritische Aktionen im Produktivmandanten

durchgeführt wurden.

122




fungszeitraum ein. Wählen Sie die Registerkarte Rollen/Profile aus, setzen Sie einen

Haken bei Profile, und tragen Sie in das Feld Profilname »SAP_ALL« ein. Führen Sie

den Report aus. Es werden Ihnen alle Benutzer angezeigt, denen im Prüfungszeit-

raum SAP_ALL zugeordnet oder entzogen wurde. Gleichen Sie diese Liste mit der

Dokumentation dazu ab.

123


zu Kapitel 8

8.1 Das ABAP Dictionary

Klären Sie diese Fragestellung mit der Entwicklung.




ABAP Dictionary 3 Wurde eine Dokumentation zu den eigenentwickelten

Domänen angelegt?

Eigenentwickelte Domänen müssen dokumentiert sein.

Hier besteht das Risiko, dass bei Weiterentwicklungen die

Domänen falsch eingesetzt bzw. unnötigerweise neue

Domänen angelegt werden.



ABAP Dictionary 3 Wurde eine Dokumentation zu den eigenentwickelten

Datenelementen angelegt?

Eigenentwickelte Datenelemente müssen dokumentiert

sein.


Datenelemente falsch eingesetzt bzw. unnötigerweise

neue Datenelemente angelegt werden.

125


8.2 Das Konzept der Tabellensteuerung

8.2.1 Dokumentation


8.2.2 Mandantenunabhängige Tabellen


DD02L anzeigen. Schränken Sie das Feld Tabellenname (TABNAME) auf den Kundenna-

mensraum für Tabellen ein (siehe im Buch Abschnitt 8.2.7, »Unternehmenseigene

Tabellen und Views«) sowie (falls vorhanden) unternehmenseigene Namensräume.

Lassen Sie das Feld mand.abh (CLIDEP) leer, und wählen Sie für das Feld die Selektions-

option Einzelwert ( ) aus (siehe Abbildung 8.1).



Tabellen und

Views

2 Wurde eine Dokumentation zu den eigenentwickelten

Tabellen und Views angelegt?

Eigenentwickelte Tabellen und Views müssen dokumen-

tiert sein.


Tabellen/Views falsch eingesetzt bzw. unnötigerweise

neue Tabellen angelegt werden.



Tabellen und

Views

1 Existieren unternehmenseigene Tabellen mit betriebswirt-

schaftlichen Daten, die mandantenunabhängig sind?

Unternehmenseigene Tabellen mit betriebswirtschaftli-

chen Daten müssen als mandantenabhängige Tabellen

definiert sein.

Hier besteht das Risiko, dass aus anderen Mandanten

heraus Unternehmensdaten gelesen und auch manipuliert

werden können.

126

8.2 Das Konzept der Tabellensteuerung

Abbildung 8.1 Mandantenunabhängige unternehmenseigene Tabellen anzeigen

Im Ergebnis werden Ihnen alle unternehmenseigenen Tabellen angezeigt, die man-

dantenunabhängig definiert sind.

8.2.3 Unternehmenseigene Views


DD25L anzeigen. Schränken Sie das Feld Viewname (VIEWNAME) auf den Kundenna-

mensraum für Tabellen ein (siehe im Buch Abschnitt 8.2.7, »Unternehmenseigene

Tabellen und Views«) sowie (falls vorhanden) unternehmenseigene Namensräume.

Schränken Sie zusätzlich das Feld Viewtyp (VIEWCLASS) auf den Wert »C« (Pflege-View)

ein.



Tabellen und

Views

1 Existieren unternehmenseigene Views für nicht änderbare

Tabellen, deren Inhalte nicht manuell gepflegt werden sol-

len?

Unternehmenseigene Views für nicht änderbare Tabellen,

deren Daten nicht manuell gepflegt werden sollen, dürfen

nicht existieren.

Hier besteht das Risiko, dass Tabelleninhalte manipuliert

werden können.

127


Überprüfen Sie im Ergebnis die im Feld Primärtabelle (ROOTTAB) hinterlegten Tabellen

hinsichtlich ihrer manuellen Änderbarkeit (mittels Transaktion SE11 oder Tabelle

DD02L).

8.3 Zugriffe auf Tabellen

8.3.1 Zugriff über das DBA Cockpit




folgenden Tabelle ein.



Zugriffe auf

Tabellen

2 Besitzen Benutzer die Berechtigung zur Anzeige von Tabel-

len über das DBA Cockpit?

Die Berechtigung zur Anzeige von Tabellen mit dem DBA

Cockpit darf nur an wenige administrative Benutzer verge-

ben werden.

Hier besteht das Risiko, dass Tabellen angezeigt werden

können, für die der Benutzer eigentlich keine Berechtigun-

gen besitzt.


S_DBCON ACTVT(Aktivität)

03 (Anzeigen)

DBA_DBHOST(Servername)

<Servername>

DBA_DBSID(Datenbankname)

<Datenbankname>

DBA_DBUSER(Datenbankbenutzer)

<Datenbankbenutzer>

128

8.3 Zugriffe auf Tabellen

8.3.2 Manuelle Änderung

Rufen Sie Transaktion RDDPRCHK_AUDIT auf. Schränken Sie das Feld Tabellenname

auf den Kundennamensraum für Tabellen ein (siehe im Buch Abschnitt 8.2.7, »Unter-

nehmenseigene Tabellen und Views«) sowie (falls vorhanden) unternehmenseigene

Namensräume. Wählen Sie zum Menüpunkt Tabellenpflege mit SE16 die Option vor-

handen aus (siehe Abbildung 8.2).

S_TABU_SQL ACTVT

(Aktivität)

33 (Lesen)

DBSID(Datenbankverbindung)

<Datenbankverbindung>

TABLE(Tabelle)

*

TABOWNER(Besitzer in der Datenbank)

<Datenbankbenutzer>



Zugriffe auf

Tabellen

2 Welche unternehmenseigenen Tabellen können manuell

im SAP-System geändert werden?

Es dürfen nur Customizing-Tabellen manuell änderbar sein.

Hier besteht das Risiko, dass auch Tabellen, die Stamm-

und Bewegungsdaten enthalten, als Änderbar definiert

werden.


129


Abbildung 8.2 Manuell pflegbare Tabellen anzeigen

Ihnen werden alle unternehmenseigenen Tabellen angezeigt, die manuell gepflegt

werden können.

8.3.3 Laufende Einstellungen


OBJH anzeigen. Schränken Sie das Feld Objekt (OBJECTNAME) auf den Kundennamens-

raum für Tabellen und Views ein (siehe im Buch Abschnitt 8.2.7, Unternehmensei-

gene Tabellen und Views) sowie (falls vorhanden) unternehmenseigene

Namensräume. Setzen Sie im Feld Laufende Einstellung (CURSETTING) ein »X« als

Selektion. Ihnen werden alle unternehmenseigenen Tabellen und Views angezeigt,

die als laufende Einstellung deklariert sind.



Zugriffe auf

Tabelle

1 Wurden Tabellen/Views als laufende Einstellung deklariert,

die im Produktivsystem nicht gepflegt werden dürfen?

Laufende Einstellungen dürfen nur für Tabellen/Views ein-

gerichtet werden, die aus betriebswirtschaftlicher Sicht im

Produktivsystem gepflegt werden müssen.

Hier besteht das Risiko, dass freigabepflichtige Änderungen

direkt im Produktivsystem ohne Vier-Augen-Prinzip vorge-

nommen werden.

130

8.4 Berechtigungen für Tabellen und Views

8.3.4 Dokumentation

Tabellenänderungen können Sie mit Transaktion SCU3, Schaltfläche Protokolle aus-

werten, auswerten. Prüfen Sie, ob die Änderungen dokumentiert sind.


8.4.1 Mandantenunabhängige Tabellen







Zugriffe auf

Tabellen

2 Werden manuelle Tabellenänderungen dokumentiert?

Manuelle Tabellenänderungen müssen dokumentiert

werden.

Hier besteht das Risiko, dass Änderungen an Tabellen (Cus-

tomizing) ohne Dokumentationen nicht nachvollzogen

werden können.



Tabellenberechti-

gungen

1 Welche Benutzer können mandantenunabhängige Tabel-

len ändern?

Nur Administratoren dürfen mandantenunabhängige

Tabellen ändern.

Hier besteht das Risiko, dass Benutzer Systemeinstellungen

ändern.



02 (Ändern)


131





folgenden Tabelle ein (anstelle des Sterns geben Sie den Wert »#*« ein).


X

oder


02 (Ändern)

TABLE(Tabelle)


X



Tabellenberechti-

gungen

1 Welche Benutzer können alle Tabellen des Systems ändern?

Die Berechtigung zum Ändern aller Tabellen darf im Pro-

duktivsystem nicht vergeben werden.

Hier besteht das Risiko, dass Benutzer Tabellen ändern,

deren Inhalte rechnungslegungsrelevant sind.



02 (Ändern)


*


X


132


8.4.2 Tabellen ohne Gruppenzuordnung

Rufen Sie Transaktion RDDTDDAT_BCE auf. Schränken Sie das Feld Tabellenname auf

den Kundennamensraum für Tabellen ein (siehe im Buch Abschnitt 8.2.7, Unterneh-

menseigene Tabellen und Views«) sowie (falls vorhanden) unternehmenseigene

Namensräume. Klicken Sie doppelt in das Feld Berechtigungsgruppe, und wählen Sie

die Selektionsoption Einzelwert ( ) aus. Führen Sie den Report aus. Ihnen werden

alle unternehmenseigenen Tabellen angezeigt, die keiner Berechtigungsgruppe

zugeordnet sind.

oder


02 (Ändern)

TABLE(Tabelle)

*


X



Tabellenberechti-

gungen

2 Sind die unternehmenseigenen Tabellen Berechtigungs-

gruppen zugeordnet?

Unternehmenseigene Tabellen müssen durch Berechti-

gungsgruppen geschützt werden.

Hier besteht das Risiko, dass Berechtigungen für eigene

Tabellen zu umfassend vergeben werden.


133


8.4.3 Berechtigungsgruppe &NC&





8.5 Die Tabellenpufferung

Dieser Abschnitt enthält keine Checklisten.



Tabellenberechti-

gungen

2 Besitzen Benutzer Zugriff auf die Berechtigungsgruppe

&NC&?

Der Zugriff auf Tabellen der Berechtigungsgruppe &NC&

darf nur äußerst restriktiv vergeben werden.

Hier besteht das Risiko, dass Benutzer auf Tabellen zugrei-

fen können, auf die sie keinen Zugriff haben dürfen.



02 (Ändern)

03 (Anzeigen)


&NC&

134


zu Kapitel 9

9.1 Entwicklerrichtlinien


9.2 Entwickler- und Objektschlüssel

9.2.1 Produktivsystem



Entwicklerrichtlinie 1 Existiert eine Entwicklerrichtlinie, in der das gesamte

Verfahren der Transporte und Eigenentwicklungen

beschrieben ist?

Es muss eine Entwicklerrichtlinie existieren, in der Vor-

gaben für Eigenentwicklungen und Transporte aufge-

führt sind.

Hier besteht das Risiko, dass Eigenentwicklungen und

Transporte ohne konkrete Vorgaben und damit ohne

Kontrollen durchgeführt werden.



Entwickler- und

Objektschlüssel

1 Besitzen Benutzer im Produktivsystem einen Entwickler-

schlüssel?

Außer einem Notfallbenutzer, der nach dem Vier-

Augen-Prinzip einzusetzen ist, darf es keine Entwickler

im Produktivsystem geben.

Hier besteht das Risiko, dass durch eine Anwendungs-

entwicklung im Produktivsystem gegen geltende

Gesetze (z. B. § 239 HGB Radierverbot) verstoßen wird.

135


Rufen Sie im Produktivsystem Transaktion SE16 auf, und lassen Sie sich Tabelle

DEVACCESS anzeigen. Darin sind die Benutzer mit Entwicklerschlüssel hinterlegt.

9.2.2 Qualitätssicherungssystem

Rufen Sie im Qualitätssicherungssystem Transaktion SE16 auf, und lassen Sie sich

Tabelle DEVACCESS anzeigen. Darin sind die Benutzer mit Entwicklerschlüssel hinter-

legt.

9.2.3 Entwicklungssystem

Rufen Sie im Entwicklungssystem Transaktion SE16 auf, und lassen Sie sich Tabelle

DEVACCESS anzeigen. Darin sind die Benutzer mit Entwicklerschlüssel hinterlegt.



Entwickler- und

Objektschlüssel

2 Besitzen Benutzer im Qualitätssicherungssystem einen

Entwicklerschlüssel?

Das Qualitätssicherungssystem muss bezüglich der Ent-

wickler wie das Produktivsystem behandelt werden. Es

sollte keine Entwickler in diesem System geben.

Hier besteht das Risiko, dass Freigabeverfahren durch

Eingriffe von Entwicklern beeinflusst werden.



Entwickler- und

Objektschlüssel

2 Welche Benutzer besitzen im Entwicklungssystem einen

Entwicklerschlüssel?

Nur die tatsächlichen Entwickler dürfen einen Entwick-

lerschlüssel besitzen.

Hier besteht das Risiko, dass unberechtigte Benutzer

eine Anwendungsentwicklung betreiben dürfen.

136


9.2.4 Dokumentation der Entwicklerkonten

Prüfen Sie die Dokumentation.

9.2.5 Beantragung von Entwicklerschlüsseln

Wählen Sie im Launchpad des SAP Service Marketplace die Kachel Benutzermanage-

ment und dort den Punkt Reports und Updates. Sollte ihr eigenes Benutzerkonto

dafür keine ausreichende Berechtigung besitzen, lassen Sie dies von einem entspre-

chend berechtigtem Administrator ausführen. Wählen Sie im Feld Berechtigungen

den Eintrag Objekt- und Entwicklerschlüssel registrieren aus, und klicken Sie auf die

Schaltfläche Start. Die dafür berechtigten Benutzer werden Ihnen angezeigt (siehe

Abbildung 9.1).



Entwickler- und

Objektschlüssel

2 Existiert eine Dokumentation darüber, welche Entwick-

lerkonten es in welchem System gibt?

Die Vergabe eines Entwicklerschlüssels muss grundsätz-

lich dokumentiert werden.

Hier besteht das Risiko, dass es keine Vorgaben und

keine Nachvollziehbarkeit darüber gibt, welche Perso-

nen als Entwickler tätig sein sollen.



Entwickler- und

Objektschlüssel

1 Wer besitzt einen Zugang zum SAP Service Marketplace

mit der Berechtigung, Entwicklerschlüssel zu beantra-

gen?

Das Zugriffsrecht zum Anfordern neuer Schlüssel darf

nur entsprechend autorisierten Personen zugeordnet

sein.

Hier besteht das Risiko, dass unberechtigt Entwickler-

schlüssel angefordert und auch im Produktivsystem ein-

gesetzt werden können.

137


Abbildung 9.1 Benutzer mit Berechtigung zur Beantragung

von Entwicklerschlüsseln anzeigen


Rufen Sie Transaktion SE13 auf. Tragen Sie Tabelle DEVACCESS ein, und klicken Sie auf

die Schaltfläche Anzeigen. Der Eintrag Datenänderungen protokollieren muss akti-

viert sein.



Entwickler- und

Objektschlüssel

1 Wurde für Tabelle DEVACCESS die Protokollierung akti-

viert?

Die Tabelle muss protokolliert werden, um nachzuvoll-

ziehen, welche Entwicklerschlüssel wann eingegeben

wurden.

Hier besteht das Risiko, dass die Eingabe von Entwickler-

schlüsseln, insbesondere im Produktivsystem, nicht

nachvollzogen werden kann.

138


9.2.7 Vorhandene Objektschlüssel

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle ADIRACCESS anzeigen. Darin

sind die Objektschlüssel hinterlegt.

9.2.8 Dokumentation der Objektschlüssel

Prüfen Sie die Dokumentation.



Entwickler- und

Objektschlüssel

2 Welche Objektschlüssel für SAP-eigene Objekte wurden

bereits angefordert?

Es dürfen nur Objektschlüssel für SAP-eigene Objekte

angefordert werden, wenn dies unumgänglich ist. Die

Anforderung muss hinreichend begründet sein.

Hier besteht das Risiko, dass SAP-eigene Objekte ohne

ausreichende Begründung geändert wurden und

dadurch die Gewährleistung für die Objekte von SAP-

Seite aus nicht mehr gegeben ist.



Entwickler- und

Objektschlüssel

2 Existiert eine Dokumentation über die angeforderten

Objektschlüssel?

Angeforderte Objektschlüssel müssen grundsätzlich

dokumentiert werden.

Hier besteht das Risiko, dass nicht mehr nachvollziehbar

ist, aus welchem Grund der Schlüssel beantragt wurde

und ob das in Zukunft (z. B. bei Releasewechseln) noch-

mals relevant sein könnte.

139


Prüfen Sie stichprobenartig in der Dokumentation, ob die Einträge aus Tabelle

ADIRACCESS dort dokumentiert sind.

9.3 Systemänderbarkeit


Rufen Sie Transaktion RSAUDIT_SYSTEM_ENV auf (alternativ Transaktion

RSWBO004), und klicken Sie auf die Schaltfläche Ausführen ( ). Die Zeile System-

änderbarkeit (global) zeigt Ihnen den aktuellen Stand an (siehe Abbildung 9.2).



Entwickler- und

Objektschlüssel

2 Wurde in der Dokumentation jede Änderung am SAP-

eigenen Objekt erläutert?

Jede Änderung an SAP-eigenen Objekten muss ausführ-

lich dokumentiert werden.

Hier besteht das Risiko, dass diese Objekte bei Release-

wechseln oder beim Einspielen von Support Packages

als Geändert angezeigt werden und nicht nachvollzogen

werden kann, ob diese Änderungen noch relevant sind

und wie weiter zu verfahren ist.



Systemänderbarkeit 1 Ist das Produktivsystem gegen eine Anwendungsent-

wicklung gesperrt?

Die Systemänderbarkeit muss im Produktivsystem auf

nicht änderbar gesetzt sein.

Hier besteht das Risiko, dass im Produktivsystem Pro-

gramme angelegt oder geändert werden können und

somit gegen gesetzliche Auflagen verstoßen wird.

140

9.3 Systemänderbarkeit

Abbildung 9.2 Systemänderbarkeit des Produktivsystems prüfen




Systemänderbarkeit 1 Wer besitzt im Produktivsystem die Berechtigung, die

Systemänderbarkeit einzustellen?

Die Vergabe dieser Berechtigung muss äußerst restriktiv

gehandhabt werden, und die Berechtigungen dürfen

nur an die Administration vergeben werden.

Hier besteht das Risiko, dass unberechtigte Personen

das Produktivsystem für die Anwendungsentwicklung

freischalten können.

141






9.3.3 Änderungen der Systemänderbarkeit

Rufen Sie Transaktion RSWBO004 auf, und klicken Sie auf die Schaltfläche Protokoll

( ). Klicken Sie in der darauffolgenden Ansicht auf die Schaltfläche Alles expandie-

ren ( ). Ihnen werden alle Änderungen an der Systemänderbarkeit aufsteigend

angezeigt.



SE06

RSWBO004

SCTS_RSWBO004

<Reporting-Transaktion>

S_CTS_ADMI oder S_CTS_SADM S_ADMI_FCD(Systemadministrations-

funktion)

SYSC



Systemänderbarkeit 2 Wurden in letzter Zeit Änderungen an der Systemänder-

barkeit im Produktivsystem vorgenommen, und war es

für einen langen Zeitraum änderbar?

Änderungen an der Systemänderbarkeit dürfen nur in

Ausnahmefällen vorgenommen und müssen zeitnah

wieder zurückgesetzt werden.

Hier besteht das Risiko, dass vergessen wurde, die Sys-

temänderbarkeit zurückzusetzen, und dass das System

für einen längeren Zeitraum änderbar war.

142

9.4 Das Transportsystem

9.3.4 Dokumentation

Lassen Sie sich die Dokumentation aushändigen und gleichen Sie es mit dem Ergeb-

nis der Prüfung aus Abschnitt 9.3.3, »Änderungen der Systemänderbarkeit«, ab.



Rufen Sie im Entwicklungssystem Transaktion SUIM auf, und wählen Sie den Menü-

pfad Benutzer • Benutzer nach komplexen Selektionskriterien • Benutzer nach kom-

plexen Selektionskriterien. Wählen Sie die Registerkarte Berechtigungen aus, und

geben Sie die Werte aus der folgenden Tabelle ein.



Systemänderbarkeit 2 Wurden die Änderungen an der Systemänderbarkeit

dokumentiert?

Änderungen an der Systemänderbarkeit sind grundsätz-

lich zu dokumentieren.

Hier besteht das Risiko, dass die Gründe für die Ände-

rungen nicht nachvollzogen werden können und

dadurch die Ordnungsmäßigkeit gefährdet ist.



Transportsystem 2 Wer ist berechtigt, im Entwicklungssystem neue Auf-

träge anzulegen, freizugeben und ins Produktivsystem

zu importieren?

Für diesen Vorgang muss eine Funktionstrennung

implementiert sein.

Hier besteht das Risiko, dass ohne Funktionstrennung

Transporte vollständig in einer Hand liegen und somit

keine Kontrolle der Transporte erfolgt.

143


Rufen Sie im Produktivsystem Transaktion SUIM auf, und wählen Sie den Menüpfad

Benutzer • Benutzer nach komplexen Selektionskriterien • Benutzer nach komplexen

Selektionskriterien. Wählen Sie die Registerkarte Berechtigungen aus, und geben Sie


Vergleichen Sie, ob identische Benutzer in beiden Auswertungen erscheinen.

9.4.2 Funktionstrennung



SE01 oder SE09 oder SE10

S_TRANSPRT oder

S_SYS_RWBOACTVT(Aktivität)

01 (Anlegen)

TTYPE(Auftragstyp)

DTRA (Workbench-Aufträge)

CUST (Customizing-Aufträge)



STMS

STMS_IMPORT

STMS_QUEUES

<Reporting>

S_CTS_ADMI oder

S_CTS_SADMCTS_ADMFCT(Administrationsfunktion)

IMPS (Import einzelner Aufträge)

IMPA (Import aller Aufträge)



Transportsystem 1 Wer besitzt zusätzlich zu dem Recht, neue Aufträge im

Entwicklungssystem anzulegen, freizugeben und ins

Produktivsystem zu importieren, noch das Recht zur

Anwendungsentwicklung oder zum Customizing im

Entwicklungssystem?

Es muss eine Funktionstrennung zwischen Entwicklung

und Transporten implementiert sein.

Hier besteht das Risiko, dass Entwickler ihre Eigenent-

wicklungen ohne Freigabeverfahren ins Produktivsys-

tem transportieren können.

144


Rufen Sie im Entwicklungssystem Transaktion SUIM auf, und wählen Sie den Menü-

pfad Benutzer • Benutzer nach komplexen Selektionskriterien • Benutzer nach kom-

plexen Selektionskriterien. Wählen Sie die Registerkarte Berechtigungen aus, und

geben Sie die Werte aus den folgenden Tabellen ein.

Die erste Tabelle zeigt die Berechtigung zur Entwicklung im Entwicklungssystem.

Die zweite Tabelle zeigt die Berechtigung zum Customizing im Entwicklungssystem.



01 (Anlegen)

02 (Ändern)

06 (Löschen) usw.

OBJTYPE(Objekttyp)

PROG

FUGR

TABL usw.



02 (Ändern)


<je nach Aufgabe, möglichst

kein Stern>

oder


02 (Ändern)

TABLE(Tabelle)

<je nach Aufgabe, möglichst

kein Stern>

145


9.4.3 Durchgeführte Reparaturen

Rufen Sie im Produktivsystem Transaktion SE16 auf, und lassen Sie sich Tabelle E070

anzeigen. Geben Sie in der Selektionsmaske der Tabelle im Feld Typ (TRFUNCTION) den

Wert »R« ein, und lassen Sie sich das Ergebnis anzeigen. Es werden alle Aufträge vom

Typ Reparatur angezeigt. Den Inhalt der Aufträge können Sie mit Transaktion SE01

oder dem Report RSWBO050 einsehen.

9.4.4 Dokumentation der Reparaturen

Lassen Sie sich zu den im vorangehenden Abschnitt ermittelten Aufträgen die Doku-

mentation aushändigen.



Transportsystem 1 Wurden im Produktivsystem Reparaturen durchge-

führt?

Reparaturen dürfen nur in Notfällen durchgeführt

werden.

Hier besteht das Risiko, dass Programmänderungen

direkt im Produktivsystem durchgeführt wurden und

somit das Freigabeverfahren umgangen wurde. Werden

über solche Änderungen rechnungslegungsrelevante

Tabellen geändert, kann dies gegen § 239 HGB (Radier-

verbot) verstoßen.



Transportsystem 2 Wurden diese Reparaturen dokumentiert?

Reparaturen müssen dokumentiert werden.

Hier besteht das Risiko, dass Programm- oder Tabellen-

änderungen inhaltlich nicht nachvollzogen werden

können.

146


9.4.5 Reparaturkennzeichen







Transportsystem 2 Wer ist berechtigt, Reparaturkennzeichen im Produktiv-

system zurückzusetzen?

Dieses Zugriffsrecht darf nur der Administration zuge-

ordnet werden.

Hier besteht das Risiko, dass durchgeführte Reparaturen

durch die Zurücknahme des Kennzeichens verschleiert

werden könnten.



02 (Ändern)


STRW


X

oder


02 (Ändern)

TABLE(Tabelle)

TADIR


X

147


9.4.6 Transportverzeichnis

Lassen Sie sich von einem Administrator die Berechtigungen des Transportverzeich-

nisses aushändigen (ls –liaR /trans > <Dateiname>). Die Berechtigungen sollten fol-

gendermaßen vergeben sein:

� Verzeichnis .../trans

– Besitzer: <sid>adm

– Gruppe: sapsys

– Rechte: 775 ( rwx rwx r–x )

� Unterverzeichnisse von .../trans

– Besitzer: <sid>adm

– Gruppe: sapsys

– Rechte: 770 ( rwx rwx --- )

9.4.7 Quality-Assurance-Genehmigungsverfahren



Transportsystem 2 Sind die Zugriffsrechte auf das Transportverzeichnis

gemäß SAP-Sicherheitsleitfaden eingestellt?

Die Zugriffsrechte müssen gemäß SAP-Sicherheitsleitfa-

den eingestellt sein.

Hier besteht das Risiko, dass Transportaufträge auf der

Betriebssystemebene manipuliert oder gelöscht werden

können.



Transportsystem 2 Ist das Quality-Assurance-Genehmigungsverfahren

gemäß den Unternehmensvorgaben eingerichtet?

Es muss unternehmensbezogen entschieden werden, ob

und wie das Verfahren einzusetzen ist.

Hier besteht das Risiko, dass Aufträge ohne Freigabever-

fahren in das Produktivsystem transportiert werden

können.

148


Rufen Sie in der Einstiegsmaske von Transaktion STMS den Menüpfad Übersicht •

Systeme auf. In der Systemübersicht rufen Sie den Menüpfad Springen • Transport-

domäne auf. Wechseln Sie hier auf die Registerkarte QA-Genehmigungsverfahren.

Die Konfiguration wird angezeigt.

9.4.8 Importe ins Produktivsystem







Transportsystem 2 Wer ist berechtigt, Importe ins Produktivsystem durch-

zuführen?

Nur die Basisadministration sollte dazu berechtigt sein,

Importe ins Produktivsystem durchzuführen. Entwick-

lern darf diese Berechtigung nicht zugeordnet werden.

Hier besteht das Risiko, dass durch eine fehlende Funkti-

onstrennung Entwicklungen ohne Freigabeverfahren in

das Produktivsystem importiert werden. Des Weiteren

besteht das Risiko, dass Aufträge, die nicht im Qualitäts-

sicherungssystem freigegeben wurden, trotzdem in das

Produktivsystem importiert werden.



STMS

STMS_IMPORT

STMS_QUEUES

<Reporting>

S_CTS_ADMI oder

S_CTS_SADMCTS_ADMFCT(Administrationsfunktion)

IMPS (Import einzelner Auf-

träge)

IMPA (Import aller Aufträge)

149


9.4.9 Notfallbenutzer

Lassen Sie sich das Notfallbenutzerkonzept aushändigen.

9.5 Eigenentwicklungen in ABAP

9.5.1 Daten aus dem Produktivsystem

Dies kann stichprobenartig überprüft werden. Überprüfen Sie im Entwicklungs- und

Testsystem den Inhalt z. B. folgender Tabellen mit Transaktion SE16:

� KNB1: Kundenstamm (Buchungskreis)

� KNC1: Kundenstamm (Verkehrszahlen)

� LFB1: Lieferantenstamm (Buchungskreis)

� LFC1: Lieferantenstamm (Verkehrszahlen)

� PA0001: Mitarbeiterstammdaten



Transportsystem 1 Existiert im Produktivsystem ein Notfallbenutzer für

Reparaturen?

Es muss ein Notfallbenutzerkonzept existieren.

Hier besteht das Risiko, dass es in Notfällen zu Zeitver-

zögerungen kommen kann, wenn kein Notfallbenutzer

existiert, oder dass Entwickler mit Entwicklerrechten im

Produktivsystem existieren.



Eigenentwicklungen 2 Befinden sich Originaldaten aus dem Produktivsystem

im Entwicklungs-/Testsystem?

Originaldaten dürfen nur übertragen werden, wenn sie

anonymisiert wurden.

Hier besteht das Risiko, dass im Entwicklungssystem auf

produktive Daten zugegriffen werden kann. Insbeson-

dere bei sensiblen Daten, wie z. B. Mitarbeiterdaten, ist

dies äußerst kritisch.

150


9.5.2 Befehl EXEC SQL

Rufen Sie Transaktion SA38 auf, und führen Sie den Report RS_ABAP_SOURCE_SCAN aus.

Geben Sie die folgenden Selektionskriterien ein:

� Programmname: Namenräume gemäß Abschnitt 9.5.2, »Befehl EXEC SQL«, im

Buch

� gesuchter String: EXEC SQL

� Includes auflösen: aktivieren

� Kommentarzeilen ignorieren: aktivieren

Führen Sie den Report aus. Als Ergebnis werden alle unternehmenseigenen Pro-

gramme angezeigt, in denen der Befehl EXEC SQL genutzt wird.

9.5.3 SELECT-Zusatz CLIENT SPECIFIED



Eigenentwicklungen 1 Wird in neu angelegten ABAP-Programmen der Befehl

EXEC SQL verwendet?

Generell sollte dieser Befehl nicht verwendet werden,

nur bei systemnahen Zugriffen auf die Datenbank, z. B.

für das Monitoring.

Hier besteht das Risiko, dass durch diese Programme

Tabellen direkt in der Datenbank geändert werden kön-

nen und damit die Sicherheitsmechanismen von SAP

umgangen werden.



Eigenentwicklungen 1 Wird der Zusatz CLIENT SPECIFIED zur Anweisung

SELECT in neu angelegten ABAP-Programmen verwen-

det?

Bei der Verwendung dieses Befehls müssen Sie genaues-

tens prüfen, welche Daten mandantenübergreifend

gelesen werden sollen.

Hier besteht das Risiko, dass über diese Programme ein

Zugriff auf Tabellen aus anderen Mandanten ermöglicht

wird, z. B. vom Mandanten 000 aus auf den Produktiv-

mandanten.

151





Buch

� gesuchter String: CLIENT SPECIFIED




gramme angezeigt, in denen der Befehl CLIENT SPECIFIED genutzt wird.

9.5.4 ENQUEUE-Bausteine




Buch

� gesuchter String: ENQUEUE




gramme angezeigt, in denen der Befehl ENQUEUE genutzt wird.



Eigenentwicklungen 1 Werden in neu angelegten Dialoganwendungen

ENQUEUE-Bausteine zur Sperrung von Daten genutzt?

Bevor Daten von einem Programm geändert werden

dürfen, müssen diese auf jeden Fall gesperrt sein.

Hier besteht das Risiko, dass durch fehlende Sperrungen

mehrere Benutzer gleichzeitig denselben Datensatz

bearbeiten können und dadurch Inkonsistenzen entste-

hen.

152


9.5.5 Funktion GENERATE SUBROUTINE POOL


Geben Sie folgende Selektionskriterien ein:


Buch

� gesuchter String: GENERATE SUBROUTINE POOL




gramme angezeigt, in denen der Befehl GENERATE SUBROUTINE POOL genutzt wird.

9.5.6 Berechtigungsprüfungen


Geben Sie folgende Selektionskriterien ein:



Eigenentwicklungen 1 Wird die Funktion GENERATE SUBROUTINE POOL in neu

angelegten ABAP-Programmen verwendet?

Die Funktion GENERATE SUBROUTINE POOL darf nicht ver-

wendet werden.

Hier besteht das Risiko, dass Quelltexte zur Laufzeit

generiert und damit die Sicherheitsmechanismen des

SAP-Systems umgangen werden können.



Eigenentwicklungen 1 Sind in neu angelegten ABAP-Programmen Berechti-

gungsprüfungen implementiert?

Alle Programme müssen über das Berechtigungskon-

zept geschützt werden.

Hier besteht das Risiko, dass ungeschützte Programme

von unberechtigten Benutzern ausgeführt werden kön-

nen.

153



Buch

� gesuchter String: AUTHORITY-CHECK




gramme angezeigt, in denen der Befehl AUTHORITY-CHECK genutzt wird. Stellen Sie das

Ergebnis der Liste aller unternehmenseigenen Reports gegenüber. Rufen Sie Trans-

aktion SE16 auf, und lassen Sie sich Tabelle TRDIR anzeigen. Geben Sie in der Selekti-

onsmaske der Tabelle im Feld Programmname (NAME) die kundeneigenen

Namensräume für ABAP-Programme über die Mehrfachselektion ein und im Feld

ProgTyp (SUBC) den Wert »1« (Ausführbares Programm). Lassen Sie sich das Ergebnis

anzeigen und gleichen Sie es mit dem Ergebnis des Reports RS_ABAP_SOURCE_SCAN ab.

9.5.7 Debugging



Selektionskriterien. Selektieren Sie die Registerkarte Berechtigungen, und geben Sie




Eigenentwicklungen 1 Wer besitzt das Zugriffsrecht, im Produktivsystem

ABAP-Programme zu debuggen, mit Replace-Möglich-

keit?

Dieses Zugriffsrecht darf im Produktivsystem nieman-

dem zugeordnet werden.

Hier besteht das Risiko, dass Daten über Hauptspei-

cheränderungen manipuliert werden können und damit

gegen § 239 HGB (Radierverbot) verstoßen wird.



02 (Ändern)

OBJTYPE(Objekttyp)

DEBUG

154


9.5.8 Änderung von Hauptspeicherinhalten

Rufen Sie das SysLog mit Transaktion SM21 auf. Lassen Sie die Felder Startdatum/

-zeit und bis Enddatum/-zeit leer. Tragen Sie im Feld Meldungs-ID die Meldungs-

nummer »A19« ein, und klicken Sie auf Ausführen ( ). Werden Meldungen ange-

zeigt, ist dort zu erkennen, in welchem Programm welcher Feldinhalt geändert

wurde (durch Doppelklick auf den entsprechenden Eintrag).

Wird das Security Audit Log zur Protokollierung des Debuggings eingesetzt, kann

auch dies zur Auswertung genutzt werden.

9.5.9 Versionshistorie

Rufen Sie Transaktion SA38 auf, und lassen Sie sich den Report RSTMSTPP anzeigen.

Geben Sie in der Selektionsmaske den Namen des Produktivsystems an, und führen



Eigenentwicklungen 1 Wurden in letzter Zeit im Produktivsystem im Debug-

Modus Hauptspeicherinhalte geändert?

Änderungen von Hauptspeicherinhalten im Debug-

Modus dürfen im Produktivsystem nicht vorgenommen

werden.

Hier besteht das Risiko, dass Daten im Änderungsmodus

manipuliert wurden.



Eigenentwicklungen 2 Wird durch den Import neuer Programmversionen eine

Versionshistorie im Produktivsystem erzeugt?

Alle Versionen von eigenen Programmen sind aufbe-

wahrungspflichtig (gemäß HGB 10 Jahre). Sie können

aber auch im Entwicklungssystem archiviert werden.


Programmversionen nicht archiviert werden.

155


Sie den Report aus. Der Parameter VERS_AT_IMP gibt an, ob Versionen geschrieben

werden:

� NEVER: Es werden keine Versionen erzeugt.

� ALWAYS: Es werden Versionen erzeugt.

9.5.10 Löschen der Versionshistorie

Standardmäßig sind die Reports RSVCAD00, RSVCAD03 und RSVCAD04 nicht durch Berech-

tigungsgruppen geschützt. Überprüfen Sie, ob die Reports durch eigene Berechti-

gungsgruppen geschützt wurden. Rufen Sie Transaktion SE16 auf, und lassen Sie sich

Tabelle TRDIR anzeigen. Geben Sie im Feld Programmname (NAME) über die Mehrfach-

selektion die Namen der beiden Reports ein. Im Feld SECU ist die Berechtigungs-

gruppe hinterlegt. Standardmäßig ist das Feld leer, da keine Gruppe zugeordnet ist.

Überprüfen Sie als Nächstes, wer diese Reports ausführen darf. Rufen Sie im Produk-

tivsystem Transaktion SUIM auf, und wählen Sie den Menüpfad Benutzer • Benutzer


Selektieren Sie die Registerkarte Berechtigungen, und geben Sie die Werte aus der fol-

genden Tabelle ein.



Eigenentwicklungen 1 Können die Reports zum Löschen von Versionen genutzt

werden?

Das Löschen der Versionshistorie ist nicht zulässig.

Hier besteht das Risiko, dass Versionen gelöscht werden

und damit zum einen gegen geltende Gesetze versto-

ßen wird und zum anderen keine Nachvollziehbarkeit

über die Programmänderungen gegeben ist.


S_PROGRAM P_ACTION(Benutzeraktion)

SUBMIT

(Ausführen)

P_GROUP(Berechtigungsgruppe)

<Berechtigungsgruppe gemäß

Tabelle TDDAT>

156

9.6 Transaktionen

9.6 Transaktionen

9.6.1 Pflegerechte



Selektionskriterien. Selektieren Sie die Registerkarte Berechtigungen, und geben Sie





Transaktionen 2 Wer besitzt die Berechtigung, Transaktionen anzulegen

oder zu ändern?

Nur Entwickler dürfen diese Berechtigung besitzen.

Hier besteht das Risiko, dass durch das Anlegen neuer

Transaktionen ein Zugriff auf Programme ermöglicht

wird, für die sonst keine Berechtigung vorhanden ist.



SE93


01 (Anlegen)

02 (Ändern)

06 (Löschen)

OBJTYPE(Objekttyp)

TRAN



Transaktionen 1 Wurden Transaktionen im Produktivsystem angelegt?

Transaktionen dürfen ausschließlich im Entwicklungs-

system angelegt werden.

Hier besteht das Risiko, dass neue Transaktionen unbe-

merkt im Produktivsystem angelegt wurden.

157


Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle TADIR anzeigen. In der

Selektionsmaske geben Sie im Feld Objekttyp (OBJECT) den Wert »TRAN« für Trans-

aktionen ein. Im Feld Objektname (OBJ_NAME) selektieren Sie über die Mehrfach-

selektion nach »Y*« und »Z*«. Im Ergebnis wird im Feld Verantwortlicher (AUTHOR)

der Benutzer angezeigt, der die Transaktion angelegt hat. Im Feld Originalsystem

(SRCSYSTEM) können Sie ablesen, in welchem System die Transaktion angelegt wurde.

9.6.3 Berechtigungen für Transaktionen

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle TSTC anzeigen. Lassen Sie

sich alle Transaktionen gemäß den unternehmenseigenen Namenskonventionen

anzeigen (Eintrag »Y*« oder »Z*« im Feld Transaktionscode TCODE). Öffnen Sie ein

zweites Fenster über den Menüpfad System • Neues GUI-Fenster. Rufen Sie in diesem

Fenster Transaktion SE16 auf, und lassen Sie sich Tabelle TSTCA anzeigen. Lassen Sie

sich alle Transaktionen gemäß den unternehmenseigenen Namenskonventionen

anzeigen (Eintrag »Y*« oder »Z*« im Feld Transaktionscode TCODE). Überprüfen Sie, ob

alle Transaktionen, die in Tabelle TSTC angezeigt werden, ebenfalls in TSTCA existieren

und ob ihnen ein Berechtigungsobjekt zugeordnet wurde.



Transaktionen 2 Sind die neuen Transaktionen durch Berechtigungsob-

jekte geschützt?

Transaktionen müssen generell durch Berechtigungsob-

jekte geschützt werden.

Hier besteht das Risiko, dass diese Transaktionen auf-

grund eines fehlenden Zugriffsschutzes von unberech-

tigten Benutzern ausgeführt werden können.

158

9.7 Berechtigungen zur Anwendungsentwicklung


Rufen Sie Transaktion SE13 auf. Tragen Sie Tabelle TSTC ein, und klicken Sie auf die

Schaltfläche Anzeigen. Der Eintrag Datenänderungen protokollieren muss aktiviert

sein. Wiederholen Sie diesen Schritt für die folgenden Tabellen:

� TSTCP: Parameterwerte zu Transaktionen

� TSTCA: den Transaktionen zugeordnete Berechtigungsobjekte

� TCDCOUPLES: Transaktionsberechtigung bei CALL TRANSACTION

9.7 Berechtigungen zur Anwendungsentwicklung

Dieser Abschnitt enthält keine Checklisten.



Transaktionen 1 Werden Änderungen an Transaktionen protokolliert?

Änderungen an Transaktionen müssen protokolliert

werden.

Hier besteht das Risiko, dass Parameter zu Transaktio-

nen geändert und dadurch andere Programme oder

Tabellen durch eine Transaktion aufgerufen werden.

159


zu Kapitel 10

10.1 Funktionsweise des Berechtigungskonzepts

10.1.1 Unternehmenseigene Berechtigungsobjekte

Rufen Sie Transaktion SUIM auf, und wählen Sie den Menüpfad Berechtigungs-

objekte • Berechtigungsobjekte nach komplexen Selektionsbedingungen. Tragen Sie

als Selektionskriterium zum Feld Berechtigungsobjekt über die Mehrfachselektion

die Werte »Y*« und »Z*« ein, falls vorhanden auch den Unternehmensnamensraum.

Im Ergebnis werden alle unternehmenseigene Berechtigungsobjekte aufgelistet.

10.1.2 SAP-Standardrollen



SAP-Berechtigungs-

konzept

2 Existieren unternehmenseigene Berechtigungsobjekte,

und sind diese dokumentiert?

Unternehmenseigene Berechtigungsobjekte müssen

ausführlich dokumentiert sein.

Hier besteht das Risiko, dass die Berechtigungsobjekte

durch fehlende Dokumentation falsch genutzt werden.



SAP-Berechtigungs-

konzept

2 Wurden SAP-Standardrollen Benutzern zugeordnet?

SAP-Standardrollen sollten nicht genutzt werden.

Hier besteht das Risiko, dass durch die Zuordnung von

SAP-Standardrollen zu umfangreiche Berechtigungen

zugeordnet werden.

161


Rufen Sie Transaktion SUIM auf, und wählen Sie den Menüpfad Rollen • Rollen nach

komplexen Selektionskriterien • Rollen nach komplexen Selektionskriterien. Geben

Sie im Feld Rolle den Wert »SAP*« ein. Markieren Sie im Bereich Selektion nach

Benutzerzuordnung den Punkt Mit gültiger Zuordnung von. Im Ergebnis werden alle

zugeordneten SAP-Standardrollen angezeigt.

10.1.3 Unternehmenseigene Rollen

Rufen Sie Transaktion SUIM auf, und wählen Sie den Menüpfad Rollen • Rollen nach

komplexen Selektionskriterien • Rollen nach komplexen Selektionskriterien. Geben

Sie im Feld Rolle die Namenskonvention für Ihre Rollen ein (z. B. »Z*«). Markieren Sie

im Bereich Selektion nach Benutzerzuordnung die Option Ohne Benutzerzuordnung.

Im Ergebnis werden alle unternehmenseigenen, nicht zugeordneten Rollen ange-

zeigt.

10.1.4 Einzel- und Sammelprofile



SAP-Berechtigungs-

konzept

3 Existieren unternehmenseigene, nicht zugeordnete Rol-

len?

Unternehmenseigene, nicht mehr benötigte Rollen soll-

ten gelöscht werden.

Hier besteht das Risiko, dass durch eine Vielzahl nicht

mehr genutzter Rollen das Rollenkonzept intransparent

wird.



SAP-Berechtigungs-

konzept

2 Wurden Einzel- oder Sammelprofile Benutzern zugeord-

net?

Bei der Nutzung eines Rollenkonzepts dürfen keine Ein-

zel- oder Sammelprofile zugeordnet werden.

Hier besteht das Risiko, dass das Rollenkonzept durch

die Zuordnung umgangen werden kann.

162

10.2 Konzepte zum SAP-Berechtigungswesen

Für diese Fragestellung müssen die Tabellen UST04 (Benutzer mit Profilen) und USR10

(Profileigenschaften, u. a. der Profiltyp) über den Profilnamen miteinander ver-

knüpft werden. Dies kann z. B. mit dem QuickViewer (Transaktion SQVI) erfolgen

oder mit einem externen Programm (z. B. Microsoft Access, IDEA, ACL). Als Selekti-

onskriterium muss das Feld TYP aus Tabelle USR10 auf Einzel- und Sammelprofil ein-

gegrenzt werden (Werte »S« und »C«). In Abschnitt 1.7 ist beschrieben, wie Sie den

QuickViewer für diese Fragestellung nutzen können.




Konzepte zu SAP-

Berechtigungen

1 Existiert ein Dateneigentümerkonzept zum SAP-Berech-

tigungswesen?

Es muss ein Dateneigentümerkonzept zum SAP-Berech-

tigungswesen existieren.

Hier besteht das Risiko, dass die Verantwortlichkeiten

durch ein fehlendes Dateneigentümerkonzept für die

Beantragung von Rollen und Rollenzuordnungen nicht

geregelt sind und dadurch Berechtigungen falsch bean-

tragt werden.

Konzepte zu SAP-

Berechtigungen

2 Entspricht das Dateneigentümerkonzept den Anforde-

rungen hinsichtlich Verantwortlichkeiten und Aufga-

ben?

Das Dateneigentümerkonzept zum SAP-Berechtigungs-

wesen muss hinsichtlich Verantwortlichkeiten und Auf-

gaben detailliert ausgeprägt sein.

Hier besteht das Risiko, dass die Verantwortlichkeiten

durch eine falsche Ausprägung des Dateneigentümer-

konzepts für die Beantragung von Rollen und Rollenzu-

ordnungen nicht geregelt sind und dadurch

Berechtigungen falsch beantragt werden.

163


Konzepte zu SAP-

Berechtigungen

1 Existiert ein Antragsverfahren zum SAP-Berechtigungs-

wesen?

Es muss ein Antragsverfahren zum SAP-Berechtigungs-

wesen existieren.

Hier besteht das Risiko, dass durch ein fehlendes

Antragsverfahren Berechtigungen ohne Genehmigung

und Wissen der Verantwortlichen zugeteilt werden. Des

Weiteren besteht das Risiko, dass Berechtigungen nicht

entzogen werden, wenn ein Benutzer sie nicht mehr

benötigt.

Konzepte zu SAP-

Berechtigungen

2 Existieren benutzerfreundliche Formulare für die

Berechtigungsanträge?

Im Rahmen des Antragsverfahrens müssen benutzer-

freundliche Formulare verwendet werden.

Hier besteht das Risiko, dass Berechtigungen durch feh-

lende Formulare falsch beantragt oder umgesetzt wer-

den.

Konzepte zu SAP-

Berechtigungen

1 Existiert ein Konzept für übergreifende Berechtigun-

gen?

Es muss ein Konzept für die übergreifenden Berechti-

gungen existieren.

Hier besteht das Risiko, dass durch übergreifende

Berechtigungen ein Zugriff auf nicht berechtigte Daten

möglich ist.

Konzepte zu SAP-

Berechtigungen

1 Existiert ein internes Kontrollsystem zum SAP-Berechti-

gungswesen?

Es muss ein internes Kontrollsystem zum SAP-Berechti-

gungswesen existieren.

Hier besteht das Risiko, dass durch ein fehlendes inter-

nes Kontrollsystem Berechtigungen für kritische

Geschäftsprozesse ohne Genehmigung und Wissen der

Verantwortlichen zugeordnet werden und dass diese

Zuordnungen nicht zeitnah aufgedeckt werden.



164


Konzepte zu SAP-

Berechtigungen

1 Existieren explizite Namenskonventionen für Rollen?

Es müssen explizite Namenskonventionen für Rollen

existieren.

Hier besteht das Risiko, dass das Berechtigungskonzept

durch fehlende Namenskonventionen intransparent

wird.

Konzepte zu SAP-

Berechtigungen

2 Existieren Vorgaben für die technische Ausprägung der

Rollen?

Es müssen Vorgaben für die technische Ausprägung der

Rollen existieren.

Hier besteht das Risiko, dass Rollen durch fehlende Vor-

gaben falsch ausgeprägt werden.

Konzepte zu SAP-

Berechtigungen

2 Ist das verwendete Rollenkonzept festgelegt?

Das verwendete Rollenkonzept muss definiert werden.

Hier besteht das Risiko, dass verschiedene Rollenkon-

zepte miteinander vermischt werden und dass das

Berechtigungskonzept dadurch intransparent wird.

Konzepte zu SAP-

Berechtigungen

2 Existieren komponenten-/systemspezifische Teilkon-

zepte?

Für bestimmte Komponenten/-systeme müssen spezifi-

sche Teilkonzepte für die Berechtigungen erstellt wer-

den.

Hier besteht das Risiko, dass das Berechtigungskonzept

für diese Komponenten/-systeme nicht definiert ist und

es dadurch zu Fehlern kommen kann.

Konzepte zu SAP-

Berechtigungen

1 Existieren Vorgaben für den berechtigungsseitigen

Schutz von Eigenentwicklungen?

Es müssen Vorgaben für den berechtigungsseitigen

Schutz von Eigenentwicklungen existieren.

Hier besteht das Risiko, dass Eigenentwicklungen

berechtigungsseitig nicht ausreichend geschützt sind.



165


Lassen Sie sich diese Dokumentationen zur Prüfung aushändigen.

10.3 Customizing zum Berechtigungskonzept

10.3.1 Berechtigungsprüfung bei CALL TRANSACTION

Rufen Sie Transaktion RSPFPAR auf. Tragen Sie als Selektionskriterium den Parame-

ter auth/check/calltransaction ein, und führen Sie den Report aus. Der Wert des

Parameters muss »1« oder »2« sein.

Konzepte zu SAP-

Berechtigungen

2 Existiert ein Sicherheitskonzept zum Berechtigungskon-

zept?

Es muss ein Sicherheitskonzept zum Berechtigungskon-

zept existieren.

Hier besteht das Risiko, dass Berechtigungsprüfungen

durch eine falsche Konfiguration fehlerhaft durchge-

führt werden.



Customizing SAP-

Berechtigungskon-

zept

2 Werden S_TCODE-Berechtigungen beim Aufruf einer

Transaktion durch CALL TRANSACTION geprüft?

Bei CALL TRANSACTION-Aufrufen muss die S_TCODE-

Berechtigung geprüft werden.

Hier besteht das Risiko, dass unberechtigte Funktionen

ausgeführt werden können.



166

10.3 Customizing zum Berechtigungskonzept

10.3.2 Tabelle TCDCOUPLES

Rufen Sie Transaktion CODE_SCANNER auf, und geben Sie im Feld Pakete alle Pakete

an, die für Eigenentwicklungen genutzt werden (in der Regel die Y*-/Z*-Pakete).

Geben Sie im Feld Suchstring 1 den String CALL TRANSACTION ein. Markieren Sie die

Option Kommentarzeilen ignorieren. Im Ergebnis werden alle CALL TRANSACTION-Auf-

rufe mit den aufgerufenen Transaktionen angezeigt.

Rufen Sie im zweiten Schritt Transaktion SE16 auf, und lassen Sie sich Tabelle

TCDCOUPLES anzeigen. Überprüfen Sie, ob im Feld gerufene Transaktion zu den eige-

nen Transaktionen die Transaktionen hinterlegt sind, die über CALL TRANSACTION auf-

gerufen werden.

10.3.3 Deaktivierung von Berechtigungsobjekten


ter auth/object_disabling_active ein, und führen Sie den Report aus. Der Wert des

Parameters muss »N« sein.



Customizing SAP-

Berechtigungskon-

zept

2 Wurde für Eigenentwicklungen, bei denen CALL

TRANSACTION genutzt wird, Tabelle TCDCOUPLES ent-

sprechend gepflegt?

Für Eigenentwicklungen, in denen der Befehl CALL

TRANSACTION genutzt wird, muss Tabelle TCDCOUPLES

entsprechend gepflegt werden.

Hier besteht das Risiko, dass unberechtigte Funktionen

ausgeführt werden können.



Customizing SAP-

Berechtigungskon-

zept

1 Können Berechtigungsobjekte im Produktivsystem

deaktiviert werden?

Berechtigungsobjekte dürfen im Produktivsystem nicht

deaktiviert werden.

Hier besteht das Risiko, dass Berechtigungsprüfungen

deaktiviert und dadurch manipuliert werden können.

167


10.3.4 RFC-Berechtigungen


ter auth/rfc_authority_check ein, und führen Sie den Report aus. Der Wert des Para-

meters muss »>=1« sein.

10.3.5 Vorgaben zur Nutzung der Menüs

Lassen Sie sich die Vorgaben aushändigen und gleichen Sie die Umsetzung mit den

folgenden Tabellen ab:

� SSM_CUST: systemweite Einstellungen für alle Benutzer

� USERS_SSM: benutzerspezifische Einstellungen



Customizing SAP-

Berechtigungs-

konzept

1 Werden beim Aufruf von Funktionsbausteinen RFC-

Berechtigungen geprüft?

Beim Aufruf von Funktionsbausteinen sind grundsätz-

lich die RFC-Berechtigungen zu prüfen.


Berechtigungen aufgerufen werden können.



Customizing SAP-

Berechtigungs-

konzept

3 Existieren Vorgaben zur Nutzung der Menüs, und sind

diese im System umgesetzt?

Die Nutzung der verschiedenen Menüvarianten sollte

festgelegt sein.

Hier besteht das Risiko, dass Benutzern falsche Menü-

strukturen angezeigt werden.

168

10.4 Prüfung von Zugriffsrechten

10.3.6 Berechtigungsobjekt S_RFCACL

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle PRGN_CUST anzeigen. Über-

prüfen Sie, ob der Eintrag »ADD_S_RFCACL« existiert. Falls er existiert, darf er nicht

den Wert »YES« enthalten. Existiert dieser nicht, steht er auf dem Wert »NO«.

10.3.7 Referenzbenutzer

Rufen Sie Transaktion SE16 auf, und lassen Sie sich Tabelle PRGN_CUST anzeigen. Der

Eintrag »REF_USER_CHECK« muss existieren und den Wert »E« enthalten. Existiert

dieser nicht, können alle Benutzertypen als Referenz zugeordnet werden.

10.4 Prüfung von Zugriffsrechten

Die Buchabschnitte 10.4, »Prüfung von Zugriffsrechten, 10.5, »Trace von Benutzerbe-

rechtigungen«, und 10.6, »Berechtigungen für Prüfer«, enthalten keine Checklisten.



Customizing SAP-

Berechtigungskon-

zept

1 Wird das Berechtigungsobjekt S_RFCACL automatisch

mit einer vollen Berechtigung in SAP_ALL aufgenom-

men?

Das Berechtigungsobjekt S_RFCACL darf nicht in das

Profil SAP_ALL aufgenommen werden.

Hier besteht das Risiko, dass von anderen Systemen aus

ein uneingeschränkter Zugriff möglich ist.



Customizing

SAP-Berechtigungs-

konzept

2 Können außer dem Benutzertyp Referenz auch andere

Benutzer als Referenzbenutzer zugeordnet werden?

Es dürfen nur Benutzer vom Typ Referenz als Referenz-

benutzer zugeordnet werden.

Hier besteht das Risiko, dass Benutzer Berechtigungen

von sehr hoch berechtigten Benutzern erhalten können.

169


zu Kapitel 11

Kapitel 11 des Buches, »Praktische Prüfung von Berechtigungen«, enthält keine

Checklisten.

171

Checklisten zu Kapitel 12

12.1 Aufbau eines SAP-HANA-Systems

Abschnitt 12.1 des Buches, »Aufbau eines SAP-HANA-Systems«, enthält keine Check-

listen.

12.2 Sicherheit auf Unix-Ebene

12.2.1 Betriebssystembenutzer

Lassen Sie sich die Datei /etc/passwd (cat /etc/passwd) anzeigen. Überprüfen Sie, ob

nur die Administratoren dort als Benutzerkonten existieren sowie die HANA-Benut-

zer und die Standardbenutzer des eingesetzten Unix-Derivates.

12.2.2 Benutzer root



Unix-Sicherheit 1 Existieren nur die erforderlichen Benutzer im Betriebssys-

tem?

Es dürfen nur die Standardbenutzer sowie die Betriebssys-

temadministratoren existieren.

Hier besteht das Risiko, dass unberechtigte Zugriffe auf die

Datenbankinstallation möglich sind.



Unix-Sicherheit 1 Ist der Benutzer root gegen Anmeldungen gesperrt?

Der Benutzer root muss gegen Anmeldungen gesperrt sein

und darf nur über den Befehl su/sudo genutzt werden.

Hier besteht das Risiko, dass unberechtigte Anmeldungen

mit dem Benutzer root erfolgen.

173

12 Checklisten zu Kapitel 12

Lassen Sie sich die Datei /etc/ssh/sshd_config (cat /etc/ssh/sshd_config) anzeigen.

Prüfen Sie, ob der Parameter PermitRootLogin auf den Wert »YES« gesetzt ist.

12.2.3 Benutzer <sid>adm

Lassen Sie sich die Datei /etc/ssh/sshd_config (cat /etc/ssh/sshd_config) anzeigen.

Prüfen Sie, ob der Benutzer <sid>adm dort zum Parameter DenyUsers gesetzt ist:

DenyUsers <sid>adm

12.2.4 SAP-HANA-Installation

Prüfen Sie, ob die Berechtigungen für die Verzeichnisse /usr/sap und /opt/hana

gemäß SAP-Sicherheitsleitfaden vergeben sind:

� Welchen Verzeichnissen unterhalb des Verzeichnisses /usr/sap sind Schreib-

rechte für die Gruppe zugeordnet?

find /usr/sap/ /opt/hana/ -type d -perm -g+w -exec ls -ld {} \;



Unix-Sicherheit 1 Ist der Benutzer <sid>adm gegen Anmeldungen gesperrt?

Der Benutzer <sid>adm muss gegen Anmeldungen gesperrt

sein.

Hier besteht das Risiko, dass unberechtigte Anmeldungen

mit dem Benutzer <sid>adm erfolgen.



Unix-Sicherheit 1 Sind die Berechtigungen zum Zugriff auf die SAP-HANA-

Installation gemäß den Vorgaben vergeben?

Die Standardberechtigungen zum Zugriff auf die SAP-

HANA-Installation dürfen nicht geändert werden.

Hier besteht das Risiko, dass unberechtigte Zugriffe auf die

Datenbankinstallation möglich sind.

174

12.3 SAP-HANA-Systemsicherheit

� Welchen Verzeichnissen unterhalb des Verzeichnisses /usr/sap sind Schreib-

rechte für everyone zugeordnet?

find /usr/sap/ /opt/hana/ -type d -perm -o+w -exec ls -ld {} \;

� Welchen Verzeichnissen unter /usr/sap sind Leserechte für everyone zugeordnet?

find /usr/sap/ /opt/hana/ -type d -perm -o+r -exec ls -ld {} \;

� Welchen Dateien unter /usr/sap sind Schreibrechte für die Gruppe zugeordnet?

find /usr/sap/ /opt/hana/ -type f -perm -g+w -exec ls -la {} \;

� Welchen Dateien unter /usr/sap sind Schreibrechte für everyone zugeordnet?

find /usr/sap/ /opt/hana/ -type f -perm -o+w -exec ls -la {} \;

� Welchen Dateien unter /usr/sap sind Lese-/Ausführungsrechte für everyone zuge-

ordnet?

find /usr/sap/ /opt/hana/ -type f -perm -o+r+x -exec ls -la {} \;

� Auf welche Verzeichnisse/Dateien hat nur der Besitzer Zugriff?

find / -type f -perm u=r+w+x -exec ls -ld {} \; 2>/dev/null

� Welche Verzeichnisse/Dateien unter /usr/sap gehören nicht <sid>adm?

find /usr/sap /opt/hana/ ! -user <sid>adm -exec ls -ld {} \;

� Welche Verzeichnisse/Dateien unter /usr/sap gehören nicht der Gruppe sapsys?

find /usr/sap /opt/hana/ ! -group sapsys -exec ls -ld {} \;


12.3.1 Multitenant-Systeme

Wenn sich Datensätze in Tabelle M_TENANTS befinden, handelt es sich um ein Multi-

tenant-System. Dies können Sie wie folgt prüfen:

SELECT * FROM M_TENANTS



SAP-HANA-Sys-

temsicherheit

3 Handelt es sich um ein Multitenant-System?

Informativer Punkt für nachfolgende Prüfungen.

175


12.3.2 Tenantübergreifende Zugriffe

Prüfen Sie, ob der Parameter cross_database_access/enabled den Wert »FALSE« ent-

hält. In diesem Fall sind tenantübergreifende Zugriffe nicht aktiviert:

SELECT * FROM M_INIFILE_CONTENTS WHERE SECTION = 'cross_database_access'AND FILE_NAME = 'global.ini'

12.3.3 Remote-Benutzer

Prüfen Sie, ob Benutzern Remote-User zugeordnet wurden:

SELECT USER_NAME, HAS_REMOTE_USERS FROM USERSWHERE HAS_REMOTE_USERS = 'TRUE'



SAP-HANA-Sys-

temsicherheit

1 Falls es sich um ein Multitenant-System handelt:

Ist der tenantübergreifende Zugriff aktiviert?

Tenantübergreifende Zugriffe müssen im Betriebskonzept

beschrieben sein.


Daten möglich sind.



SAP-HANA-Sys-

temsicherheit


Welche Benutzer haben einen Remote-Zugriff in einer

Multi-Mandant-Datenbank?

Remote-Benutzer müssen im Berechtigungskonzept

beschrieben sein.



176


Prüfen Sie, welche Benutzer zugeordnet sind:

SELECT * FROM REMOTE_USERS

12.3.4 Persistenter Speicher

Prüfen Sie, ob die persistenten Daten verschlüsselt werden:

SELECT * FROM M_PERSISTENCE_ENCRYPTION_STATUS

Das Feld ENCRYPTION_ACTIVE muss den Wert »TRUE« enthalten.

12.3.5 Redo Logs



SAP-HANA-Sys-

temsicherheit


Welche Remote-Benutzer sind den Benutzern zugeordnet?

Remote-Benutzerzuordnungen müssen im Berechtigungs-

konzept beschrieben sein.





SAP-HANA-Sys-

temsicherheit

1 Sind die Daten des persistenten Speichers in SAP HANA auf

der Betriebssystemebene verschlüsselt?

Die persistenten Daten müssen verschlüsselt werden.

Hier besteht das Risiko, dass vom Betriebssystem aus auf

sensible Daten zugegriffen werden kann.



SAP-HANA-Sys-

temsicherheit

1 Sind die Daten der Redo Logs in SAP HANA auf der Betriebs-

systemebene verschlüsselt?

Die Redo Logs müssen verschlüsselt werden.

Hier besteht das Risiko, dass vom Betriebssystem aus auf

sensible Daten zugegriffen werden kann.

177


Prüfen Sie, ob die persistenten Daten verschlüsselt werden:

SELECT * FROM M_ENCRYPTION_OVERVIEW WHERE SCOPE = 'LOG'

Das Feld IS_ENCRYPTION_ACTIVE muss den Wert »TRUE« enthalten.

12.3.6 Root und Master Keys

Prüfen Sie, ob die Schlüssel geändert wurden:

SELECT * FROM ENCRYPTION_ROOT_KEYS

Das Feld CREATE_TIMESTAMP enthält das Datum der Änderung.

12.3.7 Datenübertragung

Prüfung Sie die Einstellungen zur verschlüsselten Kommunikation:

SELECT * FROM M_INIFILE_CONTENTSWHERE SECTION='communication' AND FILE_NAME='global.ini'



SAP-HANA-Sys-

temsicherheit

2 Wurden die Root Keys und die Master Keys nach der System-

installation geändert?

Die Root Keys und Master Keys sollten nach der Installation

geändert werden, insbesondere nach der Installation durch

einen Dienstleister.

Hier besteht das Risiko, dass die Schlüssel außerhalb des

Unternehmens bekannt sind.



SAP-HANA-Sys-

temsicherheit

1 Werden interne und externe Datenübertragungen ver-

schlüsselt?

Verbindungen zur SAP-HANA-Datenbank sollten grundsätz-

lich verschlüsselt werden.

Hier besteht das Risiko, dass der Datenverkehr auf unver-

schlüsselten Verbindungen abgehört werden kann.

178


Prüfen Sie die folgenden Parameter:

� sslEnforce: gibt, an, ob nur verschlüsselte Datenbankverbindungen akzeptiert

werden

� sslCryptoProvider: gibt den Crypto-Provider an.

� sslCreateSelfSignedCertificate: lässt von selbst signierte Zertifikate zu.

12.3.8 Verbindungen

Prüfen Sie, ob die Verbindungen verschlüsselt sind:

SELECT * FROM M_CONNECTIONS

Über das Feld IS_ENCRYPTED können Sie prüfen, ob die Verbindung verschlüsselt

(»TRUE«) oder unverschlüsselt (»FALSE«) ist.

12.3.9 Schnittstellen

Prüfen Sie wie folgt, welche Verbindungen existieren:

SELECT * FROM M_REMOTE_CONNECTIONS



SAP-HANA-Sys-

temsicherheit

1 Sind die aktiven (und ruhenden) Verbindungen verschlüs-

selt?

Verbindungen zur SAP-HANA-Datenbank sollten grundsätz-

lich verschlüsselt werden.

Hier besteht das Risiko, dass der Datenverkehr auf unver-

schlüsselten Verbindungen abgehört werden kann.



SAP-HANA-Sys-

temsicherheit

2 Welche Schnittstellen existieren zu anderen Systemen?

Es dürfen nur Schnittstellen gemäß der Dokumentation vor-

handen sein.

Hier besteht das Risiko, dass durch ungesicherte Verbindun-

gen auf Daten zugegriffen werden kann.

179


12.4 Die Anmeldesicherheit

12.4.1 Authentifizierung

Prüfen Sie, welche Authentifizierungsmechanismen mit dem Parameter authentica-

tion_methods aktiviert wurden:

SELECT * FROM M_INIFILE_CONTENTSWHERE FILE_NAME = 'global.ini' AND SECTION = 'authentication'

12.4.2 Kerberos-ID

Prüfen Sie diese Fragestellung mit der folgenden SQL-Anweisung:

SELECT * FROM USERS WHERE EXTERNAL_IDENTITY IN (SELECT EXTERNAL_IDENTITY FROM USERSWHERE EXTERNAL_IDENTITY IS NOT NULLGROUP BY EXTERNAL_IDENTITYHAVING COUNT(*)>1)



Anmeldesicher-

heit

1 Sind nur die gemäß Unternehmensrichtlinie zulässigen

Authentifizierungsmechanismen aktiviert?

Nicht genutzte Authentifizierungsmechanismen sollten

deaktiviert werden.

Hier besteht das Risiko, dass Benutzer unberechtigt Zugriff

auf die Datenbank erhalten.



Anmeldesicher-

heit

1 Gibt es unterschiedliche Benutzer mit derselben External ID

(Kerberos-ID)?

Die Kerberos-ID ist eindeutig; daher darf es keine zwei

Benutzerkonten mit derselben Kerberos-ID geben.

Hier besteht das Risiko, dass eine falsche Kerberos-ID mit

den Benutzerkonten genutzt werden kann.

180

12.4 Die Anmeldesicherheit

12.4.3 Anmeldeparameter

Die Anmeldeparameter lassen Sie sich mit der folgenden SQL-Anweisung anzeigen:

SELECT * FROM M_PASSWORD_POLICY

12.4.4 Benutzergruppen

Die gruppenspezifischen Anmeldeparameter lassen Sie sich mit der folgenden SQL-

Anweisung anzeigen:

SELECT * FROM USERGROUP_PARAMETERS



Anmeldesicher-

heit

1 Sind die Anmeldeparameter gemäß den Unternehmens-

richtlinien eingestellt?

Die Anmeldeparameter müssen gemäß den Vorgaben und

Sicherheitsrichtlinien eingestellt sein.





Anmeldesicher-

heit

1 Wurden Anmeldeparameter individuell für Benutzergrup-

pen eingerichtet, und entsprechen diese den Vorgaben?

Die Anmeldeparameter müssen gemäß den Vorgaben und

Sicherheitsrichtlinien auch individuell für Benutzergruppen

eingestellt sein.



181


12.4.5 Verbotene Kennwörter


SELECT * FROM _SYS_SECURITY._SYS_PASSWORD_BLACKLIST

12.5 Benutzerverwaltung

12.5.1 Benutzer SYSTEM

Prüfen Sie die Verfahrensanweisung hinsichtlich der Absicherung. Gemäß dem SAP

HANA Security Guide von SAP soll der Benutzer deaktiviert und nicht im Tagesge-

schäft genutzt werden.



Anmeldesicher-

heit

3 Sind die verbotenen Kennwörter gemäß den Unterneh-

mensrichtlinien hinterlegt?

Unzulässige Kennwörter (Firmenname usw.) müssen in

Tabelle _SYS_SECURITY._SYS_PASSWORD_BLACKLIST ein-

getragen sein.


nutzen, die leicht zu hacken sind.



Benutzerverwal-

tung

1 Existiert eine Verfahrensanweisung zur Nutzung des Benut-

zers SYSTEM?

Es muss festgelegt werden, wie der Benutzer SYSTEM abzu-

sichern ist.

Hier besteht das Risiko, dass der Benutzer SYSTEM anonym

für Anmeldungen genutzt werden kann.

182



SELECT USER_NAME, USER_DEACTIVATEDFROM USERSWHERE USER_NAME = 'SYSTEM'

Der Inhalt des Feldes USER_DEACTIVATED hat die folgende Bedeutung:

� TRUE: Benutzer ist deaktiviert

� FALSE: Benutzer ist nicht deaktiviert


SELECT * FROM M_PASSWORD_POLICYWHERE PROPERTY = 'password_lock_for_system_user'

Der Parameter muss den Wert »TRUE« enthalten.



Benutzerverwal-

tung

1 Ist der Benutzer SYSTEM deaktiviert?

Gemäß SAP-Sicherheitsleitfaden muss der Benutzer SYSTEM

deaktiviert werden.





Benutzerverwal-

tung

1 Wird der Benutzer SYSTEM durch Falschanmeldungen deak-

tiviert?

Der Parameter password_lock_for_system_user muss auf

den Wert »TRUE« gesetzt werden, um Brute-Force-Attacken

zu verhindern.

Hier besteht das Risiko, dass das Kennwort des Benutzers

SYSTEM durch Brute-Force-Attacken gehackt werden kann.

183



SELECT USER_NAME, LAST_SUCCESSFUL_CONNECT FROM USERSWHERE USER_NAME = 'SYSTEM'

Das Feld LAST_SUCCESSFUL_CONNECT enthält das letzte Anmeldedatum.

12.5.2 Restricted User


SELECT USER_NAME, LAST_SUCCESSFUL_CONNECT, IS_RESTRICTEDFROM USERS

Prüfen Sie, ob die für SAP-HANA-XS-Anwendungen eingerichteten Benutzerkonten

im Feld IS_RESTRICTED den Wert »TRUE« enthalten.



Benutzerverwal-

tung

2 Wann wurde der Benutzer SYSTEM zuletzt eingesetzt?

Die Nutzung des Benutzers SYSTEM muss dokumentiert wer-

den.





Benutzerverwal-

tung

1 Werden für SAP-HANA-XS-Anwendungen ausschließlich

Restricted Users genutzt?

Für SAP-HANA-XS-Anwendungen müssen Restricted Users

genutzt werden.

Hier besteht das Risiko, dass die Benutzer sich per ODBC/

JDBC direkt an der SAP-HANA-Datenbank anmelden können.

184


12.5.3 Abgelaufene Benutzerkonten


SELECT USER_NAME, VALID_UNTIL, IS_RESTRICTED FROM USERSWHERE VALID_UNTIL < CURRENT_DATE

12.5.4 Initialkennwörter


SELECT USER_NAME, ADMIN_GIVEN_PASSWORD, IS_RESTRICTEDFROM USERSWHERE ADMIN_GIVEN_PASSWORD = 'TRUE'



Benutzerverwal-

tung

3 Existieren abgelaufene Benutzerkonten?

Es sollten keine abgelaufenen Benutzer existieren.

Hier besteht das Risiko, dass diese Benutzer jederzeit mit

ihren Zugriffsrechten und einem neuen Kennwort wieder

aktiviert und genutzt werden können.



Benutzerverwal-

tung

2 Existieren Benutzer mit Initialkennwort?

Es dürfen nur wenige oder gar keine Benutzer existieren, die

noch ein Initialkennwort besitzen.

Hier besteht das Risiko, dass Anmeldungen mit diesen

Benutzern mit einem trivialen Kennwort möglich sind.

185




SELECT * FROM INVALID_CONNECT_ATTEMPTS

12.5.6 Benutzergruppen

Lassen Sie sich Tabelle USERS anzeigen, und prüfen Sie die Gruppenzuordnung der

Benutzer im Feld USERGROUP_NAME:

SELECT * FROM USERS



Benutzerverwal-

tung

2 Liegen für Benutzer viele fehlgeschlagene Anmeldeversuche

vor?

Falschanmeldungen von Benutzern sollten überwacht wer-

den.

Hier besteht das Risiko, dass Eindringversuche unter dieser

Benutzerkennung stattgefunden haben.



Benutzerverwal-

tung

2 Sind die Benutzer den korrekten Benutzergruppen zugeord-

net?

Wird ein Gruppenkonzept sowie eventuell eine dezentrale

Benutzerverwaltung angewandt, müssen die Benutzer den

jeweils korrekten Gruppen zugeordnet sein.

Hier besteht das Risiko, dass Benutzer von einem falschen

Personenkreis gepflegt werden können.

186

12.6 Berechtigungen in SAP HANA

12.6 Berechtigungen in SAP HANA

12.6.1 Berechtigungskonzept

Prüfen Sie das schriftliche Berechtigungskonzept für die SAP-HANA-Berechtigungen.

12.6.2 Internes Kontrollsystem

Prüfen Sie, ob ein internes Kontrollsystem existiert.



SAP-HANA-

Berechtigungs-

konzept

1 Existiert ein Berechtigungskonzept für die SAP-HANA-

Datenbank?

Es muss ein Berechtigungskonzept für die SAP-HANA-

Datenbank erstellt werden, da sie auch als Applikation anzu-

sehen ist, nicht als reine Datenbank.

Hier besteht das Risiko, dass ohne definiertes Konzept

Zugriffe und Berechtigungen intransparent vergeben wer-

den und dadurch unberechtigte Zugriffe möglich sind.



SAP-HANA-

Berechtigungs-

konzept

1 Existiert ein internes Kontrollsystem für die Berechtigungen

der SAP-HANA-Datenbank?

Es muss ein internes Kontrollsystem für die SAP-HANA-

Berechtigungen definiert werden.

Hier besteht das Risiko, dass systemkritische Berechtigun-

gen aufgrund fehlender Vorgaben vergeben werden.

187


12.6.3 System Privileges


SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE in ('ADAPTER ADMIN', 'AGENT ADMIN', 'BACKUP ADMIN','BACKUP OPERATOR', 'CERTIFICATE ADMIN', 'CREDENTIAL ADMIN', 'ENCRYPTIONROOT KEY ADMIN', 'EXTENDED STORAGE ADMIN', 'INIFILE ADMIN', 'LICENSE ADMIN','SAVEPOINT ADMIN', 'SERVICE ADMIN', 'SESSION ADMIN', 'SSL ADMIN', 'TENANTADMIN', 'TRUST ADMIN', 'VERSION ADMIN', 'RESOURCE ADMIN', 'TABLE ADMIN','AUDIT ADMIN', 'AUDIT OPERATOR', 'OPTIMIZER ADMIN', 'CREATE REMOTE SOURCE','LOG ADMIN', 'MONITOR ADMIN')AND OBJECT_TYPE = 'SYSTEMPRIVILEGE'

12.6.4 Direkte Zuordnung von Privileges




SAP-HANA-

Berechtigungs-

konzept

1 Sind System Privileges nur der Administration zugeordnet?

System Privileges dürfen (mit wenigen Ausnahmen, z. B

CATALOG READ) nur der Administration zugeordnet werden.

Hier besteht das Risiko, dass kritische Systemberechtigun-

gen außerhalb der Administration eingesetzt werden.



SAP-HANA-

Berechtigungs-

konzept

2 Wurden Privileges Benutzern direkt zugeordnet?

Berechtigungen müssen den Benutzern über Rollen zuge-

ordnet werden. Eine direkte Zuordnung sollte im Berechti-

gungskonzept ausgeschlossen werden.

Hier besteht das Risiko der Intransparenz des Berechti-

gungskonzepts.

188

12.7 Rollen in SAP HANA

SELECT * FROM GRANTED_PRIVILEGESWHERE GRANTEE_TYPE = 'USER' ANDGRANTEE NOT IN ('SYSTEM', 'SYS') AND GRANTEE NOT LIKE '_SYS%' AND(SCHEMA_NAME Is Null OR GRANTEE <> SCHEMA_NAME)ORDER BY GRANTEE, OBJECT_TYPE


12.7.1 Rollenkonzept

Prüfen Sie das schriftliche Berechtigungskonzept für die SAP-HANA-Berechtigungen

hinsichtlich der Pflege von Rollen.

12.7.2 Pflegerechte

Da die Pflege der Repository-Rollen im Rahmen der Entwicklung stattfindet, sind die

Entwicklerberechtigungen zu prüfen. Prüfen Sie die nachfolgende Berechtigung im

Entwicklungssystem, um festzustellen, wer Repository-Rollen pflegen darf. Prüfen



SAP-HANA-

Rollen

1 Existiert ein Konzept zur Rollenpflege?

Es muss ein Konzept zur Rollenpflege für die SAP-HANA-

Datenbank erstellt werden, da sie auch als Applikation anzu-

sehen ist, nicht als reine Datenbank.

Hier besteht das Risiko, dass ohne definiertes Konzept

Zugriffe und Berechtigungen intransparent vergeben wer-

den und dadurch unberechtigte Zugriffe möglich sind.



SAP-HANA-

Rollen

2 Sind die Berechtigungen zur Rollenpflege korrekt vergeben?

Die Berechtigungen zur Rollenpflege dürfen nur den ent-

sprechend verantwortlichen Benutzern zugeordnet werden.

Hier besteht das Risiko, dass Rollen von nicht dafür verant-

wortlichen Benutzern manipuliert oder versehentlich geän-

dert werden können.

189


Sie diese Berechtigung auch im Produktivsystem. Dort darf die Berechtigung keinem

Benutzer zugeordnet sein.

SELECT * FROM EFFECTIVE_PRIVILEGESWHERE USER_NAME IN ('USER1', 'USER2')AND GRANTEE_TYPE = 'USER'AND PRIVILEGE <> 'REPO.READ'AND OBJECT_TYPE = 'REPO'


SELECT * FROM _SYS_REPO.OBJECT_HISTORYWHERE OBJECT_SUFFIX = 'hdbrole'

Ihnen werden alle Rollenänderungen angezeigt. Prüfen Sie im Ergebnis, ob die Rol-

lenänderungen nur von dafür zuständigen Benutzern gepflegt wurden.

12.7.3 Katalogrollen




SAP-HANA-

Rollen

2 Wurden Rollen nur von dafür zuständigen Benutzern

gepflegt?

Rollen dürfen nur von den dafür verantwortlichen Benut-

zern gepflegt werden.

Hier besteht das Risiko, dass Rollen von nicht dafür verant-

wortlichen Benutzern manipuliert oder versehentlich geän-

dert wurden.



SAP-HANA-

Rollen

2 Besitzen Benutzer die Berechtigung zur Pflege von Katalog-

rollen?

Katalogrollen dürfen nicht verwendet werden, da sie u. a.

nicht transportierbar sind. Die Berechtigung zum Pflegen

von Katalogrollen darf nicht vergeben werden.

Hier besteht das Risiko, dass Rollen direkt im Produktiv-

system gepflegt werden, unter Umgehung des Freigabe-

verfahrens.

190


SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE = 'ROLE ADMIN'AND OBJECT_TYPE = 'SYSTEMPRIVILEGE'


SELECT * FROM GRANTED_ROLESWHERE GRANTEE_TYPE = 'USER' AND GRANTOR NOT IN ('_SYS_REPO', 'SYS')ORDER BY GRANTEE, ROLE_NAME

12.7.4 Systemberechtigungen


SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'ROLE'AND PRIVILEGE IN ('ADAPTER ADMIN', 'AGENT ADMIN', 'BACKUP ADMIN', 'BACKUPOPERATOR', 'CERTIFICATE ADMIN', 'CREDENTIAL ADMIN', 'ENCRYPTION ROOT KEYADMIN', 'EXTENDED STORAGE ADMIN', 'INIFILE ADMIN', 'LICENSE ADMIN',



SAP-HANA-

Rollen

2 Sind Benutzern Katalogrollen zugeordnet?

Katalogrollen dürfen nicht verwendet werden, da sie u. a.

nicht transportierbar sind. Stattdessen sollten den Benut-

zern Repository-Rollen zugeordnet werden.

Hier besteht das Risiko eines intransparenten Berechti-

gungskonzepts. Des Weiteren werden Benutzern die Kata-

logrollen automatisch entzogen, wenn der Besitzer der Rolle

gelöscht wird.



SAP-HANA-

Rollen

2 In welchen Rollen sind kritische Systemberechtigungen ent-

halten?

Systemberechtigungen dürfen nur den SAP-HANA-Adminis-

tratoren zugeordnet werden.

Hier besteht das Risiko, dass Systemberechtigungen durch

die Integration in falsche Rollen außerhalb der Administra-

tion zugeordnet werden.

191


'SAVEPOINT ADMIN', 'SERVICE ADMIN', 'SESSION ADMIN', 'SSL ADMIN', 'TENANTADMIN', 'TRUST ADMIN', 'VERSION ADMIN', 'RESOURCE ADMIN', 'TABLE ADMIN','AUDIT ADMIN', 'AUDIT OPERATOR', 'OPTIMIZER ADMIN', 'CREATE REMOTE SOURCE','LOG ADMIN', 'MONITOR ADMIN')AND OBJECT_TYPE = 'SYSTEMPRIVILEGE'

12.7.5 DEBUG-Berechtigungen


SELECT * FROM GRANTED_PRIVILEGESWHERE GRANTEE_TYPE = 'ROLE' ANDAND PRIVILEGE IN ('ATTACH DEBUGGER', 'DEBUG')

12.7.6 Entwicklerberechtigungen




SAP-HANA-

Rollen

1 In welchen Rollen sind DEBUG-Berechtigungen enthalten?

DEBUG-Berechtigungen dürfen im Produktivsystem nur in

Notfallrollen enthalten sein.

Hier besteht das Risiko, dass DEBUG-Berechtigungen durch

die Integration in falsche Rollen im Produktivsystem zuge-

ordnet werden.



SAP-HANA-

Rollen

1 In welchen Rollen sind Entwicklerberechtigungen ent-

halten?

Entwicklerberechtigungen dürfen nur im Entwicklungs-

system vergeben werden, im Notfall eventuell auch zeit-

begrenzt im Produktivsystem.

Hier besteht das Risiko, dass Entwicklerberechtigungen

durch die Integration in falsche Rollen im Produktivsystem

zugeordnet werden.

192

12.8 Prüfung des SAP-HANA-Berechtigungskonzepts

SELECT * FROM GRANTED_PRIVILEGESWHERE GRANTEE_TYPE = 'ROLE' ANDOBJECT_TYPE = 'REPO' AND PRIVILEGE <> 'REPO.READ'

12.7.7 Administrationsrechte


SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE = 'EXECUTE'AND OBJECT_TYPE = 'PROCEDURE'AND OBJECT_NAME = 'GRANT_ACTIVATED_ROLE'AND SCHEMA_NAME = '_SYS_REPO'


12.8.1 Entwicklerrechte




SAP-HANA-Rol-

len

2 Welche Benutzer besitzen Berechtigungen zur Zuordnung

von Repository-Rollen?

Nur die verantwortlichen Benutzerverwalter dürfen diese

Berechtigung besitzen.

Hier besteht das Risiko, dass Rollen falsch zugeordnet wer-

den.



SAP-HANA-

Berechtigungs-

prüfung

1 Welche Benutzer haben Entwicklerrechte im Produktivsys-

tem?

Entwicklerrechte dürfen im Produktivsystem nur im Notfall

zugeordnet werden.

Hier besteht das Risiko, dass eine Entwicklung im Produktiv-

system möglich ist und dadurch gegen geltende Gesetze

(u. a. § 239 HGB) verstoßen wird.

193


SELECT * FROM EFFECTIVE_PRIVILEGESWHERE USER_NAME IN ('USER1', 'USER2')AND GRANTEE_TYPE = 'USER'AND PRIVILEGE <> 'REPO.READ'AND OBJECT_TYPE = 'REPO'

12.8.2 Repository-Pflegerechte


SELECT * FROM EFFECTIVE_PRIVILEGESWHERE USER_NAME IN ('USER1', 'USER2')AND GRANTEE_TYPE = 'USER'AND PRIVILEGE like 'REPO%IMPORTED%'AND OBJECT_TYPE = 'REPO'

12.8.3 DEBUG-Berechtigungen




SAP-HANA-

Berechtigungs-

prüfung

1 Welche Benutzer dürfen importierte Repository-Objekte

ändern?

Berechtigungen zum Ändern importierter Repository-

Objekte dürfen nur im Notfall zugeordnet werden.

Hier besteht das Risiko, dass ausgelieferte Objekte geändert

und deren Funktionalitäten dadurch beeinträchtigt werden.



SAP-HANA-

Berechtigungs-

prüfung

1 Welchen Benutzern sind DEBUG-Berechtigungen zugeord-

net?

DEBUG-Berechtigungen dürfen im Produktivsystem nur im

Notfall zugeordnet werden.

Hier besteht das Risiko, dass dadurch gegen geltende

Gesetze (u. a. § 239 HGB) verstoßen wird.

194


SELECT * FROM EFFECTIVE_PRIVILEGESWHERE USER_NAME IN ('USER1', 'USER2', '...')AND GRANTEE_TYPE = 'USER'AND PRIVILEGE IN ('ATTACH DEBUGGER', 'DEBUG')

12.8.4 Systemberechtigungen


SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE IN ('ADAPTER ADMIN', 'AGENT ADMIN', 'BACKUP ADMIN','BACKUP OPERATOR', 'CERTIFICATE ADMIN', 'CREDENTIAL ADMIN', 'ENCRYPTION ROOTKEY ADMIN', 'EXTENDED STORAGE ADMIN', 'INIFILE ADMIN', 'LICENSE ADMIN','SAVEPOINT ADMIN', 'SERVICE ADMIN', 'SESSION ADMIN', 'SSL ADMIN', 'TENANTADMIN', 'TRUST ADMIN', 'VERSION ADMIN', 'RESOURCE ADMIN', 'TABLE ADMIN','AUDIT ADMIN', 'AUDIT OPERATOR', 'OPTIMIZER ADMIN', 'CREATE REMOTE SOURCE','LOG ADMIN', 'MONITOR ADMIN')AND OBJECT_TYPE = 'SYSTEMPRIVILEGE'



SAP-HANA-

Berechtigungs-

prüfung

1 Welchen Benutzern sind kritische Systemberechtigungen

zugeordnet?

Systemberechtigungen dürfen nur der Administration zuge-

ordnet werden.

Hier besteht das Risiko, dass die Datenbank durch die Nut-

zung kritischer Systemberechtigungen beschädigt wird.

195


12.8.5 Benutzerpflege


SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE = 'USER ADMIN'AND OBJECT_TYPE = 'SYSTEMPRIVILEGE'

12.8.6 Analytic Privileges


SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE = 'EXECUTE'AND OBJECT_TYPE = 'ANALYTICALPRIVILEGE'AND OBJECT_NAME = '_SYS_BI_CP_ALL'



SAP-HANA-

Berechtigungs-

prüfung

1 Welche Benutzer besitzen die Berechtigung zur Benutzer-

pflege?

Die Berechtigung darf nur den dafür verantwortlichen

Benutzern zugeordnet werden.

Hier besteht das Risiko, dass fiktive Benutzerkonten defi-

niert werden können.



SAP-HANA-

Berechtigungs-

prüfung

1 Welche Benutzer besitzen die Berechtigung für alle Analytic

Privileges?

Diese Berechtigung darf nur Benutzern zugeordnet werden,

die uneingeschränkt alle Daten lesen dürfen.

Hier besteht das Risiko, dass uneingeschränkt auf alle Daten

zugegriffen werden kann.

196

12.9 Das Security Audit Log in SAP HANA


12.9.1 Aktivierung


SELECT KEY, VALUEFROM M_INIFILE_CONTENTSWHERE KEY = 'global_auditing_state'

Der Wert »TRUE« zeigt an, dass das Audit Log aktiviert ist.



SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE = 'AUDIT ADMIN'AND OBJECT_TYPE = 'SYSTEMPRIVILEGE'



SAP HANA Audit

Log

1 Ist das Audit Log im Produktivsystem aktiviert?

Das Audit Log muss aktiviert sein.

Hier besteht das Risiko, dass gegen gesetzliche Auflagen zur

Nachvollziehbarkeit verstoßen wird.



SAP HANA Audit

Log

1 Welche Benutzer sind zum Konfigurieren des Audit Logs

berechtigt?

Nur die verantwortlichen Administratoren dürfen diese


Hier besteht das Risiko, dass die Audit-Log-Einstellungen

manipuliert werden können.

197




SELECT * FROM EFFECTIVE_PRIVILEGE_GRANTEESWHERE GRANTEE_TYPE = 'USER'AND PRIVILEGE = 'AUDIT OPERATOR'AND OBJECT_TYPE = 'SYSTEMPRIVILEGE'

12.9.4 Speicherung von Protokollen


SELECT * FROM M_INIFILE_CONTENTSWHERE SECTION = 'auditing configuration'AND KEY = 'default_audit_trail_type'

Der Wert »SYSLOGPROTOCOL« zeigt an, dass die Protokolle im Betriebssystem

gespeichert werden.



SAP HANA Audit

Log

1 Welche Benutzer sind zum Löschen der Audit-Log-Protokolle

berechtigt?

Nur die verantwortlichen Administratoren dürfen diese


Hier besteht das Risiko, dass die Protokolle gelöscht werden

und dadurch gegen gesetzliche Auflagen zur Nachvollzieh-

barkeit verstoßen wird.



SAP HANA Audit

Log

2 Werden die Audit-Log-Protokolle im Betriebssystem gespei-

chert?

Die Audit-Log-Protokolle sollten im Betriebssystem gespei-

chert werden, um Manipulationen zu verhindern.

Hier besteht das Risiko, dass die Protokolle in der Datenbank

manipuliert oder gelöscht werden können.

198


12.9.5 Richtlinien


SELECT * FROM AUDIT_POLICIESWHERE IS_AUDIT_POLICY_ACTIVE = 'TRUE'

Ihnen werden alle aktiven Audit-Log-Komponenten angezeigt. Gleichen Sie diese mit

den Unternehmensrichtlinien ab.

12.9.6 Auswertung

Prüfen Sie das schriftliche Konzept für die Audit-Log-Auswertung.



SAP HANA Audit

Log

2 Entsprechen die Einstellungen des Audit Logs den Unterneh-

mensrichtlinien?

Es müssen Vorgaben zur Einstellung des Audit Logs existie-

ren, die im System abzubilden sind.

Hier besteht das Risiko, dass das Audit Log unzureichend

definiert und dadurch gegen gesetzliche Auflagen zur Nach-

vollziehbarkeit verstoßen wird.



SAP HANA Audit

Log

2 Existiert ein Konzept zur Auswertung der Audit-Protokolle?

Im Konzept müssen Verantwortlichkeiten, Auswertungs-

zeiträume und Auswertungsinhalte definiert sein.

Hier besteht das Risiko, dass kritische Vorgänge nicht zeit-

nah erkannt werden.

199


12.9.7 Aufbewahrung

Prüfen Sie das schriftliche Konzept für die Aufbewahrung der Audit-Log-Protokolle.



SAP HANA Audit

Log

1 Existiert ein Konzept zur Aufbewahrung der Audit-Proto-

kolle?

Im Konzept muss festgelegt sein, wie lange die Protokolle

aufzubewahren sind. Hierbei sind gesetzliche Auflagen zu

beachten.

Hier besteht das Risiko, dass durch ein fehlendes Aufbewah-

rungskonzept gegen gesetzliche Auflagen zur Nachvollzieh-

barkeit verstoßen wird.

200

Wichtige Systemparameter

Anhang B des Buches, »Wichtige Systemparameter«, enthält keine Checklisten. Die

aufgeführten Systemparameter können Sie im System mit Transaktion RSPFPAR

prüfen. Hier können Sie in der Selektionsmaske nach Parametern filtern (siehe Abbil-

dung 13.1).

Abbildung 13.1 Systemparameter anzeigen

Es werden alle Systemparameter, die Ihrer Selektion entsprechen, angezeigt (siehe

Abbildung 13.2).

Abbildung 13.2 Liste der selektierten Systemparameter

201

Checklisten und praktische Prüfung zu Kapitel 1

Documents

Transcript of Checklisten und praktische Prüfung zu Kapitel 1