Sicherheit
Sicherheit von Oleafly Server
Oleafly Server ist der selbst gehostete Kollaborationsserver für die Oleafly-Desktop-App. Bevor Forschende an einem nationalen Labor oder einer Hochschule ihn nutzen können, muss ihn in der Regel ihr IT- oder Sicherheitsteam prüfen. Diese Seite ist für dieses Team geschrieben. Sie beschreibt, was der Server heute tut und was für den Einsatz in regulierten Umgebungen geplant ist.
Diese Seite behandelt den Server. Geht es nur um die Desktop-App, lesen Sie die Datenschutzseite.
Bereits umgesetzt
Was der Server jetzt tut
Selbst gehostet
Ihre Organisation betreibt den Server auf eigenen Rechnern oder im eigenen Cloud-Konto, mit Docker, Coolify, Render, Railway oder als einfachen Linux-Dienst. Projektdateien und Datenbank bleiben dort. Dateien lassen sich auf dem Datenträger oder in jedem S3-kompatiblen Speicher ablegen.
Keine Verbindungen nach außen
Der Server baut keine Netzwerkverbindungen nach außen auf, außer zu dem Anmeldeanbieter, den Ihre Organisation einrichtet.
Ihr Identitätsanbieter
Die Anmeldung erfolgt über den Identitätsanbieter Ihrer Organisation per OpenID Connect. Auch GitHub und E-Mail-Links funktionieren, ebenso ein Anmeldecode für Geräte, deren Browser nicht zur App zurückkehren kann.
Admins entscheiden, wer beitritt
Admins steuern über eine Zulassungsliste und Domainregeln, wer beitreten kann, und weisen jeder Person eine Rolle zu: Admin, Maintainer, Mitglied oder Gast. Gäste sehen nur die Projekte, zu denen sie eingeladen wurden, auf Wunsch erst nach Freigabe durch einen Admin.
Geräteschlüssel
Jedes Gerät hat einen eigenen Schlüssel, und Sitzungen sind an ihn gebunden. Ein kopiertes Token ist ohne diesen Schlüssel also nutzlos. Refresh-Tokens sind nur einmal verwendbar, und der Server erkennt eine Wiederverwendung. Wird ein Gerät abgemeldet, gilt das sofort, auch für bereits offene Verbindungen.
Signierte Änderungen
Das Gerät, das eine Änderung vornimmt, signiert sie. Der Server prüft, ob jede bearbeitende Identität zu dem Gerät gehört, das die Änderung signiert hat, und prüft Kommentarautoren auf dieselbe Weise. Projekt-Snapshots erstellt er selbst aus dem Protokoll signierter Änderungen, statt hochgeladenen Daten zu vertrauen.
Sicherheits- und Zugriffsprotokolle
Ein Sicherheitsprotokoll erfasst Anmeldungen, abgelehnte Anmeldungen, Admin-Aktionen und Geräteänderungen, jeweils mit der Client-Adresse. Projektinhaber können außerdem ein Zugriffsprotokoll führen, das zeigt, wer ihr Projekt geöffnet hat.
Container-Image und SBOM
Jedes Release enthält ein schlankes Container-Image ohne Shell, eine Software-Stückliste (SBOM) und Herkunftsnachweise zum Build.
Unabhängige Prüfungen
Unabhängige Prüfer haben Sicherheit, Leistung und Skalierbarkeit des Servers untersucht. Ihre Befunde wurden behoben, und für die Korrekturen gibt es Tests.
Geplant
Geplant für den Einsatz in regulierten Umgebungen
Manche Installationen brauchen mehr, als der Server heute leistet. Noch ist nichts aus diesem Abschnitt verfügbar. Wenn Ihre Prüfung von einem dieser Punkte abhängt, sagen Sie es uns, wenn Sie Kontakt aufnehmen. Das hilft uns zu entscheiden, was wir zuerst umsetzen.
FIPS-Modus
Im FIPS-Modus sollen TLS und Signaturen ein nach FIPS 140 validiertes kryptografisches Modul verwenden.
Verschlüsselte Projekte
Projektinhalte sollen auf den Geräten der Mitglieder verschlüsselt werden. Der Server soll dann nur versiegelte Änderungen weiterleiten und weder Texte noch Kommentare noch Dateien lesen können. Wird jemand entfernt, sollen die Schlüssel rotiert werden.
Strengere Prüfungen für Admins
Sensible Admin-Aktionen sollen vorher Touch ID, Windows Hello oder eine erneute Anmeldung verlangen. Geräteschlüssel sollen in der Secure Enclave oder einem TPM liegen. Jeder Admin soll eine E-Mail erhalten, wenn sich Rollen oder Einstellungen ändern, und Sie sollen Richtlinien für Sitzungen und Inaktivität festlegen können.
Audit-Export
Die Sicherheits- und Zugriffsprotokolle sollen als syslog oder JSON an Ihr SIEM gestreamt werden, mit Aufbewahrungseinstellungen und Legal Hold.
Verschlüsselung ruhender Daten
Datenbank und gespeicherte Dateien sollen mit Schlüsseln aus dem Schlüsselverwaltungsdienst Ihrer Organisation verschlüsselt werden.
SCIM-Provisionierung
Mitglieder sollen per SCIM aus Ihrem Identitätsanbieter provisioniert werden.
Installation ohne Internet
Es wird dokumentierte Schritte geben, mit denen sich der Server in einem Netzwerk ohne Internetzugang installieren lässt.
Sicherheitsdokumentation
Wir werden für den Server ein Bedrohungsmodell, einen Härtungsleitfaden, eine Matrix der geteilten Verantwortung und einen Prozess zur Offenlegung von Schwachstellen veröffentlichen, und ein Dritter wird einen Penetrationstest durchführen.
Kontakt
Sicherheitsprüfung oder Pilotprojekt anfragen
Wenn Ihr Team Oleafly Server prüft oder ein Pilotprojekt durchführen möchte, eröffnen Sie einen Thread in GitHub Discussions. Beschreiben Sie, was Ihre Prüfung erfordert, auch wenn es um geplante Punkte geht.
Sie haben eine Schwachstelle gefunden? Posten Sie sie nicht öffentlich. Melden Sie sie vertraulich über GitHub, wie in der Sicherheitsrichtlinie beschrieben.