If not addressed in design and deployment, the risks with microservices can multiply since any application could be composed of hundreds of microservices
The use of cloud software and services has grown with organizations taking advantage of the opportunity to reduce OPEX and offset support costs by using someone else’s hardware. In tandem, consumption of cloud services has increased with more people working remotely. Criminals have spotted this, and in 2021 we saw a few toe-in-the-water attacks culminating in the Log4j zero-day vulnerability, which has been widely reported in the media.
We have also seen microservices become a highly popular method for developing cloud-based applications. It is simple to deploy, and the ability to upgrade application components without significant downtime allows providers to offer enhanced service level agreements and reliability statements for their customers, resulting in an overall better customer experience. Many of the applications and services we use daily are developed in this way. They have become so reliable that even a moment of outage feels unacceptable, when in the past, it could be the expected norm for systems to go offline for hours in a month for ‘service upgrades.’
For all the positive benefits of microservices, security has proven to be a challenge as testing evolution falls behind and fails to keep up and address risks caused by mass deployment and adoption. Remember, taking a single application and breaking it into smaller components will increase the potential attack surface available. Each microservice needs to expose its own set of APIs, communication methods and entry/exit points to be viable – and each of these carries a level of risk.
Secure Application Containers
It is common for microservices to use containers for deployment, but this method carries risk as containers are based on images – which can have vulnerabilities. It is essential to scan for and then address any discovered issues regularly.
Also, as mentioned above, remember that a container has threat surfaces, and so it is essential to apply protection thoroughly. One way of doing this is to limit access privileges for users and resources.
• Restrict permissions to the least required by any user or service, and never use SUDO or privileged accounts when running services.
• Do not store any secrets on a container. Anyone who has (or gains) access will see them.
• Consider isolation rules for sensitive systems. It should be possible to update, manage or modify a microservice without affecting nearby microservices. This isolation level also ensures that an attacker who compromises one part of the system will be restricted from lateral movement across the environment.
Ensure Data is Protected
This may sound obvious, but it gets overlooked, especially in internal environments. It’s essential to enforce HTTPS and encryption to secure data in transit and data at rest on the network. For added security, it is worthwhile to enable the ‘HTTP Strict Transport Security’ response header so that endpoint devices can only access via HTTPS.
These steps can reduce the risk of an attacker accessing and exposing data.
Reduce Access Points with an API Gateway
Users should not communicate directly with microservices, an approach which reduces the risk of direct access and a user being able to exploit a service directly. An API gateway provides a single-entry point for all traffic and redirects to the microservices.
Another benefit of an API gateway is that it can be configured to provide token-based authentication to reduce the risk of unauthorized users on the system and role-based access. Once a user is connected to their network and has access to data, privileges are well controlled.
Use Rate Limits
A common method attackers use to gain access to applications or deploy a denial-of-service attack (DDoS) is to use multiple sets of different credentials to access an application at high speed. By attempting and failing to login repeatedly, the application becomes bogged down in requests and eventually either fails or slows to a point where no one can successfully authenticate.
Rate limits can be configured to ensure that an application can only accept a fixed number of requests within a set amount of time and are a great way of preventing DDoS and credential stuffing attacks.
Adopt Defense-in-Depth as a Strategy
Most organizations use multiple security tools to protect their network and data. Still, each tool is often seen as a single measure rather than considering all tools together, as a secure environment.
Defense-in-depth encourages a review of all tools in place, ultimately defining a strategy to use everything available to create a layered security approach between users (or potential attackers) and applications/microservices in use.
An example would be to ensure that token-based authentication can allow users inside the firewall to access corporate services. Still, roles-based access ensures that users can only see what is relevant for them, and monitoring can alert them of any potential deviations or breaches. The combination of tools together provides defense-in-depth and a more robust security posture than a set of tools used individually.
Monitor and Update
It’s essential to constantly monitor microservices for potential attacks and to check for vulnerabilities or threats during development cycles. Many tools can help with this, such as open-source Prometheus.
Monitoring is only one side of this coin, however, as it is equally important to implement any changes recommended by the tools to make sure that microservices and platforms are fully up to date. All too often, vulnerabilities are exposed on older versions of code and force organizations to react with a fire drill to either update or lockdown at-risk applications and services.
Microservices are the future for cloud-based application development. The flexibility and scale allow organizations to grow on-demand and ensure that the best possible customer/service user-experience is always provided. The risks with microservices are not all that different than the risks with normal applications. Still, if not addressed in design and deployment, these risks can multiply massively since any application could be composed of hundreds of microservices.
Consider security at every stage of the design and deployment to ensure a robust security posture for your deployment.