At the core of every environment that is designed to make people productive is the need “under the hood” to be able to establish what users of that environment can do, what they can access, and – in many cases, how they can easily communicate with other users. The long-standing methodology (with a few exceptions and variants) has been the use of groups objects within that environment’s directory service.
The use of a group has been around for decades, allowing those in charge of an application, platform, operating system, or environment, the ability to cluster sets of users together to assign permissions, privileges, and restrictions, as well as to facilitate a simplified means by which to email that set of users. We’ve seen this forever in the on-prem world, and continue to see it in the cloud.
Now, nobody knows groups better than we do. So, we thought we’d take a few blogs and look at how several of today’s most popular cloud-based application environments utilize and manage groups, and how you can best ensure a secure and accurate directory. So, in this first blog in a three-part series, we’re going to take a look specifically at Google’s Google Workspace, discussing what kind of configuration and management is possible, and where it’s lacking.
Managing Groups in Google Workspace
Let’s begin by defining Google Workspace’s specific purposes for groups:
- Assign permissions to resources and applications
- Deliver messages to multiple users simultaneously
- To be used as forums or collaborative inboxes
Beyond the traditional use of groups (where IT creates a group, adds users, and gives it access to a resource, the management of groups in Google Workspace also includes features such as:
- View membership
- Invite users to join
It’s all pretty powerful and user productivity-centric stuff, but it does have some downsides.
- It needs a source directory or system of record – Even Google realizes you probably already have an on-prem directory that you wish to duplicate in Google Workspace. They use Google Cloud Directory Sync to sync the directory data in your on-prem directory, your HR database, etc. – anything that’s LDAP-based will do – with your instance of Google Workspace. One of the downsides of this method is that Google Workspace is only as good as your source directory. If your IT organization is like most, your source Directory isn’t up to date, which means, neither will Google Workspace be.
- It requires separate management of groups – while the sync will create identical users, contacts, groups, and more, the configuration of the Google Workspace groups is still unique to Google Workspace and requires a second, manual step to ensure the right permissions, privileges, etc. are applied.
- There’s no Group Lifecycle Management – Google Workspace has some very cool capabilities around delegating responsibility to users to self-manage groups. But, one of the dangers of delegation is the loss of control from a security standpoint. What’s needed is a way to centralize the ownership, and continual attestation that the groups are configured correctly (and securely) and are still necessary to the organization – in short, implement group lifecycle management.
Google Groups – Pretty “Suite”
The Google Workspace contains a lot of functionality that empowers users and teams to create, collaborate, and communicate effectively and efficiently. But like any other set of resources, IT needs to be concerned that security is as high a priority as productivity. In the case of Google Workspace, the focus is heavy on productivity, and light on security – sure, they have some security granularity built-in, but the lack of lifecycle-focused group management means it will inevitably become a group mess in the cloud.
To learn more about how you can automate the centralized synchronization, configuration, delegation, and management of groups on-prem, in Google Workspace and other cloud applications, Contact Us for a Free Demo