Employee (EmpID, FName, LName, Title, Office) HR (EmpID, Address, SSN, DOB, Salary)
Employee
EmpID FName LName Title Office
E01 Tom Roberts CEO A110
E02 Alison Garrett CFO A118
E03 Betty Chu HR Director A203
E04 Cindy Donnelly Sales Director B116
E05 Alex Gardner Sales Assoc B118
E06 Miguel Sanford CIO A202
HR
EmpID Address SSN DOB Salary
E01 212 Orchid Ave 000-404-1234 03/01/1957 175000 E02 1234 Brown St 000-145-0909 05/25/1966 140000 E03 67 Tulip Lane 000-223-7888 10/13/1973 80000 E04 101 Harrison Ave 000-132-5673 02/17/1970 60000 E05 73 East Liberty 000-454-9654 10/16/1982 48000 E06 43 Falcon Dr 000-065-7788 02/15/1967 160000
FIGURE 5.37 Employee data with PI and PII in separate tables.
Now we can increase security on the PI and PII with table-level privi- leges by specifying different access requirements to the non-PI and non-PII data in the Employee table compared to the PI and PII data in the HR table.
Specifically, we want to allow only human resources to have read-write—as well as add and remove—access to both tables. We also want to allow all other employees to have just read-only access to Employee, and no access at all to the HR table. Table 5.4 lists the user access specifications for the new database.
User Account Employee HR Budget
roberts read none read, write
garret read none read, write, add, delete
chu@localhost read, write, add, delete read, write, add, delete read
gardner@192.168.2.10_ read none read
donnelly@localhost read none read
donnelly@192.168.2.8 read none read
sanford@localhost read, grant none, grant read, grant
sandord@192.168.2.% read none read
TABLE 5.4 Defining user data access requirements for tables in the BusinessTLSSplitHR database.
Note the privileges we previously applied to BusinessTLS have no effect on BusinessTLSSplitHR, so we have a clean slate upon which to work; as previously mentioned, it is generally good practice to start default secure in order to prevent inadvertently leaving a user with too many privileges.
Because the access requirements for BusinessTLSSplitHR.Employee are the same as with BusinessTLS.Employee, we can apply the same privileges to that table, as shown in Figure 5.38. In this example, we first choose to use the BusinessTLSSplitHR database so we do not have to specify the database name in each grant statement. We also issue the first privileges to ' sanford'@'localhost', because as an administrator account, that user could then issue the remaining privilege grants. We then assign read-only privileges to all of the non-human resource personnel as a precaution. By specifying a series of lower privileges before assigning the higher privilege, we can help avoid accidently assigning human resource privileges to a non-human resource employee, especially if we are recalling and editing previous statements.
FIGURE 5.38 Assigning privileges to the nonconfidential employee data.
Also note that rather than create a new BusinessTLSSplitHR database with the split tables, we could have instead edited BusinessTLS and moved the PI and PII columns out of the Employee table into a new HR table. In this manner, the grants that were previously issued to the Employee table would still exist, and in this case can be used as is because the access to that nonconfidential data did not change in this particular scenario. However, in practice we should carefully assess whether it is best from a principle of least privilege goal to start with a default secure new database and add the neces- sary privileges for user data access requirements, or modify the current data- base and manage its privileges accordingly, which may involve adding as well as removing privileges. Depending on the situation, either approach may be best in terms of or require fewer steps to implement.
To the newly split HR table, we now must assign human resources personnel read, write, add, and remove access, as shown in Figure 5.39.
FIGURE 5.39 Assigning privileges to the confidential employee data.
Note that in Figure 5.39 we designate that 'sanford'@'localhost' has the capability to manage privileges even though that user has no access to the table’s data. Such a designation allows us to implement the situation that 'sanford'@'localhost' (or any other such database administrator) has the capa- bility to add or remove user privileges to the HR table as necessary, while keeping the PI and PII confidential or inaccessible to themselves. To assign such a privilege, we can assign no data access to the table by specifying only the USAGE privilege along with the WITH GRANT OPTION clause.
Another way we can assign the capability to manage user privileges to a table but have no other data access is by specifying GRANT OPTION as the privilege, as shown in Figure 5.40.
FIGURE 5.40 Alternative approach to assign no data access but capability to manage privileges.
Regardless of how we specify a no-access privilege, we can then list the privileges of 'sanford'@'localhost' and see the capability to grant privileges but no read or other access to the data. Figure 5.41 shows the user’s privileges, and in particular the privilege listing for the BusinessTLSSplitHR.HR table shows USAGE privilege and the capability to manage user privileges.
FIGURE 5.41 Showing no data access but capability to manage privileges.
We can complete the necessary privileges for our new database by assign- ing them for the Budget table. The privileges for the Budget table and its user access specifications are identical to that in the BusinessTLS database, so we can assign the privileges in a similar manner, as shown in Figure 5.42.
FIGURE 5.42 Assigning privileges to the confidential employee data.
We can now keep PI and PII confidential to non-human resource per- sonnel. We should test all user access to ensure the defined access require- ments are met as expected. As examples, Figure 5.43 shows that roberts has no capability to access the HR table (that should be the case for all non-hu- man resources personnel).
FIGURE 5.43 Demonstrating that user roberts has no access to the HR data.
Figure 5.44 issues a data retrieval to confirm that 'chu'@'localhost' has read access to the HR table. We could also test further to show that par- ticular user also has the capability to change, add, and remove data to that table.
FIGURE 5.44 Demonstrating that user chu has access to the HR data.
TLS can often provide a great deal of data security in a flexible man- ner. However, there may be cases when TLS may not fully meet our data needs. Consider that in our goal to keep PI and PII confidential, a non-hu- man resource employee does not have the capability to see their own data or manage their data directly. For such requirements, we have to turn to other levels of data security, such as column-level or row-level security, or employ other data access mechanisms. We will describe all of those, starting with column-level security next.