Blob-v2-Schlüsselinventur sicher bewerten

Diese Betriebsseite richtet sich an Betreiber selbst gehosteter Workspace-Installationen. Nutzen Sie sie, wenn Sie einen Root-Key-Wechsel vorbereiten, einen alten Schlüssel aus dem Root-Key-Bundle entfernen möchten oder einen Blocker der Blob-Inventur einordnen müssen.

Nach der Prüfung wissen Sie, ob Blob-v1- und Blob-v2-Bestände eine alte kid noch benötigen. Entfernen Sie einen Schlüssel erst, wenn Distribution, Drain und das konkrete Removal-Gate ohne offenen Befund sind.

Das richtige Werkzeug wählen

Die Root-Key-Inventur benötigt privilegierten lokalen Zugriff auf die verschlüsselte Serverkonfiguration, das Root-Key-Bundle, PostgreSQL und den Storage-Root. Sie ist deshalb kein tenantgebundener Remote-Aufruf.

Aufgabe	Werkzeug und Grenze
Einen laufenden Server über autorisierte Tenant-APIs bedienen	Verwenden Sie `nucli`. `nucli` liest keine Root-Key-Bundles und scannt keinen lokalen Blob-Storage.
Einen dokumentierten lokalen `numin`-Vertrag ausführen	Verwenden Sie ausschließlich die unter numin aufgeführten Befehle. Der aktuelle öffentliche `numin`-Vertrag enthält keine Root-Key-Inventur.
Den Workspace-Server starten	Verwenden Sie den Server-Entrypoint ausschließlich als Runtime. Nutzen Sie ihn nicht als allgemeine Administrations-CLI.
Eine Blob-v2-Root-Key-Inventur erzeugen	Verwenden Sie nur den freigegebenen, versionsgleichen Betriebsweg Ihrer Installation. Stoppen Sie, wenn Ihr Deployment keinen solchen Vertrag bereitstellt. Ersetzen Sie ihn nicht durch direkten Datenbankzugriff oder eigene Storage-Skripte.

Ein eigener nucli-Skill ist für diese Aufgabe nicht erforderlich. Ein solcher Skill könnte nur einen vorhandenen, authentisierten Serververtrag anleiten; er darf keine lokale Kryptologik oder einen Root-Key-Scan im Client nachbauen.

Was die Inventur schützt

Workspace verwendet ein versioniertes Root-Key-Bundle. Die kid bezeichnet die Schlüsselversion, nicht das Schlüsselmaterial. Neue Writes verwenden die aktive kid; ältere Blobs können weiterhin eine entschlüsselungsfähige ältere kid benötigen.

Die Inventur trennt drei Aussagen:

Welches Containerformat liegt vor?
Welche authentifizierte kid benötigt der Container?
Gibt es fehlende, ungültige oder noch nicht abgedeckte Bestände, die eine Entfernung blockieren?

Warum der Klartextheader nicht genügt

Ein Blob-v2-Container beginnt mit einem begrenzten Klartextheader. Er enthält nur den Formatwert nucleus-blob-container.v2, die Kryptodomäne nucleus/blob.v2, die kid, ein zufälliges Salt und die Chunkgröße. Tenant, Store, Objekt, Dateiname, Medientyp und Nutzdaten bleiben verschlüsselt.

Die Inventur zählt die Header-kid nicht direkt. Sie verwendet die kid zuerst zur Auflösung des vorhandenen Root-Key-Domain-Schlüssels und prüft anschließend den ersten verschlüsselten Metadatenframe:

Der exakte Header ist als Additional Authenticated Data an AES-GCM gebunden.
Der Blob-Schlüssel ist aus Domain-Schlüssel, Salt sowie Tenant-, Store- und Objekt-ID abgeleitet.
Der entschlüsselte Metadatenframe muss wieder zum erwarteten Tenant, Store, Objekt und Medientyp passen.
Erst nach erfolgreicher Authentifizierung gelangt die kid in die Inventurzählung.

Damit schlagen Änderungen an Header, kid, Salt oder Objektbindung fail-closed fehl. Eine unbekannte oder nicht mehr entschlüsselungsfähige kid wird nicht als gültiger Bestand gezählt.

Was die begrenzte Prüfung nicht leistet

Die Schlüsselinventur liest keine vollständigen Nutzdatenframes. Sie ersetzt keine vollständige Integritätsprüfung des Dokuments.

Prüfung	Schlüsselinventur	Vollständiger Blob-Read
Format und Headervertrag	Ja	Ja
Authentifizierte `kid`	Ja	Ja
Tenant-, Store- und Objektbindung	Ja	Ja
Erster verschlüsselter Metadatenframe	Ja	Ja
Alle Nutzdatenframes	Nein	Ja
Abschlusstrailer, Größe und SHA-256	Nein	Ja
Daten nach dem Trailer	Nein	Ja

Diese Grenze ist für ein Key-Retirement sicher: Gehört ein Container zu einer alten kid, zählt die Inventur diese Abhängigkeit bereits nach dem authentifizierten Metadatenframe. Auch eine später beschädigte Payload kann dadurch die alte Schlüsselabhängigkeit nicht verbergen.

Voraussetzungen

Prüfen Sie vor dem Inventurlauf:

Sie verwenden exakt die Workspace-Version, die zu Datenbank und Blob-v2-Format der Installation gehört.
Der Betriebsweg hat read-only Zugriff auf die verschlüsselte Konfiguration, den zugehörigen Config-Key, PostgreSQL und den vollständigen Storage-Root.
Alle erwarteten Server- und Begleitprozesse melden ihren Bundle-Fingerprint und ihre aktive kid über den freigegebenen Observability-Weg.
Das aktuelle Root-Key-Bundle bleibt gesichert und enthält alle noch benötigten decrypt_kids.
Eine aktuelle Sicherung und ein dokumentiertes Change-Fenster liegen vor.

Geben Sie niemals Root-Key-Werte, abgeleitete Schlüssel, Config-Keys, Datenbankpasswörter oder Blob-Inhalte in Tickets, Chat, Shell-Historien oder Inventurprotokollen aus. kid und Bundle-Fingerprint sind Identifikatoren, keine Schlüsselwerte; behandeln Sie auch sie als betriebliche Metadaten.

Inventurergebnis lesen

Ein vollständiger Bericht enthält mindestens diese Blob-Sicht:

Feld	Bedeutung	Sichere Reaktion
`blob_objects`	Anzahl kryptografisch eingeordneter Blob-v1- und Blob-v2-Objekte	Mit dem erwarteten Storage-Bestand plausibilisieren.
`blob_formats`	Anzahl je authentifiziertem oder kanonisch geprüftem Format	`nucleus-blob-container.v2` muss bei vorhandenen v2-Writes sichtbar sein.
`blob_kids`	Anzahl gültiger Blobs je authentifizierter `kid`	Jeder Eintrag für eine alte `kid` blockiert deren Entfernung.
`blob_missing`	Datenbankobjekte ohne erreichbaren Payload	Größer als null blockiert Drain und Retirement.
`blob_invalid`	Unbekannte, manipulierte oder nicht authentifizierbare Container	Größer als null blockiert Drain und Retirement.
`coverage_pending` oder `scope_pending`	Root-Key-Domänen ohne vollständigen Inventur- oder Laufzeitvertrag	Nicht leer bedeutet: keine Entfernung freigeben.

Die zusammengefassten Gates haben unterschiedliche Aufgaben:

Gate	Prüft	Freigabekriterium
`distribution`	Alle erwarteten Prozesse verwenden denselben Bundle-Stand und dieselbe aktive `kid`.	`status:clear`
`drain`	Keine ungültigen oder fehlenden Bestände und keine relevanten Writes mit alten Schlüsseln.	`status:clear`
`retirement`	Distribution, Drain und alle einzelnen Removal-Gates sind frei.	`status:clear`
`retirement_gate[<kid>]`	Konkrete Abhängigkeiten einer nicht aktiven `kid`.	Für die zu entfernende `kid`: `status:clear`

active_write_key ist kein Fehler. Die aktive kid darf nicht entfernt werden und erhält deshalb keinen normalen Clear-Status.

Blocker sicher behandeln

Eine alte `kid` besitzt noch Blob-Bestand

Lassen Sie die kid in decrypt_kids. Für Blob-v2 existiert kein allgemein freigegebener Relokations-, Downgrade- oder Rekey-Pfad. Verschieben Sie die Datei nicht manuell und schreiben Sie keinen v1-Container als Ersatz.

Warten Sie auf einen expliziten, versionsgebundenen und dry-run-fähigen Offline-Vertrag. Ein erneuter normaler fachlicher Write darf einen Blob nur dann ersetzen, wenn der jeweilige Produktvertrag dies ausdrücklich erlaubt.

`blob_missing` ist größer als null

Entfernen Sie den Datenbankeintrag nicht, um den Zähler zu bereinigen. Prüfen Sie Sicherungen, Storage-Mount, Berechtigungen und die Vollständigkeit des Storage-Rolls. Stellen Sie den fehlenden Payload nur über einen dokumentierten Restore- oder Recovery-Vertrag wieder her.

`blob_invalid` ist größer als null

Bewahren Sie Container und Bericht für die Analyse. Prüfen Sie zuerst Version, Bundle, Storage-Konsistenz und einen möglichen unvollständigen Restore. Probieren Sie keine anderen Schlüssel und ändern Sie den Header nicht. Ein ungültiger Container ist ein Blocker, kein Bestand mit der Anzahl null.

Erzeugen Sie den Bericht über den freigegebenen, versionsgleichen und read-only Betriebsweg Ihrer Installation.
Prüfen Sie zuerst distribution und die erwarteten Prozessrollen.
Prüfen Sie blob_missing, blob_invalid, Formate und KID-Zählungen.
Prüfen Sie drain und danach das Removal-Gate der konkreten alten kid.
Dokumentieren Sie nur Identifikatoren, Zählwerte, Status und redigierte Gründe. Speichern Sie keine Schlüsselwerte oder Payloads.
Entfernen Sie die alte kid nur über einen ausdrücklich freigegebenen Bundle-Vertrag und nur, wenn das Gesamtgate retirement sowie das konkrete Removal-Gate clear melden.
Rollen Sie das geänderte Bundle vollständig aus und prüfen Sie danach Fingerprint, aktive kid, Reads und Fehlerzähler erneut.

Erfolg erkennen

Die Prüfung ist erfolgreich abgeschlossen, wenn:

nucleus/blob.v2 als vollständig inventarisierte At-Rest-Domäne erscheint,
blob_missing=0 und blob_invalid=0 gelten,
die zu entfernende kid in blob_kids keinen Bestand mehr besitzt,
alle erwarteten Prozessrollen einen konsistenten Bundle-Stand melden,
distribution, drain, retirement und das konkrete Removal-Gate den erforderlichen Clear-Status besitzen,
der freigegebene Rollout keine unbekannten kid-, Verify-, Decrypt- oder Read-Fehler erzeugt.

Ein abgebrochener oder unvollständiger Lauf ist kein Erfolg. Behalten Sie die alte kid, bis Sie die Prüfung vollständig wiederholen können.

Nächste Schritte

Ordnen Sie allgemeine Sicherheitsanforderungen unter Betriebssicherheit ein.
Prüfen Sie Storage-Aufbau und Dokumentbetrieb unter Dokumente und Storage.
Verwenden Sie nucli ausschließlich für autorisierte Remote- und Tenant-Aufgaben.
Prüfen Sie die eng begrenzten lokalen Verträge unter numin.
Planen Sie Binär- und Bundle-Rollouts mit Updates und Rollback.

Blob-v2-Schlüsselinventur sicher bewerten

Das richtige Werkzeug wählen

Was die Inventur schützt

Warum der Klartextheader nicht genügt

Was die begrenzte Prüfung nicht leistet

Voraussetzungen

Inventurergebnis lesen

Blocker sicher behandeln

Eine alte `kid` besitzt noch Blob-Bestand

`blob_missing` ist größer als null

`blob_invalid` ist größer als null

Die Distribution ist blockiert

Die Coverage ist offen

Sichere Entscheidungsfolge

Erfolg erkennen

Nächste Schritte