When tackling challenges with the Google Cloud Platform, it's crucial to adhere to GCP security best practices to construct and host your solution effectively. To create an operational, secure, reliable, performant, and cost-effective solution, fine-tune these settings and implement best practices from the outset, before diving into the design and engineering process.

Google Cloud Platform - Shared Responsibility Model

They provide a variety of offerings and solutions including Infrastructure, as a Service (IaaS) Platform as a Service (PaaS), and Software, as a Service (SaaS). The interaction between users and cloud providers varies depending on the selected service as depicted in the diagram.

‍

In the context of security, public cloud providers, including Google, share a common responsibility. They are obligated to furnish users with a robust and secure infrastructure foundation. Additionally, providers must enable users to comprehend and effectively implement their respective roles within the shared responsibility model.

Google Cloud Platform Security Guidelines

Never use non-corporate accounts, such as personal ones, for business purposes.

‍

Utilize fully managed corporate Google accounts to enhance visibility, auditing, and control over access to GCP resources. Avoid using email accounts external to your organization for business-related activities.

‍

Explore Cloud Identity, a standalone Identity-as-a-Service (IDaaS) offering, to access key identity management features available in Google Workspace. This suite includes secure cloud-native collaboration and productivity applications. The Cloud Identity management layer allows you to enable or disable access to various Google solutions, including GCP, for your organization's members.

‍

Upon signing up for Cloud Identity, a dedicated organizational node is created for your domain. This facilitates mapping your corporate structure and controls GCP resources through the Google Cloud resource hierarchy.

‍

Activating MFA is paramount. Ensure that every user account in your system, particularly administrators, has MFA enabled. Alongside robust passwords, MFA stands out as the most effective measure to secure user accounts and protect against unauthorized access.

‍

With these foundational steps in place, we are now ready to delve into specific GCP security best practices. Since there is so much to this topic, we’ll split this into three parts for easier readability, and convenience.

GCP Security Overview

In this segment, we will guide you through the key GCP services, offering a set of two dozen best practices for each. Aim for optimal Google Cloud Platform security by integrating the Open Source tool Cloud Custodian, a Cloud Security Posture Management (CSPM) solution. CSPM tools assess your cloud configuration, pinpoint common configuration errors, and actively monitor cloud logs to identify threats and changes in configuration.

‍

Now, let's proceed with a detailed exploration of each GCP service, outlining specific best practices tailored to enhance security.

Identity and Access Management (IAM)

The IAM feature of Google Cloud Platform (GCP) is vital, for managing controlled access, to your resources ensuring that the principle of privilege is followed. IAM enables you to control the authentication (logging in) and authorization (granting permissions) of individuals who utilize your resources.

Here are some recommended security practices for IAM within GCP:

1. Review Your IAM Policies for Personal Email Accounts

For every Google Cloud Platform project, enumerate the accounts that have been provided access to that specific project:

<pre class="codeWrap"><code>gcloud projects get-iam-policy PROJECT_ID</code></pre>

Additionally, document the accounts added within each folder:

<pre class="codeWrap"><code>gcloud resource-manager folders get-iam-policy FOLDER_ID</code></pre>

Furthermore, document your organization's IAM policy:

<pre class="codeWrap"><code>gcloud organizations get-iam-policy ORGANIZATION_ID</code></pre>

It is imperative that IAM policies refrain from granting permissions to email accounts outside the organization's domain. This exemption applies to Google-owned service accounts.

‍

By default, email addresses beyond the organization's domain do not possess access to its Google Cloud deployments. However, any user email account can be incorporated into the IAM policy for Google Cloud Platform projects, folders, or organizations. To counteract this, activate Domain Restricted Sharing within the organization policy:

<pre class="codeWrap"><code>gcloud resource-manager org-policies allow --organization=ORGANIZATION_ID iam.allowedPolicyMemberDomains=DOMAIN_ID</code></pre>

‍

The following Cloud Custodian rule can be employed to identify the utilization of personal accounts:

<pre class="codeWrap"><code>- name: personal-emails-used
 description: |
   Use corporate login credentials instead of personal accounts,
   such as Gmail accounts.
 resource: gcp.project
 filters:
  - type: iam-policy
     key: "bindings[].members[]"
     op: contains-regex
     value: .+@(?!organization.com|.+gserviceaccount.com)(.+.com)</code></pre>

2. Verify Multi-Factor Authentication (MFA) Activation for All User Accounts

Multi-factor authentication refers to the practice of employing methods to confirm a user's identity. This serves as a security measure to safeguard against threats that could take advantage of compromised or vulnerable credentials. It's important to note that multi-factor authentication is not enabled by default.

‍

Ensure that, for every Google Cloud Platform project, folder, or organization, the multi-factor authentication is activated for each account. If it is not already set up, take the necessary steps to enable it.

3. Guarantee Implementation of Security Key Enforcement for Admin Accounts

Users in GCP assigned the Organization Administrator roles hold the utmost privilege within the organization.

‍

These accounts require the highest level of protection through the most robust form of two-factor authentication: Security Key Enforcement. Ensure that administrators utilize Security Keys for authentication rather than less secure second factors like SMS or one-time passwords (OTP). Security Keys are tangible physical devices employed to access Google Organization Administrator Accounts. They transmit an encrypted signature instead of a code, enhancing resistance to phishing attempts.

‍

Identify users possessing Organization Administrator privileges:

<pre class="codeWrap"><code>gcloud organizations get-iam-policy ORGANIZATION_ID</code></pre>

Inspect members granted the role "roles/resourcemanager.organizationAdmin" and manually verify that Security Key Enforcement has been activated for each account. If not enabled, treat it seriously and enable it promptly. By default, Security Key Enforcement is not turned on for Organization Administrators.

‍

In the event an organization administrator loses access to their security key, it could result in an inability to access their account. To address this, configuring backup security keys is crucial.

4. Prohibit the Utilization of User-Managed Service Account Keys

Access to service account keys grants individuals the ability to reach resources through the respective service account. GCP-managed keys are employed by Cloud Platform services like App Engine and Compute Engine. These keys remain inaccessible for download, as Google retains and automatically rotates them nearly every week.

‍

In contrast, user-managed keys are generated, downloaded, and overseen by the user, persisting for a period of 10 years from their creation.

‍

User-managed keys are susceptible to compromise due to common development practices, such as inadvertent exposure in source code, retention in the downloads directory, or unintentional disclosure on support blogs or channels.

‍

Enumerate all service accounts:

<pre class="codeWrap"><code>gcloud iam service-accounts list</code></pre>

Identify user-managed service accounts by noting that their account emails conclude with

iam.gserviceaccount.com.

‍

For each user-managed service account, compile a list of keys managed by the user:

<pre class="codeWrap"><code>gcloud iam service-accounts keys list --iam-account=SERVICE_ACCOUNT --managed-by=user</code></pre>

‍

No keys should be present in the list. If any keys appear, it is imperative to delete them:

<pre class="codeWrap"><code>gcloud iam service-accounts keys delete --iam-account=SERVICE_ACCOUNT KEY_ID</code></pre>

Please note that deleting user-managed service account keys could potentially disrupt communication with applications relying on these keys. To preemptively address this, consider disabling the creation of service account keys.

‍

Additional GCP security IAM best practices encompass:

1. Service accounts should not be granted Admin privileges.

2. At the project level, IAM users should not be assigned the Service Account User or Service Account Token Creator roles.

3. If permitted (as mentioned in point #4), user-managed/external keys for service accounts should undergo rotation every 90 days or sooner.

4. Adhere to the separation of duties when assigning service account-related roles to users.

5. Similarly, enforce separation of duties when assigning KMS-related roles to users.

6. Refrain from creating API keys for a project.

7. If API keys are essential, restrict them for use only by specified Hosts and Apps.

8. Limit API keys to the specific APIs that the application requires access to.

9. Ensure that API keys are rotated every 90 days or sooner.

Key Management Service (KMS) Overview

Google Cloud Key Management Service (KMS) is a solution that allows users to manage both asymmetric encryption keys in the cloud. It provides a mechanism to handle these keys for your cloud services, mirroring practices employed on-premises. KMS enables the creation, utilization, rotation, and destruction of encryption keys, including AES 256, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 keys.

Critical Google Cloud Platform Security Best Practices for KMS:

5. Verify for Anonymously or Publicly Accessible Cloud KMS Keys

Granting permissions to allUsers or allAuthenticatedUsers can lead to unauthorized access to the dataset, posing a risk, especially when sensitive data is stored in that location.

‍

Ensure that access to a Cloud KMS encryption key is not permitted for anonymous and/or public users. By default, Cloud KMS restricts access to allUsers or allAuthenticatedUsers.

‍

Enumerate all Cloud KMS keys:

<pre class="codeWrap"><code>gcloud kms keys list --keyring=KEY_RING_NAME --location=global --format=json | jq '.
[].name'</code></pre>

‍

To eliminate access for allUsers and allAuthenticatedUsers, remove the IAM policy binding for a specific KMS key:

<pre class="codeWrap"><code>gcloud kms keys remove-iam-policy-binding KEY_NAME --keyring=KEY_RING_NAME --
location=global --member=allUsers --role=ROLE
gcloud kms keys remove-iam-policy-binding KEY_NAME --keyring=KEY_RING_NAME --
location=global --member=allAuthenticatedUsers --role=ROLE</code></pre>

‍

The following Cloud Custodian rule identifies the presence of anonymously or publicly accessible Cloud KMS keys:

<pre class="codeWrap"><code>- name: anonymously-or-publicly-accessible-cloud-kms-keys
  description: |
    It is recommended that the IAM policy on Cloud KMS cryptokeys should
    restrict anonymous and/or public access.
  resource: gcp.kms-cryptokey
  filters:
   - type: iam-policy
      key: "bindings[*].members[]"
      op: intersect
      value: ["allUsers", "allAuthenticatedUsers"]

</code></pre>

6. Confirm Regular Rotation of KMS Encryption Keys Every 90 Days or Sooner

Encryption keys are designed with a defined rotation period, representing the time required for the automatic generation of a new key version. Since a key safeguard a set of data, multiple files can be encrypted using the same key. Users possessing decryption rights for that key can then decrypt those files. Consequently, it is crucial to ensure that the rotation period is configured to a specific duration.

‍

A recommended GCP security practice is to establish a rotation period of 90 days or less:

<pre class="codeWrap"><code>gcloud kms keys update new --keyring=KEY_RING --location=LOCATION --rotation-period=90d</code></pre>

By default, KMS encryption keys undergo rotation every 90 days. If you have not altered this setting, your configuration is secure.

Cloud Storage Overview

Google Cloud Storage provides a platform for storing diverse volumes of data organized into containers known as "buckets." Given that these buckets hold valuable data, they become attractive targets for potential attackers. Consequently, it is essential to implement robust security measures to safeguard your information.

Here are some key GCP security best practices to enforce:

7. Verify Non-Exposure of Cloud Storage Buckets to Anonymous or Public Access

Granting anonymous or public access provides unrestricted permission to anyone seeking to access the content within a bucket. This approach is not recommended, especially when dealing with sensitive data. It is essential to confirm that anonymous or public access to the bucket is restricted.

‍

Enumerate all buckets in a project:

<pre class="codeWrap"><code>gsutil ls</code></pre>

‍

Inspect the IAM Policy for each bucket obtained from the above command:

<pre class="codeWrap"><code>gsutil iam get gs://BUCKET_NAME</code></pre>

‍

Ensure that no role includes allUsers or allAuthenticatedUsers as a member. If any such instances are identified, take action to remove them:

<pre class="codeWrap"><code>gsutil iam ch -d allUsers gs://BUCKET_NAME
gsutil iam ch -d allAuthenticatedUsers gs://BUCKET_NAME</code></pre>

Additionally, consider implementing preventive measures to restrict Storage buckets from becoming publicly accessible by configuring the Domain Restricted Sharing organization policy.

8. Confirm Activation of Uniform Bucket-Level Access for Cloud Storage Buckets

Cloud Storage provides two systems for granting permissions: Cloud Identity and Access Management (Cloud IAM) and Access Control Lists (ACL). Both systems operate concurrently, with either granting permissions allowing users to access the cloud storage resource.

‍

Cloud IAM, used across Google Cloud, offers varied permissions at both the bucket and project levels. In contrast, ACLs, specific to Cloud Storage, provide limited permission options but allow for per-object permission granularity.

‍

Enabling uniform bucket-level access deactivates ACLs on all Cloud Storage resources (buckets and objects), exclusively permitting access through Cloud IAM. This feature simplifies and consolidates access-granting mechanisms and ensures that if a Storage bucket is not publicly accessible, no object within it is publicly accessible.

‍

Enumerate all buckets in a project:

<pre class="codeWrap"><code>gsutil ls</code></pre>

‍

Check whether uniform bucket-level access is enabled for each bucket obtained from the above command:

<pre class="codeWrap"><code>gsutil uniformbucketlevelaccess get gs://BUCKET_NAME/</code></pre>

‍

If uniform bucket-level access is enabled, the response should resemble the following:

<pre class="codeWrap"><code>Uniform bucket-level access setting for gs://BUCKET_NAME/:
   Enabled: True
   LockedTime: LOCK_DATE</code></pre>

‍

If it's not enabled for a bucket, activate it using:

<pre class="codeWrap"><code>gsutil uniformbucketlevelaccess set on gs://BUCKET_NAME/</code></pre>

‍

You can also establish an Organization Policy to mandate uniform bucket-level access for any new bucket. The following Cloud Custodian rule identifies buckets lacking uniform access:

<pre class="codeWrap"><code>- name: check-uniform-access-in-buckets
  description: |
    It is recommended that uniform bucket-level access is enabled on
    Cloud Storage buckets.
  resource: gcp.bucket
  filters:
    - not:
     - type: value
        key: "iamConfiguration.uniformBucketLevelAccess.enabled"
        value: true
</code></pre>