[MUSIC PLAYING]
NICOLETTE STEPAKOFF: Hey, Nicolette here.
I'm a Google Workspace specialist focused
on public sector, and today, we will
be discussing context-aware access, because you don't
want anybody on your team to say,
I've got a bad feeling about this.
With context-aware access, you can set up different access
levels based on a user's identity and the context
of the request, like location, device security status, maybe
even IP address, expanding these policies to other Google
Workspace entry points, such as Google Drive for desktop,
or using Gmail on your mobile.
This gives admins greater control over how, when,
and where users can access Workspace resources.
You can still set access policies
such as 2-step verification, or what others call multifactor
authentication, for all members of an organizational unit
or group.
Context-aware access provides additional granular and
contextual controls for users.
A few of the ways I've seen context-aware access used
is when you want to allow access to apps from only
company-issued devices, allow access
to Drive only if a user's device is encrypted,
and restricting access to apps from outside
of the corporate network.
You can also combine more than one use case into a policy.
For example, you could create an access level that
requires app access from devices that are company-owned,
encrypted, and meet minimum OS version.
The first step in setting context-aware access
is to create an access level that
combines conditions and values that define a user or device
context.
Access levels define the context within which
a user can access apps.
For example, you can create an access level
for accessing Gmail that requires users
to connect from a specific IP address range
and require that their devices be encrypted.
So let's say Mary's using Gmail on her laptop
in the corporate office, and then she
decides to walk to a nearby coffee shop, where she
plans to continue using Gmail.
Because her IP address changed, she
won't be able to access Gmail at the coffee shop
if you, the admin, specify that users can only
connect to Gmail from a corporate IP address range.
Private IP addresses aren't supported in this example.
Now, before I show you the fun stuff of setting up
context-aware access, I'd like to talk to you about the two
rollout options you will have when setting up
context-aware access.
You can turn on context-aware access
at different times in the rollout process.
You can turn it on before creating access levels
and assigning them to apps, which
means that access levels you assign to apps
are enforced immediately, or you could do an initial setup
and review--
so access level creation, access level assignment,
end point verification--
without turning on context-aware access.
During this time, access level assignments are not enforced.
When you're done configuring, you can then
turn on context-aware access.
So let's show you a little bit about how
to set up context-aware access.
To turn on context-aware access, we're
going to go ahead and start in the Admin Console.
We'll move your gaze to the left side of the screen here,
and we're going to go ahead and click to the left of Security.
In the dropdown, we'll go ahead and click the caret
to the left of Access and Data Control,
and we're going to find Context-Aware Access.
Over on the right, you'll notice that context-aware access
is currently turned off.
We can enable context-aware access for everyone
by turning it on.
It is important to note that context-aware access is going
to be on or off for everybody.
However, once we get to assigning the access levels,
that's when you can assign an access level to current OUs
that you have set up.
So what I'm going to do is I'm going to review an access
level that I have currently set up,
and then we'll jump back into this screen
and we'll turn on our context-aware access.
So we'll move our gaze just to the right
here, where we see access levels.
I'm going to go ahead and click into my access levels.
And you'll notice that I have one access level created.
If I wanted to create a new access level,
we'll move our gaze to the upper right corner,
and you can click Create Access Level.
But again, today, I'm going to just review an access level
that I have predefined.
So you'll notice we have a Details section where
I've named the access level, and then maybe you
want to provide it a brief description.
If we scroll down a bit, your access level
is going to consist of one or more conditions
that you are going to define.
So access level conditions contain
attributes that you are going to select, such as device policy,
geographic region, IP subnet, et cetera.
You can create two different types of access levels.
So you have Basic mode in the upper left here and Advanced.
Now, Basic mode does provide you with a list
of those predefined conditions, and you can add as many
of the attribute conditions as you want.
And then you have Advanced.
So in Advanced mode is where you can create access levels
that you might not be able to create with the Basic settings,
such as you might want to create an access level to include
a vendor condition for third party integrations,
or maybe the ability to use a certificate-based
authentication.
So in this mode, you can build those custom levels
using common expression language.
For example, here in Advanced, you
can create an access level that maybe requires
the device is encrypted and one or more of the following
is true-- either the request originated from the States
or the device that requested originates
from an approved domain by the admin.
For now, I'm not going to touch Advanced.
I'm actually just going to hop back into Basic mode.
And here again, we have our geographic origin
is the United States.
So anybody that is going to access
the app that we'll select has to come from the United States.
In the lower right, you will see a blue Save button
if you're creating a new access level.
But today, since this is predefined, I'll go ahead
and just hit Cancel.
We'll be taken back to the access levels list.
Now that we've created an access level, let's go ahead
and assign that access level to the apps.
Moving your gaze to the upper left corner,
we're going to select Context-Aware
Access in the breadcrumbs, and we'll
choose Assign Access Levels.
So here is where you can assign access levels to specific apps.
And remember, we can do this on an OU basis.
So what I'll do is move your gaze to the left.
I'm going to find my Back to the Future OU.
Today, we'll focus on Gmail.
I could either check the box to the left of Gmail
and in the upper portion of this table choose Assign,
or, if I hover over Gmail over to the right,
I can choose the blue Assign button.
Now, you'll get a couple of pop-ups.
The first option in the pop-up means
that users, if they meet the condition of your access level,
will be granted access to this app.
So I'm going to choose Back to the Future Access Level.
You'll also have an option below that says "Apply to Google
desktop and mobile apps."
This is very, very important.
To apply access levels to the desktop, Android, and iOS apps,
as well as web apps, where we want to make sure
this box is checked.
It is important to note that this box does only
apply to native apps.
But again, we recommend that you check
this box whenever you assign access levels to apps
and always deploy endpoint verification from a security
standpoint.
Once we're done, we'll go ahead and hit Save.
And just like that, we've created and assigned
an access level.
In the upper left, we'll click back to our Context-Aware
Access breadcrumb, and then I can choose that Turn
On option, if I would like to turn on that access level
and those apps that have been assigned.
Thanks for joining us as we cover context-aware access.
Stay tuned for our next video to learn more about how
you can set up and customize your mobile device management,
and be sure to check out the description below
for helpful links and subscribe to the Google Workspace YouTube
channel.
Thanks for joining us.
[MUSIC PLAYING]