Microservices architectures seem to be the new trend in the approach to application development. However, one should always keep in mind that microservices architectures are always closely associated with a specific environment: Companies want to develop faster and faster, but resources are also becoming more limited, so they now want to use multiple languages and approaches. Therefore, it is difficult to evaluate a microservice architecture without reference to the environmental conditions. However, if you separate these external factors, you can still see that a microservice architecture offers much more isolation than other architectures – and can also handle security measures better than, for example, monolithic approaches due to today’s techniques and tools.
In recent years, the trend of microservices became more and more prevalent and took over the large monolithic systems. One reason for this is that companies want to be independent of a single platform in which all functions are combined. Often, individual functions do not fit the business processes or the best solution for an application is not offered in this platform. Therefore, the idea behind microservices is to use the most suitable solution for each individual requirement. This can be achieved by dividing the system into many smaller services, each of which is responsible for a specific requirement. [1]
There are many reasons why companies have chosen a Microservice architecture over a single monolithic platform. Which architecture is ultimately better depends, of course, on the needs of each organization. After all, different types of services need to be provided by both. One important service, among others, is the process and guarantee of security. Because with the emerging hype of the microservice architecture, the question also arises whether a more secure overall system could also be created as a result. Security challenges are one of the most important factors for organizations to be able to offer their product reliably. Is the customer’s data stored securely? Are there security gaps between the interfaces? How can developers access data without being exposed to the risk of external parties being able to read this data?
Therefore, with a microservices architecture, you might want to think not only about the structure and processes, but also focus more deeply on the security component for once. In particular, not only what the security strategies of microservices look like, but also their best practices for avoiding attacks.
Monolith first
To understand why the security challenges with microservices need to be handled more elaborately and with much more thought, the difference to the monolithic approach needs to be explained first. In the case of monoliths, usually only one platform is provided, which includes all functions. A monolithic architecture does not follow an explicit division into subsystems, i.e. it is not broken down into several services that contain different components.
Monolith Architecture
Monolithic systems usually try to cover a wide range of related functions. For example, a monolithic Web hosting platform may include not only a Web server that handles HTTP requests on the server side, but also load balancing, a content distribution network and also firewalls. Backup – and security systems are provided by the platform and are therefore already in place. [1]
With Microservice architecture a contrast to traditional, monolithic approaches is created. With microservices, an application is structured as a set of distinct services, each serving a different purpose. So if a service within an application fails, the application can still continue to run. The communication between the services takes place via application programming interfaces (APIs) and thus even complex applications can be realized. [1]
As can be seen in the following figure, this can be used to divide an e-commerce application into its main tasks. In this way, a separate service is created for user accounts, inventory and shipping, each of which performs its own functions separately from the others. In addition, the application consists of several components, whereby, among other things, a separate data store is made available for each service. [3]
Microservices Architecture [3]
Microservices offer with their approach of structure valuable flexibility that cannot be provided by the traditional monolithic approach. As their services are separated from each other, the services are more differentiated and can run independently from each other.
Based on their advantages, you can clearly see why the trend of many organizations went in the direction of microservices architecture. However, with new trends, often only the advantages of the entire system are brought to the general public and it is often forgotten that other systems may offer better ways in certain processes. Thus, good software architecture is characterized in particular by whether the system is robust, not susceptible to errors and, above all, secure. Unfortunately, security is still a frequently neglected non-functional property of today’s IT systems. We should therefore ask ourselves how a microservice architecture deals with this property.
How to secure Microservices?
With microservices architectures, there are a lot of contact points where the application and its data can be protected. Intelligent endpoints and dumb pipes for asynchronous communication mechanisms, management that no longer takes place in just one place, plus new data management and, last but not least, automation of infrastructure and distribution. All this leads to a new distributed and dynamic system in which security risks must be avoided. It is important to remain agile and keep the microservices security pattern up to date simultaneously. [2]
Layers of Protection
Especially the services with the most sensitive data must be protected via several security measures. The more important the data, the more layers of protection are needed. This strategy, which involves multiple security controls, is also called “defense in depth”. It is no longer sufficient to rely only on a single firewall as was the case with monolithic systems. [2]
Defense Layers in Depth
This is also called “secure delegation” and is the security architecture of highly distributed systems. In this case, for example, the data layer can still check the validity of the request, who is the sender and who is the internal middleman. The requirement is that absolutely no credentials are sent, only secured tokens. And the identity of the client and its access rights can be checked at any border.
Isolation
One of the basic principles of microservices architecture is isolation. Among other things, this prevents neighboring services from being affected if individual services fail. And if attacks or security risks occur in a microservice, the attacker would not be able to access other services. Thus, for example, the data of another microservice cannot be accessed at the database level. So isolation ensures that each individual microservice can be deployed, maintained, modified, scaled, and decommissioned without impacting the surrounding services in an application. This is a powerful change compared to the monolith from above. [4]
Practices to prevent Microservices from security risk
There are many practices on how to deal with these security challenges. Some methods are standard practices and are not only used in a microservices architecture. However, the strategies mentioned below are especially recommended to be used in the case of a microservice architecture so that a secure system can be created. These practices can make it easier for developers not to test only at the end of a single event, but to create a fast and flexible development cycle using CI/CD approaches (Continuous Integration/Continuous Delivery).
API Gateways
Even in a microservice architecture, communication must be established between the client and the microservice. Each microservice provides several endpoints and it must be guaranteed that different formats, such as mobile remote apps or web applications on the client side, can communicate with several microservice types.In order to reduce the requirements on the back-end system and to make communication with multiple microservices less extensive, API gateways are inserted as an interface at this point. However, API gateways not only contribute to the optimization of the communication paths, but also facilitate the development work on the part of the microservices. Overarching aspects, such as security and authorization, can now be implemented at a central point, and at the same time direct access from outside can only take place to a limited extent. This separates the microservices from the outside world and they cannot be used directly by the clients. [5]
Authentication secure
An important security aspect is user identification. In order to find out whether the respective user is a possible attacker, microservices must also implement strategies for user authentication and access control. In addition, the interaction of many microservices raises the question of whether each individual user call to each microservice should be authenticated. Wouldn’t there be many disadvantages in performance and complexity if every microservice implemented user authentication? A popular standard for user authentication is OAuth2 (“Open Authorization”), which can be used to ensure that such disadvantages do not arise. With this open standard protocol, access can be delegated. Here, a dedicated OAuth2 server is operated, and microservices also require additional OAuth mechanisms for verification. [7]
OAuth Authorization Flow [6]
As one of the actors, the resource owner serves to give permission to a client to access the data on its behalf. Therefore, an access token is created and exchanged according to the OAuth protocol. This token is used to grant access to the data in the resource server. This server then checks the validity of the token using the validation of the OAuth server. In addition to the authorization of a user’s request, authentication takes place beforehand. In order to avoid the before mentioned problem of having to implement authentication at each microservice, this is done centrally in the API gateway. [7]
Dependency Management
What plays a crucial role in microservice application development is the fact that multiple teams of developers can work simultaneously on different processes in one system. These processes often contain only small services, for the development of which common open source modules are used. Therefore, the majority of software on organizations today consists of third-party components and are open source. These modules often bring with them a wide range of dependencies, all of which are impossible to audit and track for security. Accordingly, it would not be noticeable if there were security vulnerabilities in one of their dependencies, since in addition to direct dependencies there are also transitive ones – basically a dependency on a dependency. Therefore, it is highly advisable to have these dependencies checked via certain helper tools. Especially with regard to outdated dependencies that let an application be significantly affected. Because old libraries often have detected vulnerabilities and without detection that this library needs to be updated, this risk remains. [8]
However, companies repeatedly have the problem that the priority for updating dependencies is very low. Often, warnings about expiring libraries or even updates are ignored because the software is still working properly. Simple laziness is thus the main reason that companies do not update their modules. Another reason can be the fear that the current build will no longer run because updating one dependency has broken another, transitive dependency. To prevent this from happening, there are several dependency management tools available. For example, the SonarQube tool can be used to perform a quality check of the dependencies in the code. There are also tools like SonarQube that can automate dependency updates. What brings us to the next point. [8]
DevSecOps Tools and practices
Running processes in an automated way and working together efficiently and effectively in the area of software development are part of important methods of the DevOps approach. But while DevOps is responsible for providing the infrastructure for services and delivering those services, DevSecOps is about the security of that infrastructure.
DevSecOps Pipeline [9]
What this means is that the entire DevOps pipeline – the stages from requirement, design, code, build, test to deployment stage – must have a security infrastructure built into it. And for a company to achieve such DevSecOps including safe delivery of code, it must also make use of certain tools and practices. This already shows that the DevSecOps approach also entails further structural adjustments in companies. Not only in the expansion of the tools, but also in the overall processes and the scope of work of the employees.
One important starting point, among others, is the integration of security processes into the CI/CD pipeline, so that this process can also be automated. Here, the first step could be scanning the code for vulnerabilities, which must be done at every stage of the development process. For example, technologies that incorporate Static Application Security Testing (SAST) security concepts are applied here. This involves performing checks early in the development process by running special tools over the code to detect vulnerabilities in the code. This is a white-box process, which means that the code is only visible and does not have to be running. The main goal here is to find contaminated code that could later introduce malware.
There are also other tools for detecting vulnerabilities in open source components. Many of these vendors have also developed their tools to the point where they can be easily integrated into build environments such as CI servers, build tools or repositories. [9]
Another important aspect is that the protection continues during the runtime and the software is secured against threats even when it is put into operation. Tools can be used to monitor the application for unusual behavior and respond to security vulnerabilities. [9]
Cloud-native Container Security
The cloud-native approach focuses on creating microservices. In this method, applications are developed and operated entirely in the cloud. Why this approach is used is especially due to the advantages that a cloud environment brings and perfectly matches the concepts of a microservice. Containers can be used to decouple systems, for example, making the individual services independent of each other and providing a more targeted focus on the individual systems. This leads to better resilience and handling. Because cloud environments benefit not only from a containerized but also dynamically orchestrated platform, software automation is driven more stably and you can respond more quickly to changes. Together with the DevSecOps approach, the process strategy can be improved and risks minimized. Among other things, a number of automated container security technologies and tools provide methods for containers to be secured. This is because containers also bring several challenges in terms of security that should be noticed.
Containers take a lot of effort away from developers by providing images and processes, but then the question arises whether they really know what exactly is happening on the platforms. One of the main problems is the lack of visibility, which can easily hide vulnerabilities. [10]
Microservices Security: Always staying ahead
Microservice architecture offers the opportunity to focus on work organization and economic growth in addition to technology. With this software architecture, companies could expand their resources. However, it is also important to ensure that, especially when individual resources are outsourced, secure data transfer and storage remains guaranteed and other security challenges must be managed. But how does the whole approach impact organizations when security measures need to be implemented throughout the DevOps pipeline? Especially in light of the constant expansion and evolution of system architectures – from a monolithic architecture, to microservices architecture, to more cloud-native environments. Many new trends lead to further advantages, such as easy scalability, flexibility or fast maintainability. However, regardless of which architecture suits a company best, with each update it is also dependent on considering the new security strategies and also implementing them with the help of security processes and tools. This is the only way to create a secure and robust system.
Sources:
[1] – https://www.talend.com/de/resources/monolithische-systeme/
[2] – https://www.whitesourcesoftware.com/resources/blog/microservices-architecture/
[3] – https://microservices.io/patterns/microservices.html
[4] – https://securityintelligence.com/posts/how-to-secure-microservices-architecture/
[5] – https://docs.microsoft.com/de-de/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern
[6] – https://docs.oracle.com/cd/E82085_01/160027/JOS%20Implementation%20Guide/Output/oauth.htm
[7] – https://blog.viadee.de/microservices-absichern-mit-spring-boot-netflix-zuul-und-oauth-2-0-teil-1
[8] – https://www.whitesourcesoftware.com/free-developer-tools/blog/dependency-management/
[9] – https://www.whitesourcesoftware.com/resources/blog/devsecops/
[10] – https://www.whitesourcesoftware.com/resources/blog/top-container-security-tools/
Leave a Reply
You must be logged in to post a comment.