Ctrlk
BlogSupport
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Context Used to Calculate Effective Permissions

Prisma Cloud IAM Security is powered by a two-part proprietary algorithm. First, services from multiple cloud entities are combined to compute the net effective permissions of each cloud resource. Net effective permissions data includes:

This information is then matched with last access data to identify when a permission was last used. To efficiently process the high volume of usage data, last access destinations are limited to 100. Each permission includes a maximum number of 100 last access rows including the latest events of each day.

AWS Net Effective Permissions Calculation

The following AWS policy types and identities are used to calculate the net effective permissions:

  • AWS IAM role

  • AWS IAM policy

  • AWS IAM group

  • AWS service control policies (SCPs)

  • Role trust relationships

  • Permission boundaries

  • NotAction

  • Policies with wild card support

Other resource types you may have in your AWS deployment are not factored into net-effective permission calculations.

In addition, permissions can also be set by a resource-based policy. The following AWS resource-based policies are supported in the net effective permissions calculation:

  • Lambda function

  • S3 bucket

  • SQS queue

  • SNS topic

  • ECS task definition

  • Secret manager

  • KMS key

  • Lambda layer version

When you define permissions there are several IAM concepts that you can specify. The IAM Security module currently uses some of these concepts and ignores the following concepts:

  • IAM variables

  • Service linked roles

  • NotResource

You can also query your results in Prisma Cloud using the following AWS concepts:

  • Tags

  • Conditions

Reference IAM Query attributes to view AWS tag attributes and learn more about running IAM queries for AWS Tags.

Note that unlike AWS, tags in Prisma Cloud are not case-sensitive.

After the net effective permissions are calculated the actual usage (last access) is matched to determine when write events were actually used. Because the last access calculation is based on a 24-hour period for each account, you should wait at least 24 hours to see the updated last access value for any new actions in your account. Last access is supported by the majority of write events. The following AWS services and events are verified:

Service

Event Name

Cloud9

  • CreateEnvironmentEC2

Elastic Compute Cloud

  • CreateImage

  • CreateNetworkAcl

  • CreateRoute

  • CreateSecurityGroup

  • CreateSubnet

  • CreateVpcEndpoint

  • DeleteFlowLogs

  • DeletePlacementGroup

  • DeleteVolume

  • DeleteVpnGateway

  • ImportKeyPair

  • MonitorInstances

  • AssociateIamInstanceProfile

  • ModifyVpcEndpointServicePermissions

Elastic Container Registry

  • PutImage

  • DeleteLifecyclePolicy

  • DeleteRepositoryPolicy

  • PutLifecyclePolicy

  • SetRepositoryPolicy

Elastic Container Service

  • DeregisterTaskDefinition

ElastiCache

  • CreateCacheCluster

  • CreateCacheSecurityGroup

Elastic File System

  • CreateFileSystem

Elastic Load Balancing

  • CreateListener

  • DeleteLoadBalancerListeners

  • SetLoadBalancerPoliciesOfListener

  • CreateLoadBalancerPolicy

  • DeleteLoadBalancerPolicy

Elastic MapReduce

  • RunJobFlow

Elasticsearch

  • CreateElasticsearchServiceRole

Identity and Access Management

  • AddUserToGroup

  • CreatePolicy

  • CreateUser

  • DeleteRole

  • DeleteUserPolicy

  • UpdateAccessKey

  • UpdateUser

  • PutGroupPolicy

  • PutRolePolicy

  • PutUserPolicy

  • AttachGroupPolicy

  • AttachUserPolicy

  • CreatePolicyVersion

  • AddUserToGroup

  • UpdateLoginProfile

  • CreateAccessKey

  • AttachRolePolicy

  • SetDefaultPolicyVersion

  • CreateLoginProfile

Key Management Service

  • CreateKey

Lambda

  • UpdateFunctionCode20150331v2

  • AddPermission20150331v2

  • RemovePermission20150331v2

Relational Database Service

  • CreateDBClusterSnapshot

  • DeleteDBSubnetGroup

Amazon Redshift

  • CreateCluster

  • DeleteClusterParameterGroup

  • ModifyClusterIamRoles

S3

  • PutBucketAcl

Simple Notification Service

  • CreateTopic

Simple Queue Service

  • DeleteQueue

AWS Certificate Manager

  • AddTagsToCertificate

Managed Message Broker Service

  • CreateBroker

AWS Batch

  • DeleteComputeEnvironment

Amazon Cognito Identity Pools

  • CreateIdentityPool

AWS Config

  • DeleteDeliveryChannel

AWS Database Migration Service

  • CreateReplicationInstance

Amazon DynamoDB

  • CreateTable

AWS Backup

  • PutBackupVaultAccessPolicy

  • DeleteBackupVaultAccessPolicy

AWS Organizations

  • UpdatePolicy

AWS IoT

  • AttachPolicy

  • AttachPrincipalPolicy

  • DetachPrincipalPolicy

  • DetachPolicy

  • CreateSecurityProfile

  • UpdateSecurityProfile

  • DeleteSecurityProfile

Azure Net Effective Permissions Calculation

When processing Azure Active Directory (AD) groups, a maximum of 1000 group members are allowed. All entities are supported including users, groups, managed identities and service principals.

See What is Prisma Cloud IAM Security to learn more about how the IAM Security module works.

The following Azure permission levels are supported:

  • Entra ID

  • Management Group

  • Subscription

  • Resources

When you define permissions there are several IAM concepts that you can specify. The IAM Security module currently uses some of these concepts and ignores the following concepts:

  • Resource groups

  • Multi-tenant access

  • Conditions

  • Tags

Prisma Cloud requires additional permissions to display the above-mentioned permission levels. If you are new to Prisma Cloud and used a Terraform template for Azure account onboarding no additional action is required, since the template includes these permissions. If you have already associated Prisma Cloud with your Azure account, you have the option to rerun the Terraform template or manually add the required permissions.

Enable Access Management for Azure Entra ID

If your Azure deployment uses Azure Entra ID, follow the steps below to enable access:

  1. Sign in to the Azure portal as a Global Administrator in Azure AD.

  2. Open Microsoft Entra ID (formerly Azure Active Drectory).

  3. Select Manage > Properties

  4. Under Access management for Azure resources, set the toggle to Yes.

  5. Click Save.

Manually add permissions for Azure Management Groups

If your Azure deployment uses management groups, follow the steps below to manually add the Microsoft.Management/managementGroups/descendants/read permission:

  1. On your Azure account portal, navigate to the Management group.

  2. Select the Tenant/Root Management Group > Access Control (IAM).

  3. Assign the above-mentioned permission to your Prisma Account.

Manually add permissions for Azure Management Groups

If your Azure deployment uses subscriptions, follow the steps below to manually add the Microsoft.Resources/subscriptions/read permission:

  1. On your Azure account portal, navigate to the Subscription group.

  2. Select the Subscription for which you wish to ingest tags.

  3. Click on the Access Control (IAM) tab.

  4. Assign the above-mentioned permission to your Prisma Account.

You can validate that the permission levels are added by running an IAM Query. Reference IAM Query Attributes to view all the Azure permission level attributes.

GCP Net Effective Permissions Calculation

Prisma Cloud uses GCP entities, service-based policies, and IAM concepts for calculating net effective permissions. If your cloud environment has additional resource types, Prisma Cloud does not factor them into the net-effective permissions.

The list of GCP entities that are used to calculate the net effective permissions are as follows:

Entities

GCP Principal

  • User account

  • Service account

  • Group account

GCP Role

  • Basic

  • Predefined

  • Custom

GCP Levels

  • Organization

  • Folder

  • Project

  • Service (if supported)

GCP Public

  • All users

  • All authenticated users

Prisma Cloud leverages GCP Deny Policies feature to calculate net effective permissions. Deny Policies is a public Beta release on GCP, so Net effective permissions calculation for denied permissions will also be a Beta release on Prisma Cloud.

In addition, permissions can also be set by a service-based policy. The following GCP service-based policies are supported in the net effective permissions calculation:

Service-based Policies

App Engine

gcloud-app-engine-application

Big Query

  • gcloud-bigquery-dataset-list

  • gcloud-bigquery-table

Cloud Bigtable

  • gcloud-bigtable-instance-list

  • gcloud-bigtable-table

Cloud Compute

  • gcloud-compute-instances-list

  • gcloud-compute-image

  • gcloud-compute-instance-disk-snapshot

Cloud Functions

gcloud-cloud-function

Cloud Key Management Service

gcloud-kms-keyring-list

Cloud Run

gcloud-cloud-run-services-list

Cloud Spanner

  • gcloud-cloud-spanner-database

  • gcloud-cloud-spanner-instance

  • gcloud-cloud-spanner-instance-backup

Cloud Storage

gcloud-storage-buckets-list

Cloud SQL

gcloud-sql-instances-list

Dataproc

gcloud-dataproc-clusters-list

Pub/Sub

  • gcloud-pubsub-topic

  • gcloud-pubsub-snapshot

Secrets Manager

gcloud-secretsmanager-secret

When you define permissions there are several IAM concepts that you can specify. The IAM Security module currently uses some of these concepts and ignores the following concepts:

  • Conditions

  • GCP Project Boundaries

  • Dynamic Groups

  • Level for Permissions in Custom Roles

  • Permissions Dependencies

  • Google-Managed Service Accounts

  • Google Workspace Domain

  • Cloud Identity Domain

  • Project Viewer

  • Project Owner

  • Cross-Account Support with Service Accounts

  • When processing Groups, a maximum of 1000 members are allowed.

  • Group permissions are displayed only if you have:

    • Onboarded your GCP Organization on Prisma Cloud. Projects do not allow you to view group permissions.

    • Added Deny Policies at the folder level.

    • Included the group.read permission in Google Workspace for the Prisma Cloud Service Account.

After the net effective permissions are calculated the actual usage (last access) is matched to determine when write events were actually used. Last access is supported by the majority of write events. Because the last access calculation is based on a 24-hour period for each account, you should wait at least 24 hours to see the updated last access value for any new actions in your account. The following GCP services and events are verified:

Service

Event Name

IAM

  • iam.roles.create

  • iam.roles.create

  • iam.roles.delete

  • iam.roles.undelete

  • iam.roles.update

  • iam.serviceAccountKeys.create

  • iam.serviceAccountKeys.delete

  • iam.serviceAccounts.create

  • iam.serviceAccounts.delete

  • iam.serviceAccounts.disable

  • iam.serviceAccounts.enable

  • iam.serviceAccounts.setIamPolicy

  • iam.serviceAccounts.undelete

  • iam.serviceAccounts.update

Compute

  • compute.backendServices.setIamPolicy

  • compute.disks.removeResourcePolicies

  • compute.disks.setIamPolicy

  • compute.images.setIamPolicy

  • compute.instanceTemplates.setIamPolicy

  • compute.instances.removeResourcePolicies

  • compute.instances.setIamPolicy

  • compute.instances.setServiceAccount

  • compute.machineImages.setIamPolicy

  • compute.snapshots.setIamPolicy

PreviousRemediate Alerts for IAM SecurityNextNetwork Security

Last updated

Was this helpful?