Data masking — admin overview (Beta Access)
Last Update: Sep 2024 • Est. Read Time: 10 MINData masking allows your organization to better protect customer privacy by minimizing access to sensitive data. Kustomer offers a powerful suite of features that allow admins to control which data fields agents should have access to while supporting customers. These features help minimize accidental sharing of private data on even the most well-intentioned support team.
This article will offer an overview of the data masking feature from an admin perspective. We'll cover everything you'll need to know in the setup, maintenance, and usage aspects of this feature.
Who can access this feature? | |
User types | Admins can access the Attributes page. |
In this article
- What is data masking and sensitive data?
- Why use data masking?
- How does it work?
- Beta Access limitations
- Data masking settings
- Set up masked attributes
- Temporary access to unmask data
- Learn about sensitive data edge cases
- Interactions with other features
- Appendix: data masking and the Kustomer Apps Platform
What is data masking and sensitive data?
Data masking (a.k.a. data obfuscation) is the process of obscuring or hiding information from unauthorized users. Data masking is a practice essential to many regulated industries where personally identifiable information (PII) must be protected from overexposure. It's also required for data privacy compliance in some regions — one notable example is General Data Protection Regulation (GDPR), which requires the use of data masking for sensitive data collected about EU citizens.
Note: Data masking should not be confused with message redaction:
- Data masking hides sensitive data from groups of users.
- Message redaction is the practice of permanently and irrevocably deleting information from the platform.
Sensitive data is defined as any data or attributes that contain personally identifiable information (PII) which could be potentially used to distinguish one person from another, either directly or indirectly.
Sensitive data can be obviously identifiable like a First/Last Name or Social Security #. Depending on the industry you're in, this may also extend to other data markers like phone number, date of birth, address, email, and so on. Data that can be used alone or in combination with other factors to positively identify an individual could be considered as sensitive data.
Why use data masking?
With data masking, your organization can expose sensitive data as needed to relevant teams, without compromising the data or straying out of compliance. This helps reduce security risk by limiting agent access to viewing or searching for PII only when it is necessary to perform their job, or if they're authorized to do so.
For example, your organization may want to safeguard sensitive data and limit the amount of information agents have access to. Or, you may work in an industry with data privacy regulations that require access to a minimum amount of data on a need-to-know basis.
Since every organization's data security needs are different, our data masking feature lets you pick which fields to hide in the interface. This helps your team custom-fit a solution that protects customer privacy, while still allowing agents access to the data they need to provide great customer service.
How does it work?
In the Klass Management > Attribute Settings, admins can edit an attribute to denote when any standard or custom attribute on a Klass should have its data masked. You can mask data on up to 20 attributes per Klass. A preview will appear to demonstrate how the partially masked or fully masked attribute will appear to unauthorized users.
Admins can then use permission sets to control which users or teams have access to view masked data using the Read Unmasked checkbox, much in the same way you'd control a team's Read or Edit access. Learn more about using attribute permissions in Attribute level permissions.
Authorized users will have normal access to viewing and searching Klass attributes. However, users without the correct field-level permissions access will see that the customer's sensitive information is obscured with asterisks, along with a Masked badge to indicate that data is being masked.
Where is and isn't data masked in the UI?
Data is masked to unauthorized users:
- When viewing any Standard or Custom Object in the timeline — including customers, conversations, companies, or KObjects
- In the left pane when viewing a customer in Currently Viewing
- In the Browser title, like the name of a tab or window
- In Insights details, Insights cards, and Insights panel
- While editing attributes in all edit modals — including conversation, customer, and company attributes
- In search results when searching for customers, conversations, companies, or KObjects
- When using the Kustomer API to fetch standard and custom objects
- In Audit Logs Settings, object names are masked in the Section links column
Data masking does not extend to:
- Automations, including business rules, queues and routing, and workflows
- Conversational assistants
- Reporting
- Data exports
- Some app integrations may be incompatible with data masking during Beta Access, which can result in loading issues or broken links in app-created KViews
- Using dynamic text that includes sensitive data (learn more)
Note: Users with access to create automations and exports will have indirect access to sensitive data through their ability to potentially post data to external services, or to export data which would otherwise be masked in Kustomer.
Please be aware of this condition as you assign permission sets to users. Learn more about sensitive data edge cases.
Full vs. partial masking
If an attribute contains sensitive data, it can be fully masked, which would obscure every character in the sensitive string. Full masking is always an available option, and is used in all cases where partial masking isn't available.
Certain attributes offer a partial masking option, which shows the last 4 digits or domain suffix of a string. This can be a useful way to give agents enough information to verify a customer's identity when offering support, without allowing so much access that they gain insight into their full PII.
These attributes support partial masking, and will appear to agents as follows:
- Emails: *******.com
- Phones: *******5309
The masked representation of an email field always uses a fixed number of asterisks independent of the length of the original field value. This is done to prevent audiences from using the length to make educated guesses about the contents of the masked field.
Beta Access limitations
Data masking is a feature that's still in development. During the Beta Access period, there are a few limitations to be aware of while planning your use of this integration. If any of these items block your use of data masking, please check back as we'll be continuing to improve this Kustomer offering in the near future.
Using drafts
During Beta Access, agents can compose a draft to a customer, but if they can't see the details of the recipient for that channel (like the customer's email address when sending an email), they won't be able to send the message without requesting access first. This applies to all channels — not being able to view the customer's phone number would block a WhatsApp message, not being able to view the Instagram ID would block Instagram, and not being able to view email address would block email or any other channel that sends via that identifier.
Until this functionality is added, there are 2 methods for working around this limitation:
- If agents have access to requesting unmasked data, they can unmask to unblock sending a drafted message.
- While this limitation is in place, admins may want to avoid masking data that identifies a recipient, like their email address or phone number.
Automatic masking in message metadata
If a recipient is masked (for example: Instagram ID, email, phone number, etc.) this data will not be automatically masked in message metadata, like voice calls on the timeline.
If you wish to mask PII on message metadata as well as the attribute, you can choose to mask message headers in the Message klass, in addition to the attributes in the Customer klass.
Exports
In exports, we currently block users from creating an export with attributes with which they don’t have read access, which will result in a 403 Forbidden error. This does not currently take into account sensitive attributes and read unmasked permissions. A user without read unmasked permissions for an attribute can create an export with that attribute and potentially read its value in the exported data.
In the future, users will be required to have read unmasked permissions to attributes they want to export instead of just read permissions.
Data masking settings
Go to Settings and select Security > Data Masking to find an in-app overview of data masking. From here, you can follow tours to set up masked attributes and permission sets and customize the temporary access period.
Set up masked attributes
Data masking is a property of standard and custom attributes in your Kustomer organization. You can control data masking settings when editing the properties for any Klass attribute.
To mask data in an attribute:
- Go to Settings > Platform > Klasses.
- Select the Pencil icon next to the Klass you wish to edit.
- Locate the attribute you want to mask, then select the Pencil icon to open the Edit Property popover.
- Check the Mask the data in this attribute box.
- You'll see a preview of the field that will be masked. On certain attributes, you can choose between Partial and Full masking. When you're satisfied, select Save Changes.
Repeat the above steps as desired for all other attributes you wish to mask.
You can review the masking status for any attribute by referring to the Data Privacy column in the attributes list. This will display a status pill that indicates whether an attribute is partially or fully masked.
Temporary access to unmask data
Admins can allow agents to request temporary access to masked data through an additional action in the Customer permissions. This may be useful for organizations where agents should never see PII, and only need to access customer data in response to a customer's request for assistance.
Before data is unmasked, the agent will see a confirmation dialog to ensure this event is not taken unintentionally. For admin oversight, all unmask events are recorded in the audit logs.
If the agent proceeds, the customer's data will be unmasked temporarily. The Masked badge will change color and be labeled Unmasked, and users can hover on the badge to see how much time remains in the temporary access period.
To review all unmasking events, go to Settings and select Security > Audit Log.
When an agent unmasks data in this fashion, the customer's data will be unmasked for everybody in your organization for a predetermined length of time. You can customize this length of time in the Data Masking settings by entering the preferred value in the Temporary Access Period field, with a minimum of 1 hour and a maximum of 72 hours.
An agent's access to the Unmask Data option this is managed through Object Permissions > Customer > Temporarily Unmask Customer Data.
If Temporarily Unmask Customer Data is unchecked, then agents won't be presented the option to unmask data themselves. Instead, they'll see a note to contact an admin if they need to request access to view data.
Learn about sensitive data edge cases
Kustomer offers a multitude of powerful automation features which reference and convert data for use elsewhere within or outside of the Kustomer platform. In this section, we'll discuss some possible use cases to be aware of when using advanced Kustomer features to avoid accidental disclosure of sensitive data.
Dynamic text
Admins using dynamic text may reveal sensitive attributes to unauthorized agents through the draft editor.
Dynamic text can potentially reference sensitive data like customer names. If someone with access to sensitive data (like an admin) composes a reply or note in the timeline, it's possible for them to include dynamic text that references sensitive data. Sending this reply would convert the dynamic text with the customer name to plain text, making that data visible to an agent who might otherwise not have access to that data.
As a user with access to unmasked data, be cognizant about referencing sensitive data in dynamic text to avoid unintended disclosure.
Implicit visibility through automations and exports
Users with the ability to create automations will have indirect access to sensitive data that they can use to external services for subsequent reading. For example, a user could create a workflow with a Rest API action, or set up a business rule with email forwarding & templates. Both of these cases would result in a user having the ability to access sensitive data after transmitting it outside the Kustomer platform.
Be sure that your admin team is aware of these cases when granting this access to users that would otherwise not have permission to view masked data.
Automations
All automations work off events published by sobjects
, e.g., kustomer.customer.update
. For this reason, events will be published as unmasked so automation services can continue to read data as unmasked. Automation services also make internal requests to sobjects
and customer-search
to fetch and update standard and custom objects.
Any user with access to Business Rules, Queues and Routing, or Workflows will be able to access masked data through the use and administration of these automations.
Conversational Assistants
Admin users can create a conversational assistant that displays messages using Customer, Conversation, and KObject attributes.
These messages are shown to end users, and subsequently can be viewed by agent users in the customer timeline when an agent takes over the conversation from an assistant. If the conversational assistant is built to include attributes containing sensitive masked data, it would expose that data to users otherwise lacking access to masked data.
Exports
Data can be exported from Search and Reporting.
For exports from Search, a request is made to POST /v1/exports
. Any users with permissions to export searches will be able to see unmasked data after that data is reported. The permissions to export searches are:
roles: [ 'org.admin.exports', 'org.admin.analytics', 'org.admin.analytics.exports', 'org.admin.search', 'org.admin.search.export', 'org.permission.analytics', 'org.permission.analytics_export', ]
For exports from Reporting, a request is made to POST /v1/analytics/exports
. Any users with permissions to export data from the Reporting UI will be able to see unmasked data. The permissions to export reporting data are:
roles: [ 'org.admin.analytics', 'org.admin.analytics.export', 'org.permission.analytics', 'org.permission.analytics_export', ]
Exports from Scheduled Reports are created by web
making a request to POST /v1/report-subscription
.
Interactions with other features
Data masking is a far-reaching feature that has impacts throughout the Kustomer platform. In this section, will discuss special cases and best practices to be aware of when planning how to integrate data masking in your organization.
Conditional attributes
Conditional attributes allow you to mark when a field is required in order to mark a conversation as done. When setting up conditional attributes, be sure to consider if any of the required attributes will have data masking turned on, and whether your agents will have access to those fields.
If you set an attribute as required, but agent users don't have access to that field, then these agents would potentially be unable to mark conversations as Done.
Working with undefined values
If a field has partial masking turned on but contains an undefined or empty value, a user who would normally see the data as masked will see fully masked values instead, due to the lack of a meaningful way to partially mask an undefined value. Fields that are in an empty state are considered undefined.
For example, let's say you have a user with edit access to a phone number field with partial masking, but they don't have Read Unmasked permissions to the phone number. In cases where there's no number on file, the user would see the entire field as masked.
Appendix: data masking and the Kustomer Apps Platform
Data masking can also impact apps and custom integrations. Apps and integrations created before the introduction of data masking in Q2 2022 will need to be updated to properly support data masking.
If you've performed any in-house customization of your Kustomer organization, please refer to the Apps Platform documentation on our Developer Portal to learn how to address any compatibility issues with Klass Views and the Cards SDK.
If you've developed and published an app through the Kustomer Apps Platform, there may be temporary issues with app functionality during the Beta Access period. We appreciate your patience as our team works to investigate and fix these apps during Beta Access.