What Are Microservices And How Do I Secure Them?

I'm consistently seeing twitter feeds with #Microservices embedded in the tweets.  So, what are microservices, what value do they add to my business and how do I secure them, if I decide to adopt them? 
​
MicroServices
 
Firstly, microservices and REST, are architectural approaches to developing code.  So, let me cover what REST is, and then microservices becomes a little easier to understand. 
 
In the Certified Cloud Security Professional course that I run, there is a specific section under Cloud Application Security, where the learning outcome is to describe specific cloud application architecture and to understand the application programming interface (API) structures. 
 
Below is a diagram that outlines the 2 types of APIs that we consider in the course:

To summarise, SOAP is a protocol for exchanging structure information, whereas REST is an architectural style that relies on stateless, cache less protocols.  Put simply REST is a way of Creating (using the POST verb), Reading (using the GET verb), Updating (using the PUT verb) and Deleting (using the delete verb).
 
Let's extend this concept a little further and we'll start to understand Microservices.  With REST, we can see that the commands, or verbs, are very simple.  This means it's easy to create small independent services.  Principle 1 of Microservices.
 
By ensuring that our APIs are clearly documented and follow this RESTful style, we form the basis of creating well-defined, lightweight APIs.  Principle 2 of Microservices.
 
And finally, by using REST, i.e. POST, GET, PUT, DELETE we are using an HTTP resource API.  Principle 3 of Microservices.
 
Let's expand out those 3 key principles and explore what they mean:

P1 - Create Small Independent Services.
Independence means that we do not need a centralised datastore, instead the data is distributed and when we change one of our services, it does not require other services to be changed.  This is referred to as loose-coupling.
Small means that each we focus on a very small set of capabilities that focus on a specific domain.  Ideally a single capability.

P2 - Create well-defined, lightweight APIs.
Well-defined means that I clearly document how to call the API.  Lightweight referring to the small range of functions that I can execute to achieve my outcome.

P3 - Using an HTTP resource API where possible.
This means we are using HTTP commands, i.e. POST, GET, PUT DELETE in a RESTful manner.

Here is a piece of code below that follow the 3 principles using AWS.  It deletes a jpeg picture file, called dodgy picture, from storage on AWS.  The storage is simple storage service, or S3 for short, and we refer to the container that holds the jpeg, as a bucket:
 
DELETE /dodgy_picture.jpg HTTP/1.1
Host: examplebucket.s3-us-west-2.amazonaws.com
Date: Mon, 11 Apr 2016 12:00:00 GMT
x-amz-date: Mon, 11 Apr 2016 12:00:00 GMT
Authorization: authorization string

In this case, we can see it is a Small Independent Service, it uses an HTTP resource API, it is lightweight and it is well-defined, as exemplified by the AWS S3 documentation:
 
http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html
 
We can also do the same on Azure.
 
Again, the documentation around Azure Blob storage shows the APIs are well-defined:
 
https://docs.microsoft.com/en-us/rest/api/storageservices/blob-service-rest-api

Security
 
If we look to the certified cloud security professional (CCSP) best practices, we can see some common themes that apply to microservices:
 
Secure APIs
To provide unauthorised access to the data, leading to data loss, data breach or service hijacking, it's best to implement a method of ensuring that the API calls you receive are authenticated.  In other words, they are authorised to make the call and access your data.
 
This can be achieved using an API gateway service, such as AWS API Gateway or Azure API Management, most likely linked to a directory service, such as Microsoft Active Directory or AWS Cloud Directory service.

Protect Data
To protect the data in transit between the two API calls, it's worth considering virtual private network (VPN) technologies, such as Azure VPN Gateway or AWS VPN CloudHub. 
 
To protect data at rest you can use encryption.  Encryption requires the exchange of keys and the keys need to be secured in a safe place.  Remember if the location is too safe, and you cannot find the keys, you cannot unencrypt the data.  Which means you're prone to data loss. 
 
Data in Motion
Azure VPN Gateway / AWS VPN CloudHub
 
Data at Rest
Azure Storage Service Encryption / AWS S3 Server-Side Encryption
 
Key Management
Azure Key Vault / AWS Key Management Service / AWS CloudHSM

Monitor
Enable application logging on all your API's so you can see that they are behaving as required.  Logging at the infrastructure level can also reveal vulnerabilities that may affect the way APIs are called.  At both levels, you should be centralising all your logs into a SIEM (Security Information and Event Management) system.
 
SIEM
Azure Log Integration / Azure Operations Management Suite - Log Analytics / AWS Kinesis / AWS ElasticSearch
 
The OWASP Top 10 outlines application best practices to avoid common vulnerabilities that can be introduced as part of a software development lifecycle.  There are various tools that can be used to help detect the OWASP vulnerabilities:
 
OWASP Detection Tools
Amazon Web Application Firewall / Azure Application Gateway
 
Vulnerability Assessment
Azure Security Centre / Azure API Management
AWS Inspector / AWS Vulnerability / Penetration Testing
​

​Business Value
 
By adopting the 3 principles we outlined above and incorporating the key security best practices, we can clearly see that we're helping the business in many ways:
 
Faster Value
Adopting a microservices architecture, allows us to develop services quickly and scale them as required.  When this is\ combined with agile storyboarding and agile prototyping techniques, our clients can clearly see tangible results within weeks.
 
Higher Efficiency
The probability of wastage decreases rapidly by adopting a microservices architecture, since we are focused on creating functions that our clients absolutely need.  By enabling secure API communications coupled with logging, we can provide quality assurances back to the business using analytics. 
 
We also have the freedom to fail-fast which means we can innovate and try out new things.  And because our architecture is comprised of small, loosely-coupled components, we can roll-out new versions or releases of services, in a DevOps manner, on a weekly basis, rather than performing this on a monolithic scale every few months or years.
 
Finally, we can take microservices further by utilising serverless architectures, such as AWS Lambda or Azure Functions.  This reduces the need for our developers to worry about the size and scale of the virtual machine and storage infrastructure and instead focus on writing reliable, scalable and easy to understand code.
 
Another concept we can utilise is containerisation, using Docker, which effectively builds us a consistent environment that we can port between test, pre-production and production without introducing those nasty regressions, or unintended bugs.  Docker manifests itself as AWS EC2 Container service or Azure Container Service.
 
Both serverless architectures and containerisation concepts are blog posts, so I’ll cover them in future blog editions.
 
What are you waiting for?  Let's move to microservices….