Regional Data Residency Requirement in Blockchain
A blockchain network is a distributed and decentralized system that has, virtually, no boundaries and geography. Because of its distributed nature, any information stored in a blockchain network may cross regional borders, and data may not reside within a defined region. To meet compliance with regional laws for data residency, data entered in applications connected to a digital ledger implemented in Azure Blockchain should be stored on a storage facility physically located within the territory. This is achieved in two steps:
1. Communication with Azure Blockchain Workbench is via REST API or Azure Service Bus, using the Azure Blockchain Development Kit. Data is anonymized and a reference key and value pair is generated for each message packet and submitted to the blockchain digital ledger. In this way, no identifiable information is stored in the blockchain network.
2. Actual data is transferred to a database located in a local data center, along with the reference key.
Sending messages to Blockchain Workbench
The built-in capability in Azure Blockchain Workbench REST API to submit authenticated requests to execute transactions on a distributed ledger is depicted in the following diagram.
1. The external application authenticates to the Azure Active Directory provisioned as part of the Azure Blockchain Workbench deployment.
2. Authorized users receive a bearer token that can be sent with requests to the API.
3. External applications make calls to the REST API using the bearer token.
4. The REST API packages the request as a message and sends it to the Service Bus. From here it is retrieved, signed, and sent to the appropriate distributed ledger.
5. The REST API makes a request to the Azure Blockchain Workbench SQL DB to record the request and establish the current provisioning status.
6. The SQL DB returns the provisioning status and the API call returns the ID to the external application that called it.
As the Blockchain Workbench infrastructure may be provisioned on Azure data centers outside of the region of compliance, it is necessary to introduce the 2-step mechanism described at the beginning to alter the course of transaction of data messages.
The Data Anonymization process can be implemented as a micro-service or a serverless Azure Function. Different algorithms for anonymization may be implemented, including hashing or RSA encryption.
Reading data from Blockchain Workbench
As seen for the sending message to Blockchain Workbench integration, the reading data process follows a similar pattern:
1. The external application authenticates to the Azure Active Directory provisioned as part of the Azure Blockchain Workbench deployment.
2. Authorized users receive a bearer token that can be sent with requests to the API.
3. External applications make calls to the REST API using the bearer token.
4. The REST API queries the data for the request from the SQL DB and returns it to the client.
At this point, the information retrieved from the Blockchain Workbench database is anonymized, according to the process described before. To read this information in clear, it is necessary to look it up from the local database, using the reference key stored with each message.
The Data Reveal process can be implemented as a micro-service or a serverless Azure Function. If hashing was used for anonymization, the hash represents the key as well, as hash values are unique, and the reveal process can look up data in the local database by its value. If RSA encryption or similar was used, the public key used for encryption will be used to look up data, and the associated private key owned by the external system used for decrypting data.
