Schutz von SAP-Konfigurationen
In den vergangenen neun Jahrenhaben sich mehr als 200 Fortune-1000-Unternehmen auf Onapsis verlassen, umihre SAP-Implementierungen sowie die Daten und Prozesse, auf die diese angewiesen sind,zuschützen. Im Rahmen unserer Forschungsarbeit und der Zusammenarbeit mit diesen Kunden haben wir zahlreiche Angriffe auf SAP-Anwendungen, Verstöße gegen Compliance-Vorschriften und Geschäftsinhaber beobachtet, die unter den Folgen von SAP-Risiken zu leiden hatten.
Es gibt zahlreicheunterschiedliche Sicherheitsrisiken, die SAP-Anwendungen betreffen können, wobei viele davon auf unsichere Konfigurationen zurückzuführen sind. In dieser Blogreihe werden wir sowohl die offensichtlichen als auch die versteckten Risiken unsicherer Konfigurationen undder SAP-Konfigurationsabweichung beleuchten.
Es gibt zahlreiche verschiedene Anpassungen und Einstellungen, die an SAP-Anwendungen vorgenommen werden können und die unter den Begriff „Sicherheitskonfigurationen“ fallen:
- Profilparameter
- In SAP-Tabellen gespeicherte Einstellungen
- Konfiguration von Audit-Protokollen
- ICF-Dienste: Aktivierung/Authentifizierung/Autorisierung
- Schnittstellen für Authentifizierung und Autorisierung
- ACL-Dateien
- Standardbenutzer
- Standard-/schwache Passwörter
- Benutzer mit erweiterten Rechten
- Und noch mehr…
Änderungen an bestimmten Einstellungen dieser Gruppen können schwerwiegende Auswirkungen auf die Sicherheit haben. Zudem werden die meisten dieser Änderungen überhaupt nicht nachverfolgt oder protokolliert. Lediglich Änderungen in der ABAP Workbench (ABAP-Programme, ABAP Dictionary usw.) oder im IMG (Implementierungsleitfaden, der für das System-Customizing verwendet wird) durchlaufen den ordnungsgemäßen Änderungsmanagementprozess über das SAP Change and Transport System (CTS). Andere Arten von Konfigurationen, wie z. B. Änderungen an RFC-Zielen, am Inhalt von ACL-Dateien, an dynamischen Profilparametern oder an ICF-Services, werden direkt in der Produktion implementiert, ohne dass Genehmigungen oder Transporte zwischen den verschiedenen Ebenen des Transport Management Systems (TMS) erforderlich sind. Einige dieser Änderungen (z. B. Änderungen am Inhalt von Gateway-ACLs oder an RFC-Zielen) werden weder im Security Audit Log noch in einem anderen SAP-Systemprotokolleintrag protokolliert.
Aus diesem Grund müssen sich BASIS-Teams und Sicherheitsadministratoren nicht nur in sehr komplexen Szenarien zurechtfinden und dabei einen Ausgleich zwischen Betriebs- und Sicherheitsaktivitäten schaffen, sondern auch die Geschäftsverantwortlichen sind nicht in der Lage zu erkennen, welche Änderungen in ihren Systemen stattfinden. Diese Situation wird alsSAP-Konfigurationsdrift bezeichnet.
Externe oder interne Administratoren, Entwickler und/oder Tester nehmen im Rahmen ihrer täglichen Arbeit ständig Änderungen an SAP-Systemen vor. Dies birgt die große Gefahr, dass bereits sicher oder konform konfigurierte Systeme nicht nur unsicher werden oder die Compliance-Anforderungen nicht mehr erfüllen, sondern dass auch der bisherige Zeitaufwand für die ursprüngliche Absicherung des Systems zunichte gemacht wird. Wir haben von Kunden gehört, die über die Herausforderungen durch interne menschliche Fehler oder den Missbrauch ihrer Ressourcen durch Dritte sprachen, was zu SAP-Konfigurationskatastrophen führte, ihre Systeme gefährdete und den BASIS-Teams und Sicherheitsadministratoren viel unnötige Doppelarbeit bescherte.
Aus Sicherheitssicht besteht bei jeder fehlerhaften Konfiguration das Risiko, dass die SAP-Systeme Bedrohungen ausgesetzt werden, die ihre Vertraulichkeit, Integrität oder Verfügbarkeit gefährden könnten. Aus Compliance-Sicht besteht ein erhebliches finanzielles Risiko in Form von Strafen, wennStandardrichtlinien wie SOX, DSGVO oder PCI nicht eingehalten werden.
Zudem entstehen jedes Mal, wenn dies geschieht, erhebliche finanzielle Belastungen durch den Aufwand, die Arbeit erneut zu erledigen und die SAP-Systeme wieder in einen sicheren oder konformen Zustand zu versetzen. Ganz zu schweigen von den Ausfallzeiten für das Unternehmen, die dadurch entstehen, dass die Systeme stunden- oder sogar tagelang offline geschaltet werden müssen. Wir wissen, dass das Erreichen dieses gewünschten Zustands (Get Clean) für unsere Kunden mit sehr hohen Kosten in Bezug auf Zeit und Ressourcen verbunden ist. Doch wenn dieser Zustand erreicht ist, entstehen noch höhere Kosten für die Aufrechterhaltung des SAP-Systems in diesem Zustand (Stay Clean).