Organizational Structures
A discussion of different methods of distributing access rights on an organizational level.
Last updated
A discussion of different methods of distributing access rights on an organizational level.
Last updated
A single company often operates several sensors distributed between installations. These installations can be independent both in development and deployment, requiring consideration for how access rights are managed.
Where different installations are separated by project, one method may be to manage the access rights within the project itself. By creating Service Accounts within projects as required, with different roles, only the required access needs to be granted.
This would allow all projects to be independent of each other regarding access rights. For a Service Account to access an installation, the credentials for that specific project would have to be obtained. This allows for much more granular control at the expense of some management.
Similar behavior to Project-Isolated Access could also be achieved by having a single project dedicated to Service Account management. Here, multiple Service Accounts would be created in a single project and given a role in different projects depending on the task they’re going to perform.
In terms of granularity of control, the result is much the same as having Service Accounts in the related projects. However, depending on how the task of managing the access rights falls within the organization, this method may prove to be simpler in generating an overview of who can access what.
In cases where Company A provides a service to Company B, an exchange of access rights may be necessary. Service Accounts can be used to accomplish this safely.
We have created a mock situation where Company A would like to provide a monitoring and alerting service to Company B and C.
Company A creates a project with an accompanying Service Account for each of their clients, Company B and C.
The credentials for these Service Accounts are copied to the monitoring system, using the Service Accounts to fetch data through the REST API.
Company A provides Company B and C with the respective Service Accounts email addresses and requests to create a member with sufficient access. Company B gives project-level access rights as only a few projects are to be monitored. Company C gives organization-level access, allowing Company A to fetch data from all projects.
Afterward, Company A’s monitoring system can log in using the Service Accounts and list the projects and the sensors within them, then fetch data as they see fit. For Company C, which gave organization-level access, Company A can create and delete projects, move devices between all the projects, and invite new members to the organization.
This approach would allow both the service provider, Company A, and its customers to be in control. Company B and C can at any time revoke access to Company A in their respective projects by removing the Service Account members. Likewise, Company A is in a position where it can invoke security routines such as rotating key-ids at will.
Company A could also use a single Service Accounts residing in its inventory project. This would simplify management as the same Service Account Email would be handed out to all clients. While simpler, this could make the probability of mixing clients higher, though it does not come at the expense of security. The members created by the clients fetch data in the monitoring service, keeping them isolated.
