Governing Third-Party Access to Google Drive

Disclaimer: The Google Drive API may require additional constraints to authorise the application to your company’s Google Drive. If this applies to you it will prevent you from using the tool demonstrated below. If you find any issues, related to the authorisation flow, please raise an issue at https://github.com/matamorphosis/GDrive-Access-Governance/issues.

Background

Ever heard of governing access? If not, then maybe the following will resonate with you.

Just under 4 years ago, I was only a holiday with my extended family, when we realised we were out some essential dinner ingredients. My brother in-law, who runs a small business (SMB), and I hopped in the car and headed for the shops. During the drive he began describing a security pain-point he was having, controlling access to sensitive information in his company’s Google Drive. He explained that since starting his company 6 years earlier, he didn’t have an easy way of removing access to files he had shared with former interns, contractors, and clients.

Employees who had left the company, had their access managed through their company Google account, where they would lose access as part of their Google account being deactivated. However, this didn’t extend to the others, who would need temporary access. When dealing with thousands of files, it’s difficult for anyone to remember what files have been shared with who. It’s too complex to track manually, and Google doesn’t provide an easier way of handling this.

Since this conversation I’ve met people from at least 5 other businesses who have this exact same problem. I now understand it as an extensive issue that impacts many SMBs to this day.

Overview and Definitions

Before we delve deeper, let’s revisit some common Identity and Access Management terminology:

Worker: Someone who provides work to an organisation (employees, interns, and contractors)
Leaver: Someone who leaves an organisation (applies to all workers)
Mover: Someone who changes roles in the same organisation, or a workers that changes their their worker relationship with the company (i.e. contractor -> employee)
Joiner: Someone who joins an organisation (applies to all workers)
Mandatory Access Control (MAC): Providing only the specific permissions required to perform a particular task.
Role-Based Access Control (RBAC): Providing access based on a user’s role in the organisation. (i.e. The HR team has access to HR systems)
Discretionary Access Control (DAC): A designated owner provides user access, and determines level of access to a resource.
Access Management: The process of managing the access, and levels of access a worker has to a resource.
Access Governance: The process of monitoring and controlling who within your organization has access to what, when and how.

If you were bothered to read those definitions, understand them, and apply them to the problem, then you would know that the problem pertains to short-term

Leavers who have been given access to files in Google Drive using
Discretionary Access Control (DAC) where Google Drive fails to provide a simple way of performing
Access Governance against the organisations shared Google Drive files.

In general Discretionary Access Control is the hardest to govern. Due to the vast and complex nature of having a large volume of owners in an organisation, who can govern access how they like. It also increases the risk of the owner managing and governing access in a secure fashion.

Governing Access in Google Drive

As an automation enthusiast, there’s nothing I enjoy more than building tools to address complex, and sometimes niche security issues. I did do some research on tools to address this issue, but they were mostly paid-products. While I’m sure it’s possible to integrate a fully-fledged IAM system with Google Drive, keep in mind we’re talking about an SMB problem. Many SMBs lack the budget for one of these systems.

One SMB I know that has this issue, reduces their risk of not governing access properly, by only sharing files that exist in a designated shared directory, and perform a monthly, manual audit against that directory. So if you want to do nothing more than take some good advice. I do have to say that is a simple trick to help manage this problem. However, this isn’t exactly a solution, it’s optimistic to assume that no one will ever share a file outside of the shared directory. You still have to audit the shared directory, which is long and mundane by hand. Manual tasks cause fatigue over time, which is a human vulnerability which is often exploited by malicious actors. This is why governing access is critical, and while access governance tools are critical for success.

After hearing the problem statement, it became clear that I could built a tool, that would automatically detect all files in Google Drive, giving visibility into who has access to what. I decided to research Google APIs for Google Drive, and sure enough there is a freely-available API which I was able to use. This started out as a script, but has now moved into more of a web platform.

If you want to jump straight to it, you can find the project at https://github.com/matamorphosis/GDrive-Access-Governance.

Please only continue if you would like to learn how to set up and use this platform. The rest of this post is fairly technical.

Setting Up the Platform

Note: While Endure Secure doesn’t want to discourage anyone from standing this platform up themselves, it does require a decent level of technical knowledge. Please don’t hesitate to contact us if you need support setting this up. You can find lots of information by following the link above.

To run Google Drive Access Governance, you will need Docker installed on your local machine.

Next start docker and download the docker-compose.yml file to your laptop (contents below)

version: "1.0"
services:
  gdag:
    image: ghcr.io/matamorphosis/gdag-appliance:latest
    container_name: gdag
    ports:
    - "443:443"
    networks:
      vpcbr:
        ipv4_address: 10.0.0.6

  auth-flow:
    image: ghcr.io/matamorphosis/gdag-auth-flow:latest
    container_name: auth-flow
    ports:
    - "81:81"
    networks:
      vpcbr:
        ipv4_address: 10.0.0.7

networks:
  vpcbr:
    driver: bridge
    ipam:
     config:
       - subnet: 10.0.0.0/16
         gateway: 10.0.0.1

gdag-appliance: This image is the main image that runs the GDAG platform.
gdag-auth-flow: This image stands up a server that handles the authorisation flow, needed to give gdag-appliance access to manage your Google Drive.

Open a terminal in the same directory as the docker-compose.yml file, and bring the cluster up. This will attach your terminal to both the gdag-appliance and gdag-auth-flow docker containers.

You will notice every 10 seconds a GET request is made to the gdag-appliance, this is the gdag-auth-flow polling for the credentials.json which you will upload in an upcoming step. Please ignore these requests.

Navigate to the docker IP on your host (almost always you can use localhost), on port 443

You will arrive on the upload page of the GDAG appliance. You will not be able to use the appliance until you upload a credentials.json file to the appliance. To obtain OAuth 2.0 credentials, which you can download to this file, please follow the instructions at https://developers.google.com/drive/api/quickstart/python, you will need to Enable the Google Drive API also, which is linked to the same document.

After uploading the credentials.json file successfully, you will be able to access the rest of the web application; however, you won’t be able to perform any tasks just yet. Please check your docker-compose logs, and you should see a URL similar to the following

Open the URL in your browser. Google presents this warning for a few different reasons, but in this case most likely due to the data the tool needs to access, and the rights it needs to your data. For more information on this, please refer to the GCP support article on unverified apps here. Because the app is bound to credentials supplied by the user, it is the user’s responsibility to obtain verification for the app. For further questions on this, please get in contact with us. If you are a developer, you can see the particular scopes being requested by the app here.

If you are happy to continue, accept that this is an unverified app to continue, shown below.

After clicking “Continue” you should see a message telling you that the authentication flow has completed. Your application is now able to manage your Google Drive.

The gdag-auth-flow container will exit at this point, and is no longer required. So don’t worry if you see that it’s gone down after these above steps. The below demos, show how to use the platform.

Demo – Governing Access to a Shared File for a non-Gmail Domain

A very common way to audit for external access, is to search for all domains that are not yours. For example Endure Secure may want to search for all files that are shared with anyone who’s email address does not end with “endsec.au”. This demo shows this concept; however, “gmail.com” is the allowed domain in this demo.

I’m creating a new folder in Google Drive called “Shared”, sharing it with a “hotmail.com” email address, and then creating a new file within called “Test Document”:

In Google Drive Access Governance, click “DOMAIN TASKS” in the banner at the top, then click “Create New Domain Task”

You will see a form appear called “Create Domain Task”.

This form has several fields, explained below:

Field Number	Label	Description
1	Task Name	Whatever you would like to call your task
2	Box #1 – For Domains	A box to supply a list of domains.
3	Do you want the supplied domains flagged if found or other domains?	Flag whatever domains you are concerned about, either: 1. Domains not in Box #1 2. The domains in Box #1
4	Auto-Certify Access for Flagged Users?	Automatically certify the access of any identified users.
5	Auto-Revoke Access for Flagged Users?	Automatically revoke the access of any identified users.
6	Box #2 – For Directories	A box to supply a list of directories.
7	Should the search be confined to the directories supplied or avoid searching within them?	Either run the search so that: 1. The search is limited to the supplied directories. 2. The search is excludes the supplied directories.

In this case we’re going to enter “gmail.com” in Box #1 and instruct the task to flag email address belonging to other domains. We don’t want to automatically certify or revoke results, and so we will leave both checkboxes unchecked. As in this demo, I am just looking at the Shared directory, I will enter the name Shared in Box #2, and finally limit the search to that directory. This is very similar to what companies who confine shared documents to a single folder would want to do for their audit.

Next we’ll click run to execute the task. This will execute a background task. Task runtime varies in length, but after some time, results will start appearing. This can be monitored by refreshing the OPEN RESULTS page from time-to-time. A task confined to specific directory will always be faster than a full audit of Google Drive. In the below screenshot we can see that the platform has identified the hotmail.com account we previously shared the “Test Document” file with.

In this case only one email was identified for this file, but for multiple emails, they will appear as comma-separated values in the row in the table. To review each one, select “Review Access”.

Now we are going to revoke access, select the checkbox to the left of the line item with the email account we want to revoke shared access from, and click “Revoke”

A pop-up confirming the revocation will appear. Click “OK” to proceed.

The page will refresh, and the result will have disappeared, with multiple emails, if only some emails are revoked, they will be removed from the record, but the record will still exist.

Going back to the file in Google Drive, it is evident that the file is no longer shared.

Support

If you need support for governing access in general, using Google Drive Access Governance, or any of our other open-source projects advertised on our GitHub or the Products page on our website, please get in touch with us using the Contact form on out website.

If you like the work we’re doing or are finding your organisation benefitting from the open-source projects managed by Endure Secure, why not consider sponsoring our ability to give back to the global open-source community? Sponsorship enables us to better prioritise the maintenance and innovation of our open-source projects. Most sponsorship tiers receive free support hours as reward for their generosity.

Share this content:

Governing Third-Party Access to Google Drive