Les données d'enregistrement des clients transitent via Pub/Sub vers BigQuery. Vous devez masquer les identifiants gouvernementaux lors de l'ingestion, mais permettre au service client de consulter les originaux lorsqu'il est autorisé. Quelle approche utilisez-vous ?

L'utilisation de Cloud DLP avant le chargement pour tokeniser les identifiants gouvernementaux avec un jeton de chiffrement cryptographique préservant le format est la meilleure approche. Cela permet de masquer les données sensibles pendant l'ingestion (conformité) tout en conservant leur format original, ce qui est crucial pour les applications qui attendent un format spécifique. Le service client peut ensuite détokeniser les données pour accéder aux originaux lorsqu'il est autorisé, répondant ainsi à l'exigence de consultation des originaux. Chiffrer la colonne ID avec BigQuery AEAD et stocker les clés dans une nouvelle table accessible uniquement aux utilisateurs autorisés est une option de chiffrement, mais la déchiffrement en temps réel pour le service client peut être plus complexe à gérer et ne préserve pas le format. Utiliser la sécurité au niveau des colonnes de BigQuery est une bonne pratique pour contrôler l'accès, mais elle ne masque pas les données pendant l'ingestion ; elle contrôle seulement qui peut les voir une fois qu'elles sont dans BigQuery. Utiliser Cloud DLP avant le chargement pour remplacer les ID par un hachage cryptographique masque les données, mais un hachage est unidirectionnel et ne permet pas de récupérer les identifiants originaux, ce qui va à l'encontre de l'exigence du service client.