How we use Google Identity Platform to secure work projects

Our mobile app developers are running their projects in Firebase, a platform by Google that integrates monitoring tools, user analytics in apps, and other useful tools. There is an alert system that sends notifications to the email if something in the app starts going wrong.

Previously, employees joined projects in Firebase through their own Google accounts. The same way the workspace was accessed by customer representatives including analysts, PMs, etc. This scheme created serious security risks as if the personal account was compromised, attackers would have a direct path to our products. There were also no centralized control tools to disconnect an employee who quit the team or left the company, let alone users from outside the company.

In addition, Firebase users with basic roles had excessive permissions, for example, "editor" and "viewer" could move into the project management console.

How we took control over the situation

So, we needed an authentication system that would provide login without private addresses, having an administrator console to control all project participants. We also needed a way to give the users the minimum rights they needed. We did not have to go far and the solution was a cloud platform run by Google (Google Cloud Platform, GCP).

Now we have a corporate account, which we synchronized with Active Directory. Team members receive invitations to join the project via email and authenticate with their True Engineering login. Synchronization with Active Directory is done through Google Identity Platform (GIP), which also provides Single Sign-On.

Since the credentials come from our AD, Firebase automatically complies with our own security rules, such as password management policy and user hierarchy. Participants do not need to be added manually as they are automatically pulled into the GIP admin console from AD.

As to access rights management, the platform is very powerful: there are about 5 thousand roles provided. The user can configure access for any purpose.

Main security features of Google Identity Platform

• The admin panel has an entire list of users with access to working projects, you can assign and unassign access rights with a couple of clicks. There are tools to control IP addresses with the ability to send an alert if a user logs in from an unusual location.
• The SSO system keeps track of the list of applications where users log in to their work address. Of course, these are applications that are connected to work projects and privacy is maintained. Unnecessary or insecure applications can be forcibly deactivated via the admin panel or by assigning group policies to the applications.
• You can see how many documents an authorized user has uploaded to Google Drive, and how many files he or she has made available. Again, for privacy reasons, the content of the files is not disclosed. But if a company has strict rules about using the cloud, this feature could be very useful. For example, True Engineering prohibits developers from sending work files to public clouds.
• There is basic but not bad vulnerability analytics (Security Health Analytics). It helps to automatically detect configuration problems, unprotected ports, and more serious threats. If a product has the ability to execute arbitrary code, intercept data, or gain unauthorized rights, the Security Command Centre will show the vulnerable asset and suggest how to eliminate a particular threat.

Image

• Remote employee device management tools allow user to lock a stolen or lost smartphone. In addition, there are alerts about hacked gadgets: in Android it checks for root access, and for iOS jailbreak is monitored. For us, this feature is not very useful, as our mobile developers use exactly such devices, but in general, the information is more useful.

How to set up Google Identity Platform: step-by-step instructions
1) Go to Google Cloud Console.
2) Log in with your GoogleID.
3) In the control panel on the left side, find IAM & Admin position, and click on the second item:

Image

4) Clicking will open a window to go to the checklist.

Image

5) Follow the step-by-step instructions.

Image

The super administrator can do absolutely anything. In particular, only a super administrator can restore an account.

Use the super administrator role to create "regular" administrators who will perform work tasks, hide the super administrator credentials in a safety locker.

It is very important to carefully build the resource hierarchy. Do everything step by step, do not skip anything. Note that permissions are inherited: if something is missing, a user with minimal permissions can gain maximum access.

At the end, be sure to double-check everything. For example, make sure that a user without "Owner" rights can't invite anyone to the project or go to the Google Cloud console. At the Firebase level, a regular user should not have Add member and Advanced permission setting buttons active.

Short checklist:

• You must have a Super Administrator
• Administrator at the organizational level
• Administrators at the resource level (units, folders, projects)
• One user can have multiple admin rights.

The Firebase administrator has maximum rights only in Firebase:

Image

The organization administrator has maximum rights at the organization level. Only Project Mover can create, delete and migrate projects.

Image

See Google Help for more information.

Conclusion

As we said above, from our point of view, the solutions by Google are almost as good as many of the paid products currently offered on the market. All of the features we've described here are available in the free version of the Google Cloud Platform, which includes access for 50 employees. We have about 40 specialists in our Mobile Apps Development Department, so these features are quite enough for us.

Besides, if you need to increase the quota, you can send a request to Google support, and they are likely to provide you with what you need. For example, in our work we use the BigQuery tools, also from the Google portfolio. They are paid, and the billing is calculated by the volume of requests sent. Using these systems may well be an argument for expanding the free GCP quota.