Kundendaten in App‑Demos schützen — sichere Demo‑Setups

Warum Kundendaten bei App‑Demos durchsickern

Die meisten Datenlecks in Demos sind Unfälle. Ein Dashboard ist mit echten Datensätzen vorbelegt, jemand sucht eine echte E‑Mail, um „zu zeigen, wie es funktioniert“, oder ein Autocomplete‑Feld füllt während der Präsentation einen echten Kundennamen aus.

Demos zeigen auch Verbindungen, an die Sie nicht mehr gedacht haben: Analytics‑Tools, E‑Mail‑Provider, Bezahlsysteme und Support‑Inboxen. Wenn Sie in Ihrem echten Workspace demoen, können aktive Ereignisse zur falschen Zeit auftauchen — eine neue Bestellung, ein Ticket‑Update oder eine Push‑Benachrichtigung.

„Kundendaten“ sind mehr als Name und E‑Mail. Dazu gehört alles, womit sich jemand identifizieren lässt oder was zeigt, was sie gekauft haben und warum sie Sie kontaktiert haben: Namen, E‑Mails, Telefonnummern, Adressen, Rechnungen, Zahlungsverläufe, Tarifdetails, Support‑Konversationen, interne Notizen, Nutzungsprotokolle, die an eine Person oder Firma gebunden sind, und hochgeladene Dateien.

Wenn das in einem Sales‑Call zu sehen ist, leiden mehrere Parteien. Ein Kunde fühlt sich exponiert oder verliert Vertrauen. Ihr Team landet in einem unangenehmen Datenschutz‑Gespräch. Ihr Ruf kann schnell Schaden nehmen, selbst wenn das Leck nur wenige Sekunden dauerte.

Das Ziel ist einfach: Demos so gestalten, dass echte Namen, E‑Mails und Datensätze niemals erscheinen — selbst wenn Sie die falsche Registerkarte anklicken.

Ein häufiges Beispiel: Sie öffnen „Kunden“, um Filter zu zeigen, und die Liste ist nach „zuletzt aktiv“ sortiert, mit echten E‑Mails sichtbar. Ein Screenshot später ist der Schaden da.

Übliche Stellen, an denen Datenlecks passieren

Die meisten Demo‑Lecks sind keine Hacks. Es sind ungeplante Dinge auf dem Bildschirm.

Wo echte Daten meistens auftauchen

Der größte Fehler ist, die Live‑Produktion zu demoen, weil sie „schon eingerichtet ist“. Das bringt echte Kundennamen, E‑Mails, Rechnungen und Support‑Threads nur einen Klick entfernt.

Andere Leckstellen sind leicht zu übersehen:

• Autocomplete, zuletzt verwendete Einträge und im Browser gespeicherte Logins können echte Accounts mit einem Klick offenbaren.
• E‑Mail‑Benachrichtigungen, Chat‑Widgets, Kalender‑Popups und CRM‑Alerts können über Ihrer Bildschirmfreigabe auftauchen.
• Logs, Admin‑Dashboards und Fehlerseiten geben oft komplette Datensätze aus (E‑Mails, Tokens, Adressen), weil sie fürs Debugging gebaut wurden.
• Integrations‑Bildschirme können Drittanbieter‑Daten zeigen (Payments, Slack‑Kanäle, Analytics‑Dashboards).
• Die gesamte Bildschirmfreigabe mit vielen offenen Tabs macht es leicht, beim Wechseln kurz etwas Sensibles zu zeigen.

Ein realistisches Szenario: Sie suchen nach „Acme“, um ein Kundenprofil zu zeigen, und das Dropdown schlägt „Acme – billing issue – [email protected]“ aus einer früheren Sitzung vor. Sie haben es nicht selbst getippt, aber alle haben es gesehen.

Behandeln Sie Support‑ und Admin‑Ansichten als hohes Risiko. Sie enthalten oft ausführliche Logs, weitreichende Berechtigungen und Komfort‑Shortcuts, die in der Entwicklung praktisch, vor der Kamera aber gefährlich sind.

Zwei Grundregeln: Fake‑Daten und ein dedizierter Demo‑Workspace

Zwei Regeln erledigen den Großteil der Arbeit: niemals echte Daten zeigen und niemals aus einem echten Workspace demoen.

Ein dedizierter Demo‑Workspace (oder Tenant) ist eine separate Kopie Ihrer App mit eigener Datenbank, eigenen Nutzern und Einstellungen. Er sollte wie das echte Produkt aussehen, aber isoliert sein, sodass nichts, was Sie im Call tun, echte Namen, E‑Mails, Bestellungen oder Support‑Tickets offenlegen kann.

Fake‑Daten sind kein zufälliger Füllstoff. Halten Sie sie klein, vorhersehbar und auf die Story zugeschnitten, die Sie erzählen. Eine kurze Liste von Beispielkunden, einige Rechnungen und ein oder zwei Edge‑Cases reichen meist.

Gute Demo‑Setups haben gemeinsame Merkmale: ein reiner Demo‑Workspace, ein winziger Datensatz mit offensichtlichen Platzhaltern (z. B. [email protected]), ein wiederholbarer Reset‑Prozess, Presenter‑Accounts mit minimalem Zugriff und sensible Felder standardmäßig verborgen.

Machen Sie Resets einfach. Wenn eine Demo damit endet, dass Sie Datensätze erstellen, Einstellungen ändern oder Dateien hochladen, brauchen Sie einen schnellen Weg, um in einen bekannten Zustand zurückzukehren. Das kann ein Datenbank‑Restore, ein Skript zum Befüllen oder eine „Factory Reset“-Funktion sein.

Schritt für Schritt: Ein sicheres Demo‑Umfeld einrichten

Ein sicheres Demo‑Setup dreht sich vor allem um Trennung. Ihre Demo sollte sich wie das echte Produkt verhalten, ohne echte Personen, Accounts oder Systeme zu berühren.

Erstellen Sie einen dedizierten Demo‑Workspace, der niemals für echte Kunden genutzt wird. Geben Sie ihm einen Namen wie „Demo Only“ und machen Sie die Unterscheidung zur Produktion klar.

Die Kernkonfiguration

Halten Sie die Reihenfolge simpel:

• Nutzen Sie eine separate Demo‑Datenbank mit eigenen Zugangsdaten.
• Deaktivieren Sie Produktions‑Integrationen (Zahlungen, CRM‑Sync, Analytics‑Exports, Dateispeicher).
• Seed‑en Sie gefälschte Nutzer, Firmen und Aktivitäten, die zur Demo‑Story passen.
• Schalten Sie ausgehende E‑Mails, SMS, Push‑Benachrichtigungen und Webhooks aus (oder leiten Sie sie in ein sicheres Ziel um).
• Verwenden Sie Demo‑spezifische API‑Keys und Secrets für Drittanbieter.

Machen Sie dann einen schnellen Sanity‑Check: Melden Sie sich als normaler Nutzer an und klicken Sie genau die Abläufe durch, die Sie zeigen werden.

Produktion unerreichbar machen

Der größte Sicherheitsgewinn ist, technisch unmöglich zu machen, dass Demo‑Code Produktion erreicht.

• Beschränken Sie den Netzwerkzugang, sodass Demo‑Server nur mit Demo‑Datenbanken sprechen können.
• Entfernen Sie Produktions‑Environment‑Variablen von Demo‑Hosts und CI.
• Sperren Sie Admin‑Screens, sofern Sie sie nicht wirklich brauchen.
• Bestätigen Sie, dass Logs und Fehlertracker keine echten Nutzerdaten ziehen.

Wie man Fake‑Daten erzeugt, die trotzdem glaubwürdig wirken

Glaubwürdige Fake‑Daten helfen, eine klare Produktstory zu erzählen, ohne jemandes echte Informationen offenzulegen.

Ersetzen Sie alles, was persönlich wirkt: Namen, E‑Mails, Telefonnummern, Adressen, Firmennamen und Profilfotos. Nutzen Sie realistische Formate, damit die App echt wirkt, vermeiden Sie aber alles, das zufällig auf eine reale Person passen könnte. Ein einfacher Grundsatz: Verwenden Sie reservierte Domains wie example.com und halten Sie Telefonnummern in offensichtlich gefälschten Bereichen.

Gewöhnen Sie sich daran, sensible Felder standardmäßig zu maskieren. Zeigen Sie z. B. Kartennummern als **** **** **** 1234, API‑Keys als sk_live_...9K und Telefonnummern als (***) *‑12. Vollständige Werte sollten erst nach einer bewussten Aktion sichtbar werden (und idealerweise nur im Admin‑Modus).

Für flüssige Demos seed‑en Sie einen Datensatz, der Ihre besten Features hervorhebt und ein paar Edge‑Cases enthält. Ein kompletter Account, ein chaotischer Account und ein Account mit hohem Volumen reichen oft aus, um Listen, Filter, Validierung und Pagination ohne Überraschungen zu zeigen.

Vergessen Sie Exporte nicht. Wenn Ihre Demo CSV/PDF erstellen kann, deaktivieren Sie Exportfunktionen im Demo‑Workspace oder redigieren Sie automatisch Spalten wie E‑Mail, Adresse, Notizen und IDs, die sensibel aussehen.

Automatisieren Sie das Nachfüllen. Ein Reset‑Skript (oder Button), das die Demo‑Daten löscht und neu anlegt, hält jeden Call sauber und vorhersehbar.

Berechtigungen im Demo‑Workspace einschränken

Behandeln Sie Ihren Demo‑Workspace wie eine öffentliche Bühne. Selbst wenn Sie allen auf dem Call vertrauen, gehen Sie davon aus, dass Screenshots gemacht werden und Fehler passieren.

Trennen Sie Konten. Behalten Sie ein echtes Admin‑Konto, das Sie nie auf Calls verwenden, und ein separates Presenter‑Konto mit eingeschränktem Zugriff.

Für die meisten Demos reicht Lesezugriff. Sie können Seiten durchklicken und Fragen beantworten, ohne eine versehentliche Änderung oder Löschung zu riskieren. Wenn Sie einen Edit‑Flow zeigen müssen, erstellen Sie eine enge Rolle, die nur Demo‑Datensätze bearbeiten darf.

Beginnen Sie damit, den Zugriff auf die Bereiche zu entfernen, die beim Offenlegen am meisten Schaden anrichten: Abrechnung, Benutzerverwaltung, Audit‑Logs, API‑Keys und Integrationen sowie Exporte.

Begrenzen Sie außerdem, was Listen und Suche zurückgeben können. Wenn jemand versehentlich eine echte E‑Mail eintippt, sollte Ihre App nichts zurückliefern. Scope‑en Sie Listenseiten auf Demo‑Tenant, Tags oder einen festen Datensatz und begrenzen Sie die Ergebnisse, damit die UI nie „alles“ lädt.

Fügen Sie eine visuelle Erinnerung hinzu, damit Sie nie vergessen, wo Sie sind. Ein auffälliges Banner mit „DEMO“ (und idealerweise ein anderes Theme) hilft, den klassischen Fehler zu vermeiden, Produktion während der Bildschirmfreigabe zu öffnen.

Reale Verbindungen und Benachrichtigungen deaktivieren

Eine Demo ist der schlechteste Zeitpunkt, um zu entdecken, dass Ihre App noch mit der echten Welt kommuniziert. Ein Klick auf „Senden“, ein automatischer Workflow oder ein Webhook‑Retry kann einen Kunden anschreiben, eine Karte belasten oder in einem echten Channel posten.

Schalten Sie alles ab, was außerhalb des Demo‑Workspaces senden oder synchronisieren kann: E‑Mail, SMS, Push, Payments, Analytics, Support‑Tools und Webhook‑basierte Automationen. Wenn Sie ein Feature zeigen müssen, nutzen Sie den Sandbox‑ oder Testmodus des Anbieters und vergewissern Sie sich, dass tatsächlich der Testmodus in der Demo‑Umgebung ausgewählt ist.

Blockieren Sie auch die stillen Dinge: Hintergrundjobs, geplante Reports, Willkommens‑Sequenzen und Fehler‑Alerts. Ein Demo‑Account, der echte Benachrichtigungen auslöst, kann Namen, E‑Mails oder interne URLs auf dem Bildschirm leaken, selbst wenn Sie die Integrationsseite nie öffnen.

Eine schnelle Pre‑Demo‑Prüfung, die die meisten Fehler auffängt:

• Stellen Sie ausgehende Kanäle auf No‑Op (E‑Mail, SMS, Push, Webhooks, Chat‑Widgets).
• Bestätigen Sie Sandbox‑Modus für Payments und Drittanbieter‑APIs.
• Deaktivieren Sie Scheduler und Worker, die Nachrichten versenden.
• Ersetzen Sie reale Analytics‑Keys durch leere oder Demo‑Properties.

Screen‑Share‑Hygiene: Gewohnheiten, die Ausrutscher verhindern

Viele Demo‑Lecks passieren, wenn der Call gut läuft und Sie für fünf Sekunden das Falsche teilen. Gute Screen‑Share‑Gewohnheiten reduzieren dieses Risiko, ohne das Gespräch zu verlangsamen.

Vor der Freigabe: 60‑Sekunden‑Reset — Benachrichtigungen pausieren, sauberes Browser‑Profil nutzen (keine gespeicherten Passwörter oder Autofill), unnötige Tabs schließen, bestätigen, dass Sie im Demo‑Workspace sind, und planen, mit Demo‑Suchbegriffen zu arbeiten.

Während des Calls: Langsamer tippen. Wenn Sie Suche zeigen müssen, verwenden Sie vorgefertigte Demo‑Begriffe wie „Acme Demo“ oder „Test User 03“ und halten Sie sie in einer Notiz zum Kopieren/Einfügen.

Haben Sie einen Backup‑Plan, damit Sie nicht versuchen müssen, live zu retten. Eine kurze Aufnahme des Happy Path und ein paar Screenshots wichtiger Bildschirme können den Call retten, wenn etwas merkwürdig aussieht.

Fehler, die zu Datenlecks führen (und wie man sie vermeidet)

Die meisten Demo‑Lecks entstehen durch kleine Entscheidungen, um ein paar Minuten zu sparen, die dann vergessen werden.

In Produktion zu demoen ist der schnellste Weg, Namen, E‑Mails, Support‑Tickets und interne Notizen offenzulegen. Beheben Sie das mit einem dedizierten Demo‑Workspace und Fake‑Daten.

Einen echten Kundenrekord „nur für die Demo“ zu klonen, bleibt oft bestehen und taucht in Suche, kürzlichen Listen und Autocomplete auf. Beheben Sie das, indem Sie glaubwürdige Fake‑Daten in Masse erzeugen, damit Sie nie echte Datensätze kopieren müssen.

Ein gemeinsamer Admin‑Login im Team erhöht die Chance, dass jemand den falschen Workspace öffnet und erschwert das Nachvollziehen von Änderungen. Geben Sie jedem Teammitglied ein demo‑spezifisches Konto mit minimalen Rechten.

Das Vergessen, E‑Mail, SMS, Push und Webhooks zu deaktivieren, kann reale Nachrichten auslösen (Passwort‑Resets, Rechnungen, Einladungen). Lösen Sie das, indem Sie ausgehende Kanäle stubs und automatisierte Kampagnen im Demo‑Umfeld ausschalten.

API‑Keys, Secrets oder Tokens in Einstellungen oder Logs sichtbar zu lassen, ist riskant, selbst bei „internen“ Calls, weil Aufnahmen und Screenshots passieren. Beheben Sie das, indem Sie sensible Konfigurationen verbergen, reale Keys aus Demo‑Builds entfernen und Logs davon abhalten, Tokens auszugeben.

Schnelle Checkliste vor dem Start eines Demo‑Calls

Verbringen Sie zwei Minuten mit den Grundlagen, bevor Sie den Bildschirm teilen.

• Bestätigen Sie, dass Sie im dedizierten Demo‑Workspace angemeldet sind und Header/Org‑Name klar als Demo angezeigt werden.
• Überprüfen Sie die Bildschirme, die Sie öffnen werden (Listen, Suchergebnisse, Profile, Rechnungen, Aktivitätslogs), und stellen Sie sicher, dass nur Fake‑Daten angezeigt werden.
• Schalten Sie alles ab, was echte Nachrichten verschicken kann (E‑Mail, SMS, Webhooks, Einladungen, Push).
• Nutzen Sie ein sauberes Browser‑Profil, schließen Sie irrelevante Tabs und deaktivieren Sie Desktop‑Benachrichtigungen.
• Halten Sie ein Fluchtfenster bereit (ein sicherer Dashboard‑Screen oder ein schneller Fensterwechsel).

Wenn Ihr Produkt Verbindungen zu Drittanbietern hat, überprüfen Sie Integrationen doppelt. Ein Demo, das in einen echten Slack‑Channel postet oder eine echte Passwort‑Reset‑E‑Mail sendet, kann binnen Sekunden zu einem Datenschutzvorfall werden.

Beispiel‑Szenario und nächste Schritte

Ein typischer Ausrutscher: Sie geben einen Sales‑Demo, jemand fragt „Kannst du nach Acme suchen?“ Sie tippen in die globale Suche und ein alter Datensatz erscheint mit echtem Kundennamen und E‑Mail aus der Produktion. Nun ist es auf dem geteilten Bildschirm.

Ein dedizierter Demo‑Workspace verhindert das auf zwei Wegen. Er enthält nur gefälschte Testdaten, und er verwendet separate Zugangsdaten sowie eine separate Datenbank, sodass Autocomplete und letzte Einträge keine echten Datensätze ziehen können.

Wenn mitten im Call etwas Sensibles erscheint, halten Sie es einfach: hören Sie auf zu tippen, wechseln Sie zu einem sicheren Bildschirm, sagen Sie kurz, dass Sie in den Demo‑Workspace wechseln, und machen Sie weiter aus einem bekannten, sicheren Ablauf.

Nach dem Call: notieren Sie, was passiert ist, und beheben Sie die Grundursache (Workspace‑Trennung, Datenmaskierung, Berechtigungen).

Wenn Sie eine KI‑generierte App geerbt haben, die Demo und Produktion mischt, oder Sie vermuten, dass Secrets und Integrationen falsch verdrahtet sind, kann FixMyMess (fixmymess.ai) helfen, indem sie den Codebestand diagnostizieren, Umgebungen trennen und riskante Pfade härten. Sie bieten ein kostenloses Code‑Audit an, um Probleme vor Commit zu identifizieren — viele Fixes lassen sich in 48–72 Stunden abschließen.