Microservices have become the leading method of application development.
Unfortunately, security testing has not evolved quickly enough to address the risks introduced by this mass adoption of microservices.
Engineers and architects are challenged by security issues that arise with microservices. If these concerns are not addressed in the SDLC, vulnerabilities will appear in production.
The common practice is to test for vulnerabilities in each microservice, the reason is that every instance of microservice exposes its own set of entry points, APIs, and communication paths that create exposure to additional attack vectors that are currently not addressed. But this is not so simple to achieve in a complex microservices architecture.
This is part of a series of articles about Web Application Security.
In this article, you will learn:
- The Top 5 Challenges of Microservices Security
- Best Practices for an Effective a Microservices Security Architecture
- Automated Microservices Security with Bright
Top 5 Microservices Security Challenges
The diagram below illustrates how even a simple microservices architecture involves multiple components, each with its own vulnerabilities and security risks. Let’s review the top 5 microservices challenges making it difficult to secure modern applications.
1. Infrastructure design and multi-cloud deployments
Microservices are distributed over many data centers, cloud providers, and host machines.
Building infrastructure across many cloud environments increases the risk of losing control and visibility of the application components.
2. Segmentation and isolation
Decoupled application components perform their duty in co-dependence with many other services.
All these components establish and maintain communication channels over different infrastructure layers, so often cross-service communication is skipped when testing for security vulnerabilities, the result of this is significant exposure in the interfaces between these services.
3. Identity management and access control
Microservices expose new entry points to both internal and external actors.
Access controls need to be regulated for all entities, whether legitimate or illegitimate.
It’s important to have an administrative interface that can help you manage users, applications, groups, devices, and APIs from one central location, giving you real-time visibility into what’s happening in your environment.
4. Data management
Data generated in a microservices architecture moves, changes, and is continuously interacted with. Data is also stored in different places and for different purposes. Owners of data assets need insight into the life cycle and the dynamics of data to avoid breaches.
Can you be sure that your data is secure?
Data leaks can happen regardless of the communication channel’s exposure. Malicious actors can chain vulnerabilities to break through to private assets.
5. The rapid rate of application changes
Application development in modern SDLC forces the code base and data stores to grow over time. Development methodologies push iterative and incremental development, putting microservices under the constant workload.
How can you know at any time that new code coming through the development pipeline will not expose your application to the new sets of vulnerabilities and dangerous attack vectors?
Security testing must keep up with the pace of the SDLC, to enhance DevSecOps.
Decomposing applications into microservices increases the application’s attack surface because of newly added entry points and connections between instances that are now spread out over many environments, because of that microservices security requires non-trivial and ready-made solutions.
Related content: Read our guide to websocket security.
Best Practices for an Effective a Microservices Security Architecture
The following best practices can help you design security into your microservices applications and address application security challenges.
Deploy Security at Container Level
In many, microservices are based on container technology. The most glaring vulnerability of containers is that they are based on images, which may contain vulnerabilities. Perform regular scanning to ensure you don’t use images that contain security vulnerabilities or other security issues.
In addition, a container has both internal and external threat surfaces. A great first step to protecting containers at runtimer is adopting the principle of least privilege (POLP). This can involve some or all of the following strategies:
- Limit permissions to the minimum required by each user or service role
- Never use sudo or a privileged accounts to run services
- Limit or control the use and control of available resources—for example, restrict a container’s access to the host operating system
- Never keep secrets on the container, because anyone with access to the container can see them
- Define isolation with appropriate rules for resources with different levels of sensitivity
Create an API Gateway
Microservices often span several different networks, using a variety of technologies, interfaces and protocols. An important way to secure microservices is to create one entry point, which all clients and systems access, and which can easily be secured.
This entry point is called an API gateway. If you design your system in such a way that all clients always connect to the API gateway, you can use it to perform authentication and authorization, and filter requests to sensitive resources. The API gateway authenticates users and service roles and decides which microservices they are allowed to access.
API gateways can provide additional security capabilities like SSL termination, protocol conversion, monitoring, routing, and caching of requests.
Isolation
In a microservices architecture, each service is a separate, isolated part of the application. You should be able to implement, maintain, modify, extend and update microservices without
affecting other nearby microservices.
Isolation should also be performed at other layers of the infrastructure, such as the database. One microservice should not have access to data belonging to other microservices. By achieving complete isolation at all layers, attackers who compromise one microservice cannot perform lateral movement to attack other parts of the system.
Use OpenID or OAuth 2.0
OpenID and OAuth 2.0 are two authentication systems that can generate tokens to enable secure user access. Using a system like OAuth 2.0 is excellent for microservices security. It ensures users obtain permissions to any resource via a resource server.
OAuth can provide four types of authentication tokens—resource server, resource owner, authorization server, and client. Tokens can be used to access resources until they expire. OAuth also provides a mechanism for refreshing tokens after the original one expires.
Learn more in our detailed guide to web application scanning.
Don’t Show Sensitive Data As Plain Text
Plaintext can be easily read and copied by users and machines. A first step to protecting personally identifiable information (PII) is to avoid displaying it in clear text. All passwords
and usernames must be stripped or masked when saving logs or records.
Adding TLS/HTTPS will not solve the problem, if data is stored unsecurely at rest. You can also try to encrypt logs, but this won’t help against attackers who can directly access system memory. Therefore the only safe route is to avoid persisting sensitive information in the first place.
Automated Microservices Security with Bright
Bright integrates automated AI-powered Dynamic Application Security Testing into the SDLC to scan applications built atop of the complex microservices architecture each time the application code is packaged to a running application and forwarded to the testing phase.
Bright provides you with real-time reports with zero false positives in no time, where you can see reported vulnerabilities with a reproducible proof-of-concept and ranked by the severity of the impact they make on an application, this confirms the overall health and capacity of an application to handle production runtime without being exposed to vulnerabilities, regardless of the scope and the complexity of the underlying microservices architecture mesh.
Start protecting microservices today — try Bright free
