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: the data in question is replaced immediately after it's captured and doesn't leave the monitored process or the end user's browser. This data is already masked out before it is sent (data in transit) to the Dynatrace cluster and before it is stored (data at rest) there.
  • Masking at storage: the data in question is processed by Dynatrace to allow for better analysis, but the original data is replaced with placeholder strings such as <masked> prior to storage.
  • Masking at display: the data in question is stored in its original form but only presented 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 *.

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 and numbers that are part of the where clause of an SQL statement
  • Bind parameters 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 GDPR regulations, go to Settings > Preferences > Data privacy, and enable the data masking option. This settings page contains several configuration flags that allow you to enable proper masking of captured data.

Masking of IP addresses and GPS coordinates

Dynatrace captures IP addresses of end users to determine the region from which they access your application.

Once enabled, IP address masking sets the last octet of monitored IPv4 addresses and the last 80 bits of IPv6 addresses to zeroes. GPS coordinates are rounded up to 1 decimal place (~10 km). This masking occurs on the Dynatrace cluster prior to storage. Full IP addresses are never written to disk. Location lookups are made using anonymized IP addresses and GPS coordinates.

Masking of personal data in URLs

Dynatrace captures the full URIs of requests that are sent from browsers (mobile and desktop) and requests that are sent and received within monitored server-side processes.

Once enabled, Dynatrace does the following:

  • Automatically detects UUIDs, IBANs, IP addresses, and other IDs in the URL path and replaces these parts with a string like [IBAN] or [IPv4].
  • Replace query parameter values with the string <masked>.

Masking of user action names Only for web applications

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, click on..., loading of page..., or key press on...
  • 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, however, confidential data, for example, email addresses, usernames, or account numbers, may be unintentionally included in user action names because the confidential data is included in an HTML element label, attribute, or other value (for example, click on my Account Number: 1231231). If such confidential data appears in your application's user action names, you should turn on Mask user actions. 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 would change to:

  • 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)

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 *****. Thus the data is protected from view by unauthorized personal.

Personal data types

The following data types are considered confidential and are masked at display:

  • Requests attributes that are 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

Dynatrace allows you to decide whether a request attribute should be treated as confidential. For this and other obvious reasons, users who are authorized to define request attributes must have the Configure capture of personal data permission. For complete details, see Mark request attributes as confidential