role that already has user members.
6.1 DEFINING ROLE MEMBERS AND DATA ACCESS REQUIREMENTS
To demonstrate the use of roles with privilege management, let’s look at the BusinessRole database, which contains our Business scenario but will use roles. Here we have the Employee and original Budget tables (with- out the Notes column included) of the previous chapter but with no privi- leges assigned. Let’s see how we can alternatively use roles to achieve and manage the data access requirements given in Table 5.5, Table 5.6 and Table 5.7. In this scenario, we can consider five roles or sets of users: a gen- eral role for all employees in the business, a role for the CEO employee(s), a role for the CFO employee(s), a role for HR employee(s), and a role for the CIO employee(s). Table 6.1 indicates the user(s) that belong in each role, with an X placed in the corresponding cell that matches a given row (user) with the role (column).
Role
user AllEmployees CEO CFO HR CIO
roberts X X
garrett X X
chu@localhost X X
gardner@192.168.2.10_ X
donnelly@localhost X
donnelly@192.168.2.8 X
sanford@localhost X X
sandord@192.168.2.% X
TABLE 6.1 Users and their roles in the business scenario.
Now let’s define the TLS and/or CLS requirements for each role.
Depending on the scenario, we may have only TLS requirements, only CLS requirements, or both TLS and CLS requirements. In this case we have both.
Table 6.2a shows the TLS specifications for each role. Notice that we are allow- ing all employees to have USAGE privilege for both tables. Recall that USAGE privilege itself does not provide for specific access to a table, but rather allows a user to access a table based on other privileges, such as the CLS privileges that we will soon include. Even though certain employees will have additional table-level privileges (such as the CFO’s requirement to add or delete rows in the Budget table), we still define a minimal set of privileges that is applied to all employees. If an employee is to have additional table-level privileges, we add to the minimal set of privileges by adding the user to another role that has those additional privileges. For example, even though user garrett is in the AllEmployees role and has minimal access to all tables, that user is also in the CFO role, and the CFO role includes the capability to add or remove rows of data in the Budget table. So garrett has USAGE privilege provided by the AllEmployees role, as well as INSERT and DELETE privileges provided by the CFO role. The HR and CIO roles also have additional privileges that are added to the privileges of the respective users who belong to those roles.
Role Employee Budget
AllEmployees usage usage
CEO usage usage
CFO usage usage,add,remove
HR usage,add,remove usage
CIO usage,grant usage,grant
TABLE 6.2A Roles and their TLS requirements that will be supplemented with CLS in the business scenario.
When we list TLS (and, as we will also soon see, CLS) requirements for roles, we may have some roles that have identical requirements. When that happens, we can either implement both roles with the identical requirements, or consolidate the roles into one role in order to implement fewer roles. Both approaches have advantages and disadvantages, and we may find that one approach is more suitable for a given scenario. For example, in Table 6.2a, the AllEmployees role and CEO role have the same TLS requirements, namely only USAGE privilege to the Employee and Budget tables. We can either implement both roles with the same sets of TLS privileges, or consolidate both roles into one.
If we implement both roles and their identical TLS requirements, notice that for any employee who has the CEO role, the CEO role adds no addi- tional TLS capabilities beyond that of the AllEmployees role. That is because in this scenario, the CEO personnel also belongs to the AllEmployees role.
Even though this particular situation involves only two roles and one user, the involvement of roles that add no additional privileges may accumulate and increase the overall number and complexity of roles to manage. In practice, when implementing security measures, we typically opt for the simpler and/
or smaller configuration of a security control. By doing so, we become less likely to compromise the principle of least privilege or introduce security vul- nerabilities. Such concerns can especially arise if we reduce a privilege in the future for one role but overlook reducing that privilege in another role that should also have had that privilege removed. As an example, suppose that the AllEmployees and CEO roles have identical privileges that include read access to some data. But later, the data access requirements change such that we must remove read privilege of that data for all employees, including the CEO. If we remove that read privilege from the AllEmployees role but over- look removing read privilege from the CEO role, the CEO personnel would still have read privilege to that data, thus compromising the principle of least privilege.
On the other hand, if the AllEmployees and CEO roles have identical privileges to a table, suppose we instead consolidate those roles, so there is not a CEO role in the TLS requirements. Consequently, the CEO is a mem- ber of only the AllEmployees role, and removing the read privilege from the AllEmployees role now affects all employees, including the CEO. Following the idea to consolidate roles when possible, we can reduce the list of roles involved with—as well as simply the management of—TLS requirements by
omitting a set of TLS privileges for the CEO role, because that set would add no additional TLS capabilities. Because the other roles do not share identical requirements, we do not consider consolidating them. Table 6.2b shows a reduced set of TLS requirements for roles, with the CEO role requirements omitted, or more accurately, consolidated with the AllEmployees role.
Role Employee Budget
AllEmployees usage usage
CFO usage usage,add,remove
HR usage,add,remove usage
CIO usage,grant usage,grant
TABLE 6.2B Reduced set of roles and their TLS requirements that will be supplemented with CLS in the business scenario.
Looking at the CIO role, we see the privileges for table usage as well as to manage user privileges. Recall that the CIO sanford@localhost is to have the capability to manage user privileges on both tables, however san- ford@192.168.2.% is to have no such capability. We can implement that dis- tinction by adding both users to the AllEmployees role, but only add sanford@
localhost to the CIO role. That in effect allows user sanford to have the CIO role, and hence the capability to manage user privileges, only when logging directly into the DBMS. In contrast, when user sanford logs into the DBMS from another system in the 192.168.2.% network, that user is considered to be in only the AllEmployees role and does not have the capability to manage user privileges.
With the TLS requirements defined, we can now look at the CLS require- ments of each table. Table 6.3a lists the CLS data access requirements for the Employee table. Here we have read-only access to nonconfidential data for all employees, but employees with the HR role additionally have read-write access to all data.
role EmpID FName LName Title
AllEmployees read read read read
CEO read read read read
CFO read read read read . . .
HR read,write read,write read,write read,write
CIO read read read read
(Continued)
Office Address SSN DOB Salary
read none none none none
read none none none none
. . . read none none none none
read,write read,write read,write read,write read,write
read none none none none
TABLE 6.3A CLS data access requirements by role for the Employee table columns.
Here we see a case that has a greater number of identical requirements between roles. Among the five roles, four of them have identical CLS require- ments. We can reduce the overall set of CLS data access requirements and simplify the implementation of column-level privileges with the consolidated list given in Table 6.3b.
role EmpID FName LName Title
AllEmployees read read read read . . .
HR read,write read,write read,write read,write
Office Address SSN DOB Salary
. . . read none none none none
read, write
read, write
read, write
read, write
read, write TABLE 6.3B Reduced set of CLS data access requirements by role for the Employee table columns.
In Table 6.4a, for the Budget table we also see some identical CLS data access requirements across roles. As with the Employee table, we can com- bine the roles that have read-only access and thus omit the HR and CIO roles.
role BudgetID Year Quarter Sales Expenses
AllEmployees read read read read read
CEO read,
write
read, write read, write read, write
read, write
CFO read, write read,
write
read, write
read, write
read, write
HR read read read read read
CIO read read read read read
TABLE 6.4A CLS data access requirements by role for the Budget table columns.
(Continued)
Turning to the CEO and CFO roles, we also see they have identical data access requirements and can be consolidated. However, such a consolidation may create some confusion, because if we were to consolidate both roles into the CEO role, then we would have to add both roberts and garrett (the CFO employee) to the CEO role. Likewise, if we had instead consolidated both roles into the CFO role, we would have to add both roberts (the CEO) and garrett to the CFO role. Either way, we add a user to a role that does not match their actual job description.
To avoid such confusion, we may choose to create a new role (such as Financial) and consolidate the CEO and CFO roles into that. However, such a choice increases the number of roles, and we must now add both users roberts and garrett to that new role. Alternatively, we may find it simpler overall to leave both the CEO and CFO roles in this set of requirements, so each role provides the necessary privileges to their user(s). Table 6.4b follows the latter approach, omitting the roles that have identical requirements to AllEmployees but keeping the CEO and CFO roles, even though they have identical data access requirements.
role BudgetID Year Quarter Sales Expenses
AllEmployees read read read read read
CEO read,
write
read, write read, write read, write
read, write
CFO read, write read,
write
read, write
read, write
read, write TABLE 6.4B Reduced set of CLS data access requirements by role for the Budget table columns.