So nehmen Sie eine selbstgehostete Anwendung außer Betrieb und erhalten dabei Daten und beseitigen Zugriffswege

Die Stilllegung einer Anwendung ist ein Data-Governance-Projekt, keine Serveraufgabe

Um eine selbstgehostete Anwendung sicher außer Betrieb zu nehmen, behandeln Sie die Arbeit als kontrollierte Stilllegung von Aufzeichnungen, Workflows, Identitäten und Infrastruktur. Das Stoppen eines Containers oder das Löschen eines virtuellen Servers kann den sichtbaren Dienst beenden, beantwortet aber nicht die wichtigen Fragen: Welche Aufzeichnungen müssen weiterhin verfügbar bleiben, wer kann noch darauf zugreifen, welche anderen Systeme hängen noch von der Anwendung ab und wann sollten aufbewahrte Kopien gelöscht werden?

Ein solider Stilllegungsplan trennt drei Ergebnisse, die häufig verwechselt werden. Ein Export ist eine nutzbare Darstellung von Aufzeichnungen für Personen oder ein Ersatzsystem. Ein Wiederherstellungs-Backup ist eine Kopie, die nach einem Ausfall zur Wiederherstellung der Anwendung dient. Eine Aufbewahrungsentscheidung legt fest, welche Informationen zu welchem Zweck, unter welchen Kontrollen und wie lange aufbewahrt werden sollen. Ein Artefakt kann manchmal mehr als einem Zweck dienen, dies sollte jedoch nicht vorausgesetzt werden.

Benennen Sie einen verantwortlichen Anwendungseigentümer und beziehen Sie die für Betrieb, Aufzeichnungen, Sicherheit, Finanzen und Geschäftsprozesse verantwortlichen Personen ein. Wenn die Anwendung personenbezogene, finanzielle, vertragliche oder regulierte Informationen enthält, holen Sie vor der Vernichtung die für Ihre Organisation angemessene rechtliche, datenschutzrechtliche oder aufzeichnungsbezogene Beratung ein.

• Legen Sie ein schriftliches Stilllegungsziel und einen Zieltermin fest.
• Benennen Sie Verantwortliche für Datenentscheidungen, technische Durchführung und endgültige Freigabe.
• Dokumentieren Sie den Grund für die Stilllegung, den Ersatz oder die Konsolidierung.
• Definieren Sie Erfolg sowohl als Verfügbarkeit der Aufzeichnungen als auch als Entfernung nicht benötigter Zugriffe – nicht lediglich als Offline-Server.

Wählen Sie den Stilllegungszustand, bevor Sie die Abschaltung planen

Nicht jede Anwendung sollte direkt von der Produktion zur Löschung übergehen. Wählen Sie zunächst den vorgesehenen Endzustand, denn er bestimmt, wie Sie Daten migrieren, mit Nutzern kommunizieren und Zugriffe entfernen.

Eine Migration zu einem Ersatzsystem ist angebracht, wenn ein anderes System die aktive Arbeit übernimmt. Ein reiner Archivmodus ist angebracht, wenn Aufzeichnungen möglicherweise benötigt werden, aber keine neue Arbeit stattfinden soll. Eine vollständige Abschaltung ist nur dann angebracht, wenn Aufzeichnungen gemäß der genehmigten Aufbewahrungsentscheidung behandelt und Abhängigkeiten entfernt wurden. Diese Zustände können schrittweise umgesetzt werden: Produktion, schreibgeschütztes Archiv, dann vollständige Stilllegung.

Nutzen Sie den schreibgeschützten Modus nicht als vage Verschiebung. Definieren Sie, wer darauf zugreifen darf, welche Aufzeichnungen eingesehen werden dürfen, wie der Zugriff genehmigt wird, ob Integrationen deaktiviert sind, wie lange das Archiv bestehen wird und welches Ereignis seine endgültige Entsorgung autorisiert.

• Ersatz: Migrieren Sie aktive Aufzeichnungen, bestätigen Sie die Verantwortlichkeit im neuen System und setzen Sie einen klaren Umstellungstermin.
• Nur Archiv: Verhindern Sie Änderungen, minimieren Sie Nutzerzugriffe und behalten Sie nur die Infrastruktur bei, die für den genehmigten Abruf erforderlich ist.
• Vollständige Abschaltung: Entfernen Sie öffentliche Routen, stoppen Sie Dienste, widerrufen Sie Anmeldedaten und entsorgen Sie Infrastruktur erst nach der Prüfung.
• Setzen Sie die vollständige Stilllegung aus, wenn rechtliche Sperren, Prüfungspflichten, ungelöste Migrationslücken oder mögliche Rechtsansprüche eine fortgesetzte Aufbewahrung erfordern.

Erstellen Sie ein Inventar, das der Anwendung über ihren Hauptcontainer hinaus folgt

Beginnen Sie mit einem Inventar, anhand dessen jemand die Anwendung verstehen könnte, nachdem der ursprüngliche Administrator das Unternehmen verlassen hat. Nehmen Sie Geschäftszweck, Eigentümer, Nutzer, Datenkategorien, Hosting-Standort, Domains, Ersatzsystem und Stilllegungsentscheidung auf.

Erfassen Sie bei Docker-basierten Bereitstellungen persistenten Speicher getrennt von Containern. Docker Volumes (https://docs.docker.com/engine/storage/volumes/) sind persistente Datenspeicher und können nach dem Löschen eines Containers bestehen bleiben. Das Löschen eines gestoppten Service-Containers ist kein Datenexport: Daten außerhalb eines Volumes können beim Entfernen von Containern verloren gehen. Ermitteln Sie benannte und anonyme Volumes, da anonymer Speicher bei der Containerbereinigung entfernt werden kann.

Bewahren Sie die Bereitstellungsdefinition auf, bevor Sie sie ändern. Compose-Dateien können Dienste, Netzwerke, Volumes und zugehörige Konfiguration definieren. Ermitteln Sie außerdem produktionsspezifische Compose-Konfigurationen, die Docker für Einstellungen wie Umgebungsvariablen, Neustartrichtlinien und zusätzliche Dienste wie Logging empfiehlt. Erfassen Sie die Konfiguration sicher und kopieren Sie keine Geheimnisse in allgemein zugängliche Dokumente. Die Docker-Compose-Produktionshinweise (https://docs.docker.com/compose/how-tos/production/) erläutern diese Trennung.

• Datenbanken, benannte Volumes, anonyme Volumes, per Bind Mount eingebundene Verzeichnisse und hochgeladene Dateien.
• Compose-Dateien, Umgebungsdateien, Bereitstellungsnotizen, Image-Referenzen, Netzwerke und Reverse-Proxy-Konfiguration.
• Domains, Subdomains, DNS-Einträge, TLS-Zertifikate und öffentliche Routen.
• Geplante Jobs, Worker-Prozesse, Warteschlangen, Reporting-Aufgaben und Log-Ziele.
• Eingehende und ausgehende E-Mail-Einstellungen, Zahlungsanbieter, Webhooks, APIs, Identitätsanbieter und Analytik.
• Dienstkonten, Administratorkonten, Benutzergruppen, API-Token, SSH-Zugriff sowie Notfall- oder Break-Glass-Zugriff.
• Anbieter-Abonnements, Cloud-Ressourcen, Speicherorte und für Abrechnungen Verantwortliche.

Klassifizieren Sie Aufzeichnungen, bevor Sie über Export, Aufbewahrung oder Löschung entscheiden

Erstellen Sie ein Register zur Datenverfügung, anstatt während der Abschaltung ad hoc zu entscheiden. Dokumentieren Sie für jeden Bestand an Aufzeichnungen Zweck, Geschäftseigentümer, Sensitivität, Grundlage der Aufbewahrung, genehmigtes Ziel, Abrufmethode, Zugriffskontrollen und Löschauslöser. Trennen Sie operative Aufzeichnungen von Systemartefakten: Kundendateien, Rechnungen, Prüfungsnachweise und unterzeichnete Dokumente können anders behandelt werden müssen als Cache-Daten, temporäre Uploads und Protokolle.

Für Organisationen, die der DSGVO unterliegen, bedeutet der Grundsatz der Speicherbegrenzung, dass personenbezogene Daten nicht länger aufbewahrt werden sollten, als es für den Erhebungszweck erforderlich ist. Das bedeutet nicht, dass eine sofortige Löschung immer richtig ist. Eine Aufbewahrung kann beispielsweise wegen rechtlicher Verpflichtungen oder zur Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen erforderlich sein. Siehe die Leitlinien der Europäischen Kommission zu den DSGVO-Grundsätzen (https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en) und DSGVO Artikel 17 (https://eur-lex.europa.eu/eli/reg/2016/679/2016-05-04). Die DSGVO-Leitlinien sind kein vollständiger Aufbewahrungsplan und sollten nicht als Rechtsberatung verstanden werden: Branchen-, Vertrags- und rechtsraumspezifische Anforderungen können abweichen.

Aufbewahrte Archive erfordern Schutzmaßnahmen. Nach den DSGVO-Grundsätzen verlangen Integrität und Vertraulichkeit angemessene technische und organisatorische Maßnahmen gegen unbefugte oder unrechtmäßige Verarbeitung sowie gegen unbeabsichtigten Verlust, Zerstörung oder Beschädigung. Beschränken Sie den Archivzugriff auf Personen, die ihn benötigen, und dokumentieren Sie, wer einen Abruf genehmigt.

• Aufbewahren: Genehmigte Aufzeichnungen mit einem identifizierten Zweck, Eigentümer, Aufbewahrungszeitraum und Zugriffsweg.
• Exportieren: Aufzeichnungen, die für einen operativen Ersatz, eine Prüfung, den Kundenservice oder künftige Nachweise benötigt werden.
• Löschen: Daten ohne genehmigten Aufbewahrungszweck, nachdem Sperren und Abhängigkeiten geprüft wurden.
• Dokumentieren: Entscheidungen, Genehmigende, Archivorte, Löschtermine und Ausnahmen.

Validieren Sie Exporte als nutzbare Aufzeichnungen, nicht nur als erfolgreiche Downloads

Ein Export ist nur dann nützlich, wenn die Organisation ihn identifizieren, öffnen, verstehen und später den ursprünglichen Aufzeichnungen zuordnen kann. Ein Datenbank-Dump oder Volume-Archiv kann für die Wiederherstellung wertvoll sein, jedoch für ein Finanz-, Support- oder Rechtsteam ungeeignet sein, das ohne Rekonstruktion der gesamten Anwendung eine bestimmte Rechnung, Kundenhistorie oder ein Dokument benötigt.

Dokumentieren Sie für jeden Export Umfang, Stichtagszeitpunkt, Quellanwendung, Format, Zeichenkodierung, gegebenenfalls Anzahl der Aufzeichnungen, Umgang mit Anhängen, Felddefinitionen und verantwortlichen Eigentümer. Fügen Sie genügend Kontext hinzu, um Kennungen, Statuswerte und Zeitstempel interpretieren zu können. Bewahren Sie Exportmanifeste zusammen mit dem Archiv auf, nicht nur in den Notizen eines ausscheidenden Administrators.

Testen Sie mit realistischen Abruffragen. Bitten Sie den benannten Eigentümer der Aufzeichnungen, eine repräsentative Auswahl zu finden, zugehörige Dateien zu öffnen, wichtige Felder zu bestätigen und die Ergebnisse vor der Abschaltung mit der laufenden Anwendung zu vergleichen. Wenn eine Migration erfolgt, gleichen Sie Quelle und Ziel ab und beheben Sie Ausnahmen vor der endgültigen Umstellung.

• Kann eine berechtigte Person ohne Administratorrechte später eine Aufzeichnung finden und lesen?
• Sind Dateianhänge und hochgeladene Dokumente enthalten und korrekt verknüpft?
• Enthalten Exporte erforderliche Beziehungen, Kennungen und Zeitstempel?
• Sind das Format und gegebenenfalls erforderliche Software dokumentiert?
• Ist der Archiveigentümer bekannt und wurde der Abrufzugriff getestet?
• Wurde eine repräsentative Stichprobe mit der Quelle abgeglichen?

Ordnen Sie jede externe Abhängigkeit zu und deaktivieren Sie sie

Eine stillgelegte Anwendung kann weiterhin E-Mails versenden, Anfragen annehmen, Automatisierungen auslösen oder Kosten bei Drittanbietern verursachen, wenn ihre Abhängigkeiten aktiv bleiben. Erstellen Sie eine Abhängigkeitskarte, die die Richtung zeigt: Was ruft die Anwendung auf, was ruft die Anwendung selbst auf und was läuft ohne Nutzeraktion geplant ab?

Prüfen Sie die Laufzeitkonfiguration sorgfältig. Behandeln Sie Geheimnisse getrennt von gewöhnlichen Einstellungen. Ermitteln Sie sensible Werte in der Anwendungs-, Host- und Bereitstellungskonfiguration und widerrufen oder rotieren Sie sie, anstatt sich allein auf die Löschung der Infrastruktur zu verlassen.

Deaktivieren Sie Abhängigkeiten in einer bewussten Reihenfolge. Stoppen Sie geplante Erzeuger und eingehende Webhooks vor der finalen Datenaufnahme, damit nicht unerwartet neue Aufzeichnungen eintreffen. Widerrufen Sie dann ausgehende Anmeldedaten und deaktivieren Sie Verbraucher, die eine Antwort der Anwendung erwarten. Dokumentieren Sie jede Änderung und ihr Prüfergebnis.

• Webhook-Endpunkte und Signaturgeheimnisse.
• API-Schlüssel, OAuth-Clients und Integrations-Token.
• SMTP-Anmeldedaten, E-Mail-Weiterleitungsregeln und eingehende E-Mail-Routen.
• Anwendungen beim Identitätsanbieter, SSO-Verbindungen und Bereitstellungsregeln.
• Schlüssel für Zahlungsdienste, Callback-URLs und Abonnementabhängigkeiten.
• Geplante Jobs, Warteschlangen, Worker, Cron-Aufgaben und externe Automatisierung.
• Ziele für Monitoring, Alarmierung, Protokollierung und Datenexport.

Entfernen Sie Zugriffe schichtweise: Personen, Maschinen und öffentliche Routen

Das Löschen von Benutzerkonten in der Anwendung ist notwendig, aber nicht ausreichend. Zugriffe können über Administrator-Anmeldedaten, gemeinsam genutzte Passwörter, API-Token, Dienstkonten, SSH-Schlüssel, Sitzungen beim Identitätsanbieter, Reverse-Proxy-Authentifizierung und Notfallkonten fortbestehen. Erstellen Sie ein Zugriffsregister und weisen Sie einen Verantwortlichen zu, der bestätigt, dass jeder Pfad entfernt wurde oder absichtlich für den Archivzugriff beibehalten wird.

Planen Sie die Reihenfolge sorgfältig. Behalten Sie einen eng kontrollierten Notfallzugriffsweg bei, bis Exporte, Wiederherstellungskopien und Prüfungen abgeschlossen sind. Lassen Sie ihn nicht undokumentiert oder gemeinsam genutzt. Sobald die Freigabe vorliegt, widerrufen Sie den letzten administrativen Zugriffsweg und dokumentieren Sie Zeitpunkt, handelnde Person und Nachweis.

Wenn Traefik Teil der Bereitstellung ist, prüfen Sie Router als Teil der Beseitigung öffentlicher Erreichbarkeit. Ein HTTP-Router (https://doc.traefik.io/traefik/reference/routing-configuration/http/routing/router/) gleicht eingehende Anfragen ab und leitet sie an einen Dienst weiter. Wenn die Traefik-API oder das Dashboard aktiviert und die relevante Konfiguration zugänglich ist, kann dies helfen, Router, Dienste, Middlewares, Entry Points und Beziehungen aufzulisten. Die Dokumentation zu Traefik API und Dashboard (https://doc.traefik.io/traefik/operations/dashboard/) warnt vor einer öffentlichen Freigabe in der Produktion; beschränken Sie den Zugriff auf berechtigte Administratoren und interne Netzwerke.

• Deaktivieren Sie Benutzerkonten und entfernen Sie privilegierte Rollen.
• Widerrufen oder rotieren Sie Administratorpasswörter, API-Token und Anmeldedaten von Dienstkonten.
• Entfernen Sie SSO- und Verzeichnisgruppen-Zuweisungen; prüfen Sie das Deprovisionierungsverhalten.
• Entfernen Sie SSH-Schlüssel, Serverkonsolenzugriff und gemeinsam genutzte Geheimnisse.
• Deaktivieren Sie nicht mehr benötigte Proxy-Routen und Authentifizierungskonfigurationen.
• Behalten Sie nur genehmigten, zeitlich begrenzten Archivzugriff bis zur endgültigen Stilllegung.

Fahren Sie den Workload herunter, entfernen Sie DNS-Exponierung und prüfen Sie die Stilllegung

Führen Sie die endgültige Abschaltung erst durch, nachdem die genehmigten Export-, Archiv- und Abhängigkeitsarbeiten abgeschlossen sind. Stoppen Sie den Anwendungs-Workload und zugehörige Worker, Scheduler und unterstützende Dienste, die nicht mehr benötigt werden. Bevor Sie die Stilllegung als abgeschlossen erklären, deaktivieren Sie das Neustartverhalten sowohl in der Produktions-Bereitstellungsdefinition als auch in der laufenden Umgebung. Docker Compose unterstützt Neustartrichtlinien wie `always`, `on-failure` und `unless-stopped`; ein gestoppter Dienst kann andernfalls nach einem Host- oder Dienstneustart zurückkehren. Siehe die Docker-Compose-Dienstreferenz (https://docs.docker.com/reference/compose-file/services/).

Behandeln Sie Domains und DNS als explizite Umstellungsaufgabe. Listen Sie jeden Hostnamen, Eintragstyp und jede öffentliche Route auf, über die die Anwendung erreichbar ist, einschließlich Subdomains für Webhooks, APIs oder E-Mail-bezogene Dienste. Entscheiden Sie für jeden Hostnamen, ob der Eintrag entfernt, Nutzer zu einem genehmigten Ersatz weitergeleitet oder ein eingeschränktes Archivziel beibehalten werden soll. Dokumentieren Sie das vorgesehene Ziel und den Eigentümer, bevor Sie DNS ändern.

Berücksichtigen Sie die für die geänderten Einträge geltende DNS-TTL und das Ausbreitungsverhalten. Testen Sie nach dem geplanten Änderungsfenster jeden ehemaligen Hostnamen aus den relevanten Netzwerken und bestätigen Sie, dass er nicht mehr zur stillgelegten Anwendung aufgelöst wird oder dorthin leitet. Testen Sie auch jede genehmigte Weiterleitung oder jedes Ersatzsystem. Prüfen Sie die Reverse-Proxy-Konfiguration und gegebenenfalls Traefik-Router und -Dienste, damit eine veraltete Route nicht weiterhin Anfragen an den Workload weiterleitet.

Erfassen Sie Prüfnachweise vor der Entsorgung der Infrastruktur. Dazu können der Status gestoppter Dienste, die deaktivierte Neustartkonfiguration, DNS- und Routentestergebnisse, Bestätigungen der Deaktivierung von Abhängigkeiten, Aufzeichnungen über Zugriffsentszug und die Abnahme des Archivs gehören. Bewahren Sie die Nachweise zusammen mit dem Stilllegungsnachweis auf, damit der Endzustand später verstanden und geprüft werden kann.

• Stoppen Sie die Anwendung, Worker, Warteschlangen und geplanten Dienste, die nicht mehr genehmigt sind.
• Deaktivieren Sie vor der endgültigen Freigabe das Neustartverhalten von Compose oder anderen Workloads.
• Entfernen, leiten Sie um oder beschränken Sie jeden genehmigten DNS-Eintrag und jede öffentliche Route.
• Prüfen Sie nach dem geplanten DNS-Änderungsfenster, dass ehemalige Hostnamen die Anwendung nicht mehr erreichen.
• Bestätigen Sie, dass sich jedes Ersatzsystem oder jede Archivroute wie vorgesehen verhält.
• Dokumentieren Sie Abschaltzeitpunkt, ausführende Person, durchgeführte Tests, Ergebnisse und Ausnahmen.