Securing Google Cloud Super Admins
Preventive Measures
Set up multiple super admin accounts
Your organization should have more than one super administrator account, each managed by a separate individual (avoid sharing an admin account). If one account is lost or compromised, another super admin can perform critical tasks while the other account is recovered.
Don’t use a super admin account for daily activities
Users should only sign in to a super admin account to perform super admin tasks, such as setting up 2-Step Verification (2SV), managing billing and user licenses, or helping another admin recover their account. Super administrators should use a separate, non-admin account for day-to-day activities.
For example, if Maria and James are super admins, they should each have one identifiable admin account and one user account, as follows:
- admin-maria@example.com, maria@example.com
- admin-james@example.com, james@example.com
Require 2-Step Verification for admin accounts
If someone manages to get the admin password, 2-Step Verification (2SV) helps protect the account from unauthorized access. It’s especially important for super admins to use 2SV because their accounts control access to all business and employee data in the organization.
For details, refer to Protect your business with 2-Step Verification.
Use security keys for 2-Step Verification
There are several 2SV methods, including security keys, Google prompt, Google Authenticator, and backup codes. Security keys are small hardware devices that are used for second factor authentication. They help to resist phishing threats and are the most secure form of 2SV. Types of security keys:
- A hardware security key or a Titan Security Key.
- Your phone’s built-in security key (available on Android 7+ or iOS 10+).
When a user signs in to their Google Account, their device detects that the account has a security key. For the second verification step, the user signs in with their security key. Users connect their security key to their device by USB, Bluetooth, or NFC (Near Field Communication), depending on the type of key. Learn more about security keys.
Split ownership of the credentials and 2SV method
To prevent unauthorized use of the Super Admin account, place the 2SV method in the custody of another individual, preferably from a separate department. For example, if the Super Admin account belongs to a member of the Cloud Operations team, the 2SV method can be held in the custody of the Compliance or Security department, unrelated to the Cloud Operations team. This also helps achieve the principle of Segregation of Duties (SoD).
Detective Measures
Google Admin Console (admin.google.com)
Set Up Admin Email Alerts
Monitor admin activity and track potential security risks by setting up admin email alerts for certain events, such as suspicious sign-in attempts, compromised mobile devices, or changes by another admin.
When you turn on an alert for an activity, you receive an email each time that activity happens. For details, refer to Admin email alerts & system-defined rules.
(Manually) Track Super Admin activity in the Google Admin console
Admin log events can help you review admin activity in the Google Admin console. You can use the audit and investigation page to perform searches related to Admin log events. There you can view a record of actions performed in your Google Admin console, such as when an administrator added a user or turned on a Google Workspace service.
For a full list of services and activities that you can investigate, such as Google Drive or user activity, read through the data sources for the audit and investigation page.
(Programmatically) Analyze and Alert on Super Admin Activity
Step 1. Forward log event data to Google Cloud
You can opt in to share the log event data with Google Cloud. If you turn on sharing, data is forwarded to Cloud Logging, where you can query and view your logs and control how you route and store your logs.
Step 2. Create a Logging Sink at the Organization level
Next, collate and route organization-level logs to a logging sink to a supported destination such as Pub/Sub. Like any sink, your aggregated sink contains a filter that selects individual log entries. For examples of filters that you might use to create your aggregated sink, see Sample queries using the Logs Explorer.
For all Google Admin logs, you can choose a log filter like the below. You can further refine this to ensure only relevant logs are routed to the logging sink.
protoPayload.serviceName="admin.googleapis.com"Step 3. Use PubSub as your Log Destination
Configure a Pub/Sub topic as the destination for log entries that you routed from Cloud Logging sink above. When you route logs to a Pub/Sub topic, Logging publishes each log entry as a Pub/Sub message as soon as Logging receives that log entry. Routed logs are available in near real-time, generally within seconds of their arrival to Logging, with 99% of logs available in less than 60 seconds.
Step 4. (Optional) Send Logs to your SIEM system
We recommend using Pub/Sub for integrating Cloud Logging logs with third-party software such as your SIEM. For details, refer to Export Google Cloud security data to your SIEM system.
On your log analytics tool, you can configure rules that can alert based on events of interest. For example, you can set up alerts that trigger whenever any activities performed by any of your Super Admin accounts are detected from these logs.
Step 5. Create a Cloud Function to Trigger Alerts to a Email or Chat system
Alongside logs exported to your SIEM system, you can create a Cloud Function that subscribes to the same Pub/Sub topic. This Cloud Function gets triggered whenever a log entry is published as a Pub/Sub message.
You can use this Cloud Function to implement any logic that parses the Google Admin logs and triggers an outbound webhook to your email or chat tool — helping you receive instant notifications on any events of interest.
Google Cloud Console (console.cloud.google.com)
Alert on Sensitive Admin Activity Logs
Admin Activity audit logs (ADMIN_WRITE) contain log entries for API calls or other actions that modify the configuration or metadata of resources. For example, these logs record when users create VM instances or change IAM permissions.
Admin Activity audit logs are always written; you can’t configure, exclude, or disable them. Even if you disable the Cloud Logging API, Admin Activity audit logs are still generated.
You should route logs related to Admin Activities to your log analytics tool of choice such as BigQuery or your SIEM. The routing destination, path and complexity vary depending on the analytics tools that you use, as shown in the following diagram.
On your log analytics tool, you can configure rules that can alert based on events of interest. For example, you can set up alerts that trigger whenever any activities are detected on any or all of the following:
- specific services (e.g. storage.googleapis.com)
- specific projects (e.g. logName =~ “^projects/PROJECT_ID”)
- specific resource types (e.g. gcs_bucket)
- specific operations (e.g. storage.buckets.get, storage.buckets.list)
- specific principals (e.g. admin-maria@example.com)
Alert on Discovery Activity Logs
Data Access audit logs contain API calls that read the configuration or metadata of resources, as well as user-driven API calls that create, modify, or read user-provided resource data.
Data Access audit logs — except for BigQuery Data Access audit logs — are disabled by default because audit logs can be quite large. If you want Data Access audit logs to be written for Google Cloud services other than BigQuery, you must explicitly enable them. Enabling the logs might result in your Google Cloud project being charged for the additional logs usage. For instructions on enabling and configuring Data Access audit logs, see Enable Data Access audit logs.
Step 1. Enable Data Access audit logs for Resource Manager API at the Org Level
In order to maximize the value of Data Access audit logs in terms of security visibility while also limiting their cost and management overhead, we recommend that you do the following to filter out low-value, high-volume logs.
Enable Data Access logs (ADMIN_READ) for the Cloud Resource Manager API. These APIs are typically invoked whenever a user tries to access a project or an organization irrespective of whether you are using GCP via the console, api, gcloud, or any of the language SDKs. It offers a cost-effective solution for alerting on any usage of the Super Admin account.
You can enable and configure Data Access audit logs in an organization, which applies to all the existing and new Google Cloud projects and folders in the organization.
Best Practice: Enable Data Access audit logs at the folder or organization level to ensure compliance across all child projects of that folder or organization. When you enable the audit logs at the folder or organization level, the audit policy applies to all existing and new projects in that folder or organization. That audit policy cannot be disabled at the project level.
Step 2. Create a Logging Sink at the Organization level
Next, collate and route organization-level logs to a logging sink to a supported destination such as Pub/Sub. Like any sink, your aggregated sink contains a filter that selects individual log entries. For examples of filters that you might use to create your aggregated sink, see Sample queries using the Logs Explorer.
For collecting all Data Access audit logs, you can choose a log filter like the below. I have further refined this to ensure that only logs relevant to Super Admin users are routed to the logging sink.
gcloud logging sinks create admin-read-activity-sink \
pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID \
- organization=ORG_ID - include-children \
- log-filter='log_id("cloudaudit.googleapis.com/data_access")
AND protoPayload.authenticationInfo.principalEmail="SUPER_ADMIN_EMAIL"'Step 3. Use PubSub as your Log Destination
Configure a Pub/Sub topic as the destination for log entries that you routed from Cloud Logging sink above. When you route logs to a Pub/Sub topic, Logging publishes each log entry as a Pub/Sub message as soon as Logging receives that log entry. Routed logs are available in near real-time, generally within seconds of their arrival to Logging, with 99% of logs available in less than 60 seconds.
Step 4. (Optional) Send Logs to your SIEM system
We recommend using Pub/Sub for integrating Cloud Logging logs with third-party software such as your SIEM. For details, refer to Export Google Cloud security data to your SIEM system.
On your log analytics tool, you can configure rules that can alert based on events of interest. For example, you can set up alerts that trigger whenever any activities performed by any of your Super Admin accounts are detected from these logs.
Step 5. Create a Cloud Function to Trigger Alerts to a Email or Chat system
Alongside logs exported to your SIEM system, you can create a Cloud Function that subscribes to the same Pub/Sub topic. This Cloud Function gets triggered whenever a log entry is published as a Pub/Sub message.
You can use this Cloud Function to implement any logic that parses the Data Access audit logs and triggers an outbound webhook to your email or chat tool — helping you receive instant notifications on any events of interest.
Corrective Measures
Set up multiple super admin accounts
The first and most important step is to ensure your organization has more than one super administrator account, each managed by a separate individual (avoid sharing an admin account). If one account is lost or compromised, another super admin can perform critical tasks while the other account is recovered.
Managing Compromise of Super Admin accounts in Cloud Identity
Now, if and when there is a compromise of a super admin account, you can use the another Super Admin account to take one or more of the following actions:
- Change or reset your password — You can change your password for security reasons or reset it if you forget it.
- Suspend or Delete the compromised account — You can temporarily block a user’s access to your organization’s Google services by suspending their account.
- Account recovery process — The super admin account recovery process will help you recover your account in the event that super admin credentials are lost or compromised.
Other Best Practices
The full list of security best practices related to Super Admin accounts is listed here.
