Sicherheitserklärung

Mit Guard.ch öffnet ein Team eine verdächtige URL in einem isolierten Cloud-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 an, wer sie geöffnet hat (Drive-by-Exploits, Fingerprinting, Preisgabe der IP-Adresse); ein Kunde sieht Daten eines anderen Kunden (Datenabfluss zwischen Workspaces, Zustand, der von einer Untersuchung in die nächste übergeht); und ein Angreifer, der einen einzelnen Knoten erreicht, arbeitet sich zu unserer Kontodatenbank vor. Die im Folgenden beschriebenen Kontrollen wirken genau diesen drei Risiken entgegen. Was eine Untersuchung sieht, wird nie gespeichert: Es besteht nur, solange sie läuft. Wir benennen, was heute umgesetzt ist, und kennzeichnen, was auf der Roadmap steht.

Dauerhaft gespeichert werden Kontodaten und die Produktionsdatenbank ausschliesslich in unserer primären Speicherumgebung in Helsinki, Finnland, innerhalb des Europäischen Wirtschaftsraums, gehostet bei Hetzner. Die Knoten, auf denen der Untersuchungs-Container läuft und die den Cloud-Browser zu dir streamen, stehen teils in der Europäischen Union (Hetzner), teils an Standorten ausserhalb des EWR: Singapur, Salt Lake City in den USA und Beauharnois in Kanada, ausgewählt nach der Latenz zur Person, welche die Untersuchung führt. Auf jedem dieser Knoten gilt: Was die Untersuchung sieht, besteht nur im Arbeitsspeicher und in diesem Container, solange sie läuft. Endet die Untersuchung, wird der Container zerstört und alles darin mit ihm. Nichts wird irgendwohin hochgeladen, nach dem Ende der Untersuchung existiert keine Kopie der Sitzungsinhalte mehr, dauerhafte Daten verlassen Helsinki nie, und es gibt keine Replikation über mehrere Regionen.

• Langzeitspeicher: Hetzner, Helsinki (Finnland), EWR. Die Produktionsdatenbank und ihre Backups bleiben innerhalb dieser Umgebung. Die Speicher-Volumes sind auf Blockebene verschlüsselt (siehe Abschnitt 3).
• Browser-Knoten: Europäische Union (Hetzner) sowie Standorte ausserhalb des EWR in Singapur, Salt Lake City (USA) und Beauharnois (Kanada), gewählt nach Latenz. 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 ausgelegt, dass sie keinen Zustand teilen, und der einzige Bind-Mount vom Host ist eine einzelne, nur lesbare Hostname-Datei. Ein Knoten ausserhalb des EWR hält Sitzungsinhalte flüchtig, solange die Untersuchung läuft, und nach ihrem Ende nichts mehr; für diese Übermittlungen gelten die Standardvertragsklauseln und das von der Schweiz anerkannte Gegenstück, wie in Abschnitt 9 der Datenschutzerklärung beschrieben.
• Lebenszyklus einer Untersuchung: Die Analyse-Spur hält im Arbeitsspeicher neben dem Browser, was sie beobachtet; Browser-Profil, Cookies, Downloads und der Cache auf der Festplatte liegen in der beschreibbaren Schicht des Containers. Beides besteht nur, solange die Untersuchung läuft. Endet sie (keine bestehende Verbindung mehr, Ablauf der maximalen Laufzeit oder ein explizites Beenden aus dem Dashboard), entfernt der Knoten-Agent den Container samt seinen Volumes endgültig, wodurch die beschreibbare Schicht verworfen wird, und die Analyse-Spur verschwindet mit dem Prozess, der sie gehalten hat. Nichts wird irgendwohin hochgeladen, und zwischen zwei Untersuchungen bleibt auf dem Knoten nichts zurück.
• Festplattenverschlüsselung auf den Knoten: Die Arbeitsdateien des Browsers (overlayfs auf der Host-SSD) bestehen nur für die Dauer der Untersuchung und werden mit dem Container entfernt; die Live-Analyse berührt die Festplatte gar nicht, weil sie im Arbeitsspeicher gehalten wird. Eine Festplatten-Vollverschlüsselung auf der Knoten-Ebene schreiben wir heute nicht vor; dauerhaft verschlüsselt wird in Helsinki, wo Datenbank und Backups auf Blockebene verschlüsselt sind. Ist Festplatten-Vollverschlüsselung auf der Knoten-Ebene eine Beschaffungsanforderung in deinem Umfeld, melde dich vor dem Onboarding bei [email protected], damit wir den Umfang klären können.
• Workspace-Bindung: Der Zugriff auf eine laufende Untersuchung ist an das Konto und den Workspace gebunden, die sie gestartet haben. Das Backend prüft die Zugehörigkeit, bevor es Zugriff gewährt; Lesezugriffe über Workspace-Grenzen hinweg werden im Backend abgewiesen, nicht erst im Dashboard.

Der Datenverkehr zwischen dir, dem Knoten, dem Anwendungs-Backend und der Datenbankschicht 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 wird an unserer Proxy-Schicht terminiert.
• 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.
• Knoten zu Backend: Interne Aufrufe zwischen den Browser-Knoten, dem Analysedienst und dem Backend laufen über TLS und authentifizieren sich mit einem Shared-Secret-Header (X-Edge-Secret). Zum Speicher wandern keine Sitzungsinhalte, weil keine gespeichert werden.
• Im Ruhezustand: Die Volumes in Helsinki, auf denen die Produktionsdatenbank liegt, 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 werden nie in Logs geschrieben.

Authentifizierung und Autorisierung erzwingt das Backend, nicht erst das Dashboard. Intern hat nur ein möglichst kleiner Personenkreis Zugang zur Produktion.

• 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.
• Workspace-Autorisierung: Der Zugriff auf eine laufende Untersuchung, auf den Untersuchungsverlauf und auf Abrechnungsaktionen richtet sich nach der Workspace-Mitgliedschaft und der für jeden Nutzer hinterlegten Rolle und wird im Backend durchgesetzt.
• 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, Support-Zugriff auf ein Konto, 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 Knoten mit den Browsern und die Ebene mit unserer Datenbank sind bewusst getrennte Vertrauensgrenzen. Das Designziel: Ein Angreifer, der einen Knoten erreicht, kann die Kontodaten anderer Kunden nicht lesen und findet auf dem Knoten auch keine gespeicherten Sitzungsinhalte vor.

• Browser-Container besitzen keine Zugangsdaten zu unserer Datenbank oder zum Speicher und schreiben nichts in dauerhaften Speicher. Steuer- und Streaming-Verkehr läuft über den Proxy-Sidecar des Knotens, und der Container authentifiziert seine Aufrufe gegenüber dem Knoten mit einem knotenweiten Shared Secret.
• Lesezugriffe auf Untersuchungsdaten vermittelt das Backend: Es prüft die Workspace-Zugehörigkeit, bevor es etwas aus einer laufenden Untersuchung ausliefert.
• Bestehen bleibt der Untersuchungsdatensatz selbst (URL, Zeitstempel, Status), in der Datenbank an das zugehörige Konto und den Workspace gebunden. Leseanfragen über Workspace-Grenzen hinweg weist das Backend ab, und gespeicherte Sitzungsinhalte gibt es ohnehin keine anzufragen.
• 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 Edge-Knotens.

Wir behalten Abhängigkeiten von Drittanbietern im Blick, 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ängigkeitsprüfung: Wir pinnen Lockfiles fest und verfolgen Sicherheitshinweise zu unseren Paket-Ökosystemen und den Upstream-Browser-Projekten.
• Patch-Richtlinie: 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 die neueste stabile Upstream-Version 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. Wesentliche 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-Agenten, 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, Knoten-Flotte und die Datenbankebene in Helsinki. Logs werden in einen externen Log-Speicher übertragen 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 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 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.

Was eine Untersuchung sieht, wird nicht aufbewahrt: Es besteht nur im laufenden Container und wird mit ihm zerstört. Für Konto-, Log- und Abrechnungsdaten, die tatsächlich bestehen bleiben, gelten die Fristen unten. Der massgebliche Aufbewahrungsplan, einschliesslich der Kriterien für Kategorien ohne feste Frist, steht in Abschnitt 7 der Datenschutzerklärung; die wichtigsten Fristen fassen wir hier zusammen.

• Untersuchungsinhalte: bleiben nur für die Dauer der Untersuchung bestehen, auf jedem Plan. Sie liegen im Container, solange die Untersuchung läuft, und werden mit dessen Zerstörung verworfen; danach existiert keine Kopie davon, es kann also auch keine Frist ablaufen.
• Kontolöschung: Konto-, Workspace- und Untersuchungsdatensätze, 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 die zuvor entfernten 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, wo wir heute stehen 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 Inhalte der Untersuchungen, die Kunden durchführen, als Auftragsverarbeiter, und für einen eng umgrenzten Teil der Untersuchungsdaten, der Missbrauchsabwehr, Plattformsicherheit und rechtlicher Compliance 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 wir es einhalten.
• SOC 2 Type II: Roadmap-Punkt. Wir sind nicht SOC-2-zertifiziert und besitzen keinen SOC-2-Report. Behaupten werden wir das erst, wenn es so weit ist.
• 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 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 Knoten- und Datenbank-Infrastruktur), sofern die Forschung:

• sich ausschliesslich gegen unsere eigenen Systeme richtet, nicht gegen Drittwebsites, die in einer Untersuchung 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 und auf unsere Aufforderung hin alle zurückbehaltenen Daten löscht;
• den Dienst für andere Nutzer nicht beeinträchtigt (kein volumetrischer Denial-of-Service, keiner auf Anwendungsebene, keine Ressourcenerschö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.
• Befunde 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 (Architekturunterlagen, Due Diligence zu Subprozessoren) gehen alle an die unten genannte Adresse.

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.