On-Premise (Betrieb im eigenen Haus)
Kurz gesagt
On-Premise heißt bei ERP: Hardware, Betriebssystem und Datenbank stehen in Räumen des Betriebs; er installiert, aktualisiert, überwacht und sichert die Warenwirtschaft vor Ort oder lässt das in seinem Auftrag tun. Die Aufgaben reichen von Patch- und Änderungsmanagement über Schadprogrammschutz bis zu Datensicherung und Restore-Test. NIST SP 800-145 definiert Cloud Computing über fünf Merkmale; den Begriff On-Premise verwendet sie nicht.
Das Wichtigste
- On-Premise: Der Betrieb stellt Rechner, Betriebssystem und Datenbank selbst bereit und betreibt sie.
- Betriebsaufgaben vor Ort: patchen, schützen, protokollieren, sichern und das Zurückspielen testen.
- Das IT-Grundschutz-Kompendium des BSI (Edition 2023, seit 1. Februar 2023) führt diese Aufgaben als Bausteinanforderungen.
- NIST SP 800-145 (September 2011) beschreibt Cloud Computing über fünf Merkmale und nennt kein On-Premise.
- Die BSI-Anforderungen und die NIST-Publikation binden nur, wenn Recht oder Vertrag darauf verweisen.
On-Premise (wörtlich „im eigenen Haus”) ist ein Betriebsmodell für Software, bei dem die nutzende Organisation die Rechner, auf denen die Anwendung läuft, selbst bereitstellt, betreibt und wartet. Beim ERP umfasst das mehr als die Anwendungssoftware: Datenbankserver, Anwendungsserver, Ablage für Belege und Berichte, die Verbindung zu Maschinen und Terminals sowie die Zugänge der Mitarbeitenden. Alles davon steht in Räumen, über die der Betrieb selbst bestimmt.
Was On-Premise von der Cloud abgrenzt
Die Abgrenzung stützt sich nicht auf eine Norm, sondern auf die verbreitete Definition des Cloud Computing: NIST SP 800-145, die Publikation des US-amerikanischen National Institute of Standards and Technology vom September 2011, beschreibt Cloud Computing über fünf wesentliche Merkmale: Bereitstellung auf Abruf ohne menschliches Zutun des Anbieters, Zugriff über das Netz mit standardisierten Mechanismen, gebündelte Ressourcen für mehrere Nutzende, elastische Anpassung an die Nachfrage und gemessene Nutzung. Dazu kommen drei Dienstmodelle (SaaS, PaaS, IaaS) und vier Bereitstellungsmodelle (Private, Community, Public, Hybrid).
Den Begriff On-Premise verwendet die Publikation nicht. Sie hilft trotzdem bei der Abgrenzung, weil sie den Standort ausdrücklich offen lässt: Eine Private Cloud kann nach NIST SP 800-145 von der Organisation selbst oder von Dritten betrieben werden und „on or off premises” liegen. Ein ERP im eigenen Serverraum kann deshalb zugleich eine Private Cloud sein, wenn es die fünf Merkmale erfüllt. Der Begriff meint den Standort beim nutzenden Betrieb: Ein Server, den ein Dienstleister in seinem Rechenzentrum für Sie betreibt, ist damit gehostet und nicht On-Premise, auch wenn Sie ihn allein nutzen.
Bei ERP steht On-Premise für das Gegenstück zum Bezug aus der Umgebung eines Anbieters. Wer sein ERP als Dienst bezieht, trägt diese Betriebsaufgaben nicht in dieser Form; die Aufteilung der Verantwortungsschichten steht im Glossar zu SaaS.
Was der Betrieb selbst trägt: Checkliste
Die folgende Tabelle ordnet jedem Betriebsschritt die Anforderung aus dem IT-Grundschutz-Kompendium des BSI zu, aus der er stammt; herangezogen ist die Edition 2023 (verfügbar seit 1. Februar 2023) in der Fassung mit den Errata vom 26. März 2026. Das Kompendium ist eine Veröffentlichung des BSI und keine Rechtsnorm: Bindend werden seine Anforderungen, soweit eine Regelung oder ein Vertrag sie in Bezug nimmt, etwa ein Auftraggeber, ein Versicherer oder ein Qualitätssystem. Die Tabelle gilt für ein ERP auf eigenen Servern; andere Wege, dieselbe Aufgabe zu erfüllen, bleiben möglich.
| Aufgabe | Was beim eigenen ERP-Server dazugehört | Anforderung im BSI-Kompendium (Edition 2023) |
|---|---|---|
| Standort und Zutritt | Server stehen in einem Rechenzentrum, Serverraum oder abschließbaren Serverschrank; Zutritt haben nur berechtigte Personen. im Rechenzentrum wird jeder Zutritt einzeln erfasst; handelt es sich dagegen nur um einen Serverraum, ist zu prüfen, ob eine Überwachung aller Zutrittsmöglichkeiten sinnvoll ist | SYS.1.1.A1; INF.2.A6 |
| Stromversorgung | Betriebsrelevante Komponenten eines Rechenzentrums hängen an einer unterbrechungsfreien Stromversorgung; bei einem reinen Serverraum ist der Bedarf nach den Verfügbarkeitsanforderungen zu prüfen | SYS.1.1.A15; INF.2.A3 |
| Planung und Installation | Plattform, Dimensionierung, Protokollierung und Aktualisierungspfad vorab festlegen und dokumentieren; das Betriebssystem ist konfiguriert, bevor der Server produktiv geht | SYS.1.1.A12; SYS.1.1.A16 |
| Angriffsfläche | Nicht benötigte Rollen, Dienste, Funktionen und Schnittstellen abschalten und die Entscheidung dokumentieren | SYS.1.1.A5; SYS.1.1.A6 |
| Administrationszugänge | Eigene Administrationsrollen nach dem Minimalprinzip, getrennt von anderen Tätigkeiten und nachvollziehbar zugeordnet | OPS.1.1.2.A21; OPS.1.1.2.A22 |
| Patch- und Änderungslauf | Konzept und Zuständige festlegen und den Umgang mit Autoupdate regeln; Patches bewerten, einspielen und den Erfolg kontrollieren; eine Ablehnung mit Grund dokumentieren; eine Rückfall-Lösung bereithalten | OPS.1.1.3.A1; OPS.1.1.3.A2; OPS.1.1.3.A3; OPS.1.1.3.A15 |
| Schutz vor Schadprogrammen | Konzept erstellen, Virenschutzprogramm konfigurieren, betreiben und nach Herstellerempfehlung aktualisieren; auf dem Server prüfen, ob Virenschutz eingesetzt werden soll und kann | OPS.1.1.4.A1; OPS.1.1.4.A5; OPS.1.1.4.A6; SYS.1.1.A9 |
| Protokollierung | Sicherheitsrelevante Ereignisse wie Anmeldungen, fehlgeschlagene Berechtigungsprüfungen und Rechteänderungen erfassen; Systemzeiten synchron halten; Protokolle an einer zentralen Stelle sammeln | SYS.1.1.A10; OPS.1.1.5.A3; OPS.1.1.5.A4; OPS.1.1.5.A6 |
| Datensicherung | Je System einen Sicherungsplan mit Wiederherstellungsreihenfolge und Aufbewahrung erstellen, regelmäßig sichern, Speichermedien räumlich getrennt aufbewahren und vor Überschreiben schützen | CON.3.A1; CON.3.A4; CON.3.A5; CON.3.A12; CON.3.A14 |
| Restore-Test | Regelmäßig testen, ob sich die gesicherten Daten einwandfrei und in angemessener Zeit zurückspielen lassen, und die gemessene Dauer gegen den eigenen Zielwert stellen | CON.3.A15 |
| Notfall und Übungen | Den Server in die Notfallplanung aufnehmen, Wiederanlaufpläne und hinterlegte Schlüssel einschließen und Sofortmaßnahmen sowie Notfallpläne üben | SYS.1.1.A22; DER.4.A10 |
| Betriebsdokumentation | Betriebliche Tätigkeiten je Server nachvollziehbar festhalten (wer, wann, was), Konfigurationsänderungen einschließen und ein Betriebshandbuch pflegen | SYS.1.1.A21; SYS.1.1.A35 |
| Überwachung und Prüfung | Serverzustand und Grenzwertüberschreitungen laufend überwachen und in festen Zyklen Sicherheitsprüfungen durchführen | SYS.1.1.A23; SYS.1.1.A24 |
| Verfügbarkeit | Bei hohen Verfügbarkeitsanforderungen an den Server Redundanzen und Wartungsverträge mit den Lieferanten vorsehen (Anforderung der Stufe „erhöhter Schutzbedarf”) | SYS.1.1.A28 |
| Außerbetriebnahme | Vor dem Ausmustern die Daten sichern, Dienste auf einen anderen Server migrieren, Datenträger sicher löschen und eine Checkliste abarbeiten | SYS.1.1.A25 |
Der Vergleich der gemessenen Wiederherstellungsdauer mit dem eigenen Zielwert in der Zeile Restore-Test ist eine redaktionelle Ergänzung; der Baustein verlangt den Test selbst. Die Zeile Standort und Zutritt unterscheidet zwei Einrichtungen: Die individuelle Erfassung jedes Zutritts verlangt INF.2.A6 für das Rechenzentrum; für einen Serverraum ist nach derselben Anforderung zu prüfen, ob eine Überwachung aller Zutrittsmöglichkeiten sinnvoll ist.
Sie müssen diese Aufgaben nicht selbst ausführen. Patch-Einspielung, Wartung, Überwachung und Datensicherung lassen sich an einen IT-Dienstleister übertragen; dann steht im Vertrag, wer welche Aufgabe übernimmt und wie auf die Systeme zugegriffen wird. Bleiben muss die Zuordnung, weil die Systeme Ihre sind. Welche Nachweise bei einem beauftragten Rechenzentrum aussagekräftig sind, behandelt der Artikel Rechenzentrum und Zertifikate prüfen.
Für die beiden größten Blöcke dieser Liste gibt es eigene Anleitungen: den Ablauf eines Wiederherstellungstests mit Protokoll im Artikel Restore-Test fürs ERP und die Einrichtung von Sicherung und Zielwerten im Artikel Backup-Konzept fürs ERP. Die Reihenfolge, in der ein Betrieb ohne eigene IT-Abteilung die Sicherheitsmaßnahmen angeht, steht in IT-Sicherheit rund ums ERP.
Nicht zu verwechseln mit
- Private Cloud: ein Bereitstellungsmodell des Cloud Computing, das nach NIST SP 800-145 auch die Organisation selbst betreiben kann und das on or off premises liegen darf. Ein On-Premise-Betrieb kann deshalb zugleich eine Private Cloud sein.
- Hosting oder Colocation: Der Server steht im Rechenzentrum eines Dienstleisters. Der Standort allein sagt nichts über die Verantwortung; die Schichten ergeben sich aus dem Vertrag.
- Managed Service: Der Betrieb nimmt Ihnen die Ausführung ab, nicht die Zurechnung. Aufgaben, Zuständige und Zugriffe gehören schriftlich festgehalten.
- SaaS: Anwendung und Infrastruktur liegen beim Anbieter; die Aufteilung der Verantwortungsschichten ist im Glossar SaaS aufgeführt.
Wer die beiden Betriebsformen über fünf Jahre rechnet, findet die Beispielrechnung im Artikel Cloud-ERP oder eigener Server. Die datenschutzrechtliche Seite der Datenhaltung behandelt der Artikel Auftragsverarbeitung.