syncova-backup/docs/security-center.md

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.