Eine digitale Plattform gilt nicht als belastbar, nur weil sie im Normalbetrieb erreichbar ist. Entscheidend ist, ob Störungen früh erkannt, Sicherheitslücken kontrolliert behandelt und Daten sowie Funktionen nach einem Ausfall zuverlässig wiederhergestellt werden können.

NIS-2 macht diese Fragen für betroffene Unternehmen verbindlicher. § 30 BSIG nennt unter anderem Betriebskontinuität, Backup-Management, Wiederherstellung nach einem Notfall, Krisenmanagement sowie die sichere Wartung von IT-Systemen.

polargold entwickelt und betreut Pimcore-Plattformen, Produktdatenlösungen sowie Kunden- und Self-Service-Portale. Dabei erleben wir regelmäßig, dass nicht die einzelne Funktion, sondern das Zusammenspiel aus Anwendung, Schnittstellen, Hosting und klaren Zuständigkeiten über einen stabilen Betrieb entscheidet. Genau dort setzen wir mit Architektur, Entwicklung, Wartung und Support an.

Ein Backup ist noch kein Wiederherstellungsprozess

Viele Betriebsmodelle beschreiben, dass Daten regelmäßig gesichert werden. Das beantwortet jedoch nicht, ob diese Sicherungen vollständig, geschützt und im benötigten Zeitraum nutzbar sind.

Für ein belastbares Konzept müssen mindestens folgende Fragen geklärt werden:

  • Welche Daten, Dateien, Dokumente, Konfigurationen und Schlüssel werden gesichert?
  • Wie häufig entstehen Sicherungen und wie lange werden sie aufbewahrt?
  • Sind Sicherungen ausreichend vom produktiven System getrennt?
  • Wer darf auf Backups zugreifen und werden diese Zugriffe protokolliert?
  • Wie werden Integrität und Verwendbarkeit der Sicherungen überprüft?
  • Welche Datenverluste und Wiederanlaufzeiten sind fachlich vertretbar?

Die Antworten hängen von der Plattform ab. Ein redaktionelles CMS, ein internationales Händlerportal und eine Produktdatenplattform mit regulatorischen Dokumenten haben unterschiedliche Abhängigkeiten und Wiederanlaufziele.

Bei einer von polargold entwickelten Plattform beziehen wir daher nicht nur den sichtbaren Webauftritt ein. Gemeinsam mit Kunde und Hoster ordnen wir Datenbank, Assets, Konfiguration, Suchdienst, Dokumentengenerierung, technische Schlüssel und angebundene Systeme einem konkreten Sicherungs- und Wiederanlaufkonzept zu.

Wiederherstellung muss getestet werden

Eine erfolgreiche Sicherung bestätigt nur, dass Daten geschrieben wurden. Erst ein Wiederherstellungstest zeigt, ob das System in einer nutzbaren Form zurückgebracht werden kann.

Dabei sollte nicht ausschließlich die Datenbank betrachtet werden. Kundenportale und Pimcore-Plattformen können zusätzlich Assets, erzeugte Dokumente, Suchindizes, Warteschlangen, Integrationszustände und externe Dienste benötigen. Auch die Reihenfolge des Wiederanlaufs ist relevant.

Ein Test sollte dokumentieren:

  • welches Szenario geprüft wurde;
  • welche Sicherung verwendet wurde;
  • wie lange Wiederherstellung und Prüfung dauerten;
  • welche Daten oder Funktionen fehlten;
  • welche Verbesserungen anschließend umgesetzt werden.

So wird aus einer technischen Sicherung ein überprüfbarer Prozess der Betriebskontinuität.

Unsere Aufgabe kann dabei von der technischen Vorbereitung über die Wiederherstellung der Anwendung bis zur fachlichen Prüfung zentraler Portal- und Datenprozesse reichen. Welche Schritte polargold, Hostingpartner und Kunden-IT übernehmen, halten wir vor dem Test eindeutig fest.

Monitoring: Störungen erkennen, bevor Kunden sie melden

Eine reine Prüfung, ob die Startseite erreichbar ist, reicht bei integrierten Plattformen nicht aus. Das Portal kann sichtbar sein, während ein ERP-Import steht, Dokumente nicht erzeugt werden oder die Anmeldung über den Identitätsanbieter fehlschlägt.

Monitoring sollte deshalb die für den Geschäftsprozess entscheidenden Komponenten und Datenflüsse abbilden. Dazu können Verfügbarkeit, Antwortzeiten, fehlgeschlagene Anmeldungen, Schnittstellenfehler, Warteschlangen, Speicherverbrauch und der Status geplanter Aufgaben gehören.

Für polargold bedeutet das: Wir definieren die Überwachung aus Sicht der Anwendung und ihrer Nutzerprozesse. Bei einem Dokumentenportal kann beispielsweise entscheidend sein, ob neue Daten verarbeitet, PDFs erzeugt und berechtigten Kunden bereitgestellt werden – nicht nur, ob der Server antwortet.

Jede Alarmierung benötigt eine Zuständigkeit. Ohne definierte Empfänger, Prioritäten und Eskalationswege produziert Monitoring lediglich weitere Meldungen.

Sicherheitsupdates nach Risiko behandeln

Plattformen bestehen aus dem Kernsystem, projektspezifischen Erweiterungen, Bibliotheken, Betriebssystemen und angebundenen Diensten. Sicherheitsupdates können daher an mehreren Stellen erforderlich werden.

Ein geregelter Prozess umfasst:

  1. Informationen über neue Schwachstellen und Updates erfassen;
  2. Betroffenheit und Risiko für die konkrete Plattform bewerten;
  3. Änderung und mögliche Abhängigkeiten planen;
  4. Update in einer geeigneten Umgebung testen;
  5. Freigabe, Einspielung und Ergebnis dokumentieren;
  6. bei dringenden Fällen einen verkürzten Notfallprozess nutzen.

Nicht jedes Update hat dieselbe Dringlichkeit. Umgekehrt darf ein kritisches Sicherheitsproblem nicht bis zum nächsten allgemeinen Funktionsrelease liegen bleiben. In der laufenden Betreuung bewertet polargold deshalb die Auswirkung auf Anwendung und projektspezifische Erweiterungen, bereitet Tests und Deployment vor und stimmt mit Kunde und Hoster den geeigneten Zeitpunkt ab. Die Melde- und Entscheidungswege müssen dafür vorab feststehen.

Vorfallmanagement braucht klare Übergaben

Bei einem Sicherheitsvorfall können mehrere Organisationen beteiligt sein. Der Hoster erkennt ungewöhnliche Infrastrukturereignisse, polargold analysiert die Anwendung und der Kunde bewertet betroffene Geschäftsprozesse und Meldepflichten.

Ein sinnvoller Ablauf legt deshalb vorab fest:

  • welcher Kontakt rund um einen Vorfall erreichbar ist;
  • welche Informationen initial bereitgestellt werden;
  • wie technische Spuren gesichert werden;
  • wer über Abschaltung, Einschränkung oder Wiederanlauf entscheidet;
  • wie Zwischenstände und Abschluss dokumentiert werden;
  • wie Erkenntnisse anschließend in Architektur und Betrieb zurückfließen.

Die gesetzliche Meldung gegenüber Behörden bleibt eine Aufgabe der betroffenen Einrichtung. Dienstleister müssen jedoch so eingebunden sein, dass notwendige technische Informationen rechtzeitig verfügbar werden.

Was gehört in Leistungsbeschreibung und SLA?

Allgemeine Begriffe wie „Wartung“, „Backup“ oder „Monitoring“ lassen zu viel Interpretationsspielraum. Eine belastbare Vereinbarung beschreibt Umfang, Zuständigkeiten und Grenzen.

Dazu gehören je nach Schutzbedarf:

  • überwachte Systeme, Prozesse und Integrationen;
  • Servicezeiten, Prioritäten, Reaktions- und Eskalationszeiten;
  • Wartungsfenster und Updateverfahren;
  • Umfang, Häufigkeit und Aufbewahrung von Backups;
  • Rhythmus und Dokumentation von Wiederherstellungstests;
  • Kontakt- und Informationspflichten bei Schwachstellen und Vorfällen;
  • Abhängigkeiten und Leistungen weiterer Anbieter.

Plattformbetrieb mit klarer Verantwortung

polargold begleitet Pimcore-, Produktdaten- und Portalprojekte von der Architektur über Entwicklung und Integration bis zu Wartung und Weiterentwicklung. Wir definieren gemeinsam mit Ihnen und dem Hostingpartner, wer im laufenden Betrieb welche Verantwortung übernimmt.

  • Wartung und Sicherheitsupdates mit geregelter Bewertung und Freigabe;
  • Monitoring geschäftskritischer Funktionen und Integrationen;
  • abgestimmte Reaktions- und Eskalationswege;
  • Backup- und Wiederherstellungskonzepte einschließlich Testplanung;
  • kontinuierliche technische Weiterentwicklung der Plattform.

Damit kaufen Sie nicht nur Hosting oder einzelne Supportstunden, sondern ein nachvollziehbares Betriebsmodell für Ihre digitale Plattform. Eine rechtliche NIS-2-Konformität entsteht daraus nicht automatisch. Die technischen Betriebsprozesse lassen sich aber belastbar in Ihr übergeordnetes Risikomanagement einbinden.

Kostenlose Erstberatung zu Plattform und Betrieb anfragen

Quellen: § 30 BSIG, § 38 BSIG, BSI-Informationen zu NIS-2. Der Beitrag ersetzt keine Rechtsberatung.