Standardmäßig sicher.
An Ihr Risikoniveau anpassbar.

Nein. Der Schritt, der Ihre Dokumente durchsuchbar macht — Text in „Embeddings“ (Vektoren) umzuwandeln — ist der Teil, den Wettbewerber typischerweise an eine Drittanbieter-KI-API auslagern, was bedeutet, dass Ihre Dateiinhalte deren Gebäude verlassen. ReefOffice führt dieses Modell lokal aus: bge-m3 (ein mehrsprachiges, MIT-lizenziertes offenes Modell) in Ollama auf Ihrer eigenen VM. Die Vektoren und der Text werden in Qdrant gespeichert, ebenfalls auf Ihrer VM. Das Indexieren und Durchsuchen Ihres Korpus löst also nie einen ausgehenden KI-Aufruf aus — der Inhalt Ihrer Dokumente bleibt auf Ihrem Server. Bei Private-AI-Tarifen wird die Antwort von einem offenen Modell (standardmäßig Qwen oder ein europäisches Modell wie Mistral) auf einer ReefOffice-GPU in einem ISO-27001-zertifizierten Rechenzentrum in Deutschland erzeugt, unter Auftragsverarbeitungsvertrag — nur Ihre Frage und die passenden Ausschnitte werden dorthin gesendet, dort wird nichts gespeichert, und keine Dritt-KI ist jemals beteiligt. Der einzige Fall, in dem etwas hinausgeht, ist, wenn Sie auf einem Tarif ohne GPU bewusst Ihren eigenen externen KI-Schlüssel für geschriebene Antworten verbinden — und selbst dann werden nur Ihre Frage und die wenigen passenden Ausschnitte gesendet, nie das gesamte Korpus.

Die vorgefertigten Automatisierungen (Dokumentenindexierung, Rechnungsnachverfolgung, Vertragsablage, Auftrag-gewonnen-Einrichtung, …) laufen in einer nur dem Betreiber vorbehaltenen Automatisierungs-Engine, die ReefOffice verwaltet — nicht in Activepieces, dem No-Code-Builder, den Ihr Team nutzt. Die benötigten Zugangsdaten (Ihre Admin-Konten für Nextcloud / Dolibarr / Paperless, das Mail-Relay) werden verschlüsselt gespeichert und nur vom laufenden Job über dessen jobgebundene Laufzeit-Zugangsdaten gelesen; sie werden nie in eine Workflow-Definition geschrieben, die ein Nutzer öffnen kann. Wenn der private KI-Agent eine freigegebene Automatisierung startet, ruft er einen lokalen Allowlist-Shim auf, der die Zugangsdaten serverseitig injiziert, sodass der Agent nie allgemeine Zugangsdaten der Automatisierungs-Engine erhält. Ihr Activepieces-Sandkasten enthält keinerlei Betreiber-Zugangsdaten, und der Zugriff auf die Engine wird bei jedem Deployment betreiberseitig durchgesetzt, sodass ein veraltetes Konto keinen Zugriff behalten kann. Das schließt die Risikoklasse, bei der eine integrierte Automatisierung zum Mittel wird, ein Admin-Passwort auszulesen.

Richtig, und das ist beabsichtigt — LUKS ist das richtige Werkzeug für Bedrohungen der Daten im Ruhezustand (physische Laufwerke, Außerbetriebnahme und Snapshots, die kein Boot-Entsperrmaterial enthalten). Für einen laufenden Server wenden wir eine separate Schicht von Kontrollen an, die in jeden NixOS-Build integriert ist: ptrace ist eingeschränkt (scope=3), um Prozessinspektion zu verhindern, kexec ist deaktiviert, damit der Kernel zur Laufzeit nicht ersetzt werden kann, unprivilegiertes eBPF ist blockiert, Kernel-Zeiger sind verborgen (kptr_restrict=2), unprivilegiertes userfaultfd ist deaktiviert, unprivilegierte io_uring-Erstellung ist eingeschränkt, und Coredumps sind unterdrückt. Vollständige io_uring-Deaktivierung bleibt für spezielle gehärtete Deployments verfügbar, aber die Standardeinstellung erhält die Kompatibilität mit privilegierter Infrastruktur. Die Unveränderlichkeit von NixOS bedeutet, dass kein Paketmanager unbemerkt unerwartete Binärdateien installieren kann. Eine tägliche CVE-Prüfung (vulnix) erkennt verwundbare Pakete und meldet die Ergebnisse im Dashboard.

Ja — jeder Server führt eine tägliche CVE-Prüfung mit vulnix durch, einem NixOS-nativen Tool. Da NixOS exakte Paketversionen als kryptografische Hashes festschreibt (reproduzierbare Builds), kann vulnix jedes installierte Paket in Sekunden mit der National Vulnerability Database abgleichen. Die Ergebnisse erscheinen im Sicherheits-Tab Ihres Dashboards mit Paketname, Version und CVE-IDs. NixOS liefert in der Regel innerhalb von 24–48 Stunden nach einer CVE-Offenlegung ein gepatchtes Paket — die nächste tägliche Prüfung bestätigt die Behebung. Das ist etwas, das die meisten selbst gehosteten Stacks ohne erheblichen Werkzeugaufwand nicht leisten können; hier läuft es ab Werk.

Der Air-Gapped-Modus ist die vollständige Antwort — wir halten keinen SSH-Schlüssel, daher hat eine vollständige Kompromittierung unserer Infrastruktur keinen SSH-Weg zu Ihrer VM. Im Managed-Modus zeichnet das hash-verkettete Audit-Protokoll Steuerungsebenen-Vorgänge auf. Zusätzlich können Sie die optionale wöchentliche Zusammenfassungs-E-Mail in Ihren Kontoeinstellungen aktivieren: Sie fasst Dienst-Umschaltungen, NixOS-Update-Ergebnisse und CVE-Zahlen über Ihre Server hinweg zusammen — und gibt Ihnen eine regelmäßige, erwartete, leicht lesbare Bestätigung, dass nichts Unerwartetes passiert ist. Jede Anomalie in dieser Zusammenfassung ist ein frühes Signal, das vollständige Audit-Protokoll zu prüfen.

LUKS schützt das verschlüsselte Root-Dateisystem, wenn jemand Zugriff auf ein entferntes Root-Laufwerk oder einen Root-Disk-Snapshot ohne Boot-Entsperrmaterial erhält. ReefOffice nutzt unbeaufsichtigtes LUKS, damit Server automatisch neu starten können; dadurch sind Boot-Partition und initrd ein eigener Teil des Bedrohungsmodells. Ein vollständiges providerseitiges Image aus Boot- und Root-Speicher ist nicht dasselbe wie ein entferntes verschlüsseltes Root-Laufwerk. Die verbleibenden Pfade auf einer laufenden VM, etwa Hypervisor-Speicherzugriff oder Runtime-Zugriff, werden durch Provider-Kontrollen, Verträge und Audits geregelt, nicht durch LUKS.

Ein Angreifer müsste die laufende VM kompromittieren oder genügend Boot-Material und Festplattenzugriff erhalten, um das verschlüsselte Root-Dateisystem zu entsperren, und anschließend /etc/reefoffice/secrets.env lesen. Der Backup-Schlüssel befindet sich nie in der Datenbank der ReefOffice-Steuerungsebene. Wenn Ihre Compliance-Anforderung verlangt, dass der Backup-Schlüssel bei keiner VM-Kompromittierung erreichbar ist, entfernt der Zero-Knowledge-Modus ReefOffice nach der Übergabe aus der Verwahrung des Backup-Schlüssels.

Bei der ersten SSH-Verbindung nach der Bereitstellung zeichnet die Steuerungsebene den öffentlichen Host-Schlüssel der VM auf (Trust On First Use — TOFU). Jede weitere Verbindung prüft, ob der Schlüssel mit diesem Eintrag übereinstimmt. Eine Abweichung — die anzeigt, dass die VM ersetzt oder ein MITM eingefügt wurde — lässt die Verbindung sofort fehlschlagen und wird ins Audit-Log geschrieben. Das bedeutet, dass eine bösartige VM den Verwaltungsverkehr nicht unbemerkt abfangen kann, selbst wenn DNS oder IP-Routing kompromittiert sind.

Ihr Server läuft bei Contabo GmbH, einem 2003 gegründeten deutschen Hosting-Unternehmen mit eigenen Rechenzentren in München und Nürnberg — kein Reseller. Contabo betreut über 225.000 Kunden in 190 Ländern auf mehr als 450.000 Servern, und unabhängiges Monitoring durch HOSTtest verzeichnete 100 % Verfügbarkeit im Q3 2025 und Q4 2024. Contabo ist ein eingetragenes deutsches Unternehmen (Amtsgericht München, HRB 180722).