You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider removing or updating 6.1, given the information here under "Motivation and context."
Motivation and context
The current policy:
All highly privileged accounts SHALL leverage Google Account authentication with phishing-resistant MFA and not the agency's authoritative on-premises or federated identity system.
The roles considered "highly privileged" are defined here.
Of those roles, the most important is super admin. However, Google Workspace does not allow you to create a super admin that uses a third-party identity provider. The question is, are the other roles important enough to keep this policy in?
Additionally, a role-based definition of highly privileged accounts has the potential to miss quite a few privileged accounts, given that you can create custom roles. A privilege-based definition might be more appropriate.
For example, a list of highly-privileged privileges probably should include the User Security Management privilege, which among other things, allows you to disable MFA org-wide.
Implementation notes
N/A
Acceptance criteria
Decide if we want to keep this policy
Decide if we want to update it from a role-based definition to a privilege-based definition
The text was updated successfully, but these errors were encountered:
💡 Summary
Consider removing or updating 6.1, given the information here under "Motivation and context."
Motivation and context
The current policy:
The roles considered "highly privileged" are defined here.
Of those roles, the most important is super admin. However, Google Workspace does not allow you to create a super admin that uses a third-party identity provider. The question is, are the other roles important enough to keep this policy in?
Additionally, a role-based definition of highly privileged accounts has the potential to miss quite a few privileged accounts, given that you can create custom roles. A privilege-based definition might be more appropriate.
For example, a list of highly-privileged privileges probably should include the User Security Management privilege, which among other things, allows you to disable MFA org-wide.
Implementation notes
N/A
Acceptance criteria
The text was updated successfully, but these errors were encountered: