What if Google’s Shared Drive was actually a “Shared Drive”?
With a growing company comes many challenges. Creating a secure company shared drive is one of the more fundamental recent struggles I have had to solve. Let alone do it with a 100% remote workforce.
I'm sure many of you out there have used or currently use Google Drive but I would wager that not nearly as many have tried to use the Shared Drive feature in Google Workspace. Let me just say, they ARE NOT the same!
This all started as an idea I had on how I would set up a shared folder in Drive to be shared across the entire company with each department's folders within them that incorporate the respective team's documents as well. This all would then be controlled by a Role-Based Access Control (RBAC) model that would allow access to each of these folders.
Pretty awesome right? When thinking about how I would implement this I figured it wouldn’t be too difficult as you can already set and manage nested permissions for sub-folders in Drive the only thing I would have to solve is who owns the top-level folder. In comes Google Workspace Shared Drive.
Google Workspace Shared Drive
What is a Shared Drive you may ask? You can find that here but let me paraphrase for you in Google's words. “Your organization owns the files in a shared drive, not an individual. When an employee leaves and an admin deletes their account, their files remain in shared drives.”
This sounds excellent, exactly what I’m looking for, but wait. The next line says “Improved sharing rules: All members of a shared drive see the same content.” How is that “Improved”? That sounds to me like a downgrade in security and the ability to restrict access.
After some digging, I found that if you wanted a Shared Drive to show up for an employee in their drive it is required that you add a user to the top-level shared drive.
In this image, to have the SoundCommerce shared drive appear in My Drive, I had to be added as a member of the SoundCommerce Shared Drive. Here’s the thing about adding members to the top-level though, when you do that, those members are all given the same level of permissions to every sub-folder in that share.
This means that you can only use a Shared Drive for one topic and not many as restricting access was not possible, or so I thought.
I knew there had to be a way to do what I was trying to do so I kept digging, upon reaching out to Google Support, they told me that what I wanted to do was not possible in the Shared Drive as it is a different tool than the consumer version of Drive and therefore designed with different priorities in mind. I was instructed to set up individual drives for each team but that did not solve my problem of wanting to have all documents in one location that employees can request access to like how traditional network shares operate. However, they did mention I might look into making shortcuts to other drives. The idea of shortcuts fell on deaf ears at the time as I didn't quite understand the process they were talking about and instead opted to write up a feature request to have the functionality I was looking for added to the Workspace Shared Drive offering.
A day passed and I still couldn't shake the feeling that I missed something and there is a way to do exactly what I need. While continuing my research I came across someone else talking about shortcuts. Still unsure what a shortcut is in this context and how to make them, I started looking into how to create a Google Drive Shortcut and like a ton of bricks, the answer was right there.
How This All Works
In the Shared Drive offering, you can add shortcuts of sub-folders to other shared drives, and people who are members of the Share Drive you are adding those shortcuts to will see the shortcuts as if they were sub-folders they do not have permissions to see into without having explicitly been added as members to those folders in their actual location.
To the left, I have a test user that is added as a member of the SoundCommerce Shared Drive that then has the sub-folders of a Departments Shared Drive shortcuts placed it. As you can see the only sub-folder I have access to is the IT folder as that's the only folder that I added my test user to in the Departments Shared Drive. This works due to a Shared Drive permission that allows people to be added to sub-folders that are not members of that Shared Drive.
I'm sure this is all a bit confusing. It took me a couple of hours of staring at the screen to fully grasp what’s happening here. Please bear with me while I explain exactly what I did to make this work.
As we know that the contents of each shared drive is visible by everyone who is a member of that drive, I had to think of a way that I can use shortcuts and clever sharing of sub-folders to ensure that I would be able to still restrict access on the basis of RBAC. Here is what I can up with:
Each vertical is a new Shared Drive but only the top-level (far left) actually have members added to it. This ensures that ONLY the SoundCommerce shared drive will be visible to our employees. The next step is to create a shared drive for departments with a sub-folder for each department and another for the teams within each department.
NOTE: All sub-level shared drives need to have the following permissions to allow this to work.
After you have the bones of your structure set up the last thing to do is to create your folder shortcuts and place them in the appropriate folder one level up. You can see what I mean here by looking at the diagram above and following the purple lines.
In comes the RBAC
In order to have this all functional, we need to have a permission structure that allows for nested permissions. If we were to just add everyone individually this would only get increasingly more and more complicated and impossible to audit as teams and the company grow.
This is where we will utilize the principles of RBAC to set up a nested group structure that will have a security group structure for each tier in the organization. This will consist of Department Groups (DGs), Team Groups (TGs), and Role Groups (RGs). This concept can be expanded to include any number of these groups as the implementation is exactly the same but they may consist of a couple more tiers.
Membership would be assigned from a bottom-up approach where a Role Group would be a member of a Team Group, that Team Group would then be a member of a Department Group, and if needed the Department Group would be a member of an Organization Group (OG).
Example:
Department Group → Team Group → Role Group
Information Technology → Information Security → Security Analyst
After you have all your groups for each tier created, you have to nest them into each other. When all is said and done you will want to add each of the respective Department Groups, or if you created Organization Groups as members of the top-level share, each Department Group to the respective department folders, and so on and so forth.
To provision access for a new or existing employee to a team, all you need to do is add that employee to the appropriate Role Group for their position which will give them access to all the above groups in the hierarchy.
Google Shared Drive as a Shared Drive!
And there you have it, a working “network” share built within Google Workspace’s Shared Drive offering!
I hope this helps you manage and organize your group's shared documents more efficiently and more securely!