Roles-based access control
The Qwiet dashboard allows you to collaborate with others regarding any security vulnerabilities identified. You can view vulnerabilities on a per-application basis, assign findings for review/follow-up, communicate with one another regarding specific vulnerabilities, and more.
Depending on their assigned roles, users can view different data and perform various actions in Qwiet.
Roles-based access control (RBAC)
Roles-based access control (RBAC) is the practice of assigning permissions to users based on their role within an organization. Because RBAC eliminates the need to set permissions individually, you get a more straightforward access management approach that's less error-prone.
RBAC in Qwiet preZero
There are several concepts you should be familiar with when working with Qwiet preZero's role-based access control (RBAC) feature:
A team is a group of users and applications (e.g., Team A consists of Alice, Bob, and Charlie and App1, App2, and App3).
All users must have a role in your organization
A user can belong to one or more teams. If a user belongs to more than one team, they must be assigned a role in the context of each team to which they belong. The roles do not have to be the same (e.g., Alice is an admin for Team A, whereas she is a member in Team B).
Roles that you assign to users are additive; this means that the user can do everything their organization role permits and their team roles permit.
Organization roles allow users to perform actions on an organizational level (e.g., log in to the organization and read basic information about the organization). However, this does not grant access to apps by default; the user must be assigned to one or more teams to see apps.
Roles
There are organization roles and team roles available.
Organization roles
| Role | Description |
|---|---|
| Super Admin | Permitted all actions except deleting the organization and deleting/demoting other super admins. Can add applications. |
| Power User | Permitted all app-related actions (including adding and deleting apps). Can add apps. |
| Member | Permitted all finding-related actions. Cannot destroy data (e.g., delete apps) and is limited to updating findings metadata. |
| Guest | Can view findings-related information. |
| Team Defined | Can log into the organization, but cannot access any data unless added to a team. |
| Collaborator | Deprecated. Orgs created after the release of RBAC will not be shown this option. Can perform any non-destructive action. |
Team roles
| Role | Description |
|---|---|
| Team Admin | Permitted all app-related actions (including deleting apps) for their team. Can add apps to their teams and move apps from one team to another, as long as they are a team admin for both teams. |
| Team Manager | Permitted all app-related actions (except deleting apps) for their team. Can add apps to their teams and move apps from one team to another, as long as they are a team manager for both teams. |
| Team Member | Can perform findings-related actions, but cannot destroy data (e.g., delete apps). Can update findings metadata. |
| Team Guest | Can view findings-related data. |
Sample usage
The following examples will show how organization roles and team roles work and how the permissions granted to a user are additive.
Example 1
Alice is assigned to the ExampleCo org as team defined in this example. In this case, she can log into Qwiet, but she will not be able to see any applications, findings, and so on.
Example 2
Alice is assigned to the ExampleCo org as a member in this example. She can see all applications, including findings data, but she can only modify the findings metadata.
Example 3
In this example, Alice is granted a team defined role, granting her permission to log in to the organization. She is also a member of Team A, allowing her access to Apps A and B.
