More Info:
A deny policy statement should prevent administrators from modifying the admin group membership. This prevents privilege escalation by ensuring no single admin can grant themselves additional access.Risk Level
MediumAddress
Compliance, SecurityCompliance Standards
- APRA CPS 234 (Australia)
- 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
Remediation
Using Console
Using Console
Below is how to remediate the finding “OCI IAM Admin Group Should Be Protected From Self-Modification” using the OCI Console.The goal:
No group that has permission to manage IAM groups/administrators should be able to change its own membership or policies directly.
(Adjust to your requirements, but ensure this group can manage groups/users/policies.)
This configuration ensures that the OCI IAM admin group is protected from self-modification, satisfying the monitoring/control requirement while preserving an administrative path through a separate IAM-admin group or root identity.
No group that has permission to manage IAM groups/administrators should be able to change its own membership or policies directly.
1. Identify the High‑Privilege Admin Group
- Sign in to the OCI Console as a tenancy administrator (or root user).
- Open the navigation menu → Identity & Security → Identity → Groups.
- Locate the group that is flagged (often called
Administratorsor similar).
Note its exact name; assume it’sAdministratorsfor the examples below.
2. Check Current Policies That Let It Manage Itself
- Navigation menu → Identity & Security → Identity → Policies.
- Filter or search policies where the Subject (left side of the statement) includes the admin group, e.g.:
Allow group Administrators to manage all-resources in tenancyAllow group Administrators to manage groups in tenancy
- For each such policy, verify whether it allows this group to:
- manage
groups - manage
users - manage
policies - manage
tenancyorall-resources(which implicitly includes groups).
- manage
3. Create a Separate IAM Admin Group (if you don’t already have one)
If you don’t already have a dedicated group for IAM management that is different from the group you want to protect:- Go to Identity & Security → Identity → Groups → Create Group.
- Name it something like
IAM-Admins. - Add at least one trusted admin user to this group:
- Go to Identity & Security → Identity → Users.
- Open a user you trust.
- Under Groups, click Add User to Group → select
IAM-Admins→ Add.
4. Move IAM Management Permissions Off the Protected Group
4.1. Create a Policy for the IAM-Admins Group
- Go to Identity & Security → Identity → Policies → Create Policy.
- Place it in the root compartment (so it can manage tenancy-level IAM).
- Give it a name like
policy-iam-admins. - In the Policy Builder, add statements such as:
- Click Create.
4.2. Remove or Restrict IAM Management from the Original Admin Group
For each policy that currently grants IAM powers to the protected group (e.g.,Administrators):- Open the policy.
- Click Edit Policy Statements.
-
Either:
-
Remove statements such as:
- Or narrow them to exclude IAM resources (e.g., change to manage only specific non-IAM resources/compartments).
-
Remove statements such as:
- Save the edited policy.
Administrators group (or equivalent) no longer has the ability to modify groups, users, or policies, including itself.5. Optionally Add a Condition to Explicitly Protect the Group (Advanced)
If you want more granular control (for example, other groups can manage groups but not the critical admin group):-
In the policy for
IAM-Admins, you can use a condition to protect theAdministratorsgroup: -
Edit the
IAM-Adminspolicy and replace the genericmanage groupsline with the conditional one above. - Save the policy.
IAM-Admins can manage groups except the protected one; any change to the protected group can only be done by higher-trust mechanisms (e.g., root user or a break-glass identity).6. Validate
-
Log in as a member of the protected admin group (e.g.,
Administrators). -
Confirm:
- They cannot:
- Add/remove users to/from their own group.
- Edit policies that grant themselves IAM control.
- But they can still perform whatever non-IAM tasks you intended for them (if any).
- They cannot:
-
Log in as a member of
IAM-Admins:- Confirm they can manage other groups/policies as designed.
This configuration ensures that the OCI IAM admin group is protected from self-modification, satisfying the monitoring/control requirement while preserving an administrative path through a separate IAM-admin group or root identity.
Using CLI
Using CLI
Below is how to remediate the issue “OCI IAM Admin Group Should Be Protected From Self-Modification” using OCI CLI. The main idea is:
You will also need the tenancy OCID:
For each policy ID, inspect statements:Find and note the specific statements that give the
Add at least one trusted user to this group (replace
5. Create new IAM policy for the
Define a policy that gives
6. Remove IAM-management permissions from the
For each policy that currently gives IAM‑management to Edit Leave all other non‑IAM permissions intact.Repeat this for every affected policy.After this, the
You can refine the grep for specific IAM verbs/resources as needed and alert if any match is found.
These steps remove IAM self‑modification capability from the admin/default group and place it under a separate controlled group, satisfying the control “OCI IAM Admin Group Should Be Protected From Self-Modification,” and all changes are done using OCI CLI.
- Remove “IAM‑management” permissions from your general admin group (typically
Administrators) - Create a separate
iam-adminsgroup that manages IAM - Optionally script a check (monitoring) with OCI CLI to ensure the problem doesn’t return
1. Prerequisites
Make sure OCI CLI is configured and you have a user with enough permission to modify policies and groups at the tenancy level.2. Identify the “Administrators” group
3. List all policies in the tenancy and find IAM‑related permissions for the admin group
You’re looking for statements like:Allow group Administrators to manage users in tenancyAllow group Administrators to manage groups in tenancyAllow group Administrators to manage policies in tenancyAllow group Administrators to manage dynamic-groups in tenancy- etc.
Administrators group the ability to manage IAM resources (users, groups, policies, dynamic-groups, identity-providers, tag-namespaces, etc.).4. Create a dedicated IAM admin group
Create a new group for IAM management (example name:iam-admins):<user_ocid>):5. Create new IAM policy for the iam-admins group
Define a policy that gives iam-admins the IAM management powers you are about to remove from Administrators:Example (adjust as needed):6. Remove IAM-management permissions from the Administrators group
For each policy that currently gives IAM‑management to Administrators, you must:- Download current statements.
- Remove/adjust the lines giving IAM management to
Administrators. - Update the policy with the modified list.
6.1 Export current statements
policy-statements.json locally and delete any line like:6.2 Update the policy
Administrators group can no longer modify IAM (including itself); IAM changes are now only possible via iam-admins.7. (Optional) Basic CLI-based monitoring script
You can periodically check (e.g., via cron/OCI Functions) that no new policy grants IAM‑manage rights toAdministrators.Example check (Linux shell):These steps remove IAM self‑modification capability from the admin/default group and place it under a separate controlled group, satisfying the control “OCI IAM Admin Group Should Be Protected From Self-Modification,” and all changes are done using OCI CLI.
Using Python
Using Python
Below are (1) the IAM remediation steps in OCI and (2) a Python example you can use for monitoring / detection.
You want to:Or, if using conditional policies (Identity Domains / advanced conditions), you can be more explicit, e.g.:The exact condition keys vary slightly by domain type; check OCI docs for “IAM policy conditions” to confirm
If you share a sample of your current policy statements for the admin group, I can adjust the detection logic and give an exact “before/after” policy example.
1. Remediation concept in OCI
Goal: Ensure your “Admin” group cannot modify its own membership, policies, or other IAM primitives that control itself.Step 1 – Identify your admin group(s)
Typical names:AdministratorsSecurityAdmins- Or any group that:
- can
manage all-resources in tenancy, or - can
manage groups/manage policies/manage users.
- can
- Go to Identity & Security → Domains (or Identity → Groups in classic).
- Open each candidate group (e.g.,
Administrators). - Note the group name and OCID.
Step 2 – Create a separate “IAM Security” group (recommended)
Create a new group to own IAM administration (and especially the admin group itself):- In Identity → Groups, click Create group.
- Name it something like
IAM-Security-Admins. - Add only your highest-trust break-glass users.
Step 3 – Adjust policies so Admin group cannot self‑modify
Find all tenancy (root) policies that give your admin group broad permissions. Common risky statements:- Remove or narrow these for the Admin group.
- Move IAM-management privileges to
IAM-Security-Admins. - Optionally, use a condition to explicitly deny managing the Admin group.
target.group.name / target.iam.group.name in your environment.Key point: the admin group should not have permission to:manage groupson itself, ormanage policiesthat define its own power, or- broad
manage all-resourcesincluding identity, unless constrained with conditions.
2. Python monitoring for “self‑modifiable” admin groups (OCI SDK)
This script does detection (for monitoring). It scans tenancy policies and flags lines where an admin group has risky powers likemanage all-resources, manage groups, or manage policies without any condition.2.1. Prerequisites
- Install OCI Python SDK:
- Have a working OCI config (e.g.,
~/.oci/config) with a profile that canreadpolicies at tenancy level:
2.2. Python example
2.3. How to use this for continuous monitoring
- Run this script on a schedule (e.g., with:
- OCI Functions + Events,
- a cron job on a bastion / CI runner,
- or an OCI DevOps pipeline).
- When
risky_findingsis non-empty:- Notify security / cloud team.
- Manually update the flagged policies as described in Section 1.
If you share a sample of your current policy statements for the admin group, I can adjust the detection logic and give an exact “before/after” policy example.
Using Terraform
Using Terraform
terraform plan should show the oci_identity_policy.IAM_ADMIN_GROUP_PROTECTION resource with an updated statements attribute including the new Deny group Administrators to manage groups in tenancy where target.group.name = 'Administrators' entry and no resource replacement (-/+ or +/-) for this policy.
