Managing access in a collaborative data sharing platform
How safe is your sensitive data?
In December 2019 Gospel’s recently published patent was announced, which is an extremely exciting step forward for the business. As we all know, reading (let alone trying to make sense of) patents can be a chore. To that end, we took it upon ourselves to publish a two-part blog series to help break down the tech and terminology that easily explains how companies can implement and manage access in a collaborative data sharing platform.
Our first post in this two-part blog series talked about what it means to build a collaborative data sharing platform, where contractual trust is replaced by cryptographic trust – underpinned and enforced by rules that are configured into the underlying technology. The two main components for cryptographic trust are consensus and contextual access, which we covered in detail in part one. We used the Banking & Financial Services industry as an example to share practical use cases for each of the technical components, which we’ll continue to do in part two.
In our second and final instalment of the series, let’s take a closer look at the other defining features and capabilities necessary for managing access in a collaborative data sharing platform.
Key components for securely sharing sensitive data in the cloud
User Intent – Getting (and staying) ahead of the curve
A proper consensus method includes the step of recording a user’s intent on the blockchain – what a certain user is attempting to do with the data. This enables companies within the network to get a complete 360-degree view of every transaction for a certain dataset and allow them to better understand who is requesting what access, when and why. By seeing not only what a user requests but also knowing the intent behind that request, companies can take a more proactive rather than reactive approach to monitoring and tracking their data.
The transaction request is recorded onto the blockchain by cutting a block and distributing it onto the blockchain. The orderer cuts the block. A node within the blockchain cannot bypass the consensus algorithm in order to access the blockchain. The data is then indexed in the blockchain nodes and data access to the blockchain is prevented.
|The challenge||Our solution|
|A financial services organisation is suspicious of a possible internal bad actor. Transactions aren’t adding up and data appears to have been tampered with.||With Gospel, the organisation can view an entire history of a dataset’s lifecycle on the blockchain, including the intent behind every user transaction or request. Allowing them to better track where any suspicious activity or transactions may be occurring, by whom, and for what reason and mitigate them quicker.|
KeyStore – the Gatekeeper to your data
The KeyStore decrypts the transaction response when consensus is reached and records the transaction onto the blockchain. The KeyStore permits the decryption of data only if a transaction is correctly endorsed or approved by the consensus algorithm.
Each peer of the blockchain simulates the transaction request and sends its signed response. Responses are combined and submitted to the KeyStore.
The KeyStore decrypts the transaction response and sends it to the user that requested the transaction. The transaction request is recorded onto the blockchain, and the set of keys are then derived.
|The challenge||Our solution|
|Major banks and financial services organisations employee thousands of people globally. Eventually, an employee will move on and request all access to their personal information be revoked upon their leave.||With Gospel, companies can provide evidence that data is no longer accessible by providing the key to the employee themselves, deleting that key, or putting it in ESCROW. If in the future that data needs to be retrieved, only Gospel and the key holder (the employee) can retrieve the data.|
A certificate authority processes a user login request and issues ephemeral certificates for accessing the platform. The identity of the user is communicated within the blockchain by encoding a series of assertions and conditions into the certificate. The method includes the step of sending a Certificate Signing Request (CSR) to a cross endorsing Certificate Authority (CA).
Once signed and endorsed, the certificate is revoked when the user logs out of the platform. Access control is provided via consensus agreement of all participants within the network, including the data owner themselves.
|The challenge||Our solution|
|Your bank recently onboarded a new customer who is now applying for a loan. The customer already has a record with the banking department but not with the loan department.||Gospel enables you to create a golden record for every customer, even when they work with various departments within your organisation. When the customer applies for the loan, their record details are automatically sent to the loan department from the banking department via contextual access – and only after consensus has been reached and the transaction is signed and endorsed.|
Ready to get started?
Regardless of industry, companies need a better way to prevent data breaches, adhere to compliance regulations, and collaborate with partners and 3rd parties in a safe, secure and trusted environment. All while maintaining control and traceability over shared data.
We’ve created an entirely new sandbox environment to make it easier than ever for you to test out your use cases on the Gospel platform – free of charge.
Reach out for more information on how you can get started proving out your POCs for secure data sharing in the cloud, using clicks instead of code.
Don’t forget to check out our short 7-minute demo video for a brief overview on how to get started.
Related blogs & news
Gospel on the go: bringing GDQ to a location near you
Gospel on the go
Gospel Technology Launches Gospel Developer QuickStart (GDQ) on Google Cloud Marketplace
Inside blockchain and its various applications