Cambio de fechas

Las fechas son un tipo de datos muy común y útil. Sin embargo, en algunos casos, las fechas deben ser ofuscadas, ocultadas o generalizadas. Un método para hacer esto es la generalización, o agrupamiento. Otro es el cambio de fechas. Sin embargo, según el caso práctico y la configuración, el agrupamiento puede quitar la utilidad de las fechas. Por ejemplo, si generalizas todas las fechas a solo un año, podrías perder el orden en que ocurren los eventos. Un método alternativo para ofuscar fechas que resuelve este problema es el cambio de fechas.

Las técnicas de cambio de fechas cambian un conjunto de fechas de forma aleatoria, pero conservan la secuencia y la duración de un período. En general, el cambio de fechas se realiza en el contexto de un individuo o una entidad. Es decir, debes cambiar todas las fechas para un individuo específico con el mismo diferencial de cambio, pero debes usar un diferencial de cambio distinto para cada individuo.

Ejemplo de cambio de fechas

Considera los siguientes datos:

user_id date action
1 09/06/2009 correr
1 03/06/2009 caminar
1 23/05/2009 gatear
2 03/11/2010 gatear
2 22/11/2010 caminar

Si generalizamos estas fechas al año, obtendremos lo siguiente:

user_id date_year action
1 2009 correr
1 2009 caminar
1 2009 gatear
2 2010 gatear
2 2010 caminar

Se perdió cualquier sentido de la secuencia para cada usuario.

En su lugar, probemos el cambio de fechas:

user_id date action
1 17/07/2009 correr
1 11/07/2009 caminar
1 30/06/2009 gatear
2 26/01/2011 gatear
2 14/02/2011 caminar

Observa cómo las fechas son diferentes, pero se conservan la secuencia y la duración. Las magnitudes del cambio de fechas fueron diferentes para los user_id 1 y 2.

Cambio de fechas en Cloud DLP

La configuración para hacer esto con la API de Cloud DLP se parece a la siguiente:

deidentify_config {
  record_transformations {
    field_transformations {
      fields {
        name: "date"
      }
      primitive_transformation {
        date_shift_config {
          upper_bound_days: 100
          lower_bound_days: -100
          entity_field_id {
            name: "id"
          }
          crypto_key {
            unwrapped {
              key: "123456789012345678901234567890ab"
            }
          }
        }
      }
    }
  }
}

Los límites inferior y superior del cambio se especifican con los valores respectivos lower_bound_days y upper_bound_days. El contexto o ámbito al que se aplicará ese cambio se basa en el valor de entity_id_field, que en este caso es "user_id".

Observa también el uso de una crypto_key. Esto es similar a su uso en la seudonimización. La clave te permitirá mantener la integridad de estos cambios de fechas en múltiples solicitudes o ejecuciones de datos

Recursos

Si quieres obtener más información sobre cómo desidentificar datos mediante el cambio de fechas y otros métodos en Cloud DLP, consulta lo siguiente:

Si quieres obtener información de referencia de la API sobre transformaciones básicas en la API de Cloud DLP, consulta lo siguiente:

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

Cloud Data Loss Prevention