Additionally, notice that for the BusinessCLS.Budget table, user rob- erts has SELECT and UPDATE privileges for all columns of that table.
The columns are also listed individually, indicating that the column names were explicitly stated for the assigning of those privileges. The CFO (gar- rett) should have a similar privilege listing for the BusinessCLS.Budget table. Because of the longer line resulting from the list of column names involved with the BusinessCLS.Budget privileges, the output of that privi- lege listing may be a little difficult to read without increasing the width of the terminal window. The right side border is edited out and some lines are shortened to help make Figure 5.56 (as well as next in Figure 5.57) more readable.
For human resources personnel, Figure 5.57 shows the privileges for 'chu'@'localhost'. In a similar manner, we see that for the BusinessCLS.
Employee table, SELECT and UPDATE privilege is associated with all col- umns given by their names. Likewise, for BusinessCLS.Budget, SELECT privilege is assigned for all columns given by their names. That way, if any columns are later added to either table, they will be default secure. Other users, except for the CEO and CFO, will have a similar privilege listing for the BusinessCLS.Budget table.
FIGURE 5.57 Showing table and column-level privileges for human resources, edited for brevity.
5.8 CLS AND EVOLVING DATA ACCESS REQUIREMENTS
accessibility to more data, or reduced to require accessibility to less data.
In addition, new data may be introduced in the form of one or more new table columns that may or may not be accessible to certain employees. Let’s consider the following changes that might occur over time within our busi- ness scenario:
1. The capability for CEO and CFO to read Salary data 2. The capability for Employees to see Address data
3. The capability for executives to keep private notes in the Budget table.
The capability for CEO and CFO to read salary data
A situation may arise where management or administration may need access to certain employee PI, such as employee salaries to determine budgets, hiring considerations, or raises. If we want to give the CEO and CFO read access to employee salaries, we only need to add a column-level privilege for the Salary column to those users. Figure 5.58 illustrates how we can do so.
FIGURE 5.58 Adding an additional column-level privilege for two users to read salaries.
Note that if a user already has a set of privileges for that table, we can add to (or remove from) those privileges by specifying only the relative change to the current privileges. In other words, we do not have to specify a com- plete set of privileges that includes the current privilege(s) as well as the new privilege(s).
Now both the CEO and CFO can read data in the Salary column along with the other non-confidential data. Figure 5.59 shows user roberts retriev- ing employee names and their salaries. We should similarly test that user gar- rett can do so as well.
FIGURE 5.59 User roberts reading salary data with the newly added privilege.
The capability for employees to see address data
At times, a situation may arise where certain PI may be accessed in a limited manner, such as employee addresses for mailing of cards, gifts, or other pur- poses. If we consider that all employees may be allowed to read address data of other employees, we can incorporate that capability by similarly adding a SELECT privilege to the Address column for the affected employees. Figure 5.60 illustrates the adding of this privilege to the user roberts, and we would add this privilege similarly to other employees. Note that we do not need to add that particular privilege to human resources personnel because they already have been assigned read-write access to Address. But if we did add SELECT privilege to a user that already has a SELECT privilege for that column, there would be no functional change to the user’s capability to access that column.
FIGURE 5.60 Adding a column-level privilege to read addresses.
There can be other approaches to achieve a similar data access require- ment, and we will see some of those in later chapters. If the privilege is tem- porary, we would later have to remove that data access with the REVOKE statement as shown in Figure 5.61.
FIGURE 5.61 Removing a column-level privilege to read addresses.
We would have to similarly issue this statement for other non-human resources personnel. Note that we would have to be careful to not apply this REVOKE statement to all employees, because if applied to human resources personnel, we would remove their capability to retrieve employee addresses.
The capability for executives to keep private notes in the budget table Let’s now consider the case where a table structure may change with the crea- tion of new data. Suppose that the CEO and CFO wish to store private data in the Budget table that only they can read and write. No other employees are allowed even read access to that new data. We can implement this new data requirement by adding to the Budget table a column named Notes to store that confidential data, so that the Budget relation structure and its data is like that shown in Figure 5.62.
Budget (BudgetID, Year, Quarter, Sales, Expenses, Notes) Budget
BudgetID Year Quarter Sales Expenses Notes
B01 2021 1 1600000 1450000 (confidential)
B02 2021 2 1700000 1460000 (confidential)
B03 2021 3 1550000 1380000 (confidential)
B04 2021 4 1760000 1430000 (confidential)
B05 2022 1 1710000 1395000 (confidential)
B06 2022 2 1775000 1435000 (confidential)
B07 2022 3 1920000 1520000 (confidential)
B08 2022 4 1830000 1480000 (confidential)
FIGURE 5.62 Budget table structure and data with added column.
We can add a new column to the Budget table with the ALTER statement shown in Figure 5.63. For demonstration and testing purposes, we also fill in values for that new column.
FIGURE 5.63 Adding a new column and values for the confidential data.
Notice that the newly added Notes column is default secure, because we previously assigned column-level privileges to access the BusinessCLS.Budget data as opposed to table-level privileges. Referring back to Figure 5.56 we can confirm that column is secure by noticing that user roberts has SELECT and UPDATE privileges to the columns (BudgetID,Expenses,Quarter,Sales,Year), and that the new Notes column does not appear, either by name or inclusion by a Budget.* column wildcard. User garrett has a similar privilege listing for that table. Recall other users have no privileges to access the data in that table, so at this time no users have access to the new column.
We must then add to the CEO and CFO a privilege that allows them read-write access to the Notes column. Figure 5.64 shows the GRANT state- ment that adds read-write privilege to the CEO and CFO for the new column.
FIGURE 5.64 Adding read-write column-level privileges for confidential data.
We can confirm that users roberts and garrett now have access to the new column, as illustrated for roberts in Figure 5.65.
FIGURE 5.65 Testing that user roberts has successful read-write access to confidential data.
The added Notes column is an example of how we must be careful with table-level privileges in order to maintain the principle of least privilege with columns added in the future. If we had previously assigned a user read-only access to the BusinessCLS.Budget table and later added the Notes column, that user would now have read-only access to the confidential Notes column by default. However, because we previously assigned non-CEO and non- CFO users read-only privilege at the column-level by specifying all columns by name, there are no privileges for the newly added Notes column until we assign such, so the data in that new column is default secure. Consequently, by default, or without any additional steps, all non-CEO and non-CFO employ- ees have no access to that column, as demonstrated and tested by user chu in Figure 5.66.
FIGURE 5.66 Testing that user chu has unsuccessful read-write access to confidential data.
While column-level privileges provide more detailed security manage- ment over table-level privileges, table-level privileges and splitting tables can still be helpful. First, if we can split tables so that all columns within a table share the same security requirement, we may simplify database security man- agement by assigning privileges on a table-basis only, rather than on both a table- and column-level basis. Second, the task of specifying privileges for every necessary column by name raises the risk of omitting a column or incor- rectly defining a column’s privilege, either of which can potentially compro- mise all CIA security principles. This may result with loss of confidentiality
(by improperly allowing read access to unauthorized individuals, loss of integ- rity (by improperly allowing write or delete access to unauthorized individuals) or loss of availability (by disallowing access to authorized individuals). Finally, while most DBMSs support column-level privileges, one may encounter a DBMS (or an earlier version of one) that may not adequately support per-col- umn privileges, and another approach such as table-level privileges may be necessary.