Rolle vorwärts: ungewollte Datenabflüsse aus SAP HANA

Autor: Kai Grunwitz*

Ungewollte Datenabflüsse sind für alle Business-Systeme eine Herausforderung, da bildet auch SAP HANA keine Ausnahme. Mit der Einführung von SAP HANA verändern sich auch die Angriffsvektoren. Früher wurden SAP-Systeme eher durch Pivoting attackiert – also durch das Springen von einem System mit geringer Sicherheitsstufe, etwa eine Entwicklungsumgebung, auf ein kritisches System, oder durch Angriffe auf die SAP-Dienste, beispielsweise durch das Ausnutzen von Schwachstellen im SAP-RFC-Gateway. Jetzt liegt der Angriffs-Vektor mehr im Bereich der webbasierten Kommunikation. Kein schlecht gewählter Punkt, denn in SAP HANA gibt es aktuell über 5.000 Schnittstellen, die mittels webbasierten Protokollen angesprochen werden können. Die Wahrscheinlichkeit, Opfer eines ungewollten Datenabflusses zu werden, ist somit deutlich gestiegen.

In Projekten zur Sicherung von SAP-HANA-Umgebungen zeigt sich häufig, dass Anwender zum Schutz vor ungewollten Datenabflüssen vor allem auf das verfügbare Rollen- und Berechtigungsmanagement setzen: meist aber erst im Anschluss an ein Systemaudit, denn die Prüfer schauen sich seit geraumer Zeit gezielt Rollen- und Berechtigungszuweisungen in SAP-Systemen an. Im Mittelpunkt steht dann die Frage: Wer hat wann Zugriff auf welche Systemfunktionen und im Zuge dessen auf Informationen? Da viele Rollen historisch gewachsen, nicht oder nur unzureichend dokumentiert sind und nicht mehr den aktuellen Anforderungen an Compliance-Vorgaben wie beispielsweise dem sogenannten Least-Privileges-Prinzip entsprechen, verteilen die Prüfer hier häufig so genannte Red Flags, also Kennzeichnungen für gravierende Compliance-Verstöße.

Gerade bei der Rollenzuweisung werden häufig Fehler gemacht: Es wird immer wieder festgestellt, dass zu viele Benutzer erweiterte Rechte besitzen, die sie in ihrer täglichen Arbeit gar nicht benötigen. Hier ist Augenmaß gefordert, und der alte Grundsatz sollte noch immer gelten: „So wenig Rechte wie möglich, so viele Rechte wie nötig!“

Nehmen sich Unternehmen die Regelung der Rollen und Berechtigungen vor, dann sollten sie aber nicht gleich über das Ziel hinausschießen. Schließlich hat auch der Grundsatz „Klein anfangen und dann komplexer werden“ seine Berechtigung. Beim Schutz der Kommunikation und Daten sollte man sich daher zunächst auf wenige Kernbereiche fokussieren; auf diese Weise wird nicht nur das Risiko eines ungewollten Datenabflusses minimiert, sondern auch das Ziel der Compliance-Konformität schneller erreicht. Im Hinblick auf das HANA-Bordmittel Autorisierung bedeutet dies, dass Unternehmen mit wenigen Rollen starten und privilegierte Rollen wie SAP_ALL vermeiden, zumal die meisten Funktionen und Prozesse auch anders abgebildet werden können. Gerade das scheuen aber viele Unternehmen: stattdessen statten sie häufig eine große Anzahl an Usern mit SAP_ALL-Rechten aus oder gestalten den Prozess des Firefighter-User-Modus sehr offen – und wundern sich, wenn genau das im Auditing beanstandet wird.

Wenn Unternehmen SAP-Systeme – auch jenseits der Bordmittel von SAP HANA – noch gezielter vor Datenabflüssen schützen möchten, muss eine Datenverschlüsselung auf Basis einer konsequenten Datenklassifikation eingeführt werden. Damit lässt sich dann auch ein gezieltes Risikomanagement implementieren, das dafür sorgt, dass kritische Daten nur denjenigen Usern vorbehalten bleiben, für die sie auch tatsächlich relevant sind. Unkritische Daten können dagegen wie bisher weiterverarbeitet werden. Aktuell geht das in SAP HANA aber nur mit Tools von Drittherstellern.

Grundsätzlich ist beim Thema Datenabfluss aus SAP-Systemen noch viel Aufklärungsarbeit zu leisten. Dies gilt insbesondere für SAP HANA, denn Unternehmen stehen hier noch am Anfang von Implementierungsprojekten. Dabei machen sie sich noch nicht allzu viele Gedanken zu ungewollten Datenabflüssen aus Systemen, da sie „ja noch gar nicht im produktiven Betrieb sind“.

Gleichzeitig haben sich in SAP HANA einige Dinge gravierend geändert. Auch wenn das den zuständigen HANA-Betriebsteams bewusst ist, fallen viele bei der Umsetzung dann doch wieder auf ihre bisher implementierten Rollenmodelle zurück und versuchen diese 1:1 zu übernehmen, anstatt sich Gedanken über ein Neudesign zu machen. Häufig werden auch nur Funktionen zum Datenexport, beispielsweise zu Excel oder anderen Drittsystemen untersucht; grundlegende Funktionen wie etwa das Drucken bleiben jedoch immer wieder außen vor. Auch hier gilt es die Klassifikation der Daten zu berücksichtigen und dann eben bestimmte Nutzer von der Nutzung der betreffenden Funktion auszuschließen.

In solchen Problemen zeigt sich letzten Endes ein immer noch unzureichendes Sicherheits-Bewusstsein in den Unternehmen. Gerade in Migrationsprojekten liegt der Fokus der Aufmerksamkeit immer noch zu 90 Prozent auf der Erhebung und Abbildung funktionaler Anforderungen, und die Sicherheit muss sich mit dem kargen Rest begnügen. Doch an dem Tag, an dem die Möglichkeit des Datenabflusses zur Wirklichkeit wird, ist es für eine Korrektur zu spät.

* Kai Grunwitz ist Senior Vice President EMEA bei NTT Security