Here's a 3:30 minutes video. If you prefer text, scroll down.
Role Based Access Control for Sophie
This topic explains what is Role-Based Access Control (RBAC) and how it is implemented in Loom-Systems’ AI platform Sophie.
How can RBAC benefit you?
Role-based Access Control (RBAC) is a method of regulating access to a computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or change specific data.
What is it good for (in Sophie’s context)?
Scenario A- Regulatory reasons: Logs from certain sources contain sensitive data, for example Personally Identifiable Information (PII), or security-related information that not all users in the organization are allowed to see. RBAC allows the organization to apply its policy within Sophie.
Scenario B: Multi-Tenancy: This can allow an MSP to control its customers’ data with different sets of permissions, allowing customers access only to the data that is relevant to them.
Implementation in Sophie:
Sophie’s latest version includes a new concept: Groups. A Data Input can be linked to a specific group, so only users that were associated to the group will have associated permissions to the data.
All Monitored Sources generated from this Data Input will automatically inherit the group(s) linked to the Data Input. For a more granular permission, it is possible to set permissions within the “child” of the Data Input, specific per each Monitored Source.
A user, group, or monitored source can be a member of multiple groups. When a user and a source have at least one group in common, the user will be able to access the associated data.
Elastic Indices and Kibana:
Needless to say, the permission policy also applies for the indices. In order to support this, indices in Loom are now defined per Source and not per Application. Future version will allow both views in Kibana.
Alerts and Correlations:
RBAC won’t affect the way Loom calculates alerts or correlations. However, a user will be presented only with alerts and correlations he or she has permissions to. So, there could be a case in which a user sees only a partial incident, while a user with superior privileges sees a more comprehensive incident (in the example above, user2 won’t see that an incident he or she is watching is also correlated to an alert from Cinder, although user1 will be able to see that). Future versions will include an indication to the user that there is more information to the incident.
- Under “Manage Users” there is now a new tab, “Groups”. Within this tab you can create and edit groups.
2. Click “New” in order to create and name new groups.
3. Add the relevant role(s) to the newly created group.
4. Select desired user you wish to add to a specific group, by clicking on their ID.
5. Assign one of the available groups to the user.
6. Go to Data Inputs, click on 3 dots at end of relevant Data Input and then select Permissions in drop-down.
7. Select desired Group you wish to grant access to this Data Source.