2.4 Trustle Actors

In the Trustle environment, various actors play crucial roles in managing identity and access control. Below are the defined use cases for each actor, illustrating their responsibilities and interactions within the Trustle tool:

Organization Owner

Use Case: As the highest authority within the Trustle setup, the Organization Owner oversees all configurations and user activities. They can modify system settings, manage all users, and view comprehensive reports. For example, an Organization Owner might decide to implement a new policy that requires additional verification for users accessing highly sensitive systems.

Interactions: Organization Owners typically interact with System Owners to ensure proper configuration of each connected system and with Managers to understand and resolve any overarching issues regarding access approvals.

System Owner

Use Case: System Owners are responsible for specific systems within the Trustle framework, such as an AWS account or a Google Workspace. They manage the settings of these systems and oversee the users and resources within their scope. For instance, a System Owner of an AWS account will ensure that all IAM roles are correctly configured according to organizational policies.

Interactions: They often work closely with Organization Owners for alignment on overarching security policies and with Provisioners to ensure that access provisions to their systems are executed correctly.

Access Approver (Manager)

Use Case: Access Approvers, typically managers or supervisors, approve access requests based on necessity and compliance with security policies. For example, a manager will review and approve a request for access to financial records, ensuring that the employee has a legitimate work requirement for access.

Interactions: Access Approvers interact with Access Requestors to clarify needs or request additional information. They also interact with System Owners when approvals involve sensitive or critical system resources.

Provisioner

Use Case: Provisioners are responsible for implementing approved access requests. This can be done manually or through automated systems configured within Trustle. For example, after a manager approves access to a database, the Provisioner ensures that the employee is added to the correct user group with appropriate permissions.

Interactions: Provisioners interact with System Owners to understand the technical specifics of the systems and with Access Approvers to ensure that the provisioned access adheres to approved terms.

Principal

Use Case: Principals are the end-users or entities that request access to resources within systems. A Principal might be a developer who needs temporary access to a production server for troubleshooting. They utilize Trustle to request access, which must be approved and provisioned before use.

Interactions: Principals interact directly with Access Requestors (if they are not themselves requesting access) and Access Approvers to receive the necessary permissions for their work.

Access Requestor

Use Case: Access Requestors can either request access for themselves or on behalf of others. For example, a team lead might request access to a software development tool for a new team member. This request goes through a defined approval process tailored to the sensitivity of the access required.

Interactions: Access Requestors interact with Access Approvers to seek approval for their requests and with Provisioners who fulfill the approved access requests.

Overall Interaction Model:

The interaction between these roles creates a robust workflow within Trustle, ensuring secure and efficient access management. Organization Owners set the policies that System Owners implement. System Owners ensure technical compliance, while Access Requestors and Principals initiate the workflow for accessing resources. Access Approvers ensure that these requests meet policy standards, and Provisioners execute the approved access, completing the cycle of secure identity and access management in Trustle.