Cloud and SaaS applications encourage collaboration and sharing, but sometimes employees take that a step too far in sharing access by creating Google or Microsoft group accounts to shortcut managing shared access.
One of the most common solutions we see is using Google or Microsoft “groups” to manage shared access. The problem is, group settings weren’t designed for this purpose, and this way of using groups opens up multiple opportunities for insecure choices. Understandably, employees typically don’t understand the security implications of creating a SaaS admin account using a group email, and users don’t need administrative privileges in Google Workspace or Microsoft to create new groups and start using them this way.
Groups, aliases, dedicated users: what’s the difference?
Before we dig in further, let’s clear up some confusion about the difference between a Microsoft or Google Workspace group and similar-seeming alternatives. From a user’s perspective, it’s not obvious whether a generic email address like firstname.lastname@example.org is assigned to a group or why it would matter. Here’s a quick overview of those options:
While there isn’t a perfect choice for shared SaaS access, groups are the wrong choice
So, what’s the big deal with using groups to manage shared access? For starters, group members can view the group’s emails—including password reset communications from SaaS accounts created using that email address. In other words, anyone who joins the group can reset passwords for shared SaaS accounts. Groups also offer limited controls over who can add new users. Most importantly, the employees making decisions about signing up for SaaS accounts using groups may not understand the security implications of their choices.
Let’s take a look at some of the common ways organizations trip up when it comes to using groups to manage shared account access.
Issue 1: Using the wrong privacy settings
If your employees are using groups to create SaaS accounts with admin privileges, or to create shared SaaS accounts in general, it’s critical that you take a look at their privacy settings and make sure those groups have the appropriate level of access granted.
Microsoft offers two group privacy settings: public to your organization, or private. Public groups allow anyone in the organization to read all emails associated with a group, which means anyone can reset passwords for SaaS accounts created with that group. Private groups limit access to group members, but that control is tempered by the fact that any member of a private group can invite a new member.
Google Workspace offers more granular controls, with separate settings for who can join user groups, view group messages, or view members. Each of these can be enabled for your entire organization, only group members, only group managers, or only group owners. Depending on the global settings for your business, employees may also have the option to create groups that anyone on the internet can join and view.
If your organization has enabled the option to create public groups within the global settings for Groups for Business, any employee who creates a group can accidentally make it accessible to the entire internet.
Issue 2: Membership creep
The challenge of monitoring who’s a member of a particular group can be exacerbated by well-meaning colleagues with the ability to add users. While the intent behind a private group might be to keep membership tight, that’s not always easy to control.
For example, let’s say your DevOps team sets up a group to manage your organization’s AWS accounts, with membership limited to a few key employees. Later, an IT team member who doesn’t have context for why the group was created might make the reasonable assumption that any new DevOps employee should be added to the Devops group.
The result? The group’s membership extends far beyond its intended scope, giving too many employees the power to take actions like resetting critical passwords.
Issue 3: The weakest link problem
If your organization does decide to use groups to create SaaS accounts, particularly accounts with admin privileges, consider the security hygiene of your group members. The lowest common denominator establishes the group’s security.
If one user fails to enable multi-factor authentication or reuses passwords, their individual account could provide a stepping stone for bad actors to access any resource managed by the group, including any account with administrative privileges. You can reduce that risk by auditing your users’ security settings and making sure anyone with group access has the appropriate controls in place.
Monitoring group SaaS access with Nudge Security
Whether you’ve chosen to use groups for shared access or your users have chosen it on their own, monitoring what’s going on with your organization’s groups can prevent the most egregious misuses and misconfigurations. Nudge Security makes that easy by providing a clear overview of the groups at your organization as well as their privacy settings, their members, and their associated SaaS accounts.
Nudge Security helps you:
Inventory all groups and members in use at your organization
Discover what SaaS accounts that have been created using a group identity
Identify and monitor group members and their security settings, such as whether they have MFA enabled on their Google Workspace or Microsoft account
Assess group privacy settings and the risks posed to your organization
Be alerted whenever someone uses a group account to sign up for new SaaS accounts