Eine Anwendung im eigenen Haus betreiben: was im Alltag dazugehört

01

Der Morgen nach dem Go-Live

Die Abnahme ist unterschrieben. Die letzte Abstimmung mit dem Fachbereich liegt hinter allen Beteiligten. Und am nächsten Morgen ist die Anwendung immer noch da, mit echten Nutzern, echten Daten und einem Fehler, den vorher niemand auf dem Zettel hatte.

Ab hier beginnt der eigentliche Betrieb, ein Zustand ohne geplantes Ende. Die Reihe Vom Prototyp zur produktionsreifen Anwendung beschreibt den Weg bis zu diesem Punkt. Wie der Fachbereich eine App vorher freigibt, steht in Der Fachbereich hat eine App gebaut, welche Unterlagen die Übergabe braucht, in Vom Proof of Concept in den Regelbetrieb.

Bei einer KI-Anwendung kommt eine zusätzliche Schicht hinzu. Wer ein Sprachmodell auf eigener Hardware betreibt, übernimmt auch dessen Betrieb: Grafikspeicher, Modellversionen, Antwortzeiten unter Last. On-Premise vs. Cloud-LLM und Lokales LLM im Unternehmen ordnen diese Abwägung ein.

02

Was gehört eigentlich zum Betrieb?

Sieben Aufgaben tragen den Alltag einer Anwendung. Fehlt eine davon dauerhaft, zeigt sich das irgendwann, meist zur ungünstigsten Zeit.

• Überwachung: erkennt eine Störung, bevor ein Nutzer sie meldet.
• Sicherung und Wiederherstellung: bringt Daten nach einem Ausfall zurück, die Kopie und den erprobten Weg dahin.
• Aktualisierungspfad: bringt Sicherheitsupdates ein, mit einem Rückweg, falls etwas bricht.
• Zugriffskonzept: legt fest, wer sich anmelden, wer administrieren und wer im Notfall eingreifen darf.
• Protokollierung: erklärt einen Fehler, ohne einen Menschen zu beschreiben.
• Getrennte Umgebungen: halten eine Änderung fern von echten Nutzern, bis sie geprüft ist.
• Betriebsdokumentation: macht den Betrieb unabhängig von einzelnen Personen.

03

Was sollte überwacht werden, bevor sich jemand meldet?

Überwacht wird, was Nutzer spüren, bevor sie es melden. Das Buch „Site Reliability Engineering“ (O’Reilly, 2016) nennt dafür vier goldene Signale: Latenz, Verkehr, Fehler und Sättigung. Dazu kommen Ursachen, die eine Anwendung abrupt stoppen, etwa ablaufende Zertifikate, volle Datenträger und fehlgeschlagene Sicherungsläufe.

• Latenz: wie lange eine Anfrage dauert, getrennt nach erfolgreichen und fehlgeschlagenen Anfragen.
• Verkehr: wie viel Nachfrage auf dem System liegt, etwa Anfragen pro Minute oder gleichzeitige Sitzungen.
• Fehler: der Anteil fehlgeschlagener Anfragen, auch solcher, die formal erfolgreich sind, aber falschen Inhalt liefern.
• Sättigung: wie ausgelastet das System ist, etwa Arbeitsspeicher, Datenträger, Warteschlangen oder bei lokalen Sprachmodellen der Grafikspeicher.

In unseren Projekten sehen wir oft Dashboards mit zwanzig Kennzahlen und keiner einzigen Alarmregel, die tatsächlich jemanden erreicht. Ein einfacher Test hilft dabei: Gehen Sie die Alarme des letzten Monats durch und fragen Sie bei jedem, was daraufhin getan wurde. Bleibt die Antwort leer, war der Alarm überflüssig.

04

Wann ist eine Sicherung im Ernstfall verlässlich?

Eine Sicherung ist verlässlich, wenn die Wiederherstellung tatsächlich erprobt wurde, die Sicherung getrennt vom gesicherten System liegt und feststeht, wie alt die Daten nach einer Rücksicherung höchstens sein dürfen. Das IT-Grundschutz-Kompendium des BSI (Edition 2023) verlangt im Baustein CON.3 Tests, ob gesicherte Daten in angemessener Zeit zurückgespielt werden können.

Der Baustein CON.3 beschreibt die Gefährdung nüchtern. Dass Daten gesichert werden, heißt noch nicht, dass sie sich auch wiederherstellen lassen. Typische Gründe sind unvollständige Sicherungen, fehlende Schlüssel und undokumentierte Schritte. CON.3 verlangt zudem, Speichermedien der Datensicherung räumlich getrennt von den gesicherten Systemen aufzubewahren.

Für die Zielwerte helfen zwei Begriffe aus dem BSI-Standard 200-4 (BSI, 2023): die geforderte Wiederanlaufzeit (RTO) und der maximal zulässige Datenverlust (RPO). Aus dem RPO folgt, wie oft gesichert wird. Aus dem RTO folgt die Frage, ob eine Rücksicherung aus einem entfernten Speicher überhaupt schnell genug ist.

05

Ein Rückweg gehört zum Plan dazu

Ein tragfähiger Aktualisierungspfad legt fest, wie Sicherheitsaktualisierungen für Betriebssystem, Laufzeit, Bibliotheken und Modelle bekannt werden, wo sie zuerst eingespielt werden und wie man zurückkehrt, wenn etwas bricht. Er beginnt mit einer Liste aller Abhängigkeiten, denn wer nicht weiß, was installiert ist, erfährt auch nicht, wenn darin eine Lücke bekannt wird.

Der Baustein OPS.1.1.3 Patch- und Änderungsmanagement im IT-Grundschutz-Kompendium (BSI, Edition 2023) gibt dafür einen Rahmen. Praktisch zählen drei Dinge: festgeschriebene Versionen aller Abhängigkeiten, damit ein Build reproduzierbar ist, eine Testumgebung, die der Produktion ausreichend gleicht, und ein Rückweg, etwa das vorherige Container-Abbild.

In unseren Projekten sehen wir häufig, dass aus schnell gebauten Prototypen viele Abhängigkeiten ohne festgelegte Version mitwandern. Das rächt sich selten sofort. Es rächt sich beim ersten Sicherheitshinweis, wenn niemand mehr sagen kann, ob die eigene Anwendung überhaupt betroffen ist. Ob sich aus Software, die Sie an andere ausliefern, weitergehende Pflichten ergeben können, ordnet der Beitrag zur Haftung ein.

06

Wer darf zugreifen, und was darf ins Protokoll?

Ein Zugriffskonzept trennt die Nutzung einer Anwendung von ihrer Administration, bindet Konten an die zentrale Nutzerverwaltung und regelt einen Notfallzugang. Protokolle sollen Fehler und sicherheitsrelevante Ereignisse erklären, ohne Personen zu beschreiben: Passwörter, Sitzungskennungen, Zugriffstokens und sensible personenbezogene Daten gehören laut dem Logging Cheat Sheet der OWASP in der Regel nicht hinein.

Zugriff

Tragfähig ist eine einfache Trennung. Nutzer melden sich über die zentrale Anmeldung an, Administratoren über einen getrennten Weg mit zweitem Faktor, und ein dokumentierter Notfallzugang existiert für den Fall, dass die zentrale Anmeldung selbst ausfällt. Beim Austritt einer Person erlischt der Zugang an einer einzigen Stelle. Der Baustein ORP.4 im IT-Grundschutz-Kompendium (BSI, Edition 2023) beschreibt Identitäts- und Berechtigungsmanagement im Detail.

Protokollierung ohne personenbezogene Daten

Protokolle sind für die Fehlersuche wichtig und werden dabei leicht zu einem zweiten, schlechter geschützten Datenbestand. Das Logging Cheat Sheet der OWASP nennt unter anderem Sitzungskennungen, Zugriffstokens, Passwörter, Verbindungszeichenfolgen zu Datenbanken, Schlüssel und sensible personenbezogene Daten als Inhalte, die nicht direkt protokolliert werden sollten, und empfiehlt Entfernen, Maskieren oder Pseudonymisieren. Eine interne Kennung statt eines Namens reicht meist, um einen Vorgang nachzuvollziehen.

{"level":"error","msg":"upload failed","user":"[email protected]","token":"eyJhbGciOi...","file":"Gehaltsabrechnung.pdf"}
{"level":"error","msg":"upload failed","user_id":"u-4821","request_id":"r-9f3c","file_type":"pdf","cause":"max_size_exceeded"}

Bei KI-Anwendungen enthalten Eingaben und Antworten eines Sprachmodells alles, was Nutzer eingegeben haben. Warum solche Protokolle dieselben Rechte und Löschfristen wie die Quelldaten brauchen, beschreibt die Seite KI-Sicherheit. Ergänzend beschreibt der Baustein OPS.1.1.5 Protokollierung (BSI, Edition 2023) die Anforderungen an die Protokollierung sicherheitsrelevanter Ereignisse.

07

Warum Testumgebung und Handbuch zusammengehören

Für die meisten Anwendungen genügen Entwicklung, Test und Produktion. Wichtiger als die Zahl der Umgebungen sind drei Regeln. Konfiguration und Geheimnisse sind je Umgebung getrennt, sodass eine Testinstanz nie in die Produktionsdatenbank schreibt. Echte personenbezogene Daten gelangen nicht ungeschützt in die Testumgebung. Und Änderungen erreichen die Produktion nur über denselben Weg, auf dem sie getestet wurden.

Die Betriebsdokumentation im Dauerbetrieb bleibt knapp und handlungsorientiert: wie die Anwendung startet und stoppt, wo Protokolle und Konfiguration liegen, welche Alarme es gibt und was bei jedem zu tun ist, wie eine Wiederherstellung abläuft. Sie liegt neben dem Code und wird mit jeder Änderung am Betrieb fortgeschrieben. Eine Dokumentation, die niemand außerhalb des Ursprungsteams verstehen kann, ist im Ernstfall wertlos.

08

Eigenbetrieb, verwalteter Betrieb oder Plattform: welches Modell passt?

Die drei Modelle unterscheiden sich darin, wer welche Aufgabe übernimmt. Im Eigenbetrieb erledigt Ihre Organisation alle sieben Aufgaben selbst, auf eigener oder gemieteter Hardware. Im verwalteten Betrieb läuft die Anwendung in Ihrer Umgebung oder bei einem Hoster Ihrer Wahl, und ein Dienstleister übernimmt vertraglich festgelegte Betriebsaufgaben. Im Plattformbetrieb stellt ein Dienst Server, Infrastruktur und Skalierung bereit, während Anwendung, Daten und Zugriffe in Ihrer Verantwortung bleiben.

In unseren Projekten hören wir oft denselben Satz kurz vor der Entscheidung: eigentlich wollte man das selbst machen. Meist fehlt dann nicht der Wille, sondern die Vertretung für den Urlaub des einen Kollegen, der alles weiß.

iiterate Technologies GmbH aus Adenau entwickelt KI-Anwendungen und Individualsoftware von der Architektur bis zum Betrieb, auf Kundeninfrastruktur oder in EU-Hosting (Leistungen).