Skip to main content

OCI Storage File Systems Should Be Encrypted With

More Info:​

File Storage systems should utilize Customer-Managed Keys (CMKs) for encryption. This provides centralized, customer-controlled key lifecycle management and auditing for network-attached storage assets.

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

For OCI File Storage, encryption key type is fixed at creation. You cannot switch an existing file system from Oracle-managed keys to customer-managed keys (CMK). Remediation therefore means: create a new CMK-backed file system and migrate data.

Below are the step‑by‑step actions in the OCI Console.

1. Create / Verify a Vault and Customer-Managed Key​

  1. In the OCI Console, open the hamburger menu → Identity & Security → Vault.
  2. Choose the correct Compartment.
  3. If you don’t have a vault:
    • Click Create vault.
    • Enter Name, choose Type (typically Default), select Compartment, then Create vault.
    • Wait until it becomes Active.
  4. Open the vault → go to Master Encryption Keys (or Keys depending on UI).
  5. Click Create key:
    • Name: e.g., fss-cmk-key.
    • Protection mode: typically HSM (or according to your policy).
    • Key shape: AES-256 (standard).
    • Click Create key.
  6. Note the OCID of the key; you’ll need this when creating the file system.

2. Create a New File System Encrypted with CMK​

  1. Go to Menu → Storage → File Systems.
  2. Select the Compartment where the file system should live.
  3. Click Create file system.
  4. Fill in:
    • Name and Compartment.
    • Availability Domain matching the old file system (if applicable).
  5. Under Encryption (or KMS key):
    • Choose Encrypt using Customer-Managed Key (wording may vary).
    • Select the vault and KMS Key you created earlier.
  6. Configure Mount target / Export as needed (either use existing mount target or create a new one).
  7. Click Create.

This file system will now be encrypted with your customer-managed key.

3. Migrate Data from the Old File System​

  1. On each client (host) that mounts the old file system:
    • Mount the new CMK-encrypted file system at a temporary mount point.
  2. Use a file-level copy tool that preserves metadata, such as:
    • rsync -aHAX (Linux), or
    • cp -a / backup tools that preserve perm/ownership/ACLs as required.
  3. Verify data integrity and access on the new file system.
  4. Update application / system configs (e.g., /etc/fstab or scripts) to use the new file system exports.
  5. Once all clients use the new file system and data is verified, unmount and decommission the old file system.

4. (Optional) Use Monitoring / Cloud Guard to Track Compliance​

  1. In the Console, go to Cloud Guard (or Security Advisor depending on your tenancy).
  2. Ensure the detector recipe for Storage / File Systems includes the rule that checks for “OCI Storage File Systems should be encrypted with Customer-Managed Keys”.
  3. Confirm that the new file system no longer appears as non-compliant after the next evaluation cycle.

Because existing FSS encryption type cannot be changed, this “create new with CMK + migrate” pattern is the only way to fully remediate via the OCI Console.

Using CLI

You can’t change an existing OCI File Storage file system from Oracle-managed keys to customer-managed keys in place. You must:

  1. create or identify a customer-managed KMS key
  2. create a new file system encrypted with that key
  3. migrate data and cut over
  4. delete the old file system

Below are the essential OCI CLI steps.

1. Prerequisites​

Make sure you have:

  • OCI CLI configured (oci setup config)
  • OCIDs for:
    • Compartment
    • VCN / subnet(s) for mount targets
  • Appropriate IAM permissions for:
    • Vault & keys
    • File Storage (FSS)

Set environment variables for convenience:

export COMPARTMENT_OCID="ocid1.compartment.oc1..xxxx"
export AVAILABILITY_DOMAIN="kIdk:US-ASHBURN-AD-1"   # Example

2. Create / identify a customer-managed KMS key​

2.1 Create a Vault (if needed)​

oci kms management vault create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "fss-cmk-vault" \
  --vault-type "DEFAULT"

# Get the vault OCID and management endpoint
oci kms management vault list \
  --compartment-id "$COMPARTMENT_OCID" \
  --all

From the output, note:

  • id → VAULT_OCID
  • management-endpoint → MGMT_ENDPOINT
export VAULT_OCID="ocid1.vault.oc1..xxxx"
export MGMT_ENDPOINT="https://management-kms.us-ashburn-1.oraclecloud.com"

2.2 Create a Key​

oci kms management key create \
  --endpoint "$MGMT_ENDPOINT" \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "fss-cmk" \
  --protection-mode HSM \
  --key-shape '{"algorithm":"AES","length":32}'

List keys and capture key OCID:

oci kms management key list \
  --endpoint "$MGMT_ENDPOINT" \
  --compartment-id "$COMPARTMENT_OCID" \
  --all

export KMS_KEY_OCID="ocid1.key.oc1..xxxx"

3. Identify non-compliant file systems (Oracle-managed keys)​

List file systems:

oci fs file-system list \
  --compartment-id "$COMPARTMENT_OCID" \
  --all

For each file system, check kms-key-id in its details:

oci fs file-system get --file-system-id <FS_OCID>
  • If kms-key-id is null → encrypted with Oracle-managed keys (non-compliant).
  • If kms-key-id is set → already CMEK-encrypted.

4. Create a new CMEK-encrypted file system​

For each non-compliant file system, create a new one:

oci fs file-system create \
  --availability-domain "$AVAILABILITY_DOMAIN" \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "my-fs-cmek" \
  --kms-key-id "$KMS_KEY_OCID"

Capture new file system OCID:

oci fs file-system list \
  --compartment-id "$COMPARTMENT_OCID" \
  --all | jq -r '.data[] | select(.display-name=="my-fs-cmek") | .id'

export NEW_FS_OCID="ocid1.filesystem.oc1..xxxx"

5. Create mount target(s) and export for the new file system​

5.1 Create a mount target​

export SUBNET_OCID="ocid1.subnet.oc1..xxxx"

oci fs mount-target create \
  --availability-domain "$AVAILABILITY_DOMAIN" \
  --compartment-id "$COMPARTMENT_OCID" \
  --subnet-id "$SUBNET_OCID" \
  --display-name "my-fs-cmek-mt"

Get mount target OCID and IP:

oci fs mount-target list \
  --compartment-id "$COMPARTMENT_OCID" \
  --availability-domain "$AVAILABILITY_DOMAIN" \
  --all

export MT_OCID="ocid1.mounttarget.oc1..xxxx"

5.2 Create an export for the new file system​

oci fs export create \
  --export-set-id "$MT_OCID" \
  --file-system-id "$NEW_FS_OCID" \
  --path "/my-fs-cmek"

6. Migrate data (cutover)​

On the compute instance(s) where the old file system is mounted:

  1. Mount old and new file systems via NFS (new using mount target IP and path /my-fs-cmek):

    sudo mkdir -p /mnt/oldfs /mnt/newfs

    # Example IP and paths:
    sudo mount -t nfs <OLD_MT_IP>:/oldfs /mnt/oldfs
    sudo mount -t nfs <NEW_MT_IP>:/my-fs-cmek /mnt/newfs

  2. Copy data:

    sudo rsync -aHAX --progress /mnt/oldfs/ /mnt/newfs/

  3. Update application / fstab configurations to point to the new mount.

  4. Validate data and application access.

(These steps are on the OS, not OCI CLI, but they are required for remediation.)

7. Decommission the non-compliant file system​

Once fully cut over and validated:

export OLD_FS_OCID="ocid1.filesystem.oc1..oldxxxx"

# Remove any exports associated with OLD_FS_OCID first
oci fs export list \
  --compartment-id "$COMPARTMENT_OCID" \
  --all

# For each export ocid:
oci fs export delete --export-id <EXPORT_OCID> --force

# Delete the old file system
oci fs file-system delete \
  --file-system-id "$OLD_FS_OCID" \
  --force

Optionally delete unused mount targets once all exports are moved:

oci fs mount-target delete \
  --mount-target-id "$MT_OCID" \
  --force

8. Ongoing: Ensure new file systems use CMEK​

Enforce CMEK by:

  • Always specifying --kms-key-id "$KMS_KEY_OCID" in oci fs file-system create.
  • Adding policy / automation (e.g., Cloud Guard + Functions) to detect file systems with kms-key-id == null and alert/remediate.
Using Python

Below is how to remediate this using Python and the OCI SDK so that all File Storage file systems use a customer-managed Vault key (CMK).

1. Prerequisites​

  1. Install the OCI Python SDK:

    pip install oci

  2. Configure your OCI CLI/config file (used by the SDK): ~/.oci/config with at least:

    [DEFAULT]
    user=ocid1.user.oc1..
    fingerprint=...
    key_file=/path/to/private_key.pem
    tenancy=ocid1.tenancy.oc1..
    region=us-ashburn-1

  3. Have or create a customer-managed key (KMS) in OCI Vault and note its OCID:

    • Go to: Identity & Security → Vault → Keys → create key (if needed).
    • Copy the Key OCID (e.g., ocid1.key.oc1..).

2. Concept​

For OCI File Storage:

  • Each file system has kms_key_id attribute.
  • If kms_key_id is not set or points to an Oracle-managed key rather than your CMK, you should set/update it to your Vault key using UpdateFileSystemDetails.

You can:

  1. List all file systems in a compartment.
  2. Check whether kms_key_id equals your required CMK OCID.
  3. If not, call update_file_system to attach the CMK.

3. Python Script – Remediate All File Systems in a Compartment​

import oci

# ---------------- CONFIGURABLE VALUES ----------------
COMPARTMENT_ID = "ocid1.compartment.oc1..xxxx"  # Target compartment OCID
TARGET_KMS_KEY_OCID = "ocid1.key.oc1..xxxx"     # Your customer-managed key OCID
PROFILE = "DEFAULT"                             # Profile name in ~/.oci/config
DRY_RUN = False                                 # Set True to only report, not change
# ----------------------------------------------------


def main():
    # Load config and clients
    config = oci.config.from_file("~/.oci/config", PROFILE)
    fss_client = oci.file_storage.FileStorageClient(config)

    print(f"Scanning file systems in compartment: {COMPARTMENT_ID}")
    print(f"Target KMS key: {TARGET_KMS_KEY_OCID}")
    print(f"DRY_RUN={DRY_RUN}")

    # List file systems
    file_systems = oci.pagination.list_call_get_all_results(
        fss_client.list_file_systems,
        compartment_id=COMPARTMENT_ID
    ).data

    if not file_systems:
        print("No file systems found.")
        return

    for fs in file_systems:
        current_kms = fs.kms_key_id
        fs_name = fs.display_name or fs.id

        print(f"\nFile system: {fs_name}")
        print(f"  OCID: {fs.id}")
        print(f"  Current kms_key_id: {current_kms}")

        if current_kms == TARGET_KMS_KEY_OCID:
            print("  Status: OK (already using target CMK).")
            continue

        if DRY_RUN:
            print("  Action: Would update to target CMK (dry run).")
            continue

        # Prepare update details
        update_details = oci.file_storage.models.UpdateFileSystemDetails(
            kms_key_id=TARGET_KMS_KEY_OCID
        )

        try:
            response = fss_client.update_file_system(
                file_system_id=fs.id,
                update_file_system_details=update_details
            )
            print("  Action: Updated kms_key_id to target CMK.")
        except Exception as e:
            print(f"  ERROR: Failed to update kms_key_id: {e}")


if __name__ == "__main__":
    main()

4. How to Use This for Monitoring + Remediation​

  1. Monitoring (Detection):

    • Run the script periodically with DRY_RUN = True (e.g., via cron, OCI Functions, or OCI DevOps job).
    • Log or alert on any file system where current_kms != TARGET_KMS_KEY_OCID.

  2. Automated Remediation:

    • Run the same script with DRY_RUN = False on a schedule or triggered by an event rule (e.g., when a new file system is created).
    • Ensure the principal running the script has:
      • MANAGE file-family in the compartment.
      • USE key-family on the Vault key.

5. Minimal IAM Policy Examples​

In the compartment with file systems:

Allow group fss-admins to manage file-family in compartment <compartment-name>

For the Vault/key:

Allow group fss-admins to use keys in compartment <vault-compartment-name>

You can now continuously monitor and remediate “OCI Storage File Systems Should Be Encrypted With Customer-Managed Keys” using this Python approach.

Using Terraform
# Customer-managed key (CMK) in KMS to use for the File Storage encryption
# Replace the placeholder OCIDs with your own.
data "oci_kms_key" "cmk_for_fss" {
  # REQUIRED: OCID of the vault containing the key
  management_endpoint = "https://KMS_ENDPOINT_IN_VAULT_REGION" # e.g. https://acme-kms-vault-kms.us-ashburn-1.oraclecloud.com

  key_id = "OCID_OF_CUSTOMER_MANAGED_KEY"
}

resource "oci_file_storage_file_system" "this" {
  availability_domain = "AVAILABILITY_DOMAIN_NAME" # e.g. "kIdk:US-ASHBURN-AD-1"
  compartment_id      = "OCID_OF_COMPARTMENT"
  display_name        = "FILE_SYSTEM_NAME"

  # This enforces encryption with a customer-managed key (CMK)
  kms_key_id = data.oci_kms_key.cmk_for_fss.id

  # add any other arguments you already manage here (freeform_tags, defined_tags, etc.)
}

Changing or adding kms_key_id on an existing oci_file_storage_file_system forces replacement of the file system; this is a destructive change that requires data migration to the new file system before decommissioning the old one.

For verification, terraform plan should show the oci_file_storage_file_system either being created (if new) or replaced with kms_key_id set to the CMK OCID instead of using the default Oracle-managed encryption.