SPEAKER: If you've been following along
with this series, you've got a pretty good understanding
of the different techniques that Cloud DLP uses to find, hide,
and protect sensitive data.
Today, we'll find out how easy it
is to build and reuse your commonly used DLP
configurations.
Stay tuned.
Kitty Cat Walks has already been using DLP to inspect
and de-identify different data sources like archive chat
log files, issues from their ticketing system databases,
and data that they collect from customers for billing.
Chances are, if you're anything like Kitty Cat Walks,
the data you want to protect may be from different sources.
And you may want to inspect and de-identify
that data consistently using the same configuration each time.
This is where DLP templates come in.
Templates allow you to save DLP configuration details
and reuse them against any data that you might have,
essentially decoupling configuration information
from the implementation of your request.
There are two types of templates.
An inspection template is going to save any configuration
having to do with the process of inspecting your data,
like what infotypes you want to discover,
a likelihood threshold, maximum number of findings to return,
and exclusion rules.
You can even use an inspection template
to define your own custom infotype.
Let's see what it looks like to create a template
with some Node.js code.
Here's an example of a request that
will send the createInspectTemplate function
to create an inspection template that's configured to find phone
numbers and email addresses with a minimum likelihood
of possible.
Once it's been created, here's what that template looks
like in our Cloud console.
There's the infotypes we specified
and the likelihood too.
Let's edit our inspection template
to also include person name.
We go here where it says Manage Infotypes
and enter person name in the search box.
Select it and click Done.
Now that we've saved our change, our inspection template details
page specifies three infotypes.
Note this template path at the top of the page.
We'll use that in a second.
To see our template in action, let's check out
this inspection request.
Instead of constructing an inspection configuration object
for this inspection request, we can simply
reference the inspection template
we created using the path name like this.
Our response, of course, would be
the results of the inspection.
As expected, we've got a phone number, an email, and a name.
This is really useful if you have several inspection
jobs set up against different data sources that
inspect for the same infotypes.
Instead of editing each inspection configuration
separately, you can simply update the template details.
But hold up a second.
What about de-identification?
Well, the second type of DLP template
is a de-identification template.
A de-identification template is going
to save any configuration having to do
with the process of de-identifying your data.
For every positive result in a de-identification request,
the template will have a corresponding transformation
to apply to it.
This is also where you would specify
transformation-specific customizations like replacement
strings or encryption keys.
De-identification templates can be
applied not only to inspection results,
but also to values in a specified field in a database
table.
Here's an example of how we can use
the createDeidentifyTemplate function
to create a new de-identification template.
Here, we're specifying that we want
to replace email addresses with the corresponding infotype.
And we also want to make sure that the names are
replaced with a custom replacement value.
Once it's been created, here's what the template looks
like back in our Cloud console.
Each infotype we specified and its transformation
is listed here as a transformation rule.
Just like our inspect template, we
can edit it here to include additional infotypes.
Let's edit this template to apply masking to phone numbers.
Down here, we'll add a transformation rule
and choose Mask with character.
Now we can configure our masking for this transformation rule.
We'll specify the infotype phone number down here
where it says Manage Infotypes.
Now that it's saved, there is our new transformation rule.
De-identification templates include a test page
where we can get a quick preview of the transformations
we configured in the template.
Emails will be replaced with infotype,
names are going to be replaced with a replacement string,
and phone numbers will be masked with hash symbols.
Now let's see our de-identification template
do its thing in a de-identification request.
Instead of including a deidentifyConfig block
in a request, we can reference our de-identification template
once again using the path name from the Details page.
You'll notice that we're referencing our inspection
template from before to specify what
infotypes we're inspecting for.
And here is a response from the request.
The inspection template found a phone number, name,
and email address.
And a de-identification template applied the transformations
we specified accordingly.
Using templates is a powerful way
to decouple your inspection and de-identification
configuration from your workflows
and your implementation.
Inspection templates can be configured
to inspect up to 150 built-in and custom infotypes.
And de-identification templates can
use any combination of de-identification techniques
to de-identify the results.
We used a really simple example, but the value of templates
really shines for Kitty Cat Walks when
they got their data that needs to be inspected
and de-identified coming from their web and mobile apps,
archived on GCS buckets, and stored
on a number of databases.
Reviewing templates was a great way
to bring everything together.
Next time, we'll wrap things up with an extended episode, where
we'll dive into configuring DLP in the Google Cloud console.
See you soon.
[MUSIC PLAYING]