The traditional approach to cybersecurity has been to impose 'perimeter-based' security. This is akin to building a castle - put up the walls, make a well guarded gate, and then trust everything inside the castle, and distrust everything outside. The gate guard (aka firewall or VPN) is responsible for ensuring that only trusted people can get in. But once you are in, you are in! The whole castle is open to you.
Including the king's treasury.
This seems somewhat insecure, does it not? Even though you may be inside the castle, you probably have no business going into some areas that others are allowed into. So then you have to start building 'castles within castles' and everything starts becoming more complicated. Enter Identity and Role based access control (RBAC).
RBAC means that "inside the network" no longer means "unconditionally trusted". Identity means that you have to prove who you are, and be assigned a role, before you can access anything. Just because you have the credentials to get through the gate doesn't mean you have full access. You only have access to things that you are supposed to have access to. Identity becomes the new perimeter.
RBAC enforces least privilege by design - users are only allowed to access what their role allows - which dramatically shrinks the "blast radius" of a compromised set of user credentials. RBAC particularly helps with the messy real-world case where users tend to accumulate access over time, something referred to as "permission creep". If permissions are attached to users (for example, "account 'John' can access these shares on the server and those RDP sessions and these applications") then over time, as the user changes roles ("John went from working in the accounting department to working in HR") these permissions accumulate, because they are rarely audited and removed. However, if permissions are attached to roles ("John was in the accounting role and had access to accounting things, but now John has moved to a HR role, and has gained access to HR things but lost access to accounting things"), then permission creep is largely eliminated. This is a huge improvement in terms of limiting lateral damage from compromised accounts. Further, role permissions can be audited, because there are very few roles relative to the number of users.
RBAC is also very handy when it comes to the dreaded compliance audits. Most compliance standards - HIPAA, SOC 2, CMMC - want to see employees with roles, and least-privilege access for each role. Implementing RBAC is the easiest way of satisfying a compliance auditor. In addition, RBAC coupled with strong identity reduces the chance that employees can 'leak' credentials to each other. A leaked set of credentials is not particularly useful if the employee is not assigned that role.
Uplevel ZTNA is the first step in moving away from traditional 'perimeter-based' VPNs to a 'role-based' remote access model. You can set up roles as groups, and then attach policies to each group. You can also further strengthen security by attaching posture checks to the groups (e.g., "everybody who is accessing the accounting server needs to be running the MSP-mandated AV software"), and even further by attaching location checks ("all of our people are in Kansas, so the accounting server cannot be accessed by anybody outside Kansas"). Once the groups and policies are created, the RBAC component of the ZTNA platform will control access to designated resources - servers, applications - by role, not by user. Simply move a user into a group to assign them the role; move the user out of the group and they no longer have the privileges that go with the role. Simple. And a strong IdP integrated with the ZTNA system ensures that you can confidently establish who is on the other end, ensuring that a leaked set of credentials doesn't wind up allowing someone in North Korea to get into the accounting server.
Over the next few months, Uplevel will be extending the notion of RBAC and strong identity to other parts of the platform. Stay tuned for more updates!
