Nachvollziehbare Sicherheitsgrenzen
Kontrollierter Stripe-Zugriff für eine sensible Billing-Übergabe
Eine Abo-Migration braucht ausreichenden Zugriff auf Stripe-Objekte, darf daraus aber keine unnötig breite oder dauerhafte Berechtigung machen. MoveMRR trennt zweckgebundene Schlüssel, sichere Speicherung, zeitliche Begrenzung und die Verarbeitung von Zahlungsdaten.
Die kurze Antwort
MoveMRR verwendet für reguläre Migrationen zweckgebundene Restricted Stripe API Keys und prüft die benötigten Berechtigungen. Gespeicherte Live-Schlüssel liegen in Supabase Vault, laufen nach 30 Tagen in MoveMRR ab und werden nach dem Speichern nicht an den Browser zurückgegeben. MoveMRR verarbeitet keine rohen Kartennummern; geeignete Zahlungsdaten werden von Stripe kopiert. Sandbox Seeding nutzt separate einmalige Lese- und Test-Schlüssel, die nur dem Backend-Lauf übergeben und nicht als Projektschlüssel gespeichert werden. Diese Kontrollen reduzieren Risiken, ersetzen aber nicht Freigabe, Reconciliation und Widerruf durch die Kontoinhaber.
Produktbezogene Sicherheitsangaben geprüft am 24. Juli 2026
Umgesetzte Kontrollen und ihre genaue Grenze
Jede Kontrolle adressiert ein anderes Risiko: Restricted Permissions begrenzen mögliche Aktionen, Vault schützt einen gespeicherten Schlüssel, der Ablauf begrenzt seine Nutzungsdauer in MoveMRR und Stripes Kopierprozess hält rohe Kartendaten aus dem MoveMRR-Workflow heraus.
Zweckgebundener Stripe-Zugriff
MoveMRR verwendet zweckgebundene Restricted Stripe API Keys und validiert die erforderlichen Berechtigungen.
Grenze: Die Berechtigungen unterscheiden sich je nach Quell- oder Zielrolle. Auch ein Restricted Key bleibt ein sensibles Geheimnis und muss vom Kontoinhaber erstellt, geprüft und widerrufen werden.
Vault-Speicherung und Ablauf von Live-Schlüsseln
Gespeicherte Live-Schlüssel verwenden Supabase Vault, laufen nach 30 Tagen in MoveMRR ab und werden nach der Speicherung nicht an den Browser zurückgegeben.
Grenze: Der MoveMRR-Ablauf steuert die Nutzung innerhalb des Produkts. Er ersetzt nicht den Widerruf im Stripe Dashboard nach der Migration oder bei Verdacht auf Offenlegung.
Keine Verarbeitung roher Kartennummern
MoveMRR verarbeitet keine rohen Kartennummern. Geeignete Zahlungsdaten werden von Stripe kopiert.
Grenze: MoveMRR verarbeitet weiterhin Billing-Objekt-IDs und Migrationsmetadaten, die für den Ablauf nötig sind. Eignung und Authentifizierung werden durch Stripe, Issuer und Regulierung bestimmt.
Separate einmalige Schlüssel für Sandbox Seeding
Ein Seed Run verwendet einen einmaligen schreibgeschützten Live-Schlüssel zum Lesen sowie einen separaten Test-Schlüssel für Schreibzugriffe in die ausgewählte Stripe-Sandbox. Die vollständigen Geheimnisse werden dem Backend-Lauf übergeben und nicht als Projektschlüssel gespeichert.
Grenze: Für den Audit-Kontext können Stripe-Account-ID und ein kurzes Schlüsselpräfix protokolliert werden, niemals der vollständige Schlüssel. Diese Ausnahme ist von den gespeicherten Quell- und Zielschlüsseln regulärer Migrationen getrennt.
Warum Restricted Keys der normale Migrationszugang sind
Ein geheimer Stripe-Schlüssel kann weitreichende Aktionen erlauben. MoveMRR nutzt deshalb für reguläre Quell- und Zielzugriffe zweckgebundene Restricted Keys und prüft ihre Berechtigungen. Die Quellrolle muss die Objekte lesen können, die den aktuellen Billing-Zustand bestimmen. Die Zielrolle braucht genau die Schreibrechte, die zur vereinbarten Neuerstellung erforderlich sind. Durch die Trennung lassen sich gewährte Fähigkeiten leichter bewerten.
Least Privilege ist keine für jedes Projekt identische Liste. Subscription Schedules, Coupons, Tax-Einstellungen, Products, Prices oder eine optionale Webhook-Neuanlage können den Umfang verändern. Entscheidend ist, dokumentierte Berechtigungen für den gewählten Workflow zu erteilen, unzureichende Schlüssel abzulehnen und fachfremde Rechte zu vermeiden.
- Eigenen Schlüssel verwenden: Keinen breiten Betriebsschlüssel einer anderen Integration wiederverwenden.
- Eindeutig benennen: Zweck sowie Quell- oder Zielrolle im Stripe Dashboard sichtbar machen.
- Prüfen und widerrufen: Den Schlüssel nach Reconciliation und Applikationsübergabe in Stripe entfernen.
Was Supabase Vault und der Ablauf nach 30 Tagen bedeuten
Gespeicherte Live-Schlüssel liegen in Supabase Vault. Nach der Speicherung wird das Live-Geheimnis nicht an den Browser zurückgegeben; die Oberfläche erhält Status- und Validierungsmetadaten statt des Schlüsselwerts. Interne Migrationsoperationen fordern das Geheimnis nur an, wenn sie Stripe aufrufen müssen. Ist der sichere Vault-Pfad nicht verfügbar, wird die Speicherung eines Live-Schlüssels abgelehnt, statt still auf Base64-Codierung zurückzufallen.
Ein gespeicherter Live-Schlüssel erhält in MoveMRR ein Ablaufdatum nach 30 Tagen. Danach lehnen Migrationsoperationen seine Nutzung ab und der Bereinigungspfad kann das Geheimnis entfernen. Diese Grenze verkürzt die Aufbewahrung, widerruft den Schlüssel aber nicht automatisch bei Stripe. Rotation, Widerruf und Incident Response bleiben Aufgabe des Kontoinhabers.
Wie Zahlungsdaten bei Stripe bleiben
MoveMRR sammelt und speichert keine rohen Kartennummern. Wenn eine Migration geeignet ist, kann Stripe unterstützte Kunden- und Zahlungsmitteldaten zwischen Accounts kopieren. Der MoveMRR-Workflow verknüpft anschließend kopierte Customer- und Payment-Method-Objekte mit den neu erstellten Zielabos. Stripe dokumentiert sowohl geeignete Daten als auch Objekte, die Customer Data Copy nicht überträgt.
Diese Trennung bedeutet nicht, dass jede Zahlungsmethode ohne Nacharbeit funktioniert. Nicht unterstützte Methoden, fehlende Default Payment Methods, Ablehnungen durch Issuer und Strong Customer Authentication können Abhilfe oder Kundenaktion erfordern. Dry Run und Ausnahmenbericht sind deshalb operative Kontrollen und keine Garantie für künftige Zahlungsautorisierung.
Sandbox Seeding ist eine bewusst getrennte Ausnahme
Sandbox Seeding bildet ausgewählte Strukturen eines Live-Kontos in Stripe-Testmodus nach. Für einen Seed Run liefert der Betreiber einen einmaligen Live-Schlüssel mit Leserechten und einen einmaligen Test-Schlüssel mit den erforderlichen Schreibrechten in der Sandbox. Diese Schlüssel werden als Argumente an den Backend-Lauf übergeben und nicht in die gespeicherten Stripe-Key-Datensätze des Projekts eingefügt.
Der Live-Client ist vertraglich im Code auf Lesen beschränkt; sämtliche Seed-Schreibvorgänge gehen an ein Stripe-Testkonto. Modus und Berechtigungen werden vor dem Lauf geprüft. Die Kundensynchronisierung zwischen zwei vorbereiteten Sandboxes ist ein eigener Vorgang und nutzt gespeicherte Test-Schlüssel für Quelle und Ziel. So wird ein vorübergehender Seeding-Umfang nicht zum regulären Live-Migrationszugang.
Welche Verantwortung bei Käufer und Verkäufer bleibt
MoveMRR kann produktinterne Kontrollen durchsetzen, aber nicht bestimmen, wer innerhalb einer Transaktion den Zugriff autorisieren darf. Käufer und Verkäufer sollten Verantwortliche für Quellkonto, Zielkonto, Applikation, Cutover und Incident-Kanal benennen. Sie müssen festlegen, wann Schlüssel erstellt werden dürfen, wer Dry-Run-Nachweise prüft und wer nach der finalen Reconciliation den Zugriff widerruft.
Applikationszugänge, Webhook Signing Secrets, lokale Datenbankrechte und Mitarbeiterzugriffe sind von der Speicherung der Stripe API Keys getrennt. Ein vollständiges SaaS-Handover braucht dafür ein eigenes Inventar. Diese Seite behauptet keine Zertifizierung, kein Audit-Urteil und keinen absoluten Schutz vor jedem Sicherheitsereignis. Sie beschreibt den aktuellen Produktstand und verweist auf die Plattformquellen.
Ein belastbarer Zugriffslebenszyklus
-
Quell- und Zielrollen definieren
Vereinbare, welches Stripe-Konto gelesen oder beschrieben wird, welche optionalen Objekte dazugehören und wer den Zugriff freigibt.
-
Eigene Restricted Keys erstellen
Erteile die dokumentierten Rechte je Rolle, benenne die Schlüssel in Stripe und validiere sie in MoveMRR.
-
Vor Live-Änderungen testen
Nutze Readiness-Prüfungen und Dry Run, um fehlende Rechte, Mappings und Payment-Method-Ausnahmen zu erkennen.
-
Abgleichen, übergeben und widerrufen
Prüfe das Ziel, aktualisiere Applikationsreferenzen, übergib gegebenenfalls Webhook-Geheimnisse und widerrufe Migrationsschlüssel in Stripe.
Was diese Kontrollen nicht garantieren
- Restricted Keys reduzieren Berechtigungen, bleiben aber sensible Geheimnisse mit Wirkung innerhalb ihres freigegebenen Umfangs.
- Der Ablauf nach 30 Tagen verhindert spätere Nutzung in MoveMRR; nur der Stripe-Kontoinhaber kann den Schlüssel auf Stripe-Ebene widerrufen.
- Vault schützt gespeicherte Live-Geheimnisse; Sicherheit hängt zusätzlich von Accountzugriff, Endpunkten, operativer Prüfung und Incident Response ab.
- Keine Verarbeitung roher Kartennummern bedeutet nicht, dass künftige Zahlungen jedes Kunden garantiert ohne Reibung funktionieren.
- Diese Seite behauptet weder SOC 2 noch ISO 27001, PCI-Zertifizierung oder eine andere externe Zertifizierung für MoveMRR.
Häufige Sicherheitsfragen
Speichert MoveMRR Stripe API Keys?
Bei einer regulären Migration werden gespeicherte Live-Schlüssel in Supabase Vault abgelegt und laufen nach 30 Tagen in MoveMRR ab. MoveMRR speichert Status- und Accountmetadaten, gibt das Live-Geheimnis nach der Speicherung aber nicht an den Browser zurück. Der Kontoinhaber widerruft den Schlüssel nach dem Projekt weiterhin selbst in Stripe.
Kann ich meinen normalen Stripe Secret Key verwenden?
Der dokumentierte MoveMRR-Weg ist ein eigener, zweckgebundener Restricted Key mit geprüften Berechtigungen. Ein breiter Schlüssel vergrößert die mögliche Wirkung und erschwert einen klaren späteren Widerruf.
Erhält MoveMRR die Kartennummern der Kunden?
Nein. MoveMRR verarbeitet keine rohen Kartennummern. Stripe kopiert geeignete Zahlungsdaten. MoveMRR arbeitet mit den Billing-Objekten, IDs und Zuordnungen, die zur Koordination der Abos nötig sind.
Was ist bei Sandbox-Seeding-Schlüsseln anders?
Sie sind separate einmalige Zugangsdaten für einen Seed Run: ein Live-Leseschlüssel zum Scannen und ein Test-Schreibschlüssel für die Sandbox. Sie werden an den Backend-Lauf übergeben und nicht als reguläre Projektschlüssel gespeichert.
Widerruft der Ablauf den Schlüssel automatisch bei Stripe?
Nein. Der Ablauf stoppt die Verwendung in MoveMRR nach dem Aufbewahrungsfenster. Der Stripe-Kontoinhaber sollte den Restricted Key nach Reconciliation oder bei Verdacht auf Offenlegung zusätzlich in Stripe widerrufen.
Garantiert dieses Modell eine risikofreie Migration?
Nein. Die Kontrollen reduzieren konkrete Risiken bei Zugangsdaten und Datenverarbeitung. Zusätzlich bleiben korrekte Berechtigungen, Dry-Run-Prüfung, Freigaben, Applikationsübergabe, Reconciliation und ein Plan für Ausnahmen nötig.
Primäre Plattformquellen
Stripe-Quellen definieren Schlüssel- und Kopierverhalten auf der Stripe-Plattform. Die Supabase-Quelle erklärt die verwendete Vault-Funktion. Produktspezifische Aussagen beziehen sich auf das oben angegebene Prüfdatum.
- Stripe Best Practices für API Keys (öffnet in einem neuen Tab)
Offizielle Hinweise zum Schutz, zur Einschränkung, Rotation und Gültigkeit von Stripe-Schlüsseln.
- Stripe Restricted Keys (öffnet in einem neuen Tab)
Offizielle Stripe-Dokumentation zur Einschränkung von Ressourcenberechtigungen.
- Stripe Customer Data Copy (öffnet in einem neuen Tab)
Offizieller Umfang geeigneter Zahlungsdaten und ausgeschlossener Stripe-Objekte.
- Supabase Vault (öffnet in einem neuen Tab)
Primärdokumentation zur Datenbankfunktion für gespeicherte Geheimnisse.