Kurzantwort

Eine White-Label-SEO-Agentur muss jeden Kunden als Berechtigungsgrenze behandeln, nicht als Ordner in einer gemeinsamen Oberfläche. Wende das Prinzip der geringsten Rechte an. Nutze personenbezogene Konten, eine bei jeder Anfrage geprüfte Trennung, begrenzte Freigabelinks, ein Zugriffsprotokoll, eine Aufbewahrungsdauer und einen getesteten Widerruf. White Label ändert das Erscheinungsbild und die Vertragskette; es mindert weder die DSGVO-Pflichten noch die Haftung für einen falschen Zugriff.

Das Wichtigste in Kürze

  • Den Namen eines Kunden zu verbergen heißt nicht, ihn zu isolieren: Die Berechtigung muss serverseitig für jedes Objekt geprüft werden.
  • Geteilte Zugangsdaten verhindern die Zurechnung und verzögern den Widerruf.
  • Search Console und Analytics bieten Rollen; beginne mit der schwächsten, die wirklich ausreicht.
  • Kartiere Verantwortlichen, Auftragsverarbeiter, Zwecke, Orte, Aufbewahrung und Löschung vor dem Onboarding.
  • Stelle eine Produktfunktion niemals ohne technischen und vertraglichen Nachweis als Sicherheitsgarantie dar.

Das Bedrohungsmodell einer Agentur mit mehreren Kunden

Eine Agentur bündelt nützliche Daten: Anfragen, Leistungskennzahlen, Umsätze, Kalender, unveröffentlichte Inhalte, CMS-Zugänge und Wettbewerbsstrategie. Im White Label kann ein Dienstleister ohne direkte Beziehung für den Endkunden arbeiten, was Akteure, Exporte und Freigabekanäle hinzufügt.

Die wahrscheinlichsten Bedrohungen sind nicht alle raffiniert:

  • ein an den falschen Empfänger weitergeleiteter Berichtslink;
  • ein für Kunde A berechtigter Nutzer, der die Kennung in der URL ändert und Kunde B sieht;
  • ein Export, der mehrere Kunden enthält;
  • ein API-Schlüssel in einem Tabellenblatt oder Ticket;
  • ein ehemaliger Freiberufler, dessen Konto aktiv bleibt;
  • eine Automatisierung, die mit dem falschen Markenprofil veröffentlicht;
  • personenbezogene Daten, die „für alle Fälle" ohne Frist aufbewahrt werden;
  • ein Unteranbieter, der in der Vertragsdokumentation fehlt.

OWASP führt die fehlerhafte Objektberechtigung unter den wichtigsten API-Risiken. Die Kontrolle besteht nicht darin, Kennungen schwer erratbar zu machen: Der Server muss prüfen, dass die aktuelle Identität auf dem angeforderten Objekt handeln darf.

Minimale Datenklassifizierung

Klasse SEO-Beispiele Zugriff Aufbewahrung Zusätzliche Kontrolle
Öffentlich Öffentliche SERP, veröffentlichte Seite Berechtigtes Team Nach fachlichem Bedarf Herkunft und Datum
Intern Briefing, Kalender, Diagnose Account-Team Vertragsdauer plus Richtlinie Eingeschränkte Freigabe
Vertraulich Conversions, Margen, strategische Anfragen Benannte Rollen Begründetes Minimum Protokoll und kontrollierter Export
Geheim OAuth-Token, API-Schlüssel, CMS-Secret Das benötigende System bzw. der Dienst Rotation und Widerruf Secret-Vault, nie in Protokollen
Personenbezogene Daten E-Mail, Kennung, Lead, Verhalten Dokumentierter Zweck Definierte Dauer Rechtsgrundlage, Rechte, Minimierung

Die Klassifizierung hängt von Kontext und Regulierung ab. Eine scheinbar anonyme Anfrage kann sensibel werden, sobald sie mit einem Nutzer oder einer regulierten Branche verknüpft wird.

Verfahren in zwölf Schritten

1. Akteure und Verantwortlichkeiten kartieren

Identifiziere Endkunde, Hauptagentur, White-Label-Dienstleister, Software und Auftragsverarbeiter. Dokumentiere, wer die Zwecke festlegt, wer die Daten verarbeitet und wer Anfragen beantwortet. Die DSGVO unterscheidet Verantwortlichen und Auftragsverarbeiter; die vertragliche Bezeichnung genügt nicht, wenn die Praxis etwas anderes zeigt.

2. Ein Datenverzeichnis führen

Für jede Quelle: Kategorie, Zweck, Kunde, Verantwortlicher, Land bzw. Region, Zugriff, Auftragsverarbeiter, Aufbewahrung, Löschung und Export. Daten, deren Zweck unbekannt ist, sollten nicht standardmäßig erhoben werden.

3. Eine eindeutige Kundengrenze definieren

Jede Ressource muss eine unveränderliche Kundenkennung tragen. Datenbanken, Objekte, Dateien, Caches, Jobs und Protokolle müssen sie nutzen. Leite den Kunden nicht aus einem frei eingegebenen Domainnamen oder einer im Prompt genannten Marke ab.

4. Die Berechtigung bei jedem Zugriff prüfen

Die Regel lautet: authentifizierter Nutzer plus Rolle plus Kundenzugehörigkeit plus Berechtigung für die Handlung plus Vertragsstatus. Teste Lesen, Schreiben, Export, Freigabe und Administration. Verweigere standardmäßig.

5. Personenbezogene Konten und geringstes Privileg nutzen

Lade jede Person mit ihrer beruflichen Identität ein. Aktiviere Mehrfaktor-Authentifizierung, wo verfügbar. Vermeide geteilte „agentur@"-Konten. Wähle für Search Console und Analytics die ausreichende Rolle und prüfe sie nach dem Auftrag erneut.

6. OAuth und Secrets verwalten

Fordere die minimalen Scopes (OAuth-Berechtigungen) an. Speichere Token in einem Secrets-System, verschlüssele sie gemäß der freigegebenen Architektur, schließe sie aus Protokollen aus und plane Rotation und Widerruf. Ein Analytics-Lesezugriff deckt kein CMS ab: Jede Integration hat ihr eigenes Risiko.

7. Umgebungen und Ausgaben trennen

Nutze getrennte Testkonfigurationen. Jeder Export und jede Benachrichtigung muss vor dem Versand den Quellkunden anzeigen. E-Mail-Vorlagen, Logos, Domains, Absender und Markenstimmen müssen durch eine berechtigte Konfiguration gewählt werden, nicht durch den zuletzt gespeicherten Wert.

Ein dauerhaft öffentlicher Link zu einem vertraulichen Bericht ist ein verzögertes Leck. Bevorzuge Authentifizierung, Ablauf, definierte Zielgruppe, Widerrufbarkeit und Protokoll. Ist ein Download nötig, kennzeichne den Kunden und minimiere die Spalten.

9. Protokollieren, ohne Secrets zu kopieren

Erfasse Akteur, Kunde, Handlung, Objekt, Ergebnis, Datum und nützliche Herkunft. Protokolliere keine Token, Passwörter, vollständigen personenbezogenen Inhalte oder vertraulichen Prompts ohne Notwendigkeit. Schütze die Protokolle vor Änderung und lege ihre Dauer fest.

10. Aufbewahrung und Löschung festlegen

Der Grundsatz der Datenminimierung der DSGVO verlangt angemessene, erhebliche und auf das Notwendige beschränkte Daten. Schreibe eine Dauer je Kategorie, eine gesetzliche Ausnahme und ein überprüfbares Löschverfahren einschließlich Sicherungen auf.

11. Den Vorfall vorbereiten

Definiere Erkennung, Qualifizierung, Eindämmung, Beweissicherung, Meldung, Korrektur und Nachbereitung. Eine Vermischung von Kunden erfordert zuerst, den betroffenen Pfad zu unterbrechen, die Protokolle zu sichern und genau zu bestimmen, welche Personen und Daten betroffen sind.

12. Das Offboarding testen

Am Ende: Nutzer entfernen, OAuth und Schlüssel widerrufen, Veröffentlichung deaktivieren, Assets übertragen, vertragsgemäß löschen, Nachweis aufbewahren und Auftragsverarbeiter prüfen. Führe diesen Test vor dem ersten echten Abgang durch.

Matrix aus Kontrollen und Tests

Kontrolle Positivtest Negativtest Erwarteter Nachweis
Kundenlesen Mitglied A liest Ressource A Mitglied A fordert Ressource B an 200, dann kontrollierter 403/404
Export Export A enthält nur A Anfrage mit eingeschleustem Filter B Begrenzte Datei, protokolliertes Ereignis
CMS-Veröffentlichung Redakteursrolle veröffentlicht eine berechtigte Seite Analystenrolle versucht zu veröffentlichen Handlung, dann Ablehnung
Freigabelink Berechtigter Empfänger vor Ablauf Abgelaufener oder widerrufener Link Zugriff, dann Ablehnung
OAuth-Widerruf Aufruf funktioniert vor dem Entzug Derselbe Aufruf nach dem Entzug Berechtigungsfehler
Automatischer Job Job mit gültiger tenant_id Job ohne Kunde oder mit falschem Kunden Ausführung, dann Ablehnung
White Label Logo, Domain, Absender von Kunde A Eingeschleuste Vorlage B Ausgabe A, dann Blockade
Löschung Objekt und aktive Indizes entfernt Unberechtigte Wiederherstellung Löschbericht

Durchgerechnetes Beispiel: ein über die Kennung offengelegter Bericht

Ein fiktives Beispiel. Eine Agentur sendet Kunde A den Link /reports/1042. Ein Mitarbeiter ersetzt 1042 durch 1043 und sieht den Bericht von Kunde B. Die Kennungen waren nicht geheim, aber die eigentliche Ursache ist die fehlende Berechtigungsprüfung am Objekt.

Die „Korrektur", eine längere UUID zu verwenden, reicht nicht. Das Team:

  1. deaktiviert die öffentlichen Links;
  2. sichert die Protokolle und ermittelt, welche Berichte einsehbar waren;
  3. prüft die Meldepflichten mit dem zuständigen Verantwortlichen;
  4. ergänzt eine nach Nutzer und Kunde begrenzte Abfrage;
  5. verweigert standardmäßig Objekte außerhalb des Bereichs;
  6. ergänzt kundenübergreifende Tests für Lesen, Export und Freigabe;
  7. widerruft die alten Links;
  8. dokumentiert den Vorfall und die Aufbewahrung.

Der Regressionstest muss zwei Kunden und zwei Rollen anlegen und dann alle verbotenen Kombinationen versuchen. Nur den erlaubten Pfad zu testen belegt keine Isolation.

Interner Risikoscore

Nutze eine einfache Formel, um die Kontrollen zu ordnen:

Priorisiertes Risiko = Wirkung × Wahrscheinlichkeit × Exposition × Schwierigkeit der Erkennung.

Bewerte jeden Faktor auf einer dokumentierten internen Skala. Der Score ersetzt keine gesetzliche Pflicht: Ein Risiko einer Datenschutzverletzung oder einer verletzten Kundengrenze kann blockierend bleiben, auch wenn seine geschätzte Häufigkeit gering ist.

Was die Daten belegen und nicht belegen

Die DSGVO und die CNIL-Leitfäden legen Grundsätze und Empfehlungen zu Sicherheit, Minimierung, Rechten und Beziehungen zu Auftragsverarbeitern fest. Sie zertifizieren deine Umsetzung nicht. Eine unterzeichnete Richtlinie belegt nicht, dass die API die Kundenzugehörigkeit prüft.

OWASP liefert eine Taxonomie und Risikoszenarien; das ist weder ein Audit von SEOryon noch ein Nachweis eines Vorfalls. Googles Dokumentation beschreibt Rollen und OAuth seiner Dienste; sie deckt die CMS, Exporte oder Dienstleister deiner Kette nicht ab.

Eine Community-Frage zum „Kundenportal-Problem" zeigt qualitative Nachfrage nach Werkzeugen. Sie bestätigt keine der im Thread genannten Lösungen und misst nicht, wie häufig Vorfälle auftreten.

Häufige Fehlschläge und Abbruchkriterien

  • Geteiltes Konto: Zugriff stoppen und personenbezogene Identitäten anlegen.
  • Kunde über einen veränderbaren Parameter bestimmt: serverseitige Begrenzung verlangen.
  • Secret in einem Protokoll oder Ticket: widerrufen, verfahrensgemäß bereinigen und untersuchen.
  • Export ohne Zähler je Kunde: die Funktion bis zum Test sperren.
  • Unbekannter Auftragsverarbeiter: Übermittlung aussetzen und Vertrag sowie Standort klären.
  • Ungetestete Löschung: keine Frist versprechen, die die Architektur nicht belegen kann.
  • Automatische Veröffentlichung mit falscher Marke: den Job stoppen und alle Ausgaben des Loses prüfen.
  • Annehmen, „nur Lesen" sei risikofrei: Die gelesenen Daten können hochvertraulich bleiben.
  • Eine undokumentierte Zertifizierung oder Verschlüsselung annehmen: vor jeder werblichen Aussage aktuellen Nachweis verlangen.

Wiederverwendbares Asset: Register für Zugriff, Daten und Widerruf

Führe eine Zeile je Berechtigung: Kunde, Person bzw. Dienst, System, Rolle, Scopes, Zweck, Freigebender, Datum der Erteilung, letzte Nutzung, Prüfdatum, Widerrufsdatum und Nachweis. Verknüpfe sie mit einer Datenzeile: Kategorie, Ort, Auftragsverarbeiter, Aufbewahrung und Löschung.

Zwei Kennzahlen sind nützlich:

  • Quote aktueller Prüfungen = im Zeitfenster geprüfte Zugriffe ÷ aktive Zugriffe;
  • Widerrufsfrist = tatsächliches Widerrufsdatum abzüglich Enddatum der Berechtigung.

Mach aus 100 % Prüfquote keinen Beleg für Gesamtsicherheit. Sie belegt nur, dass diese Kontrolle gemäß ihrer Definition ausgeführt wurde.

So bringt sich SEOryon ein

Die geprüften öffentlichen Funktionen zeigen, dass SEOryon Search Console und Analytics im Lesezugriff nutzt und in mehrere CMS veröffentlichen kann. Der Lesezugriff verringert die möglichen Handlungsarten auf diesen beiden Quellen; er macht die Daten nicht unsensibel. Die CMS-Veröffentlichung beinhaltet naturgemäß eine gesonderte, zu regelnde Berechtigung.

Keine weitere Aussage zu Verschlüsselung, SSO, Standort, Zertifizierungen, Protokollen, Mandantentrennung oder Löschfristen darf ohne überprüfbare, aktuelle öffentliche Dokumentation auf dieser Seite ergänzt werden. Die Agentur muss die Einstellungen, den Vertrag, die Auftragsverarbeiter und die Tests des eigenen Deployments prüfen.

Messbare Übung

Lege zwei Testkunden, zwei Nutzer und drei Rollen an. Führe die Matrix aus Lesen, Schreiben, Export, Freigabe und Veröffentlichung aus und simuliere dann einen Abgang. Die Übung gelingt, wenn:

  1. alle kundenübergreifenden Kombinationen scheitern;
  2. kein Secret in den Protokollen erscheint;
  3. widerrufene Links nicht mehr funktionieren;
  4. OAuth und CMS innerhalb der internen Frist entzogen werden;
  5. ein Lösch- und Übergabebericht erzeugt wird;
  6. eine andere Person die Tests reproduzieren kann.

Empfohlener Weg

FAQ

Macht White Label die Agentur für die Daten des Endkunden verantwortlich?

Die Verantwortung hängt von den tatsächlichen Rollen und Verarbeitungen ab, nicht nur vom angezeigten Logo. Kartiere Verantwortlichen, Auftragsverarbeiter und Weisungen und lass den passenden rechtlichen Rahmen prüfen.

Dürfen Berater ein Search-Console-Konto teilen?

Vermeide das. Nutze personenbezogene Konten mit der Mindestrolle, einer Prüfung und einem Widerruf. Ein geteiltes Konto macht es unmöglich, den Akteur genau zu bestimmen.

Ist ein Analytics-Lesezugriff risikofrei?

Nein. Er kann Leistungsdaten, Conversions und Geschäftsdaten offenlegen. Der Lesezugriff begrenzt Änderungen, nicht Vertraulichkeit oder Abfluss.

Wie belegt man die Isolation zwischen Kunden?

Teste die verbotenen Pfade: Lesen, Ändern, Export, Cache, Suche, Job, Freigabelink und Protokoll. Eine Oberfläche, die andere Kunden ausblendet, reicht nicht.

Was muss am Vertragsende gelöscht werden?

Zugänge, Token, Schlüssel, Freigaben, Jobs und Daten gemäß Zweck, Vertrag, gesetzlichen Pflichten und Sicherungsrichtlinie. Bewahre einen Nachweis auf, ohne den gelöschten Inhalt unnötig aufzubewahren.

Quellen

Methoden- und Aktualisierungshinweis

Dieser Leitfaden liefert allgemeine technische und organisatorische Kontrollen, keine Rechtsberatung und kein Produktaudit. Überprüft am 16. Juli 2026, übersetzt und redigiert am 22. Juli 2026. Die Seite ist zu überarbeiten bei regulatorischen Änderungen, geänderten Google-Rollen, neuen öffentlichen SEOryon-Integrationen, geänderten Auftragsverarbeitern oder einer geänderten Multi-Client-Architektur.