Sicherheitserklärung

Guard.ch öffnet verdächtige URLs in isolierten Cloud-Browsern. Die folgenden Massnahmen schützen dein Gerät und Netzwerk, trennen Untersuchungen voneinander und beschränken den Zugriff auf Konto- und Workspace-Daten.

• Langzeitspeicher: Hetzner, Helsinki (Finnland), EWR, für Konto- und Workspace-Daten und die Produktionsdatenbank; die Speicher-Volumes sind auf Blockebene verschlüsselt (siehe Abschnitt 3). Verschlüsselte Datenbank-Backups liegen im Objektspeicher von IDrive e2 in Frankfurt (Deutschland), EWR. Gespeicherte Browserprofile liegen in der dafür gewählten Region: bei der OVH SAS in Gravelines (Frankreich), EWR, oder bei der OVH Hébergement Inc. in Beauharnois (Kanada).
• Browser-Standorte: Europäische Union (Hetzner), Singapur, Salt Lake City (USA) und Beauharnois (Kanada). Der Standort wird so gewählt, dass die Verzögerung für dich möglichst gering ist.
• Isolation: Jede Untersuchung erhält einen eigenen Docker-Container mit einer frischen Dateisystem-Schicht und eigenen Prozess- und Netzwerk-Namespaces. Die Container sind so ausgelegt, dass sie keinen Zustand teilen. Der einzige Bind-Mount vom Host ist eine einzelne, nur lesbare Hostname-Datei.
• Datenübermittlung: Bei Untersuchungen auf Browser-Servern ausserhalb des EWR werden Sitzungsinhalte dorthin übermittelt. Dafür gelten die Standardvertragsklauseln und das von der Schweiz anerkannte Gegenstück gemäss Abschnitt 9 der Datenschutzerklärung.
• Lebenszyklus einer Untersuchung: Die Live-Analyse arbeitet ausschliesslich im Arbeitsspeicher und verarbeitet dort die Beobachtungen während der Untersuchung. Browserprofil, Cookies, Downloads, von der Person hochgeladene Dateien und Cache liegen im Container. Seine Arbeitsdateien liegen in overlayfs auf der Host-SSD. Eine Datei, die die Person auf ihr Gerät speichert oder von dort hochlädt, geht über den Proxy von Guard.ch direkt zwischen Gerät und Container und wird nirgends sonst abgelegt. Wenn die Untersuchung endet, entfernt der Server den Container und seine Arbeitsdateien; die Analyse im Arbeitsspeicher endet ebenfalls. Zwischen zwei Untersuchungen bleiben dort keine Sitzungsinhalte zurück. Ausnahme ist ein Browserprofil, das die Person speichern lässt: Es ist ein eigenes Dateisystem auf dem Dateispeicher seiner Region, wird für die Dauer der Sitzung eingebunden und an ihrem Ende wieder gelöst, sodass auf dem Server keine Kopie davon zurückbleibt.
• Festplattenverschlüsselung: Eine vollständige Festplattenverschlüsselung auf den Browser-Servern schreiben wir derzeit nicht vor. Die Datenbank in Helsinki ist auf Blockebene verschlüsselt, und Datenbank-Backups werden vor dem Hochladen verschlüsselt (siehe Abschnitt 3). Ist eine vollständige Festplattenverschlüsselung der Browser-Server für dein Unternehmen erforderlich, melde dich vor der Einführung bei legal@guard.ch, damit wir die Anforderung klären können.

Der Datenverkehr zwischen dir, dem Knoten, dem Anwendungs-Backend und der Datenbankschicht ist bei der Übertragung verschlüsselt. Die Volumes der Produktionsdatenbank und die Datenbank-Backups sind im Ruhezustand verschlüsselt.

• HTTPS: mindestens TLS 1.2, bevorzugt TLS 1.3, mit modernen Cipher-Suites auf unseren öffentlichen Endpunkten. TLS wird an unserer Proxy-Schicht terminiert.
• Browser-Streaming: Die Übertragung des Browserbilds und deiner Eingaben läuft über TLS-geschützte Verbindungen, die an unserem Proxy enden. Bei WebRTC sind die Medien zusätzlich mit DTLS-SRTP geschützt.
• Knoten zu Backend: Interne Aufrufe zwischen Browser-Knoten, Analysedienst und Backend laufen über TLS und werden mit einem Shared-Secret-Header (X-Edge-Secret) authentifiziert.
• Im Ruhezustand: Die Volumes in Helsinki, auf denen die Produktionsdatenbank liegt, sind auf Blockebene verschlüsselt. Datenbank-Backups werden verschlüsselt, bevor sie in den Objektspeicher in Frankfurt hochgeladen werden. Gespeicherte Browserprofile liegen auf dem Dateispeicher der für sie gewählten Region (OVH Public Cloud File Storage), den nur unsere Premium-Knoten über ein privates Netzwerk ohne TLS erreichen; eine eigene Verschlüsselung fügen wir diesen Profilen nicht hinzu.
• Secrets: pro Dienst bereitgestellt und auf das beschränkt, was der jeweilige Dienst braucht. Passwörter, Tokens und API-Schlüssel werden nie in Logs geschrieben.

Authentifizierung und Autorisierung erzwingt das Backend, nicht erst das Dashboard.

• Kunden-Authentifizierung: Zugangsdaten pro Konto. Passwörter werden mit bcrypt gehasht; unterstützt sind Passkeys (WebAuthn), die Anmeldung mit Google und Microsoft sowie SSO über OIDC pro Workspace. Passkeys lassen sich in den Kontoeinstellungen hinzufügen, sobald du angemeldet bist.
• Autorisierung: Der Zugriff auf eine laufende Untersuchung ist an das Konto und den Workspace gebunden, die sie gestartet haben. Bevor das Backend Untersuchungsdaten oder den Verlauf ausliefert, prüft es das zugehörige Konto. Lesezugriffe über Workspace-Grenzen hinweg weist es ab. Abrechnungsaktionen richten sich nach Workspace-Mitgliedschaft und Rolle.
• Interner Zugriff: Der Zugang zur Produktion ist auf den kleinstmöglichen Personenkreis beschränkt und wird nach dem Least-Privilege-Prinzip vergeben. Sicherheitsrelevante Vorgänge wie Kontolöschungen, Support-Zugriffe auf Konten und Schema-Migrationen protokollieren wir zentral in unserem eigenen Log-System auf von uns betriebenen Servern.
• 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.

Browser-Server und Datenbank sind voneinander getrennt. Ein Zugriff auf einen Browser-Server soll keinen Zugriff auf Kontodaten anderer Kunden eröffnen.

• Browser-Container besitzen keine Zugangsdaten für unsere Datenbank oder den dauerhaften Speicher. Steuerung und Streaming laufen über die Proxy-Schicht des Servers. Die Verbindung zwischen Container und Server wird mit einem geheimen Schlüssel authentifiziert.
• Die ausgehenden Verbindungen des Browser-Containers führen ins öffentliche Internet zu den untersuchten Websites.

• Abhängigkeitsprüfung: Wir legen die Versionen unserer Pakete fest und verfolgen Sicherheitshinweise zu Abhängigkeiten und Browser-Projekten.
• Patch-Richtlinie: Kritische Schwachstellen (CVEs) in öffentlich erreichbaren Komponenten wollen wir nach ihrer Bekanntgabe zügig beheben. Die Browser-Images (Chrome, Firefox, Brave, Edge, Opera, Tor, Vivaldi, Chromium) erstellen wir im regulären Release-Prozess auf Basis der jeweils neuesten stabilen Version des Browser-Anbieters neu.
• Externer Penetrationstest: Bisher haben wir keinen externen Penetrationstest abgeschlossen. Ein vollständiger externer Test ist für 2026 geplant. Nach Abschluss wollen wir die Ergebnisse hier zusammenfassen.
• Bug-Bounty: Ein öffentliches Bounty-Programm betreiben wir derzeit nicht. Wesentliche Funde können wir nach eigenem Ermessen im Einzelfall belohnen. Schick Meldungen an legal@guard.ch; es gelten die Responsible-Disclosure-Bedingungen in Abschnitt 10.

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: Überwachung rund um die Uhr mit automatischen Alarmen für Backend, Proxy, Edge-Agenten, Browser-Server und die Speicherumgebung in Helsinki. Logs werden in unserem eigenen Log-Speicher auf von uns betriebenen Servern gesammelt und in festem Rhythmus ausgewertet; schwerwiegende Ereignisse lösen automatische Alarme im Operations-Kanal aus.
• Kundenbenachrichtigung (Rolle als Auftragsverarbeiter): Betrifft eine Datenschutzverletzung Untersuchungsinhalte, die wir im Auftrag eines Kunden verarbeiten, benachrichtigen wir den betroffenen verantwortlichen Kunden unverzüglich, in jedem Fall innert 48 Stunden nach Bekanntwerden, wie im Auftragsverarbeitungsvertrag zugesagt.
• Aufsichtsbehörden: Wo Art. 33 DSGVO greift, melden wir die Verletzung der zuständigen Aufsichtsbehörde unverzüglich und nach Möglichkeit innert 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 die Verletzung 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 einen schriftlichen Bericht zu Ursachen und Folgemassnahmen erstellen und ihn betroffenen Kunden auf Anfrage zugänglich machen.

Den vollständigen Aufbewahrungsplan findest du in Abschnitt 7 der Datenschutzerklärung.

• Untersuchungsinhalte: bleiben bei allen Abonnements nur für die Dauer der Untersuchung bestehen. Danach wird keine Kopie aufbewahrt. Den Ablauf beschreibt Abschnitt 2.
• Untersuchungsdatensätze: URL, Zeitstempel und Status bleiben in der Datenbank mit dem zugehörigen Konto und Workspace verknüpft. Die Zugriffskontrollen beschreibt Abschnitt 4.
• Kontolöschung: Der Zugang endet, sobald die Löschung beantragt ist. Das Konto und seine gespeicherten Browserprofile werden 8 Tage nach dem Antrag gelöscht. Ein Workspace, dessen einziges Mitglied das Konto war, wird mit dem Antrag gelöscht oder, solange ein gekündigtes Abo noch bis zum Ende der bezahlten Laufzeit läuft, nach deren Ablauf. Untersuchungsdatensätze (URL, Zeitpunkte, Status) werden einen Monat nach dem Ende der Untersuchung gelöscht, also spätestens einen Monat nach dem Antrag. Verschlüsselte Backups laufen innert 35 Tagen aus.
• Backups: Nach der Löschung aus dem laufenden System werden die Daten spätestens innerhalb von 35 Tagen auch aus den Backups entfernt. Danach ist keine Wiederherstellung mehr möglich. Werden Daten vorher aus einem Backup wiederhergestellt, entfernt der nächste Bereinigungslauf die bereits gelöschten 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.

Hier unterscheiden wir zwischen bereits umgesetzten Massnahmen und geplanten Vorhaben. Zertifizierungen oder Audit-Ergebnisse nennen wir nur, wenn sie tatsächlich vorliegen.

• DSGVO und UK-DSGVO: Bei Daten von Websitebesuchern sowie Konto-, Abrechnungs- und Sicherheitsdaten handeln wir als Verantwortliche. Untersuchungsinhalte verarbeiten wir im Auftrag unserer Kunden. Für einen eng begrenzten Teil der Untersuchungsdaten handeln wir als eigenständige Verantwortliche: Das betrifft Daten zur Missbrauchsabwehr, zur Plattformsicherheit und zur Erfüllung rechtlicher Pflichten. Einzelheiten beschreibt Abschnitt 6.1 der Datenschutzerklärung. 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 wir es einhalten.
• SOC 2 Type II: Derzeit liegt kein SOC-2-Report vor. Eine entsprechende Prüfung ist geplant.
• ISO/IEC 27001: Eine Zertifizierung ist geplant. Derzeit sind wir nicht zertifiziert.
• Externer Penetrationstest: Den aktuellen Stand und den geplanten Test beschreibt Abschnitt 6.
• Unterauftragsverarbeiter: Die aktuelle Liste der Anbieter mit Zugriff auf Kundendaten findest du im Verzeichnis der Unterauftragsverarbeiter.

Meldungen von Sicherheitsforschenden sind 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 legal@guard.ch, 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. Du darfst die von Guard.ch selbst betriebenen Systeme in gutem Glauben auf Sicherheitslücken prüfen: die Website guard.ch, das Dashboard, die API sowie unsere Browser-Server und Datenbank-Infrastruktur. Dabei gelten folgende Bedingungen:

• Prüfe nur unsere eigenen Systeme. Ausgeschlossen sind Websites Dritter, die du in einer Untersuchung besuchst, unsere Unterauftragsverarbeiter und Hosting-Anbieter sowie Infrastruktur, die uns nicht gehört. Melde Schwachstellen auf Websites Dritter direkt deren Betreibern.
• Rufe nur die Daten ab, die du zum Nachweis der Schwachstelle zwingend brauchst. Kopiere und behalte auch nur diese Daten. Übertrage keine Kundendaten, die über das für einen minimalen Proof of Concept nötige Mass hinausgehen. Lösche alle zurückbehaltenen Daten, wenn wir dich dazu auffordern.
• Beeinträchtige den Dienst für andere Nutzer nicht. Verboten sind volumetrische Denial-of-Service-Angriffe und solche auf Anwendungsebene, Ressourcenerschöpfung und destruktive Tests. Dazu gehört auch automatisiertes Scanning, das die Verfügbarkeit für andere spürbar beeinträchtigt.
• Setze kein Social Engineering gegen unsere Mitarbeitenden, Kunden oder Anbieter ein.
• Führe keine physischen Angriffe auf Räumlichkeiten, Hardware oder Rechenzentren durch.
• Gib uns vor einer Veröffentlichung angemessen viel Zeit, die Schwachstelle zu beheben.

Sicherheitsmeldungen, Fragen zu dieser Seite und Anfragen nach zusätzlicher Dokumentation schickst du an die folgende Adresse.

Sicherheitskontakt

legal@guard.ch

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, Unterauftragsverarbeiter, Impressum.