Data Sourcing: Enterprise Integration with Existing Systems

One of the prime reasons to learn how to use blockchains with Microsoft Azure is that it brings you the complete infrastructure for this point of integration at an Enterprise level. The Azure Blockchain Workbench allows for a completely agnostic set of options for various types of blockchains and their integration with companies based on existing IT ecosystems and workflows.

With large-scale enterprises becoming more and more data driven, using the correct decentralized practices in digital form has become of utmost importance and drives business decisions. And as organizations across industries would have a varied use case for a block chain application and a very different IT architecture built to cater to its functioning, Microsoft Azure comes in as a bridge that can accommodate both of these challenges. And as organizations get more and more data driven with a lot of aspects of their operations digitizing, the constant tussle of centralizing vs decentralizing shall continue and grow even further. Hence a tool like Microsoft Azure enables organization an easy and sustainable way to decentralize their processes effectively without entirely disturbing existing operations over the Enterprise Tools that were being used before Blockchains.

Consider a 10,000-person organization. The CIO wishes to make business decisions based on company strengths and weaknesses. However, the reporting of this is not very transparent, as there is a hierarchical, non-tangible process by which to derive this data offline. To avoid biases, companies integrate productivity measures in digital form; for example, the number of sales visits, number of converts, value of business, and so forth. These measures existed long before technological tools were introduced. However, with blockchains the process to trace and track these measures has become more transparent and tangible. So, when all actions update on a chain, decision-making can be a closed-loop online activity that measures and drives impact.

With this need to be connected to the stakeholders of the business—be it employees, clients, or suppliers—in tangible, traceable forms that are immutable, decentralized, and secure, blockchains are an obvious Enterprise requirement. The Azure Blockchain Workbench facilitates the smooth integration of Microsoft environments with the various elements of blockchains.

Based on the type of data and the processes around the data, the mode of integration is selected.

In this chapter, we will focus on the most common form of structured data found in Enterprises across various domains.

Onboarding: Compliance and Regulatory Requirements

Once the sourcing of data is identified, data is sorted, structured, and stored appropriately. The classification of data for private and public blockchains as well as for on-chain and off-chain activities is crucial. Such classification is linked to the policies that establish protection rights and regulations with which every business must comply.

At the same time, the process by which the data is handled is crucial, along with the state of the data, when we talk about blockchains. For instance, a normal registration of a centralized online platform merely requires an email and password set up, with some more details. However, the process of storing the password and email is unknown to the end user. There may be unsecured platforms that store passwords in plain-text and may leak out values that could be used on secured platforms as well. Thus, onboarding a user onto a blockchain differs from such common practices.

Onboarding starts with the machine addresses, private and public keys, and the validation of other nodes, depending on the type and purpose of the blockchain.

Therefore, the second touchpoint of consideration is how this sourcing of data is seamlessly onboarded to blockchains. This onboarding may be at the start of the blockchain setup, or during intervals, or during ongoing operations, or during any number of event triggers.

This integration touchpoint does not have direct tools to implement; it is more of a design consideration for the integration of processes related to onboarding. This varies highly based on the application, location, and domain of the blockchain platform.

GDPR Considerations for Blockchains

The General Data Protection Regulation (EU) 2016/​679 (GDPR) is a regulation in EU law that covers data protection and privacy for all individual citizens of the European Union (EU) and the European Economic Area (EEA) . It also addresses the transfer of personal data outside the EU and EEA areas. The GDPR aims primarily to give control to individuals over their personal data and to simplify the regulatory environment for international business by unifying the regulations within the EU.

This consists of three main aspects.

Definition of Purpose and Consent

While onboarding users, the definition of purpose must be clearly conveyed. Along with this, the rightful consents to use the data must be clearly described. This European policy has ensured such practices on a centralized platform. How does this apply to blockchains? The answer is in the smart contract triggers, which may comply and check in case of any deviation. For example, if a user has not provided consent, the blockchain platform must clearly convey and commit to the bylaws defined in the foundation of that blockchain.

Subject Access Request (SAR)

Upon the request of a user, SAR allows the retrieval of all personal information for that user from the platform. On an immutable ledger facilitated by blockchains, the complete history of data is traceable yet secure as the ability to access this data resides purely with the user.

Failure to comply with this provision may penalize the company with a fine of up to 20 million GBP or 4 percent of global turnover, whichever is higher. Such clauses may auto-trigger when such bylaws are broken. But the question here is, why would companies ever program a blockchain to become such non-profitable systems? The answer to this is that it enables the users to also have a beneficial contract during onboarding . The governance mechanism must require both stakeholders - the organizations & the users to comply with the regulations put forth in the smart contract mutually. It gives the user an avenue to put forth his terms. It may involve penalties or refunds based on the conditions agreed by both parties as a part of consensus. Since the user here is not a mere subscriber, this peer-to-peer relationship is master to master, and so the clauses must be balanced.

Data Breach Notification

The user must be notified if the platform faces a security breach so that suitable actions can be taken by the user. This also can be a part of a smart contract during onboarding.

Based on these three aspects, the Azure Compliance Manager extends an array of tools to be utilized for any policy defined over the cloud components and enforced throughout. This does not mean it comes embedded with the Azure Blockchain suite, but since the architecture lies in the same environment, it is easier to integrate them for their specific purposes.

More here: https://azure.microsoft.com/en-in/overview/trusted-cloud/compliance/.

Azure’s Compliance Manager offers various tools for various purposes. It covers an array of global policies and regulations across countries, industries, and timelines.

Azure Blueprints

Azure Blueprints allows businesses to utilize templates that are pre-defined as per policies and regulations, such as ISO, GDPR, etc., or to make custom templates for the entire organization to follow while building independent applications or company-wide applications. (This is currently a free service offered by Azure, allowing one to adhere to international policies, but it is not known how long they will keep it that way.)

When building international blockchains with users across different industries and countries, these templates must be considered to avoid national conflicts over data privacy and protection rights.

Azure Policy

Here, independent policies are defined. As we saw, Blueprints provides a template/framework for policies and security rules. The policy definition takes place in this tool. The blockchain policies for nodes and transactions can be stored here while designing universal policies.

Azure Security Center

When one activates the Security Center on Azure, a monitoring agent is actively deployed over the virtual machine components. It actively checks for threats and attacks. Similar to the security checks for SQL injections, brute-force attacks, and so forth in centralized systems, blockchain nodes have to be actively monitored for the same.

In case, in a trustless permissionless network, there are collusions observed in the patterns of fraudulent validations, the Security Center could trigger policies to avoid such attacks and safeguard the on-chain activities (Figure 6-5).

Exercise

Refer to the preceding process flow and identify the right integration components for this flow in an insurance company.

Authorization: Access Control and Security Access

Most enterprises enforce access control for various roles and activities. Based on the login credentials and metadata from the preceding stages, the proper access control is selected and functionalities are catered. Now, in case of an attack, if the lowest authority becomes vulnerable, the entire hierarchy of control will fall. Therefore, considering the ongoing practices of access control, it is highly crucial to embed the existing processes of access control onto the blockchain.

Azure Active Directory is widely used to maintain access control over all applications based on a common protocol. This component requires integration with the decentralized blockchain platform. The entity of access control is mapped from the existing record of users to the hashed machine addresses.

Another aspect of security is the Azure Key Vault, where the user stores and maintains their set of public keys and backs up the private keys if desired. However, storing keys centrally again defies the initial purpose of blockchains, as the key could be made vulnerable to attacks or leaks, making it less secure. The main reason to use the Azure Key Vault is to seamlessly integrate the existing security mechanisms with the blockchain activities.

Another form of authorization is the validator nodes, which are dependent on human intervention to approve new peers. There could be nodes assigned to forming consensus to issue CA certificates authorizing a new user on the chain.

Lastly, smart contracts may enforce a checklist of pre-requisites for the user, perhaps a minimum set of documents or a biometric scan and iris scan, to gain authorization.

Automation: Processes for Auto-trigger/Alerts of Smart Contracts

Since the onset of the digital era, most businesses have transitioned online, including bringing their data online. However, there are still large-scale companies relying on off-chain practices due to a failure to integrate with modern systems.

This is exactly where automation by smart contracts can facilitate faster transactions. Smart contracts not only digitizes contract data but also digitizes the states/ processes that are involved in transferring the data.

Let us examine a medical transport scenario where smart contracts are to be integrated.

The state flow of the organ is highly crucial for the suitable outcome of the transplant. If the donor, the doctor extracting the organ, the transport conditions (via IoT), and the delivery check on the recipient side are all on a blockchain bound with a smart contract clause for a healthy organ for a successful transplant, and if any node supplies data that has tampered with the state of the organ and its environment variables, then the recipient can transparently avoid a faulty transaction. These auto-triggers and alerts can be on the chain through the Azure event trigger at the very moment the any of the conditions (defined in the smart contract) for a healthy organ fails the contract.

For example, if the cooling system during transfer were to fail, the event trigger would invoke the Azure logic app to update the state to indicate an unsuccessful transfer. This provides a safe, transparent, clause-driven ecosystem with blockchains and the smart contract.

Complete Picture

The key to a successful working ecosystem is design (Figure 6-6). Having the right set of components aligned ensures each of the components stands up to the expectations of its functionality and at the same time maintains the conjunction of processes that were already in practice. While bringing decentralization and automation through blockchain and smart contracts to organizations that have long been run in a particular way, such changes are difficult and often break into offline processes, leading to discrepancies and opaque layers of clarity.

Design considerations and awareness of what can be seamlessly integrated are highly crucial. This chapter has aimed to cover those thoughts and considerations in terms of the availability in the Microsoft Azure ecosystem of the components around the Azure blockchain, as shown in the Figure 6-5.

These independent Azure Components are well tested and compliant for the services described above and are widely used across enterprises. Thereby Blockchains must not be seen as a stand alone system during its adoption. It is recommended to plan integration of existing systems with Blockchains to run operations seamlessly.

Thus with this, identify the touchpoints and Azure services that suit the purposes of your blockchain and the processes around it.