Role-based access control allows network managers to personalize a user's access level based on the individual's role within the organization. Rule-based systems, on the other hand, grant access to individuals complying with a specific set of conditions. By establishing a pre-defined rule-based access control setting, an administrator might, for example, grant a person or team access to a specific network resource only during regular business day hours.
Rule-based access control, frequently abbreviated as RuBAC, is often described as an attribute-based control, since end users are given a specific level of system access based on pre-determined criteria, regardless of their role or position within the organization, explains Joe Dowling, Dell Technologies' vice president of cybersecurity, identity, and access management.
RuBAC can be used in a variety of scenarios other than network access control, such as file and directory access control, and application access control, says Alaa Negeda, senior solution architect and CTO at telecommunication service provider AlxTel. “It can also be used in conjunction with other security measures, such as firewalls, intrusion detection systems, and passwords.”
RuBAC settings are typically defined by how much control each user is granted to accommodate their specific role within the organization. “The ability to control access is based on discrete criteria, conditions, or constraints,” says Alexander Marquardt, global head of identity and access management for analytics software provider SAS. “It’s explicit and very granular, focusing on a single attribute or characteristic of a subject, object, or operating environment.”
Jay Silberkleit, CIO at freight and logistics services provider XPO, believes that RuBAC is the best choice for organizations looking for a network access method that offers maximum customization and flexibility.“Rules can be changed quickly without changing the overall definition of the organizational structure,” he notes.
Benefits of RuBAC
RuBAC's central benefit is granularity and clarity, Marquardt observes. “There's no ambiguity when looking at a rule, as it explicitly allows or disallows access to a particular object or execution of a specific operation.”
The lure of increased control and flexibility also draws many organizations to RuBAC. Rule-based access control is an ideal model for any enterprise that requires explicit rules that are relatively static, Marquardt says.
RuBAC also gives adopters virtually infinite user access flexibility with only a minimal amount of overhead. “A small set of rules can be adjusted to enable functionality for a large user base,” Silberkleit explains. The approach also allows multiple network access levels to be rolled out to a subset of users for testing or experimentation. “Having this fine-grained control over access helps keep companies agile and secure,” he states.
Drawbacks and Challenges
RuBAC's biggest drawback is the level of oversight and management needed to establish, configure, set up, and test rules. Adopters also face the task of ensuring that permissions remain accurate and reliable as users' duties evolve over time. “Organizations must start with a clear strategy for set up and management,” Dell’s Dowling warns.
Marquardt notes that many adopters also face the burden of writing single-subject or single-object exceptions for a broadly applied rule, and then having to keep track of those exceptions and correctly report effective rights and permissions.
For W. Curtis Preston, chief technical evangelist at Druva, RuBAC's key disadvantage is its tedious setup process and ongoing maintenance duties, particularly if multi-factor authentication (MFA) is involved. “However, based on what we know about cyberattacks and breaches today, it's a small price to pay for your organization's peace of mind and keeping your data protected,” he says.
Customizing RuBAC rules can be challenging, Negeda acknowledges. “For example, you may need to specify the exact permissions that a certain role requires, or you may need to specify the username or group name associated with a certain role,” he explains.
RuBAC can also be difficult to scale, Negeda observes. “If you have a large number of resources, it can be difficult to create and maintain rules for each of them,” he says. “Additionally, it can be difficult to determine which users or groups should have access to which resources.”
There are many different ways to deploy RuBAC. “The most popular approach is to use a database to store the rules,” Negeda says. “Once the rules are created, they can be easily added to or updated by administrators.”
To minimize confusion and disruption, Dowling suggests that organizations considering a transition to RuBAC begin by analyzing their ongoing business requirements and existing network access classification system to determine if rule- or role-based access is the best model to use. “If rule-based access control is the right decision for your organization, extensive interviews should be completed with the business owners of the system to find the least complex ruleset to follow,” he advises.