Sicherheitserklärung

Mit Guard.ch öffnen Analysten eine verdächtige URL in einem entfernten Wegwerf-Browser, ohne der Zielseite die eigene Workstation, das eigene Netzwerk oder die eigene Identität preiszugeben. Die Plattform ist auf drei konkrete Risiken ausgelegt: Die Zielseite greift den Analysten an (Drive-by-Exploits, Fingerprinting, Preisgabe der IP), ein Kunde sieht in die Daten eines anderen (Datenabfluss zwischen Workspaces, vermischte Aufzeichnungen, geteilter Speicher), und ein Angreifer, der einen einzelnen Edge-Knoten erreicht, arbeitet sich zu gespeicherten Beweisen vor. Die unten beschriebenen Kontrollen begegnen jedem dieser Szenarien. Wir benennen, was heute umgesetzt ist, und kennzeichnen, was auf der Roadmap steht.

Dauerhaft gespeichert werden Aufzeichnungen von Untersuchungen (Bildschirmaufzeichnungen, Ereignislogs, Metadaten), Kontodaten und die Produktionsdatenbank ausschliesslich in unserer primären Speicherumgebung in Helsinki, Finnland, innerhalb des Europäischen Wirtschaftsraums, gehostet bei Hetzner. Edge-Knoten in Singapur (SG), Salt Lake City (SLC) und Beauharnois (YUL) betreiben den Untersuchungs-Container, streamen den entfernten Browser zum Analysten und schreiben die Aufzeichnungsartefakte (MP4-Video, Ereignislog, Metadaten-Sidecar) für die Dauer der Untersuchung in das beschreibbare Dateisystem des Containers. Am Ende der Untersuchung werden die Artefakte nach Helsinki hochgeladen, und der Container wird zerstört. Zwischen zwei Untersuchungen überlebt auf einem Edge-Knoten keine Aufzeichnung, ausserhalb von Helsinki existiert nirgends eine dauerhafte Kopie einer Aufzeichnung, und repliziert wird nicht über mehrere Regionen.

• Langzeitspeicher: Hetzner, Helsinki (Finnland), EWR. Objektspeicher und Datenbank-Backups bleiben innerhalb dieser Umgebung. Die Speicher-Volumes sind auf Blockebene verschlüsselt (siehe Abschnitt 3).
• Edge-Knoten: SG, SLC, YUL. Jede Untersuchung läuft in einem eigenen Docker-Container mit frischer Dateisystem-Schicht und eigenen Prozess- und Netzwerk-Namespaces; der Container wird für genau eine Untersuchung erstellt und danach zerstört. Container sind so gebaut, dass sie keinen Zustand teilen, und der einzige Bind-Mount vom Host ist eine einzelne, nur lesbare Hostname-Datei.
• Lebenszyklus einer Untersuchung: Die Aufzeichnungsartefakte liegen in der beschreibbaren Schicht des Containers (/recording/session.mp4, /recording/session.jsonl, /recording/session.metadata.json) und werden während der Untersuchung alle 30 Sekunden dorthin geschrieben (Flush). Endet die Untersuchung (Timer abgelaufen, Event-Obergrenze erreicht oder ein expliziter /finalize-Aufruf), remuxt die Capture-Komponente das Video und übergibt alle drei Artefakte an den Proxy-Sidecar des Nodes, der sie über TLS in den Objektspeicher in Helsinki hochlädt. Anschliessend entfernt der Edge-Agent den Container samt seinen Volumes endgültig (erzwungenes Löschen), womit die beschreibbare Schicht verworfen wird. Browser-Profil, Cookies, Downloads und der Cache auf der Platte verschwinden mit. Zwischen zwei Untersuchungen bleibt auf dem Edge-Knoten nichts zurück.
• Festplattenverschlüsselung auf Edge-Knoten: Aufzeichnungsartefakte liegen für die Dauer der Untersuchung und des Upload-Fensters auf der beschreibbaren Schicht des Containers (overlayfs auf der Host-SSD). Eine Vollverschlüsselung der Festplatten auf der Edge-Ebene schreiben wir heute nicht vor; dauerhaft verschlüsselt gespeichert wird am Ziel in Helsinki, wo die Verschlüsselung auf Blockebene greift. Ist Festplatten-Vollverschlüsselung auf der Edge-Ebene eine Beschaffungsanforderung in deinem Umfeld, melde dich vor dem Onboarding bei [email protected], damit wir den Umfang klären können.
• Workspace-Bindung: Gespeicherte Aufzeichnungen sind an das Konto und den Workspace gebunden, aus denen sie stammen. Das Backend prüft Eigentum und das geltende Aufbewahrungsfenster, bevor es Replay-Zugriff gewährt; Lesezugriffe über Workspace-Grenzen hinweg werden im Backend abgewiesen, nicht erst im Dashboard.

Der Verkehr zwischen Analyst, Edge, Anwendungs-Backend und Speicherschicht ist bei der Übertragung verschlüsselt. Dauerhafte Speicher-Volumes sind im Ruhezustand verschlüsselt.

• HTTPS: mindestens TLS 1.2, bevorzugt TLS 1.3, mit modernen Cipher-Suites auf unseren öffentlichen Endpunkten. TLS terminiert an unserer Proxy-Schicht.
• Remote-Browser-Streaming: Streaming- und Eingabe-Verkehr des Analysten läuft über TLS-geschützte Verbindungen, die an unserem Proxy terminieren. Wo WebRTC als Transport dient, sind die Medien zusätzlich mit DTLS-SRTP geschützt.
• Edge zu Speicher und Backend: Aufzeichnungsartefakte werden über TLS in den Objektspeicher in Helsinki hochgeladen. Interne Aufrufe zwischen Edge-Ebene und Backend authentifizieren sich mit einem Shared-Secret-Header (X-Edge-Secret).
• Im Ruhezustand: Die Speicher-Volumes in Helsinki sind auf Blockebene verschlüsselt. Backups bleiben in der Helsinki-Umgebung und unterliegen derselben Verschlüsselung im Ruhezustand.
• Secrets: pro Dienst bereitgestellt und auf das beschränkt, was der jeweilige Dienst braucht. Passwörter, Tokens und API-Schlüssel landen nie in Logs.

Authentifizierung und Autorisierung erzwingt das Backend, nicht erst das Dashboard. Intern haben so wenige Personen Zugang zur Produktion wie praktisch möglich.

• Kunden-Authentifizierung: Zugangsdaten pro Konto. Passwörter werden mit bcrypt gehasht; unterstützt sind Passkeys (WebAuthn), die Anmeldung mit Google und Microsoft sowie OIDC Single Sign-on pro Workspace. Neue Konten können unter /auth/register einen Passkey registrieren; bestehende Konten fügen einen in den Kontoeinstellungen hinzu.
• Workspace-Autorisierung: Der Zugriff auf Aufzeichnungen, Exporte und Abrechnungsaktionen hängt an der Workspace-Mitgliedschaft und an der Rolle, die für jeden Nutzer hinterlegt ist, durchgesetzt im Backend.
• Interner Zugriff: Der Zugang zur Produktion ist auf den kleinstmöglichen Personenkreis beschränkt und wird nach dem Least-Privilege-Prinzip vergeben. Sensible Operationen (Kontolöschung, Aufzeichnungs-Export durch den Support, Schema-Migrationen) werden in unsere zentrale, extern gehostete Log-Pipeline geschrieben.
• Session-Tokens: opak, serverseitig widerrufbar und an das ausstellende Konto gebunden. Ein Token gewährt nur Zugriff auf die Workspaces, in denen sein Konto Mitglied ist.

Die Edge-Ebene und die Speicherebene sind bewusst getrennte Vertrauensgrenzen. Das Designziel: Ein Angreifer, der einen Edge-Knoten erreicht, kann die gespeicherten Beweise eines anderen Kunden nicht lesen.

• Browser-Container besitzen keine Zugangsdaten zum Objektspeicher. Uploads von Aufzeichnungen laufen über den Proxy-Sidecar des Nodes; dieser holt sich die Speicher-Zugangsdaten beim Start vom Backend und hält sie für private Schreibzugriffe auf den Objektspeicher im Arbeitsspeicher. Der Container authentifiziert seine Upload- und Abschluss-Aufrufe gegenüber dem Node mit einem nodeweiten Shared Secret.
• Lesezugriffe auf Aufzeichnungen vermittelt das Backend: Es prüft Workspace-Eigentum und das geltende Aufbewahrungsfenster, bevor es eine signierte, zeitlich begrenzte Replay-URL ausstellt.
• Aufzeichnungen liegen unter Präfixen pro Untersuchung und sind in der Datenbank an das besitzende Konto und den Workspace gebunden. Leseanfragen über Workspace-Grenzen hinweg weist das Backend ab.
• Das ausgehende Netzwerk des entfernten Browser-Containers ist das öffentliche Internet (das Ziel der Analyse). Der Container besitzt keine Zugangsdaten für die Speicherebene, und Steuer- und Streaming-Verkehr läuft über die Proxy-Schicht des Nodes.

Wir verfolgen Drittabhängigkeiten, wollen Sicherheits-Patches zügig einspielen, sobald relevante CVEs veröffentlicht werden, und bauen Container-Images in regelmässigem Takt neu, damit die laufenden Browser die Upstream-Fixes erhalten.

• Abhängigkeiten im Blick: Lockfiles sind gepinnt. Sicherheitshinweise für unsere Paket-Ökosysteme und die Upstream-Browser-Projekte werden beobachtet.
• Patch-Politik: Kritische CVEs auf Komponenten, die im Internet exponiert sind, wollen wir zügig nach Veröffentlichung beheben. Browser-Images (Chrome, Firefox, Brave, Edge, Opera, Tor, Vivaldi, Chromium) werden im normalen Release-Prozess gegen den neuesten stabilen Upstream neu gebaut.
• Penetrationstest durch Dritte: Einen externen Penetrationstest haben wir bis heute nicht abgeschlossen. Ein vollständiger externer Test steht für 2026 auf der Roadmap; sobald einer abgeschlossen ist, wollen wir die Ergebnisse hier zusammenfassen.
• Bug-Bounty: Ein öffentliches Bounty-Programm betreiben wir derzeit nicht. Substanzielle Funde können wir nach eigenem Ermessen im Einzelfall belohnen. Schick Meldungen an [email protected]; es gelten die Responsible-Disclosure-Bedingungen in Abschnitt 10.

Kritische Pfade (Backend, Proxy, Edge-Agents, Speicher) werden rund um die Uhr mit automatischen Alarmen überwacht. Betrifft ein bestätigter Sicherheitsvorfall Personendaten, greifen die unten beschriebenen Meldepflichten. Den gesetzlichen Rahmen beschreibt Abschnitt 17 der Datenschutzerklärung; die vertraglichen Zusagen gegenüber Kunden stehen im Auftragsverarbeitungsvertrag.

• Monitoring: automatische Alarme für Backend, Proxy, Edge-Flotte und die Speicherebene in Helsinki. Logs werden in einen externen Log-Speicher übertragen und in festem Rhythmus ausgewertet; Ereignisse hoher Schwere lösen automatische Alarme im Operations-Kanal aus.
• Kundenbenachrichtigung (Rolle als Auftragsverarbeiter): Bei Verletzungen, die Untersuchungsaufzeichnungen betreffen, die wir im Auftrag eines Kunden verarbeiten, benachrichtigen wir den betroffenen verantwortlichen Kunden ohne unnötige Verzögerung, in jedem Fall innert 48 Stunden nach Bekanntwerden, wie im Auftragsverarbeitungsvertrag zugesagt.
• Aufsichtsbehörden: Wo Art. 33 DSGVO greift, melden wir der zuständigen Aufsichtsbehörde ohne unnötige Verzögerung und nach Möglichkeit binnen 72 Stunden nach Bekanntwerden, ausser die Verletzung führt voraussichtlich nicht zu einem Risiko für betroffene Personen. Nach Art. 24 des Schweizer DSG melden wir dem EDÖB so rasch als möglich, wenn eine Verletzung voraussichtlich zu einem hohen Risiko für betroffene Personen führt.
• Nach dem Vorfall: Zu jedem bestätigten Sicherheitsvorfall wollen wir ein schriftliches Post-mortem erstellen und es betroffenen Kunden auf Anfrage zugänglich machen.

Aufzeichnungen bleiben nur so lange erhalten, wie sie dem Kunden nützen, der sie erstellt hat. Der massgebliche Aufbewahrungsplan, einschliesslich der Kriterien für Kategorien ohne festes Fenster, ist Abschnitt 7 der Datenschutzerklärung; die wichtigsten Fenster fassen wir hier zusammen.

• Aufbewahrung von Aufzeichnungen: 1 Tag für Free-Untersuchungen und daraus abgeleitete Artefakte; 1 Monat für Untersuchungen auf bezahlten Plänen und daraus abgeleitete Artefakte.
• Kontolöschung: Gespeicherte Aufzeichnungen, die zum Konto gehören, werden innert 1 Monat nach dem Löschantrag gelöscht.
• Backups: Backups laufen innert 35 Tagen nach der primären Löschung aus. Nach diesem Fenster ist keine Wiederherstellung mehr möglich; nach einer Wiederherstellung innerhalb des Fensters löscht der nächste Bereinigungslauf bereits bereinigte Daten erneut.
• Logs: Authentifizierungs-Logs bewahren wir 180 Tage auf, Anwendungs- und Zugriffs-Logs je nach Log-Klasse 30 bis 90 Tage; länger nur dort, wo es nötig ist, um Missbrauch zu untersuchen oder eine rechtliche Pflicht zu erfüllen.

Wir sagen offen, was heute steht und was noch in Arbeit ist. Nichts auf dieser Seite ist eine Zertifizierung, eine Attestierung oder ein Audit-Ergebnis, und wir behaupten auch keines.

• DSGVO und UK-DSGVO: Wir gestalten und betreiben den Dienst so, dass wir unsere Pflichten erfüllen. Für Besucher von guard.ch sowie für Konto-, Abrechnungs- und Sicherheitsdaten handeln wir als Verantwortliche, für die Untersuchungsinhalte, die Kunden aufzeichnen lassen, als Auftragsverarbeiter, und für einen schmalen Ausschnitt der Untersuchungsdaten, der der Missbrauchsabwehr, der Plattformsicherheit und der Rechtskonformität dient, als eigenständige Verantwortliche, wie in Abschnitt 6.1 der Datenschutzerklärung dargelegt. Die Bedingungen der Auftragsverarbeitung stehen in unserem Auftragsverarbeitungsvertrag.
• Schweizer DSG (revidiert, in Kraft seit 1. September 2023): Der Betreiber ist ein Schweizer Unternehmen; das DSG gilt unmittelbar für unsere Verarbeitung, und wir betreiben den Dienst so, dass er es einhält.
• SOC 2 Type II: Roadmap-Punkt. Wir sind nicht SOC-2-zertifiziert und besitzen keinen SOC-2-Report. Wir behaupten keinen, bevor es ihn gibt.
• ISO/IEC 27001: Roadmap-Punkt. Wir sind nicht ISO-27001-zertifiziert.
• Externer Penetrationstest: noch nicht abgeschlossen; für 2026 auf der Roadmap (siehe Abschnitt 6).
• Subprozessoren: Die aktuelle Liste der Anbieter mit Zugriff auf Kundendaten ist unter /legal/subprocessors veröffentlicht.

Meldungen von Sicherheitsforschenden sind uns willkommen; wir sind auf die Community angewiesen, um Lücken zu finden, die wir übersehen haben. Glaubst du, eine Schwachstelle in Guard.ch gefunden zu haben, melde sie an [email protected], bevor du Details veröffentlichst oder an Dritte weitergibst. Wir wollen Meldungen innerhalb von zwei Werktagen bestätigen und dich bis zur Behebung auf dem Laufenden halten.

Umfang der Autorisierung. Wir autorisieren Sicherheitsforschung in gutem Glauben gegen Systeme, die Guard.ch selbst betreibt (die Website guard.ch, das Dashboard, die API sowie unsere Edge- und Speicher-Infrastruktur), sofern die Forschung:

• sich ausschliesslich gegen unsere eigenen Systeme richtet, nicht gegen Drittwebsites, die in einer Untersuchung aufgezeichnet oder besucht werden, nicht gegen unsere Subprozessoren oder Hosting-Anbieter und nicht gegen Infrastruktur, die uns nicht gehört;
• nicht mehr Daten abruft, kopiert oder behält, als zwingend nötig ist, um das Problem zu belegen, keine Kundendaten über einen minimalen Proof of Concept hinaus exfiltriert, wobei behaltene Daten auf unsere Aufforderung hin gelöscht werden;
• den Dienst für andere Nutzer nicht beeinträchtigt (kein volumetrischer Denial of Service und keiner auf Anwendungsebene, keine Ressourcen-Erschöpfung, keine destruktiven Tests);
• kein Social Engineering gegen unsere Mitarbeitenden, Kunden oder Anbieter einsetzt;
• keine physischen Angriffe auf Räumlichkeiten, Hardware oder Rechenzentren umfasst; und
• uns ein angemessenes Zeitfenster für die Behebung lässt, bevor etwas öffentlich wird.

Vom Safe Harbour ausgenommen:

• Social Engineering gegen Mitarbeitende, Kunden oder Anbieter.
• Physische Angriffe auf Räumlichkeiten oder Rechenzentren.
• Denial-of-Service-Angriffe (volumetrisch oder auf Anwendungsebene).
• Automatisiertes Scanning, das die Verfügbarkeit des Dienstes für andere Nutzer spürbar beeinträchtigt.
• Funde auf Drittwebsites, die im entfernten Browser besucht wurden; sie gehören dem Betreiber der jeweiligen Website.

Sicherheitsmeldungen, Fragen zu dieser Seite und Anfragen nach zusätzlicher Dokumentation (Architektur-Notizen, Due Diligence zu Subprozessoren) gehen alle an die Adresse unten.

Sicherheitskontakt

[email protected]

PGP

PGP-Schlüssel auf Anfrage erhältlich.

Eingangsbestätigung

Wir wollen Meldungen innerhalb von zwei Werktagen nach Eingang bestätigen.

Betreiber

Zesiger.net

Postadresse

Veröffentlicht im Impressum

Verwandte Dokumente

Auftragsverarbeitungsvertrag, Datenschutzerklärung, Subprozessoren, Impressum.