Vaulted Tokenization
Vaulted Tokenization replaces a sensitive value with a random token and stores the encrypted original in ALTR’s Payment Card Industry (PCI)-compliant token vault, as a single entry per value.
In this section
Section titled “In this section”- Bring Your Own Key (BYOK) for Vaulted Tokenization — Use your own AWS KMS key in place of ALTR’s managed encryption key.
Deterministic and Non-Deterministic Modes
Section titled “Deterministic and Non-Deterministic Modes”Vaulted Tokenization operates in two modes. Non-deterministic mode (the default) produces a unique token each time the same value is tokenized, using the vaultn_ prefix — an attacker can’t determine whether two tokens represent the same value. Deterministic mode produces the same token every time the same value is tokenized, using the vaultd_ prefix, which enables joins, lookups, and deduplication on tokenized values without detokenization.
Vault Storage
Section titled “Vault Storage”Original values are encrypted and stored in ALTR’s PCI-compliant token vault, one entry per value.
A token is a random substitute with no mathematical relationship to the original value. See Data Tokenization for how this is intended to remove tokenized columns from Payment Card Industry Data Security Standard (PCI DSS) scope.
Vaulted Tokenization stores the encrypted original as a single vault entry. Critical Tokenization instead splits the encrypted original across separate, isolated storage locations.
Tokenization is available multi-region by default, for high availability.
Masking Policies with Detokenization
Section titled “Masking Policies with Detokenization”A masking policy with detokenization determines what a role sees when querying tokenized data. See Tokenization Access Policies for the three-level access model.
For Snowflake-specific mechanics — tag connections and native versus external-function masking — see Data Masking on Snowflake.