Sicherheit von SAP in Bezug auf neue Technologien
Sicherheit von SAP in Bezug auf neue Technologien
Sicherheit von SAP in Bezug auf neue Technologien
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Sicherheit</strong> <strong>von</strong> <strong>SAP</strong> <strong>in</strong> <strong>Bezug</strong> <strong>auf</strong> <strong>neue</strong> <strong>Technologien</strong><br />
2.2.5) sicherlich <strong>auf</strong> hohem Niveau, jedoch <strong>in</strong> H<strong>in</strong>blick <strong>auf</strong><br />
Webapplikationssicherheit mangelhaft und hauptsächlich <strong>auf</strong><br />
Accountsicherheit <strong>auf</strong>gebaut. Die vorgeschlagene <strong>Sicherheit</strong>se<strong>in</strong>stellung für<br />
HTTP beschränkt sich für den JAVA Stack beispielsweise laut <strong>SAP</strong><br />
NetWeaver Security Guide <strong>auf</strong> den E<strong>in</strong>satz <strong>von</strong> SSL. Daher s<strong>in</strong>d auch die<br />
hier <strong>auf</strong>geführten Empfehlungen das Resultat aus der kritischen<br />
Betrachtung der Empfehlungen <strong>von</strong> Seiten <strong>SAP</strong>s und den durch den<br />
Verfasser im Rahmen der Durchführung dieser Diplomarbeit gewonnenen<br />
Erkenntnisse.<br />
<strong>SAP</strong> bietet e<strong>in</strong>e gut konfigurierbare Passwort Policy, die u.a.<br />
Komplexitätsanforderungen, Gültigkeitsdauer und Accountdeaktivierung<br />
def<strong>in</strong>iert (siehe Anhang B: Konfigurationsempfehlungen und<br />
Programmierrichtl<strong>in</strong>ien). Diese E<strong>in</strong>stellungsmöglichkeiten sollten gemäß der<br />
Unternehmenspolicy gesetzt werden, z.B. M<strong>in</strong>destlänge 8 Zeichen mit<br />
Gross- und Kle<strong>in</strong>buchstaben und m<strong>in</strong>destens e<strong>in</strong>em Sonderzeichen, das alle<br />
8 Wochen geändert werden muss.<br />
Ausser acht gelassen s<strong>in</strong>d bisher die Standardaccounts, die sich auch bei<br />
prakischen Überprüfungen des Verfassers als großes <strong>Sicherheit</strong>srisiko<br />
dargestellt haben. Der Account DDIC darf allerd<strong>in</strong>gs unter Umständen nicht<br />
gelöscht werden, genau so EARLYWATCH, so dass im Vorfeld e<strong>in</strong>e<br />
Überprüfung, ob das Löschen hier möglich ist, vorgenommen werden muss.<br />
Als letzten, immer vorhandenen Account mit bekanntem Passwort sollte<br />
<strong>SAP</strong>* deaktiviert werden. Löschen ist wie <strong>in</strong> Kapitel 3.3.3 beschrieben nicht<br />
möglich, jedoch die Deaktivierung.<br />
Das zweite übliche Element bei der Absicherung durch<br />
Konfigurationse<strong>in</strong>stellungen ist das klare Setzen <strong>von</strong> Rollen, Gruppen und<br />
Userrechten, <strong>in</strong>klusive deren Zuordnung zu Gruppen/Rollen.<br />
Für RFC, das <strong>SAP</strong> eigene Kommunikationsprotokoll muss<br />
auth/rfc_authority_check aktiv se<strong>in</strong>, da sonst Berechtigungen nicht geprüft<br />
werden. Sogenannte Bauste<strong>in</strong>e können RFC-fähig gemacht werden, womit<br />
sie entfernt <strong>auf</strong>gerufen werden können. Dies sollte nur für Bauste<strong>in</strong>e<br />
geschehen, für die das notwendig ist, da fehlerhafte, über RFC <strong>auf</strong>rufbare<br />
Bauste<strong>in</strong>e e<strong>in</strong> nicht zu unterschätzendes Risiko darstellen (siehe Anhang C:<br />
<strong>Sicherheit</strong> on RFC). Dasselbe gilt für das Aufrufen <strong>von</strong> RFC über SOAP, das<br />
ebenfalls restriktiv konfiguriert werden sollte.<br />
Damian Schlager Seite 76
Change language