Theme
Encryption at rest
A virtual file system can encrypt everything it writes, so that reading the raw disk, the raw bucket or a stolen backup yields ciphertext.
The key is derived from a passphrase and lives only on that Connector.
Read this first
Syncplify cannot recover your key
The key never leaves the Connector. Syncplify never has it, cannot obtain it, and cannot help you recover data encrypted with it.
If the passphrase is lost, the data encrypted with it is permanently unrecoverable. Keep your own copy of the passphrase somewhere safe, off this machine.
The choice is permanent
A virtual file system's encryption setting cannot change after it is created.
To encrypt or decrypt existing data, you create a new virtual file system with the setting you want and migrate the data across.
When it is worth it
Encryption at rest protects against somebody obtaining the storage without obtaining the Connector: a stolen disk, a backup tape, a misconfigured bucket, a cloud provider's staff.
It does not protect against somebody who has the Connector machine, because the key is there. It does not protect against a user who is allowed to read the file, because that is what being allowed to read means.
So it is worth it when your storage is somewhere you do not fully control, and it is worth less when the storage is a disk in the same locked room as the Connector.
Creating a key
Storage, then Encryption keys, then Create key.
| Field | Notes |
|---|---|
| Name | How you will refer to it when creating a virtual file system |
| Passphrase | Used once to create the key, then never shown or returned again by anything |
You can also create a key inline while creating an encrypted virtual file system.
Using one
On the virtual file system create form:
- Turn on Encrypt data at rest.
- Pick an existing key, or create a new one there and then.
- Save.
The virtual file system then carries an Encrypted at rest badge everywhere it appears.
Deleting a key
DANGER
If any data anywhere is still encrypted with a key, deleting it makes that data permanently unreadable.
The Connector shows you how many virtual file systems use a key before you delete it. Believe the number.
Backing up
Two things are worth backing up, and they are different:
Your passphrase. Store it in a password manager or a sealed envelope, not on the Connector. Without it a rebuilt Connector cannot reconstruct the key.
The Connector's data directory. It holds the derived keys, encrypted under a machine local secret. Backing it up saves you a rebuild; it does not substitute for the passphrase, and it is itself sensitive.
| Platform | Data directory |
|---|---|
| Windows | C:\ProgramData\Syncplify\sc-conn |
| Linux, macOS, FreeBSD | /opt/Syncplify/sc-conn |
| Docker | The volume mounted at /data |
What encryption does not change
- Performance is affected but not dramatically. Encryption happens as bytes pass through.
- Permissions are unaffected. They are enforced the same way either side of the encryption boundary.
- Your users see nothing. They browse, upload and download normally, with no key and no ceremony.
- Deduplication and server side copy in your storage backend stop being useful, because the ciphertext differs.
Not available on the SFTP backend
The remote server owns that storage, so the Connector cannot control how it is written to disk. The option is not offered for that type.