Let's look at some examples for the control table data when using the label security kit from sql server. In our case where we are desiging a UI application for security management of popular test tools, we will go by the use cases to pick and choose the values to populate in the tables. For example, we know that test tool users want to preserve the integrity of test results. Hence the results may be read write for data entry but read only for others. Likewise, read only results should be filterable. Hence read only users should be able to specify tags. Also test case cloning may be common operation requiring the use of templates. Similarly, we know that test cases can be used across suites and may be included in different matrices. Therefore they should be made available for increasing reuse. Testers may want the ease of use to define security up the object hierarchy and expect it to cascade down. Hence, we use the classifications of Reserved, private, protected and public. Further we can have compartments of none, readonly, readwrite and owner.
We may have only one category and one compartment. Categories can be hierarchical as in our case but compartments are mutually exclusive. The markings that we have for our category are the classifications mentioned above. Note that the default or guest low privileged access corresponding to public marking may not be sufficient for security provisioning of all out of box features and hence it may need to be split or refined into more classifications. The classification hierarchy is expressed in the marking hierarchy table as opposed to the marking table. Next we have the unique label table that assigns a unique label to a combination of markings and roles.
Database roles will be at least one for each possible value of an any or all comparision rule of a non-hierarchical category. For hierarchical categories, again there will be one for each possible value but the roles will also be nested. Some example of roles are guest, dev, test, production support, reporting, owners, administrator, security administrator etc.
When using label based security model, it is important to note that the labels are assigned directly to each row of the base table. The labels are small often a short byte or an integer and can have a non-clustered index on them. Sometimes, tags are not kept together in a base table but in a junction table of the base identifier and the label marking identifier. The reason this doesn't scale well is because it creates a duplicate column of the identifier. Moreover, if the identifier column is of type guid, then we can't even build an index on them and performance can suffer with scanning and full comparision between guids.Therefore, it is advisable to spend time and effort one time to add labels at the row level directly to the base table.
Next we define a view with a list of all security labels present in the database that the current user has access to. Users may or may not have access to specifying their labels with insert/update/delete. Also,
label syntax and semantics validation can be offloaded to xsd based checks when labels are represented by typed XML. Representations of labels in xml have an element per category.
We can also create helper functions looking up the labels based on id and vice versa and for resolving the label to whether a user has access to the data.
Thus we have discussed the database level schema changes for enabling row based security.
Next let's continue to look at the design of the UI application for Security.
The landing page of the UI security will have a split view between resources and users.Resource lockdown and user access management require detail view by themselves but the security admin's job can become easier if the landing page is like a dashboard with all the controls visible. Some examples are EMC Archer and Sharepoint applications that make governance easier. The security admin ideally wants to enable mapping between users and roles for a tool. Just as likely, (s)he may want an intuitive UI to define one or more of the base tables with appropriate tags. These tasks cannot be left to a designer or sql scripts. The UI for a security provisioning application is very much required to make the job easier and visual for a security admin.
Next the role provisioning, promotion and demotion of user accounts as well as selecting multiple roles for the same accounts must be facilitated with proper UI controls. It would be ideal if there's an illustration of the resultant privileges on a sample data based on the admin's selection of roles for a given user. This visual rendering of the final privilege set may re-inforce what is expected from the changes made.
Lastly, the changes made by an admin should be in the form of a ticket response such as for incident management. This ticket is opened whenever a security change is requested and the actions associated with the changes are documented in the ticket, ideally as automatic by the tool. The tickets not only obviate repudiation but also provide an audit trail.
The UI for a security application could open detailed views on any single account or role or label based on double-clicking with the ability to make and save changes. This gives a glimpse of the UI for security provisioning.
We may have only one category and one compartment. Categories can be hierarchical as in our case but compartments are mutually exclusive. The markings that we have for our category are the classifications mentioned above. Note that the default or guest low privileged access corresponding to public marking may not be sufficient for security provisioning of all out of box features and hence it may need to be split or refined into more classifications. The classification hierarchy is expressed in the marking hierarchy table as opposed to the marking table. Next we have the unique label table that assigns a unique label to a combination of markings and roles.
Database roles will be at least one for each possible value of an any or all comparision rule of a non-hierarchical category. For hierarchical categories, again there will be one for each possible value but the roles will also be nested. Some example of roles are guest, dev, test, production support, reporting, owners, administrator, security administrator etc.
When using label based security model, it is important to note that the labels are assigned directly to each row of the base table. The labels are small often a short byte or an integer and can have a non-clustered index on them. Sometimes, tags are not kept together in a base table but in a junction table of the base identifier and the label marking identifier. The reason this doesn't scale well is because it creates a duplicate column of the identifier. Moreover, if the identifier column is of type guid, then we can't even build an index on them and performance can suffer with scanning and full comparision between guids.Therefore, it is advisable to spend time and effort one time to add labels at the row level directly to the base table.
Next we define a view with a list of all security labels present in the database that the current user has access to. Users may or may not have access to specifying their labels with insert/update/delete. Also,
label syntax and semantics validation can be offloaded to xsd based checks when labels are represented by typed XML. Representations of labels in xml have an element per category.
We can also create helper functions looking up the labels based on id and vice versa and for resolving the label to whether a user has access to the data.
Thus we have discussed the database level schema changes for enabling row based security.
Next let's continue to look at the design of the UI application for Security.
The landing page of the UI security will have a split view between resources and users.Resource lockdown and user access management require detail view by themselves but the security admin's job can become easier if the landing page is like a dashboard with all the controls visible. Some examples are EMC Archer and Sharepoint applications that make governance easier. The security admin ideally wants to enable mapping between users and roles for a tool. Just as likely, (s)he may want an intuitive UI to define one or more of the base tables with appropriate tags. These tasks cannot be left to a designer or sql scripts. The UI for a security provisioning application is very much required to make the job easier and visual for a security admin.
Next the role provisioning, promotion and demotion of user accounts as well as selecting multiple roles for the same accounts must be facilitated with proper UI controls. It would be ideal if there's an illustration of the resultant privileges on a sample data based on the admin's selection of roles for a given user. This visual rendering of the final privilege set may re-inforce what is expected from the changes made.
Lastly, the changes made by an admin should be in the form of a ticket response such as for incident management. This ticket is opened whenever a security change is requested and the actions associated with the changes are documented in the ticket, ideally as automatic by the tool. The tickets not only obviate repudiation but also provide an audit trail.
The UI for a security application could open detailed views on any single account or role or label based on double-clicking with the ability to make and save changes. This gives a glimpse of the UI for security provisioning.
No comments:
Post a Comment