Google Workspace

Proofroom reads Google Workspace’s Admin SDK as a service account that acts for one of your administrators through domain-wide delegation, with read-only scopes, and files five kinds of evidence. Add it on Integrations → Catalogue → Google Workspace → Connect.

What each collector shows

Collector	Kind	Default cadence	What it shows	Suggested controls
Users with MFA status	snapshot	quarterly	Every active user, whether they are an administrator, whether they are enrolled in 2-Step Verification, and whether their organisational unit enforces it.	PCI DSS 8.4.2, 8.4.3; SOC 2 CC6.1
Admin and privileged roles	snapshot	quarterly	Every admin role assignment: the role (Super Admin, Help Desk Admin, your custom roles), the user or group holding it, and its scope. A group holding a role is named by its email, and each of its members (members of nested groups too) gets a row of its own naming the group.	PCI DSS 7.2.1, 7.2.2, 7.2.4; SOC 2 CC6.2, CC6.3
Leaver removals	window	quarterly	Users suspended, deleted or archived in the window, from the Admin audit log, with the administrator who did it and Google’s event status when it gives one. With a People directory source, each leaver’s removal is measured against their leave date (leaver lag).	PCI DSS 8.2.5; SOC 2 CC6.2
Inactive accounts	snapshot	quarterly	Every account that can sign in or be restored (suspended and archived ones labelled), with its creation date and last sign-in, and those with no sign-in for more than 90 days.	PCI DSS 8.2.6; SOC 2 CC6.2
MFA enforcement	snapshot	quarterly	Whether 2-Step Verification is enforced in each organisational unit, and the gaps: units where it is off, active users and administrators it is not enforced for, and users enforced but not yet enrolled.	PCI DSS 8.4.1, 8.4.2, 8.4.3; SOC 2 CC6.1

Set up

In the Google Cloud console, create a project (or use one), enable the Admin SDK API, and create a service account. Under Keys, add a JSON key and download it.
Note the service account’s client ID (on its details page; it is also client_id in the key file).
In the Google Admin console, go to Security → Access and data control → API controls → Manage Domain Wide Delegation → Add new, enter the client ID, and authorise exactly these scopes:
- https://www.googleapis.com/auth/admin.directory.user.readonly
- https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly
- https://www.googleapis.com/auth/admin.reports.audit.readonly
Only if a group holds an admin role, also authorise https://www.googleapis.com/auth/admin.directory.group.readonly for the same client ID (edit the entry and add it to the list). Proofroom asks for it with a token of its own, only when a role assignment names a group, so a set-up without it keeps working; if a group holds a role and the scope is missing, Admin and privileged roles fails and says to add it. It is the least scope that reads both a group’s name and email and its members.
Choose the administrator Proofroom acts as. Google lets only super administrators list admin roles and see other administrators’ 2-Step Verification, so use a super administrator. The scopes keep every call read-only.

Delegation changes can take up to 24 hours to apply. Proofroom never writes to Google Workspace.

If Google will not create the key

Organizations created on or after 3 May 2024 block service-account key creation by default with an organization policy, so Add key fails with “Service account key creation is disabled”. Two constraints can do this; check both and change whichever is enforced:

iam.managed.disableServiceAccountKeyCreation (the newer managed constraint, which new organizations get), and
iam.disableServiceAccountKeyCreation (the older one).

Allow keys for the service account’s own project only, not the whole organization:

Someone with Organization Policy Administrator (roles/orgpolicy.policyAdmin) on the organization signs in to the Google Cloud console and picks the service account’s project in the project picker.
Go to IAM & Admin → Organization policies, open the constraint (search “Disable service account key creation”), click Manage policy, choose Override parent’s policy, add a rule with enforcement Off, and save. Do not change the policy on the organization itself.
Create the JSON key (step 1 above).
Optional: put the policy back by choosing Inherit parent’s policy on the project, or run gcloud org-policies delete <CONSTRAINT> --project=<PROJECT_ID>. Keys made while it was off keep working; the policy only stops new keys.

The same with gcloud, for the project only:

# The older constraint:
gcloud resource-manager org-policies disable-enforce iam.disableServiceAccountKeyCreation --project=<PROJECT_ID>
# The managed constraint: write policy.yaml, then apply it.
cat > policy.yaml <<'YAML'
name: projects/<PROJECT_ID>/policies/iam.managed.disableServiceAccountKeyCreation
spec:
  rules:
  - enforce: false
YAML
gcloud org-policies set-policy policy.yaml

Signing in without a key (Workload Identity Federation) is planned for a later release.

Connect

Field	Value
Service account key	The whole JSON key file, pasted
Administrator email	The administrator from step 5
Customer	`my_customer` (the default)

Test connection signs in and, if Google refuses, says which client ID and scopes to authorise; then it calls users, admin roles and the admin audit log and names any that is refused.

How each new reading works

Inactive accounts reads each user’s lastLoginTime and creationTime from the users list. Google gives an account that has never signed in the date 1 January 1970; Proofroom reads that as “never” (UNVERIFIED: administrators report it, Google’s reference does not say). Google says its last sign-in data can lag by a few hours up to 3 days.
MFA enforcement has no policy to read with these scopes. Each organisational unit becomes one rule, read from its active users’ isEnforcedIn2Sv: every user enforced shows the unit as enforced; none shows it as off; some shows it as enforced for part of the unit (enforcement can be set for a group too) with the others listed as excluded. The allowed 2-Step Verification methods (for example whether text-message codes are allowed) are not read. Google does not say whether isEnforcedIn2Sv reflects enforcement set by group as well as by unit (UNVERIFIED). A user with enforcement on but not yet enrolled (isEnforcedIn2Sv true, isEnrolledIn2Sv false — usually a new user in the enrolment period) can still sign in with a password until the period ends, so they are listed as a gap and MFA is not shown as required for everyone. Proofroom counts MFA as required for administrators only when every active administrator is both enforced and enrolled. A possible later source is Google’s Cloud Identity Policy API (policies.list, scope https://www.googleapis.com/auth/cloud-identity.policies.readonly), which exposes the security.two_step_verification_enforcement and security.two_step_verification_enforcement_factor settings per unit and group. Proofroom does not use it yet.
Group members come from groups/{group}/members with includeDerivedMembership=true; nested groups found in the list are read too, and each person is listed once. Google notes a nested group’s members can take up to 10 minutes to appear.
Leaver removals fills the outcome from the event’s status when Google gives one; Google says not all events have a status (UNVERIFIED whether user suspensions and deletions carry one).

Credential expiry

Proofroom reads when the service account key was made from Google’s public certificate list for the service account (https://www.googleapis.com/service_accounts/v1/metadata/x509/<service account email>), which needs no sign-in or permission. The certificate for the key in use gives its creation date: the key never expires, so Proofroom asks for it to be replaced a year after it was made. If an organisation policy (iam.serviceAccountKeyExpiryHours) gives keys an expiry, that date is shown instead. The certificate’s dates are taken to be the key’s own (UNVERIFIED: Google’s documentation does not say so). The integration page shows it as “Service account key” and the first 8 characters of the key ID.

Known limits

The admin audit log returns the last 180 days.