SPEAKER: Our favorite cat walking company
has been using Cloud DLP to automatically
redact and replace sensitive values from their data.
But what about data that they need to protect
but still use for things like billing?
Stick around and find out how Cloud DLP's got them covered.
Kitty Cat Walks has already implemented Cloud DLP
to apply redaction and replacement in their issue
ticketing system so they don't inadvertently
log any sensitive information from their customers.
Their billing department, on the other hand,
handles tons of credit card numbers.
They need to protect that information
but also access those values to process
payments for their premium cat walking service.
So while Cloud DLP offers a bunch of options
to help you hide and remove sensitive values in your data,
there's one technique that leverages encryption
to de-identify and, in some cases,
re-identify those sensitive values.
Crypto-based tokenization, also referred
to as pseudonymization, is a powerful de-identification
technique that uses encryption keys to replace sensitive data
values with cryptographically generated tokens.
This method of de-identification is especially
popular in industries like finance and health care,
where protecting data is a matter of utmost importance,
but preserving data utility is still desired.
Cloud DLP supports three types of cryptographic methods.
First is deterministic encryption.
Here, the detected data is replaced
with an encrypted value and prepended
with an optional surrogate annotation.
This method supports most input types
and is authenticated, which makes it
the most recommended tokenization solution.
The next method is Format Preserving Encryption, FPE.
Like deterministic encryption, FPE
will replace the value of an encrypted string,
except it's going to be the same length
and use the same character set as the original value.
This is the way to go if you need
to retain support for any legacy data systems
that have strict length character set requirements.
The third method is cryptographic caching.
Here, DLP replaces sensitive data with a hash value.
Unlike the other two methods, cryptographic caching
uses a one-way token so it can't be reversed.
It's the perfect solution if you want each unique value
to be transformed into a corresponding unique hash
value, but don't necessarily want it to be reversible.
More on that later.
One huge factor that sets all three
of these apart from most other de-identification techniques
is that they allow us to securely
de-identify data while retaining its referential integrity.
Referential integrity allows records
to maintain the relationship to one another,
even after being individually identified.
For example, if we have this table
of data with cryptographic hashing applied
to one of its fields using the same cryptographic key,
each of the unique values will have a consistent transformed
value.
This means that data can be de-identified for security
or compliance reasons, but still used for business operations
and analytical workflows, such as joining across tables
or aggregating data.
So another powerful feature of tokenization
is the ability to reverse the encryption
to re-identify the data.
Since deterministic encryption and format preserving
encryption uses symmetric encryption key
to tokenize data, the same key can
be used to essentially undo the de-identification
to reveal the original value.
The option to re-identify expanse utility of Cloud DLP
so that data can be securely obscured
and readable only by systems authorized
to access the encryption key and the output value.
Let's see how the DLP API handles tokenization
by looking at this request from a Node.js app.
In this example, we're going to apply format preserving
encryption to the credit card number field of this sample CSV
data that out set to a variable myCSV.
This is the request object that will
send to the de-identified content function.
First, we want to specify the CSV data that we want to scan.
In the de-identification configuration,
we'll indicate a few things.
Here, in the transformations array,
is where we indicate each of the transformations we'd
like to apply.
In this case, we just want to target the info type credit
card number and provide an FPE configuration for format
preserving encryption.
There, we provide a wrapped key, which
I've contained in the variable myWrappedKey,
and the Cloud KMS key we used to wrap it in the form of a KMS
resource name.
And I threw it into the variable myKeyName.
We'll also specify that we want to transform our data using
a numeric alphabet and provide a surrogate info type
string that will be prepended to each value.
The responses function will include
the data we provided in the request,
except with the credit card numbers replaced
with an encrypted string and prepended with a surrogate info
type we specified.
As you can see, each unique value in our original data
remains unique after transformation.
With its referential integrity intact, in a larger data set
we'd still be able to analyze the data without accessing
the sensitive values.
So how about re-indentification?
The re-indentified content function
takes this request object.
It looks similar to the de-identified content request,
except we'll be passing our de-identified data.
As long as the surrogate info type and the encryption key
we provide matches what we use to tokenize our data,
the result will be our original data
with the sensitive values revealed.
Now that Kitty Cat Walks have added crypto-based tokenization
to their DLP know-how, their security and compliance teams
can sleep soundly knowing that their customer billing
information is well-protected on their systems.
Next time, we'll take what they've learned so far
and see how they'll use it to construct DLP templates so
that they can reuse inspection and de-identification
rules across different systems and processes.
See you soon.
[MUSIC PLAYING]