Securing Google Workspace — A Guide

Mike Sheward
18 min readNov 13, 2023

--

Google Workspace has become the de-facto collaboration suite of choice for many a startup, and for good reason. It’s easy to get started. You can scale up your users and features as you grow. It has a more user friendly interface than some of its competitors, especially for those who didn’t grow up around the world of Microsoft Exchange or Active Directory.

It also has a bunch of really good security features — however, a lot of them aren’t enabled by default — so it is our responsibility to enable them. In this guide, I’ll walk through my recommended Google Workspace settings for each of the ‘apps’ within the whole platform.

Note: some of these features are only unlocked at the highest tier — Enterprise Plus. So if you don’t see an option to do a thing, that is probably why. That tier costs $36 per user per month if paid monthly, which is a little steep, BUT you can run pretty much your entire business off the thing, so I think it’s pretty decent value.

Also, no, no one paid me to write this. I just did it because I like Google Workspace, and I’m just annoyed that these things aren’t enabled by default — some of them should be. I am British and nothing motivates us to write something quite like anger does.

Also also, there may be more secure versions of these settings that what I’m suggesting below — but as we all know, the most secure settings can frequently clash with the needs of most businesses. So yeah, there could very well be a more secure setting than the one I suggest, but I always try and suggest things with the best mix of security and not getting yelled at by the business. I call it, the ‘middle of the road’ setting.

All of these settings are accessed through the Google Workspace Admin portal — found, unsurprisingly, at https://admin.google.com.

By the way, the absolute worst — most terrible — default setting is in Google Groups, and I’ve made it the final entry in this list. So make sure you stick around for that one.

Authentication — 2-Step Verification

Where: Security -> Authentication -> 2-Step Verification

An important topic in the world of security, how do your users authenticate to the thing. The thing in this case being Google Workspace.

The default, out of the box configuration is to allow users to enable 2SV, but not require it. Needless to say, you should enforce it — how you set the enforcement deadlines etc, are dependent on your business and program.

For allowed methods, the middle of the road option is to allow anything except phone call and text, so essentially, authenticator apps and security keys. You can also allow users to trust devices to avoid 2FA fatigue, which is probably worth it on balance.

Default settings:

Recommended settings:

Account Recovery

Where: Security -> Authentication -> Account Recovery

Google Workspace sets two types of rule around account recovery depending on the account type. Essentially, there are one set of rules for super admins, and one set of rules for everyone else.

By default, Super Admins can recover their own accounts via a self service flow, and regular ol’ users cannot. They’d need to contact an administrator to help out.

I think this one is very dependent on the individual business. If you have an IT helpdesk, I think requiring regular users to speak with someone who can confirm their identity, but enabling super admins to self serve, is probably the best fit. Any changes to super admin accounts get flagged via an alert anyway. If not that, then disabling all self serve options — but making sure that you have trained your helpdesk folk to recognize and defeat social engineering attacks is critical.

Default settings:

Recommended settings:

Advanced Protection Program

Where: Security -> Authentication -> Advanced Protection Program

The Advanced Protection Program allows employees who are at increased risk of targeted attacks, perhaps because they are journalists, or the CFO, to enable a series of additional controls to protect their accounts. The full details on this program can be found thus: https://landing.google.com/advancedprotection/.

This one is very much an organization specific, and user specific thing.

The default configuration seems to be the most sensible for the majority of places. Allow users to enroll if they wish, and allow them to generate security codes for one time use where things like hardware keys aren’t supported — but ONLY from the same local network. It still means you have to talk to people about enrolling — but if you have people that should enroll in this program, you should talk to them a lot anyway.

Default and recommended settings:

Passwordless (still in Beta)

Where: Security -> Authentication -> Passwordless

Passkeys are seemingly the flavor of the week in the world of InfoSec at the mo — and for good reason, we’ve wanted to kill passwords forever, and now it looks like we’re finally getting there.

Google Workspace’s passkey support is in beta, which means it’s not enabled by default. My advice — enable it for a subset of users (which you can do via OU), so that you can test all the flows ahead of it becoming a potential ‘default’ in the future.

Default settings:

Recommended settings (apply to a test OU):

Password Management

Where: Security -> Authentication -> Password Management

AKA the password policy, an oft controversial topic amongst the Infosec crowd. So, here is where I’m at on it:

The default requires a password between 8–100 characters with no complexity requirements, allowed reuse, and no expiration.

My recommended setting is to up the length requirements to between 16–100 characters, enable the complexity setting, keep reuse enabled and no expiration. A note that 100 characters is the maximum allowed by google.

If people are using these settings combined with the 2SV settings above, then that is pretty solid. No one wants to rotate passwords anymore, and NIST says that requiring people to do so is not worth it.

You can also enforce these settings apply from next login to ensure everyone is compliant from the get go — of course, you should let your users know if you’re doing this.

Default settings:

Recommended settings:

API Controls

Where: Security -> Access and data controls -> API Controls -> Settings

This tucked away little setting is extremely powerful, and can really help you lock down your Google Workspace instance. Essentially, you know when you ‘Sign in with Google’ to a third party application, and it asks you to share certain information with the app — this setting is where you chose how much information your users can share without your permission or oversight. In other words, it’s a great place to go to save your org from someone accidentally sharing 5,000 documents with Shady McShadyApp.

By default, users are allowed to share whatever the eff they desire with third party apps, which as you’ll probably agree, is somewhat suboptimal. Fortunately, you can put a stop to the madness in one fell swoop.

Changing the unconfigured third-party apps setting to permit only basic information to be shared, so your users can still sign in with Google, but not give those apps any deeper access to your org without specific approval seems to be the smartest choice. We want people to not set passwords and use SSO where possible, but we also want to control where our data goes. The following change makes that happen:

Default settings:

Recommended settings:

BUT WAIT! Before you make this change, you’ll want to make sure that you set policies for the apps that you do want people to use. Otherwise, you’ll be a world of pain as things break all over the place. Stuff like, Slack, iOS would see access disrupted if this change were made without prep.

To prepare, go to Security -> Access and data controls -> API Controls -> App Access Control, and build up your allowlist of approved apps before you go ahead and make the change. The Google UI lets you see which apps are being used, and how broadly, so it’s easy to see which are the more ‘official’ ones you want to trust.

Client-side encryption and Content-Aware Access

Where: Security -> Access and data controls -> Client-side encryption/Context-Aware Access

Honorable mention for these settings here — it’s hard to suggest a recommended setting, since they are very dependent on your own organizational needs and compliance requirements — so, instead, just to a note to say these features are here and you should use them if you can.

I specifically recommend the use of context-aware access, since that can allow you to do things like stop people accessing certain classifications of file from non-compliant machines, or while they are on vacation. The possibilities are endless quite frankly.

Client-side encryption is a bit more involved to setup, but similarly powerful for tightly regulated environments.

Data Classification

Where: Security -> Access and Data Control -> Data Classification -> Drive and Docs

This is a very easy one to setup, and something you should do. It sets a mandatory label field on every new document/spreadsheet/whatever file created on Google Drive that defines the classification. If you enable this setting and make a classification label, it will help you later on if you decide to put specific controls around ‘confidential’ labelled material, for example.

The default setting is ‘off’ (along with the general labels setting). So turn that on, and configure your classification label to align with your own policy. You can then enable the default classification field.

Default setting:

Recommended setting, although you probably don’t have a ‘top secret’:

Data Protection

Where: Security -> Access and Data Control -> Data Protection

This is essentially Google’s built-in DLP tool. You can build rules in here that apply to your instance and do all manner of things. Again, hard to come up with a ‘recommended’ setting because everyone has a different risk profile, however, I would recommend that you keep the default scanning and OCR settings enabled (even though the OCR setting only applies to Google Chat, which many places don’t use.)

Default and recommended settings:

Google Session Control

Where: Security -> Access and Data Control -> Google Session Control

When you have an active Google web session, how long should it stay active for? That’s the question you are answering in here. The default is 14 days. I think that is a bit long, so I’d suggest 7 days.

Ultimately, I think the best approach is to make this setting as irrelevant as possible by layering on the session expiration settings and other controls (such as context-aware access) to prevent people’s sessions from being left unattended in the first place.

Default settings:

Recommended settings:

Less Secure Apps

In this context, “less secure apps” means apps that don’t do the Oauth dance, and instead require your username and password (shudder) to interact with Google. This type of app support will die naturally next year anyway, when Google blocks it across the board, but for now — it remains allowed by default.

I recommend killing it off early.

Default setting:

Recommended setting:

Directory info sharing

Where: Directory -> Directory settings -> Sharing settings

A minor thing, but this just restricts some of the fields shared with external services, which is never a bad thing. Make em’ work for it, don’t give it all away for free!

Default setting:

Recommended setting:

Drive and Docs — File Sharing

Where: Apps -> Google Workspace -> Drive and Docs -> Settings for Drive and Docs -> Sharing Settings -> Sharing Options

You could write a book on this topic — a boring book, but still, a book. Again, it’s very org specific, so hard to summarize a recommended setting in one spot. So let’s just go over it broadly. By default, users can share files with anyone either inside or outside the org via Google Drive/Docs. So if you want to restrict that, you can do so here.

Again, it totally depends on your compliance requirements or risk management needs. You can deny all outside sharing or limit it to specific domains.

Shared Drive Control

Where: Apps -> Google Workspace -> Drive and Docs -> Settings for Drive and Docs -> Sharing Settings -> Shared Drive Creation

Google’s equivalent of Public Folders in Microsoftland, shared drives are where teams and companies like to lay out their Google docs in the name of collaboration. Some companies have one giant Shared Drive and separate team folders. I don’t like that. Others have separate team drives with a different set of access controls on each. That seems a bit better.

However you do it, you can chose who is allowed to create the shared drives in this spot. By default, anyone can create a new shared drive, and the various settings allowing people to be added to them are pretty open. I’d lean towards a bit more restrictive, just to keep things in order — but again, it’s all very company dependent.

Since many people contribute to Shared Drives, I think it’s best to keep them internal, and keep external sharing a bit more limited, and that is reflected in my recommended settings below. You can also use your DLP rules to make this all a bit more dynamic if you wish.

Default settings:

Recommended settings:

Gmail — Attachments

Where: Apps -> Google Workspace -> Settings for Gmail -> Safety

We can all agree that the best setting here would be to completely disable all email, but unfortunately, that does not align well with the need for interstate commerce that most business have. So, we’ll let it stay, although there are lots of settings we can enable that aren’t on by default to make emails a lot more bearable from the security perspective.

Attachments, the preferred malware delivery technique, should be subject to the utmost scrutiny — and yet, the defaults do not do this.

There are three attachment security settings we should enable, all of which are pretty self explanatory.

  • Protect against encrypted attachments from untrusted senders.
  • Protect against attachments with scripts from untrusted senders.
  • Protect against anomalous attachment types in emails.

All off. All should be on.

Default settings:

Recommended settings:

Gmail — Links to images

Where: Apps -> Google Workspace -> Settings for Gmail -> Safety

There is a setting that controls wether or not links to external sites get flagged by a pop up. It’s off by default, probably should be on, so people can be jolted into checking what they are clicking on. Seems like a bit of a no-brainer to be honest. Make it this:

Gmail — Spoofing and authentication

Where: Apps -> Google Workspace -> Settings for Gmail -> Safety

These are some quite nice settings for dealing with spoofing techniques commonly used in phishing and social engineering. Why they are off by default is beyond me. Enable them all. When you enable them, you have a choice as to what to do when a message trips one of the rules, so you can reject or quarantine as you see fit.

Default settings:

Recommended settings:

Gmail — Authenticate email

Where: Apps -> Google Workspace -> Settings for Gmail -> Authenticate email

Don’t forget, the above settings are using standards such as SPF and DKIM to make their decisions about what is and is not spoofing — so you should always ensure that your own outgoing emails are properly authenticated.

This is where you’ll find the DKIM configuration for your emails. DKIM relies on a DNS TXT record installed in your DNS zone — so be sure to follow the guide in Workspace to enable this.

Default setting:

Recommended setting:

Gmail — Automatic forwarding

Where: Apps -> Google Workspace -> Settings for Gmail -> End User Access

The default Google Workspace setting allows users to enable automatic forwarding to other email addresses. This could include email addresses outside of your domain, such as a personal email account.

In summary, you don’t need that drama. Disable it.

Default setting:

Recommended setting:

Gmail — security sandbox

Where: Apps -> Google Workspace -> Settings for Gmail -> Spam, phishing and malware

Would you like Google to detonate attachments to see if they have something bad in them before they get to your users? The answer is probably, yes. The default is, ‘nah, we good’. So, to right this particular wrong, you’ll enable the security sandbox feature.

Default setting:

Recommended setting:

Note that you can also set a selection of rules to fine tune which messages are subject to this particular setting — so, if you run into issues with some legitimate emails not getting through, you could adjust those rules rather than disabling the whole thing.

Gmail — spam

Where: Apps -> Google Workspace -> Settings for Gmail -> Spam, phishing and malware

Spam filtering is enabled by default, but you can tune it here. You can elect to be more aggressive in the filtering, or you can bypass spam filtering altogether. Personally, I think Google strikes a good balance with the defaults, so I’d be tempted to leave them, but come check out these rules if you want to crank it up a notch.

Gmail — Blocked senders

Where: Apps -> Google Workspace -> Settings for Gmail -> Spam, phishing and malware

Troublesome sender repeatedly sending bad stuff? This is the place to come to explicitly block an email address or domain.

Gmail —Compliance

Where: Apps -> Google Workspace -> Settings for Gmail -> Compliance

This page has several settings which again, are pretty organization specific depending on compliance requirements. You can go very deep here, and do things like block specific attachment types, or scan for certain keywords and reroute email accordingly. The one I’d recommend for everyone, however, is the image OCR setting. It’s off by default, but you can enable it here.

This setting allows images and other files (PDF’s) to be scanned for content before they are delivered to your users. You may as well, you are paying for it.

Default setting:

Recommended setting:

Google Chat — External spaces

Where: Apps -> Google Workspace -> Settings for Google Chat -> External Spaces

Let’s be honest — in most places, Google Chat is the emergency backup in the event Slack goes down for any reason. By default, our favorite backup chat mechanism allows users to create chat messages with folks outside of the company. Doesn’t seem like a huge deal, but if you aren’t watching it all the time — better to disable that setting.

Default setting:

Recommended setting:

Alternatively, if you aren’t using it at all — just disable the chat service entirely.

Google Meet — Who can join meetings created by your organization

Where: Apps -> Google Workspace -> Settings for Google Meet -> Meet safety settings

Regardless of wether or not Google Meet is used by your org, if you have Google Workspace, it’s there and it’s enabled by default.

Not using it because your using Zoom or something else? Go ahead and disable it.

Not really using it — but don’t want to disable it? Then best to change the settings that allow Google Meet to be less of a free for all — including: ‘who can join meetings created by your organization’.

By default, the answer is anyone who so desires, you can change this to make it people with a valid Google account, or within your org. I’d say valid Google account is a good minimum.

You can also change the setting immediately underneath it to prevent people joining — non-Google Workspace Google Meets (i.e. no free Google account meetings), that one seems somewhat sensible as well.

Default settings:

Recommended settings:

Google Groups — sharing options

Where: Apps -> Google Workspace -> Settings for Groups for Business -> Sharing settings

Distros, listservs, security groups, email groups, whatever you want to equate them with, Google Groups are powerful — and have the potential to really screw you over if not managed properly. I’ve saved Google Groups till the very end, because I honestly believe the worst default setting in all of Google Workspace is to be found in the Groups app.

By default, anyone in the organization can create groups. I’m not a huge fan of this. There is a lot of scope for screw ups. Therefore, I personally like to limit new group creation to be only admins — it adds to the workload, but I think it’s a worthwhile sacrifice.

Default setting:

Recommended setting:

Next up, by default, Group owners, that is to say people in charge of their group, can choose to allow external emails to be received by the group.

Mmmm. Not really a fan of that — I think it’s always best to know which email addresses are in use outside of a company, so yeah, gonna go ahead and disable that one.

Doesn’t mean no external email can ever make it to the group — but it does mean an admin has to explicitly enable it, which I think is fair.

Default setting:

Recommended setting:

Alright, and buckle up — because here comes the howler. The absolute worst default in this whole thing that makes absolutely zero sense to me, and I have seen accidentally reveal a lot of sensitive information to many a person.

Default permission to view converstations — i.e. who in the org can read the emails sent to the group? You’d think — well, probably just people in the group, right? WRONG. The default, for some unfathomable reason, is that ANYONE IN THE ORGANIZATION CAN READ THE MESSAGES EVEN IF THEY AREN’T IN THE GROUP!!! WHAT?!

Default setting:

Recommend setting:

This one has caught so many people out, and led to so many problems — I genuinely cannot believe it hasn’t been changed yet.

I don’t get it. Limiting an audience is the primary reason people make these groups — why would anyone want to allow the whole frigging org to see the messages? I’ve seen this catch out groups named ‘legal’ and ‘finance’ and ‘senior leadership team’ and it’s done it for years. If you have the default setting enabled, anyone in the Workspace org can search for messages in your top secret group. Insane.

Anyway — fix it and move on — oh, and go check any previously created groups to make sure they don’t still have the wide open view permission.

So, I hope you found this guide useful. As I say, I’m a big fan of Google Workspace — I just wish they’d surface more of these features by default. One day, perhaps. Until then — this guide will serve as the go between to making things. a lot more secure with minimal effort.

--

--

Mike Sheward

Information security professional specializing in SecOps, IR and Digital Forensics. Author of the Digital Forensic Diaries, and now, the Pen Test Diaries.