Defining Role-Based Access Controls for Higher Education Institutions
Once someone starts to gain trust, however they do so, how do institutions use that trust in applying security policy?
The answer is that colleges and universities usually express policy as a set of access controls. For example, they might say that a specific user can connect to the finance application but can’t connect to the HR application.
That’s a fairly high-level statement, though, and how these access controls are enforced from campus to campus may be quite different. For example, the network might enforce certain controls that prevent the user from sending packets to an application they don’t have access to. A front-end device ahead of the application servers, such as a proxy firewall or SSL/TLS encryption accelerator, might do the enforcement. Or, the application itself might handle the access controls. Or, it could be some combination of all of these.
There’s no question that things can get complicated very quickly. This is especially true in heterogeneous environments, such as higher education networks, in which some applications might be firmly stuck in the past, some might be completely up to date, and the network and security infrastructure might be a mix of old and new.
Role-based access control provides a way to simplify the potential chaos that comes from a campuswide zero-trust design. With RBAC, rather than allowing access to specific users, access is granted based on the user’s role. For example, in the case of the user who should be allowed access to finance data but not HR, RBAC might create a role called “Finance People” for those who can access the finance application. Assigning that role to specific users grants access to the finance application but not the HR application, which is assigned to a different role.
LEARN MORE: What universities should know about continuous authentication
Why Should Colleges and Universities Use RBAC?
RBAC makes security management possible because when a user moves on from a finance job to something else, managing the change in security profile just means reviewing the roles available to that user. Otherwise, you’d need to find every instance in which a user might be mentioned in an access control list in every network device, VPN server, firewall, application and database system.
This example is fairly basic, but with zero trust, the concept of a role within RBAC may extend in many directions. For example, it may not be sufficient to have the role “Finance People” to get to the finance application. Networks might also require a “Trusted Device” role, meaning that the device being used has been entered into the campus mobile device management or enterprise mobility management system.
In effect, zero trust requires that you have no access until you establish trust, and RBAC is used to define what access you have once you start to establish trust through authentication and other real-time checks.
Managing role-based access controls is part of an identity and access management system. Whether that’s homegrown on campus or a commercial product, IAM tools bring user identities, authentication, roles and attributes — as well as some access control rules — into a single management system and API for applications and network devices.
Higher education network managers may never find a single one-size-fits-all solution to complicated campus security policies and application environments, but the state-of-the-art has shifted dramatically the past few years. IAM tools and RBAC, combined with strong design and modern application capabilities, make a zero-trust network architecture a solid base for improving security and simplifying identity management.