Skip to main content

🛡️ Oracle IAM Auth Tokens are not rotated every 90 days🟢

  • Contextual name: 🛡️ IAM Auth Tokens are not rotated every 90 days🟢
  • ID: /ce/ca/oracle/iam/auth-tokens-are-not-rotated-every-90-days
  • Tags:
  • Policy Type: COMPLIANCE_POLICY
  • Policy Categories: SECURITY

Stats​

not available

Logic​

Similar Policies​

  • Internal: dec-x-2e85e7c5

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-x-2e85e7c51

Description​

Open File

Description​

This policy identifies Oracle IAM auth tokens that were created more than 90 days ago. Auth tokens are long-term credentials used to authenticate with services that do not support Oracle Cloud Infrastructure signature-based authentication.

Rationale​

Auth tokens provide access at the same authorization level as the associated user for supported services. Rotating them at least every 90 days limits the time a compromised token can be used and supports a predictable credential lifecycle for users, applications, and integrations.

Impact​

Rotating an auth token can disrupt applications, integrations, or users that still depend on the old token. Because the token value is only available when the token is created, create a replacement token, update dependent workloads, and confirm access before deleting the stale token.

Audit​

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

Remediation​

Open File

Remediation​

Rotate Stale Auth Tokens​

Create a replacement auth token for the affected user, update every dependent workload to use the new token, and delete the stale token after confirming that it is no longer required.

From OCI Console​
  1. Open Identity & Security.
  2. Open the affected identity domain.
  3. Open Users and select the affected user.
  4. Open Auth tokens.
  5. Generate a replacement auth token and store the token value securely.
  6. Update dependent applications, scripts, or integrations to use the replacement token.
  7. Delete auth tokens older than 90 days after confirming they are no longer used.
From OCI CLI​

List the user's auth tokens:

oci iam auth-token list --user-id {{user-ocid}} --all

Create a replacement auth token:

oci iam auth-token create \
    --user-id {{user-ocid}} \
    --description {{new-token-description}}

Update dependent workloads to use the replacement token. After confirming that the stale token is no longer used, delete it:

oci iam auth-token delete \

... [see more](remediation.md)

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 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.89no 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.1111no data
💼 APRA CPG 234 → 💼 36e hardware and software asset controls —appropriate authorisation to prevent security compromises from unauthorised hardware and software assets;4464no data
💼 APRA CPG 234 → 💼 44c loss of, or unauthorised access to, encryption keys safeguarding extremely critical or sensitive information assets.1113no 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;56no data
💼 CIS Oracle v3.1.0 → 💼 1.10 Ensure user auth tokens rotate within 90 days or less - Level 1 (Automated)11no data
💼 Cloudaware Framework → 💼 Credential Lifecycle Management36no data
💼 FedRAMP High Security Controls → 💼 AC-2(3) Disable Accounts (M)(H)9no data
💼 FedRAMP High Security Controls → 💼 CM-7(1) Periodic Review (M)(H)1819no data
💼 FedRAMP Moderate Security Controls → 💼 AC-2(3) Disable Accounts (M)(H)9no data
💼 FedRAMP Moderate Security Controls → 💼 CM-7(1) Periodic Review (M)(H)19no data
💼 ISO/IEC 27001:2013 → 💼 A.9.2.2 User access provisioning66no data
💼 ISO/IEC 27001:2013 → 💼 A.9.2.4 Management of secret authentication information of users1012no data
💼 ISO/IEC 27001:2022 → 💼 5.17 Authentication information44no data
💼 ISO/IEC 27001:2022 → 💼 8.1 User end point devices1431no data
💼 ISO/IEC 27001:2022 → 💼 8.9 Configuration management617no data
💼 NIST CSF v1.1 → 💼 PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes2237no 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)2428no data
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization50no data
💼 NIST CSF v2.0 → 💼 PR.AA-03: Users, services, and hardware are authenticated102no 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 duties199no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-2(3) Account Management _ Disable Accounts49no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-7(1) Least Functionality _ Periodic Review33no data