Wenn ein Unternehmen SAP Business One vom eigenen Server im Büro in eine professionell verwaltete Cloud-Umgebung verlagert, liegt eine Annahme zunächst nahe: Um die Sicherheit kümmert sich jetzt jemand anderes.  „Der Cloud-Anbieter übernimmt jetzt die Sicherheit“ – diesen Satz hört man bei einer solchen Umstellung häufig.  Ganz so einfach ist es jedoch nicht.  Eine Cloud-Infrastruktur nimmt der internen IT zwar zahlreiche Aufgaben ab: Server müssen nicht mehr selbst betrieben werden, ein veraltetes Betriebssystem muss nicht intern gepatcht werden und auch ein ausgefallenes Laufwerk mitten in der Nacht ist nicht länger das Problem des eigenen IT-Teams.  Was dadurch jedoch nicht entfällt, ist die Verantwortung des Unternehmens dafür,

• wer Zugriff auf das System erhält, 

• welche Daten und Funktionen einzelne Benutzer sehen und bearbeiten dürfen, 

• wie die Endgeräte geschützt werden, die auf SAP Business One zugreifen, 

• und wie sensible Unternehmensdaten durch interne Prozesse geschützt werden. 

Auch Microsoft macht diesen Punkt in seinen eigenen Richtlinien zur Cloud-Sicherheit deutlich: Kunden bleiben grundsätzlich für ihre Daten, Identitäten und Benutzerkonten verantwortlich. Wie die Verantwortung für die zugrunde liegende Infrastruktur verteilt ist, hängt dagegen davon ab, ob es sich um IaaS, PaaS oder SaaS handelt. Dieser Artikel zeigt deshalb konkret, wo die Verantwortungsgrenzen bei SAP Business One in der Cloud liegen. Als Grundlage dienen dabei sowohl das Shared-Responsibility-Prinzip von SAP als auch das Cloud-Sicherheitsmodell von Microsoft – statt „Cloud Security“ einfach als pauschales Sicherheitsversprechen zu behandeln.

Ist SAP Business One Cloud sicher? 

Kurzantwort 

SAP Business One kann mit zahlreichen Sicherheitsmechanismen betrieben werden, darunter Authentifizierung, Autorisierung, Verschlüsselung, Datenbankschutz und Backups. In einer Cloud-Umgebung ist Sicherheit jedoch immer eine geteilte Verantwortung. Der Hosting-Anbieter bzw. SAP-Partner schützt und betreibt die Infrastruktur. Das Unternehmen selbst bleibt dagegen unter anderem für Benutzer, Berechtigungen, Geschäftsdaten, Endgeräte und interne Zugriffsrichtlinien verantwortlich.

Was bedeutet „Shared Responsibility“ bei SAP Business One Cloud? 

Cloud-Sicherheit bei SAP Business One funktioniert nicht nach dem Prinzip:  Cloud-Anbieter = 100 % verantwortlich Kunde = muss sich um nichts mehr kümmern  Stattdessen lässt sich die Umgebung eher als Zusammenspiel verschiedener Ebenen betrachten:  Cloud-Infrastruktur ↓ SAP-Umgebung ↓ SAP-Partner bzw. Managed Service Provider ↓ Interne Sicherheitsmaßnahmen des Kunden  Alle diese Ebenen tragen gleichzeitig zur Sicherheit des Gesamtsystems bei. Auch SAP unterteilt die Verantwortung für Cloud-Sicherheit zwischen SAP, dem Kunden und dem Public-Cloud-Anbieter. Dabei stellt SAP ausdrücklich klar, dass bestimmte Verantwortlichkeiten weiterhin beim Kunden liegen. Dazu gehören beispielsweise: 

• Administration der Lösung, 

• Benutzerzugriffe, 

• Datenzugriffe, 

• sowie bestimmte Aufgaben bei der Erkennung und Behandlung von Sicherheitsbedrohungen. 

Das gilt auch dann, wenn die zugrunde liegende Infrastruktur bereits an einen Cloud-Anbieter ausgelagert wurde. 

Wer ist für die Sicherheit von SAP Business One Cloud verantwortlich? 

Ist der Cloud-Anbieter für die gesamte ERP-Sicherheit verantwortlich? 

Diese beiden Fragen stellen sich Unternehmen besonders häufig zu Beginn eines Cloud-Projekts.  Die präzise Antwort lautet in beiden Fällen: 

Nur teilweise – entscheidend ist, über welche Ebene der Systemlandschaft wir sprechen.

SAP Business One Cloud: Wer trägt welche Verantwortung? 

Sicherheitsbereich	Cloud-/Hosting-Ebene	SAP-/Lösungsebene	SAP-Partner / Managed Service*	Kunde
Physisches Rechenzentrum	Hauptverantwortung	–	–	–
Compute-/Storage-Infrastruktur	Hauptverantwortung	–	Operative Überwachung	–
SAP-B1-Installation	–	Produkt	Haupt-/geteilte Verantwortung	–
Updates & Patches	–	Produktupdates	Haupt-/geteilte Verantwortung	Governance
Backup-Betrieb	Infrastrukturunterstützung	–	Haupt-/geteilte Verantwortung	Anforderungen/Validierung
Benutzeranlage	–	Funktionalität	Unterstützung	Hauptverantwortung
Benutzerberechtigungen	–	Funktionalität	Unterstützung	Hauptverantwortung
Geschäftsdaten	Schutz der Infrastruktur	Anwendungskontrollen	Operative Unterstützung	Hauptverantwortung/Eigentümerschaft
Endpoint-Sicherheit
	–	–	Beratung	Hauptverantwortung
Sicherheit von Integrationen	Geteilt	APIs/Funktionen	Geteilt	Geteilt
Sicherheitsüberwachung	Geteilt	Geteilt	Geteilt	Geteilt

*Die genaue Aufteilung der Verantwortlichkeiten hängt immer vom gewählten Hosting- und Managed-Service-Vertrag ab. Dieser Hinweis ist wichtig, denn SAP-Business-One-Umgebungen können sehr unterschiedlich betrieben werden. Einige Unternehmen betreiben SAP Business One auf einer Infrastruktur, die sie selbst verwalten. Andere nutzen einen Hyperscaler wie Microsoft Azure. Wieder andere übertragen den Betrieb der gesamten Umgebung im Rahmen eines Managed-Service-Vertrags an einen SAP-Partner. Die Tabelle zeigt daher ein typisches Verantwortungsmodell, jedoch keine allgemeingültige Regel für jede SAP-Business-One-Cloud-Umgebung. Cloud-Anbieter, Zugriffskontrolle, Verschlüsselung und Backups 

Welche Sicherheitsaufgaben übernimmt der Cloud-Anbieter? 

Gehen wir im Technologie-Stack eine Ebene tiefer zur Infrastruktur: Bei einer auf Azure gehosteten Umgebung ist Microsoft als Cloud-Anbieter für die zugrunde liegende physische Infrastruktur verantwortlich. Dazu gehören die physischen Rechenzentren, das physische Netzwerk sowie die Server, auf denen die Workloads ausgeführt werden. Wer für die darüberliegenden Ebenen verantwortlich ist, hängt vom jeweiligen Servicemodell ab. Pasted markdown 

Physische Sicherheit des Rechenzentrums 

Die Kontrolle des physischen Zugangs, die Gebäudesicherheit, der Schutz vor Umwelteinflüssen – beispielsweise durch Stromversorgung, Kühlung und Brandschutz – sowie die physische Hardware selbst liegen auf dieser Ebene in der Verantwortung des Cloud-Anbieters. 

Physische Netzwerkinfrastruktur 

Router, Switches und die zugrunde liegende Netzwerkinfrastruktur, über die das Rechenzentrum mit der Außenwelt verbunden ist, fallen ebenfalls in den Verantwortungsbereich des Anbieters. Dabei handelt es sich nicht um Komponenten, die der Kunde selbst konfiguriert oder direkt überprüft. 

Physische Hosts 

Auch die physischen Server, auf denen die Cloud-Workloads tatsächlich ausgeführt werden, einschließlich ihrer Wartung und ihres Austauschs, liegen in der Verantwortung des Cloud-Anbieters. 

Infrastruktur für Hochverfügbarkeit 

Je nach gewählter Architektur können Compute-Ressourcen, Storage, Netzwerk und die Konfiguration der Verfügbarkeit vollständig oder teilweise beim Cloud-Anbieter liegen.  Wie genau die Verantwortlichkeiten verteilt sind, hängt vom eingesetzten Servicemodell ab.  Hier lohnt sich eine klare Abgrenzung: Die Aussage „Azure sichert Ihre gesamte SAP-Business-One-Umgebung“ wäre nicht korrekt. Azure – oder ein vergleichbarer Hyperscaler – schützt den eigenen Teil des Technologie-Stacks. Die Konfiguration der Anwendung, Benutzerzugriffe und der Umgang mit Geschäftsdaten sind davon getrennte Verantwortungsbereiche. Pasted markdown 

Welche Sicherheitsmechanismen bietet SAP Business One? 

Authentifizierung  SAP Business One unterstützt eine eigene native Authentifizierung und kann zusätzlich mit Funktionen für das Identity and Authentication Management zusammenarbeiten.  Die aktuelle SAP-Dokumentation beschreibt unter anderem Unterstützung für: 

• die SAP-Business-One-eigene Authentifizierung, 

• Microsoft-Windows-Domänenauthentifizierung, 

• OpenID Connect (OIDC), 

• externe Identity Provider. 

Insbesondere OIDC ermöglicht es Unternehmen, sich mit einem bereits vorhandenen Konto eines Identity Providers anzumelden und dessen Sicherheitsmechanismen zu nutzen – beispielsweise eine Zwei-Faktor-Authentifizierung. Dadurch muss nicht zwangsläufig für SAP Business One ein weiteres separates Benutzerkonto mit eigenem Benutzernamen und Passwort verwaltet werden. 

Unterstützt SAP Business One Single Sign-on (SSO)? 

Ja. SAP Business One unterstützt verschiedene Identitäts- und Authentifizierungsmechanismen, darunter auch SSO-bezogene Funktionen über externe Identity Provider mittels OIDC. Welche konkrete Konfiguration verfügbar ist, hängt von der eingesetzten Version und Systemumgebung ab. Pasted markdown 

Wie steuert SAP Business One den Benutzerzugriff? 

Die Begriffe Authentifizierung und Autorisierung werden im Alltag häufig synonym verwendet. Tatsächlich beantworten sie jedoch zwei unterschiedliche Fragen: Authentifizierung: Wer sind Sie?  Autorisierung: Was dürfen Sie tun, nachdem Ihre Identität bestätigt wurde?  SAP Business One stellt Mechanismen bereit, mit denen sich der Datenbankzugriff einschränken und verhindern lässt, dass Endbenutzer direkt auf Datenbank-Anmeldedaten zugreifen. Dadurch werden Berechtigungsentscheidungen innerhalb der Anwendungsebene gesteuert, anstatt Zugangsdaten auf Datenbankebene unnötig offenzulegen.  In der Praxis sollte sich das an den tatsächlichen Aufgaben der Mitarbeiter orientieren.  Ein Mitarbeiter im Vertrieb benötigt beispielsweise typischerweise Zugriff auf:

• Kunden, 

• Angebote, 

• Kundenaufträge. 

Es gibt jedoch normalerweise keinen operativen Grund dafür, dass derselbe Mitarbeiter auf sensible Finanzkonfigurationen oder Einstellungen der Systemadministration zugreifen kann.  Ein Mitarbeiter im Lager benötigt dagegen beispielsweise Funktionen für:

• Bestandsverwaltung, 

• Wareneingang, 

• Kommissionierung. 

Finanzberichte oder Einstellungen zur Kreditsteuerung von Kunden gehören dagegen möglicherweise nicht zu seinem Aufgabenbereich.  Genau diese Zuordnung muss für jede Rolle und Abteilung sauber definiert werden. Erst dann wird aus dem abstrakten Begriff „Zugriffskontrolle“ eine Sicherheitsmaßnahme, die Risiken im Arbeitsalltag tatsächlich reduziert. Pasted markdown

Welche Sicherheitsverantwortung bleibt beim Kunden? 

Hier liegt ein erheblicher Teil des tatsächlichen Risikos. Denn diese Bereiche kann weder ein Hosting-Anbieter noch ein SAP-Partner vollständig im Namen des Kunden übernehmen. 

1. Benutzer-Lifecycle-Management Wer erhält wann ein Benutzerkonto?
2. Berechtigungen Welche Informationen und Funktionen darf ein Benutzer sehen, bearbeiten oder ausführen?
3. Offboarding von Mitarbeitern Was passiert unmittelbar, wenn ein Mitarbeiter das Unternehmen verlässt?
4. Privilegierte Benutzerkonten Wer besitzt Administratorrechte – und warum?
5. Endpoint-Sicherheit Laptops und Arbeitsplatzrechner, die auf das ERP-System zugreifen, müssen weiterhin geschützt werden.
6. Umgang mit Zugangsdaten Gemeinsam genutzte Benutzerkonten, schwache Passwörter und unnötige Administratorrechte sollten vermieden werden.
7. Interne Geschäftskontrollen Idealerweise sollte beispielsweise nicht dieselbe Person uneingeschränkt einen Lieferanten anlegen, eine Rechnung erfassen und die Zahlung freigeben können. Eine angemessene Funktionstrennung reduziert dieses Risiko.
8. Data Governance Wer darf:

• Kundendaten exportieren? 

• Finanzdaten einsehen? 

• Stammdaten verändern? 

• Berichte herunterladen? 

Auch Microsoft zählt Kundendaten, Identitäten, Benutzerkonten sowie Konfigurationen und Einstellungen zu den Bereichen, für die Kunden über die verschiedenen Cloud-Servicemodelle hinweg weiterhin Verantwortung tragen. Das entspricht weitgehend der Art und Weise, wie SAP die Verantwortung des Kunden im Zusammenhang mit SAP Business One beschreibt. Pasted markdown 

Wie werden Daten in SAP Business One verschlüsselt? 

Sind Daten in SAP Business One verschlüsselt? 

Das ist auf mehreren Ebenen möglich. Welche Verschlüsselungsmechanismen tatsächlich aktiv sind, hängt jedoch davon ab, wie Datenbank und Infrastruktur konkret konfiguriert wurden. Für SAP Business One auf SAP HANA dokumentiert SAP die Möglichkeit, folgende Komponenten zu verschlüsseln:

• Datenvolumes, 

• Redo-Logs, 

• Daten-Backups, 

• Log-Backups. 

Diese Bereiche können unabhängig voneinander verschlüsselt werden und schützen jeweils unterschiedliche Bestandteile der Systemumgebung.  SAP Business One dokumentiert in entsprechenden Konfigurationen außerdem eine SSL-Verschlüsselung für die Kommunikation zwischen Server und Clients. Dadurch werden Daten geschützt, während sie über das Netzwerk übertragen werden, und nicht nur dann, wenn sie auf einem Speichermedium liegen. Dabei sollten zwei Begriffe klar voneinander unterschieden werden: 

Verschlüsselung ruhender Daten – Encryption at Rest 

Sie schützt Daten dort, wo sie gespeichert sind, beispielsweise: 

• Datenbankdateien, 

• Backup-Medien. 

Verschlüsselung während der Übertragung – Encryption in Transit 

Sie schützt Daten, während sie zwischen Systemen übertragen werden, beispielsweise: 

• zwischen Client und Server, 

• zwischen zwei integrierten Anwendungen. 

Datenzustand	Beispiel	Relevanter Schutz
Ruhende Daten	ERP-Datenbank	Datenbank-/Speicherverschlüsselung
Datenübertragung	Client ↔ Server	TLS/SSL
Backup	Datenbank-Backup	Backup-Verschlüsselung
Zugangsdaten	Authentifizierung	IAM/Zugriffskontrollen

Werden Backups in SAP Business One Cloud automatisch erstellt? 

Nicht automatisch in dem Sinne, wie viele Unternehmen es zunächst verstehen.  Die korrekte Antwort lautet: 

Es hängt von der jeweiligen Hosting- und Managed-Service-Konfiguration ab. 

SAP empfiehlt in seinen Administrationsrichtlinien, eine Backup-Strategie auf Grundlage der individuellen Anforderungen und des Datenvolumens eines Unternehmens zu entwickeln und regelmäßige Backups der Anwendungsdatenbank durchzuführen.  Ein einziger Standard-Zeitplan ist daher nicht automatisch für jedes Unternehmen geeignet.  Bevor die Aussage „Wir erstellen Backups“ als ausreichende Antwort akzeptiert wird, sollten Unternehmen genauer nachfragen:

• Wie häufig werden Backups erstellt? 

• Wo werden die Backups gespeichert? 

• Sind die Backups verschlüsselt? 

• Wie lange werden sie aufbewahrt? 

• Werden Kopien geografisch getrennt gespeichert? 

• Wie schnell können die Daten tatsächlich wiederhergestellt werden? 

• Wann wurde zuletzt eine Wiederherstellung getestet? 

Ein wichtiger Unterschied: Backup, Disaster Recovery und High Availability sind nicht dasselbe 

Backup Eine wiederherstellbare Kopie der Daten.  Disaster Recovery Die Prozesse und die Infrastruktur, mit denen der Geschäftsbetrieb nach einem schwerwiegenden Ausfall wiederhergestellt werden kann.  High Availability Eine Architektur, deren Ziel es ist, Betriebsunterbrechungen von vornherein zu reduzieren.  Ein Unternehmen kann also über ausgezeichnete Backups verfügen und trotzdem keinen belastbaren Disaster-Recovery-Plan haben – beispielsweise dann, wenn nie getestet wurde, wie lange eine vollständige Wiederherstellung tatsächlich dauert. Pasted markdown

Wer ist für das Testen der Backups verantwortlich? 

Nur weil ein Backup-Job den Status „erfolgreich“ meldet, bedeutet das noch nicht, dass sich das Unternehmen im Ernstfall tatsächlich daraus wiederherstellen kann. Erst durch: 

• Wiederherstellungstests, 

• Prüfungen der Datenbankintegrität, 

• einen definierten Recovery Point Objective (RPO),

• einen definierten Recovery Time Objective (RTO)

wird aus einer reinen Backup-Routine ein tatsächlicher Wiederherstellungsplan. 

RPO – Recovery Point Objective 

Das RPO beschreibt, wie viele der zuletzt entstandenen Daten ein Unternehmen im schlimmsten Fall verlieren könnte bzw. zu verlieren bereit wäre.

RTO – Recovery Time Objective 

Das RTO beschreibt, wie lange das ERP-System maximal nicht verfügbar sein darf, bevor die Unterbrechung für das Unternehmen nicht mehr akzeptabel ist. Ein Beispiel:  Werden Backups nur alle 24 Stunden erstellt, könnten – abhängig von Architektur und Wiederherstellungsverfahren – theoretisch fast die Transaktionen eines ganzen Tages verloren gehen.  Für manche Unternehmen mag dieses Risiko vertretbar sein.  Für ein E-Commerce-Unternehmen, das täglich Hunderte Bestellungen verarbeitet, wäre der Verlust eines ganzen Geschäftstages dagegen kaum akzeptabel.  Genau deshalb sollten RPO und RTO konkret definierte und mit dem Unternehmen abgestimmte Werte sein – und keine Annahmen, die im Ernstfall zum ersten Mal überprüft werden. Pasted markdown

Wird SAP Business One automatisch sicherer, wenn es in die Cloud verlagert wird? 

Nein.  Eine professionelle Cloud-Infrastruktur kann bestimmte Risiken reduzieren, die beispielsweise durch schlecht gewartete lokale Hardware entstehen. Gleichzeitig erhalten Unternehmen Zugang zu Infrastruktur- und Sicherheitsmechanismen, die viele KMU intern nur mit erheblichem Aufwand selbst aufbauen könnten.  Das bedeutet jedoch nicht, dass andere Sicherheitsrisiken verschwinden.  Auch in einer professionell betriebenen Cloud-Umgebung können folgende Faktoren Schwachstellen verursachen: 

• zu weitreichende Benutzerberechtigungen, 

• schwache Passwörter, 

• unzureichend geschützte Endgeräte, 

• unsichere Integrationen, 

• fehlerhafte Konfigurationen, 

• fehlende interne Kontrollmechanismen. 

SAP empfiehlt selbst, Sicherheit als Thema der gesamten Systemlandschaft zu betrachten und Sicherheitsrichtlinien nicht ausschließlich auf SAP Business One zu beschränken. Das ist eine wichtige Perspektive: Das ERP-System ist nur ein Bestandteil einer größeren IT-Landschaft. Für das Gesamtrisiko ist häufig nicht deren stärkster, sondern deren schwächster Bestandteil entscheidend. Pasted markdown

Sicherheitsrisiken, Integrationen, Offboarding und Verantwortlichkeiten des SAP-Partners 

Welche sind die größten Sicherheitsrisiken bei SAP Business One Cloud, auf die KMU achten sollten? 

Dabei handelt es sich keineswegs um außergewöhnliche oder hochkomplexe Bedrohungen. Die meisten Risiken entstehen durch alltägliche operative Lücken, die sich im Laufe der Zeit unbemerkt entwickeln.  Zu weitreichende Benutzerberechtigungen: Zu viele Benutzer verfügen über mehr Zugriffsrechte, als sie für ihre tatsächliche Rolle benötigen.  Inaktive Benutzerkonten: Ehemalige Mitarbeiter, frühere externe Dienstleister oder nicht mehr verwendete Integrationen verfügen weiterhin über aktive Zugangsdaten.  Gemeinsam genutzte Benutzerkonten: Wenn mehrere Personen dasselbe Benutzerkonto verwenden, leidet die Nachvollziehbarkeit. Im Zweifelsfall lässt sich nicht eindeutig feststellen, wer eine bestimmte Aktion tatsächlich durchgeführt hat.  Unzureichend geschützte Endgeräte: Die Cloud-Umgebung selbst kann professionell abgesichert sein, während der Laptop eines Mitarbeiters, der darauf zugreift, nicht ausreichend geschützt ist.  Unsichere Integrationen: Jede API und jede Integration erweitert potenziell die Angriffsfläche – nicht nur der angebundene Online-Shop oder die jeweilige Anwendung.  Nicht gepatchte Komponenten: Add-ons, Middleware und weitere Abhängigkeiten benötigen ein eigenes Lifecycle-Management. Es reicht nicht aus, ausschließlich das zentrale ERP-System aktuell zu halten.  Unzureichende Backup-Strategie: Backups, die zwar regelmäßig erstellt, aber nie tatsächlich wiederhergestellt und getestet wurden, vermitteln möglicherweise eine falsche Sicherheit.  Fehlkonfigurationen: Auch in der Cloud hängt Sicherheit wesentlich von der richtigen Konfiguration ab. Allein die Tatsache, dass sich ein System „in der Cloud“ befindet, macht es nicht automatisch sicher. Pasted markdown 

Wie sollten SAP-Business-One-Integrationen abgesichert werden? 

Moderne SAP-Business-One-Umgebungen arbeiten nur selten vollständig isoliert.  Typische angebundene Systeme und Plattformen sind beispielsweise: 

• Magento, 

• Shopify, 

• WooCommerce, 

• CRM-Systeme, 

• Bankanbindungen, 

• Dokumentenmanagementsysteme, 

• Zahlungsdienstleister, 

• Versanddienstleister, 

• weitere Drittanbieteranwendungen. 

Eine typische Systemlandschaft kann vereinfacht so aussehen: 

SAP Business One ↔ API / Service Layer / Integrationsschicht ↔ Externes System 

Jede einzelne Verbindung in dieser Kette wirft eigene Sicherheitsfragen auf: 

• Wie wird die Verbindung authentifiziert? 

• Wie werden API-Zugangsdaten gespeichert? 

• Wie und wann werden API-Zugangsdaten erneuert bzw. rotiert? 

• Über welche Berechtigungen verfügt die Integration tatsächlich? 

• Wird die Datenübertragung verschlüsselt? 

• Werden Aktivitäten protokolliert? 

• Wie werden Fehler behandelt? 

• Gibt es öffentlich erreichbare Endpunkte, die seit Monaten nicht mehr überprüft wurden? 

Kann ein sicheres SAP-Business-One-System durch eine unsichere Integration gefährdet werden? 

Ja.  Die allgemeine Sicherheitslage wird durch die gesamte Systemlandschaft eines Unternehmens bestimmt – und nicht allein durch die Sicherheit der ERP-Anwendung.  Selbst eine optimal konfigurierte SAP-Business-One-Instanz kann Risiken ausgesetzt sein, wenn sie mit einer unzureichend abgesicherten Integration verbunden ist.  Mit anderen Worten:  Die Sicherheit der gesamten ERP-Landschaft ist nur so stark wie die Sicherheit ihrer angebundenen Systeme und Schnittstellen. Pasted markdown

Was passiert, wenn ein Mitarbeiter das Unternehmen verlässt? 

An diesem Punkt treffen die guten Absichten einer Sicherheitsrichtlinie auf die Realität eines arbeitsintensiven HR-Prozesses.  Ein sinnvoller ERP-Offboarding-Prozess sollte beispielsweise folgende Schritte umfassen:

1. SAP-Business-One-Benutzerkonto deaktivieren 

1. Remote-Zugriff widerrufen 

1. Zugriff über den Identity Provider entfernen 

1. VPN-Zugriff deaktivieren 

1. Administratorrechte entziehen 

1. Gemeinsam genutzte Zugangsdaten oder API-Credentials ändern, sofern der Mitarbeiter darauf Zugriff hatte 

1. Vom Mitarbeiter verwaltete Integrationen überprüfen 

1. Firmengeräte zurückfordern 

1. Falls erforderlich, kürzlich durchgeführte Aktivitäten überprüfen 

Das Auslassen eines einzelnen Schrittes führt normalerweise nicht unmittelbar zu einem Sicherheitsvorfall.  Es hinterlässt jedoch möglicherweise eine offene Zugangsmöglichkeit, die zu einem späteren Zeitpunkt zum Problem werden kann. Pasted markdown 

Wie häufig sollten die Zugriffsrechte in SAP Business One überprüft werden? 

Der wichtigste Grundsatz:  Benutzer sollten genau die Zugriffsrechte erhalten, die sie zur Erfüllung ihrer Aufgaben benötigen – und nicht einfach jene Berechtigungen behalten, die bei der ursprünglichen Einrichtung ihres Benutzerkontos am einfachsten zu vergeben waren.  Dieses Prinzip wird häufig als Least-Privilege-Prinzip bezeichnet. Eine Überprüfung der Berechtigungen ist insbesondere sinnvoll, wenn: 

• sich die Rolle eines Mitarbeiters ändert, 

• ein Mitarbeiter in eine andere Abteilung wechselt, 

• neue Integrationen produktiv geschaltet werden, 

• neue Add-ons implementiert werden, 

• das Unternehmen organisatorisch umstrukturiert wird, 

• Mitarbeiter das Unternehmen verlassen, 

• ein Sicherheitsvorfall auftritt. 

Zusätzlich zu diesen konkreten Auslösern sollten regelmäßige Überprüfungen anhand der individuellen Risiko- und Compliance-Anforderungen des Unternehmens erfolgen. Eine pauschale Überprüfungsfrequenz, die für jedes Unternehmen gleichermaßen geeignet ist, gibt es nicht. Pasted markdown 

Welche Aufgaben sollte ein SAP-Partner in einer Cloud-Umgebung übernehmen? 

Ein SAP-Partner bzw. Managed Service Provider kann je nach vereinbartem Leistungsumfang zahlreiche technische und operative Aufgaben übernehmen.  Dazu können beispielsweise gehören: 

• Einrichtung der Infrastruktur, 

• Installation von SAP Business One, 

• Datenbankadministration, 

• Updates und Patches, 

• Systemüberwachung, 

• Durchführung von Backups, 

• Unterstützung bei Wiederherstellungen, 

• Sicherheitskonfiguration, 

• Firewall-Konfiguration, 

• Unterstützung bei Integrationen, 

• Performance-Monitoring, 

• Fehleranalyse und Incident Troubleshooting. 

Wie diese Verantwortlichkeiten konkret verteilt sind, hängt jedoch immer vom jeweiligen Servicevertrag ab. Nicht jeder Managed-Service-Vertrag definiert die Verantwortlichkeiten auf dieselbe Weise. 

Was übernimmt ein SAP-Business-One-Cloud-Partner tatsächlich? 

In vielen Betriebsmodellen übernimmt der SAP-Partner den technischen Betrieb der Umgebung, beispielsweise: 

Infrastruktur → Patching → Backup-Betrieb → Monitoring → technische Unterstützung 

Der Kunde bleibt dagegen typischerweise verantwortlich für:  Benutzerzugriffe → Entscheidungen über Berechtigungen → Data Governance → interne Prozesskontrollen  Die konkrete Aufteilung sollte jedoch schriftlich festgelegt und nicht lediglich aus einem Verkaufsgespräch abgeleitet werden. Gerade bei sicherheitskritischen Verantwortlichkeiten ist es wichtig, eindeutig zu dokumentieren:  Wer macht was – und wer reagiert, wenn etwas nicht funktioniert? Pasted markdown 

Welche Sicherheitsfragen sollten Sie einem SAP-Business-One-Cloud-Anbieter stellen? 

Bevor Sie sich für einen Cloud-Anbieter oder Managed Service Provider entscheiden, sollten Verantwortlichkeiten, Backup-Prozesse und Wiederherstellungsziele konkret geklärt werden.  Folgende Fragen gehören auf die Checkliste: 

1. Wo wird unsere SAP-Business-One-Umgebung gehostet?

1. Wer verwaltet das Betriebssystem?

1. Wer installiert Sicherheitsupdates und Patches?

1. Wie häufig werden Backups erstellt?

1. Werden die Backups verschlüsselt?

1. Wo werden die Backups gespeichert?

1. Wie lange werden die Backups aufbewahrt?

1. Wann wurde zuletzt eine Wiederherstellung getestet?

1. Welches RPO (Recovery Point Objective) ist vorgesehen?

1. Welches RTO (Recovery Time Objective) ist vorgesehen?

1. Wer überwacht die Systemumgebung?

1. Wie werden Administratorzugänge kontrolliert?

1. Wie werden Integrationen und Schnittstellen abgesichert?

1. Was passiert im Falle eines Sicherheitsvorfalls?

1. Welche Sicherheitsverantwortlichkeiten verbleiben bei unserem Unternehmen? 

Diese Fragen helfen dabei, aus einem allgemeinen Versprechen wie „Ihre SAP-Umgebung wird sicher in der Cloud betrieben“ konkrete, überprüfbare Verantwortlichkeiten und Serviceleistungen abzuleiten. Sicherheitscheckliste und Verantwortungsmatrix  SAP Business One Cloud Sicherheitscheckliste für KMU  Die folgende Checkliste fasst die wichtigsten Bereiche zusammen, die Unternehmen bei der Absicherung einer SAP-Business-One-Cloud-Umgebung berücksichtigen sollten. Pasted markdown  Identität 

• Individuelle Benutzerkonten 

• Starke Authentifizierung 

• SSO-/Identity-Provider-Strategie, sofern sinnvoll 

• Zeitnahes Offboarding ausscheidender Mitarbeiter 

Zugriff und Berechtigungen 

• Least-Privilege-Prinzip 

• Rollenbasierte Berechtigungen 

• Begrenzte Anzahl an Administratorkonten 

• Regelmäßige Überprüfung der Zugriffsrechte 

Infrastruktur 

• Unterstützte und aktuelle Software 

• Regelmäßige Sicherheitsupdates 

• Firewall- und Netzwerkkontrollen 

• Kontinuierliches Monitoring 

Daten 

• Definierte Verschlüsselungsstrategie 

• Kontrollierter Datenzugriff 

• Richtlinien für sensible Daten 

Backups 

• Definierter Backup-Zeitplan 

• Verschlüsselung der Backups 

• Festgelegte Aufbewahrungsrichtlinie 

• Regelmäßige Wiederherstellungstests 

• Dokumentierte RPO- und RTO-Werte 

Integrationen 

• Abgesicherte APIs 

• Geschützte Zugangsdaten 

• Protokollierung relevanter Aktivitäten 

• Regelmäßige Rotation von Zugangsdaten 

• Entfernung nicht mehr benötigter Verbindungen 

Endgeräte 

• Aktuelle und regelmäßig aktualisierte Geräte 

• Endpoint-Schutz 

• Kontrollierter Remote-Zugriff 

Verantwortungsmatrix für die Sicherheit von SAP Business One Cloud 

Die folgende Matrix bildet eine zentrale Referenz für die Aufteilung der Sicherheitsverantwortung. Statt einfacher Häkchen oder Kreuze verwendet sie eine differenzierte Einteilung: 

Hauptverantwortung / Geteilte Verantwortung / Kundenseitig gesteuert / Abhängig von der Vereinbarung 

Diese Unterscheidung ist wichtig, weil ein einfaches Ja/Nein-Modell die tatsächliche Verteilung der Verantwortlichkeiten in vielen realen SAP-Business-One-Cloud-Umgebungen nicht korrekt abbilden würde. Pasted markdown Wenn ein Unternehmen SAP Business One vom eigenen Server im Büro in eine professionell verwaltete Cloud-Umgebung verlagert, liegt eine Annahme zunächst nahe: Um die Sicherheit kümmert sich jetzt jemand anderes.  „Der Cloud-Anbieter übernimmt jetzt die Sicherheit“ – diesen Satz hört man bei einer solchen Umstellung häufig.  Ganz so einfach ist es jedoch nicht.  Eine Cloud-Infrastruktur nimmt der internen IT zwar zahlreiche Aufgaben ab: Server müssen nicht mehr selbst betrieben werden, ein veraltetes Betriebssystem muss nicht intern gepatcht werden und auch ein ausgefallenes Laufwerk mitten in der Nacht ist nicht länger das Problem des eigenen IT-Teams.  Was dadurch jedoch nicht entfällt, ist die Verantwortung des Unternehmens dafür, 

• wer Zugriff auf das System erhält, 

• welche Daten und Funktionen einzelne Benutzer sehen und bearbeiten dürfen, 

• wie die Endgeräte geschützt werden, die auf SAP Business One zugreifen, 

• und wie sensible Unternehmensdaten durch interne Prozesse geschützt werden. 

Auch Microsoft macht diesen Punkt in seinen eigenen Richtlinien zur Cloud-Sicherheit deutlich: Kunden bleiben grundsätzlich für ihre Daten, Identitäten und Benutzerkonten verantwortlich. Wie die Verantwortung für die zugrunde liegende Infrastruktur verteilt ist, hängt dagegen davon ab, ob es sich um IaaS, PaaS oder SaaS handelt. Dieser Artikel zeigt deshalb konkret, wo die Verantwortungsgrenzen bei SAP Business One in der Cloud liegen. Als Grundlage dienen dabei sowohl das Shared-Responsibility-Prinzip von SAP als auch das Cloud-Sicherheitsmodell von Microsoft – statt „Cloud Security“ einfach als pauschales Sicherheitsversprechen zu behandeln.

Ist SAP Business One Cloud sicher? 

Kurzantwort  SAP Business One kann mit zahlreichen Sicherheitsmechanismen betrieben werden, darunter Authentifizierung, Autorisierung, Verschlüsselung, Datenbankschutz und Backups. In einer Cloud-Umgebung ist Sicherheit jedoch immer eine geteilte Verantwortung. Der Hosting-Anbieter bzw. SAP-Partner schützt und betreibt die Infrastruktur. Das Unternehmen selbst bleibt dagegen unter anderem für Benutzer, Berechtigungen, Geschäftsdaten, Endgeräte und interne Zugriffsrichtlinien verantwortlich.

Was bedeutet „Shared Responsibility“ bei SAP Business One Cloud? 

Cloud-Sicherheit bei SAP Business One funktioniert nicht nach dem Prinzip:  Cloud-Anbieter = 100 % verantwortlich Kunde = muss sich um nichts mehr kümmern  Stattdessen lässt sich die Umgebung eher als Zusammenspiel verschiedener Ebenen betrachten:  Cloud-Infrastruktur ↓ SAP-Umgebung ↓ SAP-Partner bzw. Managed Service Provider ↓ Interne Sicherheitsmaßnahmen des Kunden  Alle diese Ebenen tragen gleichzeitig zur Sicherheit des Gesamtsystems bei.  Auch SAP unterteilt die Verantwortung für Cloud-Sicherheit zwischen SAP, dem Kunden und dem Public-Cloud-Anbieter. Dabei stellt SAP ausdrücklich klar, dass bestimmte Verantwortlichkeiten weiterhin beim Kunden liegen. Dazu gehören beispielsweise:

• Administration der Lösung, 

• Benutzerzugriffe, 

• Datenzugriffe, 

• sowie bestimmte Aufgaben bei der Erkennung und Behandlung von Sicherheitsbedrohungen. 

Das gilt auch dann, wenn die zugrunde liegende Infrastruktur bereits an einen Cloud-Anbieter ausgelagert wurde. 

Wer ist für die Sicherheit von SAP Business One Cloud verantwortlich? 

Ist der Cloud-Anbieter für die gesamte ERP-Sicherheit verantwortlich? 

Diese beiden Fragen stellen sich Unternehmen besonders häufig zu Beginn eines Cloud-Projekts.  Die präzise Antwort lautet in beiden Fällen:  Nur teilweise – entscheidend ist, über welche Ebene der Systemlandschaft wir sprechen. SAP Business One Cloud: Wer trägt welche Verantwortung?

Sicherheitsbereich	Cloud-/Hosting-Ebene	SAP-/Lösungsebene	SAP-Partner / Managed Service*	Kunde
Physisches Rechenzentrum	Hauptverantwortung	–	–	–
Compute-/Storage-Infrastruktur	Hauptverantwortung	–	Operative Überwachung	–
SAP-B1-Installation	–	Produkt	Haupt-/geteilte Verantwortung	–
Updates & Patches	–	Produktupdates	Haupt-/geteilte Verantwortung	Governance
Backup-Betrieb	Infrastrukturunterstützung	–	Haupt-/geteilte Verantwortung	Anforderungen/Validierung
Benutzeranlage	–	Funktionalität	Unterstützung	Hauptverantwortung
Benutzerberechtigungen	–	Funktionalität	Unterstützung	Hauptverantwortung
Geschäftsdaten	Schutz der Infrastruktur	Anwendungskontrollen	Operative Unterstützung	Hauptverantwortung/Eigentümerschaft
Endpoint-Sicherheit	–	–	Beratung	Hauptverantwortung
Sicherheit von Integrationen	Geteilt	APIs/Funktionen	Geteilt	Geteilt
Sicherheitsüberwachung	Geteilt	Geteilt	Geteilt	Geteilt

*Die genaue Aufteilung der Verantwortlichkeiten hängt immer vom gewählten Hosting- und Managed-Service-Vertrag ab. Dieser Hinweis ist wichtig, denn SAP-Business-One-Umgebungen können sehr unterschiedlich betrieben werden.  Einige Unternehmen betreiben SAP Business One auf einer Infrastruktur, die sie selbst verwalten. Andere nutzen einen Hyperscaler wie Microsoft Azure. Wieder andere übertragen den Betrieb der gesamten Umgebung im Rahmen eines Managed-Service-Vertrags an einen SAP-Partner. Die Tabelle zeigt daher ein typisches Verantwortungsmodell, jedoch keine allgemeingültige Regel für jede SAP-Business-One-Cloud-Umgebung.

Cloud-Anbieter, Zugriffskontrolle, Verschlüsselung und Backups 

Welche Sicherheitsaufgaben übernimmt der Cloud-Anbieter? 

Gehen wir im Technologie-Stack eine Ebene tiefer zur Infrastruktur: Bei einer auf Azure gehosteten Umgebung ist Microsoft als Cloud-Anbieter für die zugrunde liegende physische Infrastruktur verantwortlich. Dazu gehören die physischen Rechenzentren, das physische Netzwerk sowie die Server, auf denen die Workloads ausgeführt werden.  Wer für die darüberliegenden Ebenen verantwortlich ist, hängt vom jeweiligen Servicemodell ab. Pasted markdown 

Physische Sicherheit des Rechenzentrums 

Die Kontrolle des physischen Zugangs, die Gebäudesicherheit, der Schutz vor Umwelteinflüssen – beispielsweise durch Stromversorgung, Kühlung und Brandschutz – sowie die physische Hardware selbst liegen auf dieser Ebene in der Verantwortung des Cloud-Anbieters. 

Physische Netzwerkinfrastruktur 

Router, Switches und die zugrunde liegende Netzwerkinfrastruktur, über die das Rechenzentrum mit der Außenwelt verbunden ist, fallen ebenfalls in den Verantwortungsbereich des Anbieters. Dabei handelt es sich nicht um Komponenten, die der Kunde selbst konfiguriert oder direkt überprüft.  Physische Hosts  Auch die physischen Server, auf denen die Cloud-Workloads tatsächlich ausgeführt werden, einschließlich ihrer Wartung und ihres Austauschs, liegen in der Verantwortung des Cloud-Anbieters.  Infrastruktur für Hochverfügbarkeit  Je nach gewählter Architektur können Compute-Ressourcen, Storage, Netzwerk und die Konfiguration der Verfügbarkeit vollständig oder teilweise beim Cloud-Anbieter liegen.  Wie genau die Verantwortlichkeiten verteilt sind, hängt vom eingesetzten Servicemodell ab.  Hier lohnt sich eine klare Abgrenzung: Die Aussage „Azure sichert Ihre gesamte SAP-Business-One-Umgebung“ wäre nicht korrekt.  Azure – oder ein vergleichbarer Hyperscaler – schützt den eigenen Teil des Technologie-Stacks. Die Konfiguration der Anwendung, Benutzerzugriffe und der Umgang mit Geschäftsdaten sind davon getrennte Verantwortungsbereiche. Pasted markdown 

Welche Sicherheitsmechanismen bietet SAP Business One? 

Authentifizierung  SAP Business One unterstützt eine eigene native Authentifizierung und kann zusätzlich mit Funktionen für das Identity and Authentication Management zusammenarbeiten.  Die aktuelle SAP-Dokumentation beschreibt unter anderem Unterstützung für: 

• die SAP-Business-One-eigene Authentifizierung, 

• Microsoft-Windows-Domänenauthentifizierung, 

• OpenID Connect (OIDC), 

• externe Identity Provider. 

Insbesondere OIDC ermöglicht es Unternehmen, sich mit einem bereits vorhandenen Konto eines Identity Providers anzumelden und dessen Sicherheitsmechanismen zu nutzen – beispielsweise eine Zwei-Faktor-Authentifizierung. Dadurch muss nicht zwangsläufig für SAP Business One ein weiteres separates Benutzerkonto mit eigenem Benutzernamen und Passwort verwaltet werden. 

Unterstützt SAP Business One Single Sign-on (SSO)? 

Ja. SAP Business One unterstützt verschiedene Identitäts- und Authentifizierungsmechanismen, darunter auch SSO-bezogene Funktionen über externe Identity Provider mittels OIDC. Welche konkrete Konfiguration verfügbar ist, hängt von der eingesetzten Version und Systemumgebung ab. Pasted markdown 

Wie steuert SAP Business One den Benutzerzugriff? 

Die Begriffe Authentifizierung und Autorisierung werden im Alltag häufig synonym verwendet. Tatsächlich beantworten sie jedoch zwei unterschiedliche Fragen: Authentifizierung: Wer sind Sie?  Autorisierung: Was dürfen Sie tun, nachdem Ihre Identität bestätigt wurde?  SAP Business One stellt Mechanismen bereit, mit denen sich der Datenbankzugriff einschränken und verhindern lässt, dass Endbenutzer direkt auf Datenbank-Anmeldedaten zugreifen. Dadurch werden Berechtigungsentscheidungen innerhalb der Anwendungsebene gesteuert, anstatt Zugangsdaten auf Datenbankebene unnötig offenzulegen.  In der Praxis sollte sich das an den tatsächlichen Aufgaben der Mitarbeiter orientieren.  Ein Mitarbeiter im Vertrieb benötigt beispielsweise typischerweise Zugriff auf:

• Kunden, 

• Angebote, 

• Kundenaufträge. 

Es gibt jedoch normalerweise keinen operativen Grund dafür, dass derselbe Mitarbeiter auf sensible Finanzkonfigurationen oder Einstellungen der Systemadministration zugreifen kann.  Ein Mitarbeiter im Lager benötigt dagegen beispielsweise Funktionen für:

• Bestandsverwaltung, 

• Wareneingang, 

• Kommissionierung. 

Finanzberichte oder Einstellungen zur Kreditsteuerung von Kunden gehören dagegen möglicherweise nicht zu seinem Aufgabenbereich.  Genau diese Zuordnung muss für jede Rolle und Abteilung sauber definiert werden. Erst dann wird aus dem abstrakten Begriff „Zugriffskontrolle“ eine Sicherheitsmaßnahme, die Risiken im Arbeitsalltag tatsächlich reduziert. Pasted markdown

Welche Sicherheitsverantwortung bleibt beim Kunden? 

Hier liegt ein erheblicher Teil des tatsächlichen Risikos. Denn diese Bereiche kann weder ein Hosting-Anbieter noch ein SAP-Partner vollständig im Namen des Kunden übernehmen. 

1. Benutzer-Lifecycle-Management Wer erhält wann ein Benutzerkonto?
2. Berechtigungen Welche Informationen und Funktionen darf ein Benutzer sehen, bearbeiten oder ausführen?
3. Offboarding von Mitarbeitern Was passiert unmittelbar, wenn ein Mitarbeiter das Unternehmen verlässt?
4. Privilegierte Benutzerkonten Wer besitzt Administratorrechte – und warum?
5. Endpoint-Sicherheit Laptops und Arbeitsplatzrechner, die auf das ERP-System zugreifen, müssen weiterhin geschützt werden.
6. Umgang mit Zugangsdaten Gemeinsam genutzte Benutzerkonten, schwache Passwörter und unnötige Administratorrechte sollten vermieden werden.
7. Interne Geschäftskontrollen Idealerweise sollte beispielsweise nicht dieselbe Person uneingeschränkt einen Lieferanten anlegen, eine Rechnung erfassen und die Zahlung freigeben können. Eine angemessene Funktionstrennung reduziert dieses Risiko.
8. Data Governance Wer darf:

• Kundendaten exportieren? 

• Finanzdaten einsehen? 

• Stammdaten verändern? 

• Berichte herunterladen? 

Auch Microsoft zählt Kundendaten, Identitäten, Benutzerkonten sowie Konfigurationen und Einstellungen zu den Bereichen, für die Kunden über die verschiedenen Cloud-Servicemodelle hinweg weiterhin Verantwortung tragen. Das entspricht weitgehend der Art und Weise, wie SAP die Verantwortung des Kunden im Zusammenhang mit SAP Business One beschreibt. Pasted markdown 

Wie werden Daten in SAP Business One verschlüsselt? 

Sind Daten in SAP Business One verschlüsselt? 

Das ist auf mehreren Ebenen möglich. Welche Verschlüsselungsmechanismen tatsächlich aktiv sind, hängt jedoch davon ab, wie Datenbank und Infrastruktur konkret konfiguriert wurden. Für SAP Business One auf SAP HANA dokumentiert SAP die Möglichkeit, folgende Komponenten zu verschlüsseln: 

• Datenvolumes, 

• Redo-Logs, 

• Daten-Backups, 

• Log-Backups. 

Diese Bereiche können unabhängig voneinander verschlüsselt werden und schützen jeweils unterschiedliche Bestandteile der Systemumgebung.  SAP Business One dokumentiert in entsprechenden Konfigurationen außerdem eine SSL-Verschlüsselung für die Kommunikation zwischen Server und Clients. Dadurch werden Daten geschützt, während sie über das Netzwerk übertragen werden, und nicht nur dann, wenn sie auf einem Speichermedium liegen. Dabei sollten zwei Begriffe klar voneinander unterschieden werden: 

Verschlüsselung ruhender Daten – Encryption at Rest 

Sie schützt Daten dort, wo sie gespeichert sind, beispielsweise: 

• Datenbankdateien, 

• Backup-Medien. 

Verschlüsselung während der Übertragung – Encryption in Transit 

Sie schützt Daten, während sie zwischen Systemen übertragen werden, beispielsweise: 

• zwischen Client und Server, 

• zwischen zwei integrierten Anwendungen. 

Datenzustand	Beispiel	Relevanter Schutz
Ruhende Daten	ERP-Datenbank	Datenbank-/Speicherverschlüsselung
Datenübertragung	Client ↔ Server	TLS/SSL
Backup	Datenbank-Backup	Backup-Verschlüsselung
Zugangsdaten	Authentifizierung	IAM/Zugriffskontrollen

Werden Backups in SAP Business One Cloud automatisch erstellt? 

Nicht automatisch in dem Sinne, wie viele Unternehmen es zunächst verstehen.  Die korrekte Antwort lautet: 

Es hängt von der jeweiligen Hosting- und Managed-Service-Konfiguration ab. 

SAP empfiehlt in seinen Administrationsrichtlinien, eine Backup-Strategie auf Grundlage der individuellen Anforderungen und des Datenvolumens eines Unternehmens zu entwickeln und regelmäßige Backups der Anwendungsdatenbank durchzuführen.  Ein einziger Standard-Zeitplan ist daher nicht automatisch für jedes Unternehmen geeignet.  Bevor die Aussage „Wir erstellen Backups“ als ausreichende Antwort akzeptiert wird, sollten Unternehmen genauer nachfragen:

• Wie häufig werden Backups erstellt? 

• Wo werden die Backups gespeichert? 

• Sind die Backups verschlüsselt? 

• Wie lange werden sie aufbewahrt? 

• Werden Kopien geografisch getrennt gespeichert? 

• Wie schnell können die Daten tatsächlich wiederhergestellt werden? 

• Wann wurde zuletzt eine Wiederherstellung getestet? 

Ein wichtiger Unterschied: Backup, Disaster Recovery und High Availability sind nicht dasselbe 

Backup Eine wiederherstellbare Kopie der Daten.  Disaster Recovery Die Prozesse und die Infrastruktur, mit denen der Geschäftsbetrieb nach einem schwerwiegenden Ausfall wiederhergestellt werden kann.  High Availability Eine Architektur, deren Ziel es ist, Betriebsunterbrechungen von vornherein zu reduzieren.  Ein Unternehmen kann also über ausgezeichnete Backups verfügen und trotzdem keinen belastbaren Disaster-Recovery-Plan haben – beispielsweise dann, wenn nie getestet wurde, wie lange eine vollständige Wiederherstellung tatsächlich dauert. Pasted markdown

Wer ist für das Testen der Backups verantwortlich? 

Nur weil ein Backup-Job den Status „erfolgreich“ meldet, bedeutet das noch nicht, dass sich das Unternehmen im Ernstfall tatsächlich daraus wiederherstellen kann. Erst durch: 

• Wiederherstellungstests, 

• Prüfungen der Datenbankintegrität, 

• einen definierten Recovery Point Objective (RPO),

• einen definierten Recovery Time Objective (RTO)

wird aus einer reinen Backup-Routine ein tatsächlicher Wiederherstellungsplan. 

RPO – Recovery Point Objective 

Das RPO beschreibt, wie viele der zuletzt entstandenen Daten ein Unternehmen im schlimmsten Fall verlieren könnte bzw. zu verlieren bereit wäre.

RTO – Recovery Time Objective 

Das RTO beschreibt, wie lange das ERP-System maximal nicht verfügbar sein darf, bevor die Unterbrechung für das Unternehmen nicht mehr akzeptabel ist. Ein Beispiel:  Werden Backups nur alle 24 Stunden erstellt, könnten – abhängig von Architektur und Wiederherstellungsverfahren – theoretisch fast die Transaktionen eines ganzen Tages verloren gehen.  Für manche Unternehmen mag dieses Risiko vertretbar sein.  Für ein E-Commerce-Unternehmen, das täglich Hunderte Bestellungen verarbeitet, wäre der Verlust eines ganzen Geschäftstages dagegen kaum akzeptabel.  Genau deshalb sollten RPO und RTO konkret definierte und mit dem Unternehmen abgestimmte Werte sein – und keine Annahmen, die im Ernstfall zum ersten Mal überprüft werden. Pasted markdown

Wird SAP Business One automatisch sicherer, wenn es in die Cloud verlagert wird? 

Nein.  Eine professionelle Cloud-Infrastruktur kann bestimmte Risiken reduzieren, die beispielsweise durch schlecht gewartete lokale Hardware entstehen. Gleichzeitig erhalten Unternehmen Zugang zu Infrastruktur- und Sicherheitsmechanismen, die viele KMU intern nur mit erheblichem Aufwand selbst aufbauen könnten.  Das bedeutet jedoch nicht, dass andere Sicherheitsrisiken verschwinden.  Auch in einer professionell betriebenen Cloud-Umgebung können folgende Faktoren Schwachstellen verursachen: 

• zu weitreichende Benutzerberechtigungen, 

• schwache Passwörter, 

• unzureichend geschützte Endgeräte, 

• unsichere Integrationen, 

• fehlerhafte Konfigurationen, 

• fehlende interne Kontrollmechanismen. 

SAP empfiehlt selbst, Sicherheit als Thema der gesamten Systemlandschaft zu betrachten und Sicherheitsrichtlinien nicht ausschließlich auf SAP Business One zu beschränken. Das ist eine wichtige Perspektive: Das ERP-System ist nur ein Bestandteil einer größeren IT-Landschaft. Für das Gesamtrisiko ist häufig nicht deren stärkster, sondern deren schwächster Bestandteil entscheidend. Pasted markdown

Sicherheitsrisiken, Integrationen, Offboarding und Verantwortlichkeiten des SAP-Partners 

Welche sind die größten Sicherheitsrisiken bei SAP Business One Cloud, auf die KMU achten sollten? 

Dabei handelt es sich keineswegs um außergewöhnliche oder hochkomplexe Bedrohungen. Die meisten Risiken entstehen durch alltägliche operative Lücken, die sich im Laufe der Zeit unbemerkt entwickeln.  Zu weitreichende Benutzerberechtigungen: Zu viele Benutzer verfügen über mehr Zugriffsrechte, als sie für ihre tatsächliche Rolle benötigen.  Inaktive Benutzerkonten: Ehemalige Mitarbeiter, frühere externe Dienstleister oder nicht mehr verwendete Integrationen verfügen weiterhin über aktive Zugangsdaten.  Gemeinsam genutzte Benutzerkonten: Wenn mehrere Personen dasselbe Benutzerkonto verwenden, leidet die Nachvollziehbarkeit. Im Zweifelsfall lässt sich nicht eindeutig feststellen, wer eine bestimmte Aktion tatsächlich durchgeführt hat.  Unzureichend geschützte Endgeräte: Die Cloud-Umgebung selbst kann professionell abgesichert sein, während der Laptop eines Mitarbeiters, der darauf zugreift, nicht ausreichend geschützt ist.  Unsichere Integrationen: Jede API und jede Integration erweitert potenziell die Angriffsfläche – nicht nur der angebundene Online-Shop oder die jeweilige Anwendung.  Nicht gepatchte Komponenten: Add-ons, Middleware und weitere Abhängigkeiten benötigen ein eigenes Lifecycle-Management. Es reicht nicht aus, ausschließlich das zentrale ERP-System aktuell zu halten.  Unzureichende Backup-Strategie: Backups, die zwar regelmäßig erstellt, aber nie tatsächlich wiederhergestellt und getestet wurden, vermitteln möglicherweise eine falsche Sicherheit.  Fehlkonfigurationen: Auch in der Cloud hängt Sicherheit wesentlich von der richtigen Konfiguration ab. Allein die Tatsache, dass sich ein System „in der Cloud“ befindet, macht es nicht automatisch sicher. Pasted markdown 

Wie sollten SAP-Business-One-Integrationen abgesichert werden? 

Moderne SAP-Business-One-Umgebungen arbeiten nur selten vollständig isoliert.  Typische angebundene Systeme und Plattformen sind beispielsweise: 

• Magento, 

• Shopify, 

• WooCommerce, 

• CRM-Systeme, 

• Bankanbindungen, 

• Dokumentenmanagementsysteme, 

• Zahlungsdienstleister, 

• Versanddienstleister, 

• weitere Drittanbieteranwendungen. 

Eine typische Systemlandschaft kann vereinfacht so aussehen: 

SAP Business One ↔ API / Service Layer / Integrationsschicht ↔ Externes System 

Jede einzelne Verbindung in dieser Kette wirft eigene Sicherheitsfragen auf: 

• Wie wird die Verbindung authentifiziert? 

• Wie werden API-Zugangsdaten gespeichert? 

• Wie und wann werden API-Zugangsdaten erneuert bzw. rotiert? 

• Über welche Berechtigungen verfügt die Integration tatsächlich? 

• Wird die Datenübertragung verschlüsselt? 

• Werden Aktivitäten protokolliert? 

• Wie werden Fehler behandelt? 

• Gibt es öffentlich erreichbare Endpunkte, die seit Monaten nicht mehr überprüft wurden? 

Kann ein sicheres SAP-Business-One-System durch eine unsichere Integration gefährdet werden? 

Ja.  Die allgemeine Sicherheitslage wird durch die gesamte Systemlandschaft eines Unternehmens bestimmt – und nicht allein durch die Sicherheit der ERP-Anwendung.  Selbst eine optimal konfigurierte SAP-Business-One-Instanz kann Risiken ausgesetzt sein, wenn sie mit einer unzureichend abgesicherten Integration verbunden ist.  Mit anderen Worten:  Die Sicherheit der gesamten ERP-Landschaft ist nur so stark wie die Sicherheit ihrer angebundenen Systeme und Schnittstellen. Pasted markdown

Was passiert, wenn ein Mitarbeiter das Unternehmen verlässt? 

An diesem Punkt treffen die guten Absichten einer Sicherheitsrichtlinie auf die Realität eines arbeitsintensiven HR-Prozesses.  Ein sinnvoller ERP-Offboarding-Prozess sollte beispielsweise folgende Schritte umfassen:

1. SAP-Business-One-Benutzerkonto deaktivieren 

1. Remote-Zugriff widerrufen 

1. Zugriff über den Identity Provider entfernen 

1. VPN-Zugriff deaktivieren 

1. Administratorrechte entziehen 

1. Gemeinsam genutzte Zugangsdaten oder API-Credentials ändern, sofern der Mitarbeiter darauf Zugriff hatte 

1. Vom Mitarbeiter verwaltete Integrationen überprüfen 

1. Firmengeräte zurückfordern 

1. Falls erforderlich, kürzlich durchgeführte Aktivitäten überprüfen 

Das Auslassen eines einzelnen Schrittes führt normalerweise nicht unmittelbar zu einem Sicherheitsvorfall.  Es hinterlässt jedoch möglicherweise eine offene Zugangsmöglichkeit, die zu einem späteren Zeitpunkt zum Problem werden kann. Pasted markdown 

Wie häufig sollten die Zugriffsrechte in SAP Business One überprüft werden? 

Der wichtigste Grundsatz:  Benutzer sollten genau die Zugriffsrechte erhalten, die sie zur Erfüllung ihrer Aufgaben benötigen – und nicht einfach jene Berechtigungen behalten, die bei der ursprünglichen Einrichtung ihres Benutzerkontos am einfachsten zu vergeben waren.  Dieses Prinzip wird häufig als Least-Privilege-Prinzip bezeichnet. Eine Überprüfung der Berechtigungen ist insbesondere sinnvoll, wenn: 

• sich die Rolle eines Mitarbeiters ändert, 

• ein Mitarbeiter in eine andere Abteilung wechselt, 

• neue Integrationen produktiv geschaltet werden, 

• neue Add-ons implementiert werden, 

• das Unternehmen organisatorisch umstrukturiert wird, 

• Mitarbeiter das Unternehmen verlassen, 

• ein Sicherheitsvorfall auftritt. 

Zusätzlich zu diesen konkreten Auslösern sollten regelmäßige Überprüfungen anhand der individuellen Risiko- und Compliance-Anforderungen des Unternehmens erfolgen. Eine pauschale Überprüfungsfrequenz, die für jedes Unternehmen gleichermaßen geeignet ist, gibt es nicht. Pasted markdown 

Welche Aufgaben sollte ein SAP-Partner in einer Cloud-Umgebung übernehmen? 

Ein SAP-Partner bzw. Managed Service Provider kann je nach vereinbartem Leistungsumfang zahlreiche technische und operative Aufgaben übernehmen.  Dazu können beispielsweise gehören: 

• Einrichtung der Infrastruktur, 

• Installation von SAP Business One, 

• Datenbankadministration, 

• Updates und Patches, 

• Systemüberwachung, 

• Durchführung von Backups, 

• Unterstützung bei Wiederherstellungen, 

• Sicherheitskonfiguration, 

• Firewall-Konfiguration, 

• Unterstützung bei Integrationen, 

• Performance-Monitoring, 

• Fehleranalyse und Incident Troubleshooting. 

Wie diese Verantwortlichkeiten konkret verteilt sind, hängt jedoch immer vom jeweiligen Servicevertrag ab. Nicht jeder Managed-Service-Vertrag definiert die Verantwortlichkeiten auf dieselbe Weise. 

Was übernimmt ein SAP-Business-One-Cloud-Partner tatsächlich? 

In vielen Betriebsmodellen übernimmt der SAP-Partner den technischen Betrieb der Umgebung, beispielsweise:  Infrastruktur → Patching → Backup-Betrieb → Monitoring → technische Unterstützung  Der Kunde bleibt dagegen typischerweise verantwortlich für:  Benutzerzugriffe → Entscheidungen über Berechtigungen → Data Governance → interne Prozesskontrollen  Die konkrete Aufteilung sollte jedoch schriftlich festgelegt und nicht lediglich aus einem Verkaufsgespräch abgeleitet werden. Gerade bei sicherheitskritischen Verantwortlichkeiten ist es wichtig, eindeutig zu dokumentieren:  Wer macht was – und wer reagiert, wenn etwas nicht funktioniert? Pasted markdown 

Welche Sicherheitsfragen sollten Sie einem SAP-Business-One-Cloud-Anbieter stellen? 

Bevor Sie sich für einen Cloud-Anbieter oder Managed Service Provider entscheiden, sollten Verantwortlichkeiten, Backup-Prozesse und Wiederherstellungsziele konkret geklärt werden.  Folgende Fragen gehören auf die Checkliste: 

1. Wo wird unsere SAP-Business-One-Umgebung gehostet?

1. Wer verwaltet das Betriebssystem?

1. Wer installiert Sicherheitsupdates und Patches?

1. Wie häufig werden Backups erstellt?

1. Werden die Backups verschlüsselt?

1. Wo werden die Backups gespeichert?

1. Wie lange werden die Backups aufbewahrt?

1. Wann wurde zuletzt eine Wiederherstellung getestet?

1. Welches RPO (Recovery Point Objective) ist vorgesehen?

1. Welches RTO (Recovery Time Objective) ist vorgesehen?

1. Wer überwacht die Systemumgebung?

1. Wie werden Administratorzugänge kontrolliert?

1. Wie werden Integrationen und Schnittstellen abgesichert?

1. Was passiert im Falle eines Sicherheitsvorfalls?

1. Welche Sicherheitsverantwortlichkeiten verbleiben bei unserem Unternehmen?

Diese Fragen helfen dabei, aus einem allgemeinen Versprechen wie „Ihre SAP-Umgebung wird sicher in der Cloud betrieben“ konkrete, überprüfbare Verantwortlichkeiten und Serviceleistungen abzuleiten. Sicherheitscheckliste und Verantwortungsmatrix  SAP Business One Cloud Sicherheitscheckliste für KMU  Die folgende Checkliste fasst die wichtigsten Bereiche zusammen, die Unternehmen bei der Absicherung einer SAP-Business-One-Cloud-Umgebung berücksichtigen sollten. Pasted markdown  Identität 

• Individuelle Benutzerkonten 

• Starke Authentifizierung 

• SSO-/Identity-Provider-Strategie, sofern sinnvoll 

• Zeitnahes Offboarding ausscheidender Mitarbeiter 

Zugriff und Berechtigungen 

• Least-Privilege-Prinzip 

• Rollenbasierte Berechtigungen 

• Begrenzte Anzahl an Administratorkonten 

• Regelmäßige Überprüfung der Zugriffsrechte 

Infrastruktur 

• Unterstützte und aktuelle Software 

• Regelmäßige Sicherheitsupdates 

• Firewall- und Netzwerkkontrollen 

• Kontinuierliches Monitoring 

Daten 

• Definierte Verschlüsselungsstrategie 

• Kontrollierter Datenzugriff 

• Richtlinien für sensible Daten 

Backups 

• Definierter Backup-Zeitplan 

• Verschlüsselung der Backups 

• Festgelegte Aufbewahrungsrichtlinie 

• Regelmäßige Wiederherstellungstests 

• Dokumentierte RPO- und RTO-Werte 

Integrationen 

• Abgesicherte APIs 

• Geschützte Zugangsdaten 

• Protokollierung relevanter Aktivitäten 

• Regelmäßige Rotation von Zugangsdaten 

• Entfernung nicht mehr benötigter Verbindungen 

Endgeräte 

• Aktuelle und regelmäßig aktualisierte Geräte 

• Endpoint-Schutz 

• Kontrollierter Remote-Zugriff 

Verantwortungsmatrix für die Sicherheit von SAP Business One Cloud 

Die folgende Matrix bildet eine zentrale Referenz für die Aufteilung der Sicherheitsverantwortung. Statt einfacher Häkchen oder Kreuze verwendet sie eine differenzierte Einteilung: 

Hauptverantwortung / Geteilte Verantwortung / Kundenseitig gesteuert / Abhängig von der Vereinbarung 

Diese Unterscheidung ist wichtig, weil ein einfaches Ja/Nein-Modell die tatsächliche Verteilung der Verantwortlichkeiten in vielen realen SAP-Business-One-Cloud-Umgebungen nicht korrekt abbilden würde. Pasted markdown

Sicherheitsbereich	Cloud-Anbieter	SAP-Partner	Kunde
Rechenzentrum	Hauptverantwortung	–	–
Hardware	Hauptverantwortung	–	–
Netzwerk	Hauptverantwortung	Geteilt	–
Betriebssystem	Abhängig von der Vereinbarung	Hauptverantwortung	Governance
SAP Business One	–	Hauptverantwortung	Kundenseitig gesteuert
HANA-/SQL-Datenbank	Geteilt	Hauptverantwortung	Governance
Patching	Abhängig von der Vereinbarung	Hauptverantwortung	Governance
Firewall	Geteilt	Hauptverantwortung	–
Backup	Abhängig von der Vereinbarung	Hauptverantwortung	Kundenseitig gesteuert
Monitoring	Geteilt	Hauptverantwortung	–
Benutzerkonten	–	Geteilt	Hauptverantwortung
Berechtigungen	–	Geteilt	Hauptverantwortung
Endgeräte	–	–	Hauptverantwortung
Integrationen	–	Geteilt	Geteilt
Geschäftsdaten	–	Geteilt	Hauptverantwortung
Incident Response	Geteilt	Geteilt	Geteilt

Sicherheitsbereich	Cloud-Anbieter	SAP-Partner	Kunde
Rechenzentrum	Hauptverantwortung	–	–
Hardware	Hauptverantwortung	–	–
Netzwerk	Hauptverantwortung	Geteilt	–
Betriebssystem	Abhängig von der Vereinbarung	Hauptverantwortung	Governance
SAP Business One	–	Hauptverantwortung	Kundenseitig gesteuert
HANA-/SQL-Datenbank	Geteilt	Hauptverantwortung	Governance
Patching	Abhängig von der Vereinbarung	Hauptverantwortung	Governance
Firewall	Geteilt	Hauptverantwortung	–
Backup	Abhängig von der Vereinbarung	Hauptverantwortung	Kundenseitig gesteuert
Monitoring	Geteilt	Hauptverantwortung	–
Benutzerkonten	–	Geteilt	Hauptverantwortung
Berechtigungen	–	Geteilt	Hauptverantwortung
Endgeräte	–	–	Hauptverantwortung
Integrationen	–	Geteilt	Geteilt
Geschäftsdaten	–	Geteilt	Hauptverantwortung
Incident Response	Geteilt	Geteilt	Geteilt