In the last blog, we touched briefly on group-based permissions as a means of simplifying the management of user access. Groups make it easier to assign permissions to multiple users at once, reducing the administrative burden and shortening delays on getting appropriate levels of access. Traditional identity governance and administration (IGA) solutions have been pivotal in managing roles and groups across various systems within organizations.
However, as organizations expand and modernize their cloud footprint, the limitations of traditional IGA solutions and utilizing groups for permissions become increasingly apparent. This blog post explores why traditional approaches have fallen short in meeting the needs of modern, flexible cloud environments.
Misusing Groups for Permissions Management
Previously, we went over the definition of identities, roles, and groups. Groups can be treated in one of two ways: as a collection of users who share common attributes or as a collection of permissions and/or roles.
When groups are used as collections of permissions rather than users—especially if the collections contain roles or even other groups—they create a layer of abstraction that obscures the actual permissions that are granted to users. This usually happens for the sake of operational efficiency.
For example, when a new employee joins the engineering team, there are likely a set of permissions that they receive automatically: access to development environments, GitHub, Jira, and other tools. As they work and continue to accumulate additional roles and responsibilities, it’s easier to assign them the necessary permissions by assigning them to existing groups. In a typical IGA tool, there might be groups with names like “Junior Engineering”, “Senior Engineer”, “Engineering Lead”, “Architect”, and so on. If all these groups are sets of roles and other groups, the permission difference when moving someone who was just promoted from the Junior to Senior Engineering into their new group is opaque.
This loss of visibility makes it difficult to enforce the principle of least privileged access. Over time, groups are prone to becoming bloated with unnecessary permissions. This standing, over-provisioned access across all group members presents and increased security risk in the event of an account breach.
IGA Workflow: Requesting, Approving, and Managing Roles & Permissions
The typical workflow for requesting access in an IGA solution starts with a user logging into the system and viewing their identity catalog, which displays the roles they have access to or the groups that they’re part of.
Looking through a catalog of hundreds, if not thousands of potential permissions is time-consuming. It’s much easier to see that, for example, one of your marketing team members has access to the tool you need to use so you simply request permissions similar to theirs.
This is where teams can fall into the quicksand of using groups as a collection of permissions, rather than a set of identities with similar attributes. Once an admin receives your request for access to a marketing tool, it’s faster and easier to simply add you to an existing group that has the right permissions for that tool—especially if the alternative is to login to that tool and manually configure your permissions. Depending on the volume of requests, the number of tools that need to be managed, and the complexity of configuration, there could be significant delays.
Faced with the alternative of manual configuration, groups of permissions can simplify and speed up the access request and approval workflows. But groups used this way also speed up the accumulation of unnecessary permissions. This is especially true if there is not sufficient visibility into precisely what permissions are associated with each group. The tradeoff of speed and convenience here is at the expense of security and visibility.
Security and Usability Impacts of Groups
One of the issues with using a traditional IGA solution to manage permissions via groups is that approved roles and permissions are often assigned and attached statically and permanently, leading to bloated permissions and privilege sprawl.
A user with accumulated, unnecessary permission sets granted via groups also presents a large security risk, providing potential attackers with more entry points and opportunities for lateral movement through the environment.
Managing and certifying group-based permissions also becomes cumbersome during audits and other regulatory activities. Administrators must review and certify permissions associated with users throughout the environment, which is difficult to do when groups add a layer of abstraction and opacity over who has access to which resources. Conflating groups with access management also further muddies segregation of duty (SOD) policies. This is further exacerbated as users are associated with more groups and those groups accumulate permissions and roles for tools and environments unrelated to their work.
While group-based permissions and traditional IGA solutions have played significant roles in user access management, these limitations become evident in the modern cloud landscape with the added dimension of environment levels and their respective permissions. With many traditional software tools, defined roles provide access to the same environment across all users.
This is a 1-dimensional access problem. In many cloud environments, you must consider not only the level of access but the segment of data or infrastructure to which that access applies. For example, you may allow a role to have read and write access to a non-production cloud environment but restrict it to read only for the production environment. This makes it a 2-dimensional access problem as one must consider permissions and environment scope.
Traditional IGA tools are not designed to handle this 2-dimensional access management situation. Organizations need to adopt dynamic, flexible, and granular approaches to access management to better adapt to the rapidly changing nature of cloud environments.
Moving beyond the limitations of group-based permissions will allow teams to enhance their security posture and maintain compliance while continuing to streamline operations. In our next post in this series, we will explore how just-in-time (JIT) access and adopting a zero standing privileges (ZSP) approach addresses many of the limitations of IGA and traditional access management tools.
Looking for a solution that can handle granular access across your entire cloud environment? Learn more about Britive’s CPAM platform or reach out to chat with a member of our team for an in-depth demo.
