Skip to main content

Data security and durability

Quorum Blockchain Service (QBS) uses several Azure capabilities to keep your data secure and available. Data is secured using isolation, encryption, and authentication.

Isolation​

QBS resources are isolated in a private virtual network. Each transaction and validation node is a virtual machine (VM). VMs in one virtual network cannot communicate directly to VMs in a different virtual network. Isolation ensures communication remains private within the virtual network.

Encryption​

User data is stored in Azure storage. User data is encrypted in motion and at rest for security and confidentiality.

Authentication​

Transactions can be sent to blockchain nodes via an RPC endpoint. Clients communicate with a transaction node using a reverse proxy server that handles user authentication and encrypts data over TLS.

QBS supports authentication using API keys and Azure Active Directory (Azure AD).

API keys​

API keys are used to access the JSON-RPC API endpoints used to make calls to the blockchain. API keys use a randomly generated string that act as secrets to access the RPC endpoints.

Each transaction node in your QBS member has two API keys which can be used if you want to limit access to specific nodes. Additionally, your QBS member has two API keys which provide access to any transaction node in the member. This can be helpful if you have several transaction nodes interfacing with an application without having to manage seperate keys for each transaction node.

API keys should be periodically rotated by regenerating the keys in the event your API key is lost or compromised.

Azure Active Directory​

Azure AD is used when executing the QBS management APIs. The managed app is a resource in Azure, and access control is implemented using Azure AD.

Azure AD uses a claim-based authentication mechanism where the user is authenticated by Azure AD using Azure AD user credentials. QBS integrates with Azure AD enabling ID federation, single sign-on and multi-factor authentication. You can assign users, groups, and application roles in your organization for blockchain member access.

Keys and Ethereum accounts​

When provisioning a QBS member, an Ethereum account and a public and private key pair are generated. The private key is used to send transactions to the blockchain. The Ethereum account is the last 20 bytes of the public key's hash. The Ethereum account is also called a wallet.

The private and public key pair is stored as a key file in JSON format. The private key is encrypted using the password entered when the blockchain service is created.

Private keys are used to digitally sign transactions. In private blockchains, a smart contract signed by a private key represents the signer's identity. To verify the validity of the signature, the receiver can compare the public key of the signer with the address computed from the signature.

Tessera keys are used to uniquely identify a Quorum node. Tessera keys are generated at the time of node provisioning and are specified in the privateFor parameter of a private transaction in Quorum.

Data durability​

QBS state data (chaindata) is stored in locally-redundant storage. It's replicated across multiple disks in multiple stamps in Azure data centers. If a node in the network crashes, it doesn't impact the integrity of the state data.

As more members are added to the blockchain network, public state is replicated to all nodes in each member, so in the event of a data center outage impacting a node's state data storage, once recovered the public state data is replicated from other members in the network.