Secure API Configuration

Overview

Your API credentials and accounts are a prime target for hackers. It is important to understand and implement our best practices for working securely with the Fireblocks APIs.

Role-based access control

  • When adding API users, ensure that the API user's role is provisioned in accordance with the least privilege principle. Fireblocks supports many different roles for role-based access control, and an API user can be any one of these.
  • Create as many API users as needed to separate duties and create security boundaries.

👍

Best Practice

It is best to have 2 separate API users for different functions, such as:

  1. A 'Viewer' role that performs read-only operations.
  2. A 'Signer' role with transaction signing capabilities.

Create Transaction Authorization Policy rules for API users

API Users with transaction initiation and signing capabilities are able to execute transactions like any other Fireblocks Console user.

It is imperative that you create strong Transaction Authorization Policy (TAP) rules to govern what types of transactions these API users can conduct.

👍

Best Practice

It is best to create TAP rules that limit API users to transact from a specific account and only up to a certain amount. This requires additional approvals or blocks the transaction, preventing users from trying to exceed the pre-defined amount or from transacting from an unauthorized vault account.

Whitelisting IP addresses for API requests

Each API user type on your workspace can whitelist specific IP addresses to only allow API calls from the provided address(es). If there aren't any whitelisted IP addresses for a user, API requests are possible from any IP address.

🚧

Address format requirements

Only /32 IP addresses are accepted. Do not enter addresses as a range of values.

👍

Best Practice

It is best practice to explicitly whitelist the only IPs that you expect to be calling the Fireblocks API.

The Owner of your workspace can suspend the whitelisting of new withdrawal addresses.

Submit a request to Fireblocks Support to enable / disable this feature.

Generating & storing RSA 4096 private keys

Each API user requires a corresponding public/private key pair used to sign requests. It is imperative that you keep your Fireblocks Secret Key (fireblocks_secret.key) safe and secure.

Ways to keep your public/private key pair secure:

  1. Generate a unique CSR file and corresponding public/private key pair for each unique API user, such that if one API user's keys are compromised, other ones will not be.
  2. Generate the CSR file and corresponding public/private key pair in an offline (air-gapped) environment for added security.
  3. Ensure that your fireblocks_secret.key is stored securely in a hardened environment with advanced security controls such as multi-factor authentication and endpoint protection agents.

Do not embed API keys directly in code or your API code source tree

API keys embedded in code can be accidentally exposed to the public.

👍

Best Practice

Instead of embedding your API keys within your applications, store them in environment variables or in files outside of your API code's source tree.

This is particularly important if you use a public source code management system such as GitHub.