Für SAP HANA werden in den kommenden Jahren viele neue interessante Anwendungen entstehen, die die Stärken und Eigenschaften dieser leistungsfähigen Plattform ausreizen. Sie werden hochkritische Daten verarbeiten und über vielfältige Schnittstellen mit der Außenwelt verbinden. Diese Anwendungen müssen nicht nur stabil und performant laufen, sondern auch ausreichend abgesichert sein. Durch die Integration von Prüfungen in die HANA-Entwicklungsumgebung werden Fehler frühestmöglich vermieden, Entwickler interaktiv geschult und so die Kosten durch Fehler nachhaltig minimiert.
In dieser Präsentation besprechen wir einige wichtige Aspekte für die Entwicklung von HANA-Anwendungen:
- Was Sie bei der Entwicklung von HANA-Anwendungen beachten müssen
- Wie Sie mit dem HANA Code Scanner in Eclipse und beim Web-Based Development:
- Wie Sie Fehler und Schwachstellen während der Entwicklung vermeiden
- Wie Sie Ihr HANA-Coding auf Performance, Stabilität und Sicherheit trimmen
3. 3
Einführung
Warum HANA für die SAP so wichtig ist
Strategische Lösung
S/4 HANA „wichtigste Innovation seit R/3“
Alle neuen und Bestandskunden sollen mittel- bis langfristig auf
HANA umsteigen
HANA wird sich als Entwicklungsplattform etablieren
4. 4
HANA Installationsszenarien
„HANA as a data mart“
Vergleichbar mit „klassischem“ BW-Szenario, HANA
sammelt Daten von (verschiedenen) Quellsystemen
3-stufiges Szenario mit HANA
HANA ersetzt die „normale“ Relationale Datenbank
HANA als technische Infrastruktur für native Applikationen
Neue Anwendungsplattform (S/4 HANA)
6. 6
Einführung
Warum HANA für Hacker interessant ist
Inhaltliche Überlegungen
HANA enthält kritische Geschäftsdaten Spionageziel
HANA ist wichtig für die Geschäftsprozesse
Sabotageziel
Technologische Überlegungen
Betrugsmöglichkeiten
IT- / Sicherheitsabteilungen haben mit HANA wenig
Erfahrung
9. Schwachstellen können sein:
XSS, SQL injection, ABAP code
injection
9
Webanwendungen
SAP HANA Systeme können einfach im
Internet gefunden werden
Unberechtigter Zugriff möglich
Services können mißbraucht werden
SAP HANA ist für typische Web-
Angriffe verwundbar
10. Priviligierte Berechtigungen sind
automatisch aktiviert, z.B.
Betriebssystemkommandos
10
R-Serve
R wird für statistische und erweiterte
Datenanalysen verwendet
SAP HANA kann mit R-Serve verbunden
werden um R-Funktionalitäten
aufzurufen
R-serve ist ein getrennter Host,
remote functions müssen
aktiviert werden
11. ABAP Entwicklungen müssen auf
Schwachstellen überprüft werden
11
Eigenentwicklungen
SAP HANA Anwendungen sind über den
Browser aufrufbar
Neue Programmiersprachen - erhöhte
Komplexität in der Entwicklung
Webanwendungen müssen auf
allen Ebenen abgesichert
werden
13. Herausforderungen HANA Entwicklung13
Für ABAP Entwickler neue Programmiersprachen:
JavaScript
SQLScript
R
Komplexes Rollenmodell
JavaScript Entwicklern fehlt (Enterprise) Sicherheits-Know How
Ihr Code – Ihre Verantwortung
!
15. 15
Virtual Forge HANA Security Suite
ABAP-Code für HANA optimieren (CodeProfiler)
HANA Testfälle (HANA Readiness & Optimization)
Automatisierte Korrektur („Quick Fix“ und ACE)
HANA Konfiguration absichern (SystemProfiler´)
Weitere Plattform für SystemProfiler
Testfälle, z.B., e.g. Passwort-Parameter, Berechtigung, weitere
CodeProfiler für HANA (CP4H)
Eclipse und Web DIE Integration
Weltweit erster HANA Code Scanner
16. 16
Virtual Forge CodeProfiler for HANA (CP4H)
Unterstützt SQLScript und XSJS
Direkte Integration in Eclipse und WebIDE
Inkl. Dokumentation und Lösungsansatz
Umfassende Testfälle (22 für XSJS, 17 für SQLScript, Stand
08/2015)
In Zukunft: Unterstützung von UI5 und R
Weitere Integrationsszenarien (HANA Projekte, CTS+, Finding
Management, Cockpit)
17. SAP Sicherheit und Qualität
Wissen was zu tun ist: initiale Risikobewertung17
Machen Sie den Sofort-Test
Besuchen Sie
www.virtualforge.com
Qualität
Compliance
Sicherheit
Sichere
SAP® -
Systeme
Risikobewertung /
Penetrationstest
• SAP Konfiguration
• Eigenentwicklungen
18. Haben Sie Fragen oder Anmerkungen?
Danke für Ihre Aufmerksamkeit18
Patrick Boch
www.virtualforge.com
@Virtual_Forge
Notas do Editor
Different implementation scenarios with different implications regarding security:
Data mart – data only replicated, still sensible data on there, but no processes. However: will probably be viewed with external / mobile devices (management)
3-tier: replacement for regular database, therefore all security considerations of a regular 3-tier need to be taken into account
Plattform: means: has its own security toolset, own connections to other systems, own settings, makes everything more complex, see next slide
Interesting for hackers, as business data are on HANA, reporting means lots of data coming through HANA, with S/4 also processes will be on HANA, along with all data – we will see later why this is important
Technology wise: HANA is fairly new, especially as an application platform, which means fraud will likely not be detected as easily because some security issues have not been taking into account by IT / Security yet
How complex SAP HANA really is –
Also more standard web technologies, including all security issues and settings which need to be taken care of
Most applications on HANA will be Webapplications
The URL-structure is betraying HANA in some instance – developer studio can be found on the internet
If HANA is accessible from the outside, unauthorized access is possible
Services will be misused_ Hackers will probably try all available methods for attacking websites with HANA
(will become more interesting with RAM-Scraping)
R: statistical programming language, open source, used for data analysis
R-serve: TCP/IP server allowing HANA to use R
Getrennter Host, remote functions, privileged authorization:
SSL communications
Secure authentification
Low privileges
Custom development:
ABAP security flaws still in there plus
Web developments (SQL injection, XSS, as seen on previous slide)
i.e. enlarged danger
All security featuers need to be followed:
SSL
Authentification: one good HANA feature: Not a single db user, but web user = db user, therefore less privilege than with regular web apps
Interesting for hackers, as business data are on HANA, reporting means lots of data coming through HANA, with S/4 also processes will be on HANA, along with all data – we will see later why this is important
Technology wise: HANA is fairly new, especially as an application platform, which means fraud will likely not be detected as easily because some security issues have not been taking into account by IT / Security yet
Interesting for hackers, as business data are on HANA, reporting means lots of data coming through HANA, with S/4 also processes will be on HANA, along with all data – we will see later why this is important
Technology wise: HANA is fairly new, especially as an application platform, which means fraud will likely not be detected as easily because some security issues have not been taking into account by IT / Security yet