Roles

Roles are a construct that can be applied to accounts, allowing the user to perform certain actions based on the permissions associated with the role. This is based on the principle of Role-Based Access Control (RBAC).

Role-Based Access Control (RBAC)^[1] is a method of regulating access to resources within an information system based on the roles assigned to individual users. It simplifies the management of user permissions by grouping privileges under roles, which can then be assigned to users. This approach ensures that users have access only to the information and systems necessary for their job functions, enhancing security and operational efficiency.

• Simplicity and Scalability: RBAC simplifies permission management by allowing administrators to assign roles to users instead of managing individual permissions. This is particularly beneficial in large organizations where managing access at an individual level would be impractical.

• Least Privilege Principle: By assigning roles based on job functions, RBAC helps ensure that users have the minimum necessary access to perform their duties, reducing the risk of unauthorized access.

• Improved Security and Compliance: RBAC helps organizations enforce consistent access control policies, which is crucial for meeting regulatory and compliance requirements such as HIPAA, GDPR, and for achieving ISO 27001^[2] certification.

• Reduced Administrative Workload: Roles can be predefined and reused, simplifying the onboarding and role change processes. When an employee moves up within the company, administrators can change their roles without modifying individual permissions.

• Enhanced Auditing and Monitoring: Since access is defined by roles, it's easier to track and audit who has access to what resources, improving security monitoring and incident response.

Microsoft uses it: for Microsoft Entra ID, which Office 365, Azure, DevOps, MS Teams and many other services use, is also based on RBAC. ^[3]

• Define Roles: Identify the roles within the organization and the corresponding access needs for each role. This involves understanding job functions and the resources required for those functions.

• Assign Permissions to Roles: Determine the permissions each role should have. This includes specifying what actions the role can perform on which resources. All permissions are listed under [MobileTrack.Common.Enums.PermissionValueMap] (under Fields).

• Assign Users to Roles: Assign the appropriate roles to users based on their job functions. This can be done manually or automatically based on user attributes like department or job title.

• Implement Role Hierarchies and Constraints: If needed, define role hierarchies and constraints. Hierarchies allow for roles to inherit permissions from other roles, while constraints can restrict certain combinations of role assignments to enforce security policies.

• Regular Review and Audit: Regularly review and update roles, permissions, and user assignments to ensure they remain aligned with current job functions and security policies.

The following roles are build-in and can be used by all customer companies:

1. Admin

   Admin superuser role; has access to all resources and can perform all actions. It is recommended to assign this role to a limited number of trusted users, if at all.

   • All

2. HR

   Human Resources role; can review logs, has access to accounts and can see all environments, but has no insight nor management of Devices.

   • ManageAllAccounts
   • ManageIpAddresses
   • ReviewLogs
   • ViewAccounts
   • ViewIpAddresses
   • ViewAllEnvironments

3. Location Manager

   A role for managing locations; can manage accounts and devices working from his own environment downwards, but has no access to other environments.

   • ManageAccounts
   • ManageDevices
   • ManageEnvironments
   • ReviewLogs
   • ViewAccounts
   • ViewDevices
   • ViewIpAddresses

4. Regular Employee

   A regular employee, representing a nurse, security guard, or other non-managerial role; can view devices and accounts, but has no management capabilities.

   • ViewAccounts
   • ViewDevices

5. Guest

   A guest role, for example for family members of elderly residents.

   • Has no permissions.

If the predefined roles do not meet the company's needs, custom roles can be created to address specific requirements of a company.

This custom role will be available to the company that created it only, and can only be applied to its users. If the company makes a change to the role, it will be immediately applied to all users of that company.

Reference