Sicherheits-Whitepaper

Einleitung und Zielsetzung

JurShare deckt jene Datenwege einer Anwaltskanzlei oder eines Notariats 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.

Datenhaltung & Löschung

4.1 Wie das technisch funktioniert

Hochgeladene Dateien werden in einer dedizierten Dateiablage auf dem Server in der Schweiz gespeichert, getrennt von der Datenbank mit Konto- und Metadaten. Für jede Datei berechnet JurShare beim Hochladen eine SHA-256-Prüfsumme.

4.2 Was bedeutet das für die Praxis

• Kurze Lebensdauer: Vertrauliche Inhalte liegen nur für die Dauer der Übermittlung auf dem Server – nicht Monate oder Jahre wie in einem Postfach.
• Keine Auswertung: Inhalte werden weder analysiert noch indexiert noch für das Training von KI-Modellen verwendet. Die einzige automatische Verarbeitung ist die Virenprüfung.
• Nachweis ohne Inhalt: Das Zugriffsprotokoll belegt, wer wann welche Fassung erhalten hat, ohne die Dokumente selbst aufzubewahren.
• Übernahme in die Akte: Eingereichte Unterlagen sollten vor Ablauf einer Dokumentenanfrage in die Kanzleiakte übernommen werden – danach sind sie gelöscht.

Persistente Daten – also Konto-Stammdaten, Konfigurationen, Vertragsmetadaten und Audit-Logs – werden separat in einer relationalen Datenbank gehalten. Sie enthält keine Dokumentinhalte.

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.
• 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 Volumes für Dateiablage und Datenbank möglich.
• 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

Dateiablage und Datenbank (Konto-Stammdaten, Konfigurationen, Audit-Logs) liegen auf mit AES-256 verschlüsselten Datenträgern. Die Schlüssel werden getrennt von den Daten verwaltet.

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-Speicherung: Konto- und Freigabe-Passwörter werden ausschliesslich als Argon2-Hash gespeichert, nie im Klartext.
• Zwei-Faktor-Anmeldung via TOTP (RFC 6238) mit jeder gängigen Authenticator-App.
• Session-Management: HTTP-only-Cookies; Zugriffstoken mit 15 Minuten Lebensdauer; das Erneuerungstoken ist SameSite-Strict und nur für den Erneuerungs-Endpunkt gültig.
• Brute-Force-Schutz: Argon2 macht jeden Rateversuch teuer; Bestätigungscodes verfallen nach fünf Fehlversuchen; wiederholte Angriffsmuster sperrt fail2ban auf Server-Ebene.
• Zugriff für Administrierende der Swissmakers GmbH erfolgt ausschliesslich über Zwei-Faktor-Authentifizierung, separate Admin-Konten und nur über VPN aus festgelegten IP-Bereichen.
• Strikte Trennung: Jedes Konto sieht ausschliesslich die eigenen Freigaben, Dokumentenanfragen und Zugriffsprotokolle.
• Outlook-Add-in: erhält einen eigenen, widerrufbaren Zugangsschlüssel, der nur Freigaben des eigenen Kontos verwalten darf – ohne Administrationsrechte. Eine Passwortänderung trennt alle Verbindungen.
• 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:

• Nicht erratbare Links: Freigabe-Links enthalten eine 16-stellige Zufallskennung (rund 95 Bit), Upload-Links für Dokumentenanfragen eine zufällige UUID. Durchprobieren ist praktisch aussichtslos.
• Ablaufdatum: Frei wählbar bis höchstens 90 Tage. Nach Ablauf ist der Link ungültig; der stündliche Löschlauf entfernt Freigabe und Dateien.
• Maximale Aufrufe: Optional kann die Anzahl Zugriffe begrenzt werden.
• Passwortpflicht: Jede Freigabe verlangt ein Passwort, das über einen separaten Kanal übermittelt wird (Out-of-Band). Das gilt auch für Freigaben aus dem Outlook-Add-in.
• Vorschau im Browser – Dokumente wie PDF oder Bilder lassen sich ansehen, ohne sie als Datei zu speichern.
• Sofortiger Widerruf: Die Kanzlei kann jede Freigabe mit einem Klick löschen – der Link ist ab diesem Moment ungültig.
• Optionale Empfänger-Verifizierung: Empfangende bestätigen vor dem Zugriff einen sechsstelligen Code, der an ihre E-Mail-Adresse geht (gültig 10 Minuten, höchstens fünf Versuche). Die verifizierte Adresse erscheint im Zugriffsprotokoll.
• Keine Indexierung: Sharing-Seiten sind mit noindex gekennzeichnet, 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 geteilt werden kann – bei Freigaben der Kanzlei ebenso wie bei Uploads der Mandantschaft und bei Nachreichungen:

• ClamAV mit laufend aktualisierten Signaturen als Prüf-Engine.
• Prüfung direkt nach dem Upload: Jede Datei wird unmittelbar nach dem Hochladen an den Scanner gestreamt. Das Ergebnis erscheint pro Datei: «Unbedenklich» oder der erkannte Befund.
• Blockierung: Solange eine Datei infiziert ist oder noch geprüft wird, lässt sich die Freigabe nicht abschliessen. Betroffene Dateien können entfernt und die übrigen geteilt werden.
• Archive: ClamAV prüft auch den Inhalt gängiger Archivformate wie ZIP.
• Prüfsiegel: Sind alle Dateien einer Freigabe geprüft und unbedenklich, sehen die Empfangenden den Hinweis «Mit ClamAV geprüft und keine Bedrohungen gefunden».

Die Erreichbarkeit des Scanners wird laufend überwacht. Dateien, die – etwa während einer Störung – nicht geprüft werden konnten, erhalten kein Prüfsiegel.

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

Jeder Zugriff auf eine Freigabe wird mit Zeitstempel, IP-Adresse sowie Browser, Betriebssystem und Gerät protokolliert und ist im Konto einsehbar – pro Freigabe und als Gesamtübersicht, exportierbar als CSV und druckbar als PDF:

• Erstellen einer Freigabe
• Öffnen einer Freigabe durch Empfangende
• Passwortabfrage – erfolgreich oder fehlgeschlagen
• Vorschau und Download einzelner Dateien, jeweils mit SHA-256-Prüfsumme
• Download der gesamten Freigabe als ZIP
• Bei aktiver Empfänger-Verifizierung: die bestätigte E-Mail-Adresse der zugreifenden Person

Einträge bleiben auch nach Ablauf oder Löschung der Freigabe erhalten. Auf Wunsch benachrichtigt JurShare die Kanzlei per E-Mail, sobald eine Freigabe geöffnet oder heruntergeladen wird.

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 gemäss interner Aufbewahrungsrichtlinie, orientiert an etablierter Industriepraxis.

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.
• Kein Speicherort im EU-Ausland: Auch innerhalb der EU bzw. des 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: Dokumente sind befristet und sollen mit Ablauf der Freigabe unwiderruflich verschwinden – auch aus Sicherungskopien. 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 und Notariate relevanten rechtlichen und technischen Rahmenbedingungen entwickelt:

Eine separat dokumentierte Auftragsverarbeitungsvereinbarung (AVV) regelt das Verhältnis als Auftragsbearbeiterin gegenüber der Kanzlei (verantwortliche Stelle). Sie ist öffentlich einsehbar und kann direkt mit dem Vertragsabschluss übernommen werden.

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
• 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 eine 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.