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:
  • Management Group
  • Subscription
  • Resources
Resource groups are not currently supported.
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.

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

Recommended For You