New Relic's synthetic monitoring uses monitors distributed throughout data centers around the world. By design, it captures what is essentially performance data for simulated traffic. It does not capture or handle any personal data by default. All data handled by synthetic monitors is expected to be non-personal.
This document provides additional details about what we do to ensure data privacy and security with synthetic monitoring, plus additional options you can use. For more information about New Relic's security measures, see our security and privacy documentation, or visit the New Relic security website.
What we do
Here's a summary of the data privacy and security measures that New Relic provides for you.
Data privacy and security | Comments |
|---|---|
No personal data | By definition, all data collected through synthetic monitoring is test data created for the purpose of monitoring. None of this data includes personal data from any individual. |
TLS | TLS encryption is required for all domains. This applies to public locations and private locations. |
Authentication | Synthetic monitoring supports a variety of authentication mechanisms, including Basic, Digest, NTLM, and NTLMv2. Available options depend on the type of monitor you choose. |
Data collection | The data transferred to the synthetic endpoint includes:
|
Data received | Data received from the synthetic monitoring endpoint contains the scheduled check's details. This includes the information necessary to complete the check for the minion:
|
Data storage location | Data collected by synthetic monitoring is stored in the region selected by each customer for their account (US or EU). Monitor configuration details (including frequency, check locations, target URL, and the full script for any scripted browser or API test monitors) are stored on our end. We also store all monitor check results for each monitor type. |
Data storage by monitor type | For ping monitors, data storage includes the HAR file, which includes all requests and responses made during the check. For simple browsers, scripted browsers, and API tests, data storage includes the following:
|
Response bodies | New Relic never stores response bodies from requests originated by synthetic monitoring, unless you have manually configured a monitor script to do so. |
IP addresses | Synthetic public minions are expected to be activated using non-personal credentials. Their IP addresses are not defined as personal data under data protection and privacy laws. |
What you can do
For additional levels of security and data privacy, consider using these options.
Additional measures | Comments |
|---|---|
User access | To control which of your users can access your monitors and private locations, set up role-based synthetic monitoring permissions and user groups. In addition, to track and be notified about changes, use audit logs and alert notifications. |
Passwords, API keys, user names, etc. | To securely store sensitive information, use secured credentials for scripted browsers and API tests. The credentials are securely stored using AES-GCM 256-bit encryption at rest with keys managed by AWS Key Management Service (KMS). |
Sites behind firewalls | To control what sites you want to monitor behind your firewall, you can:
|
Web pages behind login pages | If you configure synthetic monitoring to track website areas that are located behind a login page, be sure to create a non-personal login specifically for this purpose. This unique login will reduce the risk of unintended personal data exposure. |
Proxy configuration | Aside from the target URLs monitored by New Relic, private minions will regularly send data to and receive from the synthetic monitoring endpoint. To configure a proxy for all traffic to and from this endpoint, set the MINION_API_PROXY environment variable on the minion host. |
Private minions security | To ensure that only the scripts you intend to run are allowed to run on private minions, use verified script execution. |