> 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-xsiam/cloud-security/cortex-cloud-identity-security/manage-rbac-and-sbac-in-cortex-cloud-identity-security.md). # Manage RBAC and SBAC in Cloud Identity Security {% hint style="info" %} This feature is included with a Cortex XSIAM Premium license. It is also included with any other Cortex XSIAM license that has the Cloud Posture Security or Cloud Runtime Security add-on. {% endhint %} #### Grant role-based access control (RBAC) to a user Role-based access control (RBAC) helps manage access to Cloud components and Cortex Query Language (XQL) datasets, so that users, based on their roles, are granted the minimal access required to accomplish their tasks. There are two out-of-the-box roles in Cloud Identity Security that you can use to grant access only to the areas that are relevant for those working with Cloud Identity Security: * **Identity Security Administrator**: Has full access to all general administrator and Identity Security capabilities for AWS, Azure, GCP, and OCI. * **Identity Security Viewer**: Can view most Identity Security features and edit reports for AWS, Azure, GCP, and OCI. For information about managing access for Cloud Identity Security users, see [Set up users and roles](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-users-and-roles.md). {% hint style="info" %} ### Important You can use the Cloud Identity Security RBAC roles to define access to the various sections and functionalities of Cloud Identity Security, but these roles do not directly control the specific data a user sees within those sections. Data visibility is further refined and limited by scope-based access control (SBAC) capabilities. {% endhint %} #### How scope-based access control (SBAC) works in Cloud Identity Security Scope-based access control (SBAC) refines RBAC permissions by granting access only to the relevant data that a user requires for their designated role. Users having Access Management permission apply scopes in Cloud to limit the data and content that users can be granted access to. These are divided into different scoping areas, including assets, cases and issues, and endpoints, which can be applied as relevant to the enforcement area or entity. For more information about user scopes, see [Manage user scope](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope.md). **Access table display behavior** The access table of an asset is displayed to users whose scope includes that specific asset. However, if this access table also lists other assets that are not within the user's defined scope, the entire table is still visible in order to ensure that the user has a full understanding of the asset being reviewed. In such cases, if the user attempts to click on an asset that falls outside their scope, an empty asset page is displayed. For more information about assets, see [Asset management](/cortex-xsiam/detect-investigate-and-respond-to-threats/asset-management.md). **Define SBAC policies** In the Cloud Identity Security area, we strongly recommend using scopes such as Cloud Provider type, Account (Tenancy in OCI), or Region when defining your SBAC policies for the Cloud Identity Security module. Using scopes that are based on asset types (such as restricting according to specific EC2 instances or Amazon S3 buckets) as your primary or sole scope can influence the effectiveness of your SBAC policies for the following reasons: * **Interconnected permissions**: Permissions in cloud environments often involve more than one asset type. For example, a single permission might grant access to an Amazon S3 bucket or to an EC2 instance also includes an related IAM (execution) role of the instance. This is why limiting the user scope to a specific asset type is not recommended when permissions are involved. In OCI, a policy might grant a dynamic group permissions to manage resources within a specific compartment. If your scope is limited only to a single resource (like a specific database) and excludes the associated dynamic group or the parent compartment, you may not see the full context of how access is granted. * **Partial visibility**: Cloud Identity Security displays a permission if even one of the assets involved in that permission is not part of the user's defined scope. This ensures that users have sufficient context, even if not all associated assets are within their direct view. **Work with SBAC-related datasets** For investigating Identity Security permission data, Cloud provides one principal dataset: `ciem_permissions_with_last_access`. For more information about this dataset, see [Perform advanced Identity Security investigations using XQL](/cortex-xsiam/cloud-security/cortex-cloud-identity-security/perform-advanced-identity-security-investigations-using-xql.md). This dataset supports your defined SBAC policies. Users accessing this dataset will be able to see permission data that falls within their assigned scope. --- # 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-xsiam/cloud-security/cortex-cloud-identity-security/manage-rbac-and-sbac-in-cortex-cloud-identity-security.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.