Encrypted Folders (EFT built-in, Secure-Data-at-Rest Solution)

EFT Server provides three forms of securing files on disk (data-at-rest encryption):

  • OpenPGP-based encryption is a well-known, dual-key based encryption technology. The primary benefit is the fact that only recipients whose public key was included at the time of encryption will be able to decrypt the file, assuming they own the corresponding private key to their public one. This provides more control over who can access the data, vs. other methods. PGP has two shortcomings: First, it requires that participants create and maintain their key pairs, adding complexity to the process. Second, it is not a streaming encryption technology, as the entire file must be present (written to disk) before encryption (or decryption) can occur. In the context of file transfers, the result is temporary files that cause havoc with automation that consumes files the moment they are received in the target directory. Refer to OpenPGP and EFT for how to use OpenPGP.

  • Integrated Windows encryption via Encrypted File Share (EFS) addresses all of the drawbacks of PGP, eliminating participant key management and providing streaming encryption at the file I/O level; however, it also suffers from two shortcomings: First, some network drive technologies do not support Windows EFS (turning it on in EFT has no effect). Second, standards such as PCI DSS disallow the use of encryption technologies where the keys required for encryption/decryption reside on the systems within PCI scope. It just so happens that Window’s EFS keys do reside on the target system. Refer to Enable EFS Encryption for how to use Windows EFS integration.

  • Encrypted folders (EFT Enterprise built-in encryption) provides an alternative to using a best-of-breed 3rd party data-at-rest encryption solution. EFT’s encrypted folders provide streaming encryption (and decryption), enabling transparent, seamless file read/write. The symmetric encryption leverages AES 256 in CTR mode, with the encryption key known only to EFT. Any file touched by EFT’s protocols (either as a server or as a client) are automatically encrypted (or decrypted) on arrival or departure, as appropriate. In SSL FIPS mode, encryption at rest uses the FIPS-certified SSL library.

    • The primary drawback to the built-in encryption feature is that fact that any side-channeled files, such as those directly copied into a folder designated as an encrypted folder, will not be encrypted or decrypted by EFT. In fact, if you place a plaintext file in an encrypted folder and a customer logs in and downloads the file, the file will be corrupted, as EFT will attempt to decrypt what it thinks is an encrypted file. This risk can be mitigated by never side-channeling files into folders designated as secure. Instead, use EFT’s event rule Copy/Move-> LAN copy action to move files from network shares or physical folders into the secure target, as that will result in the content being encrypted (or decrypted, if done in the other direction).

Each of these methods has benefits and drawbacks. Other alternatives include using third-party data-at-rest encryption, such as the built-in encryption provided by some NAS devices.

EFT built-in Encrypted Folders

Physical folders can be transparently encrypted during read/write using EFT-managed AES-256 symmetric encryption (CTR mode), which uses a secret key known only to the server. The server will encrypt files as they arrive over supported protocols, and decrypt files when departing over those same protocols. The server, when acting as a client, will also encrypt files that it downloads into an encrypted folder, and decrypt files that it copies or moves to a remote server, including LAN copy.  (See below for instructions for creating the key.)

  • EFT generates the Encrypted Folders key upon new Site creation.

  • If the Advanced Property EncryptedFolderKey is defined and not malformed, EFT uses it for encryption/decryption, read at service startup.

  • Upon EFT upgrade, EFT generates a new key if the key is the old "default" value, and no other key is defined

The following considerations for encrypted folder targets should be noted:

  • Encrypted folders are limited to physical folders

  • Encrypted folders affect subfolders within the designated folder

  • Encrypted folders can only point to folders that are under the Site root (e.g., C:\InetPub\EFTRoot\MySite)

  • When using Encrypted folders, you can only encrypt files in the directory hierarchy of the Site's root folder. Make sure that the Site root folder on the Site > General tab is pointing to the correct path. That is, if your HA config drive is on D:\HAConfig\, you should edit the Site root folder to point to D:\HAConfig\InetPub\EFTRoot\MySite.

  • Encrypted folders cannot be EFT system folders (Install Folder, App Data Folder, Cluster Share) and Windows reserved directories (Windows, ProgramData, ProgramFiles, ProgramFilesx86), or their parents or children, and cannot be specified even by server admins. This is includes subfolders of those folders.

  • When configuring network shares for data encryption, the EFT service account must have access to the encrypted folder path; otherwise, you will be presented with a failure

  • Using the CIC Action with encrypted files will not return an accurate result. Copy/move the files to a folder that is not encrypted to process with the ICAP server.

  • If your are remotely connected via the administration interface, you will not be able to browse for folders. Instead, you must specify a valid, approved path, local to the server.

  • Whether local or remotely connected via the administration interface, administrator accounts beneath the role of Server admin (i.e., Site admin and below) will not able to browse for folders. Instead, these administrators must specify a valid, approved path, local to the server.

  • If the server cannot perform initial encryption or final decryption due to lack of permissions, sharing violations, or network disconnect, a warning will appear indicating that "Some files in the folder were not [encrypted|decrypted]. The data in the folder might be corrupt."

  • The following protocols and protocol commands are encryption/decryption aware:

    • EFT FTP/HTTP/SFTP Server (Listening Engines): all operations: upload, download, resume, FTP COMB, FTP and HTTP XCRC32, HTTP Copy file, HTTP/FTP/SFTP move file/folder, HTTP ZIP Folder Download.

    • EFT FTP/HTTP/SFTP/Local Transfer Client (Client FTP transfers): offload, download, resume, Pre/Post commands, "Rename To" after download, FTP data integrity check (CRC).

  • All side-channel operations and all actions outside of copy/move/download are unaware of encryption/decryption. So if, for example, you have a Timer rule that downloads a file from a remote host, to an encrypted folder, and then a subsequent action attempts to manipulate that file (for example in AWE), that file could be encrypted, and thus AWE will not be able to parse it.

  • A new logger is available in Logging.cfg for output to EFT.log, labeled EncryptedFolders, set to TRACE by default.

  • COM support is available

    • You can only encrypt the folders in the Site's root folder. If you attempt to encrypt folders outside of the EFT Site's root folder (e.g., C:\InetPub\EFTRoot\MySite) an error prompt occurs: "This folder is not in the directory hierarchy of this Site's root folder."

    • EFT system folders (Globalscape/EFT, AppData, and cluster share) and Windows reserved directories (Windows, ProgramData, ProgramFiles, ProgramFilesx86), as well as their parents or children, cannot be encrypted. If a reserved path is selected in the Folder to Encrypt dialog box, an error prompt occurs: "This is a reserved path and cannot be encrypted."

    • Before you enable this feature, it is recommended that you set up appropriate backup measures to protect your data. If you need to recover a private key to decrypt data, and that key is lost, you will not be able to recover the data that the key protects. If you need more information on setting up appropriate backup procedures, refer to Configuration and Security Best Practices.

To enable EFT-managed encryption

  1. In the administration interface, connect to EFT and click the Server tab.

  2. On the Server tab, click the Site you want to configure.

  3. In the right pane, click the Security tab.  

  4. In the Data Security area, next to Encrypted folders, click Configure. The Encrypted Folders dialog box appears.

    5. Encrypted Folders dialog box

  5. To add folders that contain files you want to encrypt, click Add. The Folder to encrypt dialog box appears.

  6. Type or browse for the folder that you want to encrypt, then click OK. You can only encrypt the folders in the Site's root folder (e.g., C:\InetPub\EFTRoot\MySite). (See note above regarding clusters.)

    7. Files uploaded to this folder will be encrypted upon arrival and decrypted upon departure over EFT's supported protocols. EFT will also encrypt files that are downloaded (as client) into an encrypted folder, and decrypt files that are copied or moved to a different location.

    EFT will attempt to decrypt any and all files already present in the folder. (This may take a long time if there are many files in the folder.)

To remove or replace an encrypted folder from the list

  1. On the Site > Security tab, click Configure next to Encrypted folders. The Encrypted Folders dialog box appears.

    • If the Folder Path list is empty, then the password field is NOT read only (i.e., you can change the key).

    • If the Folder Path list is NOT empty, select a folder in the list of folders, then click Remove. All encrypted files in the "removed" folder will be decrypted. (This may take a long time if there are many files in the folder. Note that files are not deleted, just unencrypted.)

  2. Click OK to close the dialog box, then click Apply.