Description
Giving business permissions to personal accounts outside organizational management can make revocation and consistent authentication policy harder. An email domain alone does not establish management or MFA, and approved external collaborators can be legitimate.
Potential impact
- Permissions can remain after employment or collaboration ends.
- Authentication and recovery procedures that do not meet organizational requirements can complicate incident response.
Remediation
- Prefer organization-managed work accounts and verify lifecycle, MFA and recovery policies. Assign owners and expiry or review procedures for external accounts.
- Grant only necessary roles and remove unneeded members. After replacing accounts or groups, verify required access and revocation of old grants.
Examples
Replace the project and email with approved values. An example.com address does not itself prove organizational management, and roles/editor remains broad. Preserve other required members of the role managed by this binding.
Before
hcl
resource "google_project_iam_binding" "example" {
project = "your-project-id"
role = "roles/editor"
members = [
"user:jane@gmail.com",
]
}
After
hcl
resource "google_project_iam_binding" "example" {
project = "your-project-id"
role = "roles/editor"
members = [
"user:jane@example.com",
]
}
Explanation:
- Before: A user with a personal email domain receives the Editor role. Check which management policies actually apply.
- After: The email domain changes. This does not itself ensure organizational management, authentication controls or minimum role scope.