> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# OCI Storage File Systems Should Be Encrypted With Customer-Managed Keys

### 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

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Using Console" defaultOpen="true">
        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.
      </Accordion>

      <Accordion title="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:

        ```bash theme={null}
        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)

        ```bash theme={null}
        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`

        ```bash theme={null}
        export VAULT_OCID="ocid1.vault.oc1..xxxx"
        export MGMT_ENDPOINT="https://management-kms.us-ashburn-1.oraclecloud.com"
        ```

        ### 2.2 Create a Key

        ```bash theme={null}
        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:

        ```bash theme={null}
        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:

        ```bash theme={null}
        oci fs file-system list \
          --compartment-id "$COMPARTMENT_OCID" \
          --all
        ```

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

        ```bash theme={null}
        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:

        ```bash theme={null}
        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:

        ```bash theme={null}
        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

        ```bash theme={null}
        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:

        ```bash theme={null}
        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

        ```bash theme={null}
        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`):

           ```bash theme={null}
           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:

           ```bash theme={null}
           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:

        ```bash theme={null}
        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:

        ```bash theme={null}
        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.
      </Accordion>

      <Accordion title="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:
           ```bash theme={null}
           pip install oci
           ```

        2. Configure your OCI CLI/config file (used by the SDK):
           `~/.oci/config` with at least:
           ```ini theme={null}
           [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

        ```python theme={null}
        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:

        ```text theme={null}
        Allow group fss-admins to manage file-family in compartment <compartment-name>
        ```

        For the **Vault/key**:

        ```text theme={null}
        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.
      </Accordion>

      <Accordion title="Using Terraform">
        ```hcl theme={null}
        # 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.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>