Anti-Quishing auf der Ausstellerseite. Datenresidenz auf der Speicherseite.
Jeder Pro-Link durchläuft bei der Ausstellung, bei jeder Zieländerung und nach einem rollierenden Zeitplan eine siebenlagige Anti-Quishing-Pipeline. Das Scan-Log enthält nur Land plus Geräteklasse, ohne IP, ohne User-Agent, ohne Cookie, ohne Verhaltensprofil. Single-Region-D1 ist ab Agency und Custom Enterprise verfügbar.
Daten, die wir sammeln
Jedes Byte, das auf unseren Servern landet, gehört zu einem von vier Bereichen:
Kontodaten
E-Mail, Plan-Tier, Plan-Status, Stripe-Kunden- und Abonnement-IDs, optionaler Teamname und Workspace-Label. Das ist alles. Kein Telefon, keine Adresse (Rechnungsadresse bleibt bei Stripe), kein Verhaltensprofil.
Code-Daten
Die Ziel-URL, ein 7-stelliger Base58-Shortcode, ein Label und Tags nach Ihrer Wahl, optionales QR-Design (Farben / Logo / Rahmen), optionaler Passwort-Gate, optionaler Zeitplan. Ihr Eigentum; jederzeit als CSV exportierbar.
Scan-Daten
UTC-Tages-Bucket plus Land (aus CF-IPCountry) plus Geräteklasse (mobil / Tablet / Desktop / unbekannt). Der Roh-User-Agent wird sofort nach der Klassifizierung verworfen. Die IP gelangt nie in die Datenbank. Im KV für den Redirect-Hot-Path gecacht, über ctx.waitUntil in D1 aggregiert. Länderaggregate unter 5 Scans werden zu „Sonstige" zusammengefasst, um Re-Identifikation zu verhindern.
Audit- / Abrechnungsmetadaten
Nur-Anhängen-Protokoll von Mutationen (wer was wann in welchem Scope getan hat), 180-Tage-Aufbewahrung. Stripe-Webhook-Ereignisse werden für Idempotenz dedupliziert, keine Kunden-PII außer der Stripe-Kunden-ID. GDPR-Anfragenprotokoll (Export / Löschung / Wiederherstellung) bleibt nach Kontolöschung erhalten, um die fristgerechte Bearbeitung jeder Anfrage zu belegen.
Das vollständige Schema steht in docs/SCHEMA.md in unserem Quell-Repo; jede Spalte ist mit einer Aufbewahrungsrichtlinie dokumentiert.
Wo die Daten liegen
| Oberfläche | Anbieter | Region | Single-Region-Option? |
|---|---|---|---|
| Dashboard + API | Cloudflare Pages Functions | Globale Edge (nächster PoP) | Ja, nur Agency+ |
| Code-Einträge (D1) | Cloudflare D1 (SQLite) | Primärregion bei Provisionierung zugewiesen (heute: ENAM) | Ja, Agency+ per-Tenant-Shard |
| Redirect-Hot-Path (KV) | Cloudflare Workers KV | Global edge-repliziert für <50 ms p99 | Nicht verfügbar (Replikation ist das Produkt) |
| Verschlüsselte Backups | Cloudflare R2 | Primärregion bei Bucket-Erstellung zugewiesen | Ja, EU / APAC-Jurisdiktions-Bucket auf Anfrage |
| Zahlungen | Stripe | US, regionale PII-Verarbeitung über Stripes eigene Residenz | Über Stripe-Vertrag |
| Transaktions-E-Mail | ZeptoMail (Zoho) | IN (Zoho EU-Region auf Anfrage verfügbar) | Ja, Zoho EU-Region |
Was genau Grenzen überquert
- Scans überqueren keine Grenze auf verlustbehaftete Weise. Ein Scan aus Lissabon trifft den Lissaboner Cloudflare-PoP; der Worker schreibt Tag/Land/Gerät in KV am Edge und aggregiert asynchron in D1 in seiner Primärregion. Die IP des Scanners verbleibt im kurzlebigen Request-State von Cloudflare für die Dauer der HTTP-Anfrage und wird nie in unsere Datenbank persistiert.
- Dashboard-Anfragen enden am nächsten Cloudflare-PoP und rufen D1 über Cloudflares privates Netzwerk auf. Unsere Pages Functions lesen und schreiben D1 in seiner zugewiesenen Region; der Edge-PoP liefert das HTML- und JS-Bundle aus dem globalen Static-Asset-Cache.
- Stripe-Webhooks überqueren die Grenze einmal: Stripe (US) POSTet an unseren Cloudflare Pages-Endpunkt, der HMAC verifiziert, eine minimale Zeile (event_id, type) für Idempotenz schreibt und nachgelagerte Ereignisse weiterleitet.
- Transaktions-E-Mail (Zepto) überquert die Grenze einmal pro Sendung. Unser Worker übergibt eine gerenderte Vorlage an Zeptos API; Zepto liefert an den Mailserver des Empfängers. Inhalt sind Einladungslinks, Abrechnungsbenachrichtigungen und Scan-Cap-Warnungen, keine Kunden-Scan-Daten.
Anti-Quishing-Pipeline
QR-Phishing stieg im Q1 2026 um 146 %. Der Standard-Kurz-Link-Anbieter reagiert nach einer Kundenbeschwerde. Wir prüfen jeden Link bei der Ausstellung, bei jeder Zieländerung auf unserer Seite und nach einem rollierenden Zeitplan, denn ein Kunde kann seine eigene URL auf seinem eigenen Server neu ausrichten, ohne je unsere API aufzurufen. Dieselbe Bedrohungsanalyse-Pipeline, die unseren öffentlichen Scanner unter check.qr.abundera.ai betreibt, läuft gegen jeden Link, den wir ausgeben.
Sieben Erkennungslagen, jede mit einer ausstehenden US-Patentanmeldung. Jede Lage speist ein einheitliches Urteil; ein Treffer in einer einzigen Lage kann eine Erstellung blockieren, eine Zieländerung ablehnen oder einen bereits aktiven Link aussetzen.
| Lage | Was sie erkennt | Wann sie läuft |
|---|---|---|
| Mutabilität der Redirect-Kette | Wie viele unabhängige Parteien den Pfad zwischen unserem Kurz-Link und der finalen Seite kontrollieren. Eine zwei-Hop-Kette über einen fremden Redirector hat eine andere Risikoklasse als ein direktes Ziel. | Erstellung, Zieländerung, rollierender Re-Check |
| Multimodale Payload-Analyse | WLAN, Kontakt, Telefonie, Mail, Kalender, Geolokalisierung, Kryptowährung, Android-Intent und Inline-Daten-Payloads erhalten jeweils einen typspezifischen Analyzer. Fest gesperrte Schemas werden beim Einreichen abgelehnt. | Erstellung, Zieländerung |
| Crawler-vs.-Browser-Cloaking | Seiten, die Scannern sauberen Inhalt und Menschen Phishing ausliefern. Erkannt durch parallele Abrufe mit kontrollierter Fingerabdruckvarianz und einem Divergenz-Score. | Erstellung, rollierender Re-Check |
| Mutabilität des Ziel-Servers | Frisch registrierte Domains, brandneue Zertifikate, churn-intensive TLDs, fehlendes HSTS und Transport-Schema-Degradierung. Unabhängig von der Redirect-Kette; eine statische Ein-Hop-Kette zu einem sechs Tage alten Zertifikat auf einer fragwürdigen TLD wird trotzdem markiert. | Erstellung, Zieländerung, rollierender Re-Check |
| Herkunft physischer Instanzen | Crowd-gesourctes Hash-Ledger, indexiert nach dekodiertem Payload. Ein einzelner QR, der in kurzer Zeit über viele disperate Regionen hinweg gescannt wird, erscheint als Sticker-Angriffs-Kandidat. Jeder von uns ausgestellte Link erhält bei der Erstellung einen sauberen Herkunftseintrag, sodass Overlay-Angriffe auf legitime Pro-Codes erkannt werden. | Kontinuierlich |
| Visuell-Marken-Divergenz | Trägt ein Code ein Markenlogo, dessen kanonische Domain-Menge nicht das dekodierte Ziel enthält, ist der Code marken-divergent. Gilt für jeden Pro-Code mit unserem Center-Logo-Feature; ein Angreifer kann keinen Chase-Logo-Code erstellen, der auf eine Nicht-Chase-Domain zeigt. | Erstellung, Logo-Änderung, Zieländerung |
| Sensor- / Venue-Topologie | Bei venue-gebundenen Codes (Parkuhren, Hotel-Check-in, Restaurantmenüs, Museumsexponate) wird der Umgebungs-RF-Kontext des Scan-Geräts gegen die registrierte Topologie dieses Venue geprüft. Eine Abweichung löst eine Sensor-Kontext-Anomalie bereits beim ersten Scan eines betrügerischen Aufklebers aus. Enterprise-Tier; der Venue-Betreiber registriert die erwartete Topologie bei der Code-Erstellung. | Jeder Scan |
Das Problem der kundenseitigen Änderung
Die Ziel-URL eines Pro-Links liegt auf dem Server des Kunden, nicht auf unserem. Der Kunde kann example.com/promo von einer echten Promo auf eine Phishing-Seite umleiten, ohne die Abundera-API je aufzurufen. Wir behandeln das als den primären Missbrauchspfad, nicht als Randfall. Rollierender Re-Check aktiver Ziele läuft nach einem Zeitplan, und unsere Cloaking-Erkennungslage zielt gezielt auf Seiten ab, die sich nach dem Einreichen verändern. Beginnt ein Ziel nach der Erstellung, Prüfungen zu scheitern, wird der Link automatisch pausiert, der Eigentümer per E-Mail mit dem spezifischen Urteil benachrichtigt und das Ereignis im Audit-Trail protokolliert.
Falsch-Positive und Einsprüche
Bedrohungsanalyse liegt manchmal falsch. Eine legitime Marke auf einem neu ausgestellten Zertifikat, eine echte Promo, deren Seite sich legitimerweise geändert hat, eine umgezogene Domain. Jede Sperre und jede automatische Pause enthält die spezifische Urteilslage, die ausgelöst hat, den auslösenden Input und einen Ein-Klick-Einspruch, der innerhalb eines Werktages an einen Menschen eskaliert. Wir pausieren lieber als zu löschen; ein pausierter Link kann nach Klärung des Einspruchs in Sekunden wieder aktiviert werden.
Single-Region-Residenz (Agency+ und Custom Enterprise)
Für EU-Only- oder APAC-Only-Käufer können Agency-Tier-Kunden anfragen:
- D1 in einer einzigen Jurisdiktion (EU: EEUR oder WEUR; APAC: APAC). Cloudflare berücksichtigt einen
location-Hinweis bei der Datenbankerstellung; wir richten einen per-Tenant-D1-Shard in der angeforderten Region ein (ADR-0010). - R2-Bucket in derselben Jurisdiktion: nächtliche verschlüsselte D1-zu-R2-Backups landen in der passenden Region.
- Zoho EU-Region für Transaktions-E-Mail, auf Service-Level konfiguriert, keine Code-Änderung.
- KV bleibt global: Edge-Replikation ist entscheidend für die <50-ms-Redirect-Garantie. Ist Single-Region-KV eine harte Anforderung, sprechen Sie uns an; wir prüfen, ob eine regional-only-Worker-Variante für Ihre Kampagne machbar ist.
Der Preis für das Single-Region-Add-on ist pauschal (kein Per-Seat-Aufpreis) und hängt von der konkreten Kombination ab. Schreiben Sie an enterprise@abundera.ai mit Ihrer Ziel-Jurisdiktion und dem erwarteten Scan-Volumen, und wir erstellen ein Angebot.
Compliance-Position
- GDPR: Minimum-Daten per Design (nur Land und Geräteklasse, keine IP, kein UA, keine Cookies) plus Ein-Klick-Export und 30-Tage-Hard-Delete. DPA und EU SCCs für alle zahlenden Tiers verfügbar.
- CCPA: durch dieselbe Export- und Lösch-Oberfläche abgedeckt. „Datenverkauf" praktizieren wir nicht: keine Weitergabe an Dritte, keine Werbepartner, kein Retargeting.
- SSO + SCIM-Provisionierung: SAML 2.0 und OIDC Single Sign-On sowie SCIM 2.0 Benutzer- & Gruppen-Lifecycle (Agency und Custom Enterprise). RFC 7643/7644-Konformität verifiziert (20/20 auf der PingIdentity-basierten Testsuite). Per-Connection-Feature-Flag hält SCIM standardmäßig deaktiviert und aktiviert es pro Kunde; rate-limitiert auf 50 RPS pro Token; audit-geloggt. Okta/Entra/JumpCloud funktionieren heute als benutzerdefinierte SCIM-Apps, während Partner-Katalog-Einträge in Bearbeitung sind.
- SOC 2 Type II: im Scoping-Prozess, 6 bis 9 Monate. Ist das eine harte Anforderung, schreiben Sie an enterprise@abundera.ai; wir teilen aktuellen Status und projizierten Zeitplan.
- PCI-DSS: außerhalb unseres direkten Scopes; Zahlungen werden vollständig von Stripe abgewickelt (PCI Level 1 zertifiziert).
Sicherheitsoffenlegung
Schwachstelle gefunden? Schreiben Sie an security@abundera.ai. Koordinierte Offenlegung: wir bestätigen innerhalb von 24 Stunden (Werktage), triagieren innerhalb von 72 Stunden und koordinieren einen Fix- und Offenlegungszeitplan mit Ihnen. Noch kein Bug-Bounty-Programm; wir nennen Forscher öffentlich unter abundera.ai/security/thanks/, sobald ein Fix ausgeliefert wird.