Was Ihre Daten schützt — und was es noch nicht gibt

Direktnachrichten und Gruppen-Direktnachrichten sind Ende-zu-Ende mit MLS verschlüsselt, dem IETF-Standard RFC 9420, umgesetzt mit OpenMLS und einmal in Rust kompiliert, sodass jeder Client denselben kryptografischen Code ausführt. Jedes Gerät ist ein eigenes Mitglied der Gruppe: Ein Gerät hinzuzufügen ist sichtbar, und eines zu entfernen erzeugt neue Schlüssel für die Unterhaltung.

• Ein Schlüssel pro Gerät, nie einer pro Konto
• Forward Secrecy und Post-Compromise Security aus dem Protokoll, nicht aus einer Richtlinie
• Der Server betreibt die Zustellung und führt keine MLS-Kryptografie aus
• Cross-Signing der Geräte und Sicherheitsnummern zur Prüfung auf einem zweiten Weg
• Verschlüsseltes Schlüssel-Backup, damit ein verlorenes Gerät keine verlorene Historie ist
• Alles auf dem Transportweg über TLS; verwaltete Inhalte verschlüsselt gespeichert

Mehrere Organisationen teilen sich eine Installation, und keine Zeile wechselt zwischen ihnen. Die Organisation wird an einer einzigen Stelle durchgesetzt statt an jeder Aufrufstelle erinnert, und eine Anfrage nach dem Objekt einer anderen Organisation wird mit „nicht gefunden“ beantwortet statt mit „nicht erlaubt“ — denn „nicht erlaubt“ bestätigt, dass es das Objekt gibt.

• Eine aus dem OpenAPI-Dokument generierte Prüfsuite führt jede Operation über die Grenze aus
• 286 Operationen ausgeführt, 286 abgewiesen — und die Suite lässt den Build scheitern, wenn das zurückfällt
• Dateien und Audit-Einträge tragen die Organisation, zu der sie gehören
• Jede Metrik und jede Logzeile trägt die Organisations-ID, nie ihren Namen

Berechtigungen sind eine Bitmaske, die in der Datenschicht ausgewertet wird — eine nicht erteilte Fähigkeit ist also nicht bloß in der Oberfläche verborgen. Eine Organisation benennt eigene Rollen über dieser Bitmaske, und eine Rolle kann nie eine Berechtigung tragen, die ihre Urheberin selbst nicht hat. Damit ist der übliche Weg zur Rechteausweitung geschlossen.

• Genau eine Inhaberin je Organisation, übertragbar, durch eine Datenbankbedingung erzwungen
• Administratoren können sich keine Abrechnungsbefugnis erteilen; die hält allein die Inhaberin
• Berechtigungs-Überschreibungen je Kategorie, Kanal und Board
• Feldgenaue Berechtigungsauflösung im Modul Personen über sieben Rollen
• Bot-Konten und persönliche Zugriffstoken, begrenzt auf benannte Operationen

Die Kontrollen, auf die es nach dem Start ankommt und nicht bei der Unterschrift. Ratengrenzen gelten je Organisation und skalieren mit der Zahl der Sitzplätze, wobei jedes Mitglied auf einen Anteil am Ganzen begrenzt ist — eine außer Kontrolle geratene Integration kann das Budget also nicht für alle anderen aufbrauchen.

• Ratengrenzen je Organisation, mit Obergrenzen je Mitglied
• Speicherabrechnung und Verbrauchsnachweise je Organisation
• Aufbewahrung je Organisation konfigurierbar; die Voreinstellung behält Daten
• Vollständiger Datenexport der Organisation
• Audit-Log administrativer Handlungen, auf die Organisation begrenzt
• Uploads werden vor dem Öffnen auf Schadsoftware geprüft
• Linkvorschauen werden hinter SSRF-Schutz geladen, nie aus Ihrem Browser

Die Plattform-Steuerungsebene — der Teil, den unsere Betreiber benutzen — ist eine eigene Identität mit eigenen Sitzungen, eigenem Audit-Log und einer bewusst blinden Oberfläche: Sie kann Organisationen auflisten, eine sperren, eine Löschung planen und eine Bereinigung ausführen, und sie kann keine Inhalte lesen. Das erzwingt eine Build-Prüfung und kein Richtlinienpapier: Das Paket der Steuerungsebene darf nichts importieren, was Ihre Inhalte lesen kann, und die Continuous Integration scheitert, sobald sich das ändert.

• Betreiberkonten sind eigene Identitäten mit verpflichtender Mehr-Faktor-Anmeldung
• Die Steuerungsebene sieht Metadaten: Organisationen, Lebenszyklus, Anzahlen
• Eine Build-Prüfung verbietet der Steuerungsebene den Import inhaltslesenden Codes
• Es gibt keine Funktion zur Identitätsübernahme und keinen stillen Support-Zugriff
• Handlungen der Betreiber werden in ein eigenes Plattform-Audit-Log geschrieben

Enclessa selbst ist ein kommerzielles Produkt, sein Quelltext ist nicht veröffentlicht. Alles, worauf es läuft, ist quelloffen unter einer von der OSI anerkannten Lizenz, und das erzwingt eine Lizenzprüfung in der Continuous Integration, die den Build scheitern lässt, sobald eine Abhängigkeit ihre Lizenz wechselt. Mehrere sonst naheliegende Komponenten fehlen im Stack genau aus diesem Grund.

• Null Laufzeitabhängigkeiten ohne OSI-Lizenz, bei jedem Build geprüft
• Abhängigkeiten wöchentlich statt vierteljährlich aktualisiert
• PostgreSQL, NATS und LiveKit darunter — Komponenten, die Sie selbst prüfen können
• Die Kryptografie ist OpenMLS, eine auditierte quelloffene Umsetzung von RFC 9420