Microservices, identity, and privacy by design
Part 2: The advent of Microservices has dramatically opened up the ability to rapidly develop and update applications and services. This is done by breaking them into very small pieces, where each piece can be managed by a single team or one team can manage several pieces. Each of these pieces then comes together with hundreds or thousands other pieces to create a larger framework or workflow. They are at the heart of the DevOps methodology, and an expectation today with the idea of a continues development or continuous delivery mindset.
This provides application and service owners the ability to rapidly scale, update, and develop their services is something that most modern business application service owners want. This also makes businesses run more efficiently. An example is when you need more delivery job servers, with Microservices you spawn more job services and you don’t go down. Easier and more efficient. However, in today’s world, we need to remember that privacy and security have to be top concerns. And in today’s world, Microservices are lacking in this area.
Microservices architecture refresher?
For those that need a reminder from part 1 of this 2-part series, Microservices are a concept that comes out of service-oriented architecture (SOA). It’s a software development technique in which an application or service offering is a collection of loosely coupled independent services that are designed to do one thing very well but only one thing. Microservices tend to be self-contained pieces of functionality focusing on completing one thing. These are normally used in collections of many Microservices, often referred to as a pattern or a Microservices architecture.
The idea here is that there is a significant amount of service granularity that can be completed by utilizing Microservices. Or, to say it differently, using Microservices, a large application id divvied up into many smaller building blocks, each an executable piece of software that as a whole collection (also known as a pattern), offers the full functionality of a single monolithic application. Each of those small components can then be managed by a small team, with very clear and clean boundaries around what their team is managing.
Identity and Data Privacy in a Microservices world
Now let’s get into how we can utilize Microservices in a world where security and data privacy are preeminent. A world where your identity is the foundation for all of your security.
Anything dealing with personal data, and this includes corporate identity, must be in a privacy by design framework. This is not something easy to integrate into the Microservice architecture, but is worth it because you do not want to be passing out personal data in areas where communication may not be secure. Because of this developers need to remember that when looking at security in Microservices, questions about security need to use phrases like "must" not "should."
The CIA triangle MUST be followed -confidentiality, integrity, and availability need to have an equal presence.
Identity systems must have a unified collection of security principles, and should either maintain as monolithic, which are easier for auditors or should be developed with privacy by design concept.
There are some Microservices out there trying to add in additional security in communication, they are then flagged by many developers for degrading the patterns and performance by utilizing multistage or complex secure pathways for communication, due to additional lag they introduce. There is a push against utilizing additional checks, multiple communication paths etc., as many people consider them to be going against the concept of keeping a pattern in Microservices.
Applying the security, we deserve and need
One way to deal with this is to use tokenization to stop passing on real personal data. Simply use the tokens and stop sending insecure personal data through. Additionally, understand that while there will be some degradation, utilize secure communications only. Skip trying for anything with personal data access to be the absolute fastest it can be. A small degradation is a big saving when compared to a 40 million euro fine from GDPR.
Sometimes it is better or at least easier to utilize a monolithic system or a hybridization between monolithic and Microservices, and secure identity management system or personal data repository and separate the use of Microservices for services that do not pass that private data. Does that mean they can’t be connected to that monolithic environment? Absolutely not. The fact of the matter is that Microservices have their place. Monolithic services have their place.
Many times, you’ll end up integrating the two in the environment. For example, having Microservices kick off by-products, such as a modern identity management system, as part of a workflow, which can pass as a token that’s a kickoff for some form of service architecture for provisioning or passing information through Microservices architecture would make absolute sense. The idea here would be that the identity information, which is personal data, is not sent.
If a product doesn’t utilize personal data and/or has no access to it, then do you need to have a privacy impact assessment every time there’s a change? On initial creation or major changes, you should still review and make sure that this is not utilizing personal data, however, this can dramatically reduce the requirements for your impact assessments that should be ongoing.
Remember there are many regulatory requirements for services industries like PCI -- DSS or SOX compliance or regulatory compliance such as GDPR. You need to make sure that you can deal with those audits internally as impact assessments and externally as traditional audits.
If you took a modern identity management system or secure personal data repositories, you could emplace it in a security framework. Identify the controls and align them with the requirements in specific regulations (industry or government-based). You now can review against the selected security or privacy frameworks on a control-by-control basis. This is simple. You can even complete a data privacy impact assessment after any changes to one product. If you have dozens or even hundreds of teams building or managing Microservices this becomes dramatically more impactful on your resources.
The rise of DevSecOps
DevOps is the normal state of being in today's world. As we just discussed it can leave some gaping holes in security, privacy, and identity. There is however a new hybrid development model that has begun taking form in the industry. This is called DevSecOps. The idea here is that security (and hopefully privacy) is part of the thinking behind the development team when it comes to application and infrastructure security from the very start. Often this ends up being another member of the scrum team, focusing purely on privacy or security. This can also mean integrating things like privileged access management tools into the deployment of additional resources on demand. How does this help? It means making use of an outside tool to keep Microservices micro, and still bring security into their deployment.
DevSecOps is not the normal state of being yet, however, if you are going to be working with Microservices, this may be something you also take a look at.
In the end, you have to secure your corporate and client identity, and personal data. Traditional Microservices can leave a hole that needs to be filled.
In the end, privacy by design requires the use of systems that are designed to be secure from their creation. You can’t have many teams managing numerous entitlements, with various teams integrating all over when sensitive data is being managed. That simply leads to a situation where fingers can be pointed. You must be able to secure items that have to be in that form of a framework. This includes personal data and corporate identity at the very least. Security starts here, with identity and personal data.
Robert Meyers is Compliance and Privacy Professional, at One Identity.