Sicherheitslücken schließen: Wie SafeState Rückrufe in Echtzeit blockiert

Rückrufe für Kinderprodukte wie Wiegen oder Schlafsäcke werden heute meist als PDF oder Website veröffentlicht. Doch selbst wenn ein Händler die Warnung sieht, endet die Verantwortung dort. Verkäufer ignorieren den Rückruf, und Käufer erhalten kein Update über die Gefährlichkeit. SafeState ändert das: Die Plattform prüft gebrauchte Artikel in Echtzeit und blockiert den Verkauf, sobald ein Rückruf vorliegt – und zwar bis auf die Seriennummer genau.

Rückrufe als aktive Sicherheitsmaßnahme umsetzen

Die größte Herausforderung lag darin, Rückrufe nicht nur als statische Informationen, sondern als sofort wirksame Barriere zu gestalten. Ein Rückruf muss alle Marktplätze sofort erreichen – unabhängig davon, in welcher Region er veröffentlicht wird. Eine verzögerte Synchronisation oder eine „irgendwann konsistente“ Datenbank würde diese Lücke offenhalten. Genau hier setzt Aurora DSQL an: Mit einer aktiv-aktiven, mehrstufigen Architektur und starker Konsistenz stellt die Datenbank sicher, dass ein Rückruf innerhalb von Sekunden überall verfügbar ist.

Ich habe einen Cluster mit drei Regionen aufgebaut – zwei Schreibknoten in us-east-1 und us-east-2, sowie einen Witness-Knoten in us-west-2. Sobald ein Rückruf über einen Endpunkt geschrieben wird, ist er sofort aus der zweiten Region abrufbar. Ein Test im SafeState-Dashboard zeigt, wie schnell diese Synchronisation funktioniert.

Der Schlüssel: Konflikte erzwingen, um Verkäufe zu blockieren

Aurora DSQL nutzt für PostgreSQL typische Snapshot-Isolation mit optimistischer Nebenläufigkeitskontrolle. Das Problem: Bei dieser Isolation kann es zu Schreibkonflikten kommen, die nicht automatisch erkannt werden. Um einen Rückruf und einen Verkauf desselben Produkts zuverlässig kollidieren zu lassen, muss man beide Vorgänge auf dieselbe Zeile schreiben.

Jedes Modell in SafeState hat eine safety_guard-Zeile, die den Sicherheitsstatus und eine Epochenzahl enthält. Beim Versuch, ein Produkt zu verkaufen, wird diese Zeile für eine exklusive Sperre ausgewählt. Falls ein Rückruf für dasselbe Modell vorliegt, scheitert der Verkaufsversuch mit einem Konflikt.

await client.query("BEGIN");
await client.query("SELECT epoch FROM safety_guard WHERE model_id = $1 FOR UPDATE", [modelId]);
// ... Prüfung, ob der Artikel betroffen ist ...
if (betroffen) {
  return { status: "BLOCKED" };
}
await client.query("INSERT INTO ownership_transfers (...) VALUES (...)");
await client.query("UPDATE product_instances SET current_owner_id = $1 WHERE id = $2", [buyer, id]);
await client.query("UPDATE safety_guard SET updated_at = now() WHERE model_id = $1", [modelId]);
await client.query("COMMIT");

Scheitert der Verkauf, weil ein Rückruf bereits vorliegt, wirft die Transaktion den Fehler SQLSTATE 40001 (OC000). Ein automatischer Wiederholungsmechanismus mit Backoff und Jitter startet die Transaktion neu. Beim zweiten Versuch wird der Rückruf erkannt, und der Verkauf wird endgültig blockiert. So gibt es keine Situation, in der ein gefährlicher Artikel noch verkauft werden kann.

Integration mit Vercel: Sicherheit ohne Passwörter

Die SafeState-App läuft als Next.js-Anwendung auf Vercel. Die Verbindung zur Aurora-DSQL-Datenbank erfolgt über das Standard-PostgreSQL-Protokoll, doch die Authentifizierung ist besonders: Anstatt Passwörter in Umgebungsvariablen zu speichern, nutzt SafeState kurzlebige IAM-Tokens, die pro Verbindung mit der Bibliothek @aws-sdk/dsql-signer generiert werden. Das eliminiert das Risiko von Credential-Leaks.

Ein weiterer wichtiger Punkt: Vercel Functions laufen auf AWS Lambda, das bestimmte Umgebungsvariablen reserviert – darunter AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY. Um diese Einschränkung zu umgehen, werden die DSQL-Credentials unter anderen Namen in den Umgebungsvariablen gespeichert und direkt an den Signer übergeben:

const creds = process.env.SAFESTATE_AWS_ACCESS_KEY_ID ? {
  accessKeyId: process.env.SAFESTATE_AWS_ACCESS_KEY_ID,
  secretAccessKey: process.env.SAFESTATE_AWS_SECRET_ACCESS_KEY
} : undefined;

const signer = new DsqlSigner(
  creds ? { hostname, region, credentials: creds } : { hostname, region }
);

Zusätzlich aktualisiert ein Cron-Job auf Vercel täglich die Rückrufdaten aus der öffentlichen CPSC-API. Eine KI analysiert Gebrauchtlisten – selbst wenn diese in umgangssprachlicher Form verfasst sind wie „gebrauchter Baby-Schlafsack, funktioniert einwandfrei“ – und ordnet sie den passenden Rückrufen zu. Unsichere Übereinstimmungen landen in einer Review-Warteschlange, während klare Fälle sofort blockiert werden.

Lessons Learned für Entwickler

Wer Aurora DSQL einsetzt, sollte Probleme lösen, bei denen Korrektheit unter hoher Nebenläufigkeit entscheidend ist. Der Aufbau eines Systems, das auf Konflikte setzt, erfordert:

• Einen gemeinsamen Schreibzugriff auf dieselbe Zeile, um Nebenläufigkeitsfehler zu erzwingen.
• Einen robusten Wiederholungsmechanismus für gescheiterte Transaktionen, besonders für Fehlercodes wie 40001 oder OC000.
• Eine klare Architektur, bei der die Nebenläufigkeitskontrolle im Mittelpunkt steht – nicht als Nebeneffekt.

Rückrufe sollten keine statischen PDFs mehr sein. Mit Aurora DSQL und Vercel lassen sie sich in Echtzeit durchsetzen und verhindern so den Weiterverkauf gefährlicher Produkte. Eine einfache Idee, die Leben retten könnte.

SafeState entstand im Rahmen des Hackathons „H0: Hack the Zero Stack“. Das Projekt ist auf GitHub verfügbar.