Redstor uses state-of-the-art security measures like Transport Layer Security (TLS) and encryption to ensure the complete safety of all data that it protects. Our software enables you to confidently recover lost data in just about any situation.
The graphic below illustrates a typical Redstor implementation with data being transferred either over a LAN or to the cloud.
Storage Platform security
The Storage Platform only allows Agent connections that use TLS (1.0, 1.1 and 1.2). Connections with insufficient security will be blocked. We recommend that you configure your connection to disable TLS 1.0 and 1.1 whenever TLS 1.2 is possible to ensure maximum protection against protocol downgrade attacks.
To learn more about how the Storage Platform Console uses OpenSSL, see Article 1371.
Data on the Storage Platform is stored in encrypted form using 256-bit AES (GCM).
Note: To further improve security on the Storage Platform, a log message pointing out any insecure cipher suites that are still accessible to the Storage Platform’s operating system will be generated daily. For more information, see Article 588.
ESE Agent security
Each Redstor Account has its own encryption key, which is used to encrypt that account’s data during the backup process. The encryption key is essential to recovery, and is neither retrievable nor readable unless a Group Certificate is present. If the encryption key is lost or forgotten, there is no way to access the backed-up data, not even for Redstor employees. It is therefore imperative to keep your encryption key in a safe place. See our encryption key best practices below.
During the backup process, data blocks are compressed with LZ4 and then encrypted on the Agent using the user’s encryption key specified when the account was created. This encryption occurs prior to data being transferred to the Storage Platform. TLS is used to authenticate the data transfer and to create a secure session between the Agent and the Storage Platform.
We use a symmetric-key cryptographic block cipher, 256-bit Advanced Encryption Standard (AES) in Galois Counter Mode (GCM) or AES-GCM to ensure authenticated encryption, guaranteeing the integrity of your data. Through AES-GCM, the integrity of each block of data is verified using its inherent checksum before being stored on the Storage Platform. Files that have become corrupt or are missing on the Storage Platform (due to disk corruption, for example) are identified by integrity checks and are retransmitted to the Storage Platform at the start of each backup.
During a backup, the Agent maintains a rolling buffer of data transmitted to the Storage Platform. Whenever a connectivity drop and subsequent reconnection to the Storage Platform occur, the service resumes from the exact position of interruption, seamlessly continuing the backup without having to start at the beginning of the file. This is especially useful when large files are being transferred.
- For more on how ESE maintains data integrity, see Article 1102.
- For information on security in our cloud service, see Article 1288.
Compliance with FIPS 140-2 (2001) and FIPS 140-3 (2019)
FIPS 140-2 and its successor FIPS 140-3 are information processing standards developed by the United States government agency NIST (National Institute of Standards and Technology). FIPS, the Federal Information Processing Standard, specifies the security requirements for cryptographic modules. Redstor can confirm that the Redstor service uses FIPS 140-2 and FIPS 140-3 compliant cryptography in the form of AES 256-bit encryption.
We recommend the following best practices for managing encryption keys:
- Only the necessary Administrators should have access to encryption keys, but never just one person.
- Access to the location of encryption keys should be protected with multi-factor authentication (MFA).
- Encryption keys should be kept separate from the data they have encrypted.
- Encryption keys should adhere to guidelines for strong passwords such as those suggested by Microsoft. These include:
- Requiring a minimum encryption key length of 8 characters.
- Banning common passwords as well as brand names, company-specific internal terms, etc.
- Prohibiting single-word passwords.
- You could also make use of a password manager such as Dashlane or Keeper.
- Data immutability: Article 1420.
- Data sovereignty: Article 1380.
Article is closed for comments.