Skip to main content

OCI Compute Block Volumes Should Be Encrypted With

More Info:​

Block volumes should be encrypted with customer-managed keys (CMK). Volumes using only Oracle-managed encryption do not provide customer control over key lifecycle and access auditing.

Risk Level​

High

Address​

Compliance, Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • AWS Startup Security Baseline
  • 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)
  • GDPR
  • HIPAA
  • ISO 27001
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST CSF
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • PCI
  • Reserve Bank of India (RBI) Cyber Security Framework
  • 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

To use customer‑managed keys (CMKs) for OCI Compute block volumes via the Console, you need to:

  1. Create a customer‑managed key in OCI Vault
  2. Apply that key to new and existing block/boot volumes used by Compute

1. Create a customer‑managed key​

  1. In the OCI Console, open the navigation menu → Identity & Security → Vault.
  2. Choose the correct compartment.
  3. Click Create vault (if you don’t already have one):
    • Name: e.g. block-vol-vault
    • Type: typically Default (or as per your org’s standards)
    • Compartment: choose the same or a shared security compartment
    • Click Create vault.
  4. Once the vault is active, click the vault name.
  5. Go to the Keys tab → Create key:
    • Name: e.g. block-volume-cmk
    • Protection mode: HSM (or Software as per policy)
    • Key shape: e.g. AES 256‑bit
    • Click Create key.

You now have a CMK that can be used for block volumes.

This ensures newly created block volumes in that compartment use your CMK by default.

  1. Navigation menu → Storage → Block Storage.
  2. In the left pane, click Block Volume Settings (or Block Storage Settings, name may vary by region/tenancy).
  3. Select the compartment where your Compute instances/volumes live.
  4. Under Encryption, set:
    • Default encryption key type: Customer-managed key (Vault).
    • Select your Vault and Key (block-volume-cmk).
  5. Click Save changes.

All new block volumes created in this compartment will now be encrypted with this CMK.

3. Apply CMK to existing block volumes​

For each existing block volume:

  1. Navigation menu → Storage → Block Storage → Block Volumes.
  2. Ensure you’re in the correct compartment.
  3. Click the block volume you want to fix.
  4. On the volume details page, look for Encryption / KMS key section.
  5. Click Change encryption key or Assign KMS key (wording can vary):
    • Choose Customer-managed key.
    • Select the Vault and the Key you created.
  6. Confirm the change.

If the UI doesn’t show a direct “change key” option in your tenancy/region, use this fallback:

  1. From the volume details page, click Create backup.
  2. After backup completes, click Restore backup:
    • In the restore dialog, pick the customer‑managed key under encryption.
    • Restore as a new block volume.
  3. Detach the old volume from your instance and attach the new, CMK‑encrypted volume.

Repeat for all block volumes reported by your monitoring tool.

4. Apply CMK to boot volumes (Compute instances)​

For existing instances:

  1. Navigation menu → Compute → Instances.
  2. Select the instance, go to the Boot volume section → click the boot volume name.
  3. On the boot volume details page:
    • If available, click Change encryption key / Assign KMS key and select your CMK.
    • If not available, use backup/restore:
      1. Click Create backup on the boot volume.
      2. After backup completes, click Restore backup:
        • Choose the customer‑managed key.
        • Restore to a new boot volume.
      3. Stop the instance, detach old boot volume, attach new CMK‑encrypted boot volume as the boot volume, and start the instance.

5. Validate in your monitoring / compliance tool​

  1. After changing keys, wait for your OCI Compute Monitoring / security posture tool to rescan.
  2. Confirm that all block and boot volumes now show:
    • Encryption: Enabled
    • Key type: Customer-managed (Vault) with your CMK.

These steps remediate the misconfiguration using only the OCI Console.

Using CLI

To meet the control “OCI Compute Block Volumes Should Be Encrypted With Customer-Managed Keys” you must:

  1. Have a Vault and Customer-Managed Key (CMK) in OCI Vault.
  2. Re-create non-compliant block volumes using that CMK (you cannot change the key of an existing volume in-place).
  3. Ensure any new volumes use the CMK.

Below are step‑by‑step remediation steps using OCI CLI.

1. Prerequisites​

Make sure:

  • OCI CLI is installed and configured with appropriate permissions.
  • You know:
    • The compartment OCID where volumes and vaults reside.
    • The availability domain of your compute instance/volumes.
    • The volume OCIDs that are not using CMK.
    • The subnet/shape etc. if you need to create a new instance or reattach volumes.

2. Create / Identify a Vault and CMK​

2.1 Create a Vault (if you don’t already have one)​

# Create a vault
oci kms management vault create \
  --compartment-id <compartment_ocid> \
  --display-name "cmk-vault" \
  --vault-type DEFAULT

# Get the vault OCID from the output
# Or list existing vaults:
oci kms management vault list --compartment-id <compartment_ocid>

From the vault JSON, note:

  • id (vault OCID)
  • management-endpoint

2.2 Create a Master Encryption Key​

# Example: create a 256-bit AES key
oci kms management key create \
  --compartment-id <compartment_ocid> \
  --display-name "block-volume-cmk" \
  --protection-mode HSM \
  --management-endpoint <vault_management_endpoint>

From the output, note:

  • id → this is your --kms-key-id.

You can also list existing keys:

oci kms management key list \
  --compartment-id <compartment_ocid> \
  --management-endpoint <vault_management_endpoint>

3. Recreate Each Non-Compliant Block Volume Using the CMK​

You cannot change encryption key on an existing volume directly. The standard pattern is:

  1. Create a backup of the existing volume.
  2. Create a new volume from that backup, specifying --kms-key-id.
  3. Detach the old volume from the instance.
  4. Attach the new CMK-encrypted volume.
  5. (Optionally) delete the old volume after verification.

Below steps per volume:

3.1 Identify the Volume​

oci bv volume get --volume-id <source_volume_ocid>

Note:

  • availabilityDomain
  • sizeInGBs
  • compartmentId

3.2 Create a Backup of the Existing Volume​

oci bv backup create \
  --volume-id <source_volume_ocid> \
  --type FULL \
  --display-name "backup-for-cmk-migration-<source_volume_ocid>"

From the output, capture the backup OCID:

backup_ocid=<backup_ocid_from_output>

Wait until backup is finished:

oci bv backup wait-for-state \
  --backup-id $backup_ocid \
  --state AVAILABLE

3.3 Create a New Volume from the Backup with CMK​

oci bv volume create \
  --availability-domain "<availability_domain>" \
  --compartment-id <compartment_ocid> \
  --source-volume-backup-id $backup_ocid \
  --kms-key-id <cmk_key_ocid> \
  --display-name "cmk-encrypted-volume-from-<source_volume_ocid>"

From the output, capture:

new_volume_ocid=<new_volume_ocid_from_output>

Wait until the new volume is AVAILABLE:

oci bv volume wait-for-state \
  --volume-id $new_volume_ocid \
  --state AVAILABLE

4. Swap the Volume on the Compute Instance​

4.1 Detach the Old Volume​

List current volume attachments (to find attachment OCID):

oci compute volume-attachment list \
  --compartment-id <compartment_ocid> \
  --instance-id <instance_ocid>

Then detach:

oci compute volume-attachment delete \
  --volume-attachment-id <old_volume_attachment_ocid> \
  --force

You may want to:

  • Stop the instance or unmount the filesystem in the OS before detaching (OS-level step, not via CLI), to avoid corruption.

4.2 Attach the New CMK-Encrypted Volume​

oci compute volume-attachment attach-paravirtualized-volume \
  --instance-id <instance_ocid> \
  --volume-id $new_volume_ocid \
  --display-name "cmk-encrypted-attachment" \
  --device /dev/oracleoci/oraclevdb

Adjust device path and attachment type (attach-iscsi-volume vs attach-paravirtualized-volume) as appropriate for your environment.

Inside the OS, mount the new volume and verify data.

4.3 (Optional) Delete the Old Volume and Backup​

After verifying:

oci bv volume delete \
  --volume-id <source_volume_ocid> \
  --force

oci bv backup delete \
  --backup-id $backup_ocid \
  --force

5. Ensure All New Volumes Use the CMK​

When creating new block volumes (manually or via automation), always specify your CMK:

oci bv volume create \
  --availability-domain "<availability_domain>" \
  --compartment-id <compartment_ocid> \
  --size-in-gbs 50 \
  --kms-key-id <cmk_key_ocid> \
  --display-name "new-cmk-encrypted-volume"

If you use Terraform/Resource Manager, CI/CD, or scripts, add kms-key-id in those definitions as well.

If you share:

  • Example volume OCID(s), and
  • The compartment / AD details (redacted as needed),

I can give you CLI commands tailored exactly to those resources.

Using Python

In OCI you cannot switch an existing block volume from Oracle-managed encryption to a customer-managed key (CMK). Remediation is:

  1. Create/identify a customer-managed key in OCI Vault.
  2. For existing volumes:
    • Take a backup.
    • Create a new volume from that backup using the CMK.
    • Attach the new volume, sync data if needed, then detach/delete the old one.
  3. For new volumes: always create them with the CMK.

Below is how to do this with Python using the OCI SDK.

1. Prerequisites​

pip install oci

~/.oci/config must be set (or use instance principal).

Python imports:

import oci
from oci.core import BlockstorageClient
from oci.core.models import CreateVolumeDetails

2. Identify a Customer-Managed Key​

You need the OCID of the KMS key (not vault) in the same region as your volumes. Example:

kms_key_id = "ocid1.key.oc1.iad.<your_key_ocid_here>"
compartment_id = "ocid1.compartment.oc1..xxxx"
availability_domain = "kIdk:US-ASHBURN-AD-1"  # example

3. Find Non‑Compliant Block Volumes​

config = oci.config.from_file()  # or oci.config.from_file(profile_name="...")

blockstorage = BlockstorageClient(config)

def list_volumes_without_cmk(compartment_id):
    result = []
    list_volumes_response = oci.pagination.list_call_get_all_results(
        blockstorage.list_volumes,
        compartment_id=compartment_id
    )
    for vol in list_volumes_response.data:
        # If kms_key_id is None -> Oracle-managed key
        if getattr(vol, "kms_key_id", None) is None:
            result.append(vol)
    return result

non_compliant_vols = list_volumes_without_cmk(compartment_id)
for v in non_compliant_vols:
    print(v.id, v.display_name, "AD:", v.availability_domain)

4. Remediate an Existing Volume (Backup → New Volume with CMK)​

You must:

  1. Create a backup of the existing volume.
  2. Create a new volume from that backup with kms_key_id set.
  3. Re-attach and migrate if necessary.
  4. Delete the old volume when safe.
from oci.core.models import CreateVolumeBackupDetails

def migrate_volume_to_cmk(volume, kms_key_id):
    # 1. Create volume backup
    print(f"Creating backup for volume {volume.display_name} ({volume.id})")
    backup_details = CreateVolumeBackupDetails(
        volume_id=volume.id,
        display_name=f"{volume.display_name}-cmk-migration-backup"
    )
    backup_resp = blockstorage.create_volume_backup(backup_details)
    backup = oci.wait_until(
        blockstorage,
        blockstorage.get_volume_backup(backup_resp.data.id),
        'lifecycle_state',
        'AVAILABLE'
    ).data

    # 2. Create new volume from backup with CMK
    print(f"Creating new CMK-encrypted volume from backup {backup.id}")
    create_vol_details = CreateVolumeDetails(
        compartment_id=volume.compartment_id,
        availability_domain=volume.availability_domain,
        display_name=f"{volume.display_name}-cmk",
        source_details={
            "type": "volumeBackup",
            "id": backup.id
        },
        kms_key_id=kms_key_id
    )
    new_vol_resp = blockstorage.create_volume(create_vol_details)
    new_vol = oci.wait_until(
        blockstorage,
        blockstorage.get_volume(new_vol_resp.data.id),
        'lifecycle_state',
        'AVAILABLE'
    ).data

    print(f"New CMK volume: {new_vol.id}")
    return new_vol, backup

You then need to:

  • Stop the instance (if boot volume) or unmount filesystem (for data volume).
  • Detach the old volume and attach the new one.
  • For a boot volume of a compute instance, you typically create a custom image then launch a new instance. That flow is more involved; for data volumes this attach/detach is sufficient.

5. Remediate All Non‑Compliant Volumes​

for vol in non_compliant_vols:
    new_vol, backup = migrate_volume_to_cmk(vol, kms_key_id)
    # TODO: manually (or via API) update attachments:
    # - detach old vol from instances
    # - attach new_vol
    # After validation, you can delete the old volume and optionally the backup.

6. Ensure New Volumes Use CMK by Default​

For any Python code that creates volumes, always provide kms_key_id:

def create_cmk_volume(compartment_id, availability_domain, kms_key_id, size_gbs=50):
    create_vol_details = CreateVolumeDetails(
        compartment_id=compartment_id,
        availability_domain=availability_domain,
        display_name="cmk-volume",
        size_in_gbs=size_gbs,
        kms_key_id=kms_key_id
    )
    resp = blockstorage.create_volume(create_vol_details)
    vol = oci.wait_until(
        blockstorage,
        blockstorage.get_volume(resp.data.id),
        'lifecycle_state',
        'AVAILABLE'
    ).data
    return vol

If your “OCI Compute Monitoring” is a separate Python-based compliance scanner, integrate:

  1. The discovery function (list_volumes_without_cmk).
  2. Reporting (e.g., print/JSON list of non-compliant volumes).
  3. Optional auto-remediation using migrate_volume_to_cmk, with safeguards (e.g., only for data volumes, maintenance window checks).
Using Terraform
# Customer-managed KMS key (CMK) for block volume encryption
resource "oci_kms_key" "BLOCK_VOLUME_CMK" {
  # Replace with your KMS vault OCID
  management_endpoint = oci_kms_vault.BLOCK_VOLUME_VAULT.management_endpoint

  display_name = "BLOCK_VOLUME_CMK"
  key_shape {
    algorithm = "AES"
    length    = 32
  }
}

# KMS vault used for the CMK
resource "oci_kms_vault" "BLOCK_VOLUME_VAULT" {
  compartment_id = "OCID_OF_COMPARTMENT_FOR_VAULT" # substitute with your compartment OCID
  display_name   = "BLOCK_VOLUME_VAULT"
  vault_type     = "DEFAULT"
}

# Block volume encrypted with customer-managed key
resource "oci_core_volume" "BLOCK_VOLUME" {
  availability_domain = "AVAILABILITY_DOMAIN_NAME"   # e.g., "kIdk:US-ASHBURN-AD-1"
  compartment_id      = "OCID_OF_COMPARTMENT_FOR_VOLUME" # substitute with your compartment OCID
  display_name        = "MY_BLOCK_VOLUME"
  size_in_gbs         = 50

  # This is the critical setting: use a customer-managed KMS key (CMK)
  kms_key_id = oci_kms_key.BLOCK_VOLUME_CMK.id
}

# Example: boot volume of a compute instance encrypted with CMK
resource "oci_core_instance" "COMPUTE_INSTANCE" {
  availability_domain = "AVAILABILITY_DOMAIN_NAME"         # same as above
  compartment_id      = "OCID_OF_COMPARTMENT_FOR_INSTANCE" # substitute
  shape               = "VM.Standard3.Flex"

  source_details {
    source_type = "image"
    source_id   = "OCID_OF_IMAGE" # substitute with your image OCID

    # Encrypt the boot volume with the same CMK
    kms_key_id = oci_kms_key.BLOCK_VOLUME_CMK.id
  }

  create_vnic_details {
    subnet_id = "OCID_OF_SUBNET" # substitute
  }

  # other required arguments (e.g., shape_config) as needed...
}

Updating kms_key_id on an existing oci_core_volume or oci_core_instance.source_details is an in-place change in Terraform (no forced replacement), though encryption rekeying is irreversible once applied.

Verification: terraform plan should show an in-place update adding or changing kms_key_id for the affected block volumes (and/or boot volumes), with no destroy/create of the volumes unless you are creating new ones.