Note: Does your organization rely on Google Workspace? Learn how Torii’s Google Integration lets you uncover shadow IT, create custom workflows to automate dozens of actions like onboarding, department transfers, and offboarding, automatically track SAML audit activity events, and more. Learn more about Torii’s powerful integration with Google Workspace.
BeyondCorp is the hot new tool to protect yourself and your company from hacking. But getting started might seem a bit daunting. This post shall share information with readers on how to get started with BeyondCorp within G Suite Enterprise, what pitfalls are coming up, and how to expand it beyond G Suite.
This can become a series as there are a lot of things to consider and work with. G Suite Enterprise is just the start, and you can expand it to include 3rd party services like Duo into your strategy.
Overview
You may have heard of BeyondCorp as a concept, found it interesting and useful, and now want to know how to implement it. You have googled around, tried to find how to implement it within G Suite and got stuck. Well, this is your guide. The G Suite implementation doesn’t call it BeyondCorp but Context-Aware Access which can be found in the Security section in G Suite. Taking a quick look, there reveals a couple of options for you to see, change, and adapt to your needs. This article will guide you through the settings and the current limitations and pitfalls.
3 key terms: BeyondCorp, Context-Aware Access, and Endpoint Verification
BeyondCorp is a security concept pioneered by Google and other born-in-the-cloud companies that noticed information security cannot be limited to the physical location called the office. Most people use third-party apps that they do not control or are not hosted inside their own network. Limiting access to devices only on your own network doesn’t make sense anymore. But you can still ensure security by making the endpoint accessing your data secure. To do so, it needs to be encrypted, have a password, and be virus free. That’s BeyondCorp in a nutshell.
Context-Aware Access is the technology that allows you to define when a user can have access to which tools. Maybe you are a bank that only wants the bankers to access your customer data inside the office or a special location. You can do that based on the endpoint’s IP address. So you only allow special IP addresses to access the CRM app.
Endpoint Verification is a part of Google’s implementation of Context-Aware Access. It defines if an endpoint is secure and safe to access your data. For example, it checks for encryption and password status.
Let’s see how it works with a concrete example: Enforcing device encryption to access Salesforce
Enforcing access to Salesforce only from encrypted devices can be done in 3 steps:
- Defining access levels
- Assigning Salesforce access level
- Testing
Step 1: Defining access levels
In G Suite (Google Workspace), you first need to go to admin.google.com > Security > Context-Aware Access.
Here you have three panes. The first two define your policy, while the third panel lets you define what your un-compliant users have to do to do or who to contact for help.
For troubleshooting purposes, it is preferable to create multiple policies that can be applied individually rather than one all-encompassing master policy, as to turn specific requirements on/off if necessary.
To get started, you first have to define access levels, so you can select ‘Create Access Level’. Now we need to name it. As we want to make sure that all devices are encrypted before accessing Salesforce, we just call it “Encrypted Device” and add a short description for later use. We want to ensure that a device is encrypted so if they get lost, we can at least make sure the data on the device is hard to get to.
Now click “Continue”.
You are now prompted with your first choice. Either you allow users access if they meet specific conditions (Allow List) or if they don’t meet those criteria (Deny List). Both have merit. For encrypted devices, we choose the (default) Allow List option. After that, we click Add Attribute > Device Policy. We are now prompted with a couple of options. As we only want to check if a device is encrypted, we leave “Device password required” at “No,” click into “Device encryption (optional),” and choose “Encrypted”. We leave everything else at default. The settings should now look like this:
Step 2: Assigning access level
Now you can press “Create Access Level”
Go to the “Assign access levels” / “App Assignment” section. On the left side, you will find all your Groups and Organizational Units, and to the right, your Core G Suite Apps and all your SAML SSO Apps. You can choose any number of G Suite and SAML apps you want to protect. To start with, you can test the functionality by selecting your Salesforce Sandbox. Now assign them the newly created policy by clicking on “Assign”. A pop-up will appear with different access levels to choose from: select the one(s) you want to use and save. Now you should be able to test if it works.
Step 3: Testing
Try opening your Salesforce Sandbox and make sure you do not have the “Endpoint Verification” extension installed/enabled in Chrome. If you do not have it installed, Google will not know the state of your device, and you’ll be denied access as you would for an encrypted device. Now install the extension and try again; you should have access now!
Before rollout, you should push this extension to all your devices and/or users using a profile or Chrome Cloud Management.
BeyondCorp’s known limitations
As BeyondCorp is still in beta at Google, there are some limitations you need to be aware of.
Mobile
On mobile, some policies only apply for official Google apps. They DO NOT apply in browsers. Yes. Not even in Chrome. Please provide feedback on this using the feedback form on top of the Context-Aware Access page.
If your policy requires an encrypted and password-protected device for, say, Google Sites, Forms, or Slides, your users may run into a problem. Public Google Sites or Forms won’t be accessible on mobile, even when they are published by outside users. Sharing a presentation on mobile in full screen won’t be possible as it opens in a webview. It just quits the webview when you press the play button and doesn’t show the normal warning page.
SAML and OAuth
Your SAML apps will only be checked on login. So you may want to reduce the session duration for these apps to 20 or 24 hours — or even less if this is a huge concern for you.
OAuth 2.0 Apps are currently not protected at all.
Conclusion
BeyondCorp is a security concept allowing you to expand your security control onto third-party apps by making sure the endpoint accessing your data is secure. You can secure your company’s access to an app in 3 steps: defining access levels, assigning access levels and then testing if it works!
