Row and Column Access Control Support in IBM DB2 For I: Paper
Row and Column Access Control Support in IBM DB2 For I: Paper
Jim Bainbridge
Hernando Bedoya
Rob Bestgen
Mike Cain
Dan Cruikshank
Jim Denton
Doug Mack
Tom McKinley
Kent Milligan
ibm.com/redbooks Redpaper
International Technical Support Organization
November 2014
REDP-5110-00
Note: Before using this information and the product it supports, read the information in “Notices” on
page vii.
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Contents v
vi Row and Column Access Control Support in IBM DB2 for i
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not grant you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the
materials for this IBM product and use of those websites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Any performance data contained herein was determined in a controlled environment. Therefore, the results
obtained in other operating environments may vary significantly. Some measurements may have been made
on development-level systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been estimated through
extrapolation. Actual results may vary. Users of this document should verify the applicable data for their
specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AS/400® IBM® Redpaper™
DB2® Power Systems™ Redbooks (logo) ®
DRDA® Redbooks® System i®
Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other
countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
viii Row and Column Access Control Support in IBM DB2 for i
DB2 for i Center of Excellence
DB2 for i
Center of Excellence
Expert help to achieve your business requirements
IBM, the IBM logo, ibm.com, DB2 and Power Systems are trademarks of
Key client benefits T
International Business Machines Corp., registered in many jurisdictions
worldwide. Other product and service names might be trademarks of IBM
Gain greater database and application performance within or other companies. A current list of IBM trademarks is available on the
your current environment. Achieve greater productivity in web at “Copyright and trademark information” at www.ibm.com/legal/
the development and maintenance of database and copytrade.shtml.
applications using modern techniques. Architect and design This document is current as of the initial date of publication and may be
data structures to accommodate and benefit from business changed by IBM at any time.
analytics (BA) tools and processes. Not all offerings are available in every country in which IBM operates.
Please Recycle
For more information
Pricing depends on the scope of work. Learn more about
the DB2 for i Center of Excellence and other related
products and services. Contact [email protected] or visit:
ibm.comV\VWHPVVHUYLFHVODEVHUYLFHV
QLS12392-USEN-00
Preface
This IBM® Redpaper™ publication provides information about the IBM i 7.2 feature of IBM
DB2® for i Row and Column Access Control (RCAC). It offers a broad description of the
function and advantages of controlling access to data in a comprehensive and transparent
way. This publication helps you understand the capabilities of RCAC and provides examples
of defining, creating, and implementing the row permissions and column masks in a relational
database environment.
This paper is intended for database engineers, data-centric application developers, and
security officers who want to design and implement RCAC as a part of their data control and
governance policy. A solid background in IBM i object level security, DB2 for i relational
database concepts, and SQL is assumed.
Authors
This paper was produced by the IBM DB2 for i Center of Excellence team in partnership with
the International Technical Support Organization (ITSO), Rochester, Minnesota US.
xii Row and Column Access Control Support in IBM DB2 for i
Tom McKinley is an IBM Lab Services Consultant working on
DB2 for IBM i in Rochester MN. His main focus is complex
query performance that is associated with Business
Intelligence running on Very Large Databases. He worked as a
developer or performance analyst in the DB area from 1986
until 2006. Some of his major pieces of work include the
Symmetric Multiple processing capabilities of DB2 for IBM i
and Large Object Data types. In addition, he was on the
original team that designed and built the SQL Query Engine.
Before his database work, he worked on Licensed Internal
Code for System 34 and System 36.
Debra Landon
International Technical Support Organization, Rochester Center
Craig Aldrich, Mark Anderson, Theresa Euler, Scott Forstie, Chad Olstad
IBM Rochester Development
Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about this paper or
other IBM Redbooks publications in one of the following ways:
Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
Preface xiii
Send your comments in an email to:
[email protected]
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
xiv Row and Column Access Control Support in IBM DB2 for i
1
Businesses must make a serious effort to secure their data and recognize that securing
information assets is a cost of doing business. In many parts of the world and in many
industries, securing the data is required by law and subject to audits. Data security is no
longer an option; it is a requirement.
This chapter describes how you can secure and protect data in DB2 for i. The following topics
are covered in this chapter:
Security fundamentals
Current state of IBM i security
DB2 for i security controls
1
http://www.idtheftcenter.org
2 http://www.ponemon.org/
With your eyes now open to the importance of securing information assets, the rest of this
chapter reviews the methods that are available for securing database resources on IBM i.
Even more disturbing is that many IBM i clients remain in this state, despite the news
headlines and the significant costs that are involved with databases being compromised. This
default security configuration makes it quite challenging to implement basic security policies.
A tighter implementation is required if you really want to protect one of your company’s most
valuable assets, which is the data.
Traditionally, IBM i applications have employed menu-based security to counteract this default
configuration that gives all users access to the data. The theory is that data is protected by
the menu options controlling what database operations that the user can perform. This
approach is ineffective, even if the user profile is restricted from running interactive
commands. The reason is that in today's connected world there are a multitude of interfaces
into the system, from web browsers to PC clients, that bypass application menus. If there are
no object-level controls, users of these newer interfaces have an open door to your data.
Although exit-point solutions can provide great benefits, they are not an alternative to
object-level control of your databases. Exit-point solutions help secure interfaces, but they do
not completely protect the data that is stored in your DB2 objects. Exit points do not exist for
every data access interface on the system. Therefore, if an application starts using an
unprotected interface, the only thing protecting your data is object-level access control. When
your security implementation totally relies on exit points, then it is also important to track any
new data interfaces that appear as IBM delivers new releases and products to ensure that
your exit-point solution provides coverage for those new interfaces.
An exit-point solution is a good option for databases with security holes that are caused by a
reliance on the default security setup or menu-based control. However, your security work
should not stop there. Instead, you must continue to work on a complete database security
solution by controlling data access at the object level.
Database
User
Access: ALL or NOTHING T bl
Table
Using SQL views to limit access to a subset of the data in a table also has its own set of
challenges. First, there is the complexity of managing all of the SQL view objects that are
used for securing data access. Second, scaling a view-based security solution can be difficult
as the amount of data grows and the number of users increases.
Even if you are willing to live with these performance and management issues, a user with
*ALLOBJ access still can directly access all of the data in the underlying DB2 table and easily
bypass the security controls that are built into an SQL view.
User with
*ALLOBJ access
The new DB2 RCAC support provides a method for controlling data access across all
interfaces and all types of users with a data-centric solution. Moving security processing to
the database layer makes it easier to build controls that meet your compliance policies. The
RCAC support provides an additional layer of security that complements object-level
authorizations to limit data access to a need-to-know basis. Therefore, it is critical that you
first have a sound object-level security implementation in place.
To accomplish these tasks, RCAC engineers devised a set of functional roles that, as a group,
implement effectively data access requirements and also limit the span of control of each role
so that each role is given only the authorities that are needed to perform its specific set of
tasks.
This chapter describes the concepts of roles and separation of duties on DB2 for i and covers
the following topics:
Roles
Separation of duties
To assist with defining roles and the separation of duties with appropriate authority, IBM i
provides function usage IDs. A function usage ID implements granular security controls rather
than granting users powerful special authorities, such as all object, job control, or service.
Roles are divided among the following DB2 functions and their corresponding function usage
IDs:
DDM and IBM DRDA® application server access: QIBM_DB_DDMDRDA
Toolbox application server access: QIBM_DB_ZDA
Database Administrator function: QIBM_DB_SQLADM
Database Information function: QIBM_DB_SYSMON
Security Administrator function: QIBM_DB_SECADM
This function usage ID provides an easy alternative (rather than writing an exit program) to
control access to these functions from the server side. The function usage IDs ship with the
default authority of *ALLOWED. The security officer can easily deny access to specific users
or groups.
The Database Administrator function provides an alternative to granting *JOBCTL, but simply
having the Database Administrator authorization does not carry with it all the needed object
authorities for every administration task. The default behavior is to deny authorization.
To perform database administrator tasks that are not related to performance analysis, you
must refer to the details of the task to determine its specific authorization requirements. For
example, to allow a database administrator to reorganize a table, the DBA must have
additional object authorities to the table that are not covered by QIBM_DB_SQLADM.
For example, a user that does not have *JOBCTL or QIBM_DB_SQLADM can still view the
SQL Plan Cache properties if granted authority to QIBM_DB_SYSMON. Without granting this
authority, the default behavior is to deny authorization.
Only those users with the QIBM_DB_SECADM function can administer and manage RCAC
rules. RCAC can be used to prevent even users with *ALLOBJ authority from freely accessing
all the data in a protected database. These users are excluded from data access unless they
are specifically authorized by RCAC. Without granting this authority, the default behavior is to
deny authorization.
For example, the following CHGFCNUSG command shows granting authorization to user
HBEDOYA to administer and manage RCAC rules:
CHGFCNUSG FCNID(QIBM_DB_SECADM) USER(HBEDOYA) USAGE(*ALLOWED)
2.1.7 Verifying function usage IDs for RCAC with the FUNCTION_USAGE view
The FUNCTION_USAGE view contains function usage configuration details. Table 2-1
describes the columns in the FUNCTION_USAGE view.
USER_NAME VARCHAR(10) Name of the user profile that has a usage setting for this
function.
To discover who has authorization to define and manage RCAC, you can use the query that is
shown in Example 2-1.
Example 2-1 Query to determine who has authority to define and manage RCAC
SELECT function_id,
user_name,
usage,
user_type
FROM function_usage
WHERE function_id=’QIBM_DB_SECADM’
ORDER BY user_name;
In IBM i 7.2, the QIBM_DB_SECADM function usage grants authorities, revokes authorities,
changes ownership, or changes the primary group without giving access to the object or, in
the case of a database table, to the data that is in the table or allowing other operations on the
table.
QIBM_DB_SECADM function usage can be granted only by a user with *SECADM special
authority and can be given to a user or a group.
QIBM_DB_SECADM also is responsible for administering RCAC, which restricts which rows
a user is allowed to access in a table and whether a user is allowed to see information in
certain columns of a table.
A preferred practice is that the RCAC administrator has the QIBM_DB_SECADM function
usage ID, but absolutely no other data privileges. The result is that the RCAC administrator
can deploy and maintain the RCAC constructs, but cannot grant themselves unauthorized
access to data itself.
Table 2-2 shows a comparison of the different function usage IDs and *JOBCTL authority to
the different CL commands and DB2 for i tools.
Table 2-2 Comparison of the different function usage IDs and *JOBCTL authority
User action
QIBM_DB_SQLADM
QIBM_DB_SECADM
QIBM_DB_SYSMON
No Authority
*JOBCTL
STRDBMON or ENDDBMON commands targeting a job that matches the current user X X X X
QUSRJOBI() API format 900 or System i Navigator's SQL Details for Job X X X
MODIFY PLAN CACHE PROPERTIES procedure (currently does not check authority) X X
CHANGE PLAN CACHE SIZE procedure (currently does not check authority) X X
QIBM_DB_SYSMON
QIBM_DB_SECADM
QIBM_DB_SQLADM
No Authority
*JOBCTL
START PLAN CACHE EVENT MONITOR procedure X X
In DB2 for i, RCAC is implemented using two different approaches that address the
shortcomings of traditional control methods and mechanisms:
Row permissions
Column masks
Another benefit of RCAC is that no database user is automatically exempt from the control.
Users with *ALLOBJ authority can no longer freely access all of the data in the database
unless they have the appropriate permission to do so. The ability to manage row permissions
and column masks rests with the database security administrator. The RCAC definitions,
enablement, and activation are controlled by SQL statements.
Row permissions and column masks require virtually no application changes. RCAC is based
on specific rules that are transparent to existing applications and SQL interfaces.
Enforcement of your security policy does not depend on how applications or tools access the
data.
RCAC also facilitates multi-tenancy, which means that several independent customers or
business units can share a single database table without being aware of one another. The
RCAC row permission ensures each user sees only the rows they are entitled to view
because the enforcement is handled by DB2 and not the application logic.
Label-based access control (LBAC): RCAC and LBAC are not the same thing. LBAC is a
security model that is primarily intended for government applications. LBAC requires that
data and users be classified with a fixed set of rules that are implemented. RCAC is a
general-purpose security model that is primarily intended for commercial customers. You
can use RCAC to create your own security rules, which in turn allows for more flexibility.
Row permission
A row permission is a database object that manifests a row access control rule for a specific
table. It is essentially a search condition that describes which rows you can access. For
example, a manager can see only the rows that represent his or her employees.
AS <correlation name>
Indicates that a row permission is created
ENABLE S ifi th
Specifies thatt th
the row permission
i i iis tto b
be iinitially
iti ll disabled
di bl d
DISABLE;
Column mask
A column mask is a database object that manifests a column value access control rule for a
specific column in a specific table. It uses a CASE expression that describes what you see
when you access the column. For example, a teller can see only the last four digits of a tax
identification number.
ON <table name>
Specifies an optional correlation name that can be used within case-expression
AS <correlation name>
Identifies the column to which the mask applies
Enabling and disabling effectively turns on or off the logic that is contained in the row
permission or column mask. Regenerating causes the row permission or column mask to be
regenerated. The row permission definition in the catalog is used and existing dependencies
and authorizations, if any, are retained. The row permission definition is reevaluated as
though the row permission were being created. Any user-defined functions (UDFs) that are
referenced in the row permission must be resolved to the same secure UDFs as were
resolved during the original row permission or column mask creation. The regenerate option
can be used to ensure that the RCAC logic is intact and still valid before any user attempts to
access the table.
Note: An exclusive lock is required on the table object to perform the alter operation. All
open cursors must be closed.
You can activate and deactivate RCAC for new or existing tables by using the SQL ALTER
TABLE statement (Figure 3-4). The ACTIVATE or DEACTIVATE clause must be the option that is
specified in the statement. No other alterations are permitted at the same time. The activating
and deactivating effectively turns on or off all RCAC processing for the table. Only enabled
row permissions and column masks take effect when activating RCAC.
Note: An exclusive lock is required on the table object to perform the alter operation. All
open cursors must be closed.
Id tifi th
Identifies the ttable
bl tto b
be altered
lt d
It is possible to define, create, and enable multiple permissions on a table. Logically, all of the
permissions are ORed together to form a comprehensive test of the user's ability to access
the data. A column can have only one mask that is defined over it. From an implementation
standpoint, it does not matter if you create the column masks first or the row permissions first.
Note: If a user does not have permission to access the row, the column mask logic is not
invoked.
IBM DB2 for i supports four different special registers that can be used to identify what user
profiles are relevant to determining object authorities in the current connection to the server.
SQL uses the term runtime authorization ID, which corresponds to a user profile on
DB2 for i. Here are the four special registers:
USER is the runtime user profile that determines the object authorities for the current
connection to the server. It has a data type of VARCHAR(18). This value can be changed
by the SQL statement SET SESSION AUTHORIZATION.
SESSION_USER is the same as the USER register, except that it has a data type of
VARCHAR(128).
CURRENT USER was added in IBM i 7.2 and is similar to the USER register, but it has
one important difference in that it also reports adopted authority. High-level language
programs and SQL routines such as functions, procedures, and triggers can optionally be
created to run using either the caller's or the owner's user profile to determine data
authorities. For example, an SQL procedure can be created to run under the owner's
authority by specifying SET OPTION USRPRF=*OWNER. This special register can also be
referenced as CURRENT_USER. It has a data type of VARCHAR(128).
SYSTEM_USER is the user profile that initiates the connection to the server. It is not used
by RCAC, but is included here for completeness. Many jobs, including the QZDASOINIT
prestarted jobs, initially connect to the server with a default user profile and then change to
use some other user profile. SYSTEM_USER reports this value, typically QUSER for a
QZDASOINIT job. It has a data type of VARCHAR(128).
In addition to these four special registers, any of the DB2 special registers can be referenced
as part of the rule text.
CURRENT_USER The effective user of the thread including adopted authority. When no adopted
authority is present, this has the same value as USER.
Figure 3-5 shows the difference in the special register values when an adopted authority is
used:
A user connects to the server using the user profile ALICE.
USER and CURRENT USER initially have the same value of ALICE.
ALICE calls an SQL procedure that is named proc1, which is owned by user profile JOE
and was created to adopt JOE's authority when it is called.
While the procedure is running, the special register USER still contains the value of ALICE
because it excludes any adopted authority. The special register CURRENT USER
contains the value of JOE because it includes any adopted authority.
When proc1 ends, the session reverts to its original state with both USER and CURRENT
USER having the value of ALICE.
Signed on as ALICE
USER = ALICE
CURRENT USER = ALICE
CALL proc1
Proc1:
P 1
Owner = JOE
SET OPTION USRPRF=*OWNER
USER = ALICE
CURRENT USER = JOE
USER = ALICE
CURRENT USER = ALICE
Figure 3-5 Special registers and adopted authority
IBM DB2 for i supports nine different built-in global variables that are read only and
maintained by the system. These global variables can be used to identify attributes of the
database connection and used as part of the RCAC logic.
CLIENT_HOST VARCHAR(255) Host name of the current client as returned by the system
CLIENT_PORT INTEGER Port used by the current client to communicate with the server
If a special register value is in the list of user profiles or it is a member of a group profile
included in the list, the function returns a long integer value of 1. Otherwise, it returns a value
of 0. It never returns the null value.
In the case of a row permission, the rule text is the “test” of whether the user can access the
row. If the test result is true, the row can be accessed. If the test result is false, the row
essentially does not exist for the user. From a set-at-a-time perspective, the permission
defines which rows can be part of the query result set, and which rows cannot.
In the case of a column mask, the rule text is both the test of whether the user can see the
actual column value, and it is the masking logic if the user cannot have access to actual
column value.
For a simple example of implementing row permissions and column masks, see 3.6, “Human
resources example” on page 22.
In general, almost any set-based, relational logic is valid. For the row permission, the search
condition follows the same rules that are used by the search condition in a WHERE clause.
For the column mask, the logic follows the same rules as the CASE expression. The result
data type, length, null attribute, and CCSID of the CASE expression must be compatible with
the data type of the column. If the column does not allow the null value, the result of the CASE
expression cannot be the NULL value. The application or interface making the data access
request is expecting that all of the column attributes and values are consistent with the
original definition, regardless of any masking.
For more information about what is permitted, see the “Database programming” topic of the
IBM i 7.2 Knowledge Center, found at:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzahg/rzahgdbp.htm?lang
=en
One of the first tasks in either the row permission or the column mask logic is to determine
who the user is, and whether they have access to the data. Elegant methods to establish the
identity and attributes of the user can be employed by using the special registers, global
variables, and the VERIFY function. After the user's identity is established, it is a simple
matter of allowing or disallowing access by using true or false testing. The examples that are
included in this paper demonstrate some of the more common and obvious techniques.
More sophisticated methods can employ existential, day of year / time of day, and relational
comparisons with set operations. For example, you can use a date master or date dimension
table to determine whether the current date is a normal business day. If the current date is a
valid business day, then access is allowed. If the current date is not a business day (for
example a weekend day or holiday), access is denied. This test can be accomplished by
performing a lookup using a subquery, such as the one that is shown in Example 3-1.
Furthermore, DB2 prevents an INSERT statement from inserting a row or an UPDATE statement
from modifying a row such that the current user cannot be permitted to access it. You cannot
create a situation in which the data you inserted or changed is no longer accessible to you.
For more information and considerations about data movement in an RCAC environment, see
Chapter 6, “Additional considerations” on page 85.
Note: DB2 does not provide any indication back to the user that the data set requested
was restricted or reduced by RCAC. This is by design, as it helps minimize any changes to
the applications accessing the data.
The following sections describe step-by-step what is needed to be done to implement RCAC
in this environment.
2. There is a way to discover which user profiles have authorization to implement RCAC. This
can be done by running the SQL statement that is shown in Example 3-3.
Example 3-3 Verifying what user profiles have authorization to implement RCAC
SELECT function_id,
user_name,
usage,
user_type
FROM qsys2.function_usage
WHERE function_id =’QIBM_DB_SECADM’
ORDER BY user_name;
3. The result of the SQL statement is shown in Figure 3-6. In this example, either MCAIN or
HBEDOYA can implement RCAC in the Human Resources database.
3.6.2 Creating group profiles for the users and their roles
Assuming that all the employees have a valid user profile, the next step is to create group
profiles to group the employees. Complete the following steps:
1. In this example, there are three group profiles:
– HR (Human Resource personnel)
– MGR (Managers)
– EMP (Employees)
These are created by creating user profiles with no password. Example 3-4 shows the
Create User Profile (CRTUSRPRF) CL commands that you use to create these group profiles.
Note: Neither of the consultants (MCAIN and HBEDOYA) belong to any group profile.
The result of this query is shown in Figure 3-7, which is the total number of employees of
the company.
2. Run a second SQL statement (shown in Example 3-6) that lists the employees. If you have
read access to the table, you see all the rows no matter who you are.
2. Look at the definition of the table and see the permissions, as shown in Figure 3-9.
QIBM_DEFAULT_EMPLOYEE_HR_SCHEMA is the default permission, as described in
3.1.2, “Enabling and activating RCAC” on page 16.
2. The other column to mask in this example is the TAX_ID information. In this example, the
rules to enforce include the following ones:
– Human Resources can see the unmasked TAX_ID of the employees.
– Employees can see only their own unmasked TAX_ID.
– Managers see a masked version of TAX_ID with the first five characters replaced with
the X character (for example, XXX-XX-1234).
– Any other person sees the entire TAX_ID as masked, for example, XXX-XX-XXXX.
To implement this column mask, run the SQL statement that is shown in Example 3-9.
ELSE 'XXX-XX-XXXX'
END
ENABLE ;
2. Look at the definition of the EMPLOYEE table, as shown in Figure 3-11. To do this, from
the main navigation pane of System i Navigator, click Schemas HR_SCHEMA
Tables, right-click the EMPLOYEES table, and click Definition.
2. The result of the query for a user that belongs to the HR group profile is shown in
Figure 3-13. This user can see all the 42 rows (employees).
3. The result of the same query for a user who is logged on as TQSPENSER (Manager) is
shown in Figure 3-14. TQSPENSER has five employees in his department and he can
also see his own row, which is why the count is 6.
5. The result of the same query that is run by the Consultant/DBE gives the result that is
shown in Figure 3-16. The consultants/DBE can manage and implement RCAC, but they
do not see any rows at all.
Does the result make sense? Yes, it does because RCAC is enabled.
6. Run queries against the EMPLOYEES table. The query that is used in this example runs
and tests with the four different user profiles and is the same query that was run in 3.6.3,
“Demonstrating data access without RCAC” on page 24. It is shown in Example 3-12.
8. Figure 3-18 shows the results of the same query for the Manager (TQSPENSER). Notice
the masking of the DATE_OF_BIRTH and TAX_ID columns.
9. Figure 3-19 shows the results of the same query for an employee (DSSMITH). The
employee can only see only his own data with no masking at all.
3. Use the view to query the data and see who is on leave. The SQL statement that is used is
shown in Example 3-14:
4. Start with the Human Resources person (VGLUCCHESS) and see what is the result of the
previous query. He sees the two employees that are on leave and no masking is done over
the DATE_OF_BIRTH and TAX_ID columns. The results of the query are shown in
Figure 3-22.
5. Figure 3-23 shows what the Manager (TQSPENSER) gets when he runs the same query
over the view. He sees only the employees that are on leave that are managed by him. In
this example, it is one employee. The columns are masked, which confirms that RCAC is
applied to the view as well.
RCAC will be used to restrict access to the rows in these three tables by using permissions,
and to restrict column values by using masks. The default position is that no user can access
the rows in the tables. From there, specific bank employees are allowed access only to the
rows for their job responsibilities. In addition, columns containing personal or sensitive data
are masked appropriately. Bank customers are allowed access to only their rows and column
values.
In this example, it is assumed that the Bank employees have access to the tables when
working on the premises only. Employee access to data is provided by programs and tools
using standard DB2 interfaces, such as embedded SQL, ODBC, JDBC, and CLI. The
database connection authentication for these interfaces uses the employee's personal and
unique IBM i user profile. Operating in their professional role, employees do not have access
to bank data through the Internet.
Bank customers have access to their accounts and transactions by using a new web
application. Each customer has unique credentials for logging in to the application. The
authentication of the customer is handled by the web server. After the customer is
authenticated, the web server establishes a connection to DB2 for data access. This
connection uses a common IBM i user profile that is known as WEBUSER. This user profile is
secured and is used only by the web application. No Bank employee has access to the
WEBUSER profile, and no customer has an IBM i user profile.
The customer’s identity is passed to DB2 by using a global variable. The global variable is
secured and can be accessed only by the WEBUSER. The web application sets the
CUSTOMER_LOGIN_ID variable to the customer's login value. This value is compared to the
customer's login value that is found in the CUSTOMER_LOGIN_ID column of the
CUSTOMERS table.
Applications that do not use the web interface do not have to be changed because the global
variable is NULL by default.
CUSTOMERS ACCOUNTS
Row Column Column
Permissions Maskingg Maskingg
CUSTOMER_DRIVERS_LICENSE_NUMBER
CUSTOMER_EMAIL
CUSTOMER_LOGIN_ID
SECURITY No Rows CUSTOMER_SECURITY_QUESTION
ACCOUNT_NUMBER
CUSTOMER_SECURITY_QUESTION_ANSWER
CUSTOMER_TAX_ID
CUSTOMER_DRIVERS_LICENSE_NUMBER
CUSTOMER_EMAIL
CUSTOMER_LOGIN_ID
DBE All Rows CUSTOMER_SECURITY_QUESTION
ACCOUNT NUMBER
ACCOUNT_NUMBER
CUSTOMER_SECURITY_QUESTION_ANSWER
CUSTOMER_TAX_ID
CUSTOMER_EMAIL
CUSTOMER_LOGIN_ID
TELLER All Rows CUSTOMER_SECURITY_QUESTION None
CUSTOMER_SECURITY_QUESTION_ANSWER
CUSTOMER_TAX_ID
CUSTOMER_DRIVERS_LICENSE_NUMBER
CUSTOMER_EMAIL
CUSTOMER LOGIN ID
CUSTOMER_LOGIN_ID
PUBLIC No Rows CUSTOMER_SECURITY_QUESTION
ACCOUNT_NUMBER
CUSTOMER_SECURITY_QUESTION_ANSWER
CUSTOMER_TAX_ID
For the demonstration and testing of RCAC in this example, the following users interact with
the database. Furthermore, the column masking rules are developed independently of the
row permissions. If a person does not have permission to access the row, the column mask
processing does not occur.
Hernando Bedoya is a DB2 for i database engineer with the user profile of HBEDOYA. He
is part of the DBE group.
Mike Cain is a DB2 for i database engineer with the user profile of MCAIN. He is part of
the DBE group.
Veronica G. Lucchess is a bank account administrator with the user profile of
VGLUCCHESS. She is part of the ADMIN group.
Tom Q. Spenser is a bank teller with the user profile of TQSPENSER. He is part of the
TELLER group.
The IT security officer has the user profile of SECURITY. She is not part of any group.
The online banking web application uses the user profile WEBUSER. This profile is part of
the CUSTOMER group. Any future customer-facing applications can also use this group if
needed.
Adam O. Olsen is a bank customer with a web application login ID of KLD72CQR8JG.
Note: Appendix A, “Database definitions for the RCAC banking example” on page 121
provides a script that you can use to create all the database definitions or DDLs to
re-create this RCAC example.
3. Click the Columns tab to see the columns of the CUSTOMERS table, as shown in
Figure 4-7.
5. Review the definition of the ACCOUNTS table. The definition of the ACCOUNTS table is
shown in Figure 4-9. RCAC has not been defined for this table yet.
7. Click the Key Constraints, Foreign Key Constraints, and Check Constraints tabs to
review the key, foreign, and check constraints on the ACCOUNTS table, as shown in
Figure 4-11. There is one Foreign Key Constraint and no Check Constraints on the
ACCOUNTS table.
9. Click the Columns tab to see the columns of the TRANSACTIONS table, as shown in
Figure 4-13.
10.Click the Key Constraints, Foreign Key Constraints, and Check Constraints tabs to
review the key, foreign, and check constraints on the TRANSACTIONS table, as shown in
Figure 4-14. There is one Foreign Key Constraint and one Check Constraint on the
TRANSACTIONS table.
3. Click Customize for the function usage ID of Database Security Administrator, as shown
in Figure 4-17.
5. The Application Administrator window opens again. The function usage ID of Database
Security Administrator now has an X in the Customized Access column, as shown in
Figure 4-19.
.
Figure 4-20 Query to display user profiles with function usage ID for RCAC
4.3.3 Creating group profiles for the users and their roles
The next step is to create the different group profiles (ADMIN, CUSTOMER, TELLER, and
DBE) and assign the different user profiles to the different group profiles. For a description of
the different groups and users for this example, see 4.2, “Description of the users roles and
responsibilities” on page 39.
3. After you create all the group profiles, you should see them listed in System i Navigator
under Users and Groups Groups, as shown in Figure 4-23.
2. The New Global Variable window opens, as shown in Figure 4-25. Enter the global
variable name of CUSTOMER_LOGIN_ID, select the data type of VARCHAR, and leave
the default value of NULL. This default value ensures that users that do not use the web
interface do not have permission to access the data. Click OK.
4. The Permissions window opens, as shown in Figure 4-27. Select Change authority for
Webuser so that the application can set this global variable.
Figure 4-27 Setting change permissions for Webuser on the CUSTOMER_LOGIN_ID global variable
Note: You must join back to ACCOUNTS and then to CUSTOMERS by using a
subquery to check whether the global variable matches CUSTOMER_LOGIN_ID.
Also, if the row permission or column mask rule text references another table with
RCAC defined, the RCAC for the referenced table is ignored.
3. Repeat steps 1 on page 58 and 2 to create column masks for the following columns:
– MASK_DRIVERS_LICENSE_ON_CUSTOMERS
– MASK_LOGIN_ID_ON_CUSTOMERS
– MASK_SECURITY_QUESTION_ANSWER_ON_CUSTOMERS
– MASK_ACCOUNT_NUMBER_ON_ACCOUNTS
– MASK_SECURITY_QUESTION_ON_CUSTOMERS
– MASK_TAX_ID_ON_CUSTOMERS
2. From the CUSTOMERS definition window, click the Check Constraints tab and click Add,
as shown in Figure 4-37.
5. Create all the other check constraints that are associated to each of the masks on the
CUSTOMERS table. After this is done, these constraints should look like the ones that are
shown in Figure 4-40.
2. Enable RCAC on the ACCOUNTS table. Right-click the ACCOUNTS table and select
Definition. As shown Figure 4-42, make sure that you select Row access control and
Column access control. Click OK.
3. A window opens, as shown in Figure 4-46. Take note of the nonsensical search condition
(0=1) of the QIBM_DEFAULT row permission. This permission is ORed with all of the
others and it ensures that if someone does not meet any of the criteria from the row
permission then this condition is tested, and because it is false the access is denied.
2. The number of rows that the DBE user MCAIN can see is shown in Figure 4-48.
Figure 4-48 Number of rows that DBE user can see in the CUSTOMERS table
Figure 4-49 SQL statement that is run by the DBE user with masked columns
Figure 4-51 Number of rows that the security officer can see in the CUSTOMERS table
3. The result of the third SQL statement is shown in Figure 4-52. Note the empty set that is
returned to the security officer.
Figure 4-52 SQL statement that is run by the SECURITY user - no results
Figure 4-54 Number of rows that the TELLER user can see in the CUSTOMERS table
3. The result of the third SQL statement is shown in Figure 4-55. Note the masked columns.
The TELLER user, TQSPENSER, can see all the rows, but there are some columns where
the result is masked.
Figure 4-55 SQL statement that is run by the TELLER user with masked columns
2. The number of rows that the ADMIN user can see is shown in Figure 4-57. The ADMIN
user can see all the rows.
Figure 4-57 Number of rows that the ADMIN can see in the CUSTOMERS table
Figure 4-58 SQL statement that is run by the ADMIN user - no masked columns
3. Verify that the global variable was set with the correct value by clicking the Global
Variable tab, as shown in Figure 4-61.
4. The number of rows that the WEBUSER can see is shown in Figure 4-62. This user can
see only the one row that belongs to his web-based user ID.
Figure 4-62 Number of rows that the WEBUSER can see in the CUSTOMERS table
Figure 4-64 List of accounts and current balance by customer using the WEBUSER user profile
Figure 4-65 Calculate transaction total by account for year and quarter using the WEBUSER profile
Figure 4-66 List of accounts and current balance by customer using a TELLER user profile
3. Compare the advised indexes that are provided by the Optimizer without RCAC and with
RCAC enabled. Figure 4-69 shows the index advice for the SQL statement without RCAC
enabled. The index being advised is for the ORDER BY clause.
This consistent enforcement across all interfaces is a good thing, but there are some nuances
and restrictions as a result of applying an SQL-based technology such as RCAC to non-SQL
interfaces. These considerations are described in this chapter.
After a row permission or column mask is added to a table, there are some data access
requests that no longer work. An attempt to open or query a table with activated RCAC
controls involving any of the following scenarios is rejected with the CPD43A4 error message:
A logical file with multiple formats if the open attempt requests more than one format.
A table or query that specifies an ICU 2.6.1 sort sequence.
A table with read triggers.
This unsupported interface error occurs when a table with RCAC controls is accessed, not
when the RCAC control is created and activated.
For example, assume that there is a physical file, PF1, which is referenced by a single format
logical file (LFS) and a multi-format logical file (LFM). A row permission is successfully
created and activated for PF1. Any application that accesses PF1 directly or LFS continues to
work without any issues. However, any application that opens LFM with multiple formats
receives an error on the open attempt after the row permission is activated for PF1.
Legacy queries that have been running without any issues for many years and over many
IBM i releases are now processed by a different query engine. As a result, the runtime
behavior and results that are returned can be different for native query requests with RCAC
enabled. The OPNQRYF command and Query/400 run with SQE by default.
The following list documents some of the query output differences that can occur when native
query requests are processed by CQE:
Different ordering in the result set
Different values for null columns or columns with errors
Suppression of some mapping error messages
Loss of RRN positioning capabilities
Duplicate key processing behavior differences
Missing key feedback
In addition, the performance of a native query with SQE can be different. It is possible that a
new index or keyed logical file might need to be created to improve the performance.
Important: Based on the potential impacts of query result set and performance
differences, you should perform extensive functional testing and performance
benchmarking of applications and reports that use native query interfaces.
For example, consider a table containing three columns of first name, last name, and tax ID
that is read by an RPG program. The user running the program is not authorized to see the
tax ID value, so a masked value (*****3333) is written into the program's record buffer, as
shown Figure 5-1.
In this example, the application reads the data for an update to correct the misspelling of the
last name. The last name value is changed to Smith in the buffer. Now, a WRITE request is
issued by the program, which uses the contents of the record buffer to update the row in the
underlying DB2 table. Unfortunately, the record buffer still contains a masked value for the tax
ID, so the tax ID value in the table is accidentally set to the masked value.
…
READ
Record Buffer-> Joe Smyth *****3333
…
/* Application logic corrects last name to Smith */
WRITE
Record
d Buffer->
ff Joe Smith
i h *****3333
*****
DB2 for i also enhanced its check constraint support in the IBM i 7.2 release with a new ON
UPDATE clause that allows the existing value to be preserved when a masked value is detected
by a check constraint. Details about how to employ this new check constraint support can be
found in 6.8.1, “Check constraint solution” on page 108.
If the invoker of the CRTDUPOBJ command asks for data to be copied with a value of *YES for
the DATA parameter, the value of the ACCCTL parameter must be *ALL. If not, the command
invocation receives an error.
When data is copied to the duplicated object with the DATA parameter, all rows and unmasked
column values are copied into the new object, even if the command invoker is not authorized
to view all rows or certain column values. This behavior occurs because the RCAC controls
also are copied to the new object. The copied RCAC controls enforce that only authorized
users are allowed to view row and column values in the newly duplicated object.
When RCAC controls are in place on the source table, the CPYF command is limited to reading
rows and column values that are based on the invoker of the CPYF command. If a user is
authorized to see all rows and column values, then all rows and unmasked column values are
copied to the target table (assuming no RCAC controls are on the target table). If a user
without full access runs the CPYF command, the CPYF command can copy only a subset of the
rows into the target table. In addition, if that user can view only masked column values, then
masked values are copied into the target table. This also applies to the Copy to Import File
(CPYTOIMPF) command.
If the target table has RCAC controls defined and activated, then the CPYF command is
allowed only to add or replace rows in the target table based on the RCAC controls. If CPYF
tries to add a row to the target table that the command invoker is not allowed to view
according to the target RCAC controls, then an error is received.
An example of this situation is shown in Figure 6-1. However, note that aggregate functions (a
form of grouping) are based on masked values.
SELECT CREDIT_CARD_NUMBER,
SUM(AMOUNT) AS TOTAL
FROM TRANSACTIONS
GROUP BY CREDIT_CARD_NUMBER
ORDER BY CREDIT_CARD_NUMBER;
Note: Column masks can influence an SQL INSERT or UPDATE. For example, you cannot
insert or update a table with column access control activated with masked data generated
from an expression within the same statement that is based on a column with a column
mask.
RCAC
Column mask
processing
SQE S
Selection
l ti P Processing
i
FieldProc
Decode and mask
r3vS#45zt!J9*m$p6 processing
The “user” that is running the data movement application or process, whether it be a high
availability (HA) scenario, an extract, transform, load (ETL) scenario, or just copying data from
one file or table to another one, must have permission to all the source rows without masking,
and not be restricted from putting rows into the target. Allowing the data movement
application or process to bypass the RCAC rules must be based on a clear and concise
understanding of the organization's object security and data access policy. Proper design,
implementation, and testing are critical success factors when applying RCAC.
Important: RCAC is applied to the table or physical file access. It is not applied to the
journal receiver access. Any and all database transactions are represented in the journal
regardless of RCAC row permissions and column masks. This makes it essential that
IBM i security is used to ensure that only authorized personnel have access to the
journaled data.
6.2.3 Effects when RCAC is defined on both source and target tables
Example 6-3 shows a simple example that illustrates the effect of RCAC as defined on both
the source and the target tables.
Given a “source” table and a “target” table with a row permission defined as NAME <> 'CAIN'
and a column mask that is defined to project the value 999.99 for AMOUNT, the SELECT
statement produces a result set that has the RCAC rules applied. This reduced and modified
result set is inserted into the “target” table even though the query is defined as returning all
rows and all columns. Instead of seven rows that are selected from the source, only three
rows are returned.
Note: Thinking of the row permission as defining a virtual set of rows that can be operated
on is the secret to understanding the effect of RCAC on any join operation.
Permitted
by
RCAC
Set A Set B
Figure 6-7 Set A and set B with row permissions
Result of Intersection
Set A Set B
Figure 6-8 Inner join without RCAC permission
Effect of column masks on inner joins: Because column masks are applied after the
query final results are determined, the masked value has no effect on the join processing
and corresponding query result set.
Permitted
Result of Intersection
Set A Set B
Figure 6-9 Inner join with RCAC permission
Set A Set B
Figure 6-10 Outer join without RCAC permission
Effect of column masks on inner joins: Because column masks are applied after the
query final results are determined, the masked value has no effect on the join processing
and corresponding query result set.
Permitted
Set A Set B
Figure 6-11 Outer join with RCAC permission
Set A Set B
Figure 6-12 Exception join without RCAC permission
Given that row permission serves to eliminate logically rows from one or more sets, more
rows can appear to be exceptions when RCAC is applied, as shown in Figure 6-13. Also,
because column masks are applied after the query final results are determined, the masked
value has no effect on the join processing and corresponding query result set.
Permitted
Set A Set B
Figure 6-13 Exception join with RCAC permission
The monitoring, analyzing, and debugging process basically stays the same when RCAC row
permissions or column masks are in place, with a few important differences:
The underlying data access plan can be different and more complex based on the rule
text.
The database results can be reduced or modified based on the rule text and user profile.
The run time of the request can be affected either positively or negatively based on the
rule text.
For high-level language record level access, query plans must be considered, and not just
program code.
During analyzing and debugging, it is important to account for all of the RCAC definitions for
each table or file to understand the logic and corresponding work that is associated with
processing the row permissions and column masks. It is also important to realize that,
depending on the user profile in effect at run time, the database actions and query results can
be different.
RCAC is designed and implemented to be transparent to the user. It is possible for user
“Mike” and user “Hernando” to run the exact same query, against the exact same data on the
exact same system, and get different result sets. There is no error, no warning, and no
indication that RCAC reduced or modified the respective answers that are returned.
Furthermore, it is also likely that user “Mike” and user “Hernando” have different query run
times even though it appears that everything is the same for both users. The actual query
plan contains the RCAC logic, and this additional code path can alter the amount of work that
is needed to produce results, based on the user running the query.
When monitoring, analyzing, and debugging a database process when RCAC is enabled, it is
critical to keep as many of the “variables” the same as possible. Use a good scientific
process. For example, when re-creating a problem situation running under the same user
profile with the same data and under the same conditions, it is almost mandatory. Otherwise,
the database behavior and query results can be different.
To successfully perform monitoring, analyzing, and debugging when RCAC is enabled likely
involves changes in the security and data access policies of the organization, and require new
responsibilities, authority, and oversight within the data-centric application development
community. As such, establishing and staffing the position of “database engineer” becomes
even more important.
Figure 6-15 shows the main dashboard of an SQL Performance Monitor. Click Summary.
Figure 6-16 shows the summary of an SQL Performance Monitor with an indication that
RCAC is applied.
When implementing RCAC as part of a comprehensive and pervasive data access control
initiative, consider that the database monitoring and analysis tools can collect literal values
that are passed as part of SQL statements. These literal values can be viewed as part of the
information collected. If any of the literals are based on or are used with masked columns, it is
important to review the database engineer's policy for viewing these data elements. For
example, supposed that column CUSTOMER_TAX_ID is deemed masked for the database
engineer and the CUSTOMER_TAX_ID column is used in a predicate as follows:
WHERE CUSTOMER_TAX_ID = '123-45-7890'
The literal value of '123-45-7890' is visible to the analyst, effectively exposing sensitive
information. If this is not acceptable, you must implement the
SYSPROC.SET_COLUMN_ATTRIBUTE procedure.
The SET_COLUMN_ATTRIBUTE procedure sets the SECURE attribute for a column so that
variable values that are used for the column cannot be seen in the SQL Performance Monitor,
SQL Plan Cache Snapshot, or Visual Explain.
The index advisor is not specifically enhanced for RCAC, but because the rule text is a fully
integrated part of the query plan, any opportunities for indexing is advised based on the
current Query Optimizer functionality. If an index is advised because of the RCAC rule text
logic, there is no RCAC reason code provided. Analyzing the query plan and the RCAC rule
text provides the understanding as to why the index is being advised.
SELECT *
FROM ACCOUNTS A
WHERE A.ACCOUNT_NUMBER = ?
AND A.CUSTOMER_ID IN (
SELECT C.CUSTOMER_ID
FROM CUSTOMERS C
WHERE C.CUSTOMER_LOGIN_ID = CUSTOMER_LOGIN_ID);
A.ACCOUNT_NUMBER
A ACCOUNT NUMBER does
d nott have
h an index
i d
C.CUSTOMER_LOGIN_ID, C.CCUSTOMER_ID does not have an index
Figure 6-18 Index advice and RCAC
In Figure 6-19, index advisor is showing an index for the ACCOUNTS and CUSTOMERS
tables based on the RCAC rule text.
For more information about creating and using indexes, see IBM DB2 for i indexing methods
and strategies, found at:
http://www.ibm.com/partnerworld/wps/servlet/ContentHandler/stg_ast_sys_wp_db2_i_in
dexing_methods_strategies
100 Row and Column Access Control Support in IBM DB2 for i
Figure 6-20 shows the QSYS2.SYSCONTROLS catalog view.
For more information, see the IBM i 7.2 DB2 for i SQL Reference Guide, found at:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/db2/rbafzintro.htm?lang
=en
6.5.1 Views
Any access to an SQL view that is over one or more tables that have RCAC also have those
row permissions and column masking rules applied. If an SQL view has predicates, those are
logically ANDed with any search condition that is specified in the permissions that are defined
on the underlying tables. The view does not have to project the columns that are referenced
by the permissions. Figure 6-21 shows an example of a view definition and user query.
SELECT *
FROM OPEN_ACCOUNTS_VIEW A
WHERE A.ACCOUNT_NUMBER = ?
102 Row and Column Access Control Support in IBM DB2 for i
What the query optimizer plans for and what the database engine runs is shown in the
Figure 6-22.
SELECT *
FROM OPEN_ACCOUNTS_VIEW A
WHERE A.ACCOUNT_NUMBER = ?
Because the MQT is a copy of the base table data, when a permission is created on the base
table, all the related MQTs are altered to have a default row permission. This default
permission prevents any of the rows from being directly queried.
When a query implicitly uses an MQT, the underlying row permissions and column masks are
built into the query that uses the MQT. In order for the MQT to be used for optimization, the
MQT must include any columns that are used by the row permissions and column masks.
104 Row and Column Access Control Support in IBM DB2 for i
This example has the following additional implications:
Users must be prevented from explicitly querying the MQT or a view that is created over it.
Those two cases bypass the row permission and column mask rules from the underlying
tables.
If the user writes code to update incrementally an MQT, that code must be run from a user
that has permission to view all of the rows and all columns in their unmasked state.
Otherwise, the MQT contents are not complete and queries that implicitly use the MQT
might get wrong results.
To prevent this, a check constraint can be created to cause an error if masked data was
inserted into the MQT.
For example, a query that references Table1 might be rewritten to access an MQT over
Table1, or it might also be optimized to access only the fields in an index that is defined over
Table1 and avoid touching Table1. With RCAC, defining these rewrites can still occur, but the
MQT or index also must include all columns that are needed by the row permissions or
column masks that are defined on Table1.
As part of adding RCAC, the impact to these potentially significant performance optimizations
must be considered. Usage of MQTs or index-only access might be reduced or eliminated by
enabling RCAC.
For native record level access, this RCAC “query” is also built and used to test the permission.
When a file is opened, the RCAC rule text logic is included, optimized, and run as part of the
native read, write, update, or delete operation. The amount of work (and time) required to
identify the record based on the user's permission is directly related to the complexity and
depth of the logic that is needed to identify the records that can be returned.
A simple example to illustrate this concept is a random read using a keyed logical file (that is,
an index). In its purest form, a random read uses two data access methods: index probe (find
the key and RRN) and table probe (find the record using RRN). If the RCAC rule text specifies
five nested subqueries to determine whether the user has access to the record, this logic
must be added to the path. The subquery processing now becomes part of the original
“random read” request. Instead of two simple I/Os to retrieve the record, there can be a
minimum of 12 I/Os to retrieve the same record. These I/Os can be done with a result of “not
found” if the user is not entitled to any of the records.
106 Row and Column Access Control Support in IBM DB2 for i
Before the record, as identified by the key, is considered available, the RCAC logic must be
run. If the record is rejected by RCAC, the next record in sequence that is permissible must be
identified. This spinning through the records can take a long time and uses many resources,
as shown in Figure 6-24.
spin
Row Permission:
thru
records
WHERE NAME <> CAIN
× 1000001 123CAINvvvvvv456
× 1000002 123CAINwwwwww456
× 1000003 123CAINxxxxxx456
1000004 123BEDOYAyyyy456
1000005 123BEDOYAzzzz456
After the row permissions and column masks are designed and implemented, adequate
performance and scalability testing are recommended.
For example, assume TABLE1 and TABLE2 have active column access control and for insert,
selecting data from TABLE2 returns the masked data. The following INSERT returns an error:
INSERT INTO TABLE1 SELECT * FROM TABLE2
The masked data that is returned from the SELECT * FROM TABLE2 might not be valid input
data for TABLE1 because of data type or column check constraint.
There are two ways to prevent this situation from happening: Define a check constraint or
create a before trigger.
As part of RCAC, new SQL syntax is provided to allow an action to be performed when a
violation of the check constraints check condition occurs instead of giving that error. However,
if the check condition is still not met after the action, a hard error is returned. A check
constraint with the new on-violation-clause is allowed on both the CREATE TABLE and ALTER
TABLE statements.
In the Example 6-4, the mask is defined to return a value of 'XXX-XX-nnnn' for any query that
is not done by a user profile in the DBMGR group. The constraint checks that the column SSN
does not have the masked value.
108 Row and Column Access Control Support in IBM DB2 for i
ELSE 'XXX-XX-'||SUBSTR(COL2_ssn,8,4)
END
ENABLE
|
/* Check constraint for the update and insert.*/
ALTER TABLE MY_LIB.EMP_INFO
ADD CONSTRAINT MASK_ssn_preserve
CHECK(SUBSTR(COL2_ssn,1,7)<>'XXX-XX-') -- Allow any value other than the mask
ON UPDATE VIOLATION PRESERVE COL2_ssn -- Don't update the mask portion of the existing value
ON INSERT VIOLATION SET COL2_ssn = DEFAULT -- for insert set this to the default value.
6.9.1 Triggers
Triggers have access to the data in rows outside of the row permission or column masking.
An after trigger has access to the new row image after the permission has allowed the update
or insert to occur. Therefore, the triggers can potentially change the insert or update image
value so that it violates the permission.
6.9.2 Functions
Within a CREATE PERMISSION or CREATE MASK, a function can be called. Because that UDF has
access to the data before the RCAC rules are applied, the SECURE attribute is required on
that function, as shown in Example 6-7.
The SECURED attribute of MY_UDF signifies that the function is considered secure for
RCAC. If a function is called from an SQL statement, and references a column in a table that
has RCAC, it must be declared as secure. In that case, if the secure function calls other
functions, they are not validated to confirm whether they are secure.
110 Row and Column Access Control Support in IBM DB2 for i
Table2 column SSN has a column mask that is defined on it.
SELECT MY_UDF4(SSN) from table2. Because SSN has a column mask that is defined,
MY_UDF4 must be created with the SECURED attribute.
Figure 6-25 illustrates that object level security is the first check and that RCAC permissions
provide control only on tables and physical files.
Table
Journal Receiver
To get access to the table and the rows, the user must pass the object level authority test and
the RCAC permission test.
The IBM i journal captures the transactional data and places an image of the row in the
journal receiver. If the user has access to the journal receiver, the row image can be viewed if
the user has authority to the journal receiver.
Although the SQL Plan Cache data, the SQL Plan Cache Snapshot data, and the SQL
Performance Monitor data do not reveal the results of queries, they can show the literal values
that are passed along with the SQL statements.
112 Row and Column Access Control Support in IBM DB2 for i
7
If you are using SQL DDL to define your DB2 tables, then you have the option of adding the
RCAC definitions to the same source file as the table definition. The benefit of this approach
is that it keeps all DDL that is related to a table in a single source file. The downside is that if
you must re-create only the RCAC definitions and leave the table unchanged, then you must
identify and extract only the RCAC definitions from the source file. There are situations where
the row permissions and column masks must be changed or re-created without changing the
definition of the associated table.
This capability makes it easy to change your RCAC definitions as you test the controls with
your applications and identify tweaks that must be made to your RCAC implementation.
However, re-creation of RCAC definitions does require an exclusive lock to be acquired on the
table during the process.
Important: Although these capabilities make it easy to temporarily turn off RCAC security
so that you can make environment or application changes, these processes require an
exclusive lock to be obtained on a table. Therefore, this activity must be planned carefully
to avoid disruptions and outages.
7.1.4 Regenerating
DB2 also can regenerate an existing row permission or column mask. This regenerate option
can be useful with more complex RCAC definitions that reference other DB2 objects.
114 Row and Column Access Control Support in IBM DB2 for i
For example, consider a row permission on an ACCOUNTS table
(PERMISSION1_ON_ACCOUNTS). The ACCOUNTS table row permission references and
compares columns in the CUSTOMERS table. When the definition of the CUSTOMERS table
changes, DB2 does not check to determine whether the change to the CUSTOMERS table
breaks the ACCOUNTS table row permission. If this table definition change does break the
row permission, an error does not surface until an application tries to read rows from the
ACCOUNTS table.
Instead of waiting for an application to detect this error, the REGENERATE option can be used on
the ACCOUNTS row permission. The REGENERATE option returns an error if the change in the
CUSTOMERS table definition causes the row permission to be invalid. In this way, the row
permission can be proactively corrected before an application discovers the error.
Save and restore processing works fine with RCAC if the RCAC definition does not reference
other DB2 objects other than the table over which they are defined. When the RCAC definition
has dependencies on other DB2 objects, the restore process is much more challenging.
Move
Copy
Duplicate
Restore
BANK SCHEMA
BANK_SCHEMA BANK TEST
BANK_TEST
ACCOUNTS ACCOUNTS
Permission Permission
CUSTOMERS CUSTOMERS
The only way to fix this issue is to re-create the row permission or column mask after the
restore operation. Re-creation of the row permission or column mask is required only for
definitions that reference other DB2 objects, but it is simpler to re-create all of the RCAC
definitions instead of a subset. For example, generate the SQL using System i Navigator,
clear the “Schema qualify names for objects” and select the “OR REPLACE clause”, and then
run the generated script.
The migration of a table with RCAC has the same challenges as restore processing. If the
RCAC definition references other DB2 objects, then IBM i CL commands do not change the
schema names that are explicitly qualified by the DB2 internal RCAC processing.
Again, re-creating the row permission or column mask is the only way to fix the issue of
references to DB2 objects in other schemas.
116 Row and Column Access Control Support in IBM DB2 for i
7.3 Monitoring and auditing function usage
While establishing proper roles for users, separating duties using function usage IDs, and
defining RCAC policies allows you to implement an effective and pervasive data access
control scheme. How do you monitor and audit everyone who is involved in the
implementation of that scheme? The answer is to use IBM i journaling. A special journal that
is called QAUDJRN, also known as the audit journal, can provide a record and audit trail of
many security relevant events that occur on the system, including RCAC-related events.
The tasks and operations of security administrators and database engineers who are
collaborating can (and should) be effectively monitored and audited to ensure that the
organization's data access control and governance policies are in place and enabled. For
example, the Database Engineers can be involved in designing and developing functions and
triggers that must be secured using the SECURE attribute. Otherwise, without properly
securing functions and triggers, the RCAC controls can be bypassed.
A new journal entry type of “AX” for journal entry code “T” (audit trail) is now used for RCAC.
More information about the journaling of RCAC operations can be found in the following
documents:
IBM i Version 7.2 Journal Management Guide, found at:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzaki/rzakiprintthis
.htm?lang=en
IBM i Version 7.2 Security Reference Guide, found at:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzarl/rzarlkickoff.h
tm?lang=en
This situation also can include separation of duties, such as allowing the application
developers to design and implement the solutions, but restricting them from accessing the
production data based on policy. Just because someone writes and owns the program, it does
not mean that they have access to all the sensitive data that their program can potentially
read.
This paper has described the following pervasive power and advantages of RCAC:
Access can be controlled through simple or sophisticated logic.
Virtually no application changes are required.
The implementation of the access policy is part of the DB2 data access layer.
Table data is protected regardless of the interface that is used.
No user is inherently exempted from the access control policies.
Groups of users can share policies and permissions.
A deep understanding of the technology, and proper planning, good design, adequate testing,
and monitored deployment are critical for success. This includes the usage of quality
assurance testing, and realistic performance and scalability exercises that serve to
demonstrate that all of your requirements are being met. As part of the verification process,
the usage of in-depth proofs of concepts and proofs of technology are recommended, if not
essential. When RCAC is activated, the results of queries can change. Anticipating this
change and realizing the effects of RCAC before going live are of the utmost importance.
With the ever-growing value of data, and the vast and varied database technology that is
available today, it is crucial to have a person or persons on staff who specialize in data-centric
design, development, and deployment. This role and responsibility falls on the database
engineer. With the availability of DB2 RCAC, the importance of full-time database engineering
has grown.
If you are interested in engaging with the DB2 for i Center of Excellence, contact Mike Cain at
[email protected].
120 Row and Column Access Control Support in IBM DB2 for i
A
/* Global Variable */
CREATE VARIABLE BANK_SCHEMA.CUSTOMER_LOGIN_ID
VARCHAR( 30) ;
/* Tables */
122 Row and Column Access Control Support in IBM DB2 for i
ALTER TABLE BANK_SCHEMA.ACCOUNTS
ADD CONSTRAINT BANK_SCHEMA.ACCOUNT_CUSTOMER_ID_FK
FOREIGN KEY( CUSTOMER_ID )
REFERENCES BANK_SCHEMA.CUSTOMERS ( CUSTO00001 )
ON DELETE RESTRICT
ON UPDATE RESTRICT ;
124 Row and Column Access Control Support in IBM DB2 for i
CREATE PERMISSION BANK_SCHEMA.PERMISSION1_ON_ACCOUNTS ON BANK_SCHEMA.ACCOUNTS AS A
FOR ROWS WHERE ( QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'DBE' , 'ADMIN' , 'TELLER' ) = 1 )
OR
( QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'CUSTOMER' ) = 1
AND ( A . CUSTOMER_ID IN (
SELECT C . CUSTOMER_ID
FROM BANK_SCHEMA . CUSTOMERS C
WHERE C . CUSTOMER_LOGIN_ID = BANK_SCHEMA . CUSTOMER_LOGIN_ID
/* END */
The publications that are listed in this section are considered suitable for a more detailed
description of the topics that are covered in this paper.
Other publications
These publications are relevant as further information sources:
IBM DB2 for i indexing methods and strategies white paper:
http://www.ibm.com/partnerworld/wps/servlet/ContentHandler/stg_ast_sys_wp_db2_i
_indexing_methods_strategies
IBM i Memo to Users Version 7.2:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzahg/rzahgmtu.htm
IBM i Version 7.2 DB2 for i SQL Reference Guide:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/db2/rbafzintro.htm?l
ang=en
IBM i Version 7.2 Journal Management Guide:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzaki/rzakiprintthis
.htm?lang=en
IBM i Version 7.2 Security Reference Guide:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzarl/rzarlkickoff.h
tm?lang=en
Online resources
These websites are relevant as further information sources:
Database programming topic of the IBM i 7.2 IBM Knowledge Center:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzahg/rzahgdbp.htm?l
ang=en
Identity Theft Resource Center
http://www.idtheftcenter.org
Ponemon Institute
http://www.ponemon.org/
128 Row and Column Access Control Support in IBM DB2 for i
Back cover ®
Implement roles and This IBM Redpaper publication provides information about the IBM i 7.2
feature of IBM DB2 for i Row and Column Access Control (RCAC). It INTERNATIONAL
separation of duties
offers a broad description of the function and advantages of controlling TECHNICAL
access to data in a comprehensive and transparent way. This SUPPORT
Leverage row publication helps you understand the capabilities of RCAC and provides ORGANIZATION
permissions on the examples of defining, creating, and implementing the row permissions
database and column masks in a relational database environment.
This paper is intended for database engineers, data-centric application
Protect columns by developers, and security officers who want to design and implement
defining column RCAC as a part of their data control and governance policy. A solid BUILDING TECHNICAL
masks background in IBM i object level security, DB2 for i relational database INFORMATION BASED ON
concepts, and SQL is assumed. PRACTICAL EXPERIENCE
IBM Redbooks are developed
by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
REDP-5110-00