Skip to main content

Dev-Ops: Security considerations for microservices

(Image credit: Image Credit: Profit_Image / Shutterstock)

Introduced into the software development space only a few years ago, microservices is an architectural style which enables developers to build out software applications that are easier to update and scale.

Before the technology became available, developers designed software applications using a monolithic approach, where all the functions of an application were built as a single and indivisible unit. However, as applications get bigger and more complex, using a monolithic approach has become problematic. In a monolithic approach, if there was an error within the application, everything would need to be taken offline, however with microservices architecture, each function can be built and deployed independently, meaning individual services can function (and fail) without impacting others.

By using microservices, a large application can be divided up into many smaller building blocks, each an executable piece of software that as a whole collection 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 boundaries around their responsibilities.

While microservices and monolithic offer different benefits to application development, it is fair to say that many developers today are abandoning the traditional monolithic approach and are seeing that the capabilities offered by microservices better suit their organisation’s growing and diverse environments.

However, before adopting a microservices architecture, there are a number of security risks which must be addressed first. So, what are the key benefits of microservices and what security and privacy issues does the function introduce?

The benefits offered by microservices

The biggest benefit developers using microservices will experience is the ability to update and develop application components without taking everything offline, colliding with other teams who are also carrying out updates or rebuilding the entire service.

Within a monolithic approach, as a once-simple application increases in size and grows in complexity, there will be many development teams carrying out updates at the same time. However, because the application is built on a single unit, there will often be a lot of overlap among the teams which can make code changes collide. This makes it difficult for updates to take place, impacting the applications quality, availability and performance.

Microservices, on the other hand, offer a much more granular approach, breaking applications down into their core components and having independent teams manage each of the functions. The architecture allows teams to work on different areas of the application, each managing their own updates and development cycles, without ever impacting other teams and allowing code changes to happen independently.

Without question, the capability of the microservices-centric design can dramatically speed up development and deployment. Individual components can be updated as the teams develop and test, without updating the entirety of the application framework or service.

However, while microservices offer many benefits, developers need to be aware of the security and privacy issues that are introduced as a result of the function.

Security considerations within microservices

While microservices speed up and simplify application development, the function does introduce additional security complications, particularly as there are different teams managing different functions within an application, which can significantly impact privacy.

If an application has access to personal data – whether it belongs to customers or the organisation – ensuring the data does not fall into the wrong hands is critical. It is therefore important to ensure that the data is only accessed by authorised individuals and that security is not impacted as a result of development updates. Anything dealing with personal data must follow a privacy by design framework. It is also important to follow the CIA triangle - confidentiality, integrity, and availability, where each have an equal presence.

Another security issue which must be addressed is ensuring that as applications are broken down into multiple components, this does not increase an organisation’s attack surface.  When thinking about security, you have to be able to create walls around what teams managing different application features can and cannot do and can and cannot access. It is therefore critical that each application component is properly secured - and this security is managed and updated regularly. New attack techniques and threats are developed every day and as a result security needs to be updated continuously. This means applying patches when they become available and making sure any vulnerabilities are mitigated.

It is also important to remember different regulatory requirements for services industries like PCI -- DSS or SOX compliance or regulatory compliance such as GDPR. Organisations need to carry out internal audits to ensure all their environments comply with each of these regulations, otherwise they could face hefty fines.

DevSecOps is recently growing in popularity and it encourages security to be introduced at the very beginning of the development lifecycle. This is a process which is recommended when it comes to microservices. Security should be considered with every application update and, as environments become more complex, each team that manages different functions with an application must be responsible for security and must ensure it is maintained. Security and privacy must be embedded in every aspect of development.

Closing thoughts

Microservices have 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; however, any organisation adopting the architecture must understand and address the security and privacy issues the technology can introduce.

This means following privacy and security by design principles and ensuring that even when there are many different teams managing different application components, security requirements are never compromised.

In general, questions need to be asked around whether microservices is the correct technology to be used for managing personal data, what boundaries are being put in place to protect sensitive data and what processes are in place to ensure all teams have a responsibility for security. Once these questions are considered and answered, developers should be able to use microservices securely and reap the many benefits they offer.

Robert Meyers, compliance and privacy professional, One Identity