Levels of data protection
Depending on your environment setup and settings, you may capture data for which you have legal obligations due to protection laws and regulations, such as GDPR, CCPA, and LGPD. To address such cases, Dynatrace offers the following three levels of protection to help you prevent the capture, storage, and display of such data.
Masking at capture
Data is masked immediately after it's captured. The original data doesn't leave the monitored process or user's browser.
Masking at storage
Data is processed by Dynatrace to allow for better analysis, but the original data is masked prior to storage.
Masking at display
Data is stored in its original form but only presented to users with a special permission.
Check a flowchart below to see on what levels and entities your end users' data is masked in Dynatrace.
For masking at capture and masking at storage, any related masking capability in Dynatrace is applied only after you enable it; such masking is not applied retroactively.
Protect personal data by not capturing it (masking at capture)
Dynatrace automatically masks certain data points at the point of capture. This happens within the application, monitored process, or browser so that the data is already replaced by a placeholder before it is sent (data in transit) to the Dynatrace cluster. Asterisks are used for such placeholders. For example, the
johnsmith username is sent and stored as
- Literals that are part of the
WHEREclause of an SQL statement
- URL query parameters in exception messages
- IBAN and credit card numbers
Protect personal data by not storing it (masking at storage)
If your organization captures personal end-user data that is subject to data protection laws and regulations, go to Settings > Preferences > Services and RUM. The opened settings page contains several configuration options that allow you to enable proper masking of captured data.
Mask IPs and GPS coordinates
🟢 Enabled by default
Dynatrace captures IP addresses and GPS coordinates of end users to determine the region from which they access your application.
With the Mask end-user IP addresses and GPS coordinates option turned on, Dynatrace masks end user IP addresses and GPS coordinates during Real User Monitoring and server-side monitoring. The last octet of monitored IPv4 addresses and the last 80 bits of IPv6 addresses are replaced with zeroes. GPS coordinates are rounded up to 1 decimal place (~10 km). The masking occurs on the Dynatrace cluster prior to storage, and full IP addresses are never written to disk. Location lookups are made using anonymized IP addresses and GPS coordinates.
The Mask end-user IP addresses and GPS coordinates — Mask all IP addresses option is enabled by default for new environments.
For mobile apps, Dynatrace uses the coordinates from the device by using GPS or Wi-Fi. If the app has the permission to use this geolocation information, Dynatrace uses it to calculate the city that is closest to the reported GPS location. If not, Dynatrace uses MaxMind Geo2 Database.
Mask personal data in URIs
🔴 Disabled by default
Dynatrace captures full URIs of requests that are sent from desktop and mobile browsers, as well as URIs of requests that are sent and received within monitored server-side processes. URIs may contain personal data, such as a user name, password, or ID.
When Mask personal data in URIs is turned on, Dynatrace detects personal data—emails, IBANs, bank card numbers, IP addresses, UUIDs, and other IDs—in URIs, query strings, headers, and exception messages and replaces this data with the
<masked> string (for example,
/url?country=Austria&city=Linz changes to
/account/iban('123456678890') changes to
/account/iban('<masked>')). As a result, the personal data is then masked in the PurePath® analysis, error analysis, user action names for RUM, and elsewhere in Dynatrace.
Mask user actions
🔴 Disabled by default
The Mask user actions (web applications only) option affects Real User Monitoring only for web applications. With this option enabled, Dynatrace uses generic values for user action names.
When Dynatrace detects a user action that triggers a page load or an AJAX/XHR action, it constructs a name for the user action based on:
- User event type, for example,
loading of page..., or
- Title, caption, label, value, ID, className, or other available property of the related HTML element, for example, an image, button, checkbox, or text input field
In most instances, the default approach to user action naming works well, resulting in user action names such as:
click on "Search" on page /search.html
keypress on "Feedback" on page /contact.html
touch on "Homescreen" of page /list.jsf
In rare circumstances, email addresses, usernames, or other confidential data may be unintentionally included in user action names. This happens when confidential data is included in an HTML element label, attribute, or other value, resulting in user action names such as
click on "My Account Number: 1231231". If such confidential data appears in your application's user action names, turn on Mask user actions (web applications only) . This setting replaces specific HTML element names and values with generic HTML element names.
With user action name masking enabled, the user action names listed above appear as:
click on INPUT on page /search.html
keypress on TEXTAREA on page /contact.html
touch on DIV of page /list.jsf
Protect personal data by not displaying it (masking at display)
Restrict view access to personal data
Dynatrace automatically considers certain data points it captures as confidential and only displays them to users who have the View sensitive request data permission. All other users see that the data point exists, but the personal data is masked out with asterisks
If your organization captures personal user data such as email addresses, IP addresses, or passwords in the course of monitoring, you should restrict view access to this personal data so that only authorized users can view it.
Also note that only users with the View sensitive request data permission can override data masking settings.
Personal data types
The following data types are considered confidential and are masked at display:
- Requests attributes marked as confidential
- Client IP addresses
- Exception messages
- URL query parameters
- HTTP headers
- HTTP POST parameters
- Original captured method argument values (the resulting request attribute is treated separately)
Mark request attributes as confidential
Request attributes are key-value pairs of metadata that are filterable across all Dynatrace service and distributed traces views.
Dynatrace allows you to decide whether a request attribute should be marked as confidential. To manage request attributes, you must have the Configure capture of sensitive data permission.