In unserem letzten Newsletter haben Sie SAPtown, eine Firma, die wie ein Gebäudekomplex oder eine kleine Stadt aufgebaut ist, kennengelernt. Sie wissen, dass ein Zaun um SAPtown gezogen ist, verschiedene Zufahrtswege existieren, Ausweispflicht besteht und besondere Transporter unterwegs sind. Einen sehr wichtigen Punkt haben wir bislang jedoch noch nicht thematisiert: Das zentrale Datenarchiv (Datenbank).
Es wird häufig vergessen, dass die gesamte Kontrolle über alle Prozesse in SAPtown hinfällig wird, wenn ein Einbrecher (Angreifer) Zugriff auf das Datenarchiv hat. Dort sind sämtliche Informationen gespeichert und hat ein Einbrecher (Angreifer) Zugang zum Archiv, lässt er sich durch kein Regelwerk von Einschränkungen, Berechtigungsobjekten oder ähnlichem mehr stören. Feindlicher Zugriff auf das Datenarchiv bedeutet also grundsätzlich „Game Over“ für ganz SAPtown! Deshalb muss das Datenarchiv auf jeden Fall durch den Zaun geschützt werden. In der Regel besteht keine Notwendigkeit, einen direkten Zugriff auf das Archiv zu erlauben. Die Hausmeister (Administratoren), die mit der Pflege des Archivs betraut sind, verwenden idealerweise ausschließlich sehr komplexe Schlüssel (Passwörter), um das Archiv zu öffnen.
Jedes Schloss braucht einen Schlüssel. Dabei entscheidet die Qualität der Mischung aus Schloss (Hashcode) und Schlüssel (Passwort), wie schwierig es ist, ein Schloss ohne Schlüssel zu öffnen oder den Schlüssel nachzumachen. In SAPtown hat jeder selbst die Möglichkeit zu bestimmen, wie gut sein Schlüssel ist. Dies bringt ganz menschliche Probleme mit sich: Stellen Sie sich vor, Sie müssten beim Öffnen Ihrer Wohnungstür den Schlüssel mehrfach nach oben, unten, links und rechts drehen und das auch noch in einer bestimmten, festgelegten Geschwindigkeit. Klingt kompliziert für den Alltag, oder? Deshalb haben Sie vermutlich ein ganz normales Schloss an Ihrer Wohnungstür. Wer den Schlüssel dazu hat, kann also die Tür öffnen. Die wenigsten Menschen würden freiwillig die komplizierte Variante wählen. Mit dem Schlüssel für SAPtown (Passwort), verhält es sich ähnlich: Wenn man nicht ein gewisses Mindestmaß an Regeln zur Erstellung eines Schlüssels befolgen muss, wird ein sehr einfacher Schlüssel entstehen und die Wahrscheinlichkeit steigt, dass ein (Einbrecher) Angreifer auf eine ähnliche Idee kommt beziehungsweise das Muster des Schlüssels schlichtweg errät. Des Weiteren hat sich die Qualität der Schlösser in SAPtown mit der Zeit weiterentwickelt, d. h. bei alten SAPtowns müssen die Schlösser ausgetauscht werden. Erhält SAPtown kein aktuelles Schloss und ein Einbrecher (Angreifer) gelangt an die Informationen eines älteren Schlosses, kann er mit hoher Wahrscheinlichkeit über das Schloss einen passenden Schlüssel errechnen. Da Menschen Gewohnheitstiere sind, passt dieser Schlüssel übrigens nicht selten auch für andere Schlösser, also eventuell auch für andere SAPtowns (Testumgebung, Produktivumgebung).
Natürlich haben wir nicht alle Sicherheitsmaßnahmen selbst in der Hand. Denn leider werden immer wieder sicherheitsrelevante Fehler bekannt, die bei der Planung von SAPtown übersehen worden sind. Im Rahmen der komplizierten Bau- und Umbaumaßnahmen während des architektonischen Aufbaus und späterer Sanierungsmaßnahmen in SAPtown werden immer wieder ungewollt Hintertüren eingebaut, die einem Bewohner oder einem Einbrecher von außen unberechtigten Zugriff auf Informationen verschaffen können. Die Fehler können sehr alt sein oder aber sie wurden erst durch das Hinzufügen neuer Stadtviertel (Funktionen) generiert. Trotz dieser Fehlergefahr sollten wir SAPtown konsequent sanieren (sicherheitsrelevante Aktualisierungen), um bekannt gewordene Hintertüren zu schließen. Leider stellt das unsere Hausmeister (Administratoren) oft vor große Herausforderungen, denn das Schließen einer Hintertür kann unter Umständen auch ungewollte Auswirkungen haben. Und wenn Teile von SAPtown aufgrund einer Sanierung (Aktualisierung) nicht mehr funktionieren, führt das schnell zu viel Aufwand, Ärger und Problemen. Hier ist es hilfreich, Bauarbeiten erst einmal zu simulieren (Testumgebung), um Änderungen auf ihre Auswirkungen prüfen zu können. Dabei sollten wir übrigens daran denken, dass auch das Fundament (Betriebssystem) von SAPtown gründlich gepflegt werden sollte!
Zu guter Letzt dürfen wir nicht vergessen, dass jedes SAPtown in einem bestimmtem Rahmen auch individuell gestaltet wird. Und wenn unser Innenarchitekt oder die Bauarbeiter Fehler machen und eine Hintertür einbauen, helfen alle anderen Sicherheitsmaßnahmen nichts. Deshalb sollten wir bei der Planung und Umsetzung unserer individuellen Gebäude in SAPtown (eigener ABAP Code) stets die Sicherheit im Auge haben und insbesondere darauf bestehen, dass unsere Innenarchitekten und Bauarbeiter (Entwickler) regelmäßig Schulungen und Fortbildungen besuchen.
SAPtown, eine Firma, die wie ein Gebäudekomplex oder eine kleine Stadt aufgebaut, ist eine Metapher, die der Veranschaulichung von Sicherheitsproblemen sowie deren Behebung in einem SAP-System dient: Gebäude und Räume stehen für Dienste und Module, deren Bewohner für Anwender, ihre Hausmeister für Administratoren und ein Transporter für SAP GUI.
Übersetzen wir die Metapher zurück in die praktische Anwendung, ergeben sich aus der Geschichte um SAPtown folgende technische Empfehlungen:
- Führen Sie eine Netzwerkseparierung ein und trennen Sie die Netzsegmente durch eine Firewall. Entwerfen Sie anschließend ein Regelwerk, das genau definiert, welches Netzsegment mit welchem Dienst kommunizieren darf. Administrative Dienste sollten beispielsweise nur aus einem administrativen Netzsegment heraus erreichbar sein. Benutzer sollten ausschließlich Zugriff via DIAG-Protokoll (Port 32xx) haben, gegebenenfalls alternativ oder zusätzlich auf die Webschnittstelle (WebGUI). Ist eine Abstimmung der SAP- und Netzwerkadministratoren zu aufwändig, könnte ein SAP-Router (Port 3299) zum Einsatz kommen, welcher aus dem Benutzersegment freigegeben wird. Dieser kann anhand seines Regelwerks dann selbst entscheiden, ob er eine Verbindung zulässt oder nicht, wobei diese Regeln von den SAP-Administratoren selbst verwaltet werden können, ohne das Netzwerk-Team zu involvieren.
- Prüfen und härten Sie Ihre Access Control Lists, insbesondere die Dateien reginfo, secinfo und ms_acl_info. Hier kann eine fehlende oder schlechte Konfiguration schnell zur unauthentifizierten Übernahme des kompletten SAP-Systems führen!
- Schränken Sie die Benutzerrechte auf Basis des Principle of Least Privilege so stark wie möglich ein. Hierfür sollten ausführbare Transaktionen und Berechtigungsobjekte möglichst restriktiv konfiguriert werden. Benutzer mit dem Profil „SAP_ALL“ sollten nur für Ausnahmefälle existieren, beispielsweise Notfall-User und Firefighter. Dies gilt, soweit möglich, auch für Entwicklungssysteme, um Eskalationsmöglichkeiten in Richtung von Test- und Produktivsystemen einzuschränken.
- Aktivieren und forcieren Sie die Verwendung SNC, idealerweise zusammen mit einer zertifikatbasierten SSO-Lösung. Alle anderen Verbindungen sollten, sofern möglich, ebenfalls verschlüsselt abgewickelt werden, darunter zum Beispiel auch die WebGUI.
- Trainieren Sie die Whitelist für RFC-Verbindungen und aktivieren Sie die Callback-Prüfung. Vermeiden Sie das Hinterlegen von Credentials und konfigurieren Sie stattdessen die Vertrauensstellungen.
- Verwenden Sie individuelle Schlüssel für die Speicherung verschlüsselter Informationen.
- Separieren Sie die Datenbank komplett von den anderen Netzen und verwenden Sie ausschließlich sehr starke Passwörter. Einige Datenbanken erlauben zusätzlich per Access Control List eine Einschränkung auf einzelne zugriffsberechtigte Hosts, alternativ kann auch eine sehr restriktive Firewall den Zugang weiter beschränken.
- Verwenden Sie für die Speicherung von Passwörtern ausschließlich den „PWDSALTEDHASH“ und deaktivieren Sie „BCODE“ und „PASSCODE“. Erzwingen Sie eine Mindestqualität von Passwörtern über die „login/*“-Parameter oder die integrierte SSO-Lösung.
- Installieren Sie regelmäßig Sicherheitsupdates und SAP-Kernel-Updates. Eine gepflegte Umgebung von produktionsnahen Test- und Abnahmesystemen hilft, potenzielle Probleme mit Updates rechtzeitig zu erkennen. Denken Sie dabei auch an das zugrundeliegende Betriebssystem!
- Prüfen und härten Sie Ihren eigens entwickelten Code auf Sicherheitsprobleme und schulen Sie Ihre Entwickler.
Wir hoffen, wir konnten zu mehr Sicherheit in Ihren SAPtowns beitragen!
08.10.2024
- 09.10.2024
Hack1/Hack2: Hacking Workshop
10.10.2024
- 11.10.2024
Hack1/Hack2: Hacking Workshop
15.10.2024
Awe2: Phishing Awareness
15.10.2024
- 16.10.2024
Hack7: Sicherheit und Einfallstore bei Webapplikationen
Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de | IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer
Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de
IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer
Direkter Kontakt
+49 (0)7071 - 40 78 56-0 oder anfrage@syss.de
IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN
+49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer