A security guard can be compared to a Zero Trust Architecture(ZTA)[1] in the sense that both aim to maintain a secure environment by continuously monitoring and verifying the identity of individuals or devices accessing resources. Just as a security guard checks the identity of everyone who enters a building, a ZTA verifies the identity of all devices and users trying to access sensitive information or systems, and only grants access if their identity is confirmed. Both the security guard and ZTA are proactive in maintaining security, instead of relying on a single barrier for protection.
The idea behind ZTA is simple: trust no one, and verify everything. This means that every request for access to a resource must be verified and authenticated, regardless of the user or device making the request. The traditional model, on the other hand, assumes that all requests coming from within the organization are trustworthy, while only scrutinizing those coming from outside the perimeter.
With the ever-increasing number of data breaches and cyber attacks, the traditional model of perimeter-based security is becoming less and less effective. Attackers are finding new and creative ways to penetrate defenses, and once inside the perimeter, they have access to an organization’s entire network.
In contrast, ZTA assumes that a breach has already occurred or is likely to occur at some point. This means that it is no longer sufficient to simply protect the perimeter. Instead, access controls must be applied to all resources, regardless of their location or the identity of the user or device requesting access.
The five core principles of ZTA are:
- Verify everything: All requests for access must be authenticated and authorized before access is granted.
- Least privilege access: Users are granted access only to the resources that are necessary to perform their job functions and nothing more.
- Assume breach: The model assumes that a breach has already occurred or will occur at some point in the future.
- Micro-segmentation: Resources are divided into smaller segments, each with their own access control policies, to limit the potential impact of a breach.
- Continuous monitoring: All network traffic and activity are continuously monitored for signs of malicious behavior or anomalous activity.
In ZTA, access control[2] is a critical component of the security framework. Access controls must be applied to all requests for access, regardless of the identity of the user or device making the request. To accomplish this, organizations can use various access control models, including Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), Access Control Lists (ACL), Policy-Based Access Control (PBAC), and Discretionary Access Control (DAC).
- RBAC is a widely used access control model that grants permissions based on a user’s assigned role. In RBAC, roles are defined based on job functions or responsibilities, and users are assigned to these roles. Permissions are then granted to roles, not individual users, making it easier to manage permissions and simplify access control.
- ABAC is a newer access control model that grants permissions based on attributes, such as user attributes, resource attributes, and environmental attributes. This allows for more granular access control, as permissions can be granted based on specific attributes of the user or resource.
- ACL is an access control model that grants permissions based on a list of authorized users or groups. In ACL, access control is defined for each resource, and a list of authorized users or groups is maintained for each resource. This model can be inflexible and difficult to manage, particularly in larger organizations.
- PBAC is an access control model that grants permissions based on a set of policies. In PBAC, policies define the conditions under which access is granted or denied. Policies can be based on attributes, roles, or other factors, and can be updated dynamically to reflect changes in the environment or user behavior.
- DAC is an access control model that grants permissions based on the discretion of the resource owner. In DAC, the resource owner has complete control over access to the resource, and can grant or deny access based on their own judgment. This model can be useful in situations where resource owners need complete control over access, but can be difficult to manage and scale.
In ZTA, RBAC and ABAC are the most commonly used access control models. RBAC is well-suited for managing large organizations with well-defined roles and responsibilities, while ABAC provides more granular access control and is better suited for dynamic environments with changing user and resource attributes. ACL and DAC are less commonly used in ZTA, due to their inflexibility and scalability limitations. PBAC is gaining in popularity in ZTA, as it provides a flexible and dynamic approach to access control.
One of the biggest benefits of ZTA is its ability to limit the potential impact of a breach. By enforcing the principle of least privilege access, the potential for lateral movement and privilege escalation is greatly reduced. Additionally, by assuming that a breach has already occurred or will occur, organizations can take a more proactive approach to security, enabling them to detect and respond to threats faster.
Another benefit of ZTA is its ability to provide a more granular approach to access control. In the traditional model, access controls are applied at the perimeter, with little consideration given to the resources inside the network. With ZTA, resources are divided into smaller segments, each with their own access control policies, providing a much more precise approach to access control.
Conclusion
Zero Trust Architecture is a security model that assumes that no user or device can be trusted by default, and that all requests for access must be authenticated and authorized before access is granted. The model is based on the principles of least privilege access, assuming breach, micro-segmentation, and continuous monitoring. While implementing ZTA requires a significant investment, the benefits of the framework outweigh the costs, and it is rapidly gaining adoption as a best practice in cybersecurity.
References
From monolithic to composable software with Bit
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
→ Micro-Frontends
→ Design System
→ Code-Sharing and reuse
→ Monorepo
Learn more:
- How We Build Micro Frontends
- How we Build a Component Design System
- How to reuse React components across your projects
- 5 Ways to Build a React Monorepo
- How to Create a Composable React App with Bit
Microservices and Zero Trust: A Match Made in Metaverse Heaven was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
