Mandatory Access Control (MAC) mechanisms: MAC is an access control model where the system enforces security policies on objects independent of user operations. DBMSes offer a variation of MAC mechanisms called Label-Based Access Control (LBAC). LBAC lets DBAs set security labels at the row or column level and mediate access to data based on the identity and label of the user and the label of the row or column. In addition to LBAC, DB2 10 for z/OS offers RCAC, which lets you set up access rules to a table at the row and column level.
The problem with LBAC is that this approach requires data classification; it may quickly become too granular and is likely to be burdensome for most IT environments. Label-based models originated and have been widely used in military and government environments and likely are most appropriate for these settings. RCAC addresses the shortcomings of LBAC, but still lacks alignment with the least privilege security principle and dynamic separation of responsibilities.
Role-Based Access Control (RBAC): RBAC establishes security policies by granting access privileges to roles rather than individuals or groups. In the RBAC model, users can’t transfer privileges to other users. This addresses the ownership rights problem in the SQL DAC approach. RBAC differs from MAC, as it grants permissions to individual transactions rather than specific objects. Flexibility is supported through roles, which, unlike groups, can be assigned dynamically based on a variety of attributes ranging from time-based to security certificates and host names. RBAC simplifies reallocating users from one role to another and altering privileges for an existing role. RBAC can be combined with DAC and RCAC capabilities to enforce separation of responsibilities, follow the least privileges access principle, keep management overhead in check, ensure fine-grained data access and facilitate regulatory compliance.
RBAC, complemented with DAC and MAC capabilities, is the most effective option from a total-cost-of-ownership perspective. That’s attributable to the significant labor and maintenance burden associated with using the DAC or MAC access control models alone, as well as the need to meet regulatory requirements.
An efficient data access mechanism that enforces centrally managed, role-based security policies directly in the DBMS should include these capabilities (see Figure 3):
• Access roles, which are a collection of privileges defined in accordance with the separation of responsibilities and least privileges principles
• Trust context as a collection of roles dynamically associated with a user based on user identity and a multi-dimensional attribute set (i.e., security certificates, host names)
• End-to-end auditing, as directed by the accountability and traceability principle, so users in various roles don’t abuse legitimate database privileges for unauthorized purposes.
Role-Based Data Access Control for System Authorities
Executing the separation of responsibilities principle is an essential part of the access control security model and key objective of many compliance initiatives such as the Sarbanes-Oxley Act, Payment Card Industry Data Security Standard (PCI DSS), etc. Essentially, it focuses on restricting the authority of individuals to minimize opportunities for fraud and human error so no individual can control all information system administrative and support functions.
The principle of the least privilege complements the principle of separation of responsibilities and states that any entity (system or human) should have access to only the resources (platforms, data) required to perform their job functions. The principle of the least privilege can be implemented as a “need-to-know” approach where entities have access to only the functions and information relevant to their roles and duties.
To uphold these security principles, DB2 10 for z/OS introduced a new authorization model to support fine-grained system authorities and separate the people responsible for the security of the corporate data from the people responsible for the integrity and maintenance of data systems. When the system parameter SEPARATE_SECURITY is set to “YES,” the previously unrestricted power of SYSADM authority is divided among several new database roles to ensure no one has full control over both the data and configuration of the system. These new database roles separate the data security and the account management from the traditional SYSADM role. Specifically: