Welche Felder du vor dem Weiterleiten von Tickets und Chatverläufen maskieren musst

Support kopiert eine Kundennachricht ins Ticket-System. Ops exportiert eine Anmeldeliste nach Slack. Entwicklung hängt einen Fehlerlog in einen Thread. Diese drei Bewegungen passieren täglich. Der letzte Beitrag behandelte welche URL-Parameter du entfernen darfst: utm_source und fbclid können weg; id= muss bleiben. Danach hören viele auf. Eine deutsche Mobilnummer wie 0151 23456789, eine elfstellige Steuer-ID, eine PAN und eine E-Mail verschwinden nicht, nur weil der Link kürzer wurde.

Die Frage ist nicht „sollen wir maskieren“, sondern wie du zwei Arten von Zeichenketten trennst. Alles, womit die nächste Person einen Menschen erreicht oder Geld bewegt, gehört hinter Sternchen. Bestell-IDs, Ticketnummern und SKUs lokalisieren Arbeit, nicht Personen — maskierst du die, kann die nächste Schicht denselben Datensatz nicht öffnen. Tabelle, Ausnahmen und Checks unten bleiben bei dieser einen Entscheidung. MyPassGen’s Seite Links säubern nutzt dieselbe Grenze für Textmaskierung. Dieser Artikel ist keine Tool-Tour. Er beantwortet, welche Felder du vor dem Weiterleiten eines Tickets oder Chatverlaufs maskieren musst — und wie du das Ergebnis prüfst.

Saubere URL heißt nicht sauberer Text

Die DSGVO Artikel 4 definiert personenbezogene Daten als Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Telefonnummer, Personalausweisnummer oder E-Mail in einem Ticket liegen auf der Seite „identifizierbar“. Leitest du das vollständige Original in den nächsten Kanal, die nächste Tabelle oder das nächste „Online-Tool“ weiter, leitest du auch die Fähigkeit zur Identifikation mit.

Artikel 9 behandelt Gesundheitsdaten, biometrische Merkmale und ähnliche Kategorien als besonders schützenswert. Das deutsche BDSG § 46 und die DSGVO-Recitals nennen explizit, dass Datenminimierung der Maßstab für Support-Kommunikation ist: schicke, was die nächste Person braucht, um die Aufgabe zu erledigen — nicht die komplette Kundenakte. Eine volle PAN in Slack zu posten oder Kontaktdaten eines Minderjährigen auf einem öffentlichen Ticket zu lassen, verfehlt diesen Test.

Die Normen setzen nicht jeden Sternchenpunkt für dich fest. Sie liefern eine Vorgabe: Die Kopie, die du sendest, soll die Arbeit fortsetzen lassen, ohne dass jemand eine vollständige Nummer sieht. Reicht eine Maske oder eine Ticket-ID, sende das. Muss eine benannte Person einen live Schlüssel erhalten, schreibe den live Schlüssel nicht in den Ticket-Text. Nutze einen Einmal-Kanal.

Felder, die maskiert werden müssen

Die Tabelle gruppiert Felder, die du in Tickets, Anmeldelisten, Demo-Decks und eingefügten Logs wirklich siehst. Sie ist kein vollständiger Compliance-Katalog — Anbieter erfinden ständig neue Präfixe — deckt aber die Werte ab, die am häufigsten durchsickern. Nach der Maske soll erkennbar bleiben: „Das ist ein Telefon / eine ID / eine E-Mail“ — aber nicht mehr unverändert nutzbar sein.

Telefonnummern: Wenn es noch wählbar ist, bist du nicht fertig

ITU-T E.164 begrenzt eine internationale öffentliche Nummer auf 15 Ziffern ohne internationales Präfix. Das Plus ist Notation, keine Ziffer. Deutsche Mobilnummern werden oft mit führender Null geschrieben; international als +49 ohne die Null. Eine Ticket-Maske wie 0151 ****6789 sagt dem nächsten Agenten „das ist ein Telefon“, ohne eine wählbare Nummer zu liefern.

Ziehe Ziffern aus Leerzeichen, Klammern und +49, bevor du entscheidest. Match nicht nur einen kompakten Zehn-Ziffern-Lauf. Umgekehrt: Ein 8- bis 15-stelliger Block kann eine Bestell-ID sein. Ohne +, Trennzeichen oder erkennbare Mobilform behandle nicht jede lange Zahl als Telefon. Die Bestell-ID zu maskieren ist der häufigere Fehler — die nächste Schicht findet die Rechnung nicht mehr.

Ausweisnummern: Die Mitte identifiziert

Eine US-SSN hat neun Ziffern in drei Gruppen. Öffentliche Beispiele der Social Security Administration maskieren als ***-**-1234: letzte vier behalten, damit Mitarbeitende „ist das dieselbe Person?“ prüfen können — Bereich und Gruppe verbergen. Eine bloße Neun-Ziffern-Kette ist nicht automatisch eine SSN. Bereich 000, 666 oder führende 9 sowie Gruppen oder Serien aus Nullen sind ungültig — oft eher Bestell-IDs oder Tippfehler.

Die deutsche Steueridentifikationsnummer hat elf Ziffern ohne Prüfziffer im Sinne einer IBAN — trotzdem ist sie personenbezogen. Maskiere mindestens die Mitte; oft reicht gar kein Hinweis im externen Kanal. Eine Personalausweisnummer mischt Buchstaben und Ziffern; eine gängige Outbound-Maske behält Anfang und Suffix, damit die Form erkennbar bleibt, und deckt die Mitte. Grenzüberschreitende Tickets enthalten manchmal eine 18-stellige chinesische Personalausweisnummer — die mittleren acht Ziffern sind ein Geburtsdatum. Nur die letzten vier zu maskieren und das Geburtsdatum stehen zu lassen, leitet Alter und Region weiter. Dieselbe Regel wie bei der SSN: Form von „das ist eine ID“ behalten, Mitte nehmen, die sagt welche Person.

Zahlungskarten: Die Anzeige-Obergrenze ist kein Ziel

Eine Primary Account Number (PAN) trägt eine per Luhn-Algorithmus berechnete Prüfziffer (ISO/IEC 7812-1 Anhang B). Luhn fängt Tippfehler ab, beweist aber keine aktive Karte. Länge meist 13 bis 19 Ziffern. PCI DSS erlaubt zur Anzeige höchstens die ersten sechs und letzten vier. Ohne konkreten BIN-Bedarf nutze nicht die volle Obergrenze.

Fast kein ausgehendes Ticket braucht den BIN. Letzte vier reichen für „ist das die Karte mit Endung 4242“. Volle PAN und Karteninhabername in derselben Slack-Nachricht stapeln Finanzkonto mit Identitätsdaten — schlimmer als eine einzelne Endung. Behandle eine lange Zahl nur als Karte, wenn Luhn passt. Scheitert der Test, eher „Geschäfts-ID“ und Sendungsnummer in Ruhe lassen.

E-Mail, Schlüssel und Adressen

Der identifizierende Teil einer E-Mail sitzt vor dem @. Erstes Zeichen behalten, Rest maskieren, Domain lassen. Das reicht meist, um Geschäfts- von Privatpostfach zu unterscheiden, ohne hinschreiben zu können. local@domain unverändert weiterzuleiten, übergibt einen Kontaktkanal an jeden, der den Thread öffnet.

API-Schlüssel tragen meist ein Familien-Präfix: sk- / sk_live_, AKIA / ASIA, AIza, ghp_ / github_pat_, glpat-, npm_, xoxb- und das Token nach Bearer. Das Präfix benennt die Familie — nicht damit jemand die API weiter aufrufen kann. Authentifiziert die maskierte Zeichenkette noch, hast du zu wenig maskiert — oder der live Schlüssel gehört nie ins Ticket. Ein vollständiger Schlüssel gehört auf einen Einmal-Link, mit dem Schlüssel nach # in der URL. Die Lese-Seite braucht kein Konto.

Bei IPv4 reichen meist die ersten zwei Oktette (Dokumentationsbereich 203.0.113.0/24 als 203.0.*.*), um Anbieter oder Büroblock zu erkennen, ohne einen Host zu pinpointen. Dasselbe für private Adressen, VPN-Ausgänge und Heim-DSL in Stacktraces: letzte zwei Oktette maskieren.

Zahlenketten, die stehen bleiben müssen

Im Fließtext gilt dieselbe Trennung wie in der Query-String. Manche Zahlen wirken zufällig, dienen aber dazu, denselben Datensatz zu öffnen. Maskierst du die, bricht die Übergabe.

• Bestellungen und Versand: Shop-Bestell-IDs, Sendungsnummern, RMA-Nummern. Länge überlappt oft mit Telefon oder PAN, aber die Zeichenkette hat weder Telefon- noch Luhn-Form.
• Tickets und Objekt-IDs: Zendesk-/Jira-Keys, interne User-IDs, SKUs, Auto-Increment-Datenbank-IDs. Der Grund fürs Weiterleiten ist oft, dass jemand anderes dieselbe Zeile öffnet.
• Builds und Zeitstempel: Build-Nummern, kurze Commit-Präfixe, Timestamps. Maskierst du die, sterben Reproduktionsschritte.

Ein Check in der Notiz-App: Kopiere den ausgehenden Text, bearbeite einen Typ nach dem anderen (Telefon, dann ID, dann Karte), und lies nach jedem Durchgang erneut. Sind Geschäfts-IDs noch da? Parsen die Sätze noch? Ersetze nicht jede lange Zahl pauschal durch Sternchen und rate dann, welche du kaputt gemacht hast.

Pass- oder PNR-ähnliche „ein bis zwei Buchstaben plus sechs bis neun Ziffern“ verwechselt man leicht mit Kennzeichen oder Buchungsreferenzen. Scheitert eine Prüfsumme, oder der Kontext ist klar Flug und Sitz, lass stehen und markiere von Hand. Diese Entscheidung nicht an einen einzigen Regex delegieren.

Maskierung ist keine Anonymisierung

DSGVO Erwägungsgrund 26 zählt anonyme Informationen nur dann nicht mehr unter die Verordnung, wenn die Person nicht mehr identifizierbar ist. Artikel 4 Abs. 5 definiert Pseudonymisierung als Verarbeitung, die ohne zusätzliche Informationen nicht mehr einer Person zugeordnet werden kann. Ein Ticket mit 0151 ****6789 plus Name, Adresse und Bestell-ID ist im Helpdesk weiter identifizierbar. Das ist bestenfalls Pseudonymisierung. Es ist keine Anonymisierung — und keine Lizenz zur Veröffentlichung.

Formuliere das Ziel korrekt: direkte Nutzbarkeit beim nächsten Forward, Screenshot, Kanal reduzieren. Maskierung erlaubt nicht, das Resultat öffentlich zu posten, und ersetzt nicht „nur senden, was nötig ist“. Namen, Straßenadressen, Gesichter, Kinderdaten und live Schlüssel sitzen oft dort, wo kein Regex hinschaut: andere Spalte, Pixel im Screenshot, durch Leerzeichen geteilte Nummer.

Name, Telefon, Ausweis und Wohnadresse in einer Nachricht sind sensibler als ein einzelnes maskiertes Telefon. Kannst du trennen, pack nicht alle vier in eine Slack-Zeile. Reicht eine Ticketnummer, damit die andere Person den Datensatz selbst öffnet, kopiere die Kundenakte nicht aus dem System heraus.

Vor Ort prüfen: Text nebeneinander, Sternchen und Network

Slogans lassen sich nicht prüfen. Zeichen schon. Diese Schritte hängen nicht an einem Markenversprechen. Notiz-App und DevTools reichen.

1. Füge das vollständige ausgehende Original lokal ein und behalte eine unberührte Kopie — maskiere nicht aus dem Gedächtnis.
2. Nutze die Tabelle oben: zuerst Telefone, dann IDs, Karten, E-Mails. Ein Typ pro Durchgang. Geschäfts-IDs vorerst stehen lassen.
3. Stelle Original und Ergebnis nebeneinander. Maskierte Felder zeigen Sternchen oder Äquivalent. Bestell-IDs, SKUs und Daten bleiben lesbar.
4. Suche im Ergebnis nach vollständigem Telefon aus dem Original, voller SSN oder Local-Part vor @. Findest du es noch, bist du nicht fertig.
5. Listet ein Tool Treffer-Typen im Browser, lies die Liste gegen die Sternchen im Ergebnis. Typ auf der Liste mit passender Maske im Output ist fertig. Typ auf der Liste mit vollständigem Wert noch sichtbar ist nicht.
6. DevTools → Network, „Preserve log“ aktivieren, Maskierung erneut ausführen. Document- und API-Requests dürfen das eingefügte Original nicht enthalten. Analytics darf keine volle ID oder volles Postfach tragen.

MyPassGen’s Seite Links säubern arbeitet an dieser Grenze. Unter Datensanierung wählst du einen Typ — Telefon, Ausweisnummer, Bankkarte, E-Mail, API-Schlüssel oder IP — und vergleichst Original mit Ergebnis nebeneinander. NANP-Nummern maskieren als letzte vier; E.164 behält einen Ländercode-Hinweis; eine 18-stellige chinesische Personalausweisnummer wird per ISO 7064 geprüft, bevor maskiert wird; Karten laufen durch Luhn, dann bleiben nur die letzten vier (enger als „erste sechs + letzte vier“); E-Mails behalten das erste Zeichen des Local-Parts. Die Verarbeitung endet im aktuellen Tab. Das Original wird nicht hochgeladen und nicht in Analytics geschrieben. Du brauchst kein Konto. Die Seite ist Hilfsmittel — wichtige Fälle brauchen weiter deinen menschlichen Durchgang.

Screenshots, Tabellen und die Illusion „schon maskiert“

Eine Tabelle ist schwerer als ein Absatz. Telefon in Spalte A, Name in B, gescannter Ausweis als Bild auf Seite drei. Textregeln sehen keine Pixel. Vor dem Senden eines Decks: unbeschnittene Ausweisfotos, Screenrecordings mit vollständiger Nummer, Excel mit Original in versteckter Spalte oder zweitem Blatt.

Chat-„Antwort“ zitiert die vorherige Nachricht. Du maskierst die neueste Zeile; im Zitat steht die vollständige Nummer noch. Slack-Threads, E-Mail-Forwards und Intercom-Notizen machen dasselbe. Klappe das Zitat auf, bevor du sendest, oder schreibe eine neue Nachricht ohne Zitat. Einen ganzen Mail-Thread weiterzuleiten, leitet auch frühe, unmaskierte Signaturen und Ticket-Bodies mit.

Kurzlink oder QR-Code repariert den Fließtext nicht. Der letzte Artikel behandelte Kurzlinks als Redirect-Schicht. Ergänzung: Leute schreiben „Bestellung für 0151 23456789“ in Seitentitel oder utm_content. Nach dem Streichen der Tracking-Namen bleiben Titel und Absatz. URL säubern und Text maskieren sind zwei Jobs. Keiner ersetzt den anderen.

Typische Fehler

„Letzte vier reichen beim Telefon.“ Die ersten sechs Ziffern einer deutschen Nummer stehen zu lassen und nur die letzten vier zu verbergen, liefert viel Kombinationsmaterial für People-Search-Dumps. Nur-Endung ist ein Display-Kompromiss, kein Beweis. Bei der SSN Bereich und Gruppe stehen lassen und nur die Seriennummer verbergen ist derselbe halbe Job.

„HTTPS schützt schon die Privatsphäre.“ HTTPS stoppt Mithörer auf dem Weg. Empfänger, jedes Kanalmitglied und jeder Helpdesk-Admin sehen weiter den Klartext, den du eingefügt hast. Du reduzierst unnötige vollständige Nummern in der Kopie, die du sendest.

„Maskiert heißt veröffentlichbar.“ Nach Pseudonymisierung kann der Helpdesk die Person noch re-identifizieren. Öffentliche Seite, externe Fallstudie oder Trainingsdeck braucht Information, die ohne Zusatzdaten nicht rückführbar ist — das ist Anonymisierung. Ein paar Sternchen sind es nicht.

„Die Regel lief schon, Review können wir sparen.“ Geteilte Nummern (0151 234 56789), ausgeschriebene Ziffern, IDs in Bildern und Schlüssel-Präfixe, die die Regel nicht kennt, leaken. Der menschliche Durchgang: Findest du im Ergebnis noch ein vollständiges Original per Suche — und lässt sich aus dem verbleibenden Kontext dieselbe Person noch zusammensetzen?

Wo mit dem Maskieren anfangen

Beginne mit dem einen Absatz, den du heute senden willst. Kopiere lokal, maskiere zuerst Telefone, vergleiche mit dem Original, entscheide dann, ob IDs und E-Mails denselben Durchgang brauchen. Alte Kanal-Themen und Wissensdatenbank-Seiten können warten. Du musst nicht die ganze Historie in einer Sitzung säubern.

Mischt ein Paste URL und Fließtext, streiche zuerst UTM und Klick-IDs mit der Tabelle aus dem vorherigen Artikel, dann maskiere den Text. Enthält eine Nachricht Bestell-ID und Telefon, behalte die Bestell-ID, maskiere das Telefon, lies den Satz erneut. Nach diesem einen Durchgang kannst du die Überschrift schon beantworten: maskiere Felder, die eine Person erreichen oder Geld bewegen; lass IDs, die denselben Geschäftsdatensatz öffnen.

Muss eine benannte Person ein live Passwort, Recovery-Code oder API-Schlüssel erhalten, schreibe das vollständige Geheimnis nicht ins Ticket — und behandle eine Maske nicht als „haben wir nicht gesendet“. Erzeuge einen Einmal-Link. Eine Datei, die mehrfach entschlüsselbar sein muss, gehört in die Datei-Verschlüsselungsbox, die auf diesem Gerät eine .lock- / .enc-Datei erzeugt; Passphrase getrennt senden. Textmaskierung reduziert vollständige Nummern in einer Diskussion — sie ist kein Schlüsselaustausch-Kanal.

FAQ

Weiß die andere Person nach der Maskierung noch, wer das ist?

Oft ja. Ticket-ID, Name und maskiertes Telefon zusammen lassen sich im Helpdesk weiter auflösen. Maskierung reduziert die Chance, dass jemand außerhalb dieses Systems aus einer vollständigen Nummer anruft oder sich ausgibt. Sie macht aus dem Text keine anonyme Statistik.

Warum wurde diese Zehn-Ziffern-Kette nicht als Telefon behandelt?

Ein langer Ziffernlauf ohne Mobilform, ohne führende 0 oder +49 und ohne Trennzeichen ist eher eine Bestell-ID. Jeden Lauf als Telefon zu behandeln maskiert den Locator, den die nächste Schicht braucht. Im Zweifel stehen lassen, nur Nummern bearbeiten, die wie NANP, + oder bekannte Mobilform aussehen — Rest von Hand markieren.

Reicht bei Karten nur die Endung für Compliance?

PCI-DSS-Anzeige-Obergrenze ist erste sechs + letzte vier. Nur-Endung ist enger und reicht meist zur Bestätigung einer Endung. Das ist trotzdem keine Erlaubnis, die Nummer in einem öffentlichen Kanal zu posten. Volle PAN plus Name gehört nicht in Slack.

Brauche ich ein Konto zum Maskieren? Wird das Original hochgeladen?

Nein, kein Konto. Das Log-Risiko beginnt, wenn du ein vollständiges Ticket an eine Seite gibst, die das Original hochlädt. Lokale Verarbeitung hält das Original im aktuellen Tab. Du prüfst, ob Network eine volle ID oder ein volles Postfach an Dritte geschickt hat — und ob du im Ergebnis noch eine unmaskierte vollständige Nummer findest.