🛡️ Oracle IAM Customer Secret Keys are not rotated every 90 days🟢

• Contextual name: 🛡️ IAM Customer Secret Keys are not rotated every 90 days🟢
• ID: /ce/ca/oracle/iam/customer-secrets-are-not-rotated-every-90-days
• Tags:
  • 🟢 Policy with categories
  • 🟢 Policy with type
  • 🟢 Production policy
• Policy Type: COMPLIANCE_POLICY
• Policy Categories: SECURITY

Stats

not available

Logic

• 🧠 prod.logic.yaml🟢
  • 📗 Oracle IAM Customer Secret
  • 🔌 Oracle IAM Customer Secret - object.extracts.yaml
  • 🧪 test-data.json

Similar Policies

• Internal: dec-x-087d4ffc

Similar Internal Rules

Rule	Policies	Flags
✉️ dec-x-087d4ffc	1

Description

Open File

Description

This policy identifies Oracle IAM customer secret keys that were created more than 90 days ago.

Rationale

Oracle IAM customer secret keys are used by Amazon S3-compatible clients to authenticate to OCI Object Storage. These credentials do not expire automatically, so an exposed or forgotten key can continue to provide access until it is deleted or replaced. Rotating customer secret keys on a defined schedule reduces the amount of time a compromised key can be used, helps remove stale credentials from applications and integrations, and supports regular validation of who still requires S3-compatible Object Storage access.

Impact

Rotating a customer secret key can disrupt applications, integrations, or users that still depend on the old key. Create a replacement key, update all dependent workloads, and confirm Object Storage access before deleting the stale key.

Audit

This policy flags an Oracle IAM Customer Secret as INCOMPLIANT if the Time Created field is more than 90 days old.

Remediation

Open File

Remediation

Rotate Stale Customer Secret Keys

Create a replacement customer secret key, update every dependent workload to use the new key, and delete the stale key after confirming that it is no longer required. Because customer secret keys are long-term credentials, avoid extending the life of the stale key after the replacement has been validated.

From OCI CLI

List the user's customer secret keys:

oci iam customer-secret-key list --user-id {{user-ocid}} --all

Create a replacement customer secret key:

oci iam customer-secret-key create \
    --user-id {{user-ocid}} \
    --display-name {{new-key-name}}

Update applications, integrations, and users to use the replacement key. After confirming that Object Storage access works with the replacement key and the stale key is no longer used, delete the stale key:

oci iam customer-secret-key delete \
    --user-id {{user-ocid}} \
    --customer-secret-key-id {{stale-key-id}}

policy.yaml

Open File

Linked Framework Sections

Section	Sub Sections	Internal Rules	Policies	Flags	Compliance
💼 APRA CPG 234 → 💼 4 Cryptographic key management refers to the generation, distribution, storage, renewal, revocation, recovery, archiving and destruction of encryption keys. Effective cryptographic key management ensures that controls are in place to reduce the risk of compromise of the security of cryptographic keys. Any compromise of the security of cryptographic keys could, in turn, lead to a compromise of the security of the information assets protected by the cryptographic technique deployed.		8	9		no data
💼 APRA CPG 234 → 💼 4 Regulated entities would typically put in place processes to ensure that identities and credentials are issued, managed, verified, revoked and audited for authorised devices, users and software/processes.		11	11		no data
💼 APRA CPG 234 → 💼 36e hardware and software asset controls —appropriate authorisation to prevent security compromises from unauthorised hardware and software assets;		44	64		no data
💼 APRA CPG 234 → 💼 44c loss of, or unauthorised access to, encryption keys safeguarding extremely critical or sensitive information assets.		11	13		no data
💼 APRA CPG 234 → 💼 d. predefined activation and deactivation dates for cryptographic keys, limiting the period of time they remain valid for use. The period of time a cryptographic key remains valid would be commensurate with the risk;		5	6		no data
💼 CIS Oracle v3.1.0 → 💼 1.9 Ensure user customer secret keys rotate every 90 days - Level 1 (Automated)			1		no data
💼 Cloudaware Framework → 💼 Credential Lifecycle Management			36		no data
💼 FedRAMP High Security Controls → 💼 AC-2(3) Disable Accounts (M)(H)			9		no data
💼 FedRAMP High Security Controls → 💼 CM-7(1) Periodic Review (M)(H)		18	19		no data
💼 FedRAMP Moderate Security Controls → 💼 AC-2(3) Disable Accounts (M)(H)			9		no data
💼 FedRAMP Moderate Security Controls → 💼 CM-7(1) Periodic Review (M)(H)			19		no data
💼 ISO/IEC 27001:2013 → 💼 A.9.2.2 User access provisioning		6	6		no data
💼 ISO/IEC 27001:2013 → 💼 A.9.2.4 Management of secret authentication information of users		10	12		no data
💼 ISO/IEC 27001:2022 → 💼 5.17 Authentication information		4	4		no data
💼 ISO/IEC 27001:2022 → 💼 8.1 User end point devices		14	31		no data
💼 ISO/IEC 27001:2022 → 💼 8.9 Configuration management		6	17		no data
💼 NIST CSF v1.1 → 💼 PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes		22	37		no data
💼 NIST CSF v1.1 → 💼 PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals' security and privacy risks and other organizational risks)		24	28		no data
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization			50		no data
💼 NIST CSF v2.0 → 💼 PR.AA-03: Users, services, and hardware are authenticated			102		no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties			199		no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-2(3) Account Management _ Disable Accounts		4	9		no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-7(1) Least Functionality _ Periodic Review		3	3		no data