Skip to main content

🛡️ Consumer Google Accounts are used🟢⚪

Similar Policies​

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-z-79f4ab881

Description​

Open File

Description​

Use corporate login credentials instead of consumer accounts, such as Gmail accounts.

Rationale​

It is recommended fully-managed corporate Google accounts be used for increased visibility, auditing, and controlling access to Cloud Platform resources. Email accounts based outside of the user's organization, such as consumer accounts, should not be used for business purposes.

Impact​

There will be increased overhead as maintaining accounts will now be required. For smaller organizations, this will not be an issue, but will balloon with size.

Audit​

For each Google Cloud Platform project, list the accounts that have been granted access to that project:

From Google Cloud CLI​
 gcloud projects get-iam-policy PROJECT_ID

Also list the accounts added on each folder:

 gcloud resource-manager folders get-iam-policy FOLDER_ID

And list your organization's IAM policy:

 gcloud organizations get-iam-policy ORGANIZATION_ID

No email accounts outside the organization domain should be granted permissions in the IAM policies. This excludes Google-owned service accounts.

... see more

Remediation​

Open File

Remediation​

Remove all consumer Google accounts from IAM policies. Follow the documentation and setup corporate login accounts.

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 CIS GCP v1.1.0 → 💼 1.1 Ensure that corporate login credentials are used11no data
💼 CIS GCP v1.2.0 → 💼 1.1 Ensure that corporate login credentials are used - Level 1 (Automated)11no data
💼 CIS GCP v1.3.0 → 💼 1.1 Ensure that Corporate Login Credentials are Used - Level 1 (Manual)11no data
💼 CIS GCP v2.0.0 → 💼 1.1 Ensure that Corporate Login Credentials are Used - Level 1 (Manual)1no data
💼 CIS GCP v3.0.0 → 💼 1.1 Ensure that Corporate Login Credentials are Used - Level 1 (Manual)1no data
💼 Cloudaware Framework → 💼 Credential Lifecycle Management18no data
💼 FedRAMP High Security Controls → 💼 IA-2 Identification and Authentication (Organizational Users) (L)(M)(H)614no data
💼 FedRAMP High Security Controls → 💼 IA-4 Identifier Management (L)(M)(H)111no data
💼 FedRAMP High Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)61432no data
💼 FedRAMP Low Security Controls → 💼 IA-4 Identifier Management (L)(M)(H)1no data
💼 FedRAMP Low Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)132no data
💼 FedRAMP Moderate Security Controls → 💼 IA-2 Identification and Authentication (Organizational Users) (L)(M)(H)64no data
💼 FedRAMP Moderate Security Controls → 💼 IA-4 Identifier Management (L)(M)(H)11no data
💼 FedRAMP Moderate Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)432no data
💼 ISO/IEC 27001:2013 → 💼 A.9.2.1 User registration and de-registration11no data
💼 ISO/IEC 27001:2013 → 💼 A.9.2.3 Management of privileged access rights312no data
💼 NIST CSF v1.1 → 💼 PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes1934no data
💼 NIST CSF v1.1 → 💼 PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties1756no data
💼 NIST CSF v1.1 → 💼 PR.AC-6: Identities are proofed and bound to credentials and asserted in interactions413no data
💼 NIST CSF v1.1 → 💼 PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals' security and privacy risks and other organizational risks)1923no data
💼 NIST CSF v1.1 → 💼 PR.DS-5: Protections against data leaks are implemented4791no data
💼 NIST CSF v1.1 → 💼 PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities2130no data
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization42no data
💼 NIST CSF v2.0 → 💼 PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions13no data
💼 NIST CSF v2.0 → 💼 PR.AA-03: Users, services, and hardware are authenticated53no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties116no data
💼 NIST CSF v2.0 → 💼 PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected148no data
💼 NIST CSF v2.0 → 💼 PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected125no data
💼 NIST CSF v2.0 → 💼 PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected142no data
💼 NIST SP 800-53 Revision 4 → 💼 AC-3 ACCESS ENFORCEMENT102no data
💼 PCI DSS v3.2.1 → 💼 7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.5no data
💼 PCI DSS v3.2.1 → 💼 7.1.3 Assign access based on individual personnel's job classification and function.5no data
💼 PCI DSS v3.2.1 → 💼 8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.22no data
💼 PCI DSS v4.0.1 → 💼 7.2.2 Access is assigned to users, including privileged users, based on job classification, function, and least privileges.5no data
💼 PCI DSS v4.0.1 → 💼 8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.2no data
💼 PCI DSS v4.0 → 💼 7.2.2 Access is assigned to users, including privileged users, based on job classification, function, and least privileges.5no data
💼 PCI DSS v4.0 → 💼 8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.2no data
💼 SOC 2 → 💼 CC6.1-4 Identifies and Authenticates Users46no data
💼 SOC 2 → 💼 CC6.1-9 Manages Credentials for Infrastructure and Software34no data