When files are uploaded from an Aspera client to HST Server, server-side encryption-at-rest
(EAR) saves files on disk in an encrypted state. When downloaded from HST Server,
server-side EAR first decrypts files automatically, and then the transferred files are
written to the client's disk in an unencrypted state.
Capabilities
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 HST Server or HST Endpoint).
- 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 it.
- Server-side EAR can be used together with client-side EAR. When used together,
content is doubly encrypted. For more information, see Client-Side Encryption-at-Rest (EAR).
- 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
metadata necessary for server-side EAR separately in a file of the same name
with the file extension .aspera-meta. By contrast,
client-side EAR creates a envelope file 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.
Requirements
If the following requirements are not met, then the server can have both encrypted
and unencrypted content. This can cause file corruption on the server or unintended
overwriting of downloaded files on the client.
- Server-side EAR must be configured when the server is first set up.
- When multiple users have access to the same area of the file system, they must
use the same EAR configuration.
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.
- Server-side EAR does not work with multi-session transfers (using ascp
-C or Node API multi_session set to greater than 1).
- Do not mix server-side EAR and non-EAR files in transfers, which can happen if
server-side EAR is enabled after the server is in use or if multiple users have
access to the same area of the file system but have different EAR
configurations.
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
/home/xfer would be set as
file:////home/xfer and a docroot of
C%3A\Users\xfer would be set as
file:///C%3A\Users\xfer.
To set the docroot for a
user, group, or default from the command line,
run the appropriate asconfigurator command:
# asconfigurator -x "set_user_data;user_name,username;absolute,file:///filepath"
# asconfigurator -x "set_group_data;group_name,group_name;absolute,file:///filepath"
# asconfigurator -x "set_node_data;absolute,file:///filepath"
-
Set the password.
The server-side EAR password can be set for all users (global)
, per group, or per user. Set the password by using
asconfigurator or manually editing
aspera.conf:
To set the EAR password for a user, group, or default, run the appropriate command:
# asconfigurator -x "set_user_data;user_name,username;transfer_encryption_content_protection_secret,passphrase"
# asconfigurator -x "set_group_data;group_name,group_name;transfer_encryption_content_protection_secret,passphrase"
# asconfigurator -x "set_node_data;transfer_encryption_content_protection_secret,passphrase"