Sicherheit · Read-only · EU-gehostet

Dein HubSpot bleibt unangetastet.

Wir lesen die Konfiguration, schreiben nie zurück und verarbeiten so wenig personenbezogene Daten wie möglich. Die Read-only-Architektur ist kein Versprechen im Kleingedruckten, sondern im Code erzwungen.

GET-only-ClientKeine KontaktdatenEU-Hosting

Vertrauen, das in der Architektur steckt.

Bausteine, die zusammen erklären, warum du dein Portal bedenkenlos verbindest — jeder einzelne nachprüfbar, keiner nur behauptet.

Read-only — beweisbar

Der HubSpot-Client kennt nur GET. Mehrschichtiger Read-only-Guard, Endpoint-Allowlist und expliziter Sync-Modus. Der technisch erforderliche HubSpot-Automation-Scope kann mehr erlauben; die App begrenzt ihn deshalb zusätzlich auf freigegebene GET-Endpunkte und führt keine Schreibaufrufe aus.

Verschlüsselung & Audit

Verschlüsselung in Transit und at rest. Vollständiges Audit-Log für die Rechenschaftspflicht. Strikt tenant-skopierte Mandantentrennung — jede Query ist app-seitig mandantengefiltert, DB-Row-Level-Security folgt als zusätzliche Härtung.

  • In Transit & at rest verschlüsselt
  • Vollständiges Audit-Log
  • Strikt tenant-skopierte Queries

Keine Kontakt-/CRM-Daten

Wir ziehen keine Kontakt-/CRM-Daten aus deinem Portal — keine Kontakte, Deals, Form-Submissions oder Engagements. Synchronisiert werden nur Konfigurations-Metadaten (Workflows, Properties, Listen, Forms). Diese Metadaten laufen für die Analyse durch die KI-Inferenz bei Anthropic (USA, SCC) — kein Training auf deinen Daten.

EU-Hosting & -Verarbeitung

Datenbank und App laufen in einem EU-Rechenzentrum. Die KI-Verarbeitung erfolgt über Anthropic PBC (USA) auf Grundlage der EU-Standardvertragsklauseln (SCC), kein Training auf deinen Daten. Eine EU-Datenresidenz der Inferenz ist geplant.

Jederzeit trennen & löschen

Du kannst dein HubSpot jederzeit trennen; deine Daten werden gelöscht. Token brauchen wir nur für Re-Syncs — du kannst sie dazwischen rotieren oder widerrufen.

Subprozessoren offengelegt

KI-Verarbeitung über Anthropic PBC (USA) auf Grundlage der EU-Standardvertragsklauseln (SCC), Zahlungen über Stripe. Alle Subprozessoren werden in der AVV/DPA gelistet — du weißt, wer was verarbeitet.

Der Client kennt nur GET.

Kein POST, kein PATCH, kein DELETE — keine Schreib-Methode existiert im HubSpot-Client. Wir synchronisieren Konfigurations-Metadaten, nie deine Records.

Was wir lesen

  • Workflows
  • Properties
  • Listen
  • Forms

Was wir nie anfassen

  • Kontakte
  • Deals
  • Form-Submissions
  • E-Mails & Engagements

Diese Daten verlassen HubSpot nie.

app.workflow-analyzer.eu/api/hubspot
GET/crm/v3/properties/contacts200
GET/automation/v4/flows200
GET/marketing/v3/forms200
POST/crm/v3/objects/contactsblockiert
PATCH/automation/v4/flows/42blockiert

Read-only-Guard · Endpoint-Allowlist · 0 Schreibzugriffe

Heute

So verbindest du heute.

Du verbindest dein Portal per OAuth oder über einen Private-App-Token mit den minimal erforderlichen Berechtigungen. Das eigentliche Read-only überlassen wir aber nicht dem Scope allein, sondern erzwingen es mehrschichtig im Code — die vier Verteidigungslinien rechts greifen unabhängig voneinander. OAuth ist live; weil der für Workflows nötige Automation-Scope technisch mehr erlauben kann, bleibt diese Guard-Kette bei jedem HubSpot-Aufruf maßgeblich.

  • 1. GET-only-Client-Guard

    Der HubSpot-Client stellt ausschließlich GET bereit — POST, PATCH, PUT und DELETE existieren gar nicht.

  • 2. Endpoint-Allowlist

    Nur eine feste Liste lesender Konfigurations-Endpoints ist erlaubt; alles außerhalb wird abgewiesen.

  • 3. Expliziter Sync-Modus

    HubSpot-Aufrufe laufen nur im freigegebenen Sync-Modus und weiterhin ausschließlich über den GET-only-Client — ohne Rückschreibpfad in dein Portal.

  • 4. check-readonly-CI

    Ein CI-Check bricht den Build, sobald irgendwo ein schreibender Aufruf in den Code geriete.

Isolation

Jeder Tenant in seiner eigenen Spur.

Die Mandantentrennung ist app-seitig erzwungen: Jede Query ist strikt tenant-skopiert und mandantengefiltert, sodass ein Portal die Daten eines anderen nicht erhält. Eine DB-Row-Level-Security in Postgres ist als zusätzliche Härtung in Vorbereitung. Verschlüsselung in Transit und at rest, ein vollständiges Audit-Log dokumentiert jeden Zugriff.

Read-only verbindenFragen zur Verarbeitung? Schreib uns
  • Jede Query strikt mandantengefiltert (app-seitig erzwungen)
  • DB-Row-Level-Security als zusätzliche Härtung in Vorbereitung
  • Verschlüsselung in Transit und at rest
  • Vollständiges Audit-Log (Rechenschaftspflicht)
  • Token rotier- und widerrufbar — Re-Sync only
  • Jederzeit trennen, Daten werden gelöscht

Alles nachlesbar — nicht nur behauptet.

Datenverarbeitung, Subprozessoren und Auftragsverarbeitung stehen schwarz auf weiß. Eine Sicherheitslücke gefunden? Melde sie direkt.

Verbinde read-only und lies sofort los.

Strikt lesend, EU-gehostet, ohne Schreibzugriff — von der ersten Sekunde an. Du kannst jederzeit trennen, deine Daten werden gelöscht.

GET-only-Client · keine Kontaktdaten · EU-Hosting