arch:how_can_we_secure_an_msa_and_manage_access_efficiently

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

arch:how_can_we_secure_an_msa_and_manage_access_efficiently [2026/08/29 07:53] – Bulk sync migration userarch:how_can_we_secure_an_msa_and_manage_access_efficiently [2026/08/29 07:59] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +====== How can we secure an MSA and manage access efficiently? ======
  
 +By Nikita Galkin (nsgalkin@edu.hse.ru)
 +
 +===== Introduction =====
 +
 +“Microservices is an architectural style, in which large complex software applications are composed of one or more services. Microservice can be deployed independently of one another and are loosely coupled. Each of these microservices focuses on completing one task only and does that one task really well. In all cases, that one task represents a small business capability” [1]. As technology continues to evolve, the use of microservices architecture (MSA) has become increasingly popular. MSA allows for the creation of complex systems by breaking them down into smaller, more manageable components. However, with this increased complexity comes the need for enhanced security measures and efficient access management.
 +
 +Securing an MSA involves various ways:
 +
 +  - Secured microservice
 +  - Role-based access control (RBAC)
 +  - Well-made MSA design
 +  - Efficient access
 +  - Network security
 +  - Reaction procedures
 +
 +There is no need to choose, most of them can be combined at the same time, giving the best result. However, everyone must understand that certain purposes lead to the specific solutions. Some ways may be inappropriate due to user comfort factor, or different security needs. In any case, the approach must be based on the viewed system and its unique details.
 +
 +===== Self-security =====
 +
 +First, it is essential to ensure that each microservice is secure in itself. This can be achieved by implementing best practices such as using strong authentication mechanisms, data encryption or maintaining software up-to-date.
 +
 +Additionally, it is crucial to limit access to microservices only to those who require it. This can be done by implementing role-based access control (RBAC) or by approaching the well-thought and planned architecture, that ensures that the most vulnerable microservices are as far from the user that doesn’t need them, as possible.
 +
 +===== Role-based access control (RBAC) =====
 +
 +RBAC involves three primary components: roles, permissions, and users (see illustration 1). It works by granting permissions to roles, and then assigning those roles to users. Roles might represent job functions or responsibilities within an organization, such as manager, administrator, or analyst. Permissions define the actions that can be executed by the current role. Users are assigned to roles based on their job or needs. 
 +It simplifies access management by allowing administrators to manage permissions at the role level rather than for each individual user. It also reduces the risk of human error by eliminating the need for administrators to manually assign permissions to individual users. In addition, RBAC provides a clear audit trail by tracking which roles were assigned to which users and when.
 +
 +[[arch:_detail:arch:picture1.png|]]
 +Figure 1. Generalized RBAC model [2]
 +
 +Role-based access control is a powerful method, where “permissions are associated with roles, and users are made members of appropriate roles. This greatly
 +simplifies management of permissions. Roles are closely related to the
 +concept of user groups in access control” [3]. This way, it is not only effective for organizations, but also for any website with different types of users. For example, there is a website called “WeCare”, that was developed by the team of HSE students NSYM. This website offers a help to elders and volunteers, providing a connection between them. Elder users have their unique features, volunteers too. Access to them is controlled by the RBAC method.
 +
 +===== Well-made design =====
 +
 +Effectiveness and security of microservice architecture is highly dependent on the design we apply. Each microservice serves its own purpose and contains the data with which its functions are associated. Nevertheless, all microservices are interconnected and organized to share the data with each other. This data can be of different importance and, unfortunately, some users can be attackers, hackers who want to steal data and harm other users. None of the systems is protected from the technical failures either and it makes sense to make the most essential microservices work the least. The structure we develop to unfold all the user needs and platform functions should be protected from the user in the most optimized way possible. We can solve this problem by keeping the most important microservices and their data away from the casual user, providing access to them only through other microservices. Developers should focus on the fact, that access to the microservice is not always justified.
 +
 +[[arch:_detail:arch:picture2.png|]]
 +Figure 2. Data-flow diagram of microservices
 +
 +===== Efficient access =====
 +
 +Sometimes the best security design, where all the important microservices are hidden in the depths of the general system, isn't the best option. Security might lead to the challenges related with unnecessary delays and bottlenecks. Nobody shall forget: efficient access management is a problem also critical when working with an MSA. Finding the balance between effectiveness and security is a global issue that requires a delicate solution. 
 +
 +However, sometimes both factors might be driven by the same tool. One approach is to implement a centralized access management system (this can include RBAC), another is multi-factor authentication and other security measures to ensure that only authorized users can access the services they need.
 +
 +===== Network security =====
 +
 +Next, securing an MSA requires a comprehensive approach to network security. This is one of the most basic and obvious actions. 
 +
 +First of all, this includes securing the communication channels between microservices with traffic encryption. One of the best options is the use of HTTPS (Hypertext Transfer Protocol Secure) and REST API. API is the most basic element of MSA, and REST design principles make the use of API optimized and secured.
 +
 +Authentication techniques block the unwanted users from services. “OAuth is an HTTP-based authorization protocol that enables the protection of resources” [4] is a good example of such authentication tool, that works perfectly with the REST API.
 +
 +Intrusion detection systems are necessary to protect against attackers, this topic is well described in the next block.
 +
 +Audit logging is the foundation for accountability, making it real to identify patterns of problems, debug issues and then prevent repudiation threats.
 +
 +[[arch:_detail:arch:picture3.png|]]
 +Figure 3. Applying security controls to the Natter API [5]
 +
 +===== Reaction procedures =====
 +
 +Any security issue has to be fixed, because the lack of reaction to the problem might cause other, more devastating issues. Longer the breach occurs, more data the hacker can retract, people might spread the use of exploits or simply users might leave due to inconveniences. It is essential to have a robust monitoring and incident response plan in place. This involves monitoring microservices for unusual activity or potential security breaches and having a plan in place to respond quickly and effectively if an incident occurs.
 +
 +===== Conclusion =====
 +
 +In summary, securing an MSA and efficiently managing access requires a comprehensive but nuanced approach that includes securing individual microservices, implementing network security measures, having a robust monitoring and incident response team in place. In addition, efficient access management can be achieved through the use of centralized access management systems and, in particular, role-based access control method. By implementing these measures, any developer, not just enterprises, can ensure that their MSA is secure, effective and accessible only to authorized users.
 +
 +===== References: =====
 +
 +[1] - Daya, S., Van, N., Kameswara, D., Carlos, E., Ferreira, M., Glozic, D., Gucer, V., Gupta, M., Joshi, S., Lampkin, V., Martins, M., Narain, S. and Vennam, R. (n.d.). Redbooks Microservices from Theory to Practice Creating Applications in IBM Bluemix Using the Microservices Approach. [online] p.4. Available at: [[https://www.redbooks.ibm.com/redbooks/pdfs/sg248275.pdf|https://www.redbooks.ibm.com/redbooks/pdfs/sg248275.pdf]].
 +‌
 +
 +[2] – Ferraiolo, D. and Kuhn, R. (n.d.). Role-Based Access Control. [online] Available at: [[https://www.researchgate.net/profile/David-Ferraiolo/publication/2792237_Role-Based_Access_Control/links/5411a7230cf2b4da1bec6172/Role-Based-Access-Control.pdf|https://www.researchgate.net/profile/David-Ferraiolo/publication/2792237_Role-Based_Access_Control/links/5411a7230cf2b4da1bec6172/Role-Based-Access-Control.pdf]].
 +
 +[3] - Sandhu ', R., Coyne, E., Feinstein, H. and Youman, C. (1996). Role-Based Access Control Models. IEEE Computer, [online] pp.38–47. Available at: [[https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/sandhu96.pdf|https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/sandhu96.pdf]].
 +
 +[4] – Massé, M. (2012). REST API design rulebook [designing consistent RESTful web service interfaces]. Beijing [U.A.] O’reilly. [online] pp. 72-73. Available at: [[https://pepa.holla.cz/wp-content/uploads/2016/01/REST-API-Design-Rulebook.pdf|https://pepa.holla.cz/wp-content/uploads/2016/01/REST-API-Design-Rulebook.pdf]]
 +
 +[5] - Madden, N. (2020). Api Security In Action. [online] pp. 62-64. Available at: [[https://cdn.ttgtmedia.com/rms/pdf/bookshelf_apisecurityinaction_excerpt.pdf|https://cdn.ttgtmedia.com/rms/pdf/bookshelf_apisecurityinaction_excerpt.pdf]]