How are you creating certifications for Azure resources?

Hello,

I have recently enabled CIEM for one of my Azure tenants and am trying to get a grasp on how to actually certify the access of select subscriptions that encompasses all the access. I have tried the following query and that seems to pull in all azureActiveRoles, azureEligibleRoles, and groups with direct access but it misses anything inherited.

source.name:“Prod Azure Tenant” AND ([subscription ID One] OR [subscription ID Two)

I appreciate any ideas on this,

Thank you!

Hello James. I think the inherited access is being missed because your current query is searching entitlement data, while Azure RBAC assigned at a parent scope is inherited down to child resources. CIEM represents that through effective access and Access Paths, rather than creating a separate entitlement for every child subscription.

I would try Cloud Resources search first:

cloudSourceType:Azure AND source:"Prod Azure Tenant"

In this category the field is source, not source.name. You can then inspect a resource from the target subscription and confirm whether cloudSubSourceNativeId or resourceId is the better field to narrow the query.

Open the resource and check Identities and Access Paths. If the missing users appear through a management group or parent scope, that should confirm where the inherited access is coming from (Viewing Cloud Access).

Also, the active/eligible roles you are seeing relate to Azure PIM. An eligible role is access the user can activate, not currently active access (Azure PIM Attributes).

For CIEM certification details, SailPoint currently documents Group and azureRoleAssignment as the Azure entitlement types to mark Cloud Enabled (Managing Azure Entitlements).

For remediation, I would follow the Access Path. If the access comes from a parent-scope RBAC assignment, remediate it at that scope. If it comes through a group, removing the group membership may be the appropriate action instead.

Hi @jewalker

The current query is missing some inherited access because ISC is only looking for entitlements where the value contains the subscription ID. This means access inherited from roles assigned at the management group level, roles assigned through groups, or nested group memberships may not be included.