📝 Google GCE Disk for critical VMs is not encrypted with Customer-Supplied Encryption Key (CSEK) 🟢

• Contextual name: 📝 Disk for critical VMs is not encrypted with Customer-Supplied Encryption Key (CSEK) 🟢
• ID: /ce/ca/google/compute-engine/disk-csek-encryption
• Located in: 📁 Google GCE

Flags

• 🟢 Policy with categories
• 🟢 Policy with type
• 🟢 Production policy

Our Metadata

• Policy Type: COMPLIANCE_POLICY
• Policy Category:
  • SECURITY

Similar Policies

• Cloud Conformity
  • Enable VM Disk Encryption with Customer-Supplied Encryption Keys

Logic

• 🧠 prod.logic.yaml 🟢
  • 📗 Google GCE Attached Disk
  • 🔌 Google GCE Disk - object.extracts.yaml
  • 🧪 test-data.json

Description

Open File

Description

Customer-Supplied Encryption Keys (CSEK) are a feature in Google Cloud Storage and Google Compute Engine. If you supply your own encryption keys, Google uses your key to protect the Google-generated keys used to encrypt and decrypt your data. By default, Google Compute Engine encrypts all data at rest. Compute Engine handles and manages this encryption for you without any additional actions on your part. However, if you wanted to control and manage this encryption yourself, you can provide your own encryption keys.

Rationale

By default, Google Compute Engine encrypts all data at rest. Compute Engine handles and manages this encryption for you without any additional actions on your part. However, if you wanted to control and manage this encryption yourself, you can provide your own encryption keys.

If you provide your own encryption keys, Compute Engine uses your key to protect the Google-generated keys used to encrypt and decrypt your data. Only users who can provide the correct key can use resources protected by a customer-supplied encryption key.

... see more

Remediation

Open File

Remediation

Currently there is no way to update the encryption of an existing disk. Therefore you should create a new disk with Encryption set to Customer supplied.

From Google Cloud Console

1. Go to Compute Engine Disks by visiting: https://console.cloud.google.com/compute/disks.
2. Click CREATE DISK.
3. Set Encryption type to Customer supplied,
4. Provide the Key in the box.
5. Select Wrapped key.
6. Click Create.

From Google Cloud CLI

In the gcloud compute tool, encrypt a disk using the --csek-key-file flag during instance creation. If you are using an RSA-wrapped key, use the gcloud beta component:

        gcloud compute instances create <INSTANCE_NAME> --csek-key-file <example-file.json>

To encrypt a standalone persistent disk:

        gcloud compute disks create <DISK_NAME> --csek-key-file <example-file.json>

policy.yaml

Open File

Linked Framework Sections

Section	Sub Sections	Internal Rules	Policies	Flags
💼 CIS GCP v1.2.0 → 💼 4.7 Ensure VM disks for critical VMs are encrypted with Customer-Supplied Encryption Keys (CSEK) - Level 2 (Automated)			1
💼 CIS GCP v1.3.0 → 💼 4.7 Ensure VM Disks for Critical VMs Are Encrypted With Customer-Supplied Encryption Keys (CSEK) - Level 2 (Automated)			1
💼 CIS GCP v2.0.0 → 💼 4.7 Ensure VM Disks for Critical VMs Are Encrypted With Customer-Supplied Encryption Keys (CSEK) - Level 2 (Automated)			1
💼 CIS GCP v3.0.0 → 💼 4.7 Ensure VM Disks for Critical VMs Are Encrypted With Customer-Supplied Encryption Keys (CSEK) - Level 2 (Automated)			1
💼 Cloudaware Framework → 💼 Data Encryption			42
💼 FedRAMP High Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)	6	14	32
💼 FedRAMP High Security Controls → 💼 SC-28 Protection of Information at Rest (L)(M)(H)	1	7	24
💼 FedRAMP Low Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)	1		32
💼 FedRAMP Low Security Controls → 💼 SC-28 Protection of Information at Rest (L)(M)(H)	1		24
💼 FedRAMP Moderate Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)	4		32
💼 FedRAMP Moderate Security Controls → 💼 SC-28 Protection of Information at Rest (L)(M)(H)	1		24
💼 ISO/IEC 27001:2022 → 💼 5.33 Protection of records		10	15
💼 NIST CSF v1.1 → 💼 PR.DS-1: Data-at-rest is protected		15	28
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization			38
💼 NIST CSF v2.0 → 💼 PR.AA-03: Users, services, and hardware are authenticated			32
💼 NIST CSF v2.0 → 💼 PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected			114
💼 NIST SP 800-53 Revision 5 → 💼 IA-5 Authenticator Management	18		16
💼 NIST SP 800-53 Revision 5 → 💼 SC-28 Protection of Information at Rest	3	16	25
💼 PCI DSS v3.2.1 → 💼 3.2 Do not store sensitive authentication data after authorization (even if encrypted).	3		5
💼 PCI DSS v3.2.1 → 💼 3.4 Render PAN unreadable anywhere it is stored.	1	7	12
💼 PCI DSS v3.2.1 → 💼 3.4.1 If disk encryption is used, logical access must be managed separately and independently of native operating system authentication and access control mechanisms.		7	12
💼 PCI DSS v3.2.1 → 💼 3.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.			5
💼 PCI DSS v3.2.1 → 💼 8.2.1 Using strong cryptography, render all authentication credentials unreadable during transmission and storage on all system components.			14
💼 PCI DSS v4.0.1 → 💼 3.1.1 All security policies and operational procedures identified in Requirement 3 are documented, kept up to date, in use, and known to all affected parties.			5
💼 PCI DSS v4.0.1 → 💼 3.3.1 SAD is not retained after authorization, even if encrypted.	3		5
💼 PCI DSS v4.0.1 → 💼 3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.			13
💼 PCI DSS v4.0.1 → 💼 3.3.3 Any storage of sensitive authentication data is limited to that which is needed for a legitimate issuing business need, is secured and encrypted using strong cryptography.			5
💼 PCI DSS v4.0.1 → 💼 3.5.1 PAN is rendered unreadable anywhere it is stored.	3		12
💼 PCI DSS v4.0.1 → 💼 3.5.1.2 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable.			5
💼 PCI DSS v4.0.1 → 💼 3.5.1.3 If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable.			12
💼 PCI DSS v4.0.1 → 💼 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.			14
💼 PCI DSS v4.0 → 💼 3.1.1 All security policies and operational procedures identified in Requirement 3 are documented, kept up to date, in use, and known to all affected parties.			5
💼 PCI DSS v4.0 → 💼 3.3.1 SAD is not retained after authorization, even if encrypted.	3		5
💼 PCI DSS v4.0 → 💼 3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.		8	13
💼 PCI DSS v4.0 → 💼 3.3.3 Any storage of sensitive authentication data is limited to that which is needed for a legitimate issuing business need, is secured and encrypted using strong cryptography.			5
💼 PCI DSS v4.0 → 💼 3.5.1 PAN is rendered unreadable anywhere it is stored.	3		12
💼 PCI DSS v4.0 → 💼 3.5.1.2 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable.			5
💼 PCI DSS v4.0 → 💼 3.5.1.3 If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable.			12
💼 PCI DSS v4.0 → 💼 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.		6	14
💼 SOC 2 → 💼 CC6.1-3 Restricts Logical Access		1	21
💼 SOC 2 → 💼 CC6.1-10 Uses Encryption to Protect Data		6	11