By default, the AppDynamics Java Agent sends transaction data to the Controller that your organization may classify as privileged information. Although such data is useful for diagnosis and troubleshooting, security considerations may require you to filter certain information from view in the Controller. You can use:
- Sensitive data filters to exclude environment variables, system property, and JMX data.
- Sensitive URL filters to exclude sensitive information from a URL in snapshot details.
- Sensitive message filters to exclude sensitive data that the application may place in log messages or exception detail messages.
Default Sensitive Data Filters
When you enable a sensitive data filter, the Controller displays asterisks for the values of matching environment variables or system properties. By default, the Java Agent enables two sensitive data filters in the app-agent-config.xml:
- Environment variables or system properties that contain the case insensitive substring "password".
- Environment variables or system properties that contain the case insensitive substring "key".
Add a Sensitive Data Filter
- Edit a versioned app-agent-config.xml file:
- Add a sensitive data filter element as a child of the Sensitive Data Filters element using one of the following attributes.
Specify a comma-separated list in the
applies-toattribute to filter the following:
match-typeattribute as follows:
Specify a string to match for the
match-patternattribute. String matches are case insensitive. The pattern matches against the environment variable and system property names, not values.
- Restart the JVM.
In the example below, the Java Agent checks for system properties and environment variables beginning with the string "DB_". The Controller displays the values of matching environment variables and system properties as asterisks. For instance, an environment variable "DB_USER" is replaced with an asterisk.
Add a Sensitive URL Filter
You can use sensitive URL filters to configure the agent to obfuscate sensitive information from the URLs in transaction snapshot details.
- Edit a versioned app-agent-config.xml file:
Add a sensitive URL filter element as a child of the sensitive URL filters element:
delimiter: Specify the character that you want to use as URL segment endpoints. The agent splices the URL at each delimiter instance to create the segments. For HTTP, use the forward slash character "/". In the case of a forward slash, the agent does not split on the slashes immediately following the protocol. For example, "https://myapp.example.com" constitutes a single segment. By default, the delimiter is "/".
segment: Specify a comma-separated list to indicate the segments that you want the agent to filter. Segment numbering starts from 1.
match-pattern: Specify the string that you want to be filtered by the
param-pattern: Specify the regular expression matching the query parameters to filter.
For example, the following configuration splits the URL on the "/" character and masks the second segment and the param-pattern in the third segment of the URL. In this case, the segmentation and obfuscation apply only to URLs containing "myapp".
The exit call to https://myapp.example.com/sensitive/data?first_name=abc&last_name=xyz breaks down to three segments: "https://myapp.example.com", "sensitive", and "data?first_name=abc&last_name=xyz". The Controller shows the masked values of the URL and the param-pattern display https://myapp.example.com/*****/data?first_name=***&last_name=*** in the snapshot details.
Add a Sensitive Message Filter
You can use sensitive message filters to configure the agent to obfuscate sensitive information contained within text messages collected by the agent from log messages, or detail messages from exceptions.
Edit a versioned app-agent-config.xml file:
Add a sensitive message filter element as a child of the sensitive message filters element:
- message-type specify throwable, logger-message or all
match-type specify the type of match that should be used to opt-in messages for redaction
match-pattern specify the pattern that, when matched, opts the message in for redaction
- redaction-regex specify a regular expression identifying data that should be redacted from the opted-in messages
For example, if an application logs SQL queries including secret numeric values, the following configuration would remove all the numeric data from the logged messages:
Resulting in –
"SELECT name from customer WHERE customer.id = 773"
Being collected as –
"SELECT name from customer WHERE customer.id = *****"