Datenmaskierung

Datenmaskierung anonymisiert sensible Spalten in dem Moment, in dem ein Branch erstellt wird. Sie hängen eine Maskierungsrichtlinie an den Branch-Erstellungsaufruf an, und die passenden Spalten des neuen Branches werden unwiderruflich umgeschrieben — gehasht, auf NULL gesetzt, gekürzt oder ersetzt —, bevor der Branch überhaupt erreichbar ist. Der Parent-Branch wird nie verändert.

Sie greifen darauf zurück, wenn Sie produktionsähnliche Daten an die Entwicklung, CI oder einen externen Dienstleister übergeben möchten, ohne die darin enthaltene PII mit zu übergeben: echte Tabellenformen, echte Zeilenzahlen, falsche E-Mail-Adressen.

How it works

Eine Maskierungsrichtlinie ist ein projektbezogener, benannter Satz von Regeln. Jede Regel ordnet Spalten nach Muster zu und benennt eine integrierte Maskierungsfunktion:

Zum Zeitpunkt der Branch-Erstellung, wenn eine masking_policy_id angegeben wird:

1. Der Branch forkt wie gewohnt von seinem Parent (Copy-on-Write — sofort).
2. Der Branch geht in den Zustand masking über. Es wird kein Endpoint bereitgestellt und der Proxy verweigert Verbindungen zu ihm: es gibt kein Zeitfenster, in dem die unmaskierten Daten gelesen werden können.
3. Ein Maskierungs-Worker verbindet sich mit der Compute des Branches als Rolle mit minimalen Rechten, ermittelt das Schema, ordnet Ihre Regeln dagegen zu und führt jedes Umschreiben in einer einzigen Transaktion aus.
4. Der Branch landet im Zustand ready und seine Endpoints kommen hoch — und liefern nun nur noch maskierte Daten aus. Bei jedem Fehler landet der Branch im Zustand failed und bleibt versiegelt; löschen Sie ihn und versuchen Sie es erneut.

Regeleingaben werden als Daten behandelt, nie als SQL: Bezeichner werden in Anführungszeichen gesetzt und Argumentwerte werden bei der Ausführung als Parameter gebunden, sodass ein bösartiger Spaltenname oder eine bösartige Konstante nicht aus dem Umschreiben ausbrechen kann.

Built-in functions

Der Katalog wird auch von der API bereitgestellt:

curl -s https://api.test.kisenon.com/v1/masking-functions \
  -H "Authorization: Bearer $KISENON_API_KEY"

Managing policies

Die Datenmaskierung wird schrittweise ausgerollt. Der hier beschriebene Richtlinien-Editor und das Dropdown bei der Branch-Erstellung werden nach und nach aktiviert; bis die Maskierung für Ihr Konto aktiv ist, antwortet die API mit 501 not_implemented und die Konsole zeigt einen Hinweis „noch nicht verfügbar" an. Ihre Projekte sind in der Zwischenzeit nicht betroffen.

Öffnen Sie in der Konsole Project settings → Data masking, um eine Richtlinie zu erstellen: benennen Sie sie, fügen Sie Regeln hinzu (Muster-Spalten + ein Funktions-Dropdown) und speichern Sie. Dieselbe Oberfläche existiert auf der API:

curl -s -X POST \
  https://api.test.kisenon.com/v1/projects/$PROJECT_ID/masking-policies \
  -H "Authorization: Bearer $KISENON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "dev-safe",
    "rules": [
      {"table_pattern": "users", "column_pattern": "email", "masking_fn": "mask_email"},
      {"table_pattern": "users", "column_pattern": "phone", "masking_fn": "mask_null"},
      {"table_pattern": "%", "column_pattern": "%ssn%", "masking_fn": "mask_ssn_partial"}
    ]
  }'

Erstellen Sie dann einen maskierten Branch, indem Sie die Richtlinie zu einem normalen Branch-Erstellungsaufruf hinzufügen:

curl -s -X POST \
  https://api.test.kisenon.com/v1/projects/$PROJECT_ID/branches \
  -H "Authorization: Bearer $KISENON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "masked-dev", "masking_policy_id": "'$POLICY_ID'"}'

Der Branch meldet state: "masking", während das Umschreiben läuft; beobachten Sie, wie er in der Konsole auf ready umspringt (live, über den Event-Stream des Projekts) oder indem Sie GET /v1/branches/{id} abfragen.

Good to know

• Maskierung erfolgt einmalig, bei der Erstellung. Das Bearbeiten einer Richtlinie berührt nie Branches, die bereits mit ihr erstellt wurden — sie behalten die Datenform, mit der sie geboren wurden. Erstellen Sie den Branch neu, um die neuen Regeln anzuwenden.
• Eine in Verwendung befindliche Richtlinie kann nicht gelöscht werden. Das Löschen einer Richtlinie, mit der ein aktiver Branch erstellt wurde, gibt 409 policy_in_use zurück; löschen Sie zuerst diese Branches.
• Nicht passende Regeln werden übersprungen, nicht fatal. Wenn Ihr Schema abgewichen ist und ein Muster auf nichts passt, wird der Branch trotzdem abgeschlossen — prüfen Sie die Regelmuster, wenn eine Spalte, die Sie maskiert erwartet hatten, immer noch die echte Datenform hat.
• Typabweichungen lassen den Branch fehlschlagen. Eine Regel, die auf eine Spalte passt, die ihre Funktion nicht umschreiben kann (etwa mask_email auf einem integer), bricht die gesamte Maske ab — der Branch landet im Zustand failed und wird nie halbmaskiert offengelegt.