This article describes best practices for different user roles and maintenance to ensure a secured workspace backup and recovery. Your workspace Owner can start the Workspace Key Backup and Recovery process with the Native Recovery Utility in their Fireblocks Console. To manage this sensitive process properly and enhance security, we recommend separating your duties by selecting a specific employee as your Security Manager.

Roles

Native Workspace Key Backup requires participation from your Workspace Owner, Security Manager (if not also the Owner), and Admin Quorum. Their responsibilities are summarized below.

Workspace Owner

The workspace Owner assigns users to your Console and API users, and is responsible for the following during backup and recovery:

• Initiates the backup process from their Fireblocks Console Settings.
  • Uploads the public backup key generated by the Security Manager for Admin Quorum approval. The Owner must also approve their own request since their approval is required, in addition to your Admin Quorum, for all workspace configuration changes.
• Receives, and provides the native in-house Workspace Key Backup package file to the Security Manager.
• Approves the public recovery key (along with the Admin Quorum) that the Owner submits.

Security Manager

The Security Manager is a special operational role recommended for backup and recovery. Typically, the Security Manager is someone entrusted to your organization other than the workspace Owner with no requirement for a specific Fireblocks user role or access to a Fireblocks workspace. For example, your organization can assign the role to an IT professional, or another team member who understands network security and how to use and secure the offline device.

This role:

• Creates and stores backup material on the offline machine.
• Creates the recovery keypair and provides it to the Owner.
• Receives the native Workspace Key Backup package from the Owner and stores it on the offline machine.
• Coordinates the public recovery key verification process by taking Admins and the Owner to the offline machine and running the Fireblocks Key Backup and Recovery Tool while Admins and Owner follow steps in their Fireblocks mobile apps.
• Performs periodic sanity checks on the native Workspace Key Backup package on the offline machine.

Admin Quorum

The Admin Quorum lists all users with admin privileges and is responsible for approval of workspace configuration. An Approval group can also be custom-assigned and play a similar role to an Admin Quorum. 

• Verifies and approves the public recovery key (along with the Owner) that the Owner submits.
• Goes to the offline machine with the Security Manager to compare the Owner’s submitted public key to the public key file on the offline machine.
• Approves the submitted public recovery key in their Fireblocks mobile apps.

Any user responsible for the native Workspace Key Backup and Recovery should always run tests in a testnet workspace before running the backup in the production workspace. Contact the Customer Success Manager if a testnet workspace has not already been obtained. 

Maintenance best practices 

Storing your offline machine

Your offline machine should be stored securely in a locked safe or compartment. Only give trusted people access to it and create a separation of duties, so that not even your workspace Owner can complete a Workspace Key Recovery without another employee.

Your workspace Owner, who has the Owner recovery passphrase, should not have daily physical access to the offline machine, except for periodic backup verification checks.

Separating components for disaster and recovery

Some other ways you can separate the required components to enhance security:

• Store your recovery keypair in a location separate from the offline machine that holds your Workspace Key Backup package.
• Manually split the zip file’s contents. There are a total of 7 files:
  
  • 2 encrypted key share files for each co-signer (1 ECDSA and 1 EdDSA, totaling 6 files: 2 files for the mobile co-signer and 4 for the 2 cloud co-signers)
  • 1 metadata.json file
  • Open the zip file, extract the encrypted key share files (mobile key shares have the prefix "MOBILE" and cloud key shares have nine-digit number prefixes), then store each co-signer’s pair of files in a separate zip file on an offline device. The metadata.json file is important but doesn't contain secrets, so it only needs to be in one split, or it can be stored in all splits.
• To combine the files, you should gather the separate zip files, extract the contents, and ensure all files are directly in the zip file, not in any directory. Then, you can use the recovery tool.

Verifying your recovery package

You can complete the verification process by following the steps in this article. Do this approximately every three to six months to ensure your key Workspace Key Backup package is intact.

Exporting vault account data to map vault accounts to private keys

You should periodically export your vault account data from your Fireblocks workspace to more easily map between your vault accounts and their private keys in the event of a recovery. We recommend doing this each time you add a new asset wallet or at regular times you set. You can do this in several ways:

Using the Fireblocks Console

In your Fireblocks Console on the left navigation panel:

1. Go to Accounts > Vault.
2. Select   Export Vault Balances & Addresses from the menu.
3. Unzip the downloaded file.

Using Fireblocks API

1. Periodically call the API for list vault accounts (paginated)
2. Subscribe to a webhook for the event VAULT_ACCOUNT_ASSET_ADDED
3. Subscribe to a Notification Center alert via email, Slack, or webhook for event type “vault account”