Implementierung und technische Leistungen
Schützen Sie Ihre SAP-Umgebung vor, während und nach der Migration
Von Analyse und Migrationsplanung über die Umsetzung der Sicherheit bis zum laufenden Monitoring machen wir Ihre SAP-Transformation sicherer, reibungsloser und besser steuerbar.
Sechs Arbeitsstränge in einem SAP-HANA-Programm
Die Migration ist der Punkt, an dem SAP-Umgebungen am stärksten exponiert sind: neue Architektur, neue Zugriffswege und Daten in Bewegung. Jeder dieser Stränge läuft parallel zur Migration, nicht danach.
Sichere Migrationsplanung
Wir definieren Umfang, Risiken, Zeitplan, Verantwortlichkeiten und technische Anforderungen der Migration, bevor das Projekt beginnt.
SAP-HANA-Sicherheitsanalyse
Wir prüfen Ihre SAP-HANA-Umgebung, Cloud-Architektur, Zugriffskontrollen, den Datenschutz und die gesamte Sicherheitslage.
Datenschutz
Wir schützen sensible Geschäftsdaten bei Speicherung, Verarbeitung, Sicherung, Übertragung und Migration.
Monitoring und Vorfallbereitschaft
Wir überwachen die Identitäts-, Endpunkt-, Cloud-Infrastruktur- und Netzwerkebenen, auf denen Ihre SAP-Landschaft aufsetzt — rund um die Uhr und aus Ihrem eigenen Tenant heraus. SAPs eigene Logquellen lassen sich als abgegrenzte Integration ergänzen.
Umsetzung und Integration
Wir unterstützen bei sicherer Konfiguration, Bereitstellung, Integration, Test und Go-live.
Compliance-Ausrichtung
Wir richten die Umgebung an Ihren weiteren Pflichten aus und erstellen die Belege für Ihren Nachweisordner zu NIS2, DORA oder ISO 27001 — Untersuchungsergebnisse, an Benchmarks gemessene Härtungsberichte und eine schriftliche Erklärung, was überwacht wird und was nicht.
Analysieren, aufbauen, erhalten
Dieselben drei Schritte wie in unserer Beratungsarbeit, angewandt auf die SAP-Landschaft — was sich ändert, ist die Tiefe.
- 01
Analysieren
Wir prüfen Ihre aktuelle Sicherheitslage, Compliance-Anforderungen, Risiken und Geschäftsprioritäten über die gesamte SAP-Landschaft.
- 02
Aufbauen und einführen
Wir prüfen die Zielarchitektur und ihre Zugriffspfade, härten die Konfiguration an veröffentlichten Benchmarks und bauen die Überwachung — Konnektoren, Detektionsinhalte und Playbooks — in Ihrem eigenen Tenant auf.
- 03
Optimieren und erhalten
Ein SOC, das rund um die Uhr die Ebenen unterhalb von SAP beobachtet, mit einem Überwachungsumfang, der mit der Landschaft mitgeprüft wird — denn Übergangslösungen aus einer Migration überleben diese meist.
Häufig gestellte Fragen
Die Fragen, die uns Sicherheits- und IT-Verantwortliche am häufigsten stellen.
Ihre Frage ist nicht dabei? Fragen Sie uns direkt
Wir sind der Partner Ihres SAP-Programms für Security Operations und Infrastruktursicherheit. Wir sind nicht Ihre SAP-Anwendungssicherheitsspezialisten — und wer beides für sich beansprucht, sollte Ihr Misstrauen wecken.
Ihrem Basis-Team gehört, was innerhalb von SAP geschieht: Rollen und Berechtigungen, Transporte, RFC- und Gateway-Konfiguration, das Anwendungs-Auditlog. Ihrem Hyperscaler gehört die Plattform unterhalb des Betriebssystems. Ihrem Integrator gehört die Konvertierung.
Was dazwischenliegt — und was keiner der drei vertraglich für Sie betreibt —, ist die Security-Operations-Ebene: eine unabhängige Prüfung der Zielarchitektur und ihrer Zugriffspfade, Konfigurationshärtung gemessen an veröffentlichten Benchmarks, der SIEM-Aufbau samt der Detektionsinhalte darin sowie die 24/7-Überwachung und Reaktion über die Identitäts-, Endpunkt-, Cloud-Infrastruktur- und Netzwerktelemetrie, auf der Ihre SAP-Systeme aufsetzen.
In den meisten Migrationsprogrammen ist das eine echte Lücke. Es ist zugleich eine engere Aussage als die, die diese Seite bisher getroffen hat.
Nein. Logs werden in Ihrer eigenen Microsoft-Azure-Umgebung zusammengeführt und gespeichert. Ihnen gehört der Workspace, Ihnen gehört das Abonnement, und Sie zahlen Ingestion und Speicherung direkt an Microsoft, statt einen Anbieter dafür zu bezahlen, dass er Ihre Daten hält.
Analysten gelangen an die Daten, indem ihnen delegierter administrativer Zugriff in Ihren Tenant gewährt wird — nicht dadurch, dass Ihre Daten in einen anbietereigenen Data Lake exportiert werden. Dasselbe gilt für die Sentinel-Instanz, wenn wir sie selbst aufbauen: Sie entsteht in Ihrem Azure-Abonnement, innerhalb eines einzigen Verzeichnisses.
Das ist der Teil der Leistung, der auch die härteste juristische Prüfung übersteht — deshalb lohnt die präzise Formulierung: Nicht die Daten bewegen sich, sondern der Zugriff.
Die darunterliegende Infrastruktur, sofern Sie nicht bewusst mehr in den Umfang nehmen. Diese Frage hat die Seite bisher schlecht beantwortet, deshalb hier ohne Umschweife.
Standardmäßig überwacht werden Identität und Authentifizierung, Endpunkt- und Servertelemetrie, Aktivität der Cloud-Infrastruktur und der Netzwerkperimeter. Die Leistung setzt mindestens drei qualifizierende Sammelquellentypen voraus, bevor sie überhaupt ein Service Level trägt — Endpunktsichtbarkeit, Benutzerauthentifizierung und -zugriff sowie Adressauflösung —, und ein ERP-Anwendungslog gehört nicht dazu. In der ausschließlich Microsoft-nativen Variante lassen sich Nicht-Microsoft-Quellen überhaupt nicht anbinden.
SAPs eigene Logs lassen sich einbinden — als kundenspezifische Quelle: mit einem für Ihre Landschaft gebauten Konnektor und Parser, dagegen geschriebenen Detektionsinhalten, als eigenes Arbeitspaket zugeschnitten und bepreist. Und das ist der entscheidende Punkt: Eine Logquelle, die in Ihrem Sentinel-Workspace liegt, aber nicht zur Überwachung abonniert ist, liegt ausdrücklich außerhalb des Umfangs für Alarmierung und Untersuchung. „Ihre SAP-Logs sind in Sentinel“ und „Ihr SAP wird überwacht“ sind zwei verschiedene Aussagen. Lassen Sie sich von jedem Anbieter sagen, welche er meint.
Zur Zusage: Das vertragliche Service Level ist eine einzige Time to Respond — 15 Minuten, für jeden Schweregrad gleich —, gemessen vom Anlegen des Vorfalls in der Plattform bis zum Abschluss von Ersttriage und Klassifizierung, einschließlich des automatisierten Teils dieses Ablaufs. Zugesagt ist, wie schnell aus einer Warnung ein klassifizierter Vorfall wird; nicht, wann Sie informiert werden, und nicht die Eindämmung — Benachrichtigung und Eskalation werden in der Bestellung vereinbart, nicht vertraglich zugesichert. Eine vertragliche Zeit bis zur Erkennung gibt es ebenfalls nicht; die kann Ihnen niemand seriös verkaufen. Und Behebung und Wiederherstellung führen Sie aus; wir untersuchen, klassifizieren, beraten und begleiten.
Indem es in der Bestellung dagegen terminiert wird, statt dass man es hinterher entdeckt — und es gibt eine konkrete Klausel, die Sie vor jeder Unterschrift kennen sollten.
Überwachungsverträge verlangen, dass Ihre Logquellen innerhalb von 30 Tagen nach dem Go-Live-Datum des SOC angebunden und integriert sind. Eine Quelle, die länger braucht, schiebt die Arbeit in eine separate Beratungsvereinbarung. Ein Freeze, der länger als einen Monat läuft, oder ein Überwachungsvertrag, der lange vor dem Cutover unterzeichnet wird, kollidiert also unmittelbar mit dieser Uhr. Das ist gut beherrschbar — aber nur, wenn das SOC-Go-Live-Datum bei der Bestellung bewusst gegen Ihre Freeze-Fenster gelegt wird.
Was wir nicht tun werden: einen Mechanismus erfinden. Wir haben echte Cutover-Programmerfahrung — Cutover-Planung, Cutover-Governance und eine Verantwortungsmatrix über SAP-Core-, Satelliten- und Infrastruktur-Arbeitsstränge hinweg in großen Transformationsprogrammen —, aber das ist Programmmanagement und kein dokumentiertes Sicherheitsverfahren für die Freeze-Phase. Wir sagen Ihnen lieber, wo der Vertrag beißt, als einen Prozess zu beschreiben, den wir nie aufgeschrieben haben.
Ja, wir schreiben es auf — und wir haben keine vorgefertigte Antwort, die wir Ihnen reichen, bevor wir hingeschaut haben.
Was die Vertragsstruktur bereits festlegt: Sie stellen Plattformlizenzen und Cloud-Verbrauch bereit und bezahlen sie; Sie aktivieren die Protokollierung auf den Systemen im Umfang und nehmen die Netzwerkänderungen vor, die zum Weiterleiten der Logs nötig sind; und Service Levels gelten nicht für Ausfälle von SaaS- oder Cloud-Infrastrukturanbietern Dritter. Die unmittelbare Folge für eine RISE-Landschaft: Jede Komponente, deren Logs wir nicht erreichen können oder deren Anbieter selbst ausfällt, liegt außerhalb jeder Zusage, die wir machen können. Das sagen wir lieber vorher, als dass es während eines Vorfalls zutage tritt.
Das Ergebnis, an dem wir uns messen lassen, ist eine Liste Quelle für Quelle: was im Umfang und überwacht ist, was zwar angebunden, aber nicht abonniert ist, und was SAP oder dem Hyperscaler gehört statt uns. In einer Landschaft mit geteilter Verantwortung ist diese Liste deutlich mehr wert als ein Architekturbild — und danach sollten Sie jeden Bieter fragen.
Belege, keine Beteuerungen. Das Untersuchungsergebnis samt Lückenverzeichnis; Härtungsberichte, gemessen an veröffentlichten Benchmarks, die den Benchmark und das Ergebnis benennen, statt einen Zustand zu behaupten; die Detektions- und Reaktions-Runbooks; und die in der vorigen Antwort beschriebene Umfangserklärung zur Überwachung, die oft die nützlichste Seite im Ordner ist, weil sie sagt, was abgedeckt ist und was nicht.
Zwei stützende Fakten. Spirity ist als Managed Security Service Provider nach ISO/IEC 27001 zertifiziert, die Leistung kommt also aus einem zertifizierten Betrieb. Und unsere Beratungspraxis erbringt die Vorbereitungsarbeit selbst: Lage- und Compliance-Untersuchung, Entwicklung von Richtlinien und Verfahren, Lückenermittlung und Maßnahmenplanung entlang NIS2, DORA und ISO 27001.
Was wir Ihnen nicht sagen werden: dass Ihre SAP-Landschaft dadurch „keine Lücke“ in Ihren Nachweisen mehr ist. Nach dem Überwachungsvertrag liegt die Log-Archivierung für Compliance- und regulatorische Zwecke bei Ihnen, ebenso das Unkenntlichmachen geschützter Daten vor der Übermittlung an das SOC, und der Anbieter weist die Verantwortung für Ihre Einhaltung von Vorschriften zur Logsammlung und -aufbewahrung von sich. Wir liefern Nachweise und schließen Kontrolllücken. Wir zertifizieren die Landschaft nicht — und wer etwas anderes behauptet, hat seinen eigenen Vertrag nicht gelesen.
Eher relevanter. Die Seite ist um die Migration herum geschrieben, weil sich eine SAP-Landschaft dann am schnellsten verändert und ihre Zugriffspfade am offensten sind — tatsächlich ist aber nur einer der Arbeitsstränge migrationsförmig.
Härtung, Überwachung, Vorfallsbereitschaft und Compliance-Ausrichtung sind Dauerleistungen. Eine Landschaft nach der Migration hat zusätzlich das Problem, dass die während des Programms getroffenen Übergangslösungen — die zusätzlichen privilegierten Konten, die vorläufigen Netzwerkpfade, die für den Cutover geöffneten Firewallregeln — das Programm meist überleben, das sie geschaffen hat, und niemand mehr da ist, der weiß, welche davon vorläufig sein sollten.
Der sinnvolle Einstieg ist in beiden Fällen derselbe: zuerst die Untersuchung, damit das Folgende auf Ihre Landschaft zugeschnitten ist und nicht auf eine Vorlage.
Bereit anzufangen?
Arbeiten Sie mit Spirity Enterprise zusammen, um die passenden Sicherheits- und IT-Lösungen für Ihr Unternehmen umzusetzen.