More Info:
Credentials for users inactive for 90+ days should be disabled. Dormant accounts with active credentials are prime targets for attackers since suspicious activity may go unnoticed.Risk Level
MediumAddress
Compliance, SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS AWS
- CIS Critical Security Controls v8
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- Cloudanix Best Practice
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- GDPR
- HIPAA
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SOC2
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Using Console
Using Console
Below are the exact console steps to remediate the “OCI IAM Unused User Credentials Should Be Disabled” finding, assuming it comes from IAM Monitoring / Security Advisor / Cloud Guard.
If you share which credential type (API key, auth token, console password, etc.) the IAM Monitoring alert is about, I can give a one‑page, credential‑specific version of the steps.
1. Identify the affected user and credential type
- Sign in to the OCI Console.
- Open the Navigation Menu → Identity & Security → Identity → Users.
- Locate the user flagged by IAM Monitoring:
- Use the Search box if needed.
- Click the user name to open the User Details page.
2. Disable unused Console password (local user)
Applies only to local OCI users (not IdP‑federated).
- On the user’s page, in the Resources panel, click Auth Tokens / Customer Secret Keys / API Keys / Console Access (names may vary slightly by tenancy / console version).
- For console password, either:
- Disable the user (hard stop for console login), or
- Remove/clear the local password (if shown as a dedicated option).
- To fully block console access for that user, under User Details:
- Set User Status to Inactive (or use Disable action from the user list).
3. Revoke unused API keys
- Still on the user’s details page, in Resources, click API Keys.
- Review the keys; for each unused key (as indicated by IAM Monitoring finding / last used metadata):
- Click the Actions (⋮) menu next to the key.
- Click Delete and confirm.
4. Revoke unused Auth Tokens
- In Resources, click Auth Tokens.
- For each token identified as unused:
- Click Revoke (or Delete) from the Actions (⋮) menu.
- Confirm the revocation.
5. Revoke unused SMTP credentials (if any)
- In Resources, click SMTP Credentials (or Email Delivery Credentials).
- For each credential set flagged as unused:
- Click Revoke or Delete in the Actions (⋮) menu.
- Confirm.
6. Revoke unused Customer Secret Keys (Object Storage/Signing keys)
- In Resources, click Customer Secret Keys.
- For each key found unused:
- Click Revoke or Delete from the Actions (⋮) menu.
- Confirm.
7. (Optional) Fully disable or delete dormant users
If all credentials are unused and the user is no longer needed:- Go back to Identity & Security → Identity → Users.
- Find the user.
- From the Actions (⋮) menu on the right:
- Choose Disable to deactivate the user, or
- Delete if you’re sure the identity is no longer required.
8. Re-check the IAM Monitoring finding
- Go to Identity & Security → Security Center / Cloud Guard / Security Advisor (depending on your setup).
- Locate the original “Unused User Credentials Should Be Disabled” problem.
- Mark it as Resolved or wait for the next evaluation cycle to confirm the status is Closed, depending on the service behavior.
If you share which credential type (API key, auth token, console password, etc.) the IAM Monitoring alert is about, I can give a one‑page, credential‑specific version of the steps.
Using CLI
Using CLI
Below is a concise, CLI-focused way to identify and disable unused IAM user credentials in OCI, suitable for wiring into monitoring/remediation.Assumptions:
This gives you a full CLI-based remediation loop for “OCI IAM Unused User Credentials Should Be Disabled.”
- You already know your compartment OCID (for listing users).
- “Unused” means “user not seen in Audit logs in X days” (e.g., 90).
- You want to disable the user account and/or delete access keys/tokens.
1. Set variables
2. Get all IAM users in the compartment
3. Function to check if a user has activity in the last N days
This uses the Audit service to see if any events were generated by this user.4. Disable unused users and remove their programmatic credentials
Warning: This will disable users and remove keys/tokens. Test first with echo-only.5. (Optional) Only disable credentials, not the user
If your policy says “disable credentials but keep user active”:- Keep user
--stateasACTIVE. - Only delete API keys / Auth Tokens / SMTP credentials (steps 4.1–4.3).
- Optionally, force a console password reset:
6. Integrate with Monitoring / Scheduled Remediation
- Put this logic in a script (e.g.,
disable-unused-iam-users.sh). - Run from:
- An OCI Compute instance with a dynamic group + policy to manage IAM, or
- Cloud Shell on a schedule via an external scheduler (e.g., Jenkins, GitHub Actions).
- Ensure IAM policy (in root compartment or relevant one) permits:
Using Python
Using Python
Below is one practical way to do this with Python + OCI SDK:
- Detect IAM users with no activity for N days (via Audit service)
- For those users:
- Deactivate their API keys
- Delete their auth tokens
- Optionally disable the user account (
lifecycle_state = INACTIVE)
1. Prerequisites
-
Install the OCI Python SDK:
-
Configure your OCI CLI/SDK config (e.g.
~/.oci/config): -
The principal (user or instance principal) running the script needs IAM policies like:
If you want to set users to INACTIVE:
2. Logic Overview
- List all IAM users.
- For each user:
- Query Audit events for that user in the last
Ndays. - If no events in that period, consider credentials “unused.”
- Query Audit events for that user in the last
- For such users:
- List API keys and deactivate/delete them.
- List auth tokens and delete them.
- (Optional) set user
lifecycle_statetoINACTIVE.
INACTIVITY_DAYS(e.g., 90).- Whether you disable specific credentials or entire user.
3. Example Python Script
4. How to Use / Adapt
- Edit the config section at top:
PROFILE,INACTIVITY_DAYS,DRY_RUN,DISABLE_USER.
- Run once in
DRY_RUN = Trueto verify behavior. - When satisfied:
- Set
DRY_RUN = False. - Optionally
DISABLE_USER = Trueif you want to fully disable users.
- Set
- Schedule the script (e.g., cron, OCI Functions, or OCI DevOps job) to enforce “unused credentials disabled” continuously.
- whether you’re using Identity Domains, and
- whether you want to only disable API keys/tokens or also console passwords,
Using Terraform
Using Terraform
Terraform cannot disable or rotate OCI IAM user credentials based on “unused for 90+ days” because that condition depends on runtime activity (last-used timestamps), which the provider does not expose as arguments.You can:
- Use Cloud Guard or custom scripts (SDK/CLI) to detect users/API keys not used in 90+ days, and
- Manually or programmatically disable those credentials via Console/CLI/SDK (e.g., deactivate API keys, disable the user).
oci_identity_user or related Terraform resources, so terraform plan will show no relevant configurable argument for “inactive for 90 days” or similar.
