Wenn wir ein Dokumentationssystem entwerfen, das aus dem System Dokumente in ein Web Frontend exponiert, gibt es eine relativ sichere Methode, zumindest die bereits im Web zugänglich gemachte Dokumentation gegen Ausfälle zu schützen, und die Verfügbarkeit sowie die Integrität dieser „Ausgabe“ zu sichern.
Die Integrität der Dokuments können wir durch einen Hash jederzeit feststellen.
Die Herkunft durch eine digitale Signatur verifizieren.
Die relativ sichere Verfügbarkeit hängt von einer, mindestens logischen Trennung des Backends, der Datenbank und des Frontends ab.
3 Säulen sollen es sein
JAMStack/ Static Site Generation
Die Vertraulichkeit für den Zugang regelt man natürlich durch eine eindeutige Identifikation und Verifizierung des Nutzers, der Zugriff zum Service oder Dokument verlangt.
Vorweg: Zugänglich meint hier natürlich einen, durch eindeutige Authentizierung und Authentifizierung autorisierten Zugriff und nicht frei f+ür Dritte zugängliche Dokumententation.
Die Sprache des statischen Webs und der Browser ist html
Zwischen die Ausgabe und das Backend gehört ein Built Prozessor, der die von der Datenbank gespeiste html Ausgabe als statisches html ausspielt, als One Way Prozess arbeitet und jede neue Dokumentation durch eben diesen Prozess zusätzlich zu dem Live Stream aus der Datenbank in ein statisches html Dokument verwandelt.
→ Die Kompromittierung der Quelle wirkt nicht automatisch rückwirkend auf bereits veröffentlichte Artefakte.
Die Sicherungsmethode funktioniert auch für PDF
Ist das Frontend vom Backend und der Datenbank entkoppelt (nicht fragen, ob es sinn macht, denn es macht sinn), anders gesagt, ist das Backend oder die Datenbank kompromittiert, so bleiben zumindest die statischen Elemente bestehen.
Bei der Kompromittierung muss man drei wesentliche Bereiche getrennt sehen und auch so behandeln.
Das Backend, die Datenbank und das Frontend.
Ist der Service auf Hoster Ebene kompromittiert, und liegen dabei alle drei Bereiche auf dem selben Root, dann gilt diese Sicherheit nicht mehr.
Ist das Backend kompromittiert, bedeutet das nicht gleich, dass die Datenbank kompromittiert werden kann.
Ist die Datenbank kompromittiert, dann sind bei dieser Vorgehensweise die bereits ausgespielten Dokumente nicht davon betroffen.
Wer hier sofprt einen Bruch in der Logik feststellt, der hat bei der Entwicklungalles richtig gemacht. Denn sicher ist ein ausgespieltes Dokument nur, wenn der Built Prozess als Einbahnstraße konzipiert ist und nicht bidirektional arbeitet.
Wer auch beii einer kompromittierung auf Hoster oder VM Ebene die Verfügbarkeit für ein ausgespieltes Dokument sicher stellen will, der muss das Dokument als Objekt behandeln und bei einem Hoster oder privat in einem Cloud Object Storage nutzen.
WORM bedeutet Write Once Read Many. Einmal geschriebene HTML-Dateien können dann von “Niemandem” mehr geändert werden. Wobei auch Niemand und niemals nicht als absolut zu betrachten sind.
Was ist dann überhaupt so richtig sicher?
Nichts und niemand ist zu 100 % sicher.