Masking Profiles
Satori’s masking profiles allow organizations to mask query responses for their users to avoid exposing sensitive information.
Unlike existing masking solutions that require defining which columns to mask, Satori’s masking profiles can be applied to data detected and tagged by Satori’s data classification and tagging mechanism.
The Satori classification and tagging mechanism fully automates the definition process.
Data Transformations
Satori supports two types of data transformations:
- Generic Data Transformations - can be applied to any data type, like replace data fields with predefined strings, hash the data or remove it completely from the result set.
- Specific Data Transformations - custom-made transformations for common data types which provide a better user experience for users of masked data. For example, anonymizing an email address by replacing the address prefix with
*
or retain only the year from a date of birth field.
To see the full list of transformations refer to the link here Transformations List
Using Masking Profiles
To simplify the process for configuring dynamic masking, Satori uses Masking Profiles. Masking profiles define the set of transformations to apply to each data type and are used by the policy engine when defining rules. The same profile can be re-used by multiple rules.
Masking Profile Implementation Methods
There are two main methods for applying "Masking Profiles" the first is to apply the masking profile to a security policy masking rule and the second method is to apply a masking policy via the Policy Engine YAML Rule Editor.
To learn more about applying a Masking Profile to a Security Policy refer to the Security Policies chapter.
Masking Profile Templates
Satori provides three preconfigured profile templates for common use-cases.
-
Permissive Profile - A profile suited for roles which require some access to PII.
-
Restrictive Profile - A profile suited for any role which does not require access to PII.
-
Analytics Profile - A profile suited for analytics teams who need to retain statistical data characteristics while protecting PII.
Masking Profile Attributes
Masking profiles are comprised of the following attributes:
- Name - a unique name of the profile.
- Description - a short description of the profile.
- Masking Conditions - a list of masking conditions.
Masking conditions define which transformation to apply for every tag. Only one condition can be set for each tag. Satori supports two types of tags:
- Pre-defined Tags - like PII, email, credit card, etc. See the tag reference for the full list.
- Custom Tags - user-defined tags. See custom tags for more information.
When defining a condition for both a tag and its category, for example email and PII, the most specific condition takes precedence. In this example, the transformation defined in the condition for email will be applied.
Creating a Masking Policy
Masking profiles are used by the policy engine when defining a rule with a mask action. In your Satori Security Policies, you can reference multiple masking profiles based upon user or group assignment, or even using ABAC attributes, e.g.
Note: you can toggle an individual masking profile on or off without deleting it from your security logic.
Using the Custom Policy feature, you can also specify masking profiles in your YAML config using its masking ID, for example:
- name: Mask Customer PII for Analysts
action:
type: mask
profile: 7d1c1d8f-2fed-4897-8163-ef174d885192
identity_tags:
- identity.datastore.role::analyst
data_tags:
- customer_data
priority: 2
Transformations
Generic Data Transformations
Name | Example | Definition |
---|---|---|
Hash | "data" => "50d858e0985ecc7f60418aaf0cc5ab587f42c2570a884095a9e8ccacd0f6545c" |
Use this transformation to obfuscate the data completely while retaining its statistical properties for counting, aggregating, etc. note: hash transformations on numeric values result in changed/different numeric values. |
Replace characters with | "12345678" => "aaaaaaaa" |
Use this transformation to preserve the length of the original data |
Replace entire string | "12345678" => "REDACTED" |
Use this transformation to make it clear the data has been masked |
Mask everything except last | "12345678" => "******78" |
Use this transformation to retain a hint of the original data |
Specific Data Transformations
In addition to the generic transformation, for selected data types specific transformation are available.
Name | Example | Definition |
---|---|---|
Hash while preserving format | "user@company.net" => "1234@567890a.bcd" |
Generates a hashed version of the original email address. Use this transformation to preserve the original format of the data |
Mask while preserving format | "user@company.net" => "****@*******.***" |
Use this transformation to obfuscate the data completely while preserving its original format |
Mask username | "user@company.net" => "****@company.net" |
Use this transformation to retain information about the domain name of the email address |
Mask domain | "user@company.net" => "user@*******.***" |
Use this transformation to retain information about the username of the email address |
Credit Card
Name | Example | Definition |
---|---|---|
Hash while preserving format | "1234-5678-9012-3456" => "abcd-ef12-3456-7890" |
Generates a hashed version of the original credit card. Use this transformation to preserve the original format of the data |
Mask while preserving format | "1234-5678-9012-3456" => "****-****-****-****" |
Use this transformation to obfuscate the data completely while preserving its original format |
Show only last 4 digits | "1234-5678-9012-3456" => "****-****-****-3456" |
Shows only last 4 digits |
Date of Birth
Name | Example | Definition |
---|---|---|
Show only the year | "abcd 2/6/1975 abcd" => "*********1975*****" |
Use this transformation to retain information about the year only |
Public IP Address
Name | Example | Definition |
---|---|---|
Anonymize IP address | "11.20.30.1" => "11.20.0.0" |
Use this transformation to retain /16 of an IPv4 address and /64 of an IPv6 address |
Hash while preserving format | "11.20.30.1" => "ab.cd.ef.1" |
Generates a hashed version of the original IP address. Use this transformation to preserve the original format of the data |
Mask while preserving format | "11.20.30.1" => "**.**.**.*" |
Use this transformation to obfuscate the data completely while preserving its original format |
Semi Structured Data
For semi-structured data granularity (e.g. a specific location inside a JSON), masking is applied to specific fields without affecting other JSON locations.
To mask information inside of a JSON field in your data source, you must first create new Satori Data Inventory entries which identify this information.
For example, if you have a JSON field named attrs
that looks like this:
{
"customer": "John Doe",
"gender": "Male",
"items": {
"SSN": "123-45-6789",
"exp": "10/01/2025",
"moresubnesting": {
"SSN": "123-45-6789",
"newfield2": "123 Main Street"
}
}
}
And you want to mask 'SSN' in two different array locations, you would need to create two new Data Inventory entries, like so:
The general rules and syntax for these new Data Inventory entries are:
Rules
$: The root object
To add a property: $.property_name
To add a property with special characters e.g. spaces: $['property name']
To add a property inside an array: $.array_name[*].property_name
Once these new entries are created, you can tag them with Satori or custom taxonomy, just like any other field. From this point on, any Security Policies and Masking Profiles will be triggered accordingly, e.g. nested masking might look like this:
{"customer":"John Doe","items":
{"SSN":"******-6789","exp":"10/01/2025","moresubnesting":
{"SSN":"******-6789","newfield2":"****treet"}}}