Sicherheits-Whitepaper

Einleitung und Zielsetzung

JurShare deckt jene Datenwege einer Anwaltskanzlei ab, die nicht über die Justizplattform justitia.swiss laufen: Mandantschaft, Gegenparteien, Versicherungen, Notariate, Banken, Treuhand, kooperierende Kanzleien. Diese Vertraulichkeit erfordert ein Sicherheitsniveau, das deutlich über dem typischer Cloud-Filesharing-Anbieter liegt.

Dieses Whitepaper beschreibt offen, wie wir bei der Swissmakers GmbH dieses Sicherheitsniveau technisch und organisatorisch umsetzen. Es richtet sich an:

• IT-Sicherheitsverantwortliche und Datenschutzberatende, die JurShare evaluieren;
• Kanzleiführungen, die die Compliance-Tauglichkeit beurteilen müssen;
• Auditoren und Aufsichtsbehörden, die Nachweise zur Schutzwirkung verlangen;
• technisch interessierte Anwältinnen und Anwälte, die wissen wollen, wo ihre Akten landen.

Sicherheitsprinzipien

Sechs Grundsätze ziehen sich durch jeden technischen Entscheid bei JurShare:

Architektur im Überblick

JurShare ist eine bewusst schmal gehaltene Plattform. Statt ein riesiges Microservice-Geflecht bauen wir auf wenige, gut verstandene Komponenten - und schützen jede einzelne von ihnen.

Die folgenden Abschnitte beleuchten jede Schicht im Detail - von unten nach oben.

In-Memory-Datenhaltung — das Herzstück

4.1 Wie das technisch funktioniert

Das Herzstück ist ein dezidiert konfigurierter Redis-Server, der innerhalb des Podman-Containers läuft. Redis ist primär ein In-Memory-Datenstore - wir konfigurieren ihn so, dass er ausschliesslich in dieser Eigenschaft betrieben wird:

4.2 Was bedeutet das für die Praxis

• Kompromittierung der Festplatte hilft Angreifern nichts - die vertraulichen Inhalte sind dort schlicht nicht.
• Stilllegung eines Servers bedeutet automatisch das Ende aller Inhaltsdaten. Kein Risiko durch ausrangierte Disks.
• Backup-Snapshots der Disk enthalten keine Mandantsdokumente.
• Forensische Wiederherstellung aus Disk-Images ist nicht möglich.
• Behördliche Datenherausgabe kann Inhalte nur dann erreichen, wenn sie zum Zeitpunkt der Anordnung gerade aktiv im RAM liegen - was die Angriffsfläche erheblich reduziert.

Persistente Daten - also Konto-Stammdaten, Konfigurationen, Vertragsmetadaten und Audit-Logs - werden separat in einer verschlüsselten relationalen Datenbank gehalten. Diese enthält jedoch keine Inhaltsdaten.

Betriebssystem & SELinux

Die Server-Basis ist Rocky Linux 10 - eine binärkompatible, Community-getragene Distribution mit langem Support-Zyklus, hoher Stabilität und transparenter Update-Politik. Wir setzen Rocky bewusst statt einer kommerziellen Distribution ein, weil wir keine Kompromisse bei Lizenz- oder Subscription-Fragen wollen.

5.1 SELinux im Enforcing-Modus

SELinux (Security-Enhanced Linux) ist auf jeder Server-Instanz im Modus enforcing aktiviert - nicht permissive, nicht disabled. Das bedeutet: Selbst wenn ein Angreifer die JurShare-Anwendung kompromittieren könnte, kann der kompromittierte Prozess nur jene Aktionen ausführen, die seine SELinux-Policy ihm explizit erlaubt.

Konkret heisst das:

• Der JurShare-Prozess kann nur auf Verzeichnisse zugreifen, die mit dem entsprechenden Type-Label versehen sind.
• Der Redis-Prozess kann nicht auf das Dateisystem schreiben - das wird durch die Policy unterbunden, nicht nur durch Konfiguration.
• Versuche, ungewöhnliche Operationen auszuführen, werden im audit.log protokolliert.
• Auch ein root-Prozess innerhalb eines kompromittierten Containers ist durch die SELinux-Domäne eingeschränkt.

5.2 Weitere OS-Härtung

• Minimale Installation: Nur explizit benötigte Pakete, keine GUI, keine Office-Tools, kein Compiler auf produktiven Maschinen.
• Kernel-Härtung: sysctl-Parameter für Netzwerk-Stack-Hardening, ASLR im Maximal-Modus, Kernel-Module-Loading restriktiv konfiguriert.
• SSH-Zugang: Nur über öffentlichen Schlüssel, kein Passwort-Login, kein Root-Login, MFA für Admin-Sessions.
• Firewalld als Host-Firewall mit Default-Deny-Politik; nur explizit benötigte Ports sind offen.
• fail2ban als Intrusion-Detection-System (IDS): wertet Server- und Anwendungs-Logs in Echtzeit aus und blockiert wiederholte Angriffsmuster automatisch via Firewall-Regel.
• Auditd protokolliert sicherheitsrelevante Systemereignisse separat vom Anwendungs-Log.

Containerisierung mit Podman

Die JurShare-Anwendung läuft nicht direkt auf dem Host, sondern in einem isolierten Container. Wir verwenden bewusst Podman statt Docker - aus mehreren Gründen.

6.1 Warum Podman

• Rootless by Default: Podman benötigt keinen privilegierten Daemon. Der Container-Prozess läuft mit den Rechten eines unprivilegierten Users.
• Kein zentraler Daemon als Single Point of Failure und als Angriffsfläche.
• Native systemd-Integration für sauberes Lifecycle-Management.
• OCI-konform, austauschbar, ohne proprietäre Lock-Ins.

6.2 Container-Härtung im Detail

• Read-only Root-Filesystem: Der Container läuft mit --read-only. Schreibzugriffe sind nur auf explizit eingerichtete tmpfs-Volumes möglich - diese liegen wiederum nur im RAM.
• Capabilities reduziert: Wir starten den Container mit --cap-drop=ALL und fügen nur die zwingend nötigen Capabilities hinzu.
• Kein Privileged-Mode: niemals --privileged. Niemals.
• Seccomp-Profile beschränken die zugänglichen Syscalls auf das unbedingt Notwendige.
• User-Namespace-Mapping: Selbst ein root-Prozess im Container ist auf dem Host ein unprivilegierter User.
• Reproducible Builds: Container-Images werden aus signierten Quellen reproduzierbar gebaut. Die Bild-Digests werden protokolliert.
• Image-Scanning: Vor dem Deployment werden Images auf bekannte Schwachstellen gescannt.
• Immutable Deployment: Container werden nicht modifiziert, sondern als Ganzes ersetzt. Patches führen zu neuen Images, nicht zu in-place Updates.

Zusätzlich greift hier die SELinux-Policy aus § 5 auch innerhalb des Container-Kontexts - ein doppelter Boden.

Kryptografie & Verschlüsselung

7.1 Verschlüsselung in transit

7.2 Verschlüsselung at rest

Daten, die der Persistenz bedürfen (Konto-Stammdaten, Konfigurationen, Audit-Logs), werden mit AES-256 verschlüsselt - sowohl auf Volume- als auch auf Anwendungs-Ebene. Schlüsselverwaltung erfolgt über ein internes Key-Management-System mit klarer Trennung zwischen Anwendungs- und Schlüsselzuständigkeiten.

7.3 Passwort-Schutz

Benutzerpasswörter werden mit modernen, speicherharten Hash-Verfahren (Argon2id mit konservativen Parametern) gehasht. Salt pro Eintrag, kein gemeinsamer Pepper-Leak-Vektor. Datenfreigaben mit Passwortschutz nutzen den gleichen Standard.

7.4 Schlüsselrotation

Verschlüsselungsschlüssel werden in regelmässigen Abständen rotiert. Bei Verdacht auf Kompromittierung erfolgt die Rotation sofort und ohne Diskussion.

Authentifizierung & Zugriff

• Passwort-Anforderungen: Mindestens 12 Zeichen, Prüfung gegen kompromittierte Passwortlisten (HIBP-Hashes), keine Pflicht zur willkürlichen Komplexität - Länge schlägt Sonderzeichen.
• Multi-Factor Authentication verfügbar via TOTP (RFC 6238) und WebAuthn-Sicherheitsschlüssel.
• Session-Management: Sichere, HTTP-only, SameSite-Strict Cookies. Kurze Lebensdauer, Idle-Timeout, geräte-gebundene Renewals.
• Brute-Force-Schutz: Adaptive Verzögerung, Account-Lockout nach mehreren Fehlversuchen, IP-basierte Rate Limits.
• Zugriff für Administrierende der Swissmakers GmbH erfolgt ausschliesslich über zwei-Faktor-Authentifizierung, separate Admin-Konten und nur über VPN aus festgelegten IP-Bereichen.
• Rollenbasierte Zugriffe (RBAC) innerhalb einer Kanzlei: Owner, Admin, Mitarbeitende mit klar definierten Rechten.
• Audit-Trail jedes administrativen Zugriffs (siehe § 13).

Sicherheit der Sharing-Links

Datenanfragen und Datenfreigaben sind das, was Empfangende konkret zu Gesicht bekommen. Diese Links werden besonders abgesichert:

• Hochentropische Token: Jeder Link enthält einen kryptographisch zufälligen Token mit ausreichender Entropie, um Brute-Force praktisch unmöglich zu machen.
• Ablaufdatum (TTL): Standardmässig 7 Tage, konfigurierbar zwischen 24 Stunden und 90 Tagen. Nach Ablauf ist der Link schlicht ungültig - nicht „deaktiviert", sondern technisch nicht mehr existent.
• Maximale Aufrufe: Optional kann die Anzahl Zugriffe begrenzt werden.
• Optionaler Passwortschutz: Zusätzliches Passwort, das auf separatem Kanal kommuniziert wird (Out-of-Band).
• Vorschau ohne Download - sensitive Dokumente können angesehen werden, ohne dass eine lokale Kopie auf dem Empfangsgerät landet.
• Sofortiger Widerruf: Die Kanzlei kann jeden Link mit einem Klick deaktivieren - die Token werden im Redis sofort invalidiert.
• Keine Indexierung: Sharing-URLs enthalten noindex-Header, werden nicht in Sitemaps geführt, und Suchmaschinen werden aktiv ausgeschlossen.

Schadsoftware-Prüfung

Jede über JurShare hochgeladene Datei wird automatisch auf Schadsoftware geprüft, bevor sie für den Download freigegeben wird:

• ClamAV mit täglich aktualisierten Signaturen als primäre Engine - derselbe Standard, den auch die Justitia-4.0-Plattform justitia.swiss verlangt.
• Erkennung im Streaming: Dateien werden während des Uploads gescannt, ohne den Upload-Vorgang spürbar zu verlangsamen.
• Automatische Quarantäne: Erkannte Treffer werden sofort blockiert; weder Empfangende noch Kanzlei erhalten die infizierte Datei.
• Hash-Reputation: Bekannt bösartige Datei-Hashes werden bereits beim Upload abgewiesen.
• Datei-Typen: Eine Allowlist erlaubt typische Kanzlei-Dateien (PDF, DOCX, XLSX, Bildformate, ZIP); ausführbare Dateitypen sind eingeschränkt.
• Archive-Inspection: ZIP- und ähnliche Container werden inspiziert, ohne sie auszupacken - sogenannte Zip-Bomben werden erkannt und abgewiesen.

Bei einem Treffer informieren wir die hochladende Person mit einer freundlichen, aber bestimmten Meldung - ohne Details zur erkannten Signatur, um Reverse-Engineering zu erschweren.

Netzwerk- & Edge-Sicherheit

• Web Application Firewall (WAF) auf der Edge filtert Angriffe gemäss OWASP Top-10 (SQL-Injection, XSS, Command-Injection, Path-Traversal etc.) und verfolgt eine Default-Deny-Politik.
• DDoS-Schutz auf Netzwerk- und Anwendungsebene; Verkehrsmuster werden kontinuierlich analysiert.
• Rate Limiting pro IP, pro Konto und pro Endpunkt.
• Bot-Mitigation: Verdächtige Automatisierung wird identifiziert und ausgebremst.
• IP-Whitelisting für Admin-Zugänge: Administrative Schnittstellen sind von aussen nicht erreichbar.
• Netzwerk-Segmentierung: Anwendungs-, Datenbank- und Management-Netze sind physisch oder logisch getrennt.
• Egress-Filtering: Der JurShare-Container darf nicht beliebig nach aussen kommunizieren - ausgehende Verbindungen sind explizit allowlisted.

Patch-Management

• Sicherheitsupdates des Betriebssystems werden, sobald von Rocky Linux verfügbar, in einem mehrstufigen Prozess (Test → Staging → Produktion) eingespielt - kritische Patches innerhalb von 24 Stunden, weniger kritische innerhalb von 7 Tagen.
• Container-Images werden regelmässig neu gebaut - idealerweise nächtlich - um die jeweils aktuellen Basisschichten zu enthalten.
• Anwendungs-Abhängigkeiten werden durch ein automatisches Dependency-Audit überwacht. Bekannte Schwachstellen (CVEs) werden zeitnah adressiert.
• Zero-Day-Bedrohungen erhalten ausserplanmässige Hot-Fixes, sobald verlässliche Informationen oder Patches verfügbar sind.
• Patch-Logs dokumentieren, was wann von wem eingespielt wurde - revisionssicher.
• Rollback-Pfad: Jeder Patch kann im Fehlerfall innert Minuten zurückgenommen werden.

Logging, Monitoring & Audit

13.1 Audit-Log für die Kanzlei

Jede für Kanzleien sicherheitsrelevante Aktion wird mit Zeitstempel und IP-Adresse protokolliert und ist im Konto einsehbar:

• Logins und fehlgeschlagene Anmeldeversuche
• Erstellen, Ändern, Widerrufen von Datenanfragen und Datenfreigaben
• Erstmaliger Zugriff von Empfangenden auf einen Sharing-Link
• Upload eines Dokuments durch Empfangende
• Download eines Dokuments durch Empfangende
• Konto- und Berechtigungsänderungen innerhalb der Kanzlei

13.2 System-Monitoring

• SIEM (Security Information and Event Management): Sicherheitsrelevante Ereignisse aus Anwendung, Container, Host, fail2ban und SELinux laufen zentral auf, werden korreliert und auf Anomalien geprüft. Auslösende Ereignisse erzeugen Alarme an die Bereitschaft.
• Anomalie-Erkennung: Ungewöhnliche Last, ungewöhnliche Zugriffsmuster, ungewöhnliche Geo-Verteilung lösen Alarme aus.
• Server-Metriken werden kontinuierlich überwacht.
• Sicherheits-Logs (auditd, SELinux-Denials, fail2ban-Aktionen) fliessen in das SIEM und werden dort korreliert.
• 24/7-Bereitschaft für sicherheitsrelevante Alarme.
• Log-Aufbewahrung: Audit-Logs in der Kanzlei-Sicht 12 Monate (verlängerbar); System-Sicherheits-Logs nach SwissNIST-Praxis.

Hosting in der Schweiz - ohne Kompromiss

Die gesamte JurShare-Infrastruktur befindet sich physisch in der Schweiz, in einem Schweizer Rechenzentrum eines Schweizer Anbieters ohne Konzern-Verbindungen zu ausländischen Hyperscalern (Cloud-Dienstanbieter).

• Physische Sicherheit nach Standards des Rechenzentrumsbetreibers: Zutrittskontrolle, Videoüberwachung, redundante Stromversorgung, Brandschutz, Klimatisierung.
• Keine Hyperscaler: Wir nutzen weder AWS, Azure noch Google Cloud - auch nicht für Backups, Logs oder Monitoring.
• CLOUD-Act-Schutz: Da weder die Anbieterin noch der Hosting-Provider unter US-Jurisdiktion stehen, ist die Plattform dem US CLOUD Act nicht unterworfen.
• Schengen-Schutz: Auch innerhalb der EU/EWR werden keine Inhaltsdaten gespeichert.
• Souveränität in der Schweiz: Behördliche Zugriffe erfolgen ausschliesslich über schweizerische Rechtshilfe - mit allen damit verbundenen Schutzschritten.

Backup & Notfallwiederherstellung

15.1 Was wird gesichert

Wir sichern nicht die Inhaltsdaten - die existieren ausschliesslich im RAM und sollen das auch bleiben. Was wir sichern, sind:

• Konto- und Konfigurationsdaten (verschlüsselt)
• Audit-Logs (verschlüsselt)
• Vertrags- und Buchhaltungsdaten
• System-Konfigurationen für Wiederherstellung

15.2 Wie wir sichern

• Ausschliesslich in der Schweiz, an mehreren physisch getrennten Standorten.
• Verschlüsselt mit AES-256, Schlüsselverwaltung getrennt.
• 3-2-1-Regel: drei Kopien, zwei verschiedene Medien, eine Off-Site-Kopie.
• Regelmässige Wiederherstellungstests: Mindestens vierteljährlich wird die Wiederherstellung getestet.
• RTO / RPO: Recovery-Ziele definiert, dokumentiert und im Notfallplan hinterlegt.

15.3 Notfallplan

Ein dokumentierter Business-Continuity- und Disaster-Recovery-Plan beschreibt das Vorgehen bei Zwischenfällen verschiedener Schwere. Der Plan wird mindestens einmal jährlich getestet und aktualisiert.

Bedrohungen & Gegenmassnahmen

Die folgende Übersicht ordnet typischen Bedrohungsszenarien die jeweiligen Schutzschichten zu:

Compliance & Standards

JurShare wurde im Hinblick auf die für Schweizer Anwaltskanzleien relevanten rechtlichen und technischen Rahmenbedingungen entwickelt:

Eine separat dokumentierte Auftragsverarbeitungsvereinbarung (AVV) regelt das Verhältnis als Auftragsbearbeiterin gegenüber der Kanzlei (verantwortliche Stelle). Diese ist auf Anfrage erhältlich und wird auf Wunsch vor Vertragsabschluss zur Verfügung gestellt.

JurShare orientiert sich an den Sicherheitsanforderungen, die das Projekt Justitia 4.0 für die Plattform justitia.swiss definiert. Die Härtung von Betriebssystem, Container und Anwendung führen wir selbst durch. JurShare ist kein Ersatz für justitia.swiss und beansprucht nicht, dem BEKJ-Obligatorium zu unterstehen.

Vulnerability Disclosure

Wir nehmen verantwortungsbewusst gemeldete Sicherheitslücken sehr ernst.

• Meldekanal: security@jurshare.ch
• PGP-Schlüssel für vertrauliche Meldungen ist auf der Webseite hinterlegt.
• Safe Harbor: Forschende, die sich an die hier publizierten Regeln halten, müssen keine rechtlichen Konsequenzen befürchten.
• Reaktionszeiten: Empfangsbestätigung innerhalb von 72 Stunden, erste inhaltliche Antwort innerhalb von 7 Werktagen.
• Anerkennung: Mit Einverständnis der Meldenden führen wir ein Security Hall of Fame.

Was nicht erwünscht ist: Massen-Scanning ohne vorherige Absprache, Tests, die andere Nutzende beeinträchtigen, Tests gegen Produktionssysteme von Kanzleikunden ohne deren Zustimmung, Social-Engineering gegen Mitarbeitende, physische Tests.

Kontakt & Versionierung

Dieses Whitepaper wird regelmässig überarbeitet. Wesentliche Änderungen werden Bestandskunden per E-Mail mitgeteilt. Die jeweils aktuelle Version ist unter jurshare.ch/sicherheit abrufbar.