Sicherheitserklärung

Mit Guard.ch öffnen Analysten 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 den Analysten an (Drive-by-Exploits, Fingerprinting, Preisgabe der IP-Adresse); ein Kunde sieht Daten eines anderen Kunden (Datenabfluss zwischen Workspaces, vermischte Aufzeichnungen, geteilter Speicher); und ein Angreifer, der einen einzelnen Edge-Knoten erreicht, arbeitet sich zu gespeicherten Beweisen vor. Die im Folgenden beschriebenen Kontrollen wirken genau diesen drei Risiken entgegen. Wir benennen, was heute umgesetzt ist, und kennzeichnen, was auf der Roadmap steht.

Dauerhaft gespeichert werden Aufzeichnungen von Untersuchungen (Snapshots, Session-Manifeste, 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 (das Session-Manifest und eine JSON-Datei pro Snapshot) 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 es gibt keine Replikation ü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 ausgelegt, dass sie keinen Zustand teilen, und der einzige Bind-Mount vom Host ist eine einzelne, nur lesbare Hostname-Datei.
• Lebenszyklus einer Untersuchung: Die Aufzeichnungsartefakte werden während der Untersuchung in die beschreibbare Schicht des Containers geschrieben (/recording/session.json sowie eine /recording/snapshot-<id>.json pro Snapshot, die je einen Screenshot und die Signale der Seite enthält). Endet die Untersuchung (Timer abgelaufen, Event-Obergrenze erreicht oder ein expliziter /finalize-Aufruf), übergibt die Capture-Komponente die Artefakte an den Proxy-Sidecar des Edge-Knotens, der sie über TLS in den Objektspeicher in Helsinki hochlädt. Anschliessend entfernt der Edge-Agent den Container samt seinen Volumes endgültig; dadurch wird die beschreibbare Schicht verworfen. Browser-Profil, Cookies, Downloads und der Cache auf der Festplatte werden dabei mitgelöscht. 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 Festplatten-Vollverschlüsselung 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 die Zugehörigkeit und das geltende Aufbewahrungsfenster, bevor es Lesezugriff zur Durchsicht gewährt; Lesezugriffe über Workspace-Grenzen hinweg werden im Backend abgewiesen, nicht erst im Dashboard.

Der Datenverkehr 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 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.
• 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 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 Aufzeichnungen, Exporte und 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, 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 Edge-Knotens; dieser holt sich die Speicher-Zugangsdaten beim Start vom Backend und hält sie im Arbeitsspeicher, um private Schreibzugriffe auf den Objektspeicher auszuführen. Der Container authentifiziert seine Upload- und Abschluss-Aufrufe gegenüber dem Edge-Knoten mit einem knotenweiten Shared Secret.
• Lesezugriffe auf Aufzeichnungen vermittelt das Backend: Es prüft die Workspace-Zugehörigkeit und das geltende Aufbewahrungsfenster, bevor es eine signierte, zeitlich begrenzte Snapshot-URL ausstellt.
• Aufzeichnungen liegen unter Präfixen pro Untersuchung und sind in der Datenbank an das zugehörige 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 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, Edge-Knoten und die Speicherebene 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 Untersuchungsaufzeichnungen, 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.

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 feste Frist, steht in Abschnitt 7 der Datenschutzerklärung; die wichtigsten Fristen fassen wir hier zusammen.

• Aufbewahrung von Aufzeichnungen: 1 Tag für Free-Untersuchungen und daraus abgeleitete Artefakte; 1 Monat für Untersuchungen in 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 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 Untersuchungsinhalte, die Kunden aufzeichnen lassen, 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 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 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.