Today, many of us set up user groups at our organizations via role-based access controls (RBAC). Also known as group-based access control, granting access to collections of employees working within a common department or on a shared project saves time and helps the right people gain access to the right resources. 

However, we often see companies creating more and more groups as they grow and add on more systems, projects, and organizational structures, often through their identity providers (IdP). With all of this rapid growth, the situation can quickly get out of hand and result in overprovisioning which introduces unnecessary risk. By default, most IdPs have relatively lenient group-based access controls out of the box. For example, a single user can access up to 100 groups within Okta. Because there aren’t any built-in workflows for deleting or limiting user access to groups over time, they can pose major security risks, such as an increased likelihood of breaches and the potential for a larger blast radius in the case of a successful breach. In addition, overprovisioning goes against many common compliance frameworks. 

While many teams are aware of these risks with group-based access control, they often struggle to pinpoint where to begin mitigating them. The scale of the problem can feel intimidating, as they must deal with a constantly growing number of groups. On top of the sheer scale of the issue, many teams also hesitate to take action since incorrectly limiting access could disrupt an employee's workflow and slow down the business.

As you look to address these issues within your own organization and balance productivity with security, it’s essential to set a foundation for groups that shrinks the group attack surface and cuts back on overprovisioning — all while still enabling colleagues to benefit from user groups and keep access to the resources they actually need. 

Why group-based access control management matters

First off, why should today’s organizations focus on better group management? There are a few reasons why unmanaged groups are a common issue and source of risk within today’s businesses, which we’ll explore below.

Group proliferation is inevitable, and needs a continuous solution.

As the typical business grows, the number of groups within the company’s identity provider (IdP) also tends to increase. One-off projects begin and end. Departments change in size and functionality. External tools are added to the organization’s ecosystem, and access to resources is granted. And as all of these changes happen, legacy group structures tend to stick around. For example:

• Project-based groups often persist after the project comes to a close.

• “Birthright” groups are commonly created to cover broad organizational functions but aren’t revised if/when the organizational structure changes.

• Teams create groups to facilitate automated tool integration but don’t delete these automation-purposed groups when the tool is no longer needed. 

As these groups grow, it’s crucial to keep up, or else bring unmanaged, identity-related risk into the organization.

Overprovisioning increases security exposure. 

If a given employee has unnecessary access to several company resources, their account could pose a greater risk if compromised. A single compromise could lead to a larger blast radius, including increased access to critical infrastructure and assets and the potential for lateral movement. These identity-related security risks are commonly exploited by attackers, with a recent report uncovering that 90% of organizations experienced an identity-related incident in the past year.

The more groups, the more work for compliance teams.

Another significant challenge caused by group proliferation is increased work for compliance teams. If groups continue to grow and spread but IT and compliance teams stay the same size, the burden for these teams dramatically increases with each passing year. 

Often, organizations don’t consider legibility when creating new groups, making it challenging for compliance teams to understand each group’s purpose. As a result, they can’t make well-informed decisions on which members and access permissions these mystery groups should actually have.

4 best practices for group-based access control

Luckily, today’s teams can take a few actionable next steps to improve the situation. Here are some places for them to get started:

Look at groups as a data structure rather than an ad-hoc access tool.

As you work to manage groups better, start by making a mindset shift. While it’s simple to add to an existing group or create a new one as needed, creating or expanding a group ad-hoc ultimately defeats the whole purpose of a directory-style hierarchy. Instead, start viewing groups as part of an interconnected data structure. An employee shouldn’t just get added to a particular group because they happen to require access to two of the six resources attached to the group and it’s easier to add them to the group “just in case” they need access to the other four resources. In addition, teams shouldn’t just create a group because multiple employees happen to request access to the same resources around the same time. Instead, focus on the strategic reasons for each group's existence, purpose, and relationship to other groups, then add employees based on these reasons.

Implement clear, human-readable naming conventions for groups. 

Naming groups in a way that clearly outlines their purpose and scope is also crucial. This way, when your organization’s IT or compliance teams look at the group down the road, they can understand precisely why it was created and how it can be refined to reduce risk (e.g., do user permissions need to be revised, does the group need to be deleted altogether, etc.). In addition, readable naming conventions enable users to request access to the right groups, making it far easier for them to adapt to new roles, departmental changes, etc.

Use time-bound access for both user-to-group and group-to-resource relationships.

Access to groups through your IdP should be temporary by default and then renewed over time as appropriate. By setting up these “use it or lose it” parameters, you can better ensure that users only get access to the resources they actively need. It’s also essential to think about group-to-resource relationships in this context. Does a particular group need permanent access to a given resource, or should they just leverage it for a one-off task and be granted time-bound access instead? 

Regularly identify and clean up unused or redundant groups, starting with the most business-critical or high-risk ones.

It’s also essential to monitor the groups within your organization and either delete or reduce the number of users within unused or redundant groups. However, this can be a huge ask for a team dealing with hundreds to thousands of groups. In these cases, start by analyzing the groups directly connected with their most sensitive systems and assets and work outward from there. 

‍

How Opal can automate group-based access control 

While all of these best practices sound great in theory, some teams face organizational resistance and practical challenges as they try to implement them. Why? Mainly because it’s challenging to identify which groups are actively serving a purpose, what their access controls look like (e.g., which groups have time-bound access and which do not?) and which groups and resources are actually being used by employees. Teams often end up interviewing individual users in an attempt to find answers. But in many cases, users ignore the team’s inquiries, as they want to hold onto access needs “just in case” they need them again someday. 

In addition, organizations in growth mode tend to change so quickly that it can be tough to manually keep up with the various system and user changes related to groups. Older organizations often have extremely complex and interconnected group structures, causing unintentional domino effects upstream, downstream, or laterally if a single change is made to a given group. For instance, removing membership to one group could cause a loss of access to crucial resources located a few levels down in nested groups. As another example, external HR/productivity automations that were built around groups will potentially break if the group membership or attributes are changed.

Opal was purpose-built for teams that face these specific issues. Our identity security platform offers powerful automations for managing group-based access control without overcorrecting, such as the option for temporary project-based groups. The platform enables customers to identify groups that are overprovisioned, prioritize that access risk against other findings to enable focus, and remediate the issue quickly to optimize group access securely..

Our platform’s functionality works for teams of all sizes. Enterprises can leverage these features to target and prioritize their group cleanup efforts, while smaller teams can kick off Opal-supported automation to clean up their entire environment.

Learn more about how Opal helps with a free Okta group security audit.