For customers with heightened regulatory or privacy needs, New Relic offers account-based, FIPS-compliant encryption-at-rest capabilities with unique keys per account. This protects data from inadvertent or intentional exposure, even if the attacker has access to the filesystem.
To achieve a high level of protection while maintaining high performance and long-term storage and retrieval of data, we use a two-tier system consisting of a data encryption key (DEK) and a master key, each with separate usage, storage, and rotation policies.
For an overview of how we handle your data in transit and at rest, see our data encryption documentation. This document describes the key management process for data encryption in more detail.
When encryption at rest is enabled for an account, each new file is encrypted (AES-GCM with 256 bit keys) with a data encryption key that is unique to the account and the server writing the data. Each DEK is generated locally using a FIPS 140-2 validated cryptographic module on the server. Each account’s DEK is rotated every 24 hours or when it has been used to encrypt 64 GB of data. It can also be rotated manually, as-needed.
The DEK that is used to encrypt a file is subsequently encrypted with the Master Key and appended in this wrapped format onto the encrypted data file. The key is encrypted remotely on our key management service (KMS), which is provided by AWS.
In order to read a file, the process is reversed: First, the NRDB host on which the data resides extracts the wrapped DEK from the file and sends it to the KMS to be decrypted (unwrapped). Finally, the host decrypts the data file and processes it.
To prevent ciphertext attacks, a new data encryption key is generated per account every 24 hours or when the existing DEK has been used to encrypt 64 GB of data.
The master key is used only to encrypt DEKs, so a ciphertext attack against it is improbable. In compliance with FIPS guidelines, the KMS automatically rotates the master key once a year. Each New Relic region contains a single master key, which is never transmitted out of the KMS.
New Relic servers generate each DEK locally, and the plain text DEK is never written to disk. If an attacker gained access to process memory, they could retrieve the unencrypted DEK for that server and time period, but they would be unable to read data from other time periods.
The Master key is generated, stored, and used within a FIPS 140-2 validated hardware security module (HSM) on the KMS. Neither New Relic nor AWS employees can retrieve the plaintext of the master key. Secure generation, management, backup, storage, and destruction are all handled and guaranteed by the KMS. Administrator access to key management functions is controlled and audited using AWS permissions and CloudTrail.
In addition to our usual review process for security-critical components, New Relic’s encryption system has been reviewed by a third party and found to meet all requirements of NIST SC-28(1) Protection of Information at Rest, SC-12(3) Cryptographic Key Establishment and Management, and SC-13 Cryptographic Protection. It is approved as part of our authorization for FedRAMP Moderate impact.
If you need more help, check out these support and learning resources:
- Browse the Explorers Hub to get help from the community and join in discussions.
- Find answers on our sites and learn how to use our support portal.
- Run New Relic Diagnostics, our troubleshooting tool for Linux, Windows, and macOS.
- Review New Relic's data security and licenses documentation.