Microservices is known to be the biggest promise of freedom. You are free to break an application into disparate services that are deployable independently and you can build them with different teams by using a programming language, database, and tooling. You can develop applications with minimal bureaucracy. But this freedom bounds you to ensure security. Applications are broken down into independent services in a microservices architecture. This means that there are more complexities and you have more services to secure. You have the technology by your side to help you with all of this, yet you need people to effectively secure microservices.
Developers are highly responsible for operating their code (DevOps) and securing the same code (DevSecOps). They have a different kind of behavior towards design. Besides, there is a difference in the kind of monitoring and tooling you have and the way you interface with systems built using a microservices architectural style. Remember the three guiding principles that guarantee strong microservices security are: traceability and development, compartmentalization, and continuous security visibility. These principles have made the job of security professionals and developers pretty easy.
Build security into your continuous delivery (CD) workflow. Within the CD workflow, you insert tests as well as restrict regions for deployment. You even set time for these kinds of restrictions. You thus automate service delivery and guarantee auditability. The point to be noted here is that you should not create a group of new tools and dashboards used by people. It is not a good practice to create interruptions in the workflow.
You should, instead, integrate with the workflows and tools that developers use currently. The tool that you use is not more important than the way you use it. When you work with the workflow that developers prefer and automate as much as possible, security teams can upkeep with the speed and agility benefits of microservices, while assuring security checks are well-placed.
Launching a “canary workload” is the other common, yet well-known technique to ensure that a new service doesn’t introduce security or other kinds of issues. A canary workload can be defined as a new production workload launched to limited users. If this kind of workload fails to trigger any automated security alert and looks fine, the CD tool rolls into full production automatically.
Continuous Security Visibility
Regardless of the size of your organization, you cannot have enough security resources to penetration test every application or look at all lines of code. Besides, one of the basic attributes of microservices is that they speed up change within and between applications. When you have dozens or hundreds of applications that change all the time, you should not rely on people giving information in an accurate or timely manner. You rather need automation or employ service discovery tools.
You can define service discovery as a registry of running instances for one or multiple services. At the time of employing service discovery tools, you can measure the riskiness of a specific service based on how many other services are dependent on it. The more these services depend on that specific service, the higher is the risk score. You also need to find out whether that service is exposed to external internet traffic. Automated security risk assessment helps you with risk stratification, allowing relatively scarce security people to focus on the microservices with maximum risk exposure. Most of the microservice frameworks offer one or several choices for service discovery.
Compartmentalization is crucial for distributed systems and the microservices that constitute them. There are two key reasons behind this criticality. Firstly, all security will probably fail at some point, which is why you should limit the blast radius of that failure. Secondly, you need to keep the data reserved only for those who need to know.
In the case of a monolithic application, things are not independent and stick together. Services are not independent of one another. Developers thus struggle to iterate on monoliths without breaking things during the process. Here, every breakpoint introduces new security issues. Monolithic applications have quite sensitive systems with a lot of inputs and outputs, i.e. the attack surface. Applications with a large attack surface can be secured, but it isn’t easy to do so. Besides, it is difficult to verify that things are working as they should.
Talking about a microservices application, security is effective and better. In this case, the “blast radius” isn’t the entire application, rather it’s just the individual services. Several security-forward companies choose to further improve on the security model with a token vault that stores sensitive data. Tokens map to the sensitive data and they are then passed around the application without the data itself moving. The token service calls crypto infrastructure placed between the token and the sensitive data, hence protecting the data. This way you can implement much finer-grained access control, making it quite easy to trace what’s happening.
Are your microservices applications secure?
Guided by the principles of traceability, continuous security visibility, and compartmentalization, security professionals can automate their security workload without burdening developers. Besides, as developers are increasingly asked to secure their applications, they also act as partners. Through automation, people and machines collaborate to make microservices highly secure.