| Appendix |
342
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 Other 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. See Step 4 of this section for more information on client-side
encryption.
• 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. Doing so can cause problems for clients by overwriting files when downloading or
uploading and corrupting metadata.
• Server-side EAR does not work with multi-session transfers (using
ascp -C
or node API
multi_session
set to greater than 1) or Watch Folders (versions prior to 3.8.0 that do not support URI docroots).
To enable server-side EAR:
a) Set users' docroots in URI format (local docroots are prepended with
file:///
).
# asconfigurator -x "set_user_data;user_name,
username
;absolute,file:///
path
"
b) Set the server-side EAR password.
Set a different EAR password for each user or group:
# 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
"
Important:
If the EAR password is lost or
aspera.conf
is compromised, you cannot access the data on
the server.
c) Require content protection and strong passwords.
These settings 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"
# asconfigurator -x "set_node_data;transfer_encryption_content_protection_strong_pass_required,true"
2.
Never use "shared" user accounts.
Configure each user as their own Aspera transfer user. Sharing Aspera transfer user account credentials with
multiple users limits user accountability (you cannot determine which of the users sharing the account performed
an action).
3.
Use passphrase-protected private keys.
The
ssh-keygen
tool can protect an existing key or create a new key that is passphrase protected.
If you cannot use private key authentication and use password authentication, use strong passwords and change
them periodically.
4.
If your workflow allows, require client-side encryption-at-rest (EAR).
Aspera clients can set their transfers to encrypt content in transit and on the server, and the server can be
configured to require client-side EAR. You can combine client-side and server-side EAR, in which case files are
doubly encrypted on the server. Client-side encryption-at-rest is not supported for
ascp4
or
async
transfers.
Client configuration
The client specifies a password and the files are uploaded to the server with a
.aspera-env
extension. Anyone
downloading these
.aspera-env
files must have the password to decrypt them. Users can enable client-side
EAR in the GUI or on the
ascp
command line.
