What is RLS in CA Data Protection?

Document ID : KB000069627
Last Modified Date : 11/06/2018
Show Technical Document Details
Introduction:
CA Data Protection (DataMinder) employs security models to ensure that reviewers can only see events they are permitted to see when searching the CMS database for events.
Question:

What is RLS (row level security)?  What are the different Row Level Security (RLS) security models?

 

Environment:
CA Data Protection 14.x\ 15.x
Answer:

RLS (Row Level Security) is a method by which security models are applied to the Data Protection Database to create a view of events that will be used to generate reports and searches for reviewers. The terminologies 'security models' and 'RLS' are often cited to mean the same thing, a filtered control that restricts a reviewers access to events.

RLS ensures that reviewers (or any search user) cannot see events associated with users outside of their management groups (or policy) when searching the CMS database for events. You can apply RLS based on certain policies that the reviewer can see or have a combination of both types of RLS (this is known as a hybrid model). RLS is primarily applied to events, users and groups for management group RLS with the underlying tables (Wgn3Event, Wgn3User and WgnGroup) inaccessible directly to search users. For policy based RLS, this also applies to triggers (Wgn3Trigger). In order to access these underlying tables and to ensure that RLS is not bypassed, several views have been created, and you should use these views when writing reports.

Within the CA Data Protection infrastructure each user of the system has a username and an associated set of privileges that give permissions to certain features of the software. These privileges are set to either on or off. When a user requires a connection to the database the infrastructure checks the CA Data Protection user privileges. One privilege is 'Admin: Disable Security Model Filtering' and this determines whether or not RLS is applied to a user. By default, it is disabled for all CA Data Protection users except administrators, but can be enabled if a particular user or group of users requires access to all events, thus bypassing RLS.

 You can choose which models are active on your CMS and multiple models can be active at the same time, the default security model being Management Group (Standard). However, each reviewer can only be linked to a single model at a time. 

 

You can manage security models in the Administration console.

To enable a security model on the CMS

  1. Choose Tools, Manage Security Models. 
  2. In the Manage Security Models dialog, click Add. 
  3. In the Create Security Model dialog, you can configure the model you want.

 

To modify a security model 

  1. Choose Tools, Manage Security Models. 
  2. Select model you want and click Modify. 
  3. You can now change the database user name or model type.

 

CA Data Protection supports the following security models:

 

Management Group (Standard) 

This is the default model, optimized to allow fast searching. It is based on the CA Data Protection user hierarchy.   It uses e-mail addresses (including synthesized addresses for participants in Web and Application Monitor events) to map participants to CA Data Protection users. Under this model, reviewers can only view events where at least one participant was in their management group when the event was captured.

 

Management Group (Standard, Self-Exclude) 

This model prevents reviewers from seeing their own events. As above, reviewers can only view events where at least one participant was in their management group. However, under this model the search results also exclude any events in which the ‘logged-on user’ (that is, the reviewer) was a participant. 

 

Management Group (Sender) 

Under this model, when a reviewer runs an e-mail search, they can only view events where the e-mail sender was in their management group when the event was captured.  This sender-centric security model is only appropriate for e-mail searches. Searches for other event types will return zero results.

 

Management Group (Sender, Self-Exclude) 

This model prevents reviewers from seeing their own e-mails (or any other events) when they run a search. As above, reviewers can only view events where the e-mail sender was in their management group. However, under this model the search results also exclude any events in which the ‘logged-on user’ (that is, the reviewer) was a participant. 

 

Policy (Standard) 

This model ensures that reviewers can only see specific types of event. For example, this model can be used to ensure that HR reviewers only see events that relate to HR issues such as employee behavior, while Legal reviewers only see events that relate to legal issues such as litigation threats or a breach of attorney client privilege. 

 

The model is based on policy classes. For categorization purposes, you can associate individual triggers with a policy class, such as ‘Employee Behavior’ or ‘Legal’. When a trigger fires, the policy class is stored with the associated event.  Likewise, each reviewer has a policy role. A policy role links a user to a collection of policy classes. In effect, the policy role determines which policy classes a user is permitted to see. When the user runs a search, the results only include events associated with these policy classes. 

 

Policy (Standard, Self-Exclude) 

This variant of the Policy model prevents reviewers from seeing their own events. As above, reviewers can see only specific types of event. However, the search results also exclude any events in which the reviewer was a participant

 

Hybrid Model: Management Group and Policy 

If required, you can add a hybrid model on your CMS. This combines the Management Group and Policy models. Its effect is to restrict reviewers so they can only see specific types of event associated with users in their management group. For example, under this model a reviewer in the Legal team can only review legal events associated with members of their management group.

 

Unrestricted 

This model is not subject to row level security (RLS). It permits reviewers to see any events when they run a search or report. Search results or reports are not restricted by policy class or the reviewer’s management group. This model is primarily required by CA Data Protection user accounts set up explicitly for use by external reporting tools when searching the Data Warehouse for events. 

 

Note: You can only assign the Unrestricted security model to a CA Data Protection user if you have the 'Admin: Disable security model filtering' administrative privilege. 

 

 

 

RLS.jpg

 

Additional Information:

You must be aware of the following:

Moving a user or group can cause unintended changes to their policy!
Although users and groups normally retain any customized policy settings or attributes when they are moved to a new parent group, it is possible that these will be overwritten if the corresponding settings or attributes inherited from the new parent group are already enforced. To avoid such unintended changes, you can configure the Administration console to display a warning before you confirm a move.


Moving a group can cause unintended row level security issues!
If a group (and therefore its users) is moved from one parent group to another, the events associated with those users are also ‘moved’. Reviewers with rights to the first group lose access to those events, but reviewers with rights to the second group gain access to those events.

This means that reviewers in the second group can view events associated with users that were not in their management group at the time the event was captured.
If this is likely to cause a problem, we recommend you leave the Allow Groups to be Moved policy setting at its default setting of False and move users between groups by creating new target groups and moving users as required. This reduces the row level security risk.