Description
Allowing a personal Gmail account to access business resources can leave permissions outside organizational onboarding, departure and access-removal processes. Check who holds each permission and who actually manages the account.
An address in a corporate domain is not necessarily an organization-managed account. For approved external users, define a sponsor, purpose and end date, and grant only required permissions.
Potential impact
- Access for departing staff or external users can remain longer than intended.
- Compromise of a personal account can expose the business permissions granted to it.
Remediation
- Review IAM members and actual account management, then revoke unapproved access. Move required human access to managed accounts or an approved external-user process.
- Apply MFA and periodic access reviews, and remove access when it ends. Manage least privilege and lifecycle for system identities separately.
Examples
These policy excerpts use the historical Deployment Manager format, whose support has ended. Other resource-creation settings are omitted; replace the addresses with actual approved principals.
Before
yaml
resources:
- name: a-new-pubsub-topic
type: pubsub.v1.topic
accessControl:
gcpIamPolicy:
bindings:
- role: roles/pubsub.publisher
members:
- "user:jane@gmail.com"
- "serviceAccount:my-other-app@appspot.gserviceaccount.com"
After
yaml
resources:
- name: a-new-pubsub-topic
type: pubsub.v1.topic
accessControl:
gcpIamPolicy:
bindings:
- role: roles/pubsub.publisher
members:
- "user:jane@example.com"
- "serviceAccount:my-other-app@appspot.gserviceaccount.com"
Explanation:
- Before: A Gmail user and a service account receive publishing permission. Check the business need and management of both identities.
- After: Only the user's address domain changes. That change does not establish organizational management or reliable access removal.