wp SAP 200702 FM Gredel - files.vogel.de · Secaron AG, Whitepaper: SAP Netweaver® Sicherheit 2...

Secaron Business-Paper

SAP Netweaver® Sicherheit

Hinweis: Veröffentlichungen, auch in Teilen, sind nur zulässig nach vorangehender Ge-nehmigung durch die Secaron AG oder eines Bevollmächtigten. Secaron AG, Juli 2006

von Andreas Baus Secaron AG Ludwigstr. 45 D-85399 Hallbergmoos Tel. +49 811 9594 - 0 Fax +49 811 9594 - 220

Secaron AG, Whitepaper: SAP Netweaver® Sicherheit

2

Zusammenfassung

Die SAP NetWeaver® Plattform bietet eine zukunftssichere Basis für Geschäftsanwendun-gen und vereint die Möglichkeiten von R/3® mit denen eines Java Enterprise Systems. Die hohe Flexibilität bedingt jedoch eine dementsprechende Komplexität und die Behand-lung von Sicherheitsrisiken des Gesamtsystems wird zur Herausforderung für jeden Betreiber. Das vorliegende Business-Paper zeigt Sicherheitsmaßnahmen und Best Practi-ces beispielhaft in verschiedenen Bereichen für typische SAP NetWeaver® Umgebungen.

Inhalt Seite

Einleitung 3

Betriebsrisiko 4

Schutzmaßnahmen 6


3

1 Einleitung Die Firma SAP ist mit ihren Produkten nach wie vor der unangefochtene Marktführer in den Bereichen Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), sowie Supply Chain Management (SCM) und baut diesen Marktvorsprung durch die sukzessive Ergänzung um neue Technologien weiter aus. Konzerne und Mittelstand nutzen die SAP NetWeaver® Plattform zur Integration und Verarbeitung von verschie-densten, teilweise geschäftskritischen Informationen. Diese Basis für Geschäftsanwen-dungen vereint die Möglichkeiten von R/3® mit einer zukunftssicheren Java Enterprise Infrastruktur als Integrationsplattform auch für nicht-SAP Anwendungen.

Diese Flexibilität muss jedoch mit einer entsprechend hohen Komplexität des Gesamtsys-tems bezahlt werden. Ein wirksames Sicherheitskonzept für aktuelle SAP® Systeme kann nur mit Know-How in allen betroffenen Bereichen aufgebaut werden. Dies reicht von der Ebene der Geschäftsprozesse über die Anwendungen, die SAP Basis in ABAP und Java Stack, Betriebsystem, Datenbank und Infrastruktur bis hin zu Vorgaben für eine sichere Entwicklung.

Im Rahmen dieses Business-Papers werden Sicherheitsmaßnahmen und Best Practices beispielhaft in verschiedenen Bereichen für typische SAP NetWeaver® Umgebungen auf-gezeigt. Der Umsetzungsgrad einiger Maßnahmen kann auch leicht ohne besondere Werk-zeuge geprüft werden. Hierzu werden an einigen Stellen im Dokument Hinweise gegeben, wie die entsprechende Systemeinstellung in einem eigenen System mit Hilfe von Windows und SAP GUI selbst überprüft werden kann.


4

2 Betriebsrisiko Das Risiko, welches der Verantwortliche bzw. die Firma durch den Betrieb eines SAP Net-Weaver® Systems trägt, bestimmt sich aus dem möglichen Schaden und der Eintritts-wahrscheinlichkeit. Der mögliche Schaden hängt im Wesentlichen von den verarbeiteten Daten ab. Zusammen mit den Geschäftsprozessen bestimmen diese den Schutzbedarf des Systems in Form des maximalen Schadens, der bei Verletzung eines Schutzzieles eintreten kann. Aus Sicht der Datenverantwortlichen sollte der nominelle Schutzbedarf eines Sys-tems in verschiedenen Bereichen (Schutzziele) bestimmt werden:

• Ein System ist Bestandteil wichtiger Geschäftsprozesse und muss den Anforderungen an die Verfügbarkeit dieser Prozesse genügen. Wichtig ist hierbei zu bestimmen, wel-cher Schaden nach einer definierten Zeitspanne eintritt und somit, wie hoch die ma-ximal mögliche Ausfallzeit des Systems ist.

• Das System verarbeitet belegsrelevante Daten, deren Integrität im firmeneigenen Interesse und zur Wahrung gesetzlicher Vorschriften zu jedem Zeitpunkt sichergestellt sein muss. Hier sollten neben dem möglichen Schaden auch die potentiellen rechtli-chen Konsequenzen mit einbezogen werden.

• Auf dem System werden Informationen gespeichert oder verarbeitet, die vertraulich behandelt werden müssen. Im Falle eines Bruchs der Vertraulichkeit kann beispiels-weise die Marktposition gegenüber Kunden der Konkurrenz beeinträchtigt werden.

Im Einzelfall können noch weitere Schutzziele, z.B. aufgrund gesetzlicher Anforderungen für einen bestimmten Industriezweig zu erfüllen sein. Bei der Wahl der möglichen Stufen für den Schutzbedarf ist weniger oft mehr. Für den wirtschaftlichen Betrieb eines SAP® Systems sollte in jedem Fall eine vollständige Bestimmung der Schutzziele und des einzel-nen Schutzbedarfs für jedes dieser Ziele erfolgen. Im Laufe der Lebenszeit des Systems sollte diese Analyse gepflegt werden um dann, genau wie das System selbst, zu reifen und an Genauigkeit zu gewinnen.

Mit Hilfe der Schutzbedarfsanalyse können Bedrohungen für diese Schutzziele identifiziert werden. Hilfreich in der Bestimmung von Bedrohungen und dem daraus möglichen Scha-den können fiktive Schadensszenarien sein, die gegebenenfalls mit Erfahrungswerten be-legt werden.

Die Bedrohungen für Dienste und Daten eines SAP® Systems können verschieden klassi-fiziert werden. Technisches Versagen oder Umwelteinflüsse wie Feuer können primär die Verfügbarkeit der Dienste beeinträchtigen. Auch organisatorische Mängel und menschliche Fehler können negativ auf dieses Schutzziel einwirken.


5

Vorsätzliche Handlungen durch einen frustrierten Mitarbeiter oder einen externen Angrei-fer können ebenfalls eine Beeinträchtigung der Verfügbarkeit zum Ziel haben. Eher ist hier jedoch mit einem gezielten Bruch der Vertraulichkeit oder der Integrität von Daten zu rechnen. Naturgemäß sind Auswirkungen solcher Angriffe meist nicht offensichtlich und diese somit ungleich schwieriger zu bekämpfen.

Dies liegt einerseits daran, dass der Ausfall eines wichtigen Dienstes schnell durch An-wender oder Administratoren bemerkt wird. Eine Inkonsistenz im Datenbestand fällt je-doch unter Umständen erst nach Wochen oder Monaten auf. Ein Datendiebstahl kann ohne spezielle Schutzmaßnahmen sogar vollständig unerkannt bleiben, da selbst die Aus-wirkungen, wie beispielsweise eine verlorene Ausschreibung, für den Betroffenen oft im Verborgenen bleiben.

Beispiel SAP Enterprise Portal Anwendung im Internet und firmeneigenen Intranet mit Zugriff auf Kundenstammdaten.

• Schutzziel: Vertraulichkeit; Bewertung: hoher Schutzbedarf

Im SAP System werden Kundendaten und Kreditkarteninformationen gespeichert. Ein Bruch der Vertraulichkeit dieser Daten bedeutet einen massiven Image- und Vertrauens-verlust auf dem Markt. Zusätzlich drohen Vertragsstrafen und der Verlust der Zertifizie-rung durch den Kreditkartenanbieter. Weiter fordert das Bundesdatenschutzgesetz ange-messene Schutzmaßnahmen zum Schutz von personenbezogenen Daten.

• Mögliche Bedrohungen für dieses Schutzziel:

o Unauthorisierter Zugriff auf den Datenbestand aus dem Internet: Ein externer Angreifer versucht gezielt an die Kreditkarteninformationen der Kunden zu ge-langen.

o Missbrauch von Zugriffsberechtigungen durch authorisierte Benutzer. Ein Mit-arbeiter eines Dienstleistungsunternehmens kopiert Kundendaten aus einem Backup und verkauft diese an Dritte.

Um die Eintrittswahrscheinlichkeit für die identifizierten Schadensszenarien schätzen zu können, werden nun potentielle Schwachstellen im SAP System, der Anwendungen oder deren Infrastruktur wie z.B. dem Betriebssystem identifiziert.

Bei Schwachstellen kann zwischen bekannten und unbekannten Schwachstellen unter-schieden werden. Um die Präsenz von Schwachstellen beider Kategorien in einem System wirksam zu verringern, wird generell das Minimalprinzip angewendet. Dies fordert, dass nur für den Geschäftsprozess und Betrieb notwendige Dienste oder Anwendungen auf dem System zur Verfügung stehen.


6

3 Schutzmaßnahmen Vielen Risiken im Zusammenhang mit SAP® Systemen kann bereits durch einfache Maß-nahmen ohne zusätzliche Hard- oder Software wirksam begegnet werden.

Betrieb Insbesondere für Maßnahmen, die den Betrieb der SAP® Systeme betreffen, sollten vorab die konkreten Bedrohungen identifiziert werden. So kann es beispielsweise notwendig sein für ein SAP System, welches auf Applikationsebene durch einen Outsourcing-Partner be-trieben wird, zusätzliche organisatorische oder auch technische Maßnahmen umzusetzen. Bei diesem Beispiel könnte die organisatorische Maßnahme in einer Berücksichtigung im entsprechenden Service-Level-Agreement (SLA) bestehen und auf technischer Ebene mit einer Protokollierung durch das SAP® Audit System berücksichtigt werden.1 Die Projekter-fahrung zeigt, dass dieser Punkt meist nicht ausreichend berücksichtigt wird und dann im Rahmen von Audits beanstandet wird und deutliche Mehrkosten generiert.

Netzwerk-Zonierung Um die Angriffsfläche, die ein SAP Web Application Server (SAP WebAS) bietet, kontrollie-ren zu können, ist eine Zonierung auf Netzwerkebene notwendig. Datenbank und Zentral-instanz bilden das Backend und sollten ausschließlich für administrative Benutzer erreich-bar sein. Je nach Größe der Installation bieten dann dedizierte Applikationsserver (Java) bzw. Dialoginstanzen (ABAP) den Zugangspunkt für Endbenutzer oder Partnersysteme, die nicht unter eigner Kontrolle stehen. Bei umfangreichen Installationen empfiehlt sich außerdem der zusätzliche Einsatz von Applikationsproxies. Bei Zugang mit SAP GUI kann dies z.B. der SAP Router sein.

Generell sollte jedoch das Netzwerkdesign sicherstellen, dass der Zugriff auf Dienste eines SAP® Systems nur den jeweiligen Nutzern möglich ist. Der Zugriff für nicht berechtigte Dritte sollte bereits auf Netzwerkebene verhindert werden.

Das für SAP GUI verwendete SAP Protokoll "DIAG" bietet nur einen Minimalschutz gegen einfache Mithör-Attacken, da nur eine Komprimierung des Datenstroms stattfindet. Bei SAP® Systemen mit mittlerem oder hohem Schutzbedarf in Bezug auf Vertraulichkeit oder Integrität sollte jedoch unbedingt eine Verschlüsselung mittels SNC (Secure Network Communication bei SAP GUI und RFC Zugriff) bzw. SSL (bei Zugriff über den Webbrow-ser) erfolgen.

Auch die B2A Anbindung mittels Business Connector (BC), z.B. via Elster an die Finanzäm-ter, sollte im Zonierungskonzept berücksichtigt werden. Da der BC mit fremden Systemen kommuniziert, ist dieser am Besten innerhalb einer DMZ aufgehoben. Eingehende Kom- 1 Weitere Informationen zu diesem Thema finden Sie auch im Secaron Whitepaper "IT-Sicherheit in Service Level

Agreements".


7

munikationsverbindungen des BC sollten durch geeignete Applikationsproxies zusätzlich abgesichert werden.

Auch hier ist in Projekten immer wieder festzustellen, dass auf die Zonierung verzichtet wird, weil zum Teil die Schutzziele nicht ausreichend klar herausgearbeitet wurden oder die Erweiterungen der Systemanbindungen in Folgeprojekten unterschätzt werden. Man hört dann meist von historisch gewachsenen Systemen, die nicht mehr angefasst werden, weil das Risiko für eine Beeinträchtigung der Verfügbarkeit zu hoch erscheint.

Basis für eine SAP Installation sollte immer eine gehärtete Betriebssysteminstallation sein. Unabhängig vom verwendeten Betriebssystem sollten hierbei die folgenden Ziele erreicht werden:

Minimalinstallation Oft sind nach Standardinstallationen auch Dienste wie Telnet oder FTP aktiv. Diese sollten unbedingt deaktiviert werden um Angriffe auf Netzwerkebene nicht unnötig zu erleichtern. Generell ist es empfehlenswert vor der Installation eines produktiven SAP® Systems eine Liste der benötigten Softwarepakete zu erstellen und andere Pakete bei der Installation abzuwählen. Diese Auswahl sollte sorgfältig durchgeführt werden, da hiermit die notwen-dig Deaktivierung oder sichere Konfiguration von Diensten und Programmen minimiert werden kann.

Bei einem Audit oder Penetrationstest kann man in der Praxis immer wieder feststellen, dass die Minimalinstallation als grundlegende Maßnahme nicht umgesetzt wird.

Konfiguration Im nächsten Schritt sollte die Konfiguration von Programmen und Netzwerkdiensten ü-berprüft werden, die für den Betrieb des Systems notwendig sind. Insbesondere die Kon-figuration von Diensten, die über das Netzwerk erreichbar sind (z.B. Backup- oder Monito-ring-Agenten) sollte dahingehend geprüft werden, dass nur notwendige Systeme mit dem Dienst kommunizieren können (z.B. über eine dedizierte Management oder Backup Netz-werkschnittstelle). Wenn dies auf Dienstebene nicht möglich ist, kann ersatzweise hierfür auch die Firewall-Funktionalität des Betriebsystems verwendet werden. Weiterhin gehören zu einer sicheren Konfiguration auf Betriebssystemebene die Umsetzung einer wirksamen Passwort-Policy und auch die Verwendung von personalisierten Benutzeraccounts für alle Administratoren.

In der Praxis mangelt es an der Verwendung von personalisierten Accounts. Dies gilt ins-besondere für Administratoren, meist wegen einer fehlenden zentralen Benutzerverwal-tung. Die Verwaltung der Benutzer wird auf dieser Ebene somit umständlich und inkonsis-tent. Die Folge sind Passwörter, die mehreren Administratoren bekannt sind, und eine sinkende Qualität der Passwörter. Zudem wird oft vermieden, das Passwort regelmäßig zu


8

ändern, um die Verfügbarkeit des Zugangs zu gewährleisten. Ein mögliches Lösungssze-nario ist die Verwendung von Public Key Verfahren für die Benutzerauthentisierung.

Administrationszugänge Für die Administration von SAP® Systemen sollten nur dedizierte oder verschlüsselte Ka-näle wie z.B. unter UNIX/LINUX die Secure Shell (SSH) verwendet werden. Das im Win-dows Umfeld oft verwendete Remote Desktop Protokoll (RDP), welches im Windows Ser-ver seit Version 2000 standardmäßig integriert ist, sollte jedoch nur mit aktiviertem TLS Protokoll verwendet werden. Die Aktivierung dieses Protokolls bedingt die Verwendung von Zertifikaten für die Authentisierung und ist im Microsoft TechNet ausführlich beschrie-ben. Sicherheitsprobleme im Standardprotokoll RDP lassen sich sonst mit einfachsten Mit-teln zum Ausspähen von Kennworten verwenden.

Die Administrationszugänge zu den Betriebssystemen sollten durch geeignete Authentisie-rungsverfahren geschützt werden. Bei Systemen mit mittlerem und hohem Schutzbedarf empfiehlt sich der Einsatz von starker Authentisierung (z.B. mittels Hardware Token oder Smartcard). Aufgrund der flexiblen Authentisierungsschnittstellen sind entsprechende Ver-fahren in allen SAP Systemplattformen integrierbar.

Patchmanagement Zum Installationszeitpunkt sollte sichergestellt werden, dass die aktuelle Version der je-weiligen Betriebssystem/Software-Komponenten installiert wird, um bekannte und bereits behobene Schwachstellen gar nicht erst einzuführen. Im Laufe der Lebenszeit des Sys-tems muss dann mit Hilfe eines Patchmanagement-Prozesses die Aktualität dieser Kom-ponenten ebenso sichergestellt werden wie bei SAP Anwendungskomponenten.

Eine solide Betriebssystemkonfiguration stellt die Basis für jedes Berechtigungskonzept innerhalb eines SAP® Systems dar. Häufig werden viele Arbeitsstunden in die Erstellung eines umfassenden Berechtigungskonzeptes auf SAP Anwendungsebene investiert. Bei einem Audit des SAP® Systems durch einen Wirtschaftsprüfer wird dies dann in Form von positiven Auditresultaten bestätigt, da oft nur auf dieser Ebene geprüft wird. Ein Angreifer wird jedoch nicht den gut gesicherten Haupteingang als Ziel wählen, wenn die Terrassen-türe weit offen steht. Denn wenn er Zugriff auf Betriebssystem- oder Datenbankebene erlangen kann, ist es möglich, einen eigenen hoch privilegierten Benutzer im SAP System über diesen Weg zu aktivieren und somit das teure Berechtigungskonzept vollständig zu umgehen.

Datenbank Genau wie die Absicherung des Betriebssystems ist auch die Sicherung der Datenbank essentiell, um ein Berechtigungskonzept auf Anwendungsebene zu untermauern. Für die Datenbank eines SAP® Systems sollten somit die folgenden Spielregeln beachtet werden:


9

• Die Datenbankinstanz sollte einzig und allein dem jeweiligen SAP System zur Verfü-gung stehen. Das bedeutet, dass außer zu Betriebszwecken (z.B. Backup oder Monito-ring) keine Zugriffe auf die Datenbank am SAP System vorbei erfolgen dürfen.

• Das Datenbanksystem sollte auf Netzwerkebene ausschließlich mit dem jeweiligen SAP System kommunizieren. Ein direkter Verbindungsaufbau eines Angreifers zur Da-tenbank wird also bereits durch die richtige Netzwerkzonierung vereitelt. Zusätzlich sollten auch auf Datenbankebene die berechtigten Verbindungspartner (z.B. IP Adres-se des SAP® Systems) angegeben werden. Bei Oracle ist dies beispielsweise in der Datenbank Konfiguration mit den Einträgen "tcp.validnode_checking" und " tcp.invited_nodes" möglich.

• Die Benutzer auf Datenbankebene sollten ebenfalls abgesichert werden. D.h. es dür-fen keine Benutzer mit Standardpasswörtern vorhanden sein und Datenbankadminist-ratoren sollten nach Möglichkeit keinen Zugriff auf die SAP Tabellen besitzen. Aus-nahme kann hier ein entsprechender Benutzer für den Notfall sein, dessen Kennwort sicher (z.B. beim Verantwortlichen für das SAP System) hinterlegt ist. Das Passwort für den Datenbankbenutzer der SAP Instanz sollte ausreichend komplex und nicht durch eine Wörterbuchattacke zu erraten sein.

Wie bereits im vorangegangenen Abschnitt erläutert, sollte der Konfiguration des Daten-banksystems dieselbe Aufmerksamkeit zuteil werden, wie dem Berechtigungskonzept auf SAP Anwendungsebene. Nur durch ausgewogene und angemessene Maßnahmen auf allen Ebenen eines SAP® Systems lässt sich die Gesamtsicherheit tatsächlich verbessern.

Die Härtung der SAP Komponenten sollte denselben Prinzipien, wie die Betriebsystemhär-tung Rechnung tragen. Exemplarisch werden im Folgenden geeignete Maßnahmen für die Härtung eines SAP Web Appliaction Server (Web AS) vorgestellt. Diese adressieren sowohl die Absicherung der ABAP, als auch der Java spezifischen Teile.

Beispiel Bei der Installation des SAP Web AS werden standardmäßig Komponenten mitinstalliert, die nicht in jeder Umgebung benötigt werden und ein Sicherheitsrisiko darstellen. Bei-spielsweise wird der Internet Graphics Server (IGS) nur in bestimmten Szenarien benötigt und sollte auch nur dann installiert bzw. gestartet werden. Da verschiedene SAP Dienste (wie der IGS) bereits eine einschlägige Sicherheitshistorie in Form von über Netzwerk nutzbaren Schwachstellen haben, ist die Einschränkung auf benötigte Dienste besonders wichtig.

Für die sichere Konfiguration eines SAP Web AS muss an verschiedenen Fronten Hand angelegt werden. Ein Großteil der Konfiguration ist mit Hilfe von Profilparametern mög-lich, die im ABAP Stack mit Hilfe der Transaktion RZ11 gepflegt werden. In der Transakti-


10

on kann weiterhin eine ausführliche Hilfe zu den Parametern aufgerufen werden. Im Fol-genden sind beispielhaft sicherheitsrelevante Parametergruppen mit ihrem jeweiligen Zweck aufgeführt: • login/*password*

Die Vorgaben für die Stärke von Kennwörtern im ABAP Stack erfolgt mit den Parame-tern dieser Gruppe. Hier sollte sichergestellt werden, dass die Werte eine ausreichen-de Passwortkomplexität vorschreiben (z.B. Mindestlänge 8 Zeichen, mindestens eine Zahl und ein Sonderzeichen).

• icm/*

Die Einstellungen für den Internet Communication Manager (ICM) beeinflussen das Verhalten des Web AS in Bezug auf HTTP, HTTPS oder auch SMTP Verbindungen. Es wird festgelegt, auf welchen Netzwerkports das System auf Verbindungen wartet und wie gesprächig sich das System in Bezug auf Fehler zeigt. Für Produktionssysteme (insbesondere mit direkter oder indirekter Verbindung zu einem Fremdnetz) sollte si-chergestellt werden, dass die webbasierte Administration des ICM nur aus vertrau-enswürdigen Netzen möglich ist. Weiterhin sollten keine detaillierten Fehlerinformatio-nen des ICM ausgegeben werden.

• auth/* In dieser Parametergruppe wird unter anderem das Verhalten des Systems bei der Prüfung von Berechtigungsobjekten festgelegt. Um das Berechtigungskonzept in Pro-duktivsystemen nicht zu untergraben, sollte hier eingestellt werden, dass keine Deak-tivierung von Berechtigungsobjekten möglich ist und auch für Remote Function Call (RFC) Aufrufe eine Berechtigungsprüfung stattfindet.

Der aktuelle Zustand der Profilparameter auf einem System kann mit Hilfe des Reports RSPARAM über die Transaktion SA38 mit der SAP Gui aufgerufen werden. Die Inhalte der sicherheitsrelevanten Parameter in diesem Report sollten in regelmäßigen Abständen (z.B. vierteljährlich) oder nach Änderungen im Basissystem auf Veränderung geprüft werden. Somit kann rechtzeitig festgestellt werden, wenn Parameter z.B. zur Fehlersuche in einer unsicheren Einstellung belassen wurden.

Je nachdem, ob das SAP System auch webbasierte Dienste bereitstellt, sollten diese Dienste nun weiter gehärtet werden. Stellt beispielsweise der Internet Communication Manager (ICM) einen Zugang zu Web-Diensten des ABAP Stacks (das Internet Communi-cation Frameworks) bereit, so sollte nun dieser Teil so konfiguriert werden, dass nur be-nötigte Dienste aufrufbar sind. Anderenfalls kann ein Angreifer über diesen Weg nähere Informationen über das System ermitteln oder Schwachstellen in Programmen (z.B. Pro-grammierbeispielen) ausnutzen, obwohl diese für den Betrieb nicht notwendig sind.


11

Das Internet Communication Frameworks (ICF) kann mit Hilfe der Transaktion SICF konfigu-riert werden. Hier sollte sichergestellt werden, dass in der Verzeichnishierarchie der einzel-nen virtuellen Server nur die Dienste aktiviert sind, die tatsächlich benötigt werden. Dies wird bei einer Installation mit aktuellen WebAS Quellen (Version 6.40, Service Release 1) bereits standardmäßig so konfiguriert. In älteren Systemen sollte dies jedoch in jedem Fall manuell geprüft werden.

Zusätzlich zur Einschränkung der angebotenen ICF Dienste sollte sichergestellt werden, dass bei Business Server Page (BSP) Anwendungen keine fremden HTML Inhalte einge-schleust werden können. Dies ist beispielsweise mit dem URL Parameter "sap-theme" möglich, der das von einer BSP Anwendung verwendete Darstellungs-Thema (z.B. Zei-chensätze, etc.) übersteuern kann und so u.U. fremde HTML-Inhalte in eine Seite ein-bringt.

Eine Whitelist Prüfung von Adressparametern, die zum Einschleusen von HTML-Inhalten verwendet werden könnten, kann ab SAP WebAS 6.40 SP14 durch Pflege der Tabelle HTTP_WHITELIST erfolgen (z.B. mit Transaktion SE16). Whitelisting bedeutet, dass nur explizit erlaubte Muster für diese URL Parameter zugelassen werden. Standardmäßig ist diese Ta-belle nicht gepflegt und es wird keine Prüfung durchgeführt.

Standardbenutzer Besonders gefährlich ist die Existenz von Systembenutzern mit Standardpasswörtern, da ein Angreifer diese im Allgemeinen zuerst prüft. Diese Benutzer (z.B. SAP*, DDIC oder auch EARLYWATCH) werden für viele Aktivitäten rund um den Basisbetrieb benötigt und sind immer vorhanden. Der Benutzer "SAP*" bildet zudem insofern ein Kuriosum, da die-ser im Normalfall auch dann zugänglich ist, wenn kein Benutzerstamm für ihn angelegt ist. Der Benutzer ist nämlich fest im Kern des ABAP Systems codiert und kann nur durch den Profilparameter "login/no_automatic_user_sapstar=1" deaktiviert werden. Aber Ach-tung: Es ist dann in jedem Fall sinnvoll einen unabhängigen Benutzer anzulegen, der für den Notfall alle Berechtigungen (Profil SAP_ALL) im System innehat.

Zur Prüfung der Existenz von Systembenutzern mit Standardpasswörtern kann der Report RSUSR003 (z.B. mittels Transaktion SA38) aufgerufen werden. Der Passwortzustand der wich-tigsten Systembenutzer in allen Mandanten, sowie die Einstellungen für die Passwort-Policy des ABAP Systems werden dann in einer Zusammenfassung angezeigt. Auch diese Prüfung sollte in regelmäßigen Abständen wiederholt und das Ergebnis dokumentiert werden.


12

Zusätzlich zu diesem Report müssen jedoch u.U. auch weitere Benutzer geprüft werden, da diese nicht in dem Report enthalten sind. So legen beispielsweise auch der Java Teil des SAP WebAS und der SAP Solution Manager Benutzer mit Standardpassworten wäh-rend der Installation an. Für jeden dieser Benutzer sollte das Kennwort geändert werden. Da diese Benutzer auch unpersonalisierten Zugang zu Produktivsystemen ermöglichen, sollten sie hier generell gesperrt und nur bei Bedarf mit Protokollierung aktiviert werden.

Java Stack Der Java Anteil im SAP WebAS stellt einen eigenständigen Applikationsserver auf J2EE Basis dar. Die Kommunikation zwischen Java und ABAP Anteil des SAP WebAS erfolgt mit dem JavaConnector (JCo), der als Schnittstelle zwischen den beiden Welten dient. Der Schutzbedarf des Java-Stack entspricht dem des angebundenen ABAP Systems, da über die JCo Verbindung auf die Daten das ABAP System zugegriffen werden kann. Somit gilt es, bei Dual-Stack (also ABAP- und Java-Anteil) Installationen eine weitere Komponente abzusichern.

Auch in der Java Stack Installation sollten nur benötigte Anteile mitinstalliert werden. Falls z.B. Knowledge Management oder das TREX System nicht verwendet werden, sollten die-se auch nicht mitinstalliert werden. Auch Beispielprogramme haben in einem Produktiv-system nichts verloren und sollten mit Hilfe des Software Deployment Manager (SDM) deinstalliert werden. Hier lauert jedoch eine Falle: mit Softwareupdates halten die deinstallierten Programme unter Umständen wieder Einzug in das System. Aus diesem Grund sollte man entweder nach jedem Update die Liste der installierten Komponenten entweder prüfen, oder die nicht benötigten Komponenten auf dem System belassen aber deaktivieren.

Nach der Installation enthält der Java Anteil des Web AS standardmäßig verschiedene aktive Dienste, die für die Ausführung von Anwendungen erforderlich sind. Einige dieser Dienste bedienen eigene Netzwerkports und bieten somit zusätzliche Fläche für einen Angreifer.

Die Konfiguration bzw. Deaktivierung von Diensten des Java Stack erfolgt mit Hilfe des Visual Administrator resp. dem Config Tool. Der Visual Administrator erlaubt hierbei die Verwaltung eines Systems über Netzwerk, während das Config Tool nur lokal auf dem jeweiligen Server verwendet werden kann.

Die folgende Tabelle zeigt Netzwerkports und deren jeweilige Dienste, die in einem Web AS Java aktiviert sein können. Der Platzhalter NN steht für die jeweilige Instanznummer, sodass z.B. der HTTP Port auf einer Instanz mit der Nummer "01" auf dem Port "50100" hört.


13

Ob nun auf einem WebAS Java (im Beispiel: IP Adresse 1.2.3.4; Instanz 00) der Telnet Dienst aktiviert und erreichbar ist, kann einfach mit folgender Windows Kommandozeile (erreich-bar via Start -> Ausführen "cmd.exe" -> OK) geprüft werden:

c:\>telnet 1.2.3.4 50008

Erscheint die folgende Fehlermeldung ist der Dienst entweder nicht gestartet, nicht er-reichbar oder hört auf einem anderen Port (z.B. wegen der falschen Instanznummer):

> Verbindungsaufbau zu 1.2.3.4...Es konnte keine Verbindung mit dem

> Host hergestellt werden, auf Port 50008: Verbinden fehlgeschlagen

Ist er jedoch erreichbar, so begrüßt Sie das SAP System mit einer Login Maske.

Diese Prüfung funktioniert generell auch für die anderen Dienste und Ports (z.B. HTTPS), a-ber der Dienst wird dann bei erfolgreicher Verbindung auf protokollkonforme Daten war-ten und weniger "benutzerfreundlich" agieren.

Service TCP Port Dienst

HTTP 5NN00 HTTP Provider

HTTP via SSL 5NN01 HTTP Provider

IIOP 5NN07 IIOP Provider

IIOP Init 5NN02 IIOP Provider

IIOP via SSL 5NN03 IIOP Provider

P4 5NN04 P4 Provider

P4 via HTTP 5NN05 P4 Provider

P4 via SSL 5NN06 P4 Provider

Telnet 5NN08 Telnet Provi-der

JMS 5NN10 JMS Provider


14

Generell gilt für die Konfiguration der Dienste wieder das Minimalprinzip: Nur tatsächlich notwendige Dienste sollten aktiviert bleiben. Das gilt natürlich im Besonderen für Netz-werkdienste wie z.B. den Telnet oder den HTTP Provider.

Eine ausführliche Übersicht über die Java Dienste, die z.B. in einer Enterprise Portal Um-gebung tatsächlich benötigt werden, liefert der SAP Hinweis 781882.

Ist klar welche Dienste benötigt werden, sollte versucht werden, mögliche Angriffspunkte auf Ebene dieser einzelnen Dienste zu minimieren. Für einen HTTP Provider bedeutet dies, dass in produktiven Java Systemen die HTTP Methoden "TRACE" und "PUT" abge-schaltet2 werden sollten, um z.B. Cookie-Stealing Attacken zu vermeiden. Weiterhin er-laubt der Dienst, dass Verzeichnisse durchsucht werden können (Directory Browsing). Auch dies kann mit entsprechender Konfiguration des Dienstes verhindert werden.3 Ab-hängig von der eingesetzten Version des SAP Web AS Java, sind diese Optionen zwi-schenzeitlich bereits standardmäßig deaktiviert.

Administrationszugänge Die Administration des Java Stack erfolgt primär mit Hilfe des Visual Administrator, der mit dem proprietären P4 Protokoll mit dem jeweiligen Server kommuniziert. Zur Absiche-rung dieser Kommunikation bestehen verschiedene Möglichkeiten. Wichtig ist jedoch in jedem Fall, dass die Kommunikation nicht unverschlüsselt erfolgen darf, um ein Ausspä-hen des Administratorkennwortes zu verhindern. Eine Möglichkeit besteht in der Verwen-dung von P4 via SSL. Hierzu muss ein X.509 Zertifikat für den P4 Provider konfiguriert werden. Eine andere Möglichkeit ist das Tunneln der P4 Verbindung über eine bestehende sichere Verbindung, beispielsweise SSH. In diesem Fall sollte der P4 Provider so einge-stellt werden, dass er nur Verbindungen vom lokalen System (IP Adresse 127.0.0.1 "lo-calhost") zulässt. Mit dieser Maßnahme kann erreicht werden, dass nur Administratoren, die bereits Betriebssystemzugriff haben, auch die Verbindung zum P4 Provider aufbauen können.

Dieselbe Maßnahme kann zur Absicherung des Telnet Providers dienen, der aufgrund des viel geringeren Ressourcenbedarfs im Vergleich zum Visual Administrator bei einem hän-genden System gute Dienste leisten kann.

Enterprise Portal Das Enterprise Portal (EP) 6.0 ist derzeit die wichtigste verfügbare Applikation für den SAP Web AS Java Stack. Zusätzlich zu den Komponenten des Java Stack werden mit der In-stallation des EP eine Vielzahl neuer Applikationen installiert. Um verschiedene Zugriffspri-vilegien der Benutzer abbilden zu können, verwendet das EP das Konzept der Portalrollen

2 siehe SAP Hinweis 724719 3 siehe SAP Hinweis 531495


15

und Sicherheitszonen. Die Portalrollen steuern die zugreifbaren Komponenten und Menü-einträge innerhalb der Portaloberfläche für die Benutzer. Verwendet ein Benutzer oder Angreifer jedoch die direkte URL einer Portalanwendung, so greift das Konzept der Si-cherheitszonen. Im SAP Enterprise Portal 6.0 sind die folgenden Sicherheitszonen defi-niert:

Sicherheitszone Beschreibung

No Safety Anonymer Zugriff wird auf Komponenten dieser Zone erlaubt.

Low Safety Ein Benutzer muss als Portal Benutzer angemeldet sein, um auf Kom-ponenten dieser Zone zugreifen zu können.

Medium Safety Ein Benutzer muss eine bestimmte Portal Rolle innehaben, um auf Komponenten dieser Zone zugreifen zu können.

High Safety Ein Benutzer muss einer Portal Rolle mit administrativen Rechten zu-geordnet sein, um auf Komponenten dieser Zone zugreifen zu können

Es ist empfehlenswert, alle Portal Komponenten einer Zone >= "Medium Safety" zuzuord-nen, um eine ausreichende Authentisierung sicherstellen zu können.

Standardmäßig erlaubt das SAP Enterprise Portal auch eine Selbstregistrierung von Benut-zern, die nach der erfolgreichen Registrierung Zugriff auf Daten der Low Safety Sicher-heitszone erlangen können. Wenn diese Funktionalität nicht benötigt wird, sollte sie un-bedingt deaktiviert werden, um zu verhindern, dass ein Angreifer in den Besitz einer im System eingetragenen Benutzerkennung kommen kann. Anderenfalls muss die Möglichkeit der Selbstregistrierung im Berechtigungskonzept berücksichtigt werden.

Zur Prüfung der richtigen Zuordnung der Portal Sicherheitszonen kann die folgende URL verwendet werden. Unter dieser URL sind alle installierten Portalapplikationen direkt, d.h. ohne Alias-Zuordnung erreichbar. Mit Hilfe eines entsprechend privilegierten Benutzers kann somit der Ist-Zustand der Sicherheitszonen geprüft werden:

http://<java_server>/irj/servlet/prt/portal/prtroot/PortalAnywhere.Go

Diese Prüfung sollte nach Updates des EP Systems wiederholt werden, da ein Update die Zuordnung von Standardkomponenten ändern kann.


16

Benutzerverwaltung Die Benutzerverwaltung im Java Teil und somit auch dem Enterprise Portal wird zentral durch die User Management Engine (UME) koordiniert. Im Normalfall wird die UME so konfiguriert, dass als Datenspeicher für die Benutzerdaten der zugehörige ABAP Stack verwendet wird. Alternativ können beispielsweise auch Verzeichnisdienste direkt ange-bunden werden. Auf Seite der Java Progamme stellt die UME die Standard Java Schnitt-stelle Authentication and Authorization Service (JAAS) mit SAP spezifischen Erweiterungen bereit. Durch die Zuordnung von Rollen zu Benutzern auf der einen Seite, und Rollen zu Berechtigungsprofilen auf der anderen Seite, wird eine dynamische Konfiguration der Be-rechtigungen ermöglicht, die mit Hilfe der UME Konfiguration steuerbar ist.

Um die Unabhängigkeit zum Datenspeicher zu gewährleisten, stellt die UME eigene Rege-lungsmöglichkeiten für eine Passwort Policy bereit. Diese sollten jedoch nur dann genutzt werden, wenn ein anderer Speicher für die Benutzerdaten als der ABAP Stack verwendet wird. Anderenfalls riskiert man schwer nachvollziehbare Inkonsistenzen z.B. beim Sperr-verhalten von Benutzern.

Falls die UME eines Java Stacks an eine entfernte ABAP Instanz zur Speicherung der Be-nutzerdaten angebunden wird, sollte diese Kommunikation unbedingt verschlüsselt erfol-gen. Hierzu bietet die UME die Möglichkeit, zur Konfiguration von SNC geschützten Ver-bindungen. Die Konfiguration der Verschlüsselung erfolgt im UME Service Abschnitt mit Hilfe des Config Tools.

Aufgrund der Flexibilität der UME, kann ein Enterprise Portal beispielsweise so konfiguriert werden, dass alle internen Benutzer im ABAP Backendsystem verwaltet werden. Externe Nutzer des Portals wie z.B. Kunden oder Partner werden jedoch in einem anderen Daten-speicher getrennt verwaltet. Hier kann beispielsweise ein LDAP Verzeichnis oder die Java Datenbank verwendet werden. Die externen Nutzer des Portals sind somit nicht direkt im ABAP Backend angelegt und bleiben somit besser kontrollierbar.

Für die zentrale Verwaltung von Benutzern im SAP System bestehen verschiedene Mög-lichkeiten. Einerseits bietet der SAP ABAP Stack bereits seit längerem die Möglichkeit der Nutzung der Zentralen Benutzer Verwaltung (ZBV), welche über verschiedene ABAP Sys-teme und Mandanten hinweg Benutzer und deren Berechtigungen pflegen kann. Die Da-ten der ZBV werden in einem vorab definierten ABAP Mandanten gespeichert und verwal-tet. Zur Kopplung an externe Datenquellen besteht hier beispielsweise die Möglichkeit, der Synchronisierung mit LDAP Verzeichnissen verschiedener Hersteller mit Hilfe des LDAP Konnektors.

Bei Nutzung dieser Möglichkeit ist zu beachten, dass der Schutzbedarf des ZBV Systems (und evtl. eines LDAP Verzeichnisses, welches als Quelle dient) automatisch den maxima-len Schutzbedarf der angeschlossenen Systeme erbt. Keinesfalls sollte man also ein Ent-


17

wicklungs- oder Integrationssystem als ZBV System auswählen, wenn produktive Systeme mit mittlerem oder hohem Schutzbedarf angeschlossen werden. Weiterhin sollte man die Verbindung zwischen ZBV und den versorgten Mandanten anderer Systeme mit Hilfe von SNC absichern, falls keine dedizierte Netzwerkverbindung zwischen den Systemen be-steht.

Die Benutzerverwaltung eines Java Stacks (UME) ist wie bereits geschildert noch flexibler und bietet die Versorgung von Benutzerinformationen aus verschiedenen möglichen Quel-len an (z.B. ABAP, Datenbank, LDAP). Wichtig ist hierbei auch, dass diese verschiedenen Quellen miteinander gemischt werden können, d.h. ein Teil der Benutzer oder Benutzerin-formationen kann aus einem LDAP eingespeist werden, während ein anderer Teil aus dem ABAP Backend geliefert wird. In jedem Fall sollten bei entsprechendem Schutzbedarf auch hier die Verbindungen zwischen den Systemen entweder mit SNC oder mit SSL verschlüs-selt werden, um einem Angreifer nicht eine Möglichkeit zur Datenmanipulation oder zum Abhören zu liefern.

Die Authentisierung für Anwendungen im Web AS Java erfolgt mit Hilfe von Logon-Modulen. Diese werden im Visual Administrator mit Hilfe von Templates verwaltet und somit den einzelnen Anwendungen zugeordnet. Da die standardisierte JAAS Schnittstelle zur Integration der Authentisierungsverfahren genutzt wird, können verschiedene Verfah-ren auch parallel genutzt werden. Von Haus aus bietet der SAP Web AS Java neben Pass-wort-Authenti-sierung, auch die Möglichkeit zur Anmeldung mit X.509 Zertifikaten oder SAP Logon-Tickets, die für ein Single-Sign-On zwischen teilnehmenden SAP® Systemen verwendete werden können.

Um maximalen Schutz gegen netzwerkbasierte Angriffe zu erreichen, empfiehlt sich die Verwendung von X.509 Zertifikaten. Diese können entweder aus einer bestehenden Be-nutzer PKI kommen oder mit Hilfe von Drittherstellerprodukten dynamisch generiert wer-den.

Die beiden anderen Verfahren (SAP Logon-Tickets und Passwort-Authentisierung) sollten nur über gesicherte Verbindungen, d.h. HTTPS verwendet werden. Single-Sign-On Funkti-onalität kann mit Hilfe von Drittherstellerprodukten auch auf ABAP Seite erreicht werden, wobei einzelne Lösungen sogar über HTTP und SAP GUI Zugriff hinweg Single-Sign-On bieten können. Je nach Produkt ist dies durch Integration in eine vorhandene Active-Directory Umgebung oder eine Public-Key-Infrastruktur (PKI) möglich. In jedem Fall ist jedoch für die Absicherung der SAP GUI Authentisierung und Kommunikation eine zusätz-liche Bibliothek notwendig, die das SNC Protokoll implementiert. Auf HTTP Seite, also für die Implementierung von SSL/HTTPS kann die kostenlose SAPCRYPTOLIB sowohl für den ABAP, als auch Java Teil des SAP Web AS verwendet werden.


18

Protokollierung Um im Falle eines Sicherheitsvorfalls die Handlungen eines Angreifers durchgängig nach-vollziehen zu können, ist ein Logging-Konzept hilfreich. In diesem Konzept sollten die fol-genden Fragen beantwortet werden: • Auf welchen Komponenten fallen Log-Daten an und welche Informationen werden

dort gespeichert? Eine Logdatenkette könnte beispielsweise wie folgt aussehen: (1) Firewall; (2) Reverse Proxy; (3) SAP Web AS ICM; (4) SAP Web AS Java; (5) SAP Web AS ABAP

• Können diese Informationen tatsächlich miteinander korreliert werden? Stehen immer Zeitstempel zur Verfügung und sind die Zeituhren auf den Systemen synchron? Wie können die Daten korreliert werden, wenn viele verschiedene Client Anfragen parallel abgearbeitet werden, existiert z.B. ein Unique-Client Identifier?

• Werden die Benutzer auch im Backend mit personalisierten Accounts angezeigt, oder wird ein technischer Benutzer für die Verbindung genutzt?

• Wer kann wie auf die Log-Daten zugreifen? Werden hier auch personenbezogene Da-ten gespeichert?

• Wie lange werden die Logdaten auf den einzelnen Komponenten vorgehalten? Wer-den die Daten im Anschluss gelöscht oder archiviert?

Die anfallenden Log-Daten sollten regelmäßig ausgewertet werden, um besondere, evtl. sicherheitsrelevante Situationen schneller identifizieren zu können. Bei Bedarf kann in SAP® Systemen mit entsprechendem Schutzbedarf das SAP Audit Log aktiviert werden. Zusätzlich können einzelne Tabellen (z.B. die User-Stammdaten gesondert überwacht werden.

Im Rahmen eines Incident Managements können die entsprechenden organisatorischen Prozesse definiert werden, wie mit bestimmten Arten von Vorfällen umzugehen ist. Es muss also definiert werden, wer bei welchen Ereignissen informiert wird und wie der Vor-fall eskaliert werden kann.


19

Zur Prüfung, ob die Logdatenkette im Bedarfsfall tatsächlich alle notwendigen Informatio-nen beinhaltet, kann eine fehlgeschlagene Geschäftstransaktion, die z.B. in einer Portal-Anwendung ausgelöst wird, verwendet werden. Prüfen Sie hier ausgehend von der Audit Fehlermeldung im SAP ABAP System, ob Sie die folgenden Informationen durch Korrelati-on der Logdaten ermitteln können:

• Art des Vorfalls • Grund der Aufzeichnung des Vorfalls im ABAP System • Benutzername im ABAP System • Zeitpunkt des Vorfalls auf allen beteiligten Komponenten • Portal/Java Anwendung • Benutzername im Portal bzw. dem SAP Web AS Java • IP Adresse des Benutzer-Webbrowsers • Optional: URL-Referer und Art des Benutzer-Webbrowsers

Entwicklung Für die Anwendungsentwicklung innerhalb des SAP Web AS Java, stellt SAP mit der Net-Weaver® Development Infrastructure (NWDI) eine Entwicklungsumgebung zur Verfü-gung, die neben den Entwicklungsprozessen auch die Konsolidierung, Freigabe und den Transport einer Java Anwendung unterstützt.

Diese Umgebung verwendet den Software Deployment Manager (SDM), um die Java Pro-grammpakete auf einem SAP System zu installieren. Der SDM besteht aus einem Java-Client Programm und einem eigenständigen Server, der parallel auf dem zentralen SAP Web AS mitläuft. Hierbei ist zu beachten, dass der SDM derzeit keine Benutzerverwaltung nutzen kann und der Zugriff auf die Funktionalität nur mit einem Passwort geschützt ist. Um die Installation oder Veränderung von Java Programmen auf einem SAP Web AS durch Unauthorisierte zu verhindern, sollte deshalb sichergestellt werden, dass für diesen technischen SDM Zugang ein ausreichend komplexes Passwort verwendet wird. Eine Bru-te-Force-Attacke auf dieses Passwort wird dadurch wirksam verhindert, dass der SDM standardmäßig nach drei Anmeldeversuchen, mit dem falschen Passwort seinen Dienst einstellt und auf Betriebssystemebene neu gestartet werden muss.

Im Normalfall wird der SDM Server durch die NWDI Umgebung gesteuert, in der das Passwort für den Zugang zum jeweiligen SDM hinterlegt sein muss. Hier sollte natürlich sichergestellt werden, dass das hinterlegte Passwort gegen unauthorisierten Zugriff abge-sichert wird.


20

Weitere Maßnahmen Falls im Rahmen einer Anwendung auf einem SAP Web AS ein Dateiupload möglich ist (z.B. im Content Server), kann mit Hilfe der Anti-Viren-Schnittstelle eine Scan-Engine an-gebunden werden. Diese Möglichkeit sollte genutzt werden, um beispielsweise die Verbreitung von Macro-Viren eindämmen zu können. Dies ist insbesondere dann notwen-dig, wenn Dateien von firmenfremden Clients hochgeladen werden können, da hier meist nicht sichergestellt werden kann, dass der entsprechende Windows PC durch eine aktuelle Antiviren-Software abgesichert ist.

Besonders bei Web-Anwendungen mit hohem Schutzbedarf, die die SAP Web AS Java Plattform nutzen, ist es empfehlenswert einen fokussierten Penetrationstest auf diese Anwendung durchzuführen.

Penetrationstests untersuchen IT-Systeme auf allen technischen Ebenen durch gezieltes Aufspüren und Ausnutzen von Schwachstellen. Der Fokus der Untersuchung kann dabei individuell festgelegt werden. So reicht das Spektrum beispielsweise von breitflächig an-gelegten Analysen von System- und Netzumgebungen bis hin zur Untersuchung detaillier-ter Fragestellungen auf SAP Anwendungsebene. Neben dem rein technischen Einsatzge-biet können Penetrationstests auch auf sozialer Ebene verwendet werden, um bei Prozes-sen die Einhaltung von Richtlinien zu überprüfen. So kann beispielsweise durch Social Engineering das Sicherheitsbewusstsein von Mitarbeitern getestet werden.

Penetrationstests bilden darüber hinaus eine sinnvolle Ergänzung zu Audits bzw. bei der Überprüfung von Service Level Agreements, um die Umsetzung von Vorgaben konkret zu verifizieren.

Als Ergebnis liefern Penetrationstests stets konkrete Aussagen zum aktuellen Sicherheits-zustand des Untersuchungsgegenstandes und geben so wertvolle Hinweise zur aktiven Steigerung der Sicherheit.


21

SAP@Secaron

Die Berater der Secaron unterstützen Sie gerne bei der Planung, Umsetzung und Prüfung der Sicherheit für Ihre SAP Systemlandschaft. Im Folgenden ein Auszug aus dem Dienstleis-tungsportfolio der Secaron rund um SAP:

• Beratung bei der Definition ausgewogener, d.h. wirtschaftlich und sicherheitstech-nisch sinnvoller Sicherheitsziele

• Umsetzung Ihrer strategischen Sicherheitsmanagementziele, z.B. durch Bereitstel-lung von Methodiken und Tools für

• systematische Verwaltung von Sicherheitsanforderungen

• Überwachung der Maßnahmenumsetzung

o sicherheitstechnische Betreuung und Beratung von SAP Projekten

o die sichere Produktivschaltung neuer Systeme und Anwendungen

o regelmäßige Systemprüfungen

• Erstellung und Pflege von Schutzbedarfs-, Bedrohungs- und Risikoanalysen zusam-men mit den Prozess- und Datenverantwortlichen

• Erstellung eines maßgeschneiderten Sicherheitskonzeptes für Ihre SAP Systemland-schaften und angebundene IT-Systeme, unter Berücksichtigung des individuellen Schutzbedarfs und bestehender Sicherheitsvorgaben

• Aufbau einer zentralen Identity Management Lösung und Integration Ihrer SAP- und Legacy Systeme

• Aufbau von Single-Sign-On Lösungen und Lösungen zur starken Authentisierung Ih-rer Benutzer an SAP- und Legacy Systemen

• Aufbau von Public-Key-Infrastrukturen (PKI) zur Authentisierung, Verschlüsselung (SNC) oder Signatur (SSF) in SAP® Systemen

• Implementierung von Best-Practice Sicherheitsmaßnahmen für SAP NetWeaver® und alle gängigen Betriebssystem und Datenbankplattformen

• Auditierung von SAP Applikationen, Servern, Datenbanken und Betriebssystemen gegen Best-Practice Anforderungen sowie Ihre firmeneigenen Sicherheitsrichtlinien

• Penetrationstests und Sourcecodereviews

Date post:	14-Sep-2019
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

wp SAP 200702 FM Gredel - files.vogel.de · Secaron AG, Whitepaper: SAP Netweaver® Sicherheit 2...

Documents