Enmascaramiento de datos

El enmascaramiento de datos anonimiza las columnas sensibles en el momento en que se crea un branch. Adjuntas una política de enmascaramiento a la llamada de creación del branch, y las columnas coincidentes del nuevo branch se reescriben de forma irreversible — con hash, anuladas, truncadas o reemplazadas — antes de que el branch sea siquiera accesible. El branch padre nunca se modifica.

Recurres a ello para entregar datos con forma de producción a desarrollo, CI o un contratista sin entregar la PII que contienen: formas de tabla reales, recuentos de filas reales, correos electrónicos falsos.

How it works

Una política de enmascaramiento es un conjunto de reglas con nombre y alcance de proyecto. Cada regla hace coincidir columnas por patrón y nombra una función de enmascaramiento integrada:

En el momento de la creación del branch, cuando se proporciona un masking_policy_id:

1. El branch se bifurca de su padre como de costumbre (copy-on-write — instantáneo).
2. El branch entra en el estado masking. No se aprovisiona ningún endpoint y el proxy rechaza las conexiones a él: no hay ninguna ventana en la que se puedan leer los datos previos al enmascaramiento.
3. Un worker de enmascaramiento se conecta a la compute del branch como un rol de mínimo privilegio, descubre el esquema, hace coincidir tus reglas con él y ejecuta cada reescritura en una sola transacción.
4. El branch aterriza en ready y sus endpoints se levantan — ahora sirviendo solo datos enmascarados. Ante cualquier fallo, el branch aterriza en failed y permanece sellado; elimínalo y reinténtalo.

Las entradas de las reglas se tratan como datos, nunca como SQL: los identificadores se entrecomillan y los valores de los argumentos se vinculan como parámetros en la ejecución, de modo que un nombre de columna o una constante hostil no puede escapar de la reescritura.

Built-in functions

El catálogo también lo sirve la API:

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

Managing policies

El enmascaramiento de datos se está desplegando progresivamente. El editor de políticas y el desplegable de creación de branch descritos aquí se habilitan de forma gradual; hasta que el enmascaramiento esté activo para tu cuenta, la API responde 501 not_implemented y la consola muestra un aviso de "todavía no disponible". Tus proyectos no se ven afectados mientras tanto.

En la consola, abre Project settings → Data masking para crear una política: ponle nombre, añade reglas (columnas de patrón + un desplegable de función) y guarda. La misma superficie existe en la 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"}
    ]
  }'

Luego crea un branch enmascarado añadiendo la política a una llamada normal de creación de branch:

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'"}'

El branch informa state: "masking" mientras se ejecuta la reescritura; obsérvalo cambiar a ready en la consola (en vivo, a través del flujo de eventos del proyecto) o sondeando GET /v1/branches/{id}.

Good to know

• El enmascaramiento es de una sola vez, en la creación. Editar una política nunca toca los branches que ya se crearon con ella — conservan la forma de datos con la que nacieron. Vuelve a crear el branch para aplicar las nuevas reglas.
• Una política en uso no se puede eliminar. Eliminar una política con la que se creó un branch activo devuelve 409 policy_in_use; elimina primero esos branches.
• Las reglas sin coincidencia se omiten, no son fatales. Si tu esquema se desvió y un patrón no coincide con nada, el branch igualmente se completa — revisa los patrones de las reglas si una columna que esperabas enmascarada todavía tiene una forma de datos real.
• Las discrepancias de tipo hacen fallar el branch. Una regla que coincide con una columna que su función no puede reescribir (digamos mask_email sobre un integer) aborta todo el enmascaramiento — el branch aterriza en failed y nunca se expone enmascarado a medias.