Lets start with the standard disclaimer. Please go to the next slide

Transcription

1 DB2 10 for z/os Security Enhancements James Click Pickel to edit Master text styles IBM Silicon Valley Laboratory DB2 for z/os Second Security level Architect Session: A05 Time: 9 November :00 am am Platform: DB2 10 z/os Thanks, My names is Jim Pickel and I am the security architect for DB2 at the Silicon Valley Lab. Today, I am going to introduce you to some of the new security features in DB2 10. Many of these features provide a data centric security solution allowing you to protect your data at the source. Thus, protecting all access and in many cases without impacting your production applications. Lets start with the standard disclaimer. Please go to the next slide

2 Satisfy Your Auditor: Plan, Protect and Audit Unauthorized Data Access Minimize the use of a superuser authorities such as SYSADM A different group should manage access to restricted data than the owner of the data Data Auditing Any dynamic access or use of a privileged authority needs to be included in your audit trail Maintain historical versions of data for years or during a business period Data Privacy All dynamic access to tables containing restricted data needs to be protected Database Administrator Tasks Temporal Data Security Administrator Tasks SQL based Auditing Row & Column Access Controls Today s Mainframe: The power of industry-leading security, the simplicity of centralised management 2 DB2 10 provides new ways to protect your companies #1 asset and satisfy your auditor with minimum impact to your applications Businesses have been protecting data from external users for many years, but because of new regulations you are now required to protect data from internal or privileged users such as users with the SYSADM or SYSCTRL authority. DB2 10 provides new configurable system authorities to protect unauthorised access from even privileged administrators. Administrators can now do their job without exposure to data. Also, regulations require security administration to be separate from data administration. In the past, the only way to get the separation of duties was using RACF access control. In 10, DB2 access control can now provides similar capability. New auditing capability has been added through the use of audit polices. You can now dynamically start auditing on any table or tables in a schema without any DDL changes or rebinding of applications. Also, you can now define an audit policy that would generate an audit trail of any users using one of the system authorities such as who is using SYSADM or SYSCTRL authority. New audit policies audit records are now written on every access to a table not just first access in a transaction. With new regulatory laws requiring historical data to be maintained over years, the problem is becoming more acute requiring significant investment by DB2 customers in changing existing or creating new database applications to manage different versions of data. DB2 now provides a capability to specify table-level specifications to control the management of data based upon time called temporal tables DB2 provides a new data privacy mechanism, called "row and column access control", which provides privacy and security policies to be defined on a table. This allows all users to access the same table (as opposed to alternative views of a table), but restricts access to the table based upon individual user permissions and masks as specified by a policy associated with the table. Lets now go into some details on each of these features. Next slide

3 Reduce your data risk by minimizing the use of SYSADM New granular system authorities and install security parameters Prior to DB2 10 SYSADM DBADM DBCTRL DBMAINT SYSCTRL PACKADM SYSOPR DATAACCESS SQLADM EXPLAIN New in DB2 10 System DBADM ACCESSCTRL SECADM Prevents SYSADM and SYSCTRL from granting or revoking privileges New separate security install zparm parameter New install SECADM authority manages subsystem security SYSADM and SYSCTRL can no longer implicitly grant or revoke privileges Control cascading effect of revokes New revoke dependent privileges install parameter New revoke dependent privileges SQL clause 3 DB2 10 introduces 6 new system authorities to reduce the dependency of SYSADM and to control the implicit privileges needed by DBA. By separating SYSADM into more granular authorities prevents a single user from having full control in DB2 so accidental or deliberate data exposure is more difficult to occur. First a new installation installation security administrator called SECADM has been added which manages the overall DB2 security controls. In order to reduce the dependency of SYSADM. SYSADM privileges are divided into three new administrative authorities: The DB2 system administrator called system DBADM which has implicit DDL privileges across all databases. A new DATAACCESS authority which has implicit access to all data. The new ACCESSCTRL authority which has implicit grant and revoke privileges. Two additional authorities are provided to allow an administrator, analyst or programmer to have access to the appropriate DB2 commands and functions needed to check SQL and monitor SQL performance without the ability to execute programs, access data or perform DDL. These new authorities were developed in conjunction with the DB2 LUW security team. These new authorities have the same syntax, semantics and behaviour allowing across both products so you can set up a common security model across your platforms. Once you have moved to the new authorities, you can then prevent SYSADM and SYSCTRL authorities from performing grants and revokes by setting the new separate security installation parameter. Once set, the new SECADM authority is now the principal authority used to manage the security controls within DB2. Currently, if you revoke a privilege from a user, it causes the privilege to be revoked from other users dependent on the grant called cascading revoke. This behaviour is not desirable in many customer shops and makes it difficult to migrate to the new authorities, especially when revoking SYSADM. A new dependent privileges clause is added to the REVOKE statements. The dependent privileges clause can have a value of INCLUDING DEPENDENT PRIVILEGES or NOT INCLUDING DEPENDENT PRIVILEGES. NOT INCLUDING DEPENDENT PRIVILEGES indicates that revocation of a privilege or an authority from an ID or a role will not revoke the grants made by that user. INCLUDING DEPENDENT PRIVILEGES indicates the current behaviour. Revoking a privilege or an authority from an ID also results in revoking the grants made by that user or cascade the revoke. The default value is based on the authority being revoked and the new REVOKE_DEP_PRIVILEGES system parameter which can be used to prevent any revoke from cascading. The next chart will discuss the other two new authorities, the new SQLADM authority and EXPLAIN privilege. Next slide

4 New authority for monitoring and tuning SQL without ability to change or access data SQLADM authority Allows the user to Issue SQL EXPLAIN statements Issue START, STOP, and DISPLAY PROFILE commands Perform actions Second level involving: EXPLAIN Third privilege level STATS privilege Fifth on level all user databases MONITOR2 privilege Execute DB2-supplied stored procedures and routines Cannot access data, perform DDL or execute 4 New authority for monitoring and tuning SQL without the ability to change or access data. The new SQLADM authority allows the user to issue EXPLAIN SQL statements, PROFILE commands, execute RUNSTATS and MODIFY STATISTICS utilities on all user databases, and perform actions involving: the new EXPLAIN privilege the existing MONITOR2 privilege The SQLADM authority allows the user to execute system defined routines (stored procedures or functions) and any package executed within the routines. Only an user or a role with SECADM or ACCESSCTRL authority can grant the SQLADM authority. It cannot access data, perform DDL or execute user programs

5 New privilege to validate SQL before moving application into production without risk to data EXPLAIN privilege Programmer can issue SQL EXPLAIN ALL statement without having the privileges to execute that SQL statement. Programmer can issue SQL PREPARE and DESCRIBE TABLE Click statements to edit Master without text requiring styles any privileges on the object. Programmer Third can level specify new BIND EXPLAIN(ONLY) and SQLERROR(CHECK) options Programmer can explain dynamic SQL statements executing under new special register, CURRENT EXPLAIN MODE = EXPLAIN 5 New privilege to validate SQL before moving into production without exposing user data. The new EXPLAIN privilege to allow a user to check and explain SQL statements without the ability to execute the statements EXPLAIN privilege allows the user to issue the SQL EXPLAIN PLAN ALL statement without requiring privileges to execute that SQL statement. Also, it allows the user to issue SQL PREPARE and DESCRIBE TABLE statements without requiring privilege on the object. It allows the user to specify BIND options, EXPLAIN(ONLY) and SQLERROR(CHECK). It allows explain information to be captured for dynamic SQL statements that have the special register CURRENT EXPLAIN MODE set to EXPLAIN, without executing the statements. Only an user or a role with SECADM or ACCESSCTRL authority can grant the EXPLAIN privilege.

6 Satisfy Your Auditor: New audit policies provide needed flexibility and functionality New auditing capability allow you to comply without expensive external data collectors New audit policies managed in catalog Audit privileged users Audit SQL activity against a table Audit distributed identities 6 New audit policies provide needed flexibility and functionality To better monitor your security plan and compliance, improved auditing is being provided to better protect against and discover unknown or unacceptable behaviors. To assist in this task, DB2 provides a new audit capability based on audit policies and categories. This allows you the ability to configure and control different auditing policies that can be used to monitor both application and individual user access. An audit policy is a set of criteria that determines what categories are to be audited. Different audit policies can be defined based on the security needs of the business. An audit policy is created by inserting a row in the catalog table. The audit policy is then enabled by issuing the START TRACE command with the audit policy name. The audit policy can be disabled by issuing the STOP TRACE command with the audit policy name. You manage auditing policies in the DB2 catalog, to audit privileged users, to audit SQL activity against a table, and to audit non z/os users accessing DB2 through the distributed data facility. The next slide will go into more details on what is being provided

7 New Audit Policies Feature Your security administrator using the new SECADM authority maintains DB2 audit policies in a new catalog table SYSIBM.SYSAUDITPOLICIES Auditor can audit access to specific tables for specific programs during day 1)Audit policy does not require AUDIT clause to be specified using DDL to enable auditing 2)Audit policy generate records for all read and update access not just first access 3)Audit policy includes additional Third level records identifying the specific SQL statements 4)Audit policy provides wildcarding of based on schema and table names Auditor can identify any unusual use of a privileged authority Records each use of a system authority Audit records written only when authority is used for access External collectors only report users with a system authority 7 New audit policy feature. An audit policy is a set of criteria that determines what categories are to be audited. Different audit policies can be defined based on the security needs of your business. An audit policy is created by a user with the new SECADM authority inserting a row in the SYSIBM.SYSAUDITPOLICIES catalog table. The categories supported are: CHECKING which generates audit records when access attempts are denied due to inadequate DB2 authorization and for RACF authentication failures. VALIDATE which generates audit records when there is an assignment or change of authorization id OBJMAINT which generates audit records when altering or dropping tables. EXECUTE which generates new audit records of for every SQL statements executed against a table or tables in a schema. Tables to be audited are specified when the audit policy is defined. This is an improvement over previous releases when an audit record is written only once per transaction. CONTEXT which generates audit records for the start of a utility, utility phase change and the end of utility. SECMAINT generates new trace records when granting or revoking privileges or administrative authorities. SYSADMIN generates audit records when system administrative authority satisfies the privilege required to perform an operation. DBADMIN generates audit records when an database administrative authority, satisfies the privilege required to perform an an operation.

8 Satisfy Your Auditor: New features to improve distributed security by providing more effective controls and more accurate audit trail Support distributed identities introduced in z/os V1R11 A distributed identity is a mapping between a RACF user ID and one or more distributed user identities, as they are known to application servers Support client certificates and password phrases introduced in z/os V1R10 AT-TLS secure handshake accomplishes identification and authentication when the client presents its certificate as identification and its proof-of- possession as authentication A RACF password phrase is a character string made up of mixed-case letters, numbers, special characters, and is between 9 to 100 characters long Support connection level security enforcement Enforces all connections must use strong authentication to access DB2 All userids and passwords encrypted using AES, or connections accepted on a port which ensures AT-TLS policy protection or protected by an IPSec encrypted tunnel 8 Additional security features improves the content of DB2's audit data. Auditing just the primary auth ID in many cases is not good enough to meet your auditor demands DB2 10 adds the following new z security features providing additional synergy with DB2 and RACF. This includes supporting distributed identities introduced in z/os V1R11. Distributed identity filters are defined in RACF to create an association between a RACF user ID and one or more distributed user identities, as they are known to the application servers and defined in distributed LDAP registries. This strengthens DB2 auditing capability by allowing distributed identities to be part of the DB2 audit log. Support for RACF client digital certificates introduced in z/os V1R10 which uses the SSL secure handshake to accomplish a user's identification and authentication to DB2. A DB2 client driver can not present its certificate as identification and its proof-of-possession as authentication. Support for password phrases introduced in z/os V1R10. A password phrase is a character string made up of mixed-case letters, numbers, and special characters, including blanks, and is between 9 to 100 characters long. It can be used instead of the traditional 8-character password. Lets go and look at the new SQL access controls feature. Next

9 Satisfy Your Auditor: New table controls to protect against unplanned and dynamic SQL access Define additional data controls at the table level Security policies are defined using SQL providing flexibility Separate security logic from application logic Security policies based on real time session attributes Protects against SQL injection attacks Determines Click how to edit column Master values text styles are returned Determines Second which level rows are returned No need to remember various view or application names No need to manage many views; no view update or audit issues All access including adhoc query tools, report generation tools is protected Policies can be added, modified, or removed to meet current company rules without change to applications 9 Today DB2 administrators using the SYSADM authority can access all user data. While their responsibilities are to manage and maintain objects in a database, in many cases there is no business reason for them to see the data. When users access data, they are subject only to the privilege checks granted on the table. But the privileges are not fine grained enough to protect data subjects' personal and sensitive information within the table. The major consequence is the business cannot easily comply with data protection laws. In many cases, privacy and security policies are either implemented directly by applications or implemented via views, When enforcing policies using applications, the data is protected only when it is accessed via those applications. This hampers the ability to use ad-hoc query tools and report generation tools. If views are used to implement policies, alternative views need to be created and managed for each group or individual users having different privileges. Because the complexity of privacy and security policies it is often too great to express all permissions in a single view. DB2 provides a new mechanism, called "row and column access control", which designates the new SECADM authority the ability to manage privacy and security policies for a table,. He can restrict access to the table based upon individual user permissions and masks as specified by a policy associated with the table. All users including the administrators are subject to these new access control. Row and column access control takes the security logic out of the application logic, places the access control as close to the data as possible, and ensures the data is protected, regardless of the tool used to access it. The evolution of security policies becomes very easy as row and column access control is data-centric and places the security logic in the database, thus, all applications and tools that access the database automatically are subject to the controls. The next chart will so an example on how to set up table access controls

10 Table controls to protect SQL access to individual rows Establish a row policy for a table Filter rows out of answer set Policy can use session information like the SQL ID is in what group or user is using what role to control when row is returned in result set Applicable Click to to SELECT, edit INSERT, Master UPDATE, title style DELETE, & MERGE Defined as a row permission: CREATE PERMISSION policy-name ON table-name FOR ROWS WHERE search-condition ENFORCED FOR ALL ACCESS ENABLE;» Optimizer inserts search condition in all SQL statements accessing table. If row satisfies search-condition, row is returned in answer set 10 When a new row access control is enforced for a table, the rows of data are skipped unless one or more row access control permissions exist that allow access by a user, group, or role. To implement row access control, DB2 introduces a new type of object called a row permission. When column access control is enforced for a table, the masked values for columns referenced in the outermost select list are returned. This slide gives you an example of the DDL used to create a row permission. A row permission expresses a row access control rule for a specific table. It contains the rule in the form of an SQL search condition that describes under what conditions who can access the rows of data. The new CREATE PERMISSION statement allows a user to create a row permission object. Multiple row permissions can be created for a table. The definition of a row permission can reference the user, role, or group in the search condition. When multiple permissions for row access control are defined for a table, a row access control search condition is derived by application of the logical OR operator to the search condition in each enabled row permission. This row access control search condition is applied when the table is accessed. An application does not need to be aware of the row access control rules and consequently there is no need to change an application after row access control is in effect for a table. Lets go to the next slide on column access control

11 Table controls to protect SQL access to columns Establish a column policy for a table Mask column values in answer set Policy can use session information to mask value like the SQL ID is in what group or user is using what role Applicable to the output of outermost subselect Defined Click as column to edit Master masks : text styles CREATE MASK mask-name ON table-name FOR Fourth COLUMN level column-name RETURN CASE-expression ENABLE; Optimizer inserts case statement in all SQL accessing table to determine mask value to return in answer set 11 To implement column access control, a new type of object is defined a column mask. A column mask is a database object that expresses a column access control rule for a specific column. It contains the rule in the form of an SQL CASE expression that describes under what conditions who can receive the masked values returned for a column. The new CREATE MASK statement allows a user to create a column mask object. Multiple column masks can be created for a table. One column can have one column mask only. The definition of a column mask can reference a user, a role, or a group in the CASE expression. The CASE expression can then mask the stored column value before returning it to the application. The CASE expression can conditionally determine how the value should be returned depending on run time session conditions. Again an application does not need to be aware of the column access control rules and consequently there is no need to change an application after the column access control is in effect for a table. Next slide will show you how to determine how to determine who to apply the control.

12 Define column or row policies based on who or what program is accessing a table SESSION_USER - Primary authorization ID of the process CURRENT SQLID - SQL authorization ID of the process SET CURRENT SQLID = string-constant; VERIFY_GROUP_FOR_USER function Get authorization IDs for the value in SESSION_USER Includes both Fourth primary level and secondary authorization IDs Return 1 if any of those authorization IDs is in the argument list WHERE VERIFY_GROUP_FOR_USER (SESSION_USER, MGR, PAYROLL ) = 1 VERIFY_ROLE_FOR_USER function Get the role for the value in SESSION_USER Return 1 if the role is in the argument list WHERE VERIFY_ROLE_FOR_USER (SESSION_USER, MGR, PAYROLL ) = 1 New built in session variables All controls to test based on program name or program attributes For example, where program originated in the network 12 Define a policy based on who is accessing the table. The following new scalar built-in functions are added to help you define your table access control policies: SESSION USER used to return the primary ID associated with the process. CURRENT SQLID used to return the SQL ID associated with the process. VERIFY_GROUP_FOR_USER returns a true if one Id associated with the process is the specified ID. VERIFY ROLE_FOR_NEW_USER returns a true if the process is associated with the specified role. Once you define the table profiles now you need to activate them.

13 Managing Row and Column Access Controls When activated row and column access controls: Make row permissions and column masks become effective in all DML All row permissions are connected with OR to filter out rows All column masks are applied to mask output All access to the table is prevented if no user-defined row permissions ALTER TABLE Fourth level table-name ACTIVATE ROW Fifth level LEVEL ACCESS CONTROL ACTIVATE COLUMN LEVEL ACCESS CONTROL; When deactivated row and column access controls: Make row permissions and column masks become ineffective in DML Opens all access to the table ALTER TABLE table-name DEACTIVATE ROW LEVEL ACCESS CONTROL DEACTIVATE COLUMN LEVEL ACCESS CONTROL; 13 Once the permissions or masks are created for a table, they must be activated for them to take affect. This slides provides an example of the syntax necessary to activate and then deactivate access controls The ACTIVATE ROW LEVEL ACCESS CONTROL clause imposes a default row permission with predicate of the form 1 = 0 to all references to data in the table. With the use of this single clause, all access to the data in the table is restricted. No rows will be returned for any read access regardless of the SQL statement or the authority of the statement authorization ID. To allow specific users to access the data, define one or more row permission objects to specify search conditions to determine what rows can be accessed by a user. A row-level access control permission can only be defined, modified, or dropped by users having SECADM authority. When row or column-level access control is enforced for a table, and a row permission or a column mask is used to specify under what conditions a user, group, or role can access rows of the table, or a column values of the table. No user has an implicit exemption from these rules. This is true even for system authorities such as SYSADM In fact, the ability to manage access control is vested solely with the SECADM authority. Thus, you can rely upon row and column access controls to ensure that administrators are no longer able to freely access all data in DB2. Now lets go through a simple example on how to set access controls on a table. Next slide.

14 Example A simple banking scenario Only allow customer service representatives to see customer data but always with masked income Table: CUSTOMER Account Alice Name Third Bob level Phone Louis Income 22,000 71, ,000 Branch A B B David ,000 C 14 To help you understand how to use permissions and masks, let me go through a very simple banking example. I have a table in which I want only the banks service representatives who need to see all customer data but only with masked incomes. No one else can see any of the rows. Here are they column names and values for the tables used in the example. A customer table with the customer's account, name, phone, income, and branch. Lets go to the next slide.

15 Setting up row permission on customer table Set up access control policies for service representatives Allow access to all customers of the bank (a row permission) CREATE PERMISSION CSR_ROW_ACCESS ON CUSTOMER FOR ROWS Click WHERE to edit Master title style VERIFY_GROUP_FOR_USER (SESSION_USER, CSR ) = 1 ENFORCED FOR ALL ACCESS; Mask all INCOME values (a column mask) Return value 0 for incomes of and below Return value 1 for incomes between and Return value 2 for incomes between and Return value 3 for incomes above Customer service reps are in the CSR group (who) 15 Lets say I want to set up a permission that prevents everyone from retrieving the rows except for service representatives. Then I want to mask the different incomes to three different values 0, 1, 2, 3, Next in this example, all customer service representatives are in the CSR group. This is the DDL used to create the permission allowing only users in the CSR group access to the rows. Now lets go to the next chart to show the DDL used to create the income mask.

16 Setting up column mask on customer table Define a column mask on INCOME column for customer service representative on customer table CREATE MASK INCOME_COLUMN_MASK ON CUSTOMER FOR COLUMN Click INCOME to edit RETURN Master title style CASE WHEN (VERIFY_GROUP_FOR_USER (SESSION_USER, CSR ) = 1) END ENABLE; THEN CASE WHEN (INCOME > ) THEN 3 WHEN (INCOME > 75000) THEN 2 WHEN (INCOME > 25000) THEN 1 ELSE 0 END ELSE NULL 16 This slides show the create mask for the customer column. In this example, when income > 150,000 then mask income to the value 3 when income > 75,000 then mask income to the value 2 when income > 25,000 then mask income to the value 1 otherwise set the income to the value 0 Lets go to the next slide to activate the permission and mask and see what DB2 does when activated.

17 Start enforcing controls on customer table Activate Row-level and Column-level Access Control ALTER TABLE CUSTOMER ACTIVATE ROW LEVEL ACCESS CONTROL ACTIVATE COLUMN LEVEL ACCESS CONTROL; COMMIT; What happens in DB2? A default row permission Fourth level is created implicitly to prevent all access to table CUSTOMER Fifth (WHERE level 1=0) except for users in the CSR group All packages and cached statements that reference table CUSTOMER are invalidated 17 Here is the ALTER statement to activate the access controls for the customer table. When this statement is issued a default row is created preventing all users except for users in the CSR group to retrieve the rows. Unless the user is in the CSR group no rows will be returned. Now all packages and cached statements that reference customer are invalidated. You will need to rebind the packages or DB2 will auto bind the packages to pick up the new access controls Lets go to the next chart to see when someone queries the customer table.

18 Selecting from customer table SELECT ACCOUNT, NAME, INCOME, PHONE FROM CUSTOMER; ACCOUNT NAME INCOME PHONE Alice Click to edit Bob Master title style Click to edit David Master text styles Louis INCOME automatically masked by DB2! When CSR Peter enters a query, he sees all the customers in the table but the INCOME column has been masked to show the values as determined by the mask. Anyone not in the CSR group entering the same query even with select privilege on the table will get a SQLCODE of +100 indicating no rows in the table. Now lets go to the next slide to show how DB2 optimizer applied the permission and mask to the query.

19 DB2 effectively evaluates the following revised query: SELECT ACCOUNT, NAME, CASE WHEN (VERIFY_GROUP_FOR_USER (SESSION_USER, CSR ) = 1) THEN CASE WHEN (INCOME > ) THEN 3 WHEN (INCOME > 75000) THEN 2 WHEN (INCOME > 25000) THEN 1 ELSE 0 END Click ELSE NULL to edit Master text styles END INCOME, PHONE FROM CUSTOMER WHERE VERIFY_GROUP_FOR_USER (SESSION_USER, CSR ) = 1 OR 1 = 0 ; 19 The original statement is modified and references to the income column is replaced with the case statement to perform the where clause is added to filter the rows. Now lets look at DB2 new temporal table feature. Next slide

20 Satisfy Your Auditor: DB2 can now manage different versions of your data Application programmers and database administrators have struggled for years with managing different versions of your application data New regulatory laws require maintaining historical versions of data for years Every update and delete of data requires copying old data to history tables Existing approaches to application level data versioning complicate table design, add complexity and are error prone for applications New system temporal table Fifth level feature allows DB2 to automatically maintain change data history for a new concept of versioning which archives old rows into a history table 20 For years, application programmers and database administrators have been facing the problem of managing different versions of application data. With new regulatory and compliance laws requiring historical data to be maintained over years, the problem is becoming more acute requiring significant investment by DB2 customers to change existing or creating new applications to just to manage different versions of data. Existing approaches to application level versioning not only explodes the table design but also adds complexity and error prone code to the application. The lack of data versioning in DB2 prevents the protection and management of core business sensitive assets by DB2. DB2 10 provides the capability to specify table-level specifications to control the management of application data based upon time. Application programmers would be able to specify queries that specify a search criteria based upon time the data existed. This function would simplify and reduce the cost of developing DB2 applications requiring data versioning and allow customers to meet new compliance laws faster and cheaper because DB2 will automatically manage the different versions of data autonomically. The expectation is that select, insert and update of current data would perform similar for tables not performing data versioning, but select of old data may be slower.

21 New system temporal table allows DB2 to automatically maintain changed data Data versioning is implemented by altering an existing or creating a table with two timestamps, a history table, and defining the versioning relationship between tables Base table must have: SYSTEM_TIME is defined two TIMESTAMP(12) NOT NULL columns First column (col1) defines the row begin time Second column (col2) defines the row end time Third column defined as TIMESTAMP(12) for the transaction that created row New period definition: PERIOD SYSTEM_TIME(col1, col2) History table must have: Same number of columns as the system period temporal table All columns must have the same corresponding names, data type, null attribute, ccsid, subtype, hidden attribute and fieldproc as the system period temporal table 21 Defining system versioning on a table. This slchart explains how to activate system versioning on a new or existing table. To create a temporal table with versioning enabled, you need to have the objects properly set-up. Basically, another table must be created to be the history table. The system-maintained base table must have: a column defined as a TIMESTAMP for the start column of a SYSTEM_TIME period. a column defined as TIMESTAMP(6) for the end column of a SYSTEM_TIME period. a SYSTEM_TIME period, specified on the two above timestamp columns in which the first column is a start column and the second column is an end column. Using the period definition. Then you need to create the history table with the same columns as the base table. Once you have the base and history table created lets go to the next slide to show how to tie the two tables together to enable data versioning

22 Start system versioning for a table After the base and history tables are appropriately defined: ALTER TABLE table-name ADD VERSIONING is specified on the base table Click that is to to be edit versioned, Master not the title history style table New FROM SYSTEM_TIME clauses: table-name FOR SYSTEM_TIME AS OF timestamp-expression table-name FOR SYSTEM_TIME FROM timestamp-expression1 TO timestampexpression2 Note: the second Fourth timestamp-expression level is not inclusive table-name FOR SYSTEM_TIME BETWEEN timestamp-expression1 AND timestamp-expression2 Note: the second timestamp-expression is inclusive 22 After the two objects are set-up properly, an ALTER TABLE ADD VERSIONING can be issued in order to establish the versioning relationship. The ALTER TABLE ADD VERSIONING is specified on the base table that is to be versioned and not the history table. The history table is identified in the ALTER TABLE ADD VERSIONING statement through the HISTORY TABLE clause. To query historical data, the table-reference of the FROM clause is extended to specify that historical data is requested. Whenever historical data is requested from a system-maintained temporal table, DB2 will rewrite the user query to include data from the history table with a UNION ALL operator. These are the three system time clauses that can be specified to include history data in the query. The AS OF, the FROM clause and the BETWEEN clause. The second timestamp is not inclusive on the FROM clause and inclusive on the BETWEEN clause.

23 UPDATE a row in a SYSTEM_TIME table At timestamp ' :12: ', UPDATE policy_info SET coverage = WHERE policy_id = 'A123'; Policy_info Policy ID A Second level Hist_policy_info Policy Coverage Sys_start ID A123 Coverage Sys_start Sys_end Sys_end 23 Update system time example. From the point of view of the pair of tables: temporal and history, no destructive data modifications are allowed for SYSTEM_TIME period support. When data is being logically modified by either an UPDATE or DELETE, the current image of the row is copied to the history table before the modification is made in the temporal table. The SYS_END value is modified in the history table row to the DB2 current timestamp when the data modification statement executed. Now lets use one of the new clauses to get the row as of a certain time. Next slide

24 Query a row in a SYSTEM_TIME table SELECT policy_id, coverage FROM policy_info FOR SYSTEM_TIME AS OF ' :00: '; Query returns the row of ('A123', 12000) Sys_end Click to Coverage edit Master Sys_start text styles Hist_policy_info Policy ID Coverage Sys_start A123 Policy_info Policy ID A Sys_end Select system time example Since SYSTEM_TIME automatically enforces no period overlaps and no period holes for a particular unique business key, an query with the FOR SYSTEM_TIME AS OF clause will return at most 1 row for a unique time. Now lets look at business time temporal table. Next slide

25 Session A05 - DB2 10 for z/os Security Enhancements - Satisfy Your Auditors using new features New granular authorities to reduce risk to data New auditing features using new audit policies New row Click and to column edit Master access table title style controls New temporal data support to comply with regulations to maintain historical data James Pickel, IBM pickel@us.ibm.com Session: A05 Platform: DB2 10 z/os 25 DB2 10 provides new granular authorities to satisfy your auditor by reducing the need of sysadm by providing new more granular authorities to allow administrators to do their job without the risk of exposing data DB2 10 improves auditing capability in order to satisfy your auditor by being able to generate more compliant audit records to meet todays compliance and data security laws DB2 10 provides new access controls to allow you to establish policies on the table to protect all access to table DB2 10 provides temporal tables to satisfy your auditor requirements to maintain change and updated history on a table Thank you