Published on April 22, 2018
Context
While IT enjoys Digital Revolution, the European business and all related businesses around the world are counting the last 30 days before the EU GDPR gets in the force. Though IT has been made the major enabler of compliance with this regulation, only a few companies have realised that the GDPR requirement about “data protection by design and by default” directly impacts what and how IT developers – regular and DevOps – do in their daily work. Let’s review API Economy, RAML and Open Source from the GDPR point of view and see if we acquire new business risks with them. How to mitigate those risks, if found, should be the topic of another post.
API Economy
According to Wikipedia, “API Economy is a general term that describes the way application programming interfaces (APIs) can positively affect an organization’s profitability. An API is a customer interface for technology products that allows software components to communicate.” Actually, this is not about communication between software components – it is about communication between applications, system and other businesses across the corporate boundaries. Whether this positively affects “an organization’s profitability”, it depends. If the affect becomes negative, does this definition mean we deal with the “API Contra-Economy”?
Any Business or Risk Manager has to ask himself a question: “if my company allows its developers engage the capabilities of other businesses via API, are we sure that the business benefits and values caused by such communications exceed the risks of engaging vendors that we do not have contractual agreements with and that we know very little about?” The GDPR clearly states that if your company uses external suppliers, and external API constitutes exactly such suppliers, you cannot be in compliance with the GDPR if you do not have evidences confirming that your suppliers are compliant with the GDPR themselves.
Nowadays, an individual developer can not only design and develop a new service (Microservice), but can also test it and deploy it in your production environment somewhere in the Cloud. For example, Amazon’s AWS platform allows this as well as the MuleSoft’s Anypoint one. It seems that almost fully automated development-delivery-deployment process needs to be “broken” to the degree that would allow checking whether the external API provider has a contract with your company.
Since the Service Contracts may be explicit (actually signed) and implicit (accepted by the consumer as-is based on the provider’s declaration about the service), the checking might require certain manual operations/process because not all implicit Service Contracts are machine readable. For example, a developer uses AWS for production; Amazon has published a lot of documents that explain why a customer has to believe that AWS is compliant with the GDPR. The customer should either believe Amazon on its word (remaining the responsible entity in front of the regulation instead of Amazon) or require any special document from Amazon confirming their compliance. Alternatively, the GDPR compliance shoulkd be embedded in the contract with the provider. This is especially important in the light of the Liability section of the standard Amazon’s Customer Contract where Amazon states it does not accept any liability for your data placed in its Cloud.
RAML
RAML stands for RESTful API Modelling Language. It’s a way of describing practically-RESTful APIs in a way that’s readable by both humans and computers. This language is used for the tools that allow designing RESTful API in JSON. Many big players in IT market support it in their development environments.
Though such tools usually support documenting the designed API, they still ignorant to the Service Contract that we mentioned before. Moreover, designing in RESTful model doesn’t promote any security means and actual file structure/path of the provider can be embedded in the API’s URI.
Even if one tries to protect the API/Microservice by encrypting the payload and digitally sign it, the significant role in the securing the outcome of RAML-based tools belong to the infrastructure – HTTPS and Gateway. People use the latter to validate Authentication and Authorisation for accessing the API endpoint designed in RAML while the network segment from the Gateway to the endpoint remains unprotected. That is, a Gateway delivers perimeter protection, which can be compromised from inside the protected area, but this is a different theme.
The RAML-based tools allow such things as exposing personal information in the URI, for instance, for GET API with parameters. Here are a couple of examples: https://example.com/invoice/2362365 or https://example.com/account/325365436/transfer?amount=$100.00&toAccount=473846376. What prevents any internal person to find this API in a registry and note the personal account number?.. It seems that the organisations that use the RAML-based tools should be able to apply some customisation (e.g., via RAML extensions), which would eliminate abilities to design API in this organisation using personal and/or sensitive data in clear. This will help compliance with GDPR a great deal.
Open Source
These days I participated in the intensive discussion on LinkedIn about compliance of open source code with the GDPR. Some companies claim their perfection on the basis they build their products using only open source code-base. It is a great source for technology – usually it is free of charge (except the support in some cases) and widely available to developers for years. Unfortunately, these days is the time to pay for this luxury.
Here is a simple question – does a developer using the open source code known whether this code is protective for personal data by design and by default? Yes, one can look into the open source code and try to understand if such protection presents. Do all developers do this in all cases? If not and if the product constructed with the use of open source is sold on the market, what the European buyer will do with this product, how will it assure the GDPR Authority’s auditor that the company is GDPR compliant when it uses a product, which compliance is unknown? In the face of GDPR, does it make sense to buy or download such products at all?
If your company develops something utilising the open source code, the company has a chance to protect itself by creating a GDPR Compliance Control Centre or a process / procedure where all open source software is tested against GDPR before developers are permitted to use it. Will this slow-down the development process? Well, yes, but this is the opportunity for more operational innovations or for changing the perception of how the open source code should be developed in the first place. We know that several good open source-based systems are supported by companies like Red Hat, MuleSoft, WSO2, etc. These companies can and should make an attestation of their open source products and provide the consumers with appropriate evidences/certificates for the GDPR compliance.
Conclusion
Since the industry has recognised the ownership of data and a necessity to protect personal data, a lot of free “cheeses” for development ended up in the mousetraps. We, finally, have reached the level of evolution, starting with which the “right of people to know” is not free anymore – nobody in Europe may use someone’s personal data without the person’s consent. This means that in our companies we have to adjust our development practice and finally take care of the privacy of our employees and our customers.
HOW to ARCHITECT for DEVELOPERS 