Skip to main content

More Info:

Boot volumes should be encrypted using Customer-Managed Keys (CMKs) to ensure operating system level data at rest is secured with keys controlled exclusively by your organizations security administrators

Risk Level

High

Address

Compliance, Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • AWS Well Architected Framework
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • HITRUST CSF
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST
  • NIST CSF
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • PCI
  • SOC2
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Using Console

Here’s how to remediate “Boot Volumes Should Be Encrypted with Customer‑Managed Keys (CMKs)” using the OCI Console.

1. Create a Vault and a Customer-Managed Key (CMK)

  1. In the OCI Console, open the navigation menu.
  2. Go to Identity & Security → Vault.
  3. Choose the compartment where you want the vault.
  4. Click Create vault:
    • Name: e.g., boot-volume-vault
    • Vault type: Default or Virtual Private
    • Click Create vault.
  5. After the vault is active, click it.
  6. Go to Master Encryption Keys → Create key:
    • Protection mode: HSM or Software (per your policy)
    • Key shape: key algorithm and length (e.g., AES-256)
    • Name: e.g., boot-volume-cmk
    • Click Create key.

2. Ensure Block Storage Can Use the Key

If needed, add a policy so Block Volume can use the key (in the tenancy root or relevant compartment):
  1. Go to Identity & Security → Policies.
  2. Choose the compartment where you manage policies (often root).
  3. Click Create policy or edit an existing one.
  4. Add a statement like (adjust compartments/OCID as needed):
  5. Save the policy.

3. Use CMK for New Boot Volumes (Going Forward)

For all new compute instances / boot volumes:
  1. Go to Compute → Instances → Create instance.
  2. Configure instance details as usual.
  3. In the Boot volume section:
    • Expand Show advanced options.
    • For Encryption, choose Encrypt using customer-managed keys.
    • Select the Vault and Key you created (boot-volume-vault / boot-volume-cmk).
  4. Complete instance creation.
All newly created boot volumes will now be encrypted with your CMK.

4. Migrate Existing Boot Volumes to CMK Encryption

You cannot just “flip” the key on an existing boot volume; you must create a new boot volume encrypted with the CMK and then move the workload.

4.1. Create a Backup of the Existing Boot Volume

  1. Go to Compute → Instances.
  2. Click the instance whose boot volume isn’t using a CMK.
  3. Under Resources, click Boot volume to open it (or note the boot volume name, then go to Block Storage → Boot volumes and open it).
  4. In the boot volume page, click Create backup:
    • Name: e.g., bv-backup-cmk-migration-<date>
    • Click Create backup.
  5. Wait until the backup is in Available state.

4.2. Create a New Boot Volume from the Backup with CMK

  1. Go to Block Storage → Boot volume backups.
  2. Open the backup you just created.
  3. Click Create boot volume.
  4. In the dialog:
    • Select Compartment (same as instance, typically).
    • Under Encryption, choose Encrypt using customer-managed keys.
    • Select your Vault and Key (boot-volume-cmk).
  5. Click Create boot volume and wait until it becomes Available.

4.3. Replace the Old Boot Volume on the Instance

This requires some downtime.
  1. Go to Compute → Instances and open the instance.
  2. Click Stop (graceful shutdown) and wait until the instance state is Stopped.
  3. Under Resources → Boot volume attachments, note the current attachment, then Detach the existing boot volume.
  4. Click Attach boot volume:
    • Select the new CMK-encrypted boot volume.
    • Attachment type: Paravirtualized or iSCSI as before.
    • Device path: leave default unless you have a specific requirement.
  5. Save/attach it.
If OCI does not allow directly attaching a different boot volume as “boot” in your region/shape, use this alternative:
  • Alternative:
    1. From Block Storage → Boot volumes, locate the new CMK-encrypted boot volume.
    2. Click Create instance from this boot volume.
    3. Configure the new instance to match the old one (shape, VCN/subnet, etc.).
    4. Redirect traffic (update DNS, load balancer backend set, or IPs) from old instance to new instance.
    5. Decommission the old instance and its non‑CMK boot volume when confirmed.

5. Clean Up and Confirm Compliance

  1. Once the instance is confirmed working on the new CMK-encrypted boot volume, delete the old non‑CMK boot volume and any unnecessary backups.
  2. To confirm:
    • Go to Block Storage → Boot volumes, open the volume.
    • Check the Encryption section; it should show the Customer-managed key and its OCID.
  3. Re-run your OCI Security/Compliance/Monitoring check (e.g., Cloud Guard target or external CSPM tool) and verify that:
    • “Boot Volumes Should Be Encrypted with Customer-Managed Keys” is now passing for the compartment/tenancy.

If you share your tenancy structure and how you’re monitoring (OCI Cloud Guard, Security Zones, or third-party CSPM), I can give a minimal, tailored checklist to verify this at scale.
Below is a concise, step-by-step way to remediate “OCI Storage Boot Volumes Should Be Encrypted With Customer-Managed Keys” using the OCI CLI.Assumptions:
  • You already have oci CLI configured with appropriate permissions.
  • You have (or will create) a Vault and a Key in OCI KMS.

1. Create (or identify) a Customer-Managed KMS Key

1.1 Find your vault

Note the id of the vault you want to use.

1.2 List keys in that vault

If a suitable key exists, note its id (<KEY_OCID>).

1.3 (Optional) Create a new key

From the output, note "id" → this is your <KEY_OCID>.

2. Ensure IAM Policy Lets Block Storage Use the Key

Create a policy in the key’s compartment (or root) so Block Volume service can use it:Example policy statement:
If using CLI to create the policy:
Replace <COMPARTMENT_NAME> accordingly.

3. Identify Boot Volumes to Fix

List instances (optional):
For a given instance, get its boot volume attachment:
From the output, note "bootVolumeId"<BOOT_VOLUME_OCID>.You can also list all boot volumes directly:

4. Reconfigure Boot Volume to Use Customer-Managed Key

You can update the boot volume to use the CMK:
This will re-encrypt the boot volume with the specified KMS CMK.Repeat for each non-compliant boot volume.

5. (Optional) Set CMK at Instance Launch / Instance Configuration

For new instances (to prevent future drift), use --kms-key-id at launch:
For instance configurations (used by Instance Pools), include kmsKeyId under instanceDetails -> blockVolumes or launchDetails depending on your template.

6. Verify Encryption Status

Check the boot volume details:
If it returns your <KEY_OCID>, the boot volume is now encrypted with a customer-managed key.
This sequence (create/identify CMK → grant Block Storage access → update boot-volume kms-key-id) is what remediates the “OCI Storage Boot Volumes Should Be Encrypted With Customer-Managed Keys” finding using OCI CLI.
Below is a step‑by‑step approach and example Python code to:
  1. Monitor OCI boot volumes for non‑compliance (not using customer-managed keys).
  2. Remediate by updating the boot volume to use a customer-managed KMS key (where supported).

1. Prerequisites

  1. OCI CLI config set up on the machine where you’ll run Python:
    • ~/.oci/config with a profile that has:
      • tenancy
      • user
      • fingerprint
      • key_file
      • region
  2. Permissions for the principal used by the SDK:
    • To manage block volumes and KMS keys:
    • Adjust SecOps to your group and scoping as needed.
  3. Customer‑Managed KMS Key already created in OCI Vault:
    • Get the OCID of the key: kms_key_id = "ocid1.key.oc1...."
    • Ensure the key is in the same region as your boot volumes.

2. High-Level Steps

  1. Identify compartments you want to monitor.
  2. For each compartment:
    • List boot volumes.
    • Check each boot volume’s kms_key_id.
  3. Monitoring:
    • Log/report volumes where kms_key_id is None or not equal to your required key.
  4. Remediation:
    • Call UpdateBootVolume with kms_key_id set to your customer-managed key.
    • Optionally, tag or log what was changed.

3. Python Example: Monitor & Remediate Boot Volume Encryption

Install SDK (if not already):

3.1. Configuration

Adjust these values in the code:
  • PROFILE_NAME – OCI CLI profile to use.
  • TARGET_COMPARTMENT_IDS – list of compartment OCIDs to scan, or use the tenancy and list all.
  • REQUIRED_KMS_KEY_ID – OCID of your customer-managed key.

3.2. Script


4. How to Use for “Monitoring” Only

  1. Keep DRY_RUN = True.
  2. Run on a schedule (e.g., cron or CI pipeline).
  3. Redirect output to logs or integrate with your logging/alerting:
    • Parse the Non-compliant boot volumes found count.
    • Trigger alerts when > 0.

5. To Enable Automatic Remediation

  1. Set DRY_RUN = False.
  2. Ensure IAM policies allow:
    • update on boot volumes.
    • use on the KMS key.
  3. Optionally:
    • Add tagging in UpdateBootVolumeDetails to mark remediated resources.
If you share your compartment structure or how you prefer alerts delivered (email, OCI Monitoring metrics, etc.), I can adapt the script to push metrics or alarms specifically for “OCI Storage Monitoring.”
Substitute:
  • OCID_OF_COMPARTMENT_FOR_KMS_VAULT with the OCID of the compartment where the vault should live.
  • OCID_OF_COMPARTMENT_FOR_KMS_KEY with the OCID of the compartment for the key.
  • AVAILABILITY_DOMAIN_NAME with the target availability domain (e.g., "kIdk:PHX-AD-1").
  • OCID_OF_BOOT_VOLUME_COMPARTMENT with the boot volume’s compartment OCID.
  • Optional source_details.id with the OCID of the existing boot volume or backup you want to base this on.
Changing or adding kms_key_id on an existing oci_core_boot_volume typically forces replacement of the boot volume; this can cause an outage and data loss if you don’t coordinate creating/attaching a new boot volume and updating any instances that use it.Verification with terraform plan should show the boot volume either:
  • being newly created with kms_key_id = oci_kms_key.BOOT_VOLUME_CMK.id, or
  • being replaced with the new resource having that kms_key_id argument set.