An explanation of how Effective Permission Calculation works in Cortex Cloud Identity Security.
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.
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 <subject> to <verb> <resource-type> in <location>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
NotActionpolicy element are subtracted from the permissions that are granted in that policy.The
NotActionelement is supported in AWS and Microsoft Azure.The
NotActionelement 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
inclause (specifying a tenancy or compartment) and theWHEREclause (specifying individual resource IDs or tags).Note
Unlike GCP (organizations/folders/projects) or Azure (management groups/subscriptions), OCI uses a nested compartment structure.