Skip to main content

More Info:

Block volumes should be encrypted using Customer-Managed Keys (CMKs). Managing your own keys provides a higher level of data security and cryptographic isolation compared to default Oracle-managed keys

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

Below are the concise step‑by‑step actions in the OCI Console to ensure Block Volumes are encrypted with customer‑managed keys (CMK) rather than Oracle‑managed keys.

1. Create (or Identify) a Customer-Managed Key

  1. Sign in to the OCI Console.
  2. Open the navigation menu → Identity & SecurityVault.
  3. Choose the Compartment where you want the vault.
  4. Click Create vault (if you don’t already have one):
    • Type: typically Default (or Virtual Private depending on your needs).
    • Compartment: select the appropriate one.
    • Click Create vault.
  5. After the vault is in Active state, click into the vault.
  6. Go to Master Encryption Keys (or Keys).
  7. Click Create key:
    • Key type: AES (for block volumes).
    • Protection mode: HSM or Software as per your policy.
    • Set name/description and click Create key.
  8. Note the OCID and name of the created key.

2. Use CMK for New Block Volumes

When you create new Block Volumes, explicitly select the CMK:
  1. Navigation menu → StorageBlock Volumes.
  2. Click Create block volume.
  3. Set:
    • Compartment, Availability Domain, Size, etc.
  4. Under Encryption:
    • Choose Customer-managed keys (or Encrypt using a key that you manage).
    • Select your Vault and then your Key from the drop‑down.
  5. Click Create block volume.
All new volumes created with that setting are encrypted with your CMK.

3. Remediate Existing Block Volumes (Re-encrypt with CMK)

Block Volumes cannot have the encryption key changed in-place. You must create a new volume encrypted with your CMK from a backup of the existing one.For each existing volume currently using Oracle-managed keys:

3.1 Create a Backup of the Existing Volume

  1. Navigation menu → StorageBlock Volumes.
  2. Select the Block Volume to remediate.
  3. From the More actions or Actions menu, choose Create backup.
  4. Provide:
    • Backup name.
    • Backup type: usually Full backup.
  5. Click Create backup and wait until the backup is Available.

3.2 Create a New CMK-Encrypted Volume from the Backup

  1. Go to Block Volume Backups (from the same Block Volumes page or left-side link).
  2. Click the backup you just created.
  3. Click Create block volume from this backup.
  4. Configure:
    • Compartment, Availability Domain as required.
  5. Under Encryption:
    • Select Customer-managed keys.
    • Choose your Vault and CMK.
  6. Click Create block volume.
You now have a new volume, same data, but encrypted with the CMK.

3.3 Swap the Old Volume with the New One

For each attached volume:
  1. Identify the instance(s) where the old volume is attached:
    • Navigation menu → ComputeInstances → click the instance → Attached block volumes.
  2. Gracefully stop or quiesce the application/OS if needed (data‑consistency decision).
  3. Detach the old volume:
    • On the instance details page, next to the old volume, click Detach.
  4. Attach the new CMK-encrypted volume:
    • Click Attach block volume.
    • Choose the new volume.
    • Set attachment type (iSCSI or paravirtualized) same as previous.
    • Complete the attach.
  5. On the instance (OS level), ensure:
    • The new device is recognized.
    • Mount it to the same mount point or update fstab as needed.
  6. Validate data and application functionality.
  7. After verification, delete the old volume (if no longer needed) to avoid extra cost and reduce risk.

4. Set CMK as Default for Future Block Volume Creation (Optional)

If your tenancy policy allows, you can enforce or standardize CMK usage:
  1. Use Tagging or Compartment policies operationally so all block volumes in a given compartment are created with the CMK.
  2. For operational enforcement/monitoring, you can:
    • Use Cloud Guard (Security → Cloud Guard) to:
      • Enable a target (tenancy/compartment).
      • Enable detectors for storage/compute and configure Responder Recipes to alert on volumes not using CMK.

5. Monitoring (Verifying Compliance in OCI Console)

To continuously monitor that Block Volumes use CMKs:
  1. Navigation menu → Observability & ManagementCloud Guard.
  2. Ensure Cloud Guard is Enabled with a target covering your compartments.
  3. Edit the Detector Recipe:
    • Look for detectors relating to block storage encryption or Oracle-managed vs customer-managed keys (names can differ by region/version).
    • Ensure they are Enabled.
  4. Configure Responder Recipe to:
    • At least send notifications (via Notifications service → topics and subscriptions).
  5. Check Cloud Guard → Findings regularly or feed into SIEM for continuous monitoring.

If you share whether you want to remediate at scale (many volumes/compartments), I can add a very short OCI CLI/script approach as well.
Below are concise, step‑by‑step OCI CLI instructions to ensure Block Volumes are encrypted with customer‑managed keys (CMK).Assumptions:
  • You already have OCI CLI configured (oci setup config) with proper permissions.
  • Replace all placeholder values (<...>) with your real OCIDs / names.

1. Create a Vault (if you don’t already have one)


2. Create a Key inside the Vault


3. Use CMK for New Block Volumes

When creating block volumes, specify --kms-key-id:
For boot volumes (when launching a compute instance):
(Or use --launch-options / --block-volume-details JSON as appropriate for your environment.)

4. Migrate Existing Volumes to CMK

4.1 List existing Block Volumes

Check each volume’s encryption key:
If returned value is empty or not your CMK, update it.

4.2 Re-encrypt an existing Block Volume with CMK

Repeat for all non‑compliant volumes.
If attached to running instances, ensure you update in a scheduled maintenance window in case of performance impact during re-encryption.

5. (Optional) Set Policy So All New Volumes Use CMK by Default

OCI doesn’t currently support a tenancy‑wide “default CMK” for block volumes solely by config; enforcement is usually done via:
  • Cloud Guard / Security Zones to detect non‑CMK volumes.
  • Golden images / Terraform / scripts that always pass --kms-key-id.
For CLI‑driven provisioning, standardize scripts to always include --kms-key-id $KMS_KEY_OCID.

6. Hook into “Storage Monitoring” / Compliance

To make sure your “OCI Storage Monitoring” (Cloud Guard / custom monitoring) shows compliance:
  • Ensure all block volumes have a non‑empty kms-key-id and that it equals your CMK OCID.
  • You can script a compliance check:
Any row returned is non‑compliant (not using CMK). Then remediate with the volume update command above.If you tell me which monitoring tool you’re using (Cloud Guard, custom scripts, etc.), I can give you an exact check/remediation script end-to-end.
Below is how to remediate this in OCI and then monitor it using Python.

1. What “remediation” means for OCI Block Volumes

In OCI:
  • A block volume is either:
    • Encrypted with Oracle-managed keys (default), or
    • Encrypted with a customer-managed key (CMK) from OCI Vault.
You cannot just “flip” an existing volume’s key. To remediate:
  1. Ensure a Vault and Key exist.
  2. Ensure all future volumes are created with that CMK.
  3. For existing volumes, migrate to new volumes encrypted with CMK (backup → restore with CMK).
  4. Implement monitoring to detect any volume not using CMK.
The user asked specifically “using Python” for OCI Storage Monitoring, so the script below focuses on:
  • Detecting non‑compliant volumes (not using CMK).
  • Optionally guiding migration steps.

2. Preconditions

Before running the Python script:
  1. Install SDK:
  2. Configure OCI CLI/SDK credentials (user, tenancy, region, key):
    • Typically ~/.oci/config with a profile, e.g. [DEFAULT].
  3. Have a Vault and Customer-Managed Key:
    • Vault type: Virtual Private or Default (up to you).
    • Record the Key OCID: ocid1.key.oc1...

3. Python: Monitor Block Volumes for CMK Usage

This script:
  • Iterates through all compartments and block volumes in a tenancy.
  • Checks kms_key_id on each volume.
  • Flags volumes not encrypted with CMK (i.e., using Oracle-managed keys).
  • (Optional) Can be narrowed to a single compartment or region.
You can run this periodically (e.g., via cron, OCI Functions, or OCI Cloud Shell + scheduler) and send the output to:
  • Logging / SIEM
  • Email / notification (using OCI Notifications)

4. Enforcing CMK for New Volumes (Python Example)

When you create volumes, always pass kms_key_id:

5. Migrating Existing Non‑Compliant Volumes to CMK

You must:
  1. Create a backup of the existing (Oracle-managed) volume.
  2. Restore a new volume from that backup, specifying kms_key_id for the CMK.
  3. Detach old volume from instance, attach new CMK-encrypted volume.
  4. Decommission the old volume once data is validated.
Python outline (simplified):
(Attach/detach operations depend on your compute setup and can be automated with oci.core.ComputeClient.)
If you tell me how you want to run this (OCI Functions, local cron, etc.) I can adapt the monitoring code to emit logs or metrics in that environment.
Changing kms_key_id on an existing oci_core_volume forces replacement of the volume; applying this to an in-use volume will destroy and recreate it, so you must plan migration or restore from backup accordingly.For verification, terraform plan should show kms_key_id set to the CMK ID on the volume and that the oci_core_volume.BLOCK_VOLUME resource will be replaced (destroyed and created) to apply the new encryption.