Los datos de registro de clientes fluyen a través de Pub/Sub hacia BigQuery. Debe redactar la identificación gubernamental al momento de la ingesta, pero permitir que el servicio al cliente vea los originales cuando esté autorizado. ¿Qué enfoque utiliza?

La opción correcta es usar Cloud DLP con tokenización criptográfica que preserve el formato. Esto permite reemplazar la identificación gubernamental con un token que mantiene el formato original, lo que facilita el análisis y la integración de datos sin exponer la información sensible. Cuando el servicio al cliente necesita ver el original, puede des-tokenizar los datos utilizando las claves apropiadas, ya que la tokenización criptográfica permite la reversibilidad. Las otras opciones son menos adecuadas: Cifrar la columna con BigQuery AEAD y almacenar las claves por separado es complejo y no es la solución principal para la redacción de datos sensibles que necesitan ser des-redactados selectivamente. La seguridad a nivel de columna de BigQuery solo restringe el acceso, no redacta los datos en el momento de la ingesta, lo que significa que la información sensible aún estaría presente en la base de datos. Reemplazar las ID con un hash criptográfico (no reversible) impediría que el servicio al cliente vea los originales, ya que el hashing es una función unidireccional.