Data masking in ClickHouse
Data masking is a technique used for data protection, in which the original data is replaced with a version of the data which maintains its format and structure while removing any personally identifiable information (PII) or sensitive information. This guide shows you how you can mask data in ClickHouse.
Use string replacement functions
For basic data masking use cases, the replace family of functions offers a convenient way to mask data:
| Function | Description |
|---|---|
replaceOne | Replaces the first occurrence of a pattern in a haystack string with the provided replacement string. |
replaceAll | Replaces all occurrences of a pattern in a haystack string with the provided replacement string. |
replaceRegexpOne | Replaces the first occurrence of a substring matching a regular expression pattern (in re2 syntax) in a haystack with the provided replacement string. |
replaceRegexpAll | Replaces all occurrences of a substring matching a regular expression pattern (in re2 syntax) in a haystack with the provided replacement string. |
For example, you can replace the name "John Smith" with a placeholder [CUSTOMER_NAME] using the replaceOne function:
More generically, you can use the replaceRegexpOne to replace any customer name:
Or you could mask a social security number, leaving only the last 4 digits using the replaceRegexpAll function.
In the query above \3 is used to substitute the third capture group into the resulting string, which produces:
Create masked VIEWs
A VIEW can be used in conjunction with the aforementioned string functions to apply transformations to columns containing sensitive data, before they are presented to the user.
In this way, the original data remains unchanged, and users querying the view see only the masked data.
To demonstrate, let's imagine that we have a table which stores records of customer orders. We want to make sure that a group of employees can view the information, but we don't want them to see the full information of the customers.
Run the query below to create an example table orders and insert some fictional customer order records into it:
Create a view called masked_orders:
In the SELECT clause of the view creation query above, we define transformations using the replaceRegexpOne on the name, email, phone and shipping_address fields, which are the fields containing sensitive information that we wish to partially mask.
Select the data from the view:
Notice that the data returned from the view is partially masked, obfuscating the sensitive information. You can also create multiple views, with differing levels of obfuscation depending on the level of privileged access to information the viewer has.
To ensure that users are only able to access the view returning the masked data, and not the table with the original unmasked data, you should use Role Based Access Control to ensure that specific roles only have grants to select from the view.
First create the role:
Next grant SELECT privileges on the view to the role:
Because ClickHouse roles are additive, you must ensure that users who should only see the masked view do not have any SELECT privilege on the base table via any role.
As such, you should explicitly revoke base-table access to be safe:
Finally, assign the role to the appropriate users:
This ensures that users with the masked_orders_viewer role are only able to see
the masked data from the view and not the original unmasked data from the table.
Use query masking rules for log data
For users of ClickHouse OSS wishing to mask log data specifically, you can make use of query masking rules (log masking) to mask data.
To do so, you can define regular expression-based masking rules in the server configuration.
These rules are applied to queries and all log messages before they are stored in server logs or system tables (such as system.query_log, system.text_log, and system.processes).
This helps prevent sensitive data from leaking into logs only. Note that it does not mask data in query results.
For example, to mask a social security number, you could add the following rule to your server configuration: