Author: Ricky Magalhaes
Agile microservices are becoming prolific and the accepted way in which we choose to build our apps and services. On the one hand, microservices allows us to move away from the monolithic approach with mainly positive results and advantages from a functionality perspective. They allow for better scalability, speed, control, and automation. On the other hand, because we are now dealing with many small units (that may be dispersed over multiple machines and systems) that function as one, the threat landscape of each application is greater and securing these services becomes more of a challenge. The multiplicity of parts need to be properly monitored, managed and secured. Moreover, the threat model is significantly different compared to the monolithic alternative and thus new securing methods are necessary to properly address these challenges as to not encumber the benefits–the essence of what makes microservices so advantageous.
With monolithic architectures, processes mainly communicate internally and locally. Microservices changes this. Microservices enables applications to be separated and each function can be independently developed. These smaller parts can then interact with each other to function as the final application. Each separate function must then be able to communicate and interact with the other and this is achieved through the cloud. It is simple to see how the architectural differences can impact the security. We have moved from securing a single application kept within a single operating system to a multiplicity of parts dispersed in a multicloud environment.
Development is much faster on micro computing platforms and deployment and scale benefits are experienced by both developers and end users. End Users can benefit from better performance and seamless updates to applications as well as lower costs. However, security is more convoluted for both developer and end user as the system is distributed.
The challenges
Greater area for attack
The attack surface increases for a multiple of reasons. The services are dispersed. There are more ports that are open, APIs are exposed and authentication becomes tricky as it needs to be undertaken at multiple points. Perimeters are no longer defined.
As each individual functionality must interact and communicate with the others they do this through APIs (application programming interfaces). These APIs are exposed and increase the attack surface substantially.
Considering all of this, applications built from microservices must be secured at a multitude of points. The security will not be good enough if only the input and output functionalities are secured but all other microservices and APIs must also be properly secured which can be tricky to accomplish.
We need to aim to reduce this area of attack.
Development and Operations converge (DevOps)
Microservices is triggering a closer interaction between the development and operation teams in order to support the applications lifecycle. Both development and operations need to have a good understanding of the processes involved and to ensure any security risks can be reduced.
A recognisable benefit of building applications in this manner is the speed at which it can be accomplished. Each functionality can be developed separately and independently of the other, thus each one can be undertaken by a different team and the time drastically reduced to achieve an operational application. However, often this leads to a lack of testing and security assurance of the applications.
The applications are becoming operational within a fraction of the time but this often happens at the detriment of testing. As normal testing procedures seem to be overlooked and less designated time is spent on testing, this is leading to the release of applications that have not been thoroughly tested before they go live. Many of those applications are including security vulnerabilities. These vulnerabilities are only realised once security has been compromised, which is then too late.
Improved agility can create security issues too, as more frequent builds have to be deployed and each can pose a security risk.
Integrated security by design
With the monolithic approach security has mostly been an afterthought. After completion of the application, only then was security considered. This approach to security will not suffice when microservices are utilised.
When microservices are used the security must be part of the building blocks of the application and must be a fundamental part of the architecture. Building security in from the get-go does take careful thought and time but at the end of the day this is best practice. This is necessary for a multiservice approach and will reduce the risk for security vulnerabilities surfacing later on, which will be more challenging to deal with at that later stage.
You are aiming to achieve the following by integrating security from the get-go:
- Strengthened and comprehensive security
- Improved intelligence
- Improved monitoring
- Better policy enforcement
- Ability to address governance and compliance by design
Best practices to secure microservices
Identification and monitoring of inter-service interactions and communications
It is essential to identify the interaction and communications between the various parts of a multiservice. This is often a challenge for security, the developer may know how it all fits together but admin may not. Admin are mostly responsible for configuring security policies and this is difficult to do properly without a comprehensive knowledge of the functioning components.
By viewing the traffic flow between the services it may help to ascertain where security policies may need to be applied and give a clearer understanding of how the application behaves. By knowing what the norm is, anything out of the norm can also be detected which may help to identify any potential compromises to security.
Improved visibility and control
For a microservices architecture you must have greater control and a more detailed view as your networks will be more convoluted because of the microservices use. The security system must be able to pick up on any visual changes in flow of traffic, any new threat vectors arising or misuse of rules and policies. You need to acquire application aware security solutions so that you have the necessary control and visibility to protect the applications and the greater systems.
Isolating services
Micro-segmentation is a means to isolate applications through the enforcing of security policies. This should not be done at a perimeter level but rather at a cluster level to be effective. The idea is to constrain the services by inserting controls around them.
Secure data
The services need to communicate with each other over a variety of systems and locations. Communications between applications must be properly secured to improve security but also for compliance reasons. This is essential as traffic is likely to pass through public environments too. Certificates must be maintained and software kept up-to-date. This needs to be achieved without causing an impact on the performance (management tools may help to achieve this). Encrypting data being communicated is essential.
Automation to manage policies
Human error is responsible for many compromises to systems security. By automating procedures such as updates, policy defining and policy replication, managing of SSL certificates and encryption keys, and separation and management of roles will reduce the chance for human error. Automation will aid in achieving an improved security posture.
Scalability and performance
The architecture must be able to support the ability to scale so that performance is not hindered. Without the appropriate architecture, the necessary security controls will be difficult to employ.
Authentication, authorisation and access control
Controlled and authorised access to the APIs is essential. This coupled with a reduced attack area will improve the security posture greatly. The principle of least privilege should be enforced to control access on a needs basis. Access to the internals of the services should be made off-limits to prevent human error.
There will come a time when data can be segregated and secured through the use of granular access control and cryptography. Applications will merely process the data by authenticating on switchable keys that expire and only will work in context. The data will be able to be geo-fenced and kept in the jurisdiction of choice and will proceed accordingly. This future is quickly becoming a regulated industry that will dictate the security that should already have been architected to form part of the microservices infrastructure.
In conclusion, Microservices is considered the superior, efficient way to develop applications and services and make it easier for developers to use and it is advantageous for end users as well. Microservices are part of the greater move towards DevOps refinement. We must ensure that comprehensive security is achieved and should follow the best practices.
Microservices changes the way in which we develop, consume, maintain and operate applications allowing scalable, portable, and adaptable applications, developed at speed. That being said we need to adapt our security to meet these changes too as to not deter the benefits of microservices.
Source: TechGenix
