ZUGRIFFSSICHERHEIT
Eine Migration braucht zweckgebundene Rechte, nicht den allgemeinen Live-Geheimschlüssel
Quell- und Zielkonto erfüllen unterschiedliche Aufgaben. Getrennte eingeschränkte Stripe-Schlüssel begrenzen deshalb Leserechte und Schreibrechte auf den tatsächlichen Migrationszweck und lassen sich nach dem Handover gezielt widerrufen.
Die kurze Antwort
Verwende für eine Stripe-Abo-Migration getrennte eingeschränkte API-Schlüssel für Quelle und Ziel. Vergib nur die Rechte, die Inventur, Zuordnung, Zielanlage und die ausdrücklich gewählte Quell-Deaktivierung benötigen. Prüfe jeden Schlüssel gegen die erwartete Kontokennung, speichere ihn in einem Secret Store, protokolliere niemals seinen Wert und widerrufe ihn nach Abschluss und vereinbarter Beobachtung. Der Migrationsschlüssel darf nicht zum dauerhaften Anwendungsschlüssel werden.
Fachlich geprüft am 24. Juli 2026
Warum Quelle und Ziel unterschiedliche Profile brauchen
Im Quellkonto wird der Bestand überwiegend gelesen: Customers, Subscriptions, Products, Prices und weitere für die Zuordnung benötigte Objekte. Wenn der freigegebene Ablauf Quellabonnements deaktiviert, ist dafür ein begrenztes Schreibrecht nötig. Das Zielkonto muss dagegen die vorgesehenen Zielobjekte anlegen oder verwalten können. Ein identischer weitreichender Schlüssel für beide Seiten widerspricht dem Prinzip geringstmöglicher Rechte.
Trenne außerdem Sandbox und Live. Testschlüssel können keine Live-Objekte verändern und Live-Kennungen sind nicht mit Sandbox-Kennungen austauschbar. Gib Schlüsseln einen eindeutigen Zweck und Besitzer, damit Dashboard, Sicherheitsverlauf und Widerruf verständlich bleiben. Verwende für wiederkehrende Produktfunktionen eigene Schlüsselprofile.
Berechtigungen aus dem tatsächlichen Ablauf ableiten
Beginne mit einer Liste der API-Operationen, nicht mit einem alten Geheimschlüssel. Welche Objekte werden nur gelesen, welche im Ziel erstellt und welche in der Quelle verändert? Müssen Coupons, Taxes, Webhook-Endpunkte oder Subscription Schedules behandelt werden? Entferne jedes Recht, das keinen dokumentierten Schritt unterstützt.
MoveMRR prüft benötigte Berechtigungen beim Verbinden. Ein Schlüssel mit zu wenigen Rechten stoppt den Ablauf vor dem Live-Lauf; das ist sicherer als eine späte Teilmigration. Ein Schlüssel mit unnötig vielen Rechten funktioniert technisch, erweitert aber den möglichen Schaden bei Fehlkonfiguration oder Offenlegung. Dass ein Schlüssel funktioniert, ist daher allein kein Sicherheitsnachweis.
Jeden Schlüssel und Kontokontext validieren
Ein gültiger Schlüssel kann zum falschen Konto gehören. Zeige deshalb bei jeder Freigabe die erwartete und die tatsächlich gelesene Kontokennung. Bei einem Käufer-/Verkäuferprojekt sollten beide Seiten ihren eigenen Schlüssel im eigenen sicheren Kontext erstellen und nicht über E-Mail oder einen allgemeinen Deal-Ordner austauschen.
- 1 Schlüssel im richtigen Stripe-Modus und Konto erzeugen.
- 2 Zweck, Eigentümer und geplantes Ablaufdatum dokumentieren.
- 3 Mit einer ungefährlichen Anfrage die Kontokennung bestätigen.
- 4 Erforderliche Lese- und Schreiboperationen in der Sandbox prüfen.
- 5 Fehlende oder überschüssige Rechte vor Live entfernen.
- 6 Quell- und Zielkennung im finalen Go/No-Go erneut vergleichen.
Wie MoveMRR Live-Schlüssel behandelt
MoveMRR verwendet zweckgebundene eingeschränkte Schlüssel und validiert die benötigten Rechte. Gespeicherte Live-Schlüssel liegen im Supabase Vault. Sie laufen in MoveMRR nach 30 Tagen ab und werden nach der Speicherung nicht wieder an den Browser ausgegeben. Das Produkt erhält keine rohen Kartennummern; berechtigte Zahlungsdaten werden über Stripe kopiert.
Diese Kontrollen verringern die Angriffsfläche, beseitigen aber nicht die Verantwortung des Kontoinhabers. Benutzerzugriffe, Endgeräte, Zwei-Faktor-Authentifizierung, Stripe-Teamrollen und sichere interne Kommunikation müssen ebenfalls stimmen. Ein kompromittierter Benutzerzugang kann nicht durch einen eingeschränkten API-Schlüssel allein kompensiert werden.
Schlüssel während des Migrationslebenszyklus verwalten
Lege vor der Erstellung fest, wann ein Schlüssel aktiviert wird, wer ihn nutzen darf und wann er widerrufen wird. Während der Probe werden ausschließlich Sandbox-Zugänge verwendet. Live-Schlüssel werden so spät wie praktikabel verbunden und nur für den freigegebenen Umfang genutzt. Ungewöhnliche Fehler oder eine ungeklärte Kontokennung führen zum Stopp, nicht zur spontanen Erweiterung der Rechte.
Nach Live-Lauf, Ergebnisabstimmung und dem vereinbarten Beobachtungsfenster werden die Migrationsschlüssel widerrufen. Dokumentiere den Widerruf und prüfe, dass keine Hintergrundaufgabe von ihnen abhängt. Die Käuferanwendung erhält eigene produktionsgeeignete Schlüssel, die nach ihrem Betriebsmodell eingeschränkt, überwacht und rotiert werden.
Geheimnisse nicht in Anwendungscode oder Protokolle bringen
Stripe-Schlüssel gehören in einen Secret Store oder die sichere Umgebungsverwaltung der Laufzeit, niemals in Quellcode, Chat, Tickets, Bildschirmfotos oder allgemeine Tabellen. Verhindere, dass Fehlerobjekte, Request-Header oder Debug-Ausgaben den Wert protokollieren. Beschränke Produktionszugriff und protokolliere, wer eine Konfiguration geändert hat.
Wenn ein Schlüssel möglicherweise offengelegt wurde, widerrufe oder rotiere ihn nach dem vorgesehenen Sicherheitsverfahren und prüfe den Sicherheitsverlauf. Kopiere ihn nicht einfach in einen anderen Kanal. Plane Rotation so, dass abhängige Dienste kontrolliert auf den Ersatz wechseln und der alte Wert danach sicher unbrauchbar wird.
Sicherheitsgrenzen richtig kommunizieren
Geringstmögliche Rechte begrenzen API-Aktionen, garantieren aber keine fehlerfreie Migration. Ein erlaubter Schreibvorgang kann mit falschen fachlichen Parametern ausgeführt werden. Deshalb bleiben Probelauf, Abnahme, Idempotenz und Ergebnisabstimmung notwendig. Ebenso schützt ein sicherer Schlüssel nicht vor falschen Kontodaten oder einer unzulässigen Deal-Struktur.
Stripe kann Berechtigungsmodelle und empfohlene Verfahren ändern. Prüfe die aktuelle offizielle Dokumentation vor Einrichtung. Bei besonderen Produkten, Connect oder weiteren Stripe-Funktionen muss das Profil aus dem konkreten Ablauf abgeleitet und separat getestet werden.
Häufige Fragen
Kann ich den normalen Stripe-Live-Geheimschlüssel verwenden?
Technisch besitzt er meist mehr Rechte, als die Migration braucht. Verwende stattdessen zweckgebundene eingeschränkte Schlüssel, damit Quelle und Ziel nur die dokumentierten Aktionen erlauben.
Brauchen Quell- und Zielkonto denselben Zugriff?
Nein. Die Quelle wird vor allem gelesen und nur für eine freigegebene Deaktivierung verändert. Das Ziel benötigt Rechte zur Anlage der vorgesehenen Objekte. Leite beide Profile separat ab.
Darf der Migrationsschlüssel nach dem Cutover in der Anwendung bleiben?
Nein. Die dauerhafte Anwendung sollte ein eigenes, ihrem Betriebszweck entsprechendes Profil verwenden. Der Migrationsschlüssel wird nach Abstimmung und Beobachtung widerrufen.
Verarbeitet MoveMRR rohe Kartendaten?
Nein. Berechtigte Zahlungsdaten werden durch Stripe kopiert. MoveMRR arbeitet mit Stripe-Objekten und Zuordnungen, nicht mit rohen Kartennummern.