Jerrit Fritzsche
610719c316
Enterprise-Backup-, Recovery-, Verification-, Security- und Monitoring-Plattform fuer Proxmox VE, Windows, Linux und Dateisysteme. Der Leitsatz, der fast jede Entscheidung erklaert: Ein Backup gilt erst als vertrauenswuerdig, wenn Integritaet geprueft und Wiederherstellbarkeit nachgewiesen wurde. Deshalb steigt ein Wiederherstellungspunkt erst nach einem tatsaechlich durchgefuehrten Restore-Test auf "recoverable", und Unbekanntes geht in keine Bewertung als "gut" ein. Umfang (Phasen 0-23): - Repository Engine: inhaltsadressierte Bloecke, atomares Commit-Protokoll, Katalogaufbau allein aus den Manifesten — ohne Datenbank - Backup Engine: inhaltsabhaengiges Chunking, Deduplizierung trotz Verschluesselung, zstd, AES-256-GCM, Streaming mit Gegendruck - Agenten fuer Windows und Linux mit Auftragsabholung (Pull-Modell) - Proxmox-Provider mit beiden Zugriffswegen auf die Sicherungsarchive - Scheduler, Recovery Engine mit Pruefpunkt, Verification, Unveraenderlichkeit - Weboberflaeche, Kennzahlen, Meldungen, Berichte, Security Center, Ransomware-Heuristik (meldet, handelt nie) - Disaster Recovery, Haertung, Leistungsmessung, Chaos Testing - Eingefrorene Vertraege fuer API, Migrationen, Backup-Format und Repository - Auslieferungspaket fuer linux/amd64, linux/arm64 und windows/amd64 Nicht enthalten und als solches gekennzeichnet: Kapazitaetsprognose, Backup Copy, Changed Block Tracking bei Proxmox, erweiterte Attribute und ACLs. Gebaut, aber nie auf echter Hardware gefahren: der Windows-Dienst, die systemd-Einheit und der verpflichtende Proxmox-Meilenstein — ob eine wiederhergestellte VM startet, ist ungeprueft. Einzelheiten in CHANGELOG.md und docs/release-candidate.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
139 lines
6.3 KiB
Markdown
139 lines
6.3 KiB
Markdown
# Security Center
|
|
|
|
Phase 15. Die Antwort auf die Frage, die vor der Wiederherstellbarkeit kommt:
|
|
**Kann jemand die Backups überhaupt vernichten?**
|
|
|
|
Der Implementierungsplan (§17) macht eine ungewöhnlich konkrete Vorgabe:
|
|
|
|
> Every finding should contain: severity, explanation, affected object,
|
|
> recommendation.
|
|
|
|
Der letzte Punkt ist der wichtigste. Ein Befund ohne Empfehlung ist eine
|
|
Beunruhigung: Er sagt, dass etwas nicht stimmt, und lässt den Betreiber damit
|
|
allein. Wer „MFA fehlt" liest, weiß noch nicht, ob er es selbst einrichten kann
|
|
oder einen Administrator braucht.
|
|
|
|
Die Vollständigkeit wird **erzwungen**: `Finding.Validate()` lehnt jeden Befund
|
|
ohne eines der vier Felder ab, und die Prüfung bricht ab, statt ihn auszuliefern.
|
|
Ein unvollständiger Befund fällt sonst erst im Betrieb auf — dann, wenn jemand
|
|
ratlos vor „Sicherheitsproblem erkannt" steht.
|
|
|
|
## Die zehn Bereiche
|
|
|
|
| Bereich | Gewicht | Geprüft wird |
|
|
| --- | --- | --- |
|
|
| Löschschutz | 20 | Repositories mit gemessener Durchsetzungsstufe |
|
|
| Widerstandsfähigkeit gegen Verschlüsselungsangriffe | 15 | Anteil geschützter Wiederherstellungspunkte, offene Verdachtsfälle |
|
|
| Zweiter Faktor | 15 | MFA je aktivem Konto, gesondert bei Konten mit Löschrecht |
|
|
| Verschlüsselung | 12 | Anteil verschlüsselter Wiederherstellungspunkte |
|
|
| Kopie an einem zweiten Ort | 10 | **Nicht prüfbar** |
|
|
| Verteilung destruktiver Rechte | 10 | Anteil der Konten mit `backups.delete` |
|
|
| Absicherung der Agenten | 8 | Tokenalter, offene Aufnahme-Tokens |
|
|
| Auditprotokoll | 5 | Vorhandensein, abgewehrte Zugriffe |
|
|
| Versionsstand | 3 | Agentenversionen gegen die Dienstversion |
|
|
| Zertifikate der Agenten | 2 | **Nicht prüfbar** |
|
|
|
|
Die Gewichte folgen einer Überzeugung: **Was den Verlust der Backups verhindert,
|
|
wiegt schwerer als was ihn nur erschwert.** Der Löschschutz steht deshalb an
|
|
erster Stelle — ohne ihn genügt ein kompromittiertes Konto, um alles zu
|
|
vernichten; Verschlüsselung und zweiter Faktor halten dann niemanden auf.
|
|
|
|
### Zwei Bereiche werden nicht geprüft
|
|
|
|
- **Kopie an einem zweiten Ort:** Sekundäre Kopien sind nicht umgesetzt
|
|
(PROMPT.md §17, Backup Copy). Die Anlage kann deshalb nicht sagen, ob es eine
|
|
gibt. Dieselbe Entscheidung wie bei `HasOffsiteCopy` in der Recovery Assurance.
|
|
- **Zertifikate der Agenten:** Die Agenten weisen sich über Betriebstokens aus.
|
|
`agent_certificates` wird von keiner Stelle beschrieben; eine Prüfung könnte
|
|
nur bestätigen, dass nichts da ist.
|
|
|
|
## Unbekannt zählt nie als gut
|
|
|
|
Ein nicht prüfbarer Bereich geht **nicht** in die Rechnung ein — weder positiv
|
|
noch negativ:
|
|
|
|
- Ihn als bestanden zu werten wäre Schönfärberei.
|
|
- Ihn als durchgefallen zu werten wäre eine Behauptung über etwas, das niemand
|
|
geprüft hat.
|
|
|
|
Deshalb steht neben der Prozentzahl immer, wie viele Punkte überhaupt erreichbar
|
|
waren (`maximum_score`) und welche Bereiche fehlen (`unchecked_areas`). Ab drei
|
|
ungeprüften Bereichen sagt die Zusammenfassung ausdrücklich: *„Die Zahl ist eine
|
|
Vermutung, keine Aussage."*
|
|
|
|
Dieselbe Struktur wie bei der Recovery Assurance aus Phase 10 — und aus demselben
|
|
Grund.
|
|
|
|
## Ein kritischer Befund deckelt die Einstufung
|
|
|
|
Eine Anlage, bei der ein einziges gestohlenes Konto alle Backups vernichten kann,
|
|
ist nicht „gut abgesichert mit kleinem Mangel". Solange ein kritischer Befund
|
|
besteht, lautet die Einstufung `unzureichend` — unabhängig von der Prozentzahl —
|
|
und `is_trustworthy` ist false.
|
|
|
|
Real nachgewiesen: 88 von 100 Punkten mit einem kritischen Befund ergeben
|
|
trotzdem `unzureichend`.
|
|
|
|
## Der Verlauf
|
|
|
|
Der Score wird bei **jedem Aufruf neu berechnet**, nicht gelesen: Er hängt am
|
|
Zustand der Anlage und veraltet von selbst. Was gespeichert wird, ist sein
|
|
Verlauf — als Reihe `security_score` in `metric_samples` (Phase 13), erfasst vom
|
|
Kennzahlensammler alle fünf Minuten.
|
|
|
|
Ohne ihn ließe sich nicht sagen, ob die Lage besser oder schlechter geworden ist.
|
|
|
|
Das Dashboard-Widget liest die **letzte Messung**, nicht den frisch berechneten
|
|
Wert: Die Übersicht bliebe sonst an zehn Datenbankabfragen hängen, und das
|
|
Kennzahlenpaket bekäme eine Abhängigkeit auf das Security Center. Der Preis ist,
|
|
dass die Zahl bis zu fünf Minuten alt sein kann — das Alter steht deshalb dabei.
|
|
|
|
## Endpunkte
|
|
|
|
| Methode | Pfad | Recht |
|
|
| --- | --- | --- |
|
|
| GET | `/api/v1/security` | `security.read` |
|
|
| GET | `/api/v1/security/findings` | `security.read` |
|
|
| GET | `/api/v1/metrics/security_score?range=7d` | `monitoring.read` |
|
|
|
|
Die Befunde stehen getrennt, weil sie die eigentliche Arbeitsliste sind — nach
|
|
Schweregrad geordnet, damit oben steht, was zuerst zu tun ist.
|
|
|
|
## Nachgewiesen
|
|
|
|
Vollständiger Zyklus gegen den laufenden Dienst:
|
|
|
|
| Schritt | Bewertung | Einstufung | Kritisch | Belastbar |
|
|
| --- | --- | --- | --- | --- |
|
|
| Ausgangslage | 35 % | unzureichend | 2 | nein |
|
|
| Gehärtetes Repository angelegt und gemessen | 40 % | unzureichend | 1 | nein |
|
|
| Zweiter Faktor für beide Konten eingerichtet | 57 % | verbesserungsbedürftig | 0 | **ja** |
|
|
|
|
Die Einstufung wechselt genau dann, als der letzte kritische Befund verschwindet
|
|
— nicht bei einer runden Prozentzahl.
|
|
|
|
Weiter geprüft:
|
|
|
|
- Alle sechs Befunde tragen Schweregrad, Erklärung, betroffenes Objekt und
|
|
Empfehlung; Empfehlungen unter 20 Zeichen werden vom Test abgelehnt.
|
|
- Zwei Bereiche als „nicht prüfbar" ausgewiesen, beide mit Begründung.
|
|
- Der Verlauf zeigt 35 % → 57 % mit dem korrekten Hinweis „nur 2 Messungen".
|
|
- Dashboard: 9 von 10 Kennzahlen verfügbar (nur die Kapazitätsprognose fehlt
|
|
noch).
|
|
|
|
## Bekannte Grenzen
|
|
|
|
- **Keine Historie der Befunde.** Gespeichert wird der Score, nicht welcher
|
|
Befund wann bestand. Wer wissen will, warum die Kurve vor drei Wochen fiel,
|
|
findet es nicht heraus.
|
|
- **Der Versionsstand vergleicht nur gegen die Dienstversion**, nicht gegen eine
|
|
Liste bekannter Schwachstellen. Eine solche gibt es hier nicht, und eine
|
|
erfundene wäre schlimmer als keine.
|
|
- **Keine Prüfung der Passwortstärke bestehender Konten.** Die Stärke wird beim
|
|
Setzen geprüft; ob ein altes Passwort den heutigen Anforderungen genügt, weiß
|
|
die Anlage nicht — sie speichert nur den Hash.
|
|
- **Keine Empfehlung mit Ausführung.** Jeder Befund nennt den nächsten Schritt,
|
|
aber niemand kann ihn per Klick auslösen. Das ist Absicht: Sicherheitsrelevante
|
|
Änderungen sollen bewusst geschehen.
|
|
- **Kein Prüfbericht zum Ausleiten.** Berichte folgen in einer späteren Phase.
|