This chapter covers data security in Google Cloud, focusing on encryption mechanisms and access controls. You will learn about encryption at rest, in transit, and the key management options: Google-managed, customer-managed (CMEK), and customer-supplied (CSEK). We also dive into Identity and Access Management (IAM) roles, policies, and the principle of least privilege. For the GCDL exam, this topic area comprises approximately 15-20% of questions, often testing your ability to choose the right encryption method for compliance requirements and to understand IAM hierarchy and policy inheritance. Expect scenario-based questions where you must recommend the appropriate security controls.
Jump to a section
Data encryption and access controls in Google Cloud are like a bank vault system with multiple layers. The vault itself is the encryption at rest, where data is stored in a secure safe. Each customer has a unique safety deposit box (a Cloud Storage bucket or BigQuery table) that is locked with a key managed by Google's Key Management Service (KMS). However, even if you have the key, you must also pass through the bank's security checkpoints (Identity and Access Management, IAM). The security guard checks your ID (authentication) and your authorization level (roles like Viewer, Editor, or Owner). For example, a bank teller can only access the lobby (Viewer role), while a manager can access the vault (Editor role). The bank also has a special protocol for sensitive transactions: Customer-Managed Encryption Keys (CMEK) allow the customer to bring their own key to lock their box, but Google still holds the physical vault key. For the highest security, Customer-Supplied Encryption Keys (CSEK) let the customer provide the key each time they access the box, and Google never stores it. This mechanistic analogy shows that encryption protects data at rest and in transit, while access controls determine who can use those keys and data.
What is Data Security in Google Cloud?
Data security in Google Cloud encompasses two primary pillars: encryption and access controls. Encryption ensures that data is unreadable without the correct key, both when stored (at rest) and when transmitted (in transit). Access controls determine who or what can perform actions on resources. Together, they form a defense-in-depth strategy.
Encryption at Rest
Encryption at rest protects data stored on disk, in databases, or in object storage. Google Cloud automatically encrypts all customer data at rest using AES-256 (Advanced Encryption Standard with 256-bit keys). This encryption is applied by default to all Google Cloud services, including Compute Engine persistent disks, Cloud Storage objects, BigQuery tables, and Cloud SQL instances. The encryption key hierarchy consists of: - Data Encryption Keys (DEKs): Used to encrypt individual data chunks. - Key Encryption Keys (KEKs): Used to encrypt the DEKs. KEKs are stored in Cloud KMS. - Key Encryption Keys for KEKs (optional): In CMEK, customers can manage the KEK themselves.
Google manages the root keys (key encryption keys for the KEKs) in a hardware security module (HSM) that is FIPS 140-2 Level 3 certified. The encryption is transparent to users; no configuration is required.
Encryption in Transit
Encryption in transit protects data as it moves between a user's device and Google Cloud, or between Google Cloud services. Google Cloud uses TLS (Transport Layer Security) 1.2 or higher by default for all external communications. For internal traffic between Google data centers, data is encrypted at the link layer using MACsec (IEEE 802.1AE) or at the application layer using ALTS (Application Layer Transport Security). ALTS is a mutual authentication and encryption protocol developed by Google. It is used for all Google Cloud service-to-service communication, including between VMs on the same network.
Key Management Options
Google Cloud offers three levels of encryption key management:
1. Google-managed encryption keys: Default. Google creates, rotates, and manages the keys. No customer involvement. Suitable for most workloads with no specific compliance requirements.
2. Customer-managed encryption keys (CMEK): Customers create and manage their own key rings and keys in Cloud KMS. Google still performs encryption/decryption, but the KEK is under customer control. Benefits: compliance with regulations that require separation of key management from the cloud provider. You can enable key rotation (default 90 days for automatically rotated keys). Keys can be disabled or destroyed, which will make data permanently inaccessible.
3. Customer-supplied encryption keys (CSEK): Customers provide their own encryption keys for each API call. Google does not store the key; it is used on-the-fly and then discarded. Only supported for Compute Engine and Cloud Storage. Not recommended for most use cases due to operational overhead and risk of key loss.
Identity and Access Management (IAM)
IAM defines who (identity) has what access (role) to which resource. The core components:
- Principal: The identity (user, group, service account, or Google Workspace domain). - Role: A collection of permissions. There are three types: - Primitive roles: Owner, Editor, Viewer. Broad and not recommended for production. - Predefined roles: Fine-grained roles created by Google, e.g., roles/storage.objectViewer. - Custom roles: User-defined roles with a specific set of permissions. - Policy: A binding that attaches a role to a principal for a specific resource. Policies are inherited from parent to child resources (organization -> folder -> project -> resource).
IAM Hierarchy and Inheritance
IAM policies are hierarchical. At the top is the organization node, which can have folders, which contain projects, which contain resources (e.g., Compute Engine instances, Cloud Storage buckets). A policy set at the organization level applies to all folders, projects, and resources underneath. A policy at the folder level applies to all projects and resources in that folder. The most specific policy overrides less specific ones. However, if a policy includes a DENY rule (using deny policies, a feature of IAM Conditions), it takes precedence over ALLOW.
IAM Conditions
IAM Conditions allow you to define conditional, attribute-based access control. For example, you can grant a role only if the request comes from a specific IP address range, or only during business hours. Conditions are written in Common Expression Language (CEL). Example: request.time < timestamp("2025-01-01T00:00:00Z").
Service Accounts
Service accounts are special Google accounts that represent non-human users, such as applications or VMs. They are used for programmatic access. For example, a Compute Engine instance can be assigned a service account that has permissions to access Cloud Storage. Service accounts can be managed similarly to user accounts with IAM roles. They can also be used for authentication between services using OAuth 2.0.
Encryption and Access Controls in Specific Services
Cloud Storage: Objects are encrypted at rest by default. You can specify a CMEK or CSEK when creating a bucket. Access is controlled via IAM (at the bucket level) and Access Control Lists (ACLs) (at the object level). ACLs are legacy and not recommended; use IAM exclusively.
Compute Engine: Persistent disks are encrypted at rest by default. You can attach a CMEK key to a disk. Access to instances and disks is controlled via IAM. SSH keys can also be used for login.
BigQuery: Tables are encrypted at rest. You can use CMEK to encrypt tables. Access is controlled via IAM (dataset-level, table-level) and authorized views.
Best Practices
Use the principle of least privilege: grant only the permissions needed.
Use predefined roles over primitive roles.
Use IAM Conditions to restrict access based on context.
Use service accounts for applications, not user credentials.
Enable key rotation for CMEK.
For highly sensitive data, consider CSEK but be aware of the operational burden.
Verification Commands
To view IAM policies:
gcloud projects get-iam-policy PROJECT_ID
gcloud storage buckets get-iam-policy gs://BUCKET_NAMETo create a CMEK key:
gcloud kms keyrings create KEY_RING --location=global
gcloud kms keys create KEY_NAME --location=global --keyring=KEY_RING --purpose=encryption
gcloud kms keys set-iam-policy KEY_NAME policy.jsonTo use CMEK with a Cloud Storage bucket:
gcloud storage buckets create gs://BUCKET_NAME --default-encryption-key=projects/PROJECT_ID/locations/global/keyRings/KEY_RING/cryptoKeys/KEY_NAMEEncrypt Data at Rest with CMEK
1. Create a key ring in Cloud KMS with a specific location (e.g., global or regional). 2. Create a symmetric encryption key inside the key ring. 3. Grant the Cloud KMS CryptoKey Encrypter/Decrypter role to the service account that will use the key. 4. When creating a resource (e.g., a Cloud Storage bucket or Compute Engine disk), specify the CMEK key. Google Cloud uses this key as the KEK to encrypt the DEK. The DEK is then used to encrypt the data. The encrypted DEK is stored alongside the data. 5. When accessing the data, Google Cloud uses the KEK (CMEK) to decrypt the DEK, then uses the DEK to decrypt the data. If the CMEK key is disabled or destroyed, the data becomes permanently inaccessible.
Create an IAM Policy with Conditions
1. Identify the principal (user or service account) and the role to assign. 2. Write a condition in CEL. For example: `request.time < timestamp("2025-12-31T23:59:59Z")`. 3. Use the gcloud command: `gcloud projects add-iam-policy-binding PROJECT_ID --member=user:email@example.com --role=roles/storage.objectViewer --condition=expression='request.time < timestamp("2025-12-31T23:59:59Z")',title=expiry,description=Expires at end of 2025`. 4. The condition is evaluated at access time. If the condition evaluates to false, the permission is denied even if the role is bound.
Rotate a CMEK Key
1. Cloud KMS supports automatic rotation with a configurable period. 2. To set rotation: `gcloud kms keys update KEY_NAME --location=global --keyring=KEY_RING --rotation-period=90d --next-rotation-time=2025-01-01T00:00:00Z`. 3. When a key is rotated, a new key version is created. Old data encrypted with the previous key version remains accessible because the old version is still available. 4. You can disable or destroy old key versions to prevent decryption of old data. 5. Best practice: rotate keys periodically (e.g., every 90 days) to limit the impact of a compromised key.
Grant Access to a Service Account
1. Create a service account: `gcloud iam service-accounts create SA_NAME --display-name="My Service Account"`. 2. Grant the service account a role on a resource: `gcloud projects add-iam-policy-binding PROJECT_ID --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com --role=roles/bigquery.dataViewer`. 3. To use the service account on a Compute Engine instance, create the instance with the service account: `gcloud compute instances create INSTANCE_NAME --service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com --scopes=bigquery`. 4. The instance can now authenticate to BigQuery using the service account's credentials without needing user passwords.
Use a Customer-Supplied Encryption Key
1. Generate a 256-bit AES key locally (e.g., using OpenSSL: `openssl rand -base64 32`). 2. When uploading an object to Cloud Storage, provide the key in the request: `gcloud storage cp file.txt gs://BUCKET_NAME --encryption-key=ENCODED_KEY`. 3. Google Cloud uses the key directly to encrypt the object. The key is not stored; it is used in memory and discarded. 4. To download the object, you must provide the same key: `gcloud storage cp gs://BUCKET_NAME/file.txt . --decryption-key=ENCODED_KEY`. 5. If the key is lost, the data is irrecoverable. This method is suitable for compliance scenarios where key storage by the provider is not allowed.
Scenario 1: Healthcare Compliance (HIPAA) A healthcare organization stores patient records in Cloud Storage and BigQuery. They need to comply with HIPAA, which requires encryption and the ability to manage keys separately from the cloud provider. They choose CMEK for both services. They create a key ring in Cloud KMS in the us-central1 region to keep keys close to data. They set automatic rotation every 90 days. They grant the Cloud Storage service agent and BigQuery service account the Encrypter/Decrypter role on the key. They also implement IAM conditions to restrict access to the key to only requests from their corporate IP range. Misconfiguration: If they accidentally delete the key, all data becomes inaccessible. They set up key version destruction with a 30-day delay to allow recovery.
Scenario 2: Multi-Tenant SaaS Application A SaaS company runs a multi-tenant application on Google Kubernetes Engine (GKE). Each customer's data is stored in separate Cloud Storage buckets and BigQuery datasets. They use IAM to isolate tenants: each service account corresponds to a tenant, and IAM policies grant access only to that tenant's resources. They use CMEK with a separate key per tenant to ensure cryptographic isolation. If one tenant's key is compromised, only that tenant's data is at risk. They also use IAM Conditions to restrict access to the key based on the tenant's service account. Common issue: Overly permissive IAM roles on the project level can accidentally grant cross-tenant access. They enforce organization policies to prevent use of primitive roles.
Scenario 3: Financial Services with CSEK A bank requires that encryption keys never be stored by the cloud provider due to internal policy. They use CSEK for their most sensitive transaction logs stored in Cloud Storage. They generate keys on-premises and use a secure key management system to distribute keys to authorized applications. Each upload and download includes the key in the API call. They accept the operational overhead: key management is manual, and key loss is catastrophic. They have automated scripts to rotate keys daily. They also use IAM to restrict who can upload objects to the bucket. Pitfall: If the key is accidentally exposed in logs or error messages, the data could be decrypted. They ensure that keys are never logged by using environment variables and secure parameter passing.
GCDL Objective 2.5: Data Security: Encryption and Access Controls
The exam focuses on your ability to differentiate between encryption options and apply IAM principles. Expect 3-5 questions on this topic.
Common Wrong Answers: 1. "CSEK is the most secure option because Google never has the key." While true that Google doesn't store the key, CSEK is not always the most secure because key management is the customer's responsibility. Loss of key means data loss. The exam expects you to recognize that CMEK is often the best balance for compliance. 2. "IAM primitive roles are recommended for simplicity." Primitive roles (Owner, Editor, Viewer) are too broad and violate least privilege. The exam tests that you should use predefined or custom roles. 3. "Encryption at rest is optional and must be enabled." In Google Cloud, encryption at rest is enabled by default for all services. You do not need to enable it. The exam may trick you into thinking it's optional. 4. "IAM policies are only applied at the project level." IAM policies are hierarchical and can be set at organization, folder, project, and resource levels. Inheritance applies.
Specific Numbers and Terms: - AES-256 encryption. - TLS 1.2 or higher for in transit. - CMEK allows customer control of KEK. - CSEK: key supplied per API call, not stored. - IAM Conditions use Common Expression Language (CEL). - Service accounts are used for non-human identities.
Edge Cases: - If a CMEK key is disabled, data becomes inaccessible immediately. - If a CMEK key is destroyed (after a 24-hour waiting period), data is permanently lost. - IAM deny policies override allow policies. - For Cloud Storage, you can use both IAM and ACLs, but IAM is preferred.
How to Eliminate Wrong Answers: - If a question asks about "most secure encryption," consider the trade-off between control and operational risk. CMEK is often the answer for compliance. - If a question mentions "customer manages keys but Google stores them," it's CMEK. - If a question says "key never stored by Google," it's CSEK. - For access control, always look for the principle of least privilege and use of predefined roles.
Google Cloud encrypts all data at rest by default using AES-256.
Encryption in transit uses TLS 1.2+ and ALTS for internal traffic.
Three key management options: Google-managed (default), CMEK (customer manages KEK), CSEK (customer supplies key per request).
IAM uses hierarchical policies with inheritance; deny policies override allow.
Use predefined roles instead of primitive roles for least privilege.
IAM Conditions allow attribute-based access control using CEL.
Service accounts are used for non-human identities (applications, VMs).
CMEK keys can be rotated automatically; disabling a key makes data inaccessible.
CSEK is high-risk due to potential key loss; not recommended for most use cases.
ACLs are legacy; use IAM for Cloud Storage access control.
These come up on the exam all the time. Here's how to tell them apart.
Google-managed encryption keys
Google creates, rotates, and manages keys.
No customer effort required.
Suitable for most workloads without specific compliance needs.
Key rotation is automatic (Google decides schedule).
Cannot disable or destroy keys independently.
Customer-managed encryption keys (CMEK)
Customer creates and manages keys in Cloud KMS.
Customer controls key lifecycle (rotation, disable, destroy).
Required for compliance regulations that mandate separation of key management.
Key rotation can be automated (e.g., every 90 days).
If key is disabled, data becomes inaccessible.
Mistake
Google Cloud does not encrypt data at rest by default; you must enable it.
Correct
Google Cloud automatically encrypts all customer data at rest using AES-256. No action is required.
Mistake
CMEK means the customer manages the entire encryption process, including the encryption algorithm.
Correct
CMEK only gives the customer control over the key material (KEK). Google still performs the encryption/decryption using its own algorithms (AES-256).
Mistake
CSEK is more secure than CMEK because Google never has access to the key.
Correct
CSEK shifts the operational burden to the customer. Key loss leads to permanent data loss. CMEK is often preferred for compliance because Google still manages the encryption process but the customer controls the key lifecycle.
Mistake
IAM policies set at the project level override organization-level policies.
Correct
IAM policies are additive and hierarchical. A more specific policy (e.g., at the resource level) can add permissions, but it cannot remove permissions granted at a higher level. However, deny policies can override allows.
Mistake
Service accounts are only used for Compute Engine instances.
Correct
Service accounts can be used by any application or service that can authenticate with Google Cloud, including Cloud Functions, App Engine, and third-party applications.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CMEK (Customer-Managed Encryption Keys) means you create and manage your own key in Cloud KMS, but Google still uses it to encrypt your data. The key is stored by Google but under your control. CSEK (Customer-Supplied Encryption Keys) means you provide your own encryption key for each API call, and Google does not store it. CSEK is more secure in terms of key custody but carries high operational risk because if you lose the key, data is unrecoverable. CMEK is the recommended option for most compliance requirements.
IAM policies are hierarchical. A policy set at the organization level applies to all folders, projects, and resources underneath. A policy at the folder level applies to all projects and resources in that folder. A policy at the project level applies to all resources in that project. A policy at the resource level applies only to that resource. If multiple policies apply, the effective permissions are the union of all ALLOW permissions. However, DENY permissions (via deny policies) override ALLOW. The most specific resource-level policy does not override a higher-level policy; rather, all applicable policies are combined.
IAM Conditions allow you to grant access based on attributes of the request, such as time, IP address, or resource type. For example, you can grant a role only during business hours or only from a specific corporate network. Conditions are written in Common Expression Language (CEL). They help implement fine-grained, context-aware access control, reducing the risk of unauthorized access even if credentials are compromised.
No. Google Cloud uses AES-256 for encryption at rest. You cannot change the algorithm. However, you can control the keys using CMEK or CSEK. The encryption algorithm is fixed to ensure security and performance.
Disabling a CMEK key immediately prevents Google Cloud from using that key to encrypt or decrypt data. Any data encrypted with that key becomes permanently inaccessible. You can re-enable the key to restore access. If you destroy the key (after a 24-hour waiting period), it is permanently deleted and cannot be recovered, resulting in permanent data loss.
Yes. All external traffic to Google Cloud APIs uses TLS 1.2 or higher. For internal traffic between Google services, encryption is applied using ALTS or MACsec. No user configuration is required.
A service account is a special type of Google account that represents a non-human user, such as an application or a virtual machine. It is used for programmatic access to Google Cloud resources. For example, a Compute Engine instance can be assigned a service account to access Cloud Storage. Service accounts authenticate using OAuth 2.0 and can have IAM roles assigned to them. They eliminate the need to embed user credentials in applications.
You've just covered Data Security: Encryption and Access Controls — now see how well it sticks with free GCDL practice questions. Full explanations included, no account needed.
Done with this chapter?