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 in the event an attacker has access to the file system.
It's important to maintain both a high level of protection and also optimal performance and long-term storage and retrieval of data. To do this, New Relic uses 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, including details about the key management process for data encryption, see data encryption documentation.
Encryption and decryption process
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.
Key rotation
To prevent ciphertext attacks, a new data encryption key is generated for each account when the existing DEK has been used to encrypt 64 GB of data or every 24 hours if the data threshold is not met before then.
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.
Key handling
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 any 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 plain text 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.
FedRAMP authorization
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.