When files are uploaded from an Aspera client to HSTS, server-side encryption-at-rest (EAR) saves files on disk
in an encrypted state. When downloaded from HSTS, 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 that is running HSTS or HSTE.
- 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 an envelope file that
contains 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, which 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 because the 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. Transfers that use ascp
-C or Node API multi_session must be 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"