Skip to main content

More Info:

Flag any IAM policy statement that grants broad verbs (manage/use) across all-resources to unconstrained groups. Wildcard administrative grants are the most critical vulnerability in identity perimeters.

Risk Level

Critical

Address

Compliance, Security

Compliance 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

Using Console

Below are concise, console-focused steps to remediate the issue “OCI Governance Policies Should Not Grant Unrestricted Resource Access” for OCI Governance Monitoring, by tightening IAM policies to least privilege.

1. Identify the Problem Policies

  1. Sign in to the OCI Console.
  2. Open the navigation menu → Identity & SecurityPolicies.
  3. Ensure you are in the root compartment (or the compartment where your Governance policies are defined).
  4. Look for policies related to:
    • governance-monitoring
    • governance-rule-family
    • or any policy used by your Governance Monitoring dynamic group or user group.
  5. Open each candidate policy and look for overly broad statements, such as:
    • Allow group <name> to manage all-resources in tenancy
    • Allow dynamic-group <name> to manage all-resources in compartment <name>
    • or use of manage with all-resources or inspect/use all-resources across the tenancy.
These are the ones that need to be remediated.

2. Determine the Minimum Required Access

Verify what the Governance Monitoring service actually needs. In most environments, it only requires permissions to:
  • Read configuration / resources to evaluate governance rules.
  • Write/read its own governance rule configurations and evaluation results.
Common resource-types involved:
  • governance-rule-family
  • Possibly instance-family, object-family, vcn-family, tag-namespaces (for read/inspect only), depending on what the rules evaluate.
Your goal: restrict “manage all-resources” to only the specific resource-families and only with the minimal verb (inspect/use/read/manage) required.

3. Edit the Policy to Remove Unrestricted Access

For each over-permissive policy:
  1. From the Policies page, click the policy name.
  2. Click Edit Policy Statements.
  3. In the existing statements:
    • Remove or rewrite lines that include:
      • all-resources
      • in tenancy when not needed (use specific compartments instead)
      • manage when lesser verbs like inspect/read/use suffice.

Example: Bad Policy

Example: More Restrictive Replacement

Adjust based on what you actually need. A typical least-privilege pattern might look like:
Or, further compartment scoped:
Key principles:
  • Replace manage all-resources with:
    • inspect all-resources where only read/visibility is needed, or
    • Resource-specific access (e.g., use governance-rule-family) where write is needed.
  • Scope from in tenancy down to the specific compartment(s) where Governance rules and targets are defined, if possible.
  1. After editing, click Save Changes.

4. Validate Governance Monitoring Still Works

  1. Go to Governance & Administration (or Security depending on tenant layout) → Governance Rules / Governance Monitoring.
  2. Run:
    • A manual evaluation or
    • Confirm scheduled evaluations run successfully and generate results.
  3. If evaluation fails with a permission error, revisit the policy and:
    • Add narrowly scoped inspect or use permissions only for the exact resource-type mentioned in the error.
    • Avoid reverting back to manage all-resources.

5. Clean Up Any Redundant or Legacy Policies

  1. In Identity & Security → Policies, review for older, unused, or overlapping policies that still grant:
    • manage all-resources
    • Very broad inspect all-resources in tenancy not needed by Governance.
  2. If confirmed unused:
    • Either delete the policy or
    • Comment out/replace the broad statements with more specific ones.

If you share a current policy statement you’re using for Governance Monitoring, I can rewrite it to a least-privilege version you can paste directly into the console.
Below is a practical, CLI‑only approach to identify and remediate overly permissive OCI IAM policies that violate “Governance Policies Should Not Grant Unrestricted Resource Access” (e.g., those used for Governance Monitoring / Cloud Guard or custom governance tooling).

1. Identify Overly Permissive Policies

Typical “unrestricted” patterns you want to flag:
  • allow group <name> to manage all-resources in tenancy
  • allow group <name> to inspect all-resources in tenancy
  • allow group <name> to read all-resources in tenancy
  • Any in tenancy with very broad verbs (manage) and wildcards.

1.1 List Policies in Your Tenancy

If you know the compartment where governance/monitoring policies live, replace TENANCY_OCID with that compartment OCID.

1.2 Inspect Each Policy’s Statements

For a specific policy:
Look for statements that:
  • Use all-resources
  • Use in tenancy instead of a compartment
  • Grant manage at too broad a scope
Example of a problematic statement:

2. Decide the Correct Scope and Permissions

Before changing anything, decide:
  1. Which group truly needs what:
    e.g., governance-monitors.
  2. What access level is actually required for governance monitoring:
    Commonly:
    • inspect or read on specific services (e.g., audit-events-family, instances, volumes, buckets).
    • Rarely manage, and only for specific resource types if automation is needed.
  3. Where (tenancy vs compartment):
    Prefer compartment scoping (in compartment <compartment_name> or using compartment OCIDs) unless full‑tenancy visibility is absolutely necessary.
Example: For read‑only governance monitoring that just needs to see resources, you might use something like:
Still tenancy‑wide, but resource-specific, not all-resources.If you can limit to a compartment:

3. Update the Policy via OCI CLI

You cannot partially edit a single statement; you replace the entire statement list.

3.1 Save the Existing Policy (Backup)

This gives you name, description, statements, etc., in case you need to revert.

3.2 Prepare a New Statements File

Create a JSON file containing the new, least‑privilege list of statements, for example new-statements.json:
Or, if you can scope to a compartment (preferred):
You can build this file from the backup, removing/replacing the problematic lines.

3.3 Apply the New Statements to the Policy

Extract the array from the JSON file and provide it to oci iam policy update:
If you also want to adjust the description to reflect that it’s restricted:
Note: jq is used here to pass a proper JSON array to --statements. Ensure jq is installed, or manually inline the array string.

4. Verify the Remediation

4.1 Confirm the New Statements

Verify that:
  • No statement uses all-resources in tenancy (unless contractually required and justified).
  • No statement uses overly broad manage where only inspect/read is needed.

4.2 Validate Governance Monitoring Still Works

  • Trigger or run your governance monitoring / Cloud Guard / custom governance jobs.
  • Check for any failures or missing visibility. If something fails, grant only the additional minimal actions required (e.g., add a specific inspect <service-family> statement) and repeat.

5. Optional: Automate Detection of Unrestricted Policies

If you want to programmatically detect problematic policies with CLI + jq:
This shows policies where any statement contains all-resources in tenancy.You can similarly search for manage all-resources or other patterns.
If you can share an example of the exact problematic policy statement you’re seeing for “OCI Governance Monitoring,” I can give you a minimal, concrete replacement statement set tailored to that use case.
Below is a concise approach to detect and then remediate overly permissive OCI policies (granting unrestricted resource access) using Python and the OCI SDK, suitable for use in a “Governance Monitoring” style workflow.

1. What “Unrestricted Resource Access” Typically Looks Like

In OCI policy language, these are examples of overly broad statements:
  • Allow group <name> to manage all-resources in tenancy
  • Allow group <name> to inspect all-resources in tenancy
  • Allow group <name> to use all-resources in tenancy
  • Same patterns but in compartment <compartment-name> when the scope should be more granular.
Your goal: detect these and then replace them with more restrictive, service- or resource-specific statements.

2. Prerequisites

  1. Install SDK:
  2. Configure ~/.oci/config with:

3. Python: Detect Policies With Unrestricted Resource Access

This script:
  • Lists all compartments
  • Lists all IAM policies
  • Flags statements with all-resources or in tenancy patterns
Use this for continuous Governance Monitoring (run as a scheduled job, send results to a log/Lambda/function, etc.).

4. Remediation Strategy (Conceptual)

You should not blindly auto-edit policies; you must understand what each group actually needs. General pattern:
  • Replace:
  • With more specific:
Basic steps:
  1. For each flagged statement:
    • Identify the group or dynamic-group.
    • Identify what services/resources they truly require.
    • Draft new statements that:
      • Replace all-resources with specific verbs and resource-types (e.g. instances, volume-family, virtual-network-family).
      • Replace in tenancy with appropriate in compartment <name>.
  2. Update the policy using the OCI SDK.

5. Python: Example of Updating a Policy

Below is a template that:
  • Reads an existing policy
  • Rewrites statements using a mapping you control
  • Updates the policy
You must define rewrite_statement to encode your organization’s rules.
Important:
  • Test changes in a non-production tenancy or compartment first.
  • Consider exporting policies (e.g., into Git) before bulk edits for rollback.
  • For governance monitoring, usually you:
    • Detect problematic policies automatically.
    • Open tickets or send alerts to owners.
    • Apply changes manually or through a controlled pipeline.

6. Integrating with “OCI Governance Monitoring”

To make this part of a governance solution:
  • Run the detection script periodically (OCI Functions, scheduled job, CI pipeline).
  • Send findings to:
    • OCI Logging / Object Storage, or
    • A ticketing system (ServiceNow/Jira) via webhook, or
    • Email/Slack via your automation layer.
  • For high-risk cases (e.g., manage all-resources in tenancy), require manual review.
  • For low-risk patterns you’ve standardized, use the update script with a carefully controlled rule set.
If you share an example of a specific policy statement you have, I can give a concrete “before/after” rewrite and the exact Python logic to handle that pattern.
Substitute:
  • TENANCY_OCID with the target tenancy OCID.
  • GOVERNANCE_TENANCY_POLICY_DISPLAY_NAME with the existing governance tenancy policy display name.
  • OPERATORS_GROUP, NETWORK_ADMINS_GROUP, READONLY_GROUP with your actual OCI IAM group names.
  • COMPARTMENT_NAME, NETWORK_COMPARTMENT_NAME with the exact compartment names/OCIDs you want to scope access to.
This change updates the existing governance tenancy policy in place (no resource replacement), but it can immediately reduce privileges for affected groups once applied, so coordinate the change with application and operations owners.For verification, terraform plan should show the oci_governance_rules_tenancy_policy.GOVERNANCE_POLICY_NAME resource with a change only in its statements attribute, removing any manage all-resources in tenancy / use all-resources in tenancy lines and replacing them with the more scoped statements you defined.