Server-Side Encryption-At-Rest (Ear) - IBM Aspera HST Admin Manual

Server-Side Encryption-at-Rest (EAR)

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
• 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
1. 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"
Client-Side Encryption-at-Rest (EAR)
| Configure the Server from the Command Line | 74
on page 137.