Zum Hauptinhalt springen

Backup und Upgrade

Was zu sichern ist​

ElementWarum
Die PostgreSQL-DatenbankEnthält alles: Funde, Prüfentscheidungen, Unterdrückungen, Regeln samt Versionshistorie, Scan-Konfigurationen, Audit-Ereignisse sowie die verschlüsselten Jira- und SMTP-Zugangsdaten.
JIRA_CREDENTIAL_ENCRYPTION_KEYOhne ihn lassen sich die gespeicherten Jira- und SMTP-Zugangsdaten in einer wiederhergestellten Datenbank nicht entschlüsseln.
FINDING_FINGERPRINT_HMAC_SECRETOhne ihn passen aus dem Backup wiederhergestellte Funde nicht mehr zu dem, was der nächste Scan erzeugt.
Ihre LizenzdateiDas erneute Hochladen ist trivial, aber halten Sie die Datei bereit, damit Sie bei einer Wiederherstellung nicht auf eine Neuausstellung warten.

Der Container selbst ist zustandslos. Es gibt kein zu sicherndes Volume und keine Datei auf der Platte, die erhalten bleiben müsste - ein verlorener Container wird ersetzt, indem das Image mit derselben Umgebung erneut gestartet wird.

pg_dump --format=custom --file=riskscanner-$(date +%F).dump riskscanner

Wiederherstellen​

  1. Spielen Sie die Datenbank in eine leere PostgreSQL-Datenbank ein.
  2. Starten Sie das Image mit denselben beiden Secrets, mit denen das Backup erstellt wurde.
  3. Melden Sie sich an und prüfen Sie unter Administration -> Jira-Verbindung, ob Verbindung testen weiterhin erfolgreich ist. Ein Fehlschlag bedeutet fast immer, dass der Verschlüsselungsschlüssel nicht zum Backup passt.

Upgrade​

Ein Upgrade ist ein Austausch des Containers. Schemaänderungen werden beim Start automatisch von Flyway angewendet, ausschliesslich vorwärts; es gibt kein separates Migrationskommando und keinen Downgrade-Pfad.

  1. Sichern Sie die Datenbank. Das ist Ihr einziger Rollback.

  2. Stellen Sie sicher, dass kein Scan läuft. Ein mitten im Lauf unterbrochener Scan lässt sich zwar fortsetzen, aber zuerst fertig zu werden hält die Lage übersichtlich.

  3. Ziehen Sie das neue Image und starten Sie den Container mit unveränderten Umgebungsvariablen neu:

    docker pull arcsoftklg/sensitive-data-scanner:latest
    docker stop sensitive-data-scanner && docker rm sensitive-data-scanner
    # mit demselben run-Befehl erneut starten

  4. Beobachten Sie die Logs, bis die Flyway-Migration abgeschlossen ist und GET /actuator/health UP meldet.

Lizenz, Regeln, Funde und Konfigurationen liegen in der Datenbank und überstehen das Upgrade. Eingebaute Erkennungsregeln können mit einem neuen Release neue Versionen erhalten; bestehende eigene Regeln und ihre Versionshistorie bleiben unangetastet.

Der Release, der versionierte v2-Fund-Fingerprints einführt, errät bewusst keine neuen Identitäten aus alten Funden: Rohwerte wurden nie gespeichert, also ist eine exakte Konvertierung unmöglich. Der erste Bestätigungsscan erzeugt neue v2-Identitäten. Frühere Funde bleiben bis zur Aufbewahrungslöschung als Historie erhalten; Prüf- oder Unterdrückungsstatus wird nicht automatisch auf ein möglicherweise anderes Geheimnis übertragen.

Rollback

Flyway-Migrationen laufen nur vorwärts und clean ist deaktiviert. Ein Downgrade auf ein älteres Image gegen ein neueres Schema wird nicht unterstützt - rollen Sie zurück, indem Sie das in Schritt 1 erstellte Datenbank-Backup einspielen und das alte Image dagegen starten.

Rollierende Upgrades mit mehreren Instanzen​

Wenn Sie von einer Version aktualisieren, die noch keine Scan-Heartbeats schreibt, warten Sie vor dem Start der ersten neuen Instanz, bis alle laufenden Scans beendet sind. Ältere Instanzen können ihre laufenden Scans nicht als aktiv melden; eine Heartbeat-fähige Instanz würde diese Läufe sonst als verwaist behandeln.

Sobald auf allen Instanzen eine Heartbeat-fähige Version läuft, koordiniert sich die Planung über die Datenbank (siehe Mehrere Instanzen betreiben), und rollierende Neustarts sind für Scans sicher, die auf weiterlaufenden Instanzen ausgeführt werden. Die Ausnahme ist ein Scan, der auf der ersetzten Instanz lief: Er hat keinen Ort mehr, an dem er weiterlaufen kann, und wird innerhalb von rund 90 Sekunden als fehlgeschlagen markiert, sodass Sie ihn auf der neuen Instanz fortsetzen können.

Die neue Instanz wendet ausserdem ihre Migrationen unmittelbar beim Start an, alte und neue Instanz teilen sich also kurzzeitig ein Schema; halten Sie die Überlappung kurz.