When files are uploaded from an Aspera client to the server, server-side
encryption-at-rest (EAR) saves files on disk in an encrypted state. When downloaded
from the server, server-side EAR first decrypts files automatically, and then the
transferred files are written to the client's disk in an unencrypted state.
Server-side EAR provides the following advantages:
- It protects files against attackers who might gain access to server-side
storage. This is important primarily when using NAS storage or cloud storage,
where the storage can be accessed directly (and not just through the computer
running Aspera Enterprise Server, Connect Server or Point-to-Point Client).
- It is especially suited for cases where the server is used as a temporary
location--for example, when a client uploads a file and another one downloads
- Server-side EAR can be used together with client-side EAR. When used together,
content is doubly encrypted.
- Server-side EAR doesn't create an "envelope" as client-side EAR does. The
transferred file stays the same size as the original file. The server stores the
encryption and various metadata necessary for server-side EAR separately. (By
contrast, client-side EAR creates a file envelope containing both the encrypted
contents of the file and the encryption metadata, and it also changes the name
of the file by adding the file extension .aspera-env.)
- It works with both regular transfers (FASP) and HTTP fallback transfers.
Limitations and Considerations
- Server-side EAR is not designed for cases where files need to move in an
encrypted state between multiple computers. For that purpose, client-side EAR is
more suitable: files are encrypted when they first leave the client, then stay
encrypted as they move between other computers, and are decrypted when they
reach the final destination and the passphrase is available.
- Do not mix server-side EAR and non-EAR transfers. Doing so can cause problems
for clients by overwriting files when downloading or uploading.
- Server-side EAR does not work with multi-session transfers (using ascp
-C or node API multi_session set to greater than 1).
Configuring Server-Side EAR
Set the docroot in URI format.
Server-side EAR requires the storage to have a docroot in URI format, such
that it is prefixed with file:///
. The third slash ( / )
does not serve as the root slash for an absolute path. For example, a docroot of
would be set as
and a docroot of
would be set as
To configure the docroot options, click Configuration
and set configurations for Global,
Groups, and Users under their
respective Docroot tabs. Select Override
in the Absolute Path row to set a docroot and adjust read, write,
and browse privileges. User docroot settings take precedence over group settings, which take precedence over global settings.
Set the password.
The server-side EAR password can be set for all users (global), per group, or
per user. In the Server Configuration
dialog, click the
tab and locate the setting for
Content Protection Secret
. Select the override box
and enter the password.
Optional: Require encryption and/or a strong password.
In addition to setting a password, you can set options to cause server-side
EAR to fail if a password is not given or if a password is not strong enough.
In the Authorization tab, select the override box next to
Strong Password Required for Content Encryption and
Content Protection Required and select