aspera.conf - Server-Side Encryption at Rest (EAR)

Capabilities

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 it.
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 /home/xfer would be set as file:////home/xfer and a docroot of C:\Users\xfer would be set as file:///C:\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"
```
This creates lines similar to the example below, in which the user asp1 has a docroot set to file:////Users/testing/Public:
```
<user>
  <name>asp1</name>
  ...
  <file_system>
    <access>
      <paths>
        <path>
          <absolute>file:////Users/testing/Public</absolute>
        </path>
      </paths>
    </access>
  </file_system>
  ...
</user>
```
To manually edit aspera.conf, open it from the following location and insert text similar to the example above.

/opt/aspera/etc/aspera.conf
Set the password.
The server-side EAR password can be set for all users (global), per group, or per user. You can specify these settings 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"
```
Setting the default value (gobal setting) creates the following text in aspera.conf:
```
<default>
  <transfer>
    <encryption>
      <content_protection_secret>passphrase</content_protection_secret>
    </encryption>
  </transfer>
  ...
</default>
```
Setting a value for a user, such as asp1, creates the following text in aspera.conf:
```
<user>
  <name>asp1</name>
    <transfer>
      <encryption>
        <content_protection_secret>passphrase</content_protection_secret>
      </encryption>
    </transfer>
  ...
</user>
```
To manually add a passphrase, open aspera.conf and insert text similar to the examples above, depending on your specifications.
Optional: Require content protect and/or strong passwords.
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. For example, the following asconfigurator command adds both these options for all users (global):
```
# asconfigurator -x "set_node_data;transfer_encryption_content_protection_required,true; \
transfer_encryption_content_protection_strong_pass_required,true"
```
This command adds the following text in aspera.conf:
```
<default>
  <transfer>
    <encryption>
      <content_protection_secret>passphrase</content_protection_secret>
      <content_protection_required>true</content_protection_required>
      <content_protection_strong_pass_required>true</content_protection_strong_pass_required>
    </encryption>
  </transfer>
  ...
</default>
```
To manually enable these options, open aspera.conf and insert text similar to the example above.
Save your changes to aspera.conf then validate them by running the following command:
```
# /opt/aspera/bin/asuserdata -v
```