This doc is for legacy encryption users. If you’re not using our previous encryption method, you can read how New Relic encrypts all data-at-rest. When we moved to the public cloud, New Relic changed how we encrypted data-at-rest. This change had no impact on our security posture. The details below apply to anyone still using our previous method of encryption-at-rest.
Encryption and decryption process
Our previous encryption-at-rest method encrypts each new file (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
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 unlikely. 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.