Sensible Datenmaskierung wird in den meisten Organisationen typischerweise den Anwendungsteams überlassen. In modernen Architekturen laufen jedoch Dutzende von Microservices, verschiedene Teams, unterschiedliche Release-Zyklen und Legacy-Anwendungen gleichzeitig. Eine in einem Service vergessene Kartennummer, ein Identitätsfeld, eine E-Mail-Liste oder ein Session-Token kann in eine Produktionsantwort oder in die Logs geraten.
Dieses Risiko beschränkt sich nicht auf externe Benutzerbildschirme. Debug-Logs, Access-Logs, SIEM-Datensätze, Fehler-Tracking-Systeme und von Support-Teams aufgerufene Datensätze können alle sensible Daten enthalten. Sobald Daten in ein Log-System eingetreten sind, wird die Bereinigung aufgrund von Aufbewahrungsrichtlinien, Backups und Zugriffskontrollen schwierig.
Einige Sicherheitslösungen erkennen sensible Daten nur oder maskieren nur auf Log-Ebene. Wenn jedoch die im Response-Body an den Benutzer zurückgegebenen Daten unberührt bleiben, geht das eigentliche Leck weiter. Einfache Nur-Replace-Ansätze sind auch nicht für jedes Szenario ausreichend — manchmal sollten nur die letzten vier Ziffern sichtbar sein, manchmal ist eine vollständige Maskierung erforderlich, und manchmal müssen bestimmte Zeichen ausgeschlossen werden.
Der richtige Ansatz besteht darin, den Schutz sensibler Daten in eine Edge-Richtlinie umzuwandeln, die nicht vom Anwendungscode abhängt. Response-Body, Log-IP-Informationen und Cookie-Inhalt müssen jeweils separat mit flexiblen Maskierungskontrollen wie Regex, String-Match, Maskierungszeichen, Offset und minimaler Vorkommen behandelt werden.
TR7 Sensitive Data Masking liefert dieses Modell: Es maskiert sensible Daten auf Plattform-Ebene, bevor sie Benutzer und Logs erreichen, und reduziert das Risiko von Datenlecks.
TR7 wendet sensiblen Datenschutz durch Response-Body-Maskierung, Log-IP-Anonymisierung, Cookie-Verschlüsselung und Erkennungssignale gemeinsam an.
TR7 kann sensible Felder im Response-Body durch String- oder Regex-Matching maskieren oder ersetzen. Der Backend-Service bleibt unverändert, während der dem Benutzer zurückgegebene Inhalt auf Edge-Ebene kontrolliert wird.
Die ipMask-Regel ermöglicht die Maskierung von Client-IP-Informationen in Logs. Dieser Ansatz trägt dazu bei, die Sichtbarkeit personenbezogener Daten in Datenaufbewahrungs- und Compliance-Prozessen zu reduzieren.
Die cookieEncryption-Regel kann ausgewählte Cookie-Werte mit AES-256-GCM verschlüsseln. Cookie-Inhalt wird auf der Benutzerseite unleserlich, während die Plattform diese Werte bei Bedarf im Anfrage-Ablauf verwalten kann.
Bekannte sensible Datenmuster wie Test-Kartennummern können als Sicherheitssignale erfasst werden. Diese Erkennungen machen die Möglichkeit von Datenlecks in Scoring-, Protokollierungs- und Vorfall-Review-Workflows sichtbar.
Sensitive Data Masking liefert unterschiedliche Datenschutzstrategien für Response-Body-, Log- und Cookie-Ebene gemeinsam.
Die modifyResponse-Regel läuft in der Antwortphase und kann übereinstimmende Daten im Response-Body verarbeiten. Der modifyType-Wert kann auf mask, replace oder htmlTag gesetzt werden. Der Mask-Modus verbirgt Zeichen, der Replace-Modus ersetzt den gesamten Wert, und der htmlTag-Modus fügt kontrollierten HTML- oder Skript-Code zur Antwort hinzu. Diese Flexibilität deckt nicht nur das Verbergen von Daten, sondern auch Szenarien ab, die eine Response-Transformation erfordern.
TR7 kann über die Felder matcher und matcherType mit einem Literal-String oder Regex abgleichen. Operatoren können eigene Muster für nationale Ausweisnummern, IBANs, Kartennummern, Telefonnummern, E-Mail-Adressen oder organisationsspezifische Datenformate definieren. Es gibt keinen vorgefertigten PII-Katalog; die Kontrolle hängt von dem vom Operator definierten Muster ab. Dieser Ansatz unterstützt verschiedene Länder- und Branchenformate mit gleicher Flexibilität.
maskChar ermöglicht die Auswahl des Maskierungszeichens und wird als einzelnes Zeichen validiert. maskOffset steuert, wie viele Zeichen vom Anfang oder Ende sichtbar bleiben; bei 0 wird die gesamte Übereinstimmung maskiert. maskFrom verhindert, dass die Maskierung angewendet wird, bis eine Mindestanzahl von Vorkommen erreicht ist. Diese Einstellungen machen sowohl die Benutzererfahrung als auch das Falsch-Positiv-Risiko besser kontrollierbar.
Bei Daten wie Kartennummern oder Kontoangaben ist es manchmal vorzuziehen, nur die letzten wenigen Zeichen anzuzeigen, anstatt alles zu verbergen. TR7 kann dieses Verhalten mit maskOffset konfigurieren. Beispielsweise ist es möglich, die letzten vier Ziffern sichtbar zu lassen und die restlichen Zeichen zu maskieren. Dies bewahrt die Benutzerfreundlichkeit in Support- und Kundenverifizierungsabläufen und reduziert gleichzeitig das Datenleckage-Risiko.
Im Replace-Modus werden die übereinstimmenden Daten vollständig durch den konfigurierten Ersatzwert substituiert. Dies eignet sich für Teams, die einen sensiblen Wert lieber durch ein festes Label, einen leeren Wert oder einen Organisations-Standard-Platzhalter ersetzen möchten, anstatt ihn mit Sternchen zu versehen. Der Replace-Ansatz sollte insbesondere dann sorgfältig verwendet werden, wenn das Antwortformat intakt bleiben muss. Der Operator kann die Maskierungs- oder Ersetzungsstrategie für jedes Muster unabhängig wählen.
TR7 kann chunked oder streaming eingehende Antworten in der Antwort-Body-Verarbeitung in die Maskierungs-Pipeline einbeziehen. Dies bietet Datenschutz in modernen Anwendungen, ohne eine Single-Chunk-Body-Annahme vorauszusetzen. Die Body-Verarbeitung muss zusammen mit Buffer-Limits geplant werden. Bei sehr großen Antworten sollten Leistung, Speicher und Maskierungsumfang an die Anforderungen des Services angepasst werden.
Response-Body-Maskierung kann so geplant werden, dass sie innerhalb eines Standardlimits von 16 KB arbeitet. Das Limit kann bei Bedarf über die Oberfläche erhöht werden, aber Maskierungsentscheidungen bei Hunderten von Megabytes müssen gegen die Leistungsauswirkung abgewogen werden. Dieses Limit hilft, Edge-Level-Datenschutz und Traffic-Leistung in Balance zu halten. Operatoren legen den Umfang auf kritischen Services bewusst fest.
Die cookieEncryption-Regel wird verwendet, um zu verhindern, dass Cookie-Inhalt auf der Client-Seite lesbar bleibt. Ausgewählte Cookie-Werte können mit AES-256-GCM verschlüsselt werden. Die Regel ist so konzipiert, dass sie einmal pro Pool verwendet wird, um wiederholte Konflikte zu verhindern. Sitzungs- oder Sticky-Cookie-Daten werden für den Benutzer damit als bedeutsamer Inhalt unsichtbar.
Die ipMask-Regel hilft dabei, Client-IP-Informationen in Log-Feldern zu maskieren. Diese Funktion reduziert das Log-Aufbewahrungsrisiko in Umgebungen mit Datenschutzanforderungen ähnlich GDPR oder lokalen Datenschutzbestimmungen. Die Sichtbarkeit personenbezogener Daten auf der Datensatzseite kann eingeschränkt werden, während der Anwendungsverkehr weiterläuft. Sicherheits- und Compliance-Teams verwalten Log-Detailebene und Datenschutzanforderungen gemeinsam.
TR7 kann bekannte Test-Kreditkartennummern-Muster als Sicherheitssignale erfassen. Diese Erkennung muss nicht als Maskierungsregel fungieren; sie kann als Scoring-, Protokollierungs- und Vorfall-Review-Signal verwendet werden. Test- oder Entwicklungsdaten, die in Produktionsantworten auftauchen, werden auf diese Weise schneller sichtbar. Betriebsteams können dieses Signal aus der Perspektive von Datenlecks oder falscher Umgebungsnutzung überprüfen.
Sensible Datenmaskierung wird zusammen mit Response-Filter-Verhalten, Regex-Handling, Mask-Parametern, Cookie-Verschlüsselung, IP-Maskierung und Body-Limits betrieben.
Jede modifyResponse-Regel kann als separater Filter auf dem Response-Body laufen. Übereinstimmende Inhalte werden durch Maskierung oder Ersetzung geleitet und die Antwort wird zurückgeschrieben. Da diese Verarbeitung in der Antwortphase erfolgt, muss sie separat von Anfrage-seitigen Regeln bewertet werden.
Wenn matcherType auf regex gesetzt ist, wird musterbbasiertes Matching verwendet; bei string wird Literal-Matching angewendet. Regex-Regeln sind mächtig, müssen aber sorgfältig geschrieben werden. Zu breite oder aufwändige Muster können Performance- und Falsch-Positiv-Risiken einführen.
maskChar wird als einzelnes Zeichen validiert. Der Standardwert ist das Sternchen. Die Einzelzeichen-Anforderung hilft, die Maskierungsausgabe vorhersehbar und konsistent zu halten.
Wenn maskOffset 0 ist, kann die gesamte Übereinstimmung maskiert werden; bei höheren Werten kann eine festgelegte Anzahl von Zeichen sichtbar bleiben. Der maskFrom-Wert legt die Mindestanzahl von Vorkommen fest, bevor die Maskierung angewendet wird. Diese Einstellungen sind besonders wichtig für die Balance zwischen Falsch-Positiv-Reduzierung und Lesbarkeit.
cookieEncryption, ipMask und modifyResponse sind keine Varianten derselben Pipeline — sie arbeiten als verschiedene Regeltypen. Response-Body-, Log- und Cookie-Ebene werden jeweils mit eigenem Verhalten geschützt. Diese Trennung macht es möglich, für jeden Datenleck-Kanal die geeignete Kontrolle zu wählen.
Response-Body-Maskierung wird innerhalb von Buffer-Limits bewertet. Das Standard-16-KB-Limit ist für viele API-Antworten ausreichend; größere Antworten können durch Erhöhen des Limits über die Oberfläche berücksichtigt werden. Leistungsauswirkungen und Speichernutzung bei großen Werten müssen separat geplant werden.
Banking-Teams können kartenähnliche Werte mit Regex erfassen und maskieren, sodass nur die letzten vier Ziffern sichtbar sind. Der Response-Body wird auf Edge-Ebene geschützt, ohne den Backend-Service zu ändern.
Gesundheitsportale können vom Operator definierte Regex-Muster für nationale Ausweisnummern oder Patientenreferenznummern schreiben. Übereinstimmende Daten werden vollständig maskiert, was die Wahrscheinlichkeit reduziert, dass sensible Informationen den Benutzerbildschirm oder Zwischensysteme erreichen.
Compliance-Teams können ipMask verwenden, um Client-IP-Informationen in Logs zu maskieren. Dies reduziert die Sichtbarkeit personenbezogener Daten während der Log-Aufbewahrung, während der betriebliche Datensatzstrom erhalten bleibt.
E-Commerce- und Finanzdienstleistungen können cookieEncryption verwenden, um ausgewählte Sitzungs- oder Sticky-Cookie-Werte zu verschlüsseln. Cookie-Inhalt wird auf der Benutzerseite als bedeutsame Daten unsichtbar, was das Manipulationsrisiko reduziert.
Datenleckage-Prävention über Response-Body-, Log- und Cookie-Ebenen. Lassen Sie uns einen Live-Setup auf Ihren eigenen Services durchführen.