> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/cortex-cloud-identity-security/how-does-effective-permission-calculation-work.md). # How does Effective Permission Calculation work? #### Effective permission calculation One of the core capabilities of Cortex Cloud Identity Security is its ability to analyze cloud permissions. Once you have onboarded your cloud organization, Cortex Cloud Identity Security gathers all the relevant information necessary for calculating permissions and then calculates the net effective permissions in your environment, which is a precise depiction of which identity can perform which specific actions and where can they be performed. Net effective permissions are used to provide context for other product features such as access tables, access to cloud resources and services count, as well as detection rules and issues. Example 117. When assessing whether a user has access to an Amazon S3 bucket, you must make sure that the permissions actually exist somewhere, while there is nothing that could deny access. A user can be granted access via a policy that is attached to the user (via direct attachment, a role the user can assume, or a group where they're a member), an inline policy, or a resource-based policy. Permissions can be denied via service control policies (SCPs), permission boundaries, a deny statement on a relevant policy, a deny statement on the resource-based policy and much more. The net effective permission calculator takes all these and more into account when determining effective permissions in your environment. A permission consists of five main components: * **Source:** The identity that can perform an action. This can be a human identity or a non-human identity. In certain cases, permissions for cloud service accounts are calculated as sources as well. In some special cases, such as where public access is granted, or when permissions are granted to an entire specific cloud account, a source can be named “all”. In such cases, notice the source’s cloud account to identify whether the permissions are granted to the public or to all entities within an account. For Oracle Cloud Infrastructure (OCI), sources include users, groups, and dynamic groups, which allow resources like Compute instances to act as identities." * **Destination:** The resource on which the source can perform actions. In cases of wildcards, the relevant wildcard appears. * **Policy:** The document where permissions are written, such as an IAM policy, Azure or GCP role, resource-based policy, or inline policy. OCI policies follow this syntax: `Allow to in ` * **Granter:** The asset that connects the source and the policy. Traditionally, this can be a group or a cloud service account. In the case of a direct attachment, or the use of inline policy, the granter and the source would be the same asset. In the case of a resource-based policy, the granter and the destination would be the same asset. In OCI, this is typically a group or dynamic group. * **Action:** The specific action that a source can perform on a granter. #### Cloud permission calculations A wide variety of tools are used by security teams to grant or revoke permissions. Cortex Cloud Identity Security takes the following parameters into consideration when calculating effective permissions. **Organization policy** Using organization policies, you can enable and turn off various types of policies across accounts and organization units. Cortex Cloud Identity Security analyzes organization policies as part of the permission calculation for: * **Amazon AWS:** Service control policies (SCPs) are supported. **Deny statements** Deny statements can appear in the various permission tools in different cloud providers and are taken into consideration in the effective permissions calculation, when they appear in the following: * **AWS:** Deny actions are supported in SCP and IAM policies. Overrides are allowed. * **Azure:** Block operations or enforce rules in policies, resource groups, and subscriptions. Hierarchies can be applied across management groups. Overrides are allowed. * **GCP:** Block actions and configurations are supported in the scope of organizations, folders, and projects. Hierarchies can be applied across hierarchy levels. Overrides are allowed. * **OCI:** Deny statements are not supported. **"NotAction" element** * In a policy, actions specified under the `NotAction` policy element are subtracted from the permissions that are granted in that policy. * The `NotAction` element is supported in AWS and Microsoft Azure. * The `NotAction` element is **not supported** in OCI. **Permissions boundary tool** You can use the IAM permissions boundary tool to limit the amount or scope of permissions granted to a principal. The permissions boundaries tool is supported in AWS and Azure. The permissions boundaries tool is **not supported** in OCI. **Resource-based policies** Resource-based policies are permissions that are configured on the destination resource. You can use resource-based policies to grant or deny permissions on a resource that is based on multiple parameters; for example, allowing or preventing a certain principal from acting on a resource. * **AWS:** Resource-based policies are calculated for the following services: AWS Lambda, Amazon S3, Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS), AWS Secrets Manager, AWS Key Management Services (KMS), and Amazon Elastic Container Registry (ECR). * **Azure:** Permissions granted of any scope are considered for effective permissions calculation. * **GCP:** Resource-based policies are calculated for the following Google Cloud services: Cloud Storage, BigQuery, Cloud Pub/Sub, Cloud Key Management (KMS), Cloud Spanner, Cloud Run, Compute Engine, Cloud Functions, and Dataproc. * **OCI:** Permissions are calculated based on policies attached at the tenancy or compartment level. OCI does not use separate resource-based policies. Instead, access to specific resources is defined within the IAM policy using the `in` clause (specifying a tenancy or compartment) and the `WHERE` clause (specifying individual resource IDs or tags).

Note

Unlike GCP (organizations/folders/projects) or Azure (management groups/subscriptions), OCI uses a nested compartment structure.

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/cortex-cloud-identity-security/how-does-effective-permission-calculation-work.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.