Hey, fellow Google Admins. Welcome back to Google Cloud Identity course. In the last video we discussed why Google Cloud Identity in the first place, I hope you got a chance to watch that video.

If not yet, I would recommend you to watch it first and in this video let's talk about what is Google Cloud Identity?

Let me share a few slides which will help you get that understanding.

So what is Google Cloud Identity?

Google Cloud Identity is an Identity as a Service (IDaaS) offering from Google which helps customers manage their identities centrally, along with providing secure authentication & authorization to applications & devices.

It is essentially identity as a service offering from Google which helps customers manage their identities centrally.

These identities may include users groups in members, etc, and we'll talk more about that in a minute, along with providing secure authentication and authorization to applications and devices so that right people would have access to right resources in the right context.

I understand this is just a summarized version of my understanding of Google Cloud Identity.

Let me take you to another slides where we will talk about that in much more detail. So you understand what Google Cloud Identity can do for you as your centralized identity provider.

Number one, it is a cloud based directory.

Which means you can do things like manage your organizational units, your users, your groups, members etc in this cloud based directory just like you have been doing in traditional Microsoft on premise Active Directory or Open LDAP.

It also offers directory sync (called Google Cloud Directory Sync or GCDS) which means in case if you already have directory somewhere like Microsoft AD or LDAP , you can install this Directory Sync behind your firewall to take all those identities and put them in Google Cloud Identity.

You can have this sync running on a schedule by itself. You can also apply settings and policies right there in the Google Cloud Identity admin console which you get when you sign up for Cloud Identity.

Now along with Directory, it also helps you with your authentication system.

For example, you can have password policies to define how complex the password should be when users are trying to log in to Google Cloud Identity.

You can also enforce MFA or two step verification as Google calls it, where once you put your credentials, you will be required to put the second factor of authentication, and it supports almost all of the factors of second factor authentication including the TOTP based ones like Google Authenticator or Microsoft Authenticator, Security Key, SMS, Voice, Mobile push etc.

Also, you can have same authentication so that once you log into Google, you should be able to connect to other third party applications which provide SAML access. There is a catalogue which Google provides in which hundreds of applications are available for you to just plug and play.

In case if you do not see any application in that catalogue, you have choice to create a custom SAML application.

Now, in case if you have been using LDAP based applications, those applications might be hooked up with your LDAP or Active Directory for authentication and authorization. You can now call Google Cloud Directory as your directory in LDAP as a service fashion.

So instead of using or hooking your your Ldap based applications with Active Directory or Open LDAP, now you can hook it up with your Google based cloud directory via a utility that's called SecureLDAP.

Now there are some applications which do not support modern authentication protocols, like SAML or OpenID.

For those applications, Google has also launched something called Password Vaulted Apps, which is available in Google Cloud Identity. I'm sure you might be using some sort of password manager in your personal life like LastPass Dashlane or maybe Google Chrome password Manager.

It is essentially the same thing, but you as a Google Cloud Identity admin can control who will have access to which application. So once you create a password vaulted application, you can either enter the credentials on your users behalf, and then you can assign this application to a group of users.  When these users log into their Google Cloud Identity dashboard, they will see the application there which they can access at one click without a need to enter password. Okay, so after authentication, it also provides you authorization to decide who and when can have access to which resources.

For example, you can define which applications will be available to which users. Google Cloud Identity comes with a few applications and one of them is Google Drive.

Now in your admin console you can define who will have access to Google Drive, Is it all of your users, or maybe a subset of your users.

You can also define context of your access, which means in which context user will be able to access application X, Y or Z.

Let me give you an example. Let's say you create a policy, which says in case of Goldy is trying to log in from Office IP range, and if Goldy is on company owned device, then he should be able to access Gmail and Google Drive.

But if Goldy is coming from his home IP address and is coming from a personal device, then he should be able to access Google Met, but not Gmail and Google Docs.

So you should be able to create those kind of policies with context aware access. Another one is programmatic access, Google Cloud Identity has some applications, and in case if you're using Google Workspace, it has even more set of applications.

But sometimes you might need to enhance your Google Workspace or Cloud Identity experience by installing third party applications, which means one side you need to enhance that experience, but on the other side you shouldn't be making any compromise on security side. So with programmatic access or a feature that's called API controls in Google Cloud Identity, you can define which third party applications are allowed to access your users data programmatically. You can put those applications in allowed list, and then only those apps will be able to programmatically interact with your users data after authorization. Now, let us see how Google Cloud Identity helps us with the user lifecycle management.  

In the last video we discussed, each user today is consuming multiple applications, and unless you have a centralized identity provider, it is very painful for users as well as for admins to do the administration and to consume those applications on day to day basis.

Fortunately, with Google Cloud Identity, you have a catalogue of applications where you can (after initial configuration) automate user life cycle management.

So for example, I can do things like if my user's job title is equal to sales, then put that user into my Salesforce group (this happens with the dynamic group functionality that Google Cloud Identity offers) and then assign Salesforce SAML application to the members of this group.

Now this user will have access to Salesforce application, and his account will also be automatically provisioned in Salesforce based on automated user lifecycle management and in case if that user leaves and you suspend that user in Google Cloud Identity, then his account would be deactivated in Salesforce too.

Another feature which Google Cloud Identity offers is Two Step Verification (2Sv) which is generally known as Multi Factor Authentication or MFA.

There is a little difference, MFA means more than one factor, it can be two or even three, However, Google's two step verification means you will have two step of verification. One is your Credential set (user email address and password) and then the second factor which can be SMS, voice, push notification, Google Authenticator or Security Key.

The best part is you do not need to invest anything additional. It's a part of Cloud Identity subscription itself, and in case if you have Google Workspace, it's all in built in.

As we discussed, you will have flexibility to implement 2Sv. You can either say enforce MFA from XYZ date so that your users will start getting notification when they try to log into Google services, that your admin has enforced MFA and you have x many days left to enroll.

You can also define the scope whether MFA is enforced for your whole organization or maybe just a subset of users, and within that subset you can also say that for my CXOs, only security key is accepted as a second factor of authentication however for rest of my users, Google authenticator or push notification is fine too.

Now, let us talk about Endpoint Management offered by Google Cloud Identity.

With Google Cloud Identity, you can manage your Android and iOS devices, you can control who can access data from these operating systems. You can also have your own allowed list where you say these are my ten corporate applications which can interact with my Google Cloud Identity data.

You can have a list of your allowed corporate applications for your Android and iOS.

On Android, you can also have a work profile, so in case of BYOD or bring your own device, your users can come up with their personal device and they will have a virtual isolation between their work and their personal life where you can control what happens in their work profile and let them choose what happens in their personal profile.

You can also do things like jailbreak detection, disable camera, password enforcement. You can also make policies on what should happen when a certain criteria is not met, Should you wipe the device?

If the device is lost or stolen or something happened to the device, you can either account wipe (which means only the corporate Google account will be wiped) or you can also do the factory reset or the device wipe (which means everything on that device will be wiped).

You can also manage Windows 10 devices with Google Cloud Identity, which means two things.

(1) You can have your Windows 10 users log into their devices via Google Authentication, that means in case if you have MFA enforced, when users try to log into their Windows 10 devices via their Google credentials, they will be required to enter their user ID, their password and second authentication factor.

It works directly with Google, so you do not need Active Directory or LDAP in place for that, but in case if you already have Active Directory, then this functionality can also work in conjunction or in complement to Active Directory.

(2) You can also push policies on Windows 10 devices right from your Google Cloud Identity admin console, just like you might do via GPO.

So things like user should not be able to turn off camera etc. You can also manage applications, you can also manage users with privilege access on those Windows machines, whether we're going to give a user local admin access or just a regular user access etc.

You can also manage your Mac devices, which means your users can log into their Mac devices via Google Authentication or Google acting as the identity provider for your Mac devices.

In case, if you're using Google Chromebooks, then you're all set because it's coming from Google itself and it provides even more functionality.

You would also have lot of security controls in place with Google Cloud Identity, lets talk about that a bit now.

There are a bunch of them, but just to name a few of the important one, the first one is DLP or data loss prevention, where in case if you're using Google Workspace, you would have DLP for Gmail and Google Drive.

You can apply DLP policies in 3 simple steps-:

Step number one -: You will define the scope (to which audience this policy be applied), so one can be all the users in your domain or a subset of users,  maybe users who belong to an individual group or organizational unit.

Step number two -: Your policy trigger, what should trigger this policy?

where you can leverage Google's 80+ content detectors to detect things like Social Security number, PHI etc.

Step number three -: Then finally, you can have your action.

This action can be, for example, if it's Google Drive, that action can be do not allow users to share this document outside my domain, or maybe let users share this document outside their domain but the recipients should not be able to make a copy or print or download this specific document.

If you want to learn more, I will have a different course in DLP soon.

Second security and compliance feature is "Data regions" where you can decide where your data be hosted when you are putting data in Google Cloud Identity.

Google has just announced a new feature called "Client side encryption", where you can retain the decryption key, so Google will even not have access to your Google Drive files.

Finally, the compliances, Google Cloud Identity does support or have compliances. For example, in case if you are a health care organization, Google can sign Business Associate Agreement (BAA) with you, at the end of the day, It's a shared responsibility, but till the time you are applying all the required controls as per Google's recommendations and your needs, then you can help yourself be compliant.

Another one is FedRAMP, Google Workspace or Cloud Identity is FedRAMP moderate as of now, and in progress for FedRAMP high.

So compliances are available in case if you are part of a regulated industry.

Okay and finally, whatever is happening so far in our journey to Google Cloud Identity will be logged so you can get insights from that.

By default, most of the logging is retained for six months in Google Cloud Identity admin console, just in case, if you have a need to retain these logs for longer duration may be for compliance or any other purpose, then there are a few options available to you.

You can have a Big Query integration, BigQuery is Google Data Warehouse offering where you can store and analyze large amounts of data.

Once you have this native integration in place, Google Cloud Identity (or Google Workspace) will automatically send logging table/s every single day to your BigQuery project, and then in BigQuery you can have your SQL queries along with your visualization layer like tableau, looker, or data studio etc.

Now in case, if you have already invested in a SIEM system such as Splunk, you can leverage Google integration with those prominent SIEM systems.

And finally, in case, if you have some sort of custom need for these logs to be made available to work with some of your homegrown systems, then you can also leverage Google Reporting API to parse those logs from Google system and take them to wherever you need to.

So in a nutshell, this is something Google Cloud Identity can help you with. There are a few things that I haven't included or I might be missing here.

If you have any questions, please feel free to put the comments under this video, and I'll be happy to collaborate on that.

But this is essentially like the summarized version of what Google Cloud Identity can do for you. I will make one more video to show you which applications from the end user side are included in Google Cloud Identity.

To wrap it up, Google Cloud Identity is an identity as a service offering from Google, it can help you manage your identities. centrally in a cloud based directory, it can also help you with secure authentication and authorization to your applications and devices.

So with that, thank you so much. In the next video, we will talk about the differences between Google Cloud Identity, Google Works Space, and Google Cloud Platform.

So stay tuned for that. Thank you so much.