Skip to main content

More Info:

OCI Vaults should be in an active, healthy state with a secure vault type (DEFAULT or VIRTUAL_PRIVATE). Vaults in degraded states may fail to serve encryption operations.

Risk Level

High

Address

Compliance, Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • AWS Startup Security Baseline
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • Cloudanix Best Practice
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Using Console

Follow these steps in the OCI Console to ensure vaults are in Active and Secure state so they pass encryption monitoring checks:

1. Find vaults that are not Active/Secure

  1. Sign in to the OCI Console.
  2. In the top left, open the Navigation Menu.
  3. Go to Identity & Security → Vault.
  4. Select the Compartment where your vaults reside (top left compartment selector).
  5. In the vault list, check the Lifecycle state column:
    • Look for states like Pending deletion, Creating, Deleted, or Failed.
  6. Also check the Vault type and any security-related configuration (network access, key management).

2. Cancel deletion for vaults in “Pending deletion”

If a vault is in Pending deletion, monitoring tools will flag it as not Active/Secure.
  1. Click the vault name.
  2. On the vault details page, check Lifecycle state.
  3. If it is Pending deletion, click Cancel deletion (button near the top).
  4. Confirm the action.
  5. Wait until the Lifecycle state becomes Active.
If Cancel deletion is not available (e.g., close to or past deletion time), you will need to:
  • Create a new vault (see next section) and
  • Re-create keys and update applications to use the new vault.

3. Create a new Active vault if needed

If a vault is deleted or unusable:
  1. Go to Identity & Security → Vault.
  2. Click Create vault.
  3. Fill in:
    • Name: meaningful name.
    • Compartment: choose correct compartment.
    • Type:
      • Default (Oracle-managed HSM) or Virtual Private (Dedicated) depending on your security requirements.
    • Protection mode: choose as per your policy.
  4. Optionally configure:
    • Network access (if using private endpoint; prefer private where your policy requires it).
  5. Click Create vault.
  6. Wait until Lifecycle state is Active.
Update all services and apps to use this new vault & keys.

4. Tighten security configuration (“Secure” state)

To be considered “secure” by typical monitoring baselines, ensure:
  1. Access control (IAM):
    • Go to Identity & Security → Policies.
    • Restrict vault access to minimum required groups.
    • Avoid broad policies like allow group X to manage all-resources in tenancy if not needed.
  2. Key management:
    • Inside the vault, go to Master Encryption Keys.
    • Use Customer-managed keys for sensitive data.
    • Configure key rotation:
      • Open a key → Key Protection or Rotation settings → enable and set an appropriate rotation interval.
  3. Network exposure (for virtual private vaults):
    • If available, prefer private endpoints controlled with security lists/NSGs.
    • Avoid unnecessary public access paths.

5. Verify remediation in Encryption Monitoring

  1. After changes propagate (a few minutes), go to your OCI Security/Monitoring tool (e.g., Cloud Guard, Security Zones, or external CSPM).
  2. Re-run or refresh the OCI Encryption Monitoring checks.
  3. Confirm the finding for “OCI Encryption Vaults Should Be In Active And Secure State” is cleared or marked as remediated.

If you tell me which monitoring product is raising this control (Cloud Guard, Security Zones, or third-party CSPM), I can map the above steps exactly to that tool’s requirement.
Below is how to remediate and enforce “OCI Encryption Vaults Should Be In Active And Secure State” using OCI CLI, assuming:
  • Active = vault lifecycle state is ACTIVE (not PENDING_DELETION / DELETED)
  • Secure = vault type is HSM-backed (PROTECTION_MODE_HSM) and keys are ENABLED

0. Prerequisites

  1. OCI CLI installed and configured:
  2. Have these values handy (or replace with your own):

1. List All Vaults and Check Their State

  • You want:
    • lifecycle-state = ACTIVE
    • vault-type = DEFAULT or VIRTUAL_PRIVATE (both are valid types; “secure” comes from HSM-backed keys rather than vault-type)
If any vaults show PENDING_DELETION, remediate in step 2.

2. Cancel Vaults in Pending Deletion (So They Become Active)

Get vaults in PENDING_DELETION:
For each id returned, cancel pending deletion:
Verify the state is now ACTIVE:

3. Ensure Keys in the Vault Are in Secure (HSM) and Enabled State

List keys for a specific vault:
You want:
  • lifecycle-state = ENABLED
  • protection-mode = HSM (this is what typically satisfies “secure”)

3.1 Enable Any Disabled Keys

Find DISABLED keys:
For each id:
Verify:

3.2 Recreate Non-HSM Keys as HSM Keys (If Required)

You cannot change protection-mode of an existing key.
If compliance requires HSM, create new HSM-backed keys and migrate usage to them.
Create an HSM key in the vault:
Confirm:
Then:
  • Update any services that used SOFTWARE keys to use these new HSM keys.
  • Optionally schedule deletion of old (non-HSM) keys once unused.

4. (Optional) Create New “Compliant” Vaults

If some vaults cannot be recovered or you want dedicated, clean ones:
After creation, create only HSM-backed keys in it (step 3.2).

5. Scriptable Remediation (Bulk)

Example shell skeleton to auto-cancel pending deletions and list non-secure keys:
Use the last list to manually fix keys (enable or recreate as HSM).
If you share the exact policy/rule text or tool generating this finding, I can adjust the CLI steps to match its exact definition of “active” and “secure.”
Below is how to handle this using Python and the OCI SDK: both to monitor vault state and to remediate what’s actually remediable.
Important: In OCI you cannot “undelete” a vault that is already in PENDING_DELETION or DELETED. For those, remediation is to create a new vault and re-point workloads.

1. Prerequisites

  1. Install OCI Python SDK:
  1. Make sure you have a working OCI config file (~/.oci/config) with:
  • tenancy
  • user
  • fingerprint
  • key_file
  • region
  • profile (e.g., DEFAULT)

2. What “Active and Secure” means in practice

For OCI Vaults, minimal checks:
  • lifecycle_state == "ACTIVE"
  • is_primary vault (if you use replication, ensure primary is healthy)
  • Not PENDING_DELETION
  • Optionally: ensure keys inside vault are ENABLED and not pending deletion.
You cannot change lifecycle from DELETED/PENDING_DELETION back to ACTIVE. So:
  • Non-remediable: PENDING_DELETION or DELETED → must create a new vault and migrate.
  • Remediable: misconfig around monitoring, key states, policy, etc.
Below are Python examples to:
  1. Monitor vault states and keys.
  2. Create a replacement vault when you detect a non-secure one.
  3. Optionally export findings for your monitoring.

3. Python: List and Check Vaults

Use this in a scheduled job (Cron, OCI Functions, or OCI Scheduled Jobs) and push results into your monitoring stack (OCI Logging, OCI Monitoring, Prometheus, etc.).

4. Optional: Check Keys Inside Vaults

A vault may be ACTIVE but the keys inside are DISABLED or PENDING_DELETION. This can break encryption operations.

5. Remediation Strategy via Python

5.1. If Vault is PENDING_DELETION or DELETED

You cannot move it back to ACTIVE. Remediation:
  1. Create a new vault.
  2. Create equivalent keys.
  3. Reconfigure apps/services to use the new vault/keys.
  4. Decommission old references.
Example: create a new vault (Python):
Then re-create keys:
After that, update:
  • Block storage, File Storage, Object Storage, DB, etc., to point to the new vault/key OCID.
This “re-pointing” is service-specific and usually done via each resource’s update API or console.

6. Enabling Disabled Keys (Remediable)

If a key is DISABLED but you want it active again:
You can combine this with the audit loop: when a key is found DISABLED, you decide (by policy) whether to auto-enable or just alert.

7. Wiring to Monitoring

To integrate with “OCI Encryption Monitoring”:
  • Run the check scripts on a schedule (e.g., OCI Functions + OCI Events, or an external scheduler).
  • For each vault/key that fails your “secure” criteria:
    • Log a structured JSON line with vault_id, key_id, state, reason.
    • Publish metrics via OCI Monitoring’s put_metric_data if you want dashboards/alarms (e.g., non_secure_vault_count).
Skeleton for sending a custom metric:
Example:

8. Summary Remediation Process

  1. Use the Python scripts above to list all vaults and keys.
  2. Flag anything not ACTIVE (vault) or not ENABLED (key).
  3. For:
    • PENDING_DELETION/DELETED vaults → create new vault + keys, update all dependent resources.
    • DISABLED keys (where policy allows) → call enable_key.
  4. Feed results to OCI Monitoring/Logging so you can alarm on non-secure states.
If you share your exact “secure state” policy (e.g., specific algorithms, minimum key length, rotation rules), I can extend the Python checks and remediation steps to match it exactly.
Notes:
  • vault_type is only set at creation; changing it in Terraform forces replacement of the vault and all keys/objects in it. This is an outage-scale, irreversible change.
  • Vault “health/active” state (e.g., degraded vs healthy) is an OCI runtime property and cannot be forced or repaired via Terraform; you must use the OCI Console and/or support to recover a degraded vault.
Verification with terraform plan:
  • For an existing vault with a non‑secure or different vault_type, the plan will show the existing oci_kms_vault being destroyed and a new one created with vault_type = "VIRTUAL_PRIVATE" (or "DEFAULT"), and no other unrelated changes.