Vertrauen bei Squish

Squish ist eine Plattform aus mehreren Services. Die Kunden-Website (squish.co) und das interne CRM (work.squish.co) laufen auf Cloudflare Workers / Pages. Fünf Node.js-Backends — squish-backend, squish-crm-backend, squish-provisioning, squish-email und squish-hosting — laufen auf Railway in der Region US-East. Kundendatensätze liegen in Salesforce; Transaktionsdaten, Audit-Logs und Provisioning-Metadaten liegen in Google Firestore (Region USA). Zahlungsdaten werden von Stripe verwahrt — Squish liegt damit bewusst außerhalb des PCI-Geltungsbereichs.

Domain-Registrierungen laufen über NameSilo. Shared Webhosting läuft auf Plesk-Nodes auf DigitalOcean-Droplets; Managed-Cloud-VPS nutzen standardmäßig CyberPanel auf einem eigenen Droplet. Gehostete Websites laufen hinter CDN und WAF von Bunny. Microsoft 365-Lizenzen werden über Pax8 (CSP) bezogen.

• Bei der Übertragung: TLS 1.3 (mindestens TLS 1.2) Ende-zu-Ende über Cloudflare. HSTS auf jeder kundenseitigen Domain erzwungen.
• Im Ruhezustand: Firestore-Standardverschlüsselung (AES-256), Salesforce-Plattformverschlüsselung; sämtliche Kartendaten verarbeitet Stripe mit PCI DSS Level 1-Kontrollen.
• Secrets: Alle API-Schlüssel, Service-Account-Zugangsdaten und Datenbank-Verbindungsdaten liegen in Railway-Umgebungsvariablen und Cloudflare Secret Bindings — niemals im Quellcode.
• Backups: Firestore Point-in-Time-Recovery (7-Tage-Fenster). Salesforce-Kundendatensätze liegen auf der Salesforce-Plattform mit deren integrierter Replikation und Disaster Recovery.

• Kundenauthentifizierung: Firebase Auth (E-Mail + Passwort, optional OAuth-Anbieter). Kurzlebige JWTs (1 Stunde Gültigkeit).
• Team-Authentifizierung: Cloudflare Access vor jeder internen Oberfläche. SSO + MFA verpflichtend. Session-Tokens pro App begrenzt.
• Service-zu-Service: gemeinsamer interner API-Schlüssel + Rollen-Gates pro Route (Admin / Support / Vertrieb).
• Impersonation: Jede „Als Kunde handeln“-Sitzung des Teams wird mit Grund, sämtlichen Aktionen sowie Start-/Endzeitpunkt protokolliert. Destruktive Aktionen (Änderung der Zahlungsmethode, Registrar-Transfers) sind während der Impersonation per expliziter Denylist gesperrt.

Jede privilegierte Aktion landet in einer dieser Append-only-Firestore-Collections:

• security_events — fehlgeschlagene Logins, RBAC-Ablehnungen, IDOR-Versuche, Rate-Limit-Auslösungen
• impersonation_sessions — Team-als-Kunde-Sitzungen mit Sub-Collection pro Aktion
• billing_actions — ausgestellte Erstattungen, Begründungen für Rollen-Limits, Zweitfreigabe-Ketten
• email_log — jede ausgehende E-Mail mit Typ, Unterdrückungsgrund und Versandstatus
• webhook_events — Idempotenz-Leases für Stripe- / NameSilo- / Pax8-Webhooks
• cron_runs — Heartbeat für jeden geplanten Job (fehlende Läufe werden so sichtbar)

Sicherheitskontrollen sind nicht nur auf dieser Seite beschrieben — tragende Kontrollen sind im Code verankert, damit das nächste Deployment sie nicht unbemerkt aufweichen kann.

• CI-Gate für Security-Header in Responses: Jeder PR durchläuft einen Vitest-Smoke-Test, der den Build fehlschlagen lässt, sobald Content-Security-Policy, Cross-Origin-Resource-Policy, Anti-Clickjacking- oder Referrer-Policy-Header von ihren Sollwerten abweichen.
• Berechtigungsprüfung für Drittanbieter beim Start: Das Backend stellt beim Hochfahren sicher, dass der konfigurierte Stripe-API-Schlüssel jeden Scope besitzt, auf den Dashboard und Checkout angewiesen sind; ein fehlender Scope wird beim Start deutlich protokolliert, statt als stiller Fehler beim Kunden aufzutauchen.
• Typgeführte SOQL-Helfer weisen fehlerhafte Bezeichner direkt am Aufrufort zurück, statt sie stillschweigend in Werte umzuwandeln, die die Abfrage ausweiten würden — Schutz vor SOQL-Injection auf Integrationsseite.
• Bereitschafts-Manifest für Umgebungsvariablen: Jeder Service deklariert alle Variablen, die er nutzt — als erforderlich oder optional markiert — und ein interner Endpunkt meldet, welche auf der laufenden Instanz fehlen. So fällt ein fehlendes Secret bei einer bewussten Prüfung nach dem Deployment auf und nicht erst bei der ersten Kundenanfrage, die es gebraucht hätte.

Betriebsdaten werden nur für kurze, begründbare Zeiträume aufbewahrt; Finanzunterlagen bleiben die 7 Jahre erhalten, die das US-Steuerrecht verlangt. Löschanträge von Kunden werden bei nicht-finanziellen Daten innerhalb von 30 Tagen umgesetzt.

Anbieter, die in unserem Auftrag Kundendaten verarbeiten. Jeder betreibt ein eigenes Compliance-Programm — die Links führen zu den jeweiligen öffentlichen Trust-Seiten.

• Sicherheitskontakt: security@squish.co — das Team wird in Echtzeit alarmiert.
• Responsible-Disclosure-Richtlinie: /.well-known/security.txt
• SLA für die Erstreaktion: innerhalb eines Werktags.
• Kundenbenachrichtigung: innerhalb von 72 Stunden nach einem bestätigten Vorfall mit Kundendaten, gemäß Art. 33 DSGVO.
• Live-Systemstatus: squish.co/status

Heute: Squish betreibt ein selbst attestiertes Sicherheitsprogramm, gestützt auf die oben beschriebenen Kontrollen. Der Großteil des SOC 2 Type 1-Kontrollsets (Zugriffskontrolle, Verschlüsselung, Audit-Logging, Anbieter- und Change-Management) ist bereits umgesetzt; das formale Audit steht auf der Roadmap.

SOC 2 Type 1: in Arbeit. Attestierung noch in diesem Jahr geplant.

SOC 2 Type 2: die Beobachtungsphase beginnt, sobald die Type 1-Attestierung vorliegt.

Für Einkaufsteams: Wir füllen gern einen Sicherheitsfragebogen aus (CAIQ-Lite, SIG-Lite oder Ihr eigenes Format). Schreiben Sie an security@squish.co.

Auftragsverarbeitungsvertrag (AVV/DPA): unser Standard-AVV, ausgerichtet an Art. 28 DSGVO und inklusive der EU-Standardvertragsklauseln, ist veröffentlicht unter squish.co/dpa und automatisch Bestandteil unserer Nutzungsbedingungen.