SAP Systeme absichern und schützen

Wer eine umfangreiche SAP-Systemlandschaft betreibt, sorgt sich immer öfter um die Sicherheit der sensiblen betriebswirtschaftlichen und personellen Daten, die in diesen Systemen hinterlegt werden.

IT-Security, und ein SAP-Umfeld bildet hier keine Ausnahme, ist ein iterativer Prozess, der stufenweise erfolgt und immer wieder ausgebaut werden sollte. Wer sich irgendwann auf seinen Lorbeeren ausruht und aufhört, seine IT-Sicherheit voran zu treiben, macht sich schnell angreifbar.

Gerade in SAP-Systemlandschaften rückt das Thema Security mehr und mehr in den Hintergrund. Die Zeiten, in denen SAP-Systeme noch abgeschottet von der Außenwelt im Data Center des Kunden verbracht haben, sind vorbei. Mehr und mehr sind SAP-Applikationssysteme untereinander und mit externen Fremdsystemen, beispielsweise von Finanz- und Zollbehörden, vernetzt. Und immer mehr SAP-Systeme werden heutzutage in die Cloud ausgelagert – und sind dadurch grundsätzlich erst einmal von außen für Angreifer zugänglich.

Das muss aber nicht heißen, dass IT-Security ein Aufgabengebiet sein muss, welches durch Angst und Schrecken beherrscht wird. Stattdessen sollte man IT-Security immer als Studium sehen, in welchem man man versucht, die Wirtschaftlichkeit von IT-Systemen durch ein abgestimmtes Zusammenspiel von Sicherheit und Effizienz zu gewährleisten. Und die Bandbreite dieses Studiums ist groß, denn sie beinhaltet nicht nur Themenfelder der Technik, sondern auch der menschlichen Psychologie und der Betriebswirtschaftslehre, die es zu beachten gilt. Akzeptanz und Wirtschaftlichkeit einer Sicherheitsmaßnahme im Verhältnis zum Risiko muss genau so akribisch verbessert und bewertet werden wie die immerwährende Absicherung der Technik. Jede implementierte Sicherheitsmaßnahme hat Auswirkungen auf die Performance, die Kosten, die Akzeptanz und die Effizienz von IT-Systemen. Insbesondere in SAP-Systemen, die dazu gedacht sind, die Total Cost of Ownership (TCO) der Informationstechnik des Kunden zu reduzieren, muss hier ein wahrer Balanceakt aus Aufwand und Sicherheit geleistet werden, der vielen besorgten Sicherheitsverantwortlichen schwer fällt.

Gute Leitfäden zum Absichern von SAP Systemen gibt es bereits an vielen Stellen schon kostenlos im Internet. Beispielsweise veröffentlicht die deutschsprachige SAP-Anwendergruppe DSAG jährlich einen Sicherheitsleitfaden, der bereits die häufigsten Angriffsvektoren aufdeckt und Lösungsansätze aufzeigt. Ebenso ist der DSAG Leitfaden für Datenschutz ein sehr hilfreiches Dokument vor allem im HR-Bereich.

Und auch von SAP selbst gibt es bereits sehr umfangreiche Security Guides. Die wichtigsten im aktuellen Umfeld sind der SAP HANA Security Guide, der SAP ERP Central Component Security Guide sowie der SAP NetWeaver Security Guide.

Nachdem man diese Standardwerke einmal durchgekaut hat sollte eine erste Prüfung stattfinden, die schon einmal sicherstellt, dass die Angriffsvektoren, die diese Anleitungen abdeckenn, schon einmal gedeckt sind. Eine gute Möglichkeit ist eine Prüfung der IT-Systemlandschaft durch ein unabhängiges Tool einer Drittpartei, die weder vom Betreiber der Systemlandschaft noch vom Softwarehersteller SAP bereitgestellt wird. Ein gängiges Tool in dieser Kategorie ist beispieslweise der Werth IT Auditor. Dieser testet ein SAP-System primär auf die Erfüllung der Standards, die in den SAP Security Guides sowie in dem DSAG Sicherheitsladen definiert wurden – und wurde aufgrund seiner Gründlichkeit im Jahr 2014 ausgezeichnet. Das Tool ist nicht für den SAP-Endanwender gedacht, sondern kommt häufig in Verbindung mit der Beratungsleistung eines externen SAP-Beratungshauses. Aufgabe des Beratungshauses ist es sicherzustellen, dass die Ergebnisse des Auditor-Tools zutreffend sind und die Umsetzung eventueller Gegenmaßnahmen nicht nur technisch möglich und durch diesen beratend unterstützt wird, sondern auch wirtschaftlich effizient und aus Kostensicht zu rechtfertigen ist. Denn zu guter letzt muss immer das Kundenumfeld betrachtet werden. Das Risiko des Kunden, einen definierbaren finanziellen Schaden durch einen möglicherweise vorhandenen Angriffsvektor zu erleiden, muss die hierzu erforderliche Gegenmaßnahme immer rechtfertigen.

Desweiteren stellt das Beratungshaus sicher, dass das Resultat des Werth Auditors ein für das Management nachvollziehbares Ergebnis abliefert, nach welchem der Projekterfolg gemessen werden kann.  Hierzu eliminiert der Berater eventuelle False Positives, die ein falsches Gefahrenpotential darstellen, und sichtet außerdem die durch das Tool als unkritisch bewerteten Checks, um das umgekehrte Szenario ebenso zu vermeiden. Ebenso stellt der Berater hier häufig das Projektergebnis im IT-Management vor und hinterlässt dem Systembetreiber eine technische Dokumentation, welche die Maßnahmen zur Vermeidung aktueller und künftiger Angriffsvektoren bespricht und verständlich darstellt.

Da sich das Tool an den Standard des aktuellen DSAG-Sicherheitsleitfadens orientiert, wird es jährlich erneuert und aktualisiert. Für den Endkunden beduetet dies, dass er einen solchen Security-Audit wenn schon nicht jährlich, dann aber in jedem Fall regelmäßig und stetig wiederholen sollte, um immer den aktuellen Sicherheitsstandards in diesem Bereich zu genügen.

Doch auch zwischen diesen Phasen lohnt es sich, über den Tellerrand der definierten Sicherheitsstandards hinaus zu blicken und seine Systeme in einem fortlaufenden Entwicklungsprozess zu härten und zu testen.

SAP Systeme absichern und schützen weiterlesen →

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

SAP HANA – Aktuelle Migrations- und Implementierungsszenarien

SAP fährt derzeit eine sehr aggressive Produktpolitik im Bezug auf HANA. Und auch, wenn HANA grundsätzlich kein Wufffffnderkind ist und durchaus nicht ohne Konkurrenz auf dem markt steht – das Konzept ist schlüssig – und die Möglichkeiten für den Endanwender vielversprechend.

Aktuelle SAP HANA Business Cases

die Gründe, warum immer mehr SAP-Kunden auf HANA wechseln, sind vielschichtig. Viele Kunden wollen auf der Höhe der Zeit stehen und nicht den Aufsprung auf die aktuelle SAP-Produktpalette verpassen. Strategien, welche die Produkte SAP BW on HANA, CRM on HANA, Simple Finance 2.0 und letztendlich auch S/4HANA beinhalten, sind ohne HANA gar nicht mehr möglich. Und eine solche Strategie hat auch seine Vorteile. Das neue Datenmodell unter Simple Finance 2.0 verschlankt das Datenvolumen von SAP ERP enorm, und CRM on HANA verspricht einen enormen Performancegewinn, der in Zukunft ein essentieller Treiber für zeitgemäße Analysen im Bereich der Customer Segmentation sein wird.

Aber auch die SAP-Produktpolitik ist in an dieser Stelle sehr fordernd. Das Fiori Gateway für S/4HANA muss schon jetzt erzwungenermaßen auf einer drei SAP Datenbanken MaxDB, SAP ASE oder SAP HANA laufen.

Wer SAP HANA einführt, sollte sich grundsätzlich Gedanken über das gesamte SAP Data Management-Produktportfolio machen. mit dem SAP Event Stream Processor können Sie mit einem kompetenten Entwiclkungsteam permanente Informations-Ströme (beispielsweise von den Sensoren der Windkraftanlagen eines Windparks) filtern und verarbeiten. Die gefilterten Daten können dann in einer SAP HANA Datenbank persistiert und von dort aus auf lokale SQL Anywhere-Datenbanken geladen werden, die es den Entscheidungsträgern ermöglichen, die aktuell für sie relevanten Daten von ihren Mobilgeräten aus einzusehen.

SAP Solution Manager als erstes HANA-Einführungsprojekt

Wer sich noch unsicher über sein Commitment auf eine HANA-Landschaft ist, dem sei an dieser stelle empfohlen, als erstes ein Migrationsprojekt auf den SAP Solution Manager on HANA zu versuchen. Das Projekt hat den Vorteil, dass keine zusätzlichen Lizenzkosten anfallen, denn eine HANA-Datenbank unter dem Solution Manager ist kostenlos. Eine Migration des SAP Solution Managers als initiales Umstellungsprojekt der HANA Landschaft hat diverse Vorteile. Das Datenvolumen der Solution Manager Datenbank ist erfahrungsgemäß kleiner als bei NetWeaver BW- oder Business Suite-Systemen. So kann man mit einem schlank budgetierten Einführungsprojekt erste Erfahrungswerte mit SAP-Applikationssystemen unter SAP HANA sammeln, ohne zunächst einen allzu großen Einflussfaktor in bestehende IT-Geschäftsprozesse befürchten zu müssen.

Typische HANA-Projektherausforderungen

Mit diesen müssen Sie  bei umfangreicheren Umstellungsprojekten – sie es nun im Rahmen der SAP Business Suite, SAP BW oder S/4HANA – immer rechnen. Neben HANA-spezifischer Anpassungen Ihrer Customer Enhancements und Ihres Codings, um von den Vorteilen SAP HANA In-Memory Computing Engine Gebrauch machen und Ihr Customizing auf das neue Release trimmen zu können, müssen Sie sich auch wieder Gedanken über all die Themen machen, die Sie in ihren bisherigen Applikationssystemen eigentlich schon geklärt hatten. Hochverfügbarkeitskonzept, Security-Konfiguration, Schulung der Mitarbeiter und Administratoren, Ausarbeitung eines Backup & Recoverykonzeptes – all diese Themen kommen auch bei einer Umstellung auf SAP HANA wieder hoch.

Zusätzlich erfolgt mit jeder Einführung eines SAP-Produkts on HANA bestenfalls eine Verschlankung Ihrer Produkt- und Systemlandschaft. Mit der Einführung von S/4HANA bietet es sich beispielsweise an, die Anzahl an ERP-Systemen in der Unternehmenslandschaft zu reduzieren. Mehrere Regionen, die zuvor durch unterschiedliche ERP-Systeme angebunden wurden, werden nun zusammengefasst. Möglicht macht dies das neue Datenmodell und die Auslagerung des operationalen Reportings von in das Fiori Frontend. Dadurch sinkt gleichzeitig die Anzahl der notwendigen OLAP-Systeme. Die Techniken der System Landscape Transformation, der SAP HANA System Replication und des SAP Replication Servers ermöglichen eine solche Zusammenfassung unter geringem Ressourcen- und Zeitaufwand. Zudem wird mit SAP BW on HANA der BW-A (Business Warehouse Accelerator) abgelöst, was ebenfalls zur Einsparung von Systemen in der Unternehmenslandschaft führen kann. Und die S/4HANA Search Engine wird auf vielen Ebenen den Einsatz der TREX Search Engine obsolet machen.

SAP HANA – Aktuelle Migrations- und Implementierungsszenarien weiterlesen →

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

SQL-Statements und Dateisystemänderungen tracen

„Woher zieht der sich den Scheiß?“. Diese Frage schwirrt mir beim Upgrade und bei der Installation von komplexen Enterprise-Technologien immer über den Kopf, wenn Dumps geworfen werden, ohne dass in den Logs irgendwelche aussagekräftigen Informationen stehen würden.

Hierbei kann es oftmals helfen, wenn man mit tracen kann, welche SQL Statements gerade von der automatischen Prozedur auf der Datenbank ausgeführt werden, und welche Dateien auf dem DAteisystem verändert werden.

Dieser Beitrag wird regelmäßig geupdatet, um verschiedene Datenbanken und Dateisysteme abzudecken.

SQL-Statements auf eine Oracle Datenbank tracen

Als erstes müssen Sie wissen, wie der User heißt, dessen Session Sie tracen wollen. Eine Liste aller User kriegen Sie über

SELECT username from dba_users;

dann braucht irh den client identifier für eine session, die unter diesem usernamen braucht. Den Cleint identifier könnt ihr rausbekommen über

select client_identifier from v$session;

Danach aktivieren wir für diesen User die STatistiken

EXECUTE DBMS_MONITOR.CLIENT_ID_stat_ENABLE(client_id => '<cleint identifier>');

Jetzt lasst ihr die atuomatishce Prozedur, die ihr analysieren wollt, nochmal laufen, so dass die abzufangenden SQL Statements auf die Datenbank angesetzt werden. Sobald ihr sicher seid, dass die SQL Statements abgesetzt wurden, deaktiviert ihr den Trace wieder über

execute dbms_monitor.client_id_stat_disable(client_id => '<client identifier>');

Die gesammelten Statistiken für den Client identifier könnt ihr nun abrufen über beispielsweise

select * FROM V$CLIENT_STATS WHERE client_identifier LIKE '<client identifier>'

In den STatistiken stehen noch nicht die SQL Statements drin, sondern nur  statistische informationen, also beispielsweise welche Art von Statement ausgeführt wurde und wie lange diese gedauert hat.

Nun wollen wir detaillierter gehen und aktivierten statt den Statistiken einen detaillierten SQL Trace.

Bevor wir den SQL Trace checken müssen wir einige Paramter checken über den Befehl

show parameter <parametername>

Hierbi checkenw ir folgende parameter

  • diagnostic_dest. Zeigt den Ordner an, in dem später der trace geschrieben wird. In einem SAP system ist dieser Ordner meistens auf X:\ORACLE\TRP\SAPTRACE
  • MAX_DUMP_FILE_SIZE. Dieser Parameter steht standardmäßig auf UNLIMITED, was bedeutet, dass die Trace Files beliebig groß werden können. DAs kann natürlich dazu führen, dass die Festplattenpartition, in welche die Traces geschrieben werden, voll wird – was wir nicht wollen. Deswegen sollte hier ein Limit gesetzt werden.
  • STATISTICS_LEVEL. Steht diese rWert uaf all, werden zusätzlich zu den SQL Statements auch die Reaktionszeiten mitgeloggt, die wir bereits weiter oben einmal geloggt haben. ist der Wert auf BASIC, werdne diese hingegen nicht mit gesammelt.

Desweiterne wird es ohne einen TraceFile Identifier sehr schwer werden herauszufinden, welches Tracefile nachher für uns interessant ist. Daher setzen wir einen solchen Identifier über

ALTER SESSION SET TRACEFILE_IDENTIFIER = 'my_trace_id';

jetzt aktivierne wir das Tracing für die gesamte Datnebankinstanz über

dbms_monitor.database_trace_enable(instance_name => '<INstanzname>');

wenn der Trace aktiv ist, bekommt ihr nun einen Datensatz zurück bei der Abfrage

select * from dba_enabled_traces;

Jetzt führen wir wieder die Prozedur aus, die zu den aufzuzeichnednen sQL Statements führt, und beenden danach das Tracing wieder über

dbms_monitor.database_trace_disable;

Wenn ihr nach Deaktiiveren des Traces nun in euer DIAGNOSTIC_DEST-Verzeichnis schaut, werdet ihr dort jede Menge aktuelle Tracefiles finden. Öffnet ihr diese, werdet ihr dort nun SQL Statements vorfinden, die auf die Datenbank ausgeführt wurden.

2016-06-02_21h44_32

Diese Trace Files könnt ihr jetzt entweder innerhalb des Verzeichnisses nach beispielsweise einer bestimmten Tabelle oder Spalte greppen. Oder ihr könnt die Trace Files auch mit Hilfe der Binary trcsess in eine einzige Datei zusammenfügen.

Alle Dateien finden, die sich die letzten x Minuten geändert haben

Oftmals führen Sie eine Tätigkeit in einem Programm durch und Sie wollen wissen, welche Dateien auf dem Betriebssystem dadurch beeinflusst werden. Wenn Sie sich merken, wann Sie die Aktion durchgeführt haben, beispielsweise um 21:35, und um 21:40 wollen Sie wissen, welche Dateien sich die letzten 5 Minuten geändert haben, können Sie im betreffenden Verzeichnis einfach eingeben

find . -cmin -5

Oder alternativ können Sie alle DAteien in diesem Verzeichnis nach dem Änderungsdatum absteigend sortieren (die neusten Files stehen unten) und dann eine Uhrzeit greppen. Der folgende String greppt nach allen Dateien, die irgendwann zwischen 21:30 und und 21:39 verändert wurden

ls -lrt . | grep "Jun 16 21:3"

Dateisystemänderungen dauerhaft tracen

wenn Ihnen die Methode aus dem oberen Abschnitt nicht genügt und Sie stattdessen änderungen auf bestimmte Dateien dauerhaft tracen wollen, ist eventuell die binary audit etwas für Sie. Installation über

apt-get install audit

Starten über

/etc/init.d/auditd start

Jetzt bestimmen Sie, welche Daten der auditd überwachen soll. Wenn Sie beispielsweise eine Auditing-Regel auf die /etc/passwd legen wollen, die sowohl lesezugriffe als auch Veränderungen an den Ateiattributen trackt, dann geben Sie ein

auditctl -w /etc/passwd -k passwdtrace -p ra

Der Parameter -p bestimmt mit den Werten „ra“, dass Lesezugriff (read) und Attributsänderungen (attribute) auf die Datei getrackt werden. Über den Parameter -k geben sie einen eindeutigen Namen ein, der dann in den Audit Logs auftaucht, wenn so eine Aktion an /etc/passwd durchgeführt wird. Wenn Sie nun das log auswerten über

ausearch -k passwdtrace

dann suchen Sie im Log nach allen Einträgen, die auf Ihre Auditing-Regel passwdtrace zutreffen.

Sie können aber nicht nur nach Audit-REgelnamen filtern, sondern z. B. auch nach executables, die auf die Dateien zugegriffen haben

ausearch -x /bin/grep

ausearch -x /bin/rm

oder nach Usern

ausearch -ui 1000

Weitere Nützliche File Changing Tools

inofity-tools, incron

 

 

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!