Worum es geht
WORM heißt write once, read many: einmal schreiben, beliebig oft lesen, nie ändern. CRMS legt die Bytes jedes endgültigen Dokuments in einen solchen Speicher. Technisch ist das ein S3-Bucket mit Object Lock. S3 ist eine weit verbreitete Schnittstelle für Objektspeicher (zum Beispiel MinIO, AWS, OBS). Object Lock ist die Funktion von S3, die ein Objekt bis zu einem Datum sperrt.
CRMS sperrt im Compliance-Modus. In diesem Modus kann niemand ein Objekt vor Ablauf der Sperre löschen oder ändern, auch nicht der Betreiber mit vollen Rechten am Bucket.
Was beim Ablegen passiert
-
1CRMSerzeugt einen Dokumentschlüssel, 256 Bit, nur für dieses Dokument
-
2CRMSverschlüsselt die Bytes mit AES-256-GCM und bindet sie an die Revision
-
3CRMS→Dateispeicherlegt die verschlüsselten Bytes unter
crms/<eigentümer>/<kette>/<revision>ab, gesperrt bisretainUntil, bei aktivem Legal Hold zusätzlich mit Legal Hold -
4Dateispeicher→CRMSantwortet mit der Versionskennung des Objekts
-
5CRMS→Datenbankhält Objektschlüssel und Versionskennung in der Revision festErgebnis: Die Revision weiß genau, welche Version welches Objekts ihr gehört
- Der Bucket sieht nur verschlüsselte Bytes. Wer den Bucket lesen kann, kann das Dokument noch lange nicht lesen.
- Die Sperre wird auf die volle Sekunde aufgerundet. Sie ist nie kürzer als das, was die Revision festhält.
- Jeder Zugriff nennt die Versionskennung. Auf einem gesperrten Bucket „gelingt“ ein Löschen ohne Version, setzt aber nur eine Löschmarke, und das Objekt bleibt. CRMS fragt deshalb immer genau die Version an.
Die Schlüssel
Jeder Dokumentschlüssel wird selbst verschlüsselt gespeichert, „eingepackt“ mit dem Schlüssel-Schlüssel aus CODAMAI_CRMS_DOCUMENT_KEY (256 Bit, Base64). Den Schlüssel-Schlüssel braucht CRMS, solange Dokumentrevisionen an sind. Fehlt er, startet CRMS nicht.
Das Einpacken ist an Kennung und Eigentümer des Dokumentschlüssels gebunden. Kopiert jemand eingepackte Bytes in eine andere Zeile, lassen sie sich dort nicht auspacken.
Ein eigener Schlüssel je Dokument erlaubt das Löschen durch Schlüsselvernichtung, siehe Aufbewahrung, Legal Hold und Löschung.
Was CRMS beim Start prüft
| Bucket vorhanden? | Object Lock an? | CODAMAI_CRMS_STORAGE_ALLOW_UNLOCKED | Versionierung an? | Start |
|---|---|---|---|---|
| nein | – | – | – | scheitert |
| ja | ja | – | – | startet, Objekte werden gesperrt |
| ja | nein | false | – | scheitert |
| ja | nein | true | nein | scheitert |
| ja | nein | true | ja | startet ohne Sperre, Legal Holds werden nicht gesetzt |
CODAMAI_CRMS_STORAGE_ALLOW_UNLOCKED=true ist nur für die Entwicklung gedacht. Ohne Sperre ist der Speicher kein WORM-Speicher mehr.
Der Bucket
- Er heißt so, wie
CODAMAI_CRMS_DOCUMENT_BUCKETsagt. Die Variable ist Pflicht. - Du legst ihn an, nicht CRMS, und zwar mit Object Lock. Auf vielen S3-Speichern lässt sich Object Lock nicht nachträglich einschalten. Wer einen Bucket anlegen darf, könnte ihn auch ohne Sperre anlegen. Deshalb tut CRMS es nicht selbst.
- Die Verbindung ist für alle CodamAI-Module dieselbe:
CODAMAI_S3_ENDPOINT,CODAMAI_S3_ACCESS_KEY,CODAMAI_S3_SECRET_KEY, dazuCODAMAI_S3_REGION(Standardus-east-1) undCODAMAI_S3_PATH_STYLE(Standardtrue, MinIO braucht das). Jedes Modul nennt nur seinen eigenen Bucket. Alle Variablen stehen unter Konfiguration.
Wer den Speicher mitbringt
| eingebettet | eigener Dienst | |
|---|---|---|
| Wo CRMS läuft | in deiner Anwendung | im CRMS-Dienst |
| Wer den S3-Speicher von CRMS mitbringt | deine Anwendung, solange Dokumentrevisionen an sind | der CRMS-Dienst |
| Wer den Bucket konfiguriert | deine Anwendung | der CRMS-Dienst. Deine Anwendung braucht keinen Bucket |
Sind Dokumentrevisionen aus (CODAMAI_CRMS_DOCUMENT_REVISIONS=false), braucht keine Betriebsart einen Speicher. FINAL wird dann abgelehnt. Mehr zu den Betriebsarten unter Eingebettet oder als eigener Dienst.
Fehler aus dem Speicher
| Schlüssel | Status | Bedeutung |
|---|---|---|
document-locked | 409 | S3 hat ein Löschen oder Ändern abgelehnt: Sperre oder Legal Hold |
document-object-missing | 500 | S3 hält diese Version nicht |
storage-versioning-missing | 500 | S3 hat keine Versionskennung geliefert, der Bucket ist nicht versioniert |
storage-failed | 502 | jede andere Ablehnung durch S3, Einzelheiten im Log |