Role-Based Access Control
Role-based access control (RBAC) lets administrators define what actions each user can
perform on the entities within Device Security, from devices and alerts to
vulnerabilities and networks.
| Where Can I Use This? | What Do I Need? |
|---|
|
|
One of the following subscriptions:
Device Security subscription
Precision AI bundle subscription
Device Security X subscription
|
Use role-based access control (RBAC) to define which actions a user can perform on
the entities within Device Security. Unlike scope-based access control (SBAC),
which defines which devices a user can access, RBAC defines what actions a user
can take on those devices and their associated resources. For Device Security
in Strata Cloud Manager, RBAC uses a three-tier permission model -
Read Write, Read Only, or No Access - applied per entity.
To use RBAC, your organization must use Device Security managed through
Strata Cloud Manager. Only users with the Superuser role in
Strata Cloud Manager can create, modify, or assign custom
Device Security roles.
Make use of RBAC when your organization needs to enforce least-privilege access
across teams that share the same tenant. Common scenarios include enterprises
where security operations analysts triage alerts but do not modify network
configuration, network administrators who maintain sites and networks but do not
resolve vulnerabilities, and integration owners who manage third-party connectors
but should not see device details. RBAC also helps prevent cross-team information
leakage in tenants where different groups own different Device Security
resources.
Configure RBAC in Strata Cloud Manager through
.
The Roles panel is scoped to a tenant, so you first select
the tenant you want to manage roles for. The panel then displays two tabs:
Predefined Roles and Custom Roles.
Superuser administrators create custom roles on the Custom
Roles tab, and then assign one or more roles to a user from the
Access Management panel in Strata Cloud Manager. Once a
role is assigned, Device Security enforces it automatically: the user can only
view or act on the entities their assigned roles permit.
Device Security supports two predefined roles and any number of custom roles:
Superuser - Predefined. Grants Read Write access to
every Device Security entity and bypasses all other role restrictions.
View Only Administrator - Predefined. Grants Read
Only access to every Device Security entity. When combined with a
custom role, the user sees everything the View Only Administrator role
grants plus any Read Write permissions the custom role adds.
Custom roles - Superuser administrators define these
per tenant. Each custom role sets a permission level (Read Write,
Read Only, or No Access) for each Device Security entity.
Predefined roles cannot be edited, cloned, or deleted. To grant a permission
combination that the predefined roles do not provide, create a custom role.
RBAC gates access to the following Device Security entities:
- Administration
- Alerts
- Dashboard & Reports
- Devices
- Integration
- Medical
- Networks
- Policies
- Queries & Filters
- Risk Factors
- Vulnerabilities
A user assigned No Access on an entity does not see that entity in the
navigation, and related widgets, pages, and API calls return no data or return a
403 response.
When a user has multiple roles assigned, Device Security applies the union of
those roles: the effective permission on each entity is the most permissive
permission granted by any assigned role. For example, a user assigned one role
that grants Read Only on Alerts and another role that grants
Read Write on Alerts has Read Write on Alerts. The Superuser role
overrides all other role assignments, and the View Only Administrator role
combined with a custom role gives the user Read Only on every entity plus
any Read Write permissions the custom role grants.
Role-based access control (RBAC) and scope-based access control (SBAC) work together
to enforce least-privilege access. RBAC defines what actions
a user can perform on Device Security entities such as devices, alerts, and
vulnerabilities. SBAC defines which entities those actions apply to by limiting the
sites a user can access. Used together, RBAC and SBAC restrict access on two axes:
what a user is allowed to do, and on which entities the user is allowed to do it on.
Device Security evaluates RBAC before SBAC. When a user makes a request,
Device Security first checks whether the user's roles permit the action on the
requested entity. If the action is not allowed, the request is blocked. If the action
is allowed, Device Security then filters the result set to devices within the
user's assigned scopes.
RBAC enforcement has the following behaviors and gaps:
System dashboards such as the Executive dashboard and the landing page
remain visible to every user regardless of the Dashboard & Reports
permission. Only custom dashboards, reports, and widgets are gated.
Query builder cannot fully enforce entity
permissions at the backend. To reduce cross-entity leakage, the
Device Security interface hides disallowed entity types from the
query builder dropdowns.
Global search doesn not return any results for users with No Access
to any entity.
Public API calls made with a service account inherit that account's
assigned role. Service account API requests are subject to the same
per-entity permission checks as user requests.
