feat(oci): add identity_storage_service_level_admins_scoped check for CIS 3.1 1.15 compliance

[rchotacode]

Context

CIS 3.1 include 1.15 which requires service level storage admins to be scoped to remove deletion permissions.
Feat #10567

Description

Policies such as manage file-systems resources enable deletion at the service level. According to OCI CIS 3.1 1.15, these policies should not be service level or have the condition where request.permission!='*SERVICE*_DELETE'.

Steps to review

Running prowler oraclecloud --check identity_storage_service_level_admins_scoped

Checklist

Community Checklist

• This feature/issue is listed in here or roadmap.prowler.com
• Is it assigned to me, if not, request it via the issue/feature in here or Prowler Community Slack

• Review if the code is being covered by tests.
• Review if code is being documented following this specification https://github.com/google/styleguide/blob/gh-pages/pyguide.md#38-comments-and-docstrings
• Review if backport is needed.
• Review if is needed to change the Readme.md
• Ensure new entries are added to CHANGELOG.md, if applicable.

SDK/CLI

• Are there new checks included in this PR? Yes / No
  • If so, do we need to update permissions for the provider? Please review this carefully.

UI

• All issue/task requirements work as expected on the UI
• Screenshots/Video of the functionality flow (if applicable) - Mobile (X < 640px)
• Screenshots/Video of the functionality flow (if applicable) - Table (640px > X < 1024px)
• Screenshots/Video of the functionality flow (if applicable) - Desktop (X > 1024px)
• Ensure new entries are added to CHANGELOG.md, if applicable.

API

• All issue/task requirements work as expected on the API
• Endpoint response output (if applicable)
• EXPLAIN ANALYZE output for new/modified queries or indexes (if applicable)
• Performance test results (if applicable)
• Any other relevant evidence of the implementation (if applicable)
• Verify if API specs need to be regenerated.
• Check if version updates are required (e.g., specs, Poetry, etc.).
• Ensure new entries are added to CHANGELOG.md, if applicable.

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

✅ Conflict Markers Resolved

All conflict markers have been successfully resolved in this pull request.

[codecov]

Codecov Report

❌ Patch coverage is 31.25000% with 33 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.41%. Comparing base (509ec74) to head (0821a02).
⚠️ Report is 60 commits behind head on master.

❗ There is a different number of reports uploaded between BASE (509ec74) and HEAD (0821a02). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (509ec74)	HEAD (0821a02)
api	1	0

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #10568       +/-   ##
===========================================
- Coverage   93.52%   59.41%   -34.11%     
===========================================
  Files         225       88      -137     
  Lines       31579     2910    -28669     
===========================================
- Hits        29534     1729    -27805     
+ Misses       2045     1181      -864     

Flag	Coverage Δ
api	?
prowler-py3.10-oraclecloud	59.41% <31.25%> (?)
prowler-py3.11-oraclecloud	59.41% <31.25%> (?)
prowler-py3.12-oraclecloud	59.41% <31.25%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
prowler	59.41% <31.25%> (∅)
api	∅ <ø> (∅)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[HugoPBrito]

This logic is still too permissive for CIS 3.1 control 1.15.

The control does not require any WHERE clause; it requires a condition that excludes delete access for the storage resource being managed. Right now a statement such as where request.region="iad" or where target.bucket.name="x" would pass, even though it still allows deletion.

Please update the check so it only treats a statement as compliant when it explicitly excludes the relevant delete permission for that resource, for example request.permission!='VOLUME_DELETE', request.permission!='FILE_SYSTEM_DELETE', request.permission!='OBJECT_DELETE', etc. This is the core requirement of CIS 1.15: service-level admins may manage the service, but they must not be able to delete the resources they manage.

[rchotacode]

I originally implemented this behavior, but looking at the CIS 1.15 examples it seems service level admins refer to unrestricted manage access to storage services. Other CIS benchmarks also seem to flag it as such. I would think that target.bucket.name="x" would be a resource level of control, not a service.

These are the example policies adjusted to fit within the control within its definition document:

Example policies for global/tenant level for block volume service-administrators:

Allow group VolumeUsers to manage volumes in tenancy where request.permission!='VOLUME_DELETE' 
Allow group VolumeUsers to manage volume-backups in tenancy where request.permission!='VOLUME_BACKUP_DELETE

Example policies for global/tenant level for file storage system service-administrators:

Allow group FileUsers to manage file-systems in tenancy where request.permission!='FILE_SYSTEM_DELETE' 
Allow group FileUsers to manage mount-targets in tenancy where request.permission!='MOUNT_TARGET_DELETE' 
Allow group FileUsers to manage export-sets in tenancy where request.permission!='EXPORT_SET_DELETE'

Example policies for global/tenant level for object storage system service-administrators:

Allow group BucketUsers to manage objects in tenancy where request.permission!='OBJECT_DELETE' 
Allow group BucketUsers to manage buckets in tenancy where request.permission!='BUCKET_DELETE'

Each of these allows manage for a file service storage, but doesn't restrict the permissions at all without the request.permission!='X_DELETE'. In addition, the reference here https://docs.oracle.com/en/solutions/oci-best-practices/protect-data-rest1.html#GUID-EBE9212C-78B0-4795-9FB5-59DB0E91E106 linked in the control says that the permissions should be give "to only the users who need these privileges," which implies that some users should still be able to have delete permissions. I interpreted this as meaning that the CIS benchmark was to limit unrestricted delete permissions given to admins over all storage services.

[HugoPBrito]

I would also revisit the manage all-resources handling here.

For CIS 1.15, broad statements should not pass just because they contain a WHERE. The implementation should only pass when it can prove that delete is excluded for the storage resources covered by the statement. Otherwise this can create false PASS results for policies that remain non-compliant with the benchmark.

[HugoPBrito]

Please align the metadata remediation examples with the CIS 1.15 wording and examples.

A couple of things to fix here:

• the examples should be framed around excluding delete permissions for the managed storage resource
• request.permission should be used consistently
• the Terraform example currently uses request.PERMISSIONS, which does not match the benchmark examples
• if possible, include examples that mirror the control more closely for the different storage resources (VOLUME_DELETE, FILE_SYSTEM_DELETE, OBJECT_DELETE, etc.), not just a single generic example

Since this metadata is what users will read for remediation, it should map directly to the benchmark language.

[HugoPBrito]

This new check still needs real unit test coverage.

At the moment the test file is empty, so we are not validating the CIS-specific behavior of the parser. Please add tests for at least:

• FAIL: manage <storage-resource> with no delete exclusion
• PASS: manage <storage-resource> with the correct request.permission!='*_DELETE' condition
• FAIL: a statement with an unrelated WHERE clause that does not exclude delete
• inactive policies
• Tenant Admin Policy

This is especially important here because the correctness of the check depends on parsing OCI policy statements exactly as required by CIS 1.15.