| Typ | Synthese |
|---|---|
| Quellen | Quelle - Informationssicherheit Zusammenfassung Quelle - LLM Wiki - Ideendatei Quelle - Warum ein Zweites Gehirn bauen Quelle - Docker Bootcamp |
| Erstellt | 2026-09-24 |
| Aktualisiert | 2026-09-27 |
| Tags | informationssicherheit, llm-wiki, backup, datenschutz, wissensmanagement |
Die Grundsätze aus der Informationssicherheit (2004), angewendet auf dieses zweite Gehirn: Viele Schutzmechanismen stecken schon im Schema, die grösste Lücke ist ein echtes Backup mit Versionsgeschichte.
Diese ganze Seite ist eine Übertragung von Claude. Keine Quelle behandelt die Sicherheit eines LLM Wikis direkt. Die Grundsätze stammen aus Quelle - Informationssicherheit Zusammenfassung, die Fakten zum Vault aus CLAUDE.md und den Seiten LLM Wiki und Datenhoheit. Die Bewertungen in der Risikotabelle sind grobe Schätzungen, keine Messungen.
Ausgangslage
- Der Vault liegt als Markdown-Dateien in einem SynologyDrive-Ordner und wird darüber synchronisiert (Datenhoheit).
- Er ist kein git-Repository. Die Ideendatei empfiehlt git ausdrücklich (Quelle - LLM Wiki - Ideendatei).
- Claude liest und schreibt die Dateien. Dabei gelangen Inhalte an einen externen KI-Dienst.
- Das Schema trennt die Rollen: Rohquellen schreibt nur der Mensch, das Wiki nur das LLM (LLM Wiki).
Die vier Schutzziele, auf den Vault übertragen
| Schutzziel (Informationssicherheit) | Bedeutung für den Vault | Was schon da ist | Lücke |
|---|---|---|---|
| Vertraulichkeit | Persönliche Notizen bleiben privat | lokale Dateien, eigener Speicher | Inhalte gehen beim Bearbeiten an den KI-Dienst (Datenhoheit, Datenschutz Schweiz) |
| Integrität | Seiten werden nicht unbemerkt verfälscht | sources/ unveränderlich, Widersprüche werden markiert, Belege pro Aussage |
Fehlerhafte LLM-Änderungen lassen sich ohne Versionsgeschichte schwer erkennen und rückgängig machen |
| Verfügbarkeit | Das Wissen ist auch nach einem Defekt noch da | Synchronisation auf das NAS | Eine Synchronisation ist kein Backup, siehe unten |
| Verbindlichkeit | Nachvollziehbar, wer was wann geändert hat | log.md als append-only-Protokoll |
Das Log beschreibt Änderungen, belegt sie aber nicht zeilengenau |
Parallelen: was das Schema schon richtig macht
Mehrere Regeln aus CLAUDE.md entsprechen klassischen Sicherheitsprinzipien:
| Prinzip aus der Quelle | Umsetzung im Vault |
|---|---|
| Funktionentrennung (Cobit): Keine Einzelperson soll einen kritischen Prozess allein kontrollieren (IT-Audit) | Drei Schichten mit klarer Schreibberechtigung: Mensch → sources/, LLM → wiki/, beide → Schema |
| 4-Augen-Prinzip (Zugriffskontrolle) | Beim Ingest werden die Kernaussagen erst besprochen, Löschen und Verschieben brauchen eine Rückfrage, Lint-Korrekturen eine Freigabe |
| Protokollierung (Zugriffskontrolle) | log.md, per grep auswertbar |
| Audit (IT-Audit) | Der Lint ist eine regelmässige Verfahrensprüfung: Er prüft, ob die Regeln des Schemas eingehalten werden |
| Integritätsdatenbank (Netzwerksicherheit) | noch nicht umgesetzt; git würde dasselbe leisten (Hash pro Dateiversion) |
Warum SynologyDrive allein kein Backup ist
Die Quelle fordert: Ein Backup „sollte nicht den gleichen Risiken ausgesetzt sein wie die produktiven Daten“ (Informationssicherheit, Abschnitt Physische Sicherheit). Eine Synchronisation überträgt aber jede Änderung, auch versehentliches Löschen, eine fehlerhafte Massenänderung oder eine Verschlüsselung durch Ransomware. Sie schützt vor dem Ausfall eines Geräts, nicht vor Fehlern in den Daten selbst.
Aus Business Continuity Planning übertragen:
- RPO (wie viel Datenverlust ist tragbar?): Ohne Versionsgeschichte ist der letzte gute Stand unklar.
- RTO (wie schnell wieder arbeitsfähig?): Markdown-Dateien sind sofort lesbar, sobald eine Kopie da ist. Das ist ein Vorteil der offenen Formate (Datenhoheit).
Kleine Risikoanalyse
Methode nach Risikoanalyse, Wahrscheinlichkeit (W) × Auswirkung (A) auf der Skala 1–5, grob geschätzt:
| Risiko | W | A | Bewertung | Strategie |
|---|---|---|---|---|
| LLM überschreibt oder verfälscht Seiten unbemerkt | 3 | 3 | 9 | vermindern: git, Lint, Review der Diffs |
| Versehentliches Löschen, das sich überall hin synchronisiert | 2 | 4 | 8 | vermindern: versioniertes Backup |
| Ransomware verschlüsselt den synchronisierten Ordner | 1 | 5 | 5 | vermindern: Offline- oder unveränderliches Backup |
| Vertrauliche Inhalte gelangen an den KI-Dienst | 3 | 2–4 | 6–12 | je nach Inhalt: akzeptieren oder vermeiden (heikles nicht in den Vault) |
| NAS-Defekt | 1 | 3 | 3 | vermindern: zweite Kopie ausser Haus |
Mögliche Massnahmen
- git einrichten. Das bringt Versionsgeschichte, zeilengenaue Diffs jeder LLM-Änderung und Hashes als Integritätsprüfung. Es steht schon als Idee im Index.
- Versioniertes Backup nach 3-2-1: drei Kopien, zwei Medien, eine ausser Haus. Snapshots auf dem NAS decken einen Teil davon ab.
- Klassifikation der Inhalte: Besonders schützenswerte Personendaten (Gesundheit u.ä., siehe Datenschutz Schweiz) eher nicht in den Vault legen oder bewusst entscheiden, welche Ordner Claude lesen darf.
- Lint als festen Rhythmus etablieren, wie ein Audit.
Keine dieser Massnahmen wurde umgesetzt. Sie sind Vorschläge. Werkzeuge werden laut Schema nur nach Rückfrage eingeführt.
Veröffentlichung und Container (Ergänzung 2026-09-27)
Die Webseite site/ wird nach jedem Build mit robocopy /MIR auf den NAS-Share web/wiki gespiegelt (siehe CLAUDE.md). Auch das ist eine Synchronisation und kein Backup: Wird eine Seite gelöscht, verschwindet sie auch auf dem NAS. Weil site/ jederzeit aus wiki/ neu gebaut werden kann und im Git liegt, ist das hier unkritisch. Die Webseite ist nur ein Abbild, die Wahrheit liegt im Repository.
Die frühere, derzeit ungenutzte Docker-Variante in deploy/ zeigt dieselbe Denkweise (Docker Compose, Quelle - Docker Bootcamp):
- Ein Container holt den Stand aus GitLab mit einem Deploy-Token, das nur lesen darf, ein zweiter liefert die Seite aus und hängt die Daten nur lesend ein (
:ro). Das ist das Prinzip der minimalen Rechte (siehe Zugriffskontrolle). - Das Token steht in
deploy/.env, die nie committet wird. Die Quelle warnt, dass Werte ausENVundARGin Images sichtbar bleiben (siehe Dockerfile). - Container sind wegwerfbar und entstehen aus der Beschreibung neu. Ins Backup gehört deshalb nur, was in Volumes und im Repository liegt, nicht der Container selbst (siehe Container).
Der Abschnitt „Mögliche Massnahmen“ oben stammt vom 2026-09-24. Git mit Push auf das private GitLab ist inzwischen eingerichtet (siehe Index und Log), die Aussage „Keine dieser Massnahmen wurde umgesetzt“ ist also teilweise überholt. Ein versioniertes Backup ausserhalb des GitLab-Servers ist weiterhin offen. Eine gründliche Überarbeitung dieser Seite wäre eine Aufgabe für den nächsten Lint.
Offene Fragen
- Welche SynologyDrive-Versionierung bzw. welche NAS-Snapshots sind aktiv, und wie lange reichen sie zurück?
- Welche Inhalte sollen grundsätzlich nicht in den Vault?
Verwandt
- Informationssicherheit – Schutzziele und Grundsätze, auf die sich diese Seite stützt
- Datenhoheit – das persönliche Gegenstück: Kontrolle über die eigenen Daten
- LLM Wiki – das Muster, dessen Sicherheit hier betrachtet wird
- Zweites Gehirn – was hier geschützt werden soll
- Wiki-Operationen – Lint als Audit, Log als Protokoll
- Business Continuity Planning – Backup, RPO und RTO
- Risikoanalyse – Methode der Risikotabelle
- Wissensrepräsentation damals und heute – die andere Synthese, die Studienwissen auf das Wiki überträgt
- Docker Compose – die frühere Docker-Variante zur Veröffentlichung des Wikis
- Container – was bei Containern ins Backup gehört