SAP Infotag: Security / Erlebe-Software 07-2014

copyright by mindsquare GmbH
| We love IT!
Sicherheit im
eigenen Haus
mindsquare Infoveranstaltung
Ingo Biermann
02.10.2014 Wir sind mindsquare – We love IT! Seite 1

Security für Business-Systeme
Ist Sicherheit im Bereich der Geschäftssysteme
überhaupt ein Thema?
02.10.2014 mindsquare – We love IT! Seite 2

Woher kam die Fehleinschätzung?
„Unser ERP ist nur intern verfügbar.“
„Hacker kennen sich mit SAP gar nicht aus.“
„Sicherheit ist Sache des Lieferanten.“
„Wir haben ein Berechtigungskonzept.“

Mythos 1: Nur intern verfügbar
Unser SAP System ist nur intern im Haus zugreifbar.
Wie soll ein Angreifer überhaupt drankommen?
Das galt früher einmal, heute:
Webserver stehen im Internet
 Online Datenaustausch mit Geschäftspartnern
Serviceverbindung zur SAP
 Clients der Anwender sind mit dem Internet verbunden

Mythos 2: Hacker kennen sich damit nicht aus
Hacker-Kids bedrohen nur die populäre Software:
Windows, Handys, usw.
Gilt nicht im kommerziellen Umfeld:
 Motivation für Angriffe: Was kostet mich das und was
gibt es zu gewinnen?
Bei Know How Abfluss sind 70% sogenannte
Innentäter*
*Quelle: Bundesamt für den Verfassungsschutz, 2010

Mythos 2: Hacker kennen sich damit nicht aus
Hacker-Kids bedrohen nur die populäre Software:
Windows, Handys, usw.

Mythos 3: Sicherheit ist Sache des Lieferanten
Um die Sicherheit der SAP Systeme
kümmert sich SAP
Security Patches der SAP werden in der Regel nicht
vollständig und sofort eingespielt
 Jeder SAP Kunde hat mehr oder
weniger große Teile
Eigenentwicklungen im System
Am Ende ist das Unternehmen
verantwortlich, das den Code
ausführt

Mythos 4: Rollen und Berechtigungen reichen aus
Wir haben ein Berechtigungskonzept!
Hervorragend! Darüber hinaus gilt:
 im Bereich Eigenentwicklung
müssen Berechtigungen explizit geprüft werden
Entwickler
machen Fehler

Sicherheit im eigenen Haus
Die einfachen Dinge
richtig machen!

Typische Architektur
von SAP Anwendungen:
Jede dieser Ebenen ist
für die Sicherheit
relevant.
Das eigene Haus
Access Layer
Applikations UI
Services
Standard Business Logik
Datenbank

Die häufigsten Schwachstellen im ABAP Coding
 ABAP Command Injection
 OS Command Injection
 Native SQL Injection
 Improper Authorization
 Directory Traversal
 Direct Database Modifications
 Cross-Client Database Access
 Open SQL Injection
 Generic Module Execution
 Cross-Site Scripting
 Obscure ABAP Code
Dazu SAP Notes: 1520356, 887168, 944279, 822881, 1497003
Quelle: http://www.bizec.org/wiki/BIZEC_APP11

Problemklassen
Einfacher gesagt:
Es gibt zwei entscheidende Problemklassen:
1. fehlende oder fehlerhafte Berechtigungsprüfungen
2. Injection Probleme

Fehlende oder fehlerhafte Berechtigungsprüfung
Es liegt in der Verantwortung des Entwicklers, die
Berechtigungsprüfung auszuführen.
Ein Beispiel:
Der Befehl CALL TRANSACTION führt eine Transaktion
aus. Ohne Berechtigungsprüfung.
Die Prüfung mit AUTHORITY_CHECK_TCODE ist dem
Entwickler überlassen.

Fehlende oder fehlerhafte Berechtigungsprüfung

Authority Check

ABAP Authority Check
Berechtigungsprüfung mit dem ABAP Mechanismus
Authority Check.
 keine eigene Berechtigungsprüfung
If sy-uname eq 'SNOWDEN'
 Weitere SAP API nutzen
 immer explizit programmieren
 alle Felder füllen (Pattern nutzen)
 Das Wichtigste: Die Rückgabe
auch prüfen!

SQL Injection

Robustheit der Anwendung
Diese Probleme lassen sich auf das Prinzip der
Robustheit zurückführen.
Robustheit im Allgemeinen heißt
 Fehler müssen richtig behandelt werden.
 dazu gehört auch die Prüfung von Berechtigungen
 Änderungen im Umfeld nicht berücksichtigt
sich nicht darauf verlassen, das Daten immer den Gut-Fall
wiederspiegeln

Robustheit der Anwendung
Robuste Anwendungsentwicklung:
 Zusatzaufwand beim Design
 Zusatzaufwand bei der Entwicklung
 Zusatzaufwand beim Testen
Aufwand zahlt sich aus „on the long run“
 Nicht nur aus Sicherheitsgründen
 auch bzgl. Datenqualität
 Aufräumarbeiten in den Daten sind extrem aufwändig

Die einfachen Dinge richtig machen
Grundsätze für die robuste Entwicklung
 Durchgehende Fehlerbehandlung. Auch im Batch.
 sy-subrc immer prüfen, genau wie andere Rückgabewerte und
Exceptions auch
 Variablen initialisieren
 Eingaben validieren, bevor sie verwendet werden
 Keine hart codierte Abhängigkeiten und Voraussetzungen
 Alles testbar machen
 Jeder Codeteil wird durchlaufen
 systematische Testfälle
 automatisierte Tests

Werkzeuge für Code Qualität
Die Werkzeuge dafür sind
 Entwicklungsrichtlinien und Checklisten
 Changemanagement Prozesse: Testmanagement, Code Reviews
 Automatische Codeprüfung
 Syntax Checker > SLIN > SAP Code Inspektor
 Eigene Erweiterung des Code Inspectors
 umfangreiche kommerzielle Tools zur Codeanalyse

Die Umsetzung
Code Qualität wird im Entwicklungsprozess angelegt
Die Einführung kann nur schrittweise erfolgen:
 Definition von Zielen und der Roadmap
 Schulung und Know How Aufbau bei Entwicklern
 Einphasen in den Entwicklungsprozess für Neuentwicklungen
 Aufräumarbeiten im bestehenden Coding
 Kontinuierliche Prüfung
 Get Clean  Stay Clean

für die Sicherheit
relevant.
Das eigene Haus
Access Layer
Applikations UI
Services
Datenbank

Know the link!

Webbasiertes UI
Webapplikationen haben ein neues Angriffsfeld
eröffnet und weiten sich immer weiter aus.
SAP Web Dynpro, SAP BSP, SAP UI5 Anwendungen
sind per URL aufrufbar.

Kiss of Death für Java Web Dynpro

Webbasiertes UI
Webapplikationen haben ein neues Angriffsfeld
eröffnet und weiten sich immer weiter aus.
SAP Web Dynpro, SAP BSP, SAP UI5 Anwendungen
sind per URL aufrufbar.
„Security by obscurity“
ist hier kein valides Konzept.

Berechtigungsprüfung bei Web Dynpro ABAP
ABAP GUI Transaktionen sind durch die S_TCODE
Berechtigung geschützt.
Für Web Dynpro Applikationen gilt das per Default nicht.
Aufruf des ersten Bildes ist möglich.

Web Dynpro ABAP Beispiel

Berechtigungsprüfung bei Web Dynpro ABAP
 Eigene Berechtigungsprüfung einbauen
 S_START für Web Dynpro aktivieren (ab Basis
Releases 7.03 and 7.30).
Bitte vorher die Rollen entsprechend anpassen!

SAP Screen Personas
[bild]

SAP Screen Personas
 Macht SAP GUI Transaktionen webfähig und individuell gestaltbar
 Verringerung der Komplexität
 Verbesserung der Übersichtlichkeit
 Teilautomatisierung von Abläufen
 ohne Programmierung
 ideal für den Rollout auf neue Benutzergruppen und Gelegenheits-
User
 Mit aktueller SAP Business Suite kostenlos verwendbar

SAP Screen Personas
Was bedeutet das für die Sicherheit?
 Bei einer neuen Oberfläche mit Web Dynpro oder SAP UI5 werden
die Berechtigungsprüfungen des Servicelayers verwendet und die
Oberfläche neu geschrieben
 Screen Personas verändert nur das Erscheinungsbild
 Berechtigungsprüfungen und Eingabeprüfungen der bestehenden
GUI Implementierung bleiben aktiv
 Informieren Sie sich über unsere Lösung: SAP endlich
benutzerfreundlicher mit SAP Screen Personas
http://erlebe-software.de/solutions/sap-screen-personas

für die Sicherheit
relevant.
Das eigene Haus
Access Layer
Applikations UI
Services
Datenbank

Portal und NWBC als L-Shape Technologie
Auf der obersten Ebene definieren Portal und NWBC
den Einstiegspunkt für die Anwender
 single Point of access
 role based access
 single sign on

Single Sign On Architektur
In einer Portallandschaft spielt das zentrale System ein
besondere Rolle
 wegen des SSO ist es die einzige Autorität für Authentifizierung
 wegen der fehlenden Datenhoheit gar keine Autorität für
Autorisierung
 Portalberechtigungen sind keine Berechtigungen

Beispiel: Universal Worklist
Die UWL führt Workflow-Aufgaben aus verschiedenen
Systemen zusammen.
Jedes Backendsystem muss beim Serviceaufruf testen,
ob und was der Anwender sehen darf.
Jedes Applikations-UI muss prüfen, ob der Anwender eine
Aktion durchführen darf.

Beispiel Universal Worklist

Single Sign On Architektur
Warum ist SSO trotzdem ein Sicherheitsgewinn?
Usability bringt auch Sicherheit
 Nur ein Passwort
 oder mit PKI gar kein Passwort
 Anwender nutzen weniger einfache Passworte und nicht überall
das Gleiche
 Passwort wird nur einmal übertragen
 Zentrale Möglichkeit zum Sperren

Die einfachen Dinge falsch machen…
Beispiel:
Wer Usermanagement-Berechtigungen im zentralen
System hat, kann sich lokale User anlegen.
Damit ist SSO in weitere Systeme möglich
 Identitätsklau

SAP WebFlow Connector Non-SAP-UWL-Connector
SAP Portal

SAP WebFlow Connector Non-SAP-UWL-Connector
SAP Portal
Wer bist du?
Was darfst
du?

für die Sicherheit
relevant.
Das eigene Haus
Access Layer
Applikations UI
Services
Datenbank

Sicherheit im eigenen Haus
Die einfachen Dinge
richtig machen!

Fazit
Die einfachen Dinge richtig machen
 Code Quality im Entwicklungsprozess verankern
 SAP Berechtigungsmechanismen nutzen
 User Interface Technologien nicht vergessen
 SSO Infrastruktur aufbauen

Custom Solutions – Ihre Lösung!
Nur Sie wissen mit welcher passgenauen Erweiterung
Sie Ihr SAP noch besser machen können.
Wir sind Ihr Dienstleister für diese neue SAP Applikation.
Von der Idee bis zum erfolgreichen Go Live:
 Schon in der Ideenphase unterstützen wir Sie
bei der Definition der Anforderungen
 Die Konzeption und Umsetzung erfolgt durch unsere SAP Experten
 Sie erhalten die Komplettlösung – Ihr Projekt machen wir zu
unserem Projekt
 Mit professionellem Projektmanagement
sicheren wir den Projekterfolg
02.10.2014 Wir sind mindsquare – we love IT! Seite 48

Auf unserer Fachbereichsseite finden Sie
unser Angebot, viel Know How und Artikel
von unserem Team: http://erlebe-software.de
Seite 49
Ihr Ansprechpartner
Ingo Biermann
Senior SAP Consultant
Fachbereichsleiter
biermann@mindsquare.de
Wir sind 02.10.2014 mindsquare – we love IT!

SAP Infotag: Security / Erlebe-Software 07-2014

Weitere ähnliche Inhalte

Andere mochten auch

SAP Infotag: Security / Erlebe-Software 07-2014

Hinweis der Redaktion