Understanding DB2 9 Security

This page intentionally left blank Understanding DB2® 9 Security IBM Press DB2® BOOKS DB2® Universal Database V8 fo...

Author: Rebecca Bond | Kevin Yeung-Kuen See | Carmen Ka Man Wong | Yuk-Kuen Henry Chan

59 downloads 1651 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

This page intentionally left blank

Understanding DB2® 9 Security

IBM Press DB2® BOOKS DB2® Universal Database V8 for Linux, UNIX, and Windows Database Administration Certification Guide, Fifth Edition Baklarz and Wong Understanding DB2 9 Security Bond, See, Wong, and Chan Understanding DB2® Chong, Liu, Qi, and Snow High Availability Guide for DB2® Eaton and Cialini DB2® Universal Database V8 Handbook for Windows, UNIX, and Linux Gunning DB2® SQL PL, Second Edition Janmohamed, Liu, Bradstock, Chong, Gao, McArthur, and Yip DB2® for z/OS® Version 8 DBA Certification Guide Lawson DB2® Universal Database V8.1 Certification Exam 700 Study Guide Sanders DB2® Universal Database V8.1 Certification Exams 701 and 706 Study Guide Sanders DB2® Universal Database for OS/390 Sloan and Hernandez The Official Introduction to DB2® for z/OS®, Second Edition Sloan Advanced DBA Certification Guide and Reference for DB2® Universal Database v8 for Linux, UNIX, and Windows Snow and Phan DB2® Express Yip, Cheung, Gartner, Liu, and O’Connell Apache Derby—Off to the Races Zikopoulos, Baklarz, and Scott DB2® Version 8 Zikopoulos, Baklarz, deRoos, and Melnyk

ON DEMAND COMPUTING BOOKS Business Intelligence for the Enterprise Biere On Demand Computing Fellenstein Grid Computing Joseph and Fellenstein Autonomic Computing Murch

RATIONAL® SOFTWARE BOOKS Software Configuration Management Strategies and IBM Rational® ClearCase ®, Second Edition Bellagio and Milligan Implementing IBM® Rational® ClearQuest® Buckley, Pulsipher, and Scott

Project Management with the IBM Rational Unified Process Gibbs IBM Rational ® ClearCase ®, Ant, and CruiseControl Lee Visual Modeling with Rational Software Architect and UML Quatrani and Palistrant

WEBSPHERE® BOOKS IBM ® WebSphere ® Barcia, Hines, Alcott, and Botzum IBM ® WebSphere ® Application Server for Distributed Platforms and z/OS ® Black, Everett, Draeger, Miller, Iyer, McGuinnes, Patel, Herescu, Gissel, Betancourt, Casile, Tang, and Beaubien Enterprise Java™ Programming with IBM ® WebSphere ®, Second Edition Brown, Craig, Hester, Pitt, Stinehour, Weitzel, Amsden, Jakab, and Berg IBM ® WebSphere ® and Lotus Lamb, Laskey, and Indurkhya IBM ® WebSphere ® System Administration Williamson, Chan, Cundiff, Lauzon, and Mitchell Enterprise Messaging Using JMS and IBM ® WebSphere ® Yusuf

MORE BOOKS

FROM

IBM PRESS

Irresistible! Markets, Models, and Meta-Value in Consumer Electronics Bailey and Wenzek Service-Oriented Architecture Compass Bieberstein, Bose, Fiammante, Jones, and Shah Lotus® Notes® Developer’s Toolbox Elliott Developing Quality Technical Information, Second Edition Hargis, Carey, Hernandez, Hughes, Longo, Rouiller, and Wilde Performance Tuning for Linux® Servers Johnson, Huizenga, and Pulavarty RFID Sourcebook Lahiri Building Applications with the Linux Standard Base Linux Standard Base Team An Introduction to IMS™ Meltz, Long, Harrington, Hain, and Nicholls Search Engine Marketing, Inc. Moran and Hunt Can Two Rights Make a Wrong? Insights from IBM’s Tangible Culture Approach Moulton Reger Inescapable Data Stakutis and Webster

Understanding DB2® 9 Security

DB2® Information Management Software

Rebecca Bond Kevin Yeung-Kuen See Carmen Ka Man Wong Yuk-Kuen Henry Chan IBM Press Pearson plc Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Cape Town • Sydney • Tokyo • Singapore • Mexico City ibmpressbooks.com

The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. © Copyright 2007 by International Business Machines Corporation. All rights reserved. Note to U.S. Government Users: Documentation related to restricted right. Use, duplication, or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation. IBM Press Program Managers: Tara Woodman, Ellice Uffer Cover design: IBM Corporation Published by Pearson plc Publishing as IBM Press IBM Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales 1-800-382-3419 [email protected] For sales outside the United States, please contact: International Sales [email protected] The following terms are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both: DB2, CICS, IMS, Lotus, Tivoli, WebSphere, Rational, IBM, the IBM logo, and IBM Press. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Microsoft .NET, .NET, Windows, Windows NT, and the Windows logo are trademarks of the Microsoft Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds. Intel, Intel Inside (logo), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. OSF/1 and UNIX are registered trademarks and The Open Group is a trademark of the The Open Group in the United States and other countries. UML is a registered trademark of the Object Management Group (OMG). Other company, product, or service names mentioned herein may be trademarks or service marks of their respective owners. Any persons, businesses, government entities, academic institutions, locales or events used in this book are fictional and for the purpose of illustrating concepts related to the subject matter of this book. Any resemblance to actual persons (living or dead), businesses, government entities, academic institutions, locales or events is entirely coincidental.

Library of Congress Cataloging-in-Publication Data

Understanding DB2 9 security : DB2, information management software / Rebecca Bond [et al.]. p. cm. ISBN 0-13-134590-7 (hardback : alk. paper) 1. IBM Database 2. 2. Database security. 3. Database management. I. Bond, Rebecca, 1950QA76.9.D314U64 2006 005.8—dc22 2006027905

All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc. Rights and Contracts Department 75 Arlington Street, Suite 300 Boston, MA 02116 Fax: (617) 848-7047 ISBN 0-13-134590-7 Text printed in the United States on recycled paper at RR Donnelly in Crawfordsville, Indiana. First printing, December 2006


To my loving and supportive husband of 38 years (the “real” James Bond) who has served as my foundation for so long, I’m surprised his head isn’t engraved “stepping stone; place Rebecca’s foot here.” To Keesa, James, and LaPamela who continue to bring such joy and fulfillment to our lives. You guys rock! To our five grandchildren (Ore, Pure, Porcelain, Witness, River), the next book is for you. Rebecca Bond

Contents Foreward Preface Acknowledgments About the Authors Chapter 1

The Regulatory Environment

5

Chapter

2

DB2 Security–The Starting Point

21

Chapter

3

Understanding Identification and Authentication– The First Line of Defense

41 93

Chapter

4

Securing DB2 on Windows

Chapter

5

Authorization–Authority and Privileges

117

Chapter

6

Label Based Access Control

165

Chapter

7

Encryption (Cryptography) in DB2

237

Chapter

8

Ready, Set, Implement?

255

Chapter

9

Database Auditing and Intrusion Detection

269

Chapter 10

SSH for Data-Partitioning on UNIX Platforms

303

Chapter 11

Database Security—Keeping it Current

309

Chapter 12

Final Thoughts: Security—The Human Factor

319

xi

Contents

Appendix A

Independent Security Packages

327

Appendix B

Kerberos

329

Appendix C

DB2 Audit Scope Record Layouts

337

Appendix D

DB2 Audit—Additional Documentation

349

Appendix E

Security Considerations for DB2

363

Appendix F

Glossary of Authorization ID

375

Appendix G

LBAC-Related SYSCAT views

379

Appendix H

Security Plug-In Return Codes

383

Appendix I

Detailed Implementation for the Case Study in Chapter 3

389

Index

395

xi

Table of Contents

Introduction A Personal Experience Provides Lessons Learned

Chapter 1


New Regulations, New Responsibilities, New Opportunities Sarbanes-Oxley Section 302 and 404 Responsibilities What Internal Controls? Changing DBA Responsibilities DB2 DBAs and the SOX Mitigation Effort The Participating DBA HIPAA Gramm-Leach-Bliley Federal Information Security Management Act

Chapter 2

DB2 Security—The Starting Point

First Words—What’s the Plan? The DB2 Security Plan Security Plan Meeting Participants Meeting Goals and Desired Outcomes Next Steps DB2 Database Security—Create the Policy Using the Plan to Formulate the Policy Review, Approve, Implement, Maintain General Guidelines—Building the DB2 Database Security Policies Change Control—Things Are Gonna Change Last Words

Chapter 3

Understanding Identification and Authentication— The First Line of Defense

First Words: Why Is Authentication Critical to Database Security? Overview of the Default DB2 Authentication Mechanism Authentication Type What Authentication Type Should I Use? Understanding Authentication—In General SRVCON_AUTH Database Manager Configuration Parameter

1 2

5 5 6 7 7 8 9 13 13 17 18

21 21 22 23 26 34 35 35 35 36 39 40

41 41 42 43 44 44 46

Table of Contents

Authentication Type Negotiation Between the Client and Server Specifying Authentication Type on the DB2 Connect Gateway How to Determine the Authentication Type Used for a Connection Introduction to Security Plug-Ins Why Did DB2 Implement the Security Plug-In Architecture? Type and Categories of Security Plug-Ins IBM-Shipped Default Plug-In Client-Side Auth Plug-Ins on the Database Server Authorization ID Versus User ID Roles of the Different Categories of Security Plug-Ins DB2 Security Plug-In APIs GSS APIs Security Plug-In-Specific Database Manager Configuration Parameters (DBM CFG Parameters) Enabling Security Plug-Ins When Is the Security Plug-In Loaded by DB2? Other Features Available in Customized Security Plug-Ins The Basic Flow of GSS API and DB2 Security Plug-In API Restrictions Imposed on GSS API Plug-Ins by DB2 Kerberos—An IBM-Shipped GSS API-Based Security Plug-In Authorization ID Mapping Consideration Customized Kerberos-Based Security Plug-In IBM-Shipped Kerberos Plug-In (IBMkrb5) More Information about Kerberos The Lightweight Directory Access Protocol (LDAP)—Yet Another IBM-Shipped User ID/Password-Based Security Plug-In IBM-Shipped LDAP Authentication and Group Membership Plug-In Authoring and Implementing Customized Security Plug-Ins Step 1: Include the Security Plug-In Header Files in Your Plug-In Step 2: Write the APIs Constituting Your Plug-In Step 3: Populate the Functions Pointer Structure Before Returning to DB2 Step 4: Compile the Plug-In Source and Create a Shared Library Step 5: Place the Library in the Appropriate Directory Case Study: Using a Customized Security Plug-In to Implement the Ability to Centralize User ID and Password and Group Membership Information in a Database Requirement Proposed Design Detailed Implementation Information Sample Scenarios Scenario 1: Mixed Use of Pre-8.2 and 9 Clients with the GSS API Plug-In Scenario 2: DB2 9 Client Communicating with a Database in a Different Instance with a Different Authentication Setting Scenario 3: Using Kerberos for Authenticating DB2 (Linux/UNIX/Windows) Client in an Environment That Also Has a DB2 for z/OS Client Security Plug-in Deployment Limitations Last Words

xiii

47 52 52 53 54 54 56 57 58 58 58 60 62 63 66 67 67 68 70 72 72 73 73 73 76 76 76 77 78 78 79 80 80 80 83 87 88 89 91 92 92

xiv

Table of Contents

Chapter 4


First Words Scope of This Chapter First Steps: Build in DB2 Security during Installation Heroes Welcomed Here Documentation Is Necessary Thinking “Security”—Planning the Windows Install Designed Especially for Windows Windows Domain\User Installation User ID DB2_EXTSECURITY The Windows Operating System—The Important Stuff Review Windows Account Policy Settings Lock Down and Protect Windows Accounts Lock Down Unneeded Features for the Windows Registry Windows Active Directory The Local System Account (LSA) Other Considerations Physical Security for Windows Servers Fixpacks, Service Packs, Patches—Use ’em or Lose The Dilemma Last Words

Chapter 5

Authorization—Authority and Privileges

First Words Terminology Object Owner Authorization ID Static SQL Object Best Practices Need-to-Know Least Privilege Separation of Duties Processes to Control and Review Avoid Granting to Groups Due Diligence Documentation Made Easy (or at Least Easier) Using Schemas for Control and Management of Database Objects Avoid Granting to PUBLIC Restricting the PUBLIC from the Start Without the Protection of “Restrictive” Easy Public Revokes Authorities Instance-Level Authority Database-Level Authority How Can Current Authorities Be Determined? Direct Authority Versus Indirect Authority

93 93 94 95 95 95 96 105 105 105 105 106 107 108 110 112 112 113 113 114 114 115

117 117 117 118 118 119 119 119 120 121 121 122 122 122 123 125 125 126 127 129 129 134 137 138

Table of Contents

xv

Privileges SQL Objects and Their Privileges Implicit Granted Authorities and Privileges Authorization Checking for DB2 Commands and Utilities Authorization Checking for SQL Statements Statement Authorization ID Different Authorization Models Available in DB2 Retrieving the Group Membership List for a Given Authorization ID More Ways to Encapsulate When Will Those Grants and Revokes Take Effect? Object Ownership Management SYSIBMADM.OBJECTOWNERS Last Words

Chapter 6

Label Based Access Control

What Is LBAC? A High-Level Overview The LBAC Architecture Security Label Components LBAC Security Policies Security Labels Row Security Labels Column Security Labels User Security Labels Exemptions Protected Table How LBAC Is Enforced Read Access Rules Write Access Rules Array Security Label Component Set Security Label Component Tree Security Label Component Exemptions The Security Plan for Protecting Data Security Plan Meeting Participants Designing the Security Solution Activity Overview for Implementing an LBAC Solution Manipulating Data in Protected Tables Insert Data Records into Protected Tables Retrieve Data Records from a Protected Table Update Data Records in a Protected Table Delete Data Records from a Protected Table Manipulating Data with Security Label with SET Security Label Component Inserting with a Security Label of SET Security Label Component Example Retrieve Data Records Protected by SET Security LabelComponent Elements Updating Data Records Protected by SET Security Label Component Deleting Data Records Protected by SET Security Label Component

138 138 144 147 147 147 148 149 155 156 158 159 163

165 165 166 167 168 168 169 169 169 169 170 171 171 172 173 174 175 175 177 177 177 178 179 180 180 181 182 182 182 185 185 188 190

xvi

Table of Contents

Manipulating Data with Security Label with ARRAY Security Label Component Inserting with a Security Label Of ARRAY Component Retrieve Data with a Security Label of ARRAY Security Label Component Update Data with a Security Label Of ARRAY Security Label Component Delete Data with a Security Label of ARRAY Security Label Component Manipulating Data with Security Label with TREE Security Label Component Insert Data with a Security Label Of TREE Security Label Component Scenario Retrieve Data with a Security Label of TREE Security Label Component Update Data with a Security Label of TREE Security Label Component Delete Data with a Security Label of TREE Security Label Component Use Case Scenario Analyzing Data Restrictions Designing the Security Solution Implementing the Security Solution Runtime Usage Managing Security Objects Review the Definition of Security Objects Review Security Labels Review Security Policies Review Security Label Components Dropping Security Labels Dropping Security Policy Dropping Security Label Component Managing User Access to Protected Data Granting Security Labels to Users Granting Exemptions to Users Revoking Security Labels from Users Revoking Exemptions from Users Managing Protected Tables Review List of Protected Tables Altering Table Protection: Adding Column Protection Altering Table Protection: Adding Row Protection Altering Table Protection: Drop Column Protection Altering Table Protection: Alter the Security Policy of a Protected Table Remove Protection from Protected Tables Dropping Protected Tables LBAC Support in Miscellaneous Utilities Views Query Through Views INSERT through Views Materialized Query Table (MQT) Staging Table Typed Table Import Export

191 191 194 196 197 199 199 199 204 205 206 207 209 210 211 214 217 217 217 218 218 218 219 220 221 221 222 222 222 223 224 224 224 225 226 226 227 227 227 227 231 232 232 232 232 232

Table of Contents

xvii

Load Copy Table in Control Center Stored Procedure: ADMIN_COPY_SCHEMA Database Backup Alter Table Referential Integrity Constraints Explain db2look Last Words Reference Material

Chapter 7

Encryption (Cryptography) in DB2

First Words The Cryptographic Keys Private Key Cryptography Public Key Cryptography What Type of Encryption Does DB2 Use? Encryption for User IDs and Passwords Passed in the Connect Statement Encryption for Sensitive Data Sent Through the Network Encrypting Sensitive Data Stored on Disk Last Words

Chapter 8

Ready, Set, Implement?

First Words: Just Start…but Where ? Apply Knowledge Reuse An Implementation Beginning Point Keeping It Real—No One Size Fits All Things Not Considered (That Likely Should Have Been) Password Authentication and Maintenance How Sensitive Are You? Implementing Foundational Security Where Design Meets Implementation Watch Out for the Public (What Does the Public Need to Know and When Do They Need to Know It?) Choosing the SHOW SQL option Security Considerations for Upgrades, Migrations, Scalability Security and Database Performance Last Words

Chapter 9

Database Auditing and Intrusion Detection

First Words Crisis Mode Initial Steps to DB2 Database Auditing Corporate Sponsor Discovery For DBAs Only From Analysis to Physical Design db2audit and Intrusion Attempts Before db2audit—Think—Test—Learn

232 233 233 234 234 234 236 236 236 236

237 237 238 238 239 239 239 241 243 254

255 255 256 256 256 257 257 258 259 259 260 266 267 267 268

269 269 270 271 271 271 273 276 277 277

xviii

Table of Contents

db2audit Facility—What Can It Do? Using db2audit for Multipartition Environments db2audit Facility Safeguards The db2audit Facility Command Syntax Triggers DB2 Recovery Expert for Multiplatform Stored Procedures, UDFs, and Other Programmatic Approaches to Auditing Monitoring, Reporting, and Analyzing Last Words

Chapter 10


First Words Secure Shell (SSH) for Data-Partitioning Feature on UNIX The Setup Steps Public Key Authentication (per User Account) Host-Based Authentication (per Machine) How to Configure DB2 to Use SSH Last Words

Chapter 11

Database Security—Keeping It Current

First Words Diligence DB2 User Community Resources Security Information on the Web Fixpacks Keeping Current Goes beyond DB2 Mixed Database Environments Vulnerability Assessments Intrusion Detection Prepare for a Breach Preparing for the Future Last Words

Chapter 12


First Words Education and Awareness For Geeks Only For the “Normal” Folks Social Engineering Step on a Crack—Break Security’s Back Publish and/or Perish? Last Words

Appendix A Appendix B

Independent Security Packages Kerberos

Configuring the NAS Kit on UNIX®/Linux® Systems for the IBMKrb5 Plug-In Configuring the Windows® Client and Domain Controller to Enable the Windows Native Kerberos Environment

278 278 278 279 299 301 301 302 302

303 303 303 304 305 306 307 308

309 309 309 310 312 312 313 314 314 315 316 317 318

319 319 320 320 321 322 323 323 325

327 329 329 332

Table of Contents

xix

Interoperability Useful Links

Appendix C Appendix D Appendix E

DB2 Audit Scope Record Layouts DB2 Audit – Additional Documentation

337 349


363

Security Considerations (Sourced from Administration Guide: Implementation) Gaining Access to Data Through Indirect Means Default Privileges Granted upon Creating a Database UNIX Platform Security Considerations for Users (Sourced from Administration Guide: Implementation) Windows Platform Security Considerations for Users (Sourced from Administration Guide: Implementation) Security Considerations in an LDAP Environment (Sourced from Administration Guide: Implementation) Security Considerations for Active Directory (Sourced from Administration Guide: Implementation) Security Considerations for Routines (Sourced from SQL Guide) Security Risks Security Considerations for DB2 Administration Server (DAS) on Windows (Sourced from Administration Guide: Implementation) Security Considerations for User Mapping Plug-In for a Federated Environment (Sourced from Websphere Information Integration Documentation)

Appendix F Appendix G Appendix H Appendix I

333 334

363 363 365 367 367 368 368 369 370 372 373

Glossary of Authorization ID LBAC-Related SYSCAT Views

375 379

Security Plug-In Return Codes Detailed Implementation for the Case Study in Chapter 3

383

Group Plug-In db2secGroupPluginInit db2secPluginTerm (Internal Name: Log_terminate_plugin) db2secGetGroupsForUser (Internal Name: Log_get_groups) db2secDoesGroupExist (Internal Name: Log_is_group) db2secFreeGroupListMemory (Internal Name: Log_free_group_list) db2secFreeErrormsg (Internal Name: Log_free_error_message) Server Authentication Plug-In db2secServerAuthPluginInit db2secServerAuthPluginTerm (Internal Name: Log_terminate_plugin) db2secValidatePassword (Internal Name: Log_validatePassword) db2secGetAuthIDs (Internal Name: Log_getauthids) db2secDoesAuthIDExist (Internal Name: Log_is_user) db2secFreeToken (Internal Name: Log_free_token) db2secFreeErrormsg (Internal Name: Log_free_error_message)

Index

389 389 389 390 390 391 391 391 391 391 392 392 393 393 393 393

395

Preface Today’s headlines have an unfortunate, recurrent theme…security breaches are becoming common place. Thousands of credit card numbers have been stolen and identity theft is on the rise throughout the world. As a result, legislative bodies are proposing ever more stringent laws and forcing corporations to fund security protections for their citizens’ data. Corporations also recognize that their continued viability depends on ensuring that the customer’s trust is not disrupted by a data breach. Fortunately for all of us, enterprises are becoming increasingly concerned about keeping their (our) data (data that is stored in databases such as DB2) safe. This book is in response to a need for ever-increasing knowledge about database security— knowledge that is not just about “technology” or “management,” but the “whole” of database security.

AUDIENCE Understanding DB2 9 Security is written for DB2 DBAs and their managers. For DBAs, this book provides a wealth of security information specific to both the “new” and the “tried and true” technology delivered in the DB2 9 product. DBAs will appreciate the numerous real-world implementation scenarios and step-by-step examples. Since, in today’s world, database security is not just about the technology, the managerial and “human” aspects of security are covered in their logical progression throughout the chapters. Through the material and examples provided, Understanding DB2 9 Security also provides a strong lesson foundation for students tasked with learning how to securely implement a DB2 database on Linux, Windows, or UNIX platforms. For all readers, the authors encourage you to develop an appreciation for the “whole” of database security.

ORGANIZATION The material in this book is organized in a logical progression from the standpoint of implementing a secure DB2 database environment. It begins by exploring the regulatory environment, continues with the technological and managerial knowledge that is so critical to the success of the effort, transitions to a discussion of post-implementation auditing, and then covers “go forward” considerations. Additional documentation details are provided where appropriate via appendixes.

Preface

xxi

Chapter 1:The Regulatory Environment Before beginning any task, it is wise to know the rules and reasons that drive the results. This Chapter provides an overview of some of the regulatory “drivers” regarding database security.

Chapter 2: DB2 Security—The Starting Point Where do you begin “building security”? Chapter 2 discusses the security “building blocks” that form the foundation for a secure implementation. The processes and team member participation necessary to create security plans and database security policies (essential to creating and maintaining a robust security implementation) are explained in depth.

Chapter 3: Understanding Identification and Authentication— The First Line of Defense Authentication, the process of identifying the user to the database, is a strong security mechanism. This chapter provides a deep dive into the topic.

Chapter 4: Securing DB2 on Windows As compared to their Linux and UNIX counterparts, Windows implementations of DB2 provide unique security opportunities and risks. The extra benefits and extra steps for a secure DB2 Windows environment are covered here.

Chapter 5:Authorization—Authority and Privileges Authorization (authorities and privileges) determine whether a user has the right to access or own a database object. As such it is a strong data protection defense. This complex topic is covered in Chapter 5.

Chapter 6: Label Based Access Control New in DB2 9, Label Based Access Control (LBAC) is an access protection mechanism that provides for a finer granularity of control over data than has been traditionally provided by table privileges. This chapter provides a comprehensive overview of LBAC and includes solid examples showing the robustness of the functionality.

Chapter 7: Encryption (Cryptography) in DB2 Encryption is typically a part of any secure implementation. DB2 9 allows use of encryption for connections, for data “in flight,” and for data on disk. These topics and step-by-step examples are covered in Chapter 7.

xxii

Preface

Chapter 8: Ready, Set, Implement? At what point is it time to begin the implementation? What must be in place before you begin? Find the answers to these questions in Chapter 8.

Chapter 9: Database Auditing and Intrusion Detection Database auditing and intrusion detection are employed for a variety of security reasons. However, setting up for this task involves some serious consideration. Chapter 9 provides both the background discussion and the technical implementation details for auditing and intrusion detection.

Chapter 10: SSH for Data-Partitioning on UNIX Platforms For environments using DB2 9 with the Data Partitioning Feature, security of machine-tomachine communication is necessary. This chapter details the setup and verification steps necessary to ensure that these types of communications don’t become a vulnerability.

Chapter 11: Database Security—Keeping It Current Security is a never-ending process. There is no “finish.” To stay secure, your environment must keep current with the latest patches and fixes. Chapter 11 discusses these and gives details on where to obtain the latest information.

Chapter 12: Final Thoughts: Security—The Human Factor Technology is only one aspect of database security. The human factors (too often overlooked) must be considered. The human aspects of security are covered in Chapter 12.

Acknowledgments Writing a technical work such as this necessitates multiple levels of review by individuals who are typically overtasked and who have little spare time. This book would not exist were it not for the ongoing support of the following individuals who took time from their all too busy schedules to assist us. Their contributions to our research, tireless reviewing of chapters, and overall enthusiasm for the topic were crucial to the effort, and the authors would like to convey their sincere appreciation. Susan Visser Paul Bird Lawrence Wargo Tim Heagarty Bob Harbus Dwaine Snow Walid Rjaibi Michael Snowbell Arnaldo Gouveia Greg Stager Hassan Shazly Herrick Mai Scott Logan

About the Authors Rebecca Bond With a background in finance, healthcare, and government technology consulting, Rebecca developed a passionate interest in data security concepts early in her IT career. Identifying security as an area that was being ignored in favor of more visible priorities on too many technical projects, she began research in 1992 on ways to secure sensitive data. During preparation work on her Master’s Capstone, entitled “Data Security in an HMO,” (a ‘thesis equivalent’ project for her MBA), Rebecca expanded the scope of her interest to include additional aspects of security such as physical security and the role played by human engineering. She began to voraciously read security manuals and analyze prominent (and not so prominent) IT security failings with a focus on how to mitigate those failings. In 1997, Rebecca was tapped as a DB2 UDB DBA on a large state financial project. This was her first introduction to DB2 UDB, and she quickly recognized the power and flexibility of the product. Determined to learn all aspects of the database engine, she began to work toward developing an expert-level competency. At each step of her work toward mastery, she validated her knowledge via the IBM certification process. She currently holds numerous IBM DB2 certifications and has been designated as an IBM DB2 Subject Matter Expert. As an independent DB2 UDB consultant, Rebecca brings a special focus toward security to each project. One of her greatest strengths is designing the database environment with security at the forefront, not as an afterthought. Even when the work day is finished, she continues her research, tenaciously seeking new ways to use the robustness of the DB2 UDB product to provide the highest level of security. During those brief moments when Rebecca’s eyes are not glued to a computer screen, she enjoys spending time gazing at Louisiana’s spectacular sunsets, “working out” on whatever physical fitness machine is part of the latest craze, writing children’s stories, buying shoes, and catching up on “what is really important” via long distance phone calls with her five grandchildren. Rebecca welcomes your correspondence on DB2 security or other topics. Her e-mail address is [email protected].

About the Authors

xxv

Kevin Yeung-Kuen See Kevin Yeung-Kuen See, CISSP, has been a Software Developer at the IBM Toronto Laboratory for the past decade. His experience includes working in the DB2 Security Development team and the DB2 SQL and Catalog Development team. He received a Masters of Mathematics in Computer Science degree (specializing in software engineering) from the University of Waterloo and a Bachelor of Computer Science degree from Acadia University. He is an IBM Certified Solutions Developer for XML and related technologies and an IBM Certified Solutions Expert (DBA for OS390, DBA for Linux/UNIX/Windows, Advanced DBA for Linux/Unix/Windows and DB2 Family Application Development). He is also an ISC2 Certified Information Systems Security Professional. He has written a few IBM developerWorks articles on the topic of DB2 security. In his spare time, he enjoys hiking, learning something new, and trying to figure out the world according to Justin, his toddler son. You can reach him at [email protected].

Carmen Ka Man Wong Carmen Wong is a Staff Software Developer at the IBM Toronto Lab. She recently joined the DB2 Continuing Engineering team, with focus on DB2 Process Model. Prior to that, she worked in the DB2 Administration Tools Development Team for five years. Her experience includes Java GUI development for DB2 Administration Tools, specialized in monitoring tools (Visual Explain and Event Monitor). She was also involved in the LBAC project in the DB2 9 release. Carmen holds a Bachelor of Mathematics in Computer Science degree from the University of Waterloo. She is an IBM Certified Application Developer (DB2 Universal Database V8.1 Family). She has published two LBAC-related tutorials on IBM developerWorks. She can be reached at [email protected].

Yuk-Kuen Henry Chan Henry Chan is an Advisory Software Developer at the IBM Toronto Lab working in the DB2 Continuing Engineering team. Prior to that, he worked on the DB2 Security Development team and the DB2 Relational Database Services team and has been with IBM for ten years. He received a Master of Science degree from the University of Alberta and a Bachelor of Mathematics degree from the University of Waterloo. He is an IBM Certified Solutions Expert (DBA for Linux/Unix/Windows and DB2 Family Application Development).


Introduction Every DBA needs a super-invisible DBA cape since we always have to be the heroes. —Rebecca Bond

ecurity in any organization often appears to be an insurmountable obstacle. As soon as you get something implemented, it needs to be reviewed and possibly revised; and shirking the responsibility is just not an acceptable option. Just like leaving the door open before a hurricane, it is too late to start to plan a defense after the storm arrives.

S

Costs and time are often cited as insurmountable issues in implementing security. On balance, however, the implementation expense cannot compare to the devastating costs of managing and recovering after a security breach. Today’s high-profile security lapses make headlines and carry the potential to destroy a company and ruin individual careers. Federal, state, and international lawmakers are taking notice of the headlines and their constituents’ complaints. In the United States, Sarbanes-Oxley, HIPAA regulations, and the Gramm-Leach-Bliley Act will soon be joined by other security-based legislative mandates as more and more corporate security breaches are reported. Although it can serve as both a technical and nontechnical reference for database security, this book is not intended to cover every aspect of information security. There is simply too much information to put in one book. Instead, the focus is on one critical piece of the whole: security for your IBM® DB2® 9 Linux®, UNIX®, and Windows® databases. Think of the information stored in those databases as jewels in your corporation’s crown. Its riches hold great potential interest to others. You may have Social Security numbers, names, addresses, and phone numbers stored there. That information is all too tempting for those who want to make an illegal profit or even those who just want to make a public point about security lapses.

1

2

Introduction

When we think about database security, perhaps we mentally imagine someone glaring at a monitor, trying password after password to gain entry to a system or database. If the trend of many high-profile recent database security breaches teaches us anything, however, it is that the threat is both internal and external. We cannot just protect from the “outside,” we have to consider that inappropriate access from the corporation’s employees can do just as much, if not more, damage. The good news is that DB2 9 offers a wealth of ways to control and protect access to your databases. These ever-increasing pressures to protect the database from a variety of threats make it critical to fully understand the numerous security features that DB2 9 provides, what they are, how to implement them, and how you can incorporate them into your overall security policy. In that regard, the focus of the material here is primarily directed toward those individuals holding the responsibilities of DB2 database administrator (DBA) or system administrator (SA). With the DB2 9 release, many new and robust features are introduced to further strengthen DB2 security and facilitate the ability to lock down the database from unintended access. Given these enhanced features, such as Label Based Access Control (LBAC), security options have been richly augmented over previous versions of the product. Whereas security of every database is the goal, the technical aspects of a database security implementation will vary depending on the platform. This book is written from the DB2 9, Linux, UNIX, and Windows perspective. It does not cover DB2 for z/OS® or DB2 for iSeries.

A PERSONAL EXPERIENCE PROVIDES LESSONS LEARNED Security and disaster recovery really hit “home” for one of the authors of this book. Rebecca Bond had been working in New Orleans in the closing days of August 2005. She had returned to her home in Ohio for a weekend trip only to find out when she reached Ohio that Hurricane Katrina had changed course and was directly targeting New Orleans. Not realizing that her return to New Orleans would be delayed for months, she had traveled lightly, bringing only one change of clothes and her USB drive. Still, she knew that the levees were designed to protect the city, so she wasn’t too concerned that the damage would be extensive. When the first levee broke in New Orleans, Rebecca realized that the initial breach was only 50 yards from where she had been living. At first, of course, she was concerned only for her friends and the people who hadn’t made it out of the city. It was much later that she realized that her apartment was probably destroyed along with all its contents. The book she was writing—the book you are reading—was partially completed but had been written (and saved) on computers that were potentially lost during the storm. Starting the task again would have meant months of rewriting chapters and would probably not have been possible because Rebecca was busy dealing with the personal and professional chaos that surrounds any true disaster recovery situation.

Introduction

3

Perhaps by divine intervention, Rebecca had brought her USB drive with her to Ohio. It had served as her backup device throughout the writing process, and she had just saved all the completed chapters the day before leaving New Orleans. Thanks to a backup device that literally is not much bigger than a thumb, this book is a Katrina survivor. Months later, Rebecca was finally able to return to New Orleans. The levee breach, despite being so close to her apartment, had not flooded her street. Her computers were in tact, as well as most of her belongings. Although she feels blessed to have been spared when so many lost so much, she also learned lessons that are appropriate to pass on to the readers of this book. First, disaster comes when you least expect it. Second, you can never have too many backups. Third, don’t count on having access to things that you typically need to do your job. Fourth, overplanning is a thousand times better than no planning. Fifth, there is no such thing as too much redundancy. As you read this book, the authors hope that you can visualize worst-case scenarios and prepare for dealing with a variety of approaches to mitigate any real-life situation you and your corporation are faced with, whether a disaster recovery or a security breach. As hard as it is to think about, it is the very act of preparing for the worst case that provides the greatest assurance of survivability.


CHAPTER

1


are providing new career and advancement opportunities for DBAs who underR egulations stand how to enhance security and mitigate risk.

NEW REGULATIONS, NEW RESPONSIBILITIES, NEW OPPORTUNITIES “Fast and loose” was how many were playing the game in the 1990s U.S. corporate environment. Controls and regulations were ignored, financial abuses were covered up, profits appeared to soar (when they were not even maintaining status quo), and on the surface, life in the stock and financial realms appeared to be a never-ending earnings party to which most wanted to be invited. The economy was robust and freewheeling. Many investors, caught up as if the 1880s gold rush had returned, hastily threw down their hard-earned money to get into “the market” before they lost the opportunity to realize the virtually guaranteed “great rewards.” Gains of hundreds of points per day were seen on NASDAQ. Initial public offerings (IPOs) of new companies were sold at several times their estimated market-entry value and were impossible to purchase before the price doubled, tripled, or quadrupled. Wealth appeared to be everywhere. Of course, that’s all history now. The facçade of financial soundness was as true as a fairy tale for some of the largest companies in the U.S. corporate lexicon. By 2002, the U.S. news became rife with tales of corporate corruption, many involving grievous financial irregularities. Evidence showed that some major corporation’s public disclosures to shareholders had not been presenting the true financial status of the company for some time. This was the time of stock price collapses and large corporate bankruptcies. The false wealth had turned to true dismay.

5

6

Chapter 1 • The Regulatory Environment

The American public, seeing their pension funds fall away, their nest egg evaporate, and their stock capital dwindle, had endured enough. Confidence needed to be restored. There was a great outcry from all across the world: “Make them accountable.” So, what does the U.S. Congress do when the citizens demand results? Congress attempted to shove the pendulum toward the opposite side. The regulatory bodies seem determined to make up for lost time. No more would citizens face losing their pension because of financial irregularities. No more would information presented to stockholders be incorrect or misleading. No more would private, personal data be “at risk.” Wait! That wasn’t the problem, was it? Didn’t we just agree that the problem was financial irregularities? How did personal, private data become a regulatory issue? It is interesting that while Congress finally got on board to assuage corporate malfeasance, other corporate controls came to light as being very lax. The poor citizens, having lost all their money in the stock market, were now faced with losing their identity! Unfortunately, with the exception of the HIPPA (Health Insurance Portability and Accountability Act) that dealt solely with health care, Congress hasn’t been able do enough to protect private, personal data, although some new regulations have been put into place. This is evidenced in the virtual daily barrage of headlines citing yet another corporate security breach with thousands of credit card numbers, Social Security numbers, names, and addresses now on the list of stolen articles and presumably in the public domain. Banks, credit agencies, personal registration information for driver’s licenses, car tags … all have suffered unintended leaks. Not yet recovered from the financial missteps, the citizens cried out again. The cry is not yet 100 percent heeded, but in time, it will be. New rules and regulations are rumored to be in consideration. This brings us to today and to the database administrators (DBAs) and system administrators (SAs) who had absolutely nothing to do with any of the wrongdoing. These are the guards of the corporate data; the keepers of the crown jewels. Welcome you heroes who, through documentation, proper procedures, determination, and technology, will turn those regulations into realities and, by your efforts, protect the citizens (and your jobs) from any harm. Bring your Super Invisible DBA cape as we explore the world of regulations … both actual and likely to be proposed … and what they mean to us as we do our jobs.

SARBANES-OXLEY July 30, 2002 was a monumental day for business accountability in the United States. It was on that date that the Sarbanes-Oxley Act of 2002 was signed into U.S. law. With the passage of Sarbanes-Oxley (also known as SOX or SARBOX), strict governmental requirements were put in

New Regulations, New Responsibilities, New Opportunities

7

place. Those included new auditing standards and disclosures, a guarantee of auditor independence, stronger enforcement of corporate responsibility, enhanced conflict of interest provisions, criminal penalties for altering documents or tampering with records, and enhanced financial disclosures. At the present, these requirements are enforced only for large, publicly traded companies; however, many smaller corporations and private companies are following these recommendations because the framework provides for a strong security and accountability matrix, and the regulations are likely to trickle down to them in time anyway. Although several of these new provisions may impact the DBA when setting up a security environment, the ones guaranteed to provide additional work opportunities are sections 302 and 404. These sections refer to corporate responsibility for financial reports and management assessment of internal controls.

Section 302 and 404 Responsibilities Section 302 takes the responsibility for financial data straight to the executive level of the organization. The executive officer of the company has to personally sign and attest that the financial reports are accurate, not misleading, and that they fully disclose financial controls and results of corporation operations. If there are any weaknesses in the design or operation of any control that would result in adversely affecting the recording, processing, aggregation and summarization, or reporting of financial data being suspect in any way, this must be disclosed. Section 404 speaks to management’s assessment of internal controls and is required to be included in the company’s annual report. This section requires the establishment and maintenance of internal control structures and reports the effectiveness of those controls over the course of the previous fiscal year. The firm doing the corporate audit also needs to attest to compliance with Section 404. Making false statements on a Sarbanes-Oxley report is against the law and can lead to hefty fines and/or jail time for the highest corporate officials. It is obvious that the company’s executive officer does not want to sign off on any documentation stating the financial or security soundness of her company without having a reliable way to know that it is safe to do so. To ensure that the information presented in the SOX certifications is “true,” there has been (and will continue to be) a need for a strong foundation of supporting information. To enable this foundation, internal controls will proliferate, and audits will become normal operating procedures.

What Internal Controls? Although there is no true, pure source to refer to for a list of Sarbanes-Oxley controls explaining what they are and how to implement them, your accounting and auditing firms will not be deterred from looking into every nook and cranny of your organization to validate the efficacy of them. That is their job, and they will do it well.

8


Because there is no “one size fits all,” it is best to be prepared with more information than is necessary. This leads us to a discussion of what regulations your CFO is going to be reading before she comes to you to discuss your role. As a part of Sarbanes-Oxley, a nonprofit agency, the Public Company Accounting Oversight Board (PCAOB), was established. The PCAOB may create rules that are then submitted to the U.S. Securities and Exchange Commission (SEC) for approval. The SEC also has rules and regulations that impact internal controls. Throw in the Generally Accepted Accounting Principles (GAAP) that you learned about in your required college business course and any accountancy’s interpretation of those principles, the Committee of Sponsoring Organizations of the Treadway Commission (COSO) a private-sector organization that provides guidance on internal controls, and the Control Objectives for Information and related Technology (COBIT) framework, and you have a general idea of the internal control requirements for Sarbanes-Oxley compliance. How they might impact your Information Technology (IT) department can be further defined based on the company’s business model, the number and types of subsidiaries and remote locations, and various other business model drivers. As you can probably tell from the preceding paragraph, different auditors bring different interpretations on compliance with internal controls. The ones listed in this book are the most frequently cited at this time, but there may be others. It is also probably obvious that the time necessary to implement new internal controls or rework old controls is not trivial. Many larger organizations report exorbitant costs and long lead times associated with SOX implementations. Some of the expenditures are so large that, when publicly announced, the company’s stock price has dropped dramatically because of stockholder’s selling. Sellers cited concerns about the sizable expenses of SOX implementations. The very controls required to prevent the stockholders from “losing their shirts” are, in fact, the ones that are driving the stock prices down (and, therefore, some of the stockholders do, in fact, lose their shirts).

Changing DBA Responsibilities A significant outcome of the SOX regulations to date has been the overtime and additional staffing in IT departments. IT departments are more often working long hours under significant stress to retrofit systems for compliance, and DBAs' efforts are critical to a successful outcome. The world of corporate accountability has changed, and the DBAs must help to rescue their company. DB2 DBAs have now been tasked with new security initiatives. They are required to ensure that only proper, “as-needed” access to the corporate data is granted, that potential misdeeds will be caught at the database layer, and that attempts to change data to hide nefarious deeds will be both unsuccessful and point to a guilty party so that punishment can be meted. Disaster recovery is taken a step further with the requirement to be able to restore to original any data that is changed in a harmful way, whether intentional or unintentional. Of course, the DBA also has to ensure that sensitive data is encrypted. Some DBAs and data analysts may even have to do data quality reviews to show that reports are generated based on factual information.


9

The tasks ahead might begin to feel overwhelming, but fortunately, DB2 DBAs have a wealth of tools to assist in creating these controls and performing these audits. DB2 DBAs are absolutely integral to the success of the company rising to the challenge of SOX compliance. Their role, as a result, has been elevated, and their sphere of influence has increased in most organizations.

DB2 DBAs and the SOX Mitigation Effort Application controls are necessary to confirm the validity of the application transactions. These are the controls designed to prevent fraud, trap or prevent unintentional mistakes, enable tracking of transactions, and ensure completeness of the application’s resulting information. The DBA is likely to be a critical resource in compliance for each of these areas. As the process toward SOX compliance begins, the DBA will likely be asked to participate in preparation of documentation and instantiating additional database implementations to satisfy some of the requirements discovered through the review. During the conversations regarding SOX implementation, the DBA will have a lot to offer in the way of DB2 features that can be deployed to satisfy many of the technical requirements that relate to requiring proof of strength of the company’s internal controls. Some of the most frequently mentioned DB2 features for SOX compliance include auditing, configuration, authorities, privileges, encryption, backups and restores, and transaction replay (roll forward). The DBA’s expertise is also needed for transitioning “user-created mechanisms” that emulate database functionality, especially if they are found lacking in security control mechanisms, such as spreadsheets. A DBA who can write solid SQL is also invaluable to the SOX effort because SQL statements will need to be created for a wide variety of reasons, such as confirming auditing (if the audit data is stored in tables), reviewing privileges granted to users, querying financial information, and verifying that confidential data is secured, just to name a few. Auditing One of the major tools that the DB2 DBA can offer in the arena of internal controls is the ability to audit transactions natively in DB2. Because one goal of SOX is to determine that adequate controls are in place, DB2 auditing is one of the “big guns” that can be positioned to satisfy the requirements to document what applications touched the database, what ID was used to instantiate those transactions, the “context” of the transaction (what SQL was run), and whether the attempt failed or succeeded. As such, DB2 auditing serves multiple purposes for SOX mitigation, including the following: • Provides documentation of transactions applied to the database • Shows any changes in authority including the id used to grant the change • Tracks any changes to the DB2 auditing configuration itself

10


• Can be used as a means to show that all transactions are recorded • Facilitates a first step toward identification of fraudulent database access Chapter 9, “Database Auditing and Intrusion Detection,” covers DB2 auditing more completely. Segregation of Duties Although the DB2 DBA cannot enforce segregation of duties from the corporation level, she certainly can do so from the database and instance level. DB2 offers a wealth of authorities, privileges, labels, and “granted” configurations that can lock down access to the finest grain of detail. For example, there are four different levels of System privileges (SYSADM, SYSCTRL, SYSMAINT, SYSMON) in DB2 that can be assigned to DBAs who need to perform normal day-to-day responsibilities. These can be assigned based on DBA job responsibilities and will be viewed by the auditor as an aid in collusion avoidance. DB2 9 also offers a unique “Security Administrator” authority (SECADM) that can be granted to a user to further define the security granularity. Chapter 5, “Authorization—Authority and Privileges,” provides more information on these topics. With Label Based Access Control (LBAC), new in DB2 9, security labels contained in an object, coupled with the security label granted to the user attempting access, can be used to fine-tune finite security access database controls based on the user’s actual business role. The granularity of access controls in DB2 is robust and will score high marks during the audit. DB2 access control general mechanisms are discussed in detail in Chapters 3, “Understanding Identification and Authentication—The First Line of Defense,” and 4, “Securing DB2 on Windows.” LBAC is discussed in Chapter 6, “Label Based Access Control.” Backups Integral to the SOX guidelines is that data must be recoverable. This is not just a requirement to be able to restore a database, it is also a requirement that data that has been corrupted by any application or user process, whether a normal mistake or as the result of a hack, is restorable to pristine. DB2 has always offered a robust internal utility for database backups. The DB2 BACKUP DATABASE command and associated application program interface (API) is time tested and widely used by DB2 DBAs everywhere. DB2 dropped-table recovery functionality, once enabled, allows a fine level of recovery should a table be accidentally dropped. Other DB2 features and functionality enable you, given the appropriate hardware, to instantiate databases using Flash or split-mirror technology, which can also serve as backup mechanisms. (Split-Mirror technology is exceptionally well covered in the book High Availability Guide for DB2, by Chris Eaton and Enzo Cialini.)


11

As you can see, DB2 recovery options are both plentiful and robust. Some well-known and oftenused examples are as follows: • A restore from a DB2 backup • Restoring a backup image into a different database (redirected restore) • Recovering a dropped table • Restoring a tablespace • Backing up and restoring single or multiple tables using export and import/load functionality • Using the DB2 Recovery Expert to restore a single unit of work With the DB2 restore utility, the database-level restore can be made over the database the backup was taken from, to another database on a different file system (using the redirected option), to a point-in-time (allowing restores to a point prior to the time when some unintended process was run), or the restore can just be to a single affected tablespace. The backup(s) being used for the restore may come from a single backup image or a combination of backup images (from the same database) applied in specific order. The restore may need to be completed with the application of DB2 database transaction logs, or may be completed using only a full backup image, depending on the scenario. The DB2 Recovery Expert is an add-on product requiring a separate license. Given the SOX requirements to be able to recover, if necessary, from virtually any unwanted SQL, the DB2 Recovery Expert provides a virtually infinite level of granularity allowing reversal of unit-ofwork SQL changes to the DB2 database without requiring a database restore operation. The product can read the DB2 transaction logs and can be used to replay transactions in reverse order, backing out the SQL unit of work in question without restricting access to the database for other transactions. As you can tell, the options for recovering a DB2 database are both powerful and flexible. They may be incorporated to play a large role in meeting compliance requirements for disaster recovery and business continuity, too. Encryption Encryption is mentioned by many SOX auditors as necessary for maintaining the confidentiality of data. Although there is no hard-and-fast guideline to determine what is confidential and what is not, it is probably safe to consider personal, identifying information such as Social Security numbers, employee ids, birth dates, and health records to be strong candidates for information requiring encryption.

12


Since Version 6, DB2 has supported password encryption “on the wire” through the use of the SERVER_ENCRYPT database manager configuration parameter. This feature keeps the login password secure and prevents password discovery via sniffing. The DATA_ENCRYPT parameter takes this encryption several steps further by encrypting not only the password, but also SQL, the output of the SQL, and more. DB2 data encryption features are also available for use by application software code via the use of built-in functions such as ENCRYPT, DECRYPT_BIN, DECRYPT_CHAR, and GETHINT. The mechanisms to encrypt/decrypt data rely on a password that can be set interactively or embedded in the application itself, providing additional flexibility. The GETHINT feature is also under code control and can be used to aide the user attempting to remember the password. Given the importance placed on encryption for many current and potential future regulatory requirements, this topic is discussed in detail in Chapter 7, “Encryption (Cryptography) in DB2.” Securing User-Designed Pseudo Databases One of the places security compliance auditors are likely to focus is reviewing the company’s “quasi” database spreadsheets and user-driven database implementations. These are not “true” databases, but they often exist and should be thought of as “pseudo” databases. Many financially oriented employees are comfortable with products such as Excel and tend to try to use them as their “front end” to data in the “real” database. Other users just copy the data from the “real” database into products such as Microsoft Access. Many auditors consider these pseudo databases to be a major risk since this activity typically results in data being manipulated outside the confines of a securely implemented database environment. If the data is manipulated outside of the “real” database and then presented as fact, so the theory goes, the results may not match the reality that would be evident in the “real” database. Because the corporation’s true databases are required to be the gold standard of data, more and more auditors are spending a significant amount of discovery time determining whether these types of pseudo database “pretenders” are being used for data manipulation. When they are discovered, the auditor will spend time determining that they do, in fact, tie to the database. Because the time involved in this type of technical detective work is costly, savvy corporations are beginning to ban pseudo databases and restrict the use of spreadsheet products to presentation of data only. Given the inability to enforce robust access controls surrounding these user-based implementations, the DB2 DBA is likely to be asked to port these pseudo databases into new DB2 instances and true DB2 databases where they can be secured as part of the sanctioned corporate IT realm. Because DB2 supports importing or loading data that has been saved in comma-delimited format (and several other formats), virtually any user-based implementation can be ported with ease to DB2.

HIPPAA

13

The Participating DBA The DB2 DBA will be a major contributor to the success of the SOX audit. The better your knowledge of the functionality of the DB2 product, the better your ability to recommend comprehensive solutions specifically tailored toward SOX fulfillment requirements. Many times, higher levels of management do not understand even the general features of the database products that run in their environments and do not ask the DBA about solutions in a timely manner. This is one time it is best to be proactive. If the DBA can become part of the SOX compliance effort at the initial stages and explain the features of DB2 that can be configured specifically with SOX compliance in mind, the effort will be rewarded with reduced implementation costs and, hopefully, a successful outcome.

HIPAA The Health Insurance Portability and Accountability Act (HIPAA) has been around since 1996. The IT departments for insurance carriers, medical centers, physician offices, pharmacies, and ancillary health providers are all well into compliance efforts. It is likely, however, that there will be increased requirements in the future as the public becomes more aware of their rights under this act and demand ever greater assurance of privacy controls. Other changes may be driven by changes to Medicare and Medicaid provisions or required if the current measures are discovered to be insufficient to ensure patient privacy. HIPAA was the first such act in the United States to impose civil and criminal penalties for improper data disclosure violations, and the penalties can be significant. For example, if identifiable information regarding an individual is disclosed for monetary gain, the offender can be imprisoned for up to 10 years and fined up to $250,000 for each such violation. Also, any person who believes that any health plan provider has not complied with HIPAA provisions may file a complaint, making the attempt to conceal noncompliance fruitless. In other words, HIPAA has the full support of the U.S. justice system, is policed by a combination of both regulatory review and the citizens at large, and requires great diligence to avoid serious consequences. This act has teeth! Goals for HIPAA include ensuring that employers or individuals can renew coverage despite current health conditions, facilitating the ability to switch health-care plans if desired, reducing health-care fraud and abuse, protecting the privacy of individual’s health information, and simplifying administrative tasks. HIPAA regulations deal with data storage in an effort to simplify the sharing of necessary information between insurers and care providers. HIPAA also provides a standardized format for claims submissions meant to ease the flow of information between health-care providers and insurers.

14


With the strong emphasis on security, HIPAA requires health-care organizations to have a verifiable written and implemented security policy and requires completion of risk assessments for compliance. The security policy must be reviewed on a regular basis (usually annually), and the DBA can be expected to be part of that review process (because many of the security controls focus on data protection). Another likely outcome of HIPAA compliance, and new responsibilities for DBAs, is the integration of disparate systems. It is to the health insurer’s benefit to consolidate systems, incorporating a smaller overall number of databases to house as much of the information as possible. This enables the organizational effort toward HIPAA compliance to focus on one infrastructure rather than many. With the requirements for strong authentication of users, auditing of all user access, and the requirement for implementation of appropriate data encryption, having a limited number of database environments may provide significant time and labor savings for the IT staff and a significant cost savings for the corporation. From the DB2 DBA standpoint, perhaps the greatest impact of HIPAA is the prevention of inappropriate viewing or sharing of confidential patient information. After all, who among us wants our employer (or anyone else) to know everything about our health. That doesn’t mean that the health-care organization should not share important health information. In fact, sharing of information is necessary for physicians to keep current on their patient’s care and for insurance companies to pay the bills. If information sharing were to stop, health care in the United States would be seriously compromised. The DB2 DBA dealing with HIPAA compliance will encounter some of the same challenges as the DBA who is dealing with Sarbanes-Oxley compliance. Both require auditing, encryption, and strong authentication. With health care, however, the aspect of “sharing” the data takes the challenge a step or two further. DB2 has many features to aid the DBA in protecting this information. These include auditing, authentication, encryption, and LBAC. Given the criticality of these topics to a successful HIPAA implementation, each of these items is covered later in this book and in much greater detail than provided in the brief overview that follows. Auditing Just as in the Sarbanes-Oxley regulations, auditing is a strong requirement for HIPAA. The information contained in health records can be very personal in nature. Beyond the civil and criminal penalties, the inappropriate disclosure of sensitive health-care information can effectively wreck lives. If the breach is subsequently publicly disclosed, an additional consequence is the likely demise of the health-care concern that failed to protect the data DB2 auditing, therefore, becomes an integral technological control mechanism, because it can be used to determine potentially inappropriate access and also serve as a deterrent if users are aware that their activity is being audited.

HIPPAA

15

The following shows a theoretical example of DB2 auditing at work in a health-care setting.

DB2 Auditing Theoretical Example James is a senior DB2 DBA for a Fortune 500 health insurance organization. While performing his daily review of the DB2 audit logs, he notices a significant increase in the number of attempts to access a program used to retrieve sensitive data.This activity is suspicious, and he begins further investigation. Using the audited event record, James identifies a user ID and application responsible for the increase in the number of program executions.With this information in hand, he reports the suspicious activity to management. Management determines that the ID belongs to a claims processor who would only seldom need access to such sensitive information. Based on the information James provides from the DB2 audit facility, management finds that the claims processor is potentially accessing information on many more individuals than he should to complete his tasks.While management investigates, James is asked to revoke all privileges on the database for the user ID in question, which he does to protect the data from any further access. During the investigation, it is discovered that the claims processor had stored his user ID and password on a sticky note and had “hidden” it underneath his keyboard. An intern who was assisting the claims processor in his work had found the sticky note and, out of curiosity, had logged on to the secure application with the claims processor’s ID. The intern was not aware of the nature of the data he was viewing until he was called in to be dismissed. The claims processor, whose casual approach to securing his user ID was revealed, received a written warning and one year of probation, but was able to keep his job. Yes, this was a completely theoretical scenario, but certainly a plausible one. It shows that the use of the DB2 audit facility can serve as a strong foundation for HIPAA compliance. Authentication Authentication can best be summed up as making sure that you are who you say you are. There are not many situations in which database authentication can be safely ignored, and health care is certainly not one of them. If any data is ever “interesting” to prying eyes, health care would likely top the list for those individuals without scruples. DB2 database authentication is multifaceted and configurable, and the DBA should take as much time as necessary to “get it right,” especially because “getting it right” is a requirement for HIPAA compliance. Encryption HIPAA requires encryption of sensitive data such as Social Security numbers, names, and birth dates. Many organizations are taking this to the next logical step and encrypting diagnosis and

16


medication information for individual records. DB2 supports data encryption and decryption natively through built-in functions. Because the encryption algorithm used by DB2 (RC2 with keys derived from an MD5 hash of the user-supplied passphrase) is designed for efficiency as well as security, this allows for faster retrieval time while still meeting the goal of protecting the data. Label-Based Access Controls New in DB2 9, LBAC enables DBAs to control access using a security label “tied” to a database object coupled with the security label granted to the user who is attempting object access. This new mechanism allows taking security to the “row” and “column” levels and can prevent or allow access to that particular row or column based on the user’s access privileges. This feature provides the DBA with strengthened mechanisms to meet HIPAA requirements. DB2 Anonymous Resolution Sharing of information in health-care settings is a necessity, but security is also a necessity. The DB2 Anonymous Resolution is an add-on product that allows health-care concerns to meet the HIPAA requirements for security while also ensuring that information is appropriately shared. An instance of one use of DB2 Anonymous Resolution in a health-care setting is discussed in the following example.

DB2 Anonymous Resolution in a Theoretical Health-Care Setting Insurance company A needs to determine whether any of its members have additional coverage through its rival, company B. Neither company wants to reveal any additional information to their rival, but they both want to know whether they share any members. If they do share any common members, they might be overpaying for claims, or paying for claims that aren’t their legal responsibility. Using DB2 Anonymous Resolution, each company’s membership roll is funneled through a cleanup process to handle any data format issues.The uniquely identifying data is then hashed using a one-way hashing algorithm.The hashed value is meaningless to anyone viewing it, so the information is protected from discovery. Both insurers agree to have the matching process completed at site A because there is no real data passed in the process and, therefore, no risk in doing so.When a match is found, DB2 Anonymous Resolution issues an alert. This means that each insurance carrier holds a policy on the same insured. At that point, the two insurance carriers can begin the process of correcting the double coverage.

Gramm-Leach-Bliley

17

Through its use of hashing, DB2 Anonymous Resolution does not pass the actual data, but instead anonymously allows a determination that there is a data match. This “match before release” helps eliminate inappropriate sharing of data of information without revealing any actual data during the process. It works even with data that is not in the exact format on both systems.

GRAMM-LEACH-BLILEY If you are a U.S. citizen/resident who was born before 1970, you probably remember the days when banks were banks, insurance companies were only in the business of writing insurance policies, and your definition of a financial institution probably involved a checking account that was held in the bank down the street. With the Gramm-Leach-Bliley Act (GLBA) of 1999, those demarcation lines have become very fuzzy. Insurance companies are now selling financial products, stockbrokers now sell IRAs, and the small bank on the corner was acquired by a national corporation a few years ago. The GLBA was the conduit to these changes. The GLBA brings tough protections for the nonpublic personal information (NPPI) held by financial institutions. Parts of this act also apply to third-party vendors and service providers that maintain or process customer data. The GLBA requires annual notification to customers regarding potential disclosure of identifying information and provisions for customers to avoid such disclosure. Examples of NPPI include customer’s names, Social Security numbers, credit histories, bank account numbers, and any other identifying financial information. Penalties for noncompliance of the GLBA can be severe; and in situations where there is a serious breach of security, the company’s board of directors can be held personally liable for civil and criminal penalties. Noncompliance can also lead to potentially serious, and certainly embarrassing, civil charges against the company president, as was the case for one large U.S. mortgage lender in 2004. Like HIPAA, the GLBA requires a strong overall, written, tested, and auditable security program with appropriate risk assessments. Also like HIPAA, strong access controls, authentication, auditing, encryption, and anonymous sharing of information will all be factors in the financial company’s GLBA solution. The GLBA also features an “opt-out” provision that is unique among the other regulatory initiatives discussed here. Financial institutions often enter into marketing agreements with other financial institutions, sharing information about customers for purposes of gaining additional business. That is one of the reasons you might receive numerous pieces of mail offering financial services through various organizations shortly after you begin a new relationship with a financial institution. Within certain guidelines, this sharing is still permitted under the GLBA, but customers now have the option to opt out of the process. This adds a layer of complexity to the business desire to share information.

18


Just as with the HIPAA regulations, DB2 features such as DB2 audit, encryption, authentication, LBAC, and DB2Anonymous Resolution can all play a role in the GLBA-compliance architecture.

FEDERAL INFORMATION SECURITY MANAGEMENT ACT In 2002, in response to increased terrorist threats, the U.S. Congress enacted the E-Government Act. Title III of the act, named the Federal Information Security Management Act (FISMA), requires U.S. federal agencies, contractors, or any other agencies that support the operations or assets of the federal agency to provide appropriate security for those operations/assets. A key element of FISMA is that these agencies conduct their day-to-day operations employing a security approach that is commensurate with the potential risk. To that end, standards for development and testing have been developed by the National Institutes of Standards and Technology Computer Security Division (NIST). The act mandates reporting by agency heads to the White House, Congress, and the General Accounting Office of the United States, confirming that security policies implemented are adequate and effective. In addition, officials are “graded” on the potential effect a serious security breach would have on the operation. From the DB2 standpoint, the DBA should be prepared to apply whatever security is necessary. Because every federal agency will have potentially different needs, the DBA should be aware of the variety and depth of DB2 security measures, including those discussed for Sarbanes-Oxley, HIPAA, and Gramm-Leach-Bliley: • Authentication • Privileges and authorities • Encryption • LBAC • Auditing • DB2 Recovery Expert and DB2 recovery functionality • DB2 Anonymous Resolution It is important to stress that the security team should make the effort to understand the needs of the particular federal agency before making recommendations or beginning to work on a solution. Each federal agency will have different drivers and different risks. There should be enough time in the project plan to perform risk assessments and gap analysis. After that work has been accomplished, the DBA is in a better position to determine how DB2 should be positioned.

Federal Information Security Management Act

19

As you consider your options for a secure implementation, remember, too, that DB2 offers a rich complement of application tools that you can use to enhance your security arsenal. Triggers, stored procedures, and user-defined functions, for example, often are coded to be used for security purposes. Update triggers, for example, can be coded to insert the “old” value of the row being updated into a separate table. With the old data safely stored, the DBA has both the before and after picture of the data row should there be any question regarding the update operation. Other DB2 mechanisms, such as replication, might prove useful, too. While reading tomorrow’s newspaper today is still not possible, one prediction is virtually certain: There will be more regulations, and the technology of information security will continue to evolve even as security breaches continue. Today, it is difficult to go too many mornings without a newspaper headline screaming about yet another security breach with thousands of pieces of identifying information delivered to the hands of hackers and thieves. If online commerce is to grow, if information technology can ever be trusted by the public, if our IT infrastructures are ever to mature, security has to be a top priority. At this time, the regulations to protect and secure data are new, and, in many cases, standards and requirements are still being formulated even though the “act” has been published and compliance is required. As DBAs, we know the drill. At some point, changes will be mandated, and what is done today to protect the data will need to be enhanced or redesigned in the future. Security will never be a stake in the ground, and the effort of establishing and maintaining a secure environment will always need to be prodded forward. Being reactive is risky. Being proactive is the only safe course.


CHAPTER

2

DB2 Security— The Starting Point

FIRST WORDS—WHAT’S THE PLAN? When thinking about organizational information security, your mind might jump to the technical details such as firewalls, access control lists, certificates, auditing, encryption, and all those wellknown electronic trappings that present a mental vision of a secure architecture. In fact, if you review the security implementations for most organizations, you will indeed see all those things. Did you ever wonder how those physical and logical layers of security ever started out? I did, and what I found out may surprise you. Despite all the electronic gadgetry, despite the fact that these environments were created by information technologists, despite this being the electronic age, despite the “paperless” society, the best security implementations … the ones that still stand up to the test of time … began as a written security plan on good, old-fashioned paper! If you’re seeking to emulate what other companies have shown to be successful, first you need to have a plan, and then you need to stick to it. That does not mean that you should create the security plan and never modify it, but it does mean that this plan should be solid enough to guide formulation of your organization’s day-to-day database security policies. In today’s lightning-speed development and production environments, slowing down long enough to actually create a plan may appear to be an unaffordable luxury. Consider, however, that this plan does not need to be an impediment to progress, but rather an empowering document, facilitating the time and commitment of resources that must be dedicated to the security initiative. If you happen to be a DBA, that written database security plan can be a lifesaver, both on initial database setup and as an ongoing reminder of the symbiotic relationship between the database and the security of the organization’s information assets. It should give you guidance both before

21

22

Chapter 2


and after a database has been launched. It will be an important guide as you formulate your DB2 database policies. It must be an active document, referred to for guidance on a regular basis and updated as change arises. For the corporation’s sake, the database security plan should not suffer the fate of so many others and become yet another a dusty binder stored on the top of someone’s filing cabinet. Perhaps, one of the most important benefits to be gained from creating a database security plan is that the very act of committing the plan to writing will assist in identifying potential security risks that might not be uncovered in a benign way otherwise. If security is not on the corporate conscious, the true threat is masked by all the tasks and energies required just to keep day-to-day operations or development going. Working on any security plan funnels the combined thoughts of the organization into one readable whole and presents in a clearer fashion the ways to address and mitigate those threats.

THE DB2 SECURITY PLAN Because you’re reading this book, it’s obvious that you have an interest in protecting the data assets held by your organization; but unless you have a very small organization with a single very small database, you need a plan and a leader. Formalization of that plan will provide great assistance toward the goal of database security, and during the formulation of that plan, a leader (corporate sponsor) should emerge. Many organizations already have some type of security plan in place that may or may not include specifics on database protection. If your organization has an enterprise-level security plan, the DB2 database security plan should be a significant and highly visible part of that document. If you do not have an enterprise level security plan in place, the DB2 database security plan should still be created, even if it must be undertaken as a standalone document. Given the criticality of protecting the data stored in those DB2 databases, ignoring the security responsibilities may mean unacceptable organizational risk. The DB2 security plan document is a road map that will provide the foundation for the enforcement of the operational DB2 database security policies that will be implemented. It should provide a meeting of the minds with regard to the security of the organization databases and how DB2 should be used to fulfill those needs. If you are a DB2 database administrator, you have a vested interest in getting a DB2 security plan in writing. This plan, once written and approved by management, can be your guideline for setting up your database security policies. It can be referred to when questions arise, such as access levels, provided to auditors to facilitate their reviews, and should be reviewed or revised when new applications are installed. A major bonus for you is that when finalized, it will keep you from having to answer the same questions about security over and over again, saving you time and allowing preservation of your sanity.

The DB2 Security Plan

23

So, if necessary, take the lead on getting a committee involved in formalizing a written DB2 security plan. You may get resistance, but remember that the database you are trying to protect is potentially one of the greatest assets held in trust by your organization (and the people it serves), and, therefore, it should be treated and protected just as any other valuable corporate asset would.

Security Plan Meeting Participants The first step toward achieving your database security plan is to identify the team members who should be involved in the creation and review of the document. In a typical organization, the positions listed in Table 2.1 might be considered key to this task. Table 2.1

Database Security Plan Team Members

All Appropriate Members of Management CIO CTO Vice presidents Division managers Technical team leads Application subject matter experts (SMEs) Network administrators Systems administrators Database administrators (DBAs) Corporate security officers

One important factor in determining who to include is the realization that the matters discussed in these meetings could be used by internal or external sources in inappropriate ways. Because the focus of the meetings is to discuss and mitigate current and future threats, the core meeting group should consist of individuals who are trusted by the organization to maintain the confidentiality of issues discussed. To succeed, the database security plan needs a corporate sponsor. This should be someone within the organization who has the appropriate level of interest, authority, and responsibility to approve, communicate, and enforce the resultant plan. If your corporation has a security officer, especially if the position that person holds has sufficient status within the organization, the security officer may be able to fulfill the sponsor role.

24

Chapter 2


Obviously in large organizations, division personnel should be involved in the process. It is important to get their unique perspective on database security because they may face challenges that are not easily identified. Depending on your organizational structure, division technical personnel should be invited to the meeting if they have discrete environments or can provide technical expertise relevant to database or application security. Communication and information from application SMEs will likely be necessary to determine the granularity of database security needed. These are the individuals who can indicate which data needs the most protection, which users should have access and the level of that access, and how to determine whether a breach has occurred. These individuals may be technical leads, application programmers, or just those who know the application well because of their role. For example, an accountant might be the individual who knows the most about the general ledger applications. The remaining participants should be the hands-on technical individuals who typically have the roles of network administrator, system administrator, and DBA. Participation of individuals who fulfill these roles is absolutely critical to successfully designing a plan because each will bring a unique focus to the process. Gather Information Before any meetings are scheduled, there should be some gathering and summarization of information if it is not already readily available to the team. A minimum starting list of items includes the following: • Current security documents • Standards (formal or informal) Any written security guidelines Any informal security policies that have been enforced in the past • Hardware in use or proposed for DB2 databases Machine specifics Physical location • Connectivity mechanisms in use • Current authentication methods • Operating system information OS type OS level • Maintenance procedures, such as patch management, currently in place • Licensing agreements


• User and group information • List of DB2 instances by hardware The type of instance Development Test Production • The database manager configuration parameters in use per instance (DBM configuration) • The product and level of the DB2 code base installed (DB2LEVEL command output) • List of DB2 databases by instance • Database configuration(s) (DB configuration) • Backup procedures including types, frequency, and storage location • Applications currently being run (as observed or proposed) • Typical number of users • Access control measures in place Authorities Privileges • List of applications Type Web-based Third-party Batch • Application “owners” • Prior risk assessments • Information on known data classification • Special security considerations Federated Information Integrator High Availability Cluster Multi-Procesing (HACMP™) • Results and recommendations of any security audits that have been performed

25

26

Chapter 2


Meeting Goals and Desired Outcomes After you get the appropriate parties and the initial information together, meeting goals should be established. It is difficult to create a database security plan in only one meeting unless your organization is very small, so it might be best to create overall goals and then plan enough meetings to allow time for discussion. Segment the discussion with the idea that internal and external security may pose different threats and, therefore, require a different set of goals. Uniformity of standards can simplify security policies and should be considered to the extent that they can be implemented across the organization without incurring increased risk. The result of these meetings should include a comprehensive, written policy addressing the components of the database security plan, including at a minimum, the following: A. Appropriate analysis of internal and external database security risks and the current approach toward their mitigation B. External security authorization mechanism 1. Group and user naming standards 2. Password standards and change guidelines C. Operating system standards (for DB2 files, file systems, logical volumes) D. A workable blueprint for setting up the DB2 database security policies What security standards should be set for all databases? 1. A List of access control levels by database a. Who needs access and at what level? b. Granularity of access control needed c. What security access is needed by the following? 1. Application 2. Group 3. User 4. Database E. Who will be responsible for internal user and/or group account setup? 1. How will user accounts be tracked? 2. How will terminations and revocations be handled? 3. How will necessary access changes be conveyed?


27

F. What approvals are needed? 1. What forms are required? 2. What sign-offs must be in place? G. Identification and classification of extremely sensitive information 1. By database 2. By application 3. By table 4. By column 5. By row H. Identification of overall DB2 security management responsibility 1. Who is the owner? 2. Who can delegate? 3. Who is the custodian? I. Uniformity of database policies and any acceptable deviations J. Auditing requirements K. Incident handling procedures L. The review cycle for the formulated database security plan 1. Are there regulatory requirements for the review cycle? 2. Should the entire plan be reviewed at once? 3. Will there be a review after hardware changes? 4. Will there be a review after software changes? Meeting Facilitation Tools When considering an analysis of internal and external database security risks, you can use a grid approach. Table 2.2 shows a basic example. Table 2.2

Database Security Risk Grid Example

Internal

Threat

Plan

Shared passwords

High

New password policy.

Disgruntled employees

Medium

Review access levels before personnel actions are undertaken. (continues)

28

Table 2.2

Chapter 2


Database Security Risk Grid Example (Continued)

Internal

Threat

Plan

Users granted inappropriate access to data

Medium

Check and review current database grants; create an access control policy.

External

Threat

Plan

Introduction of vulnerabilities due to lack of maintenance

High

Schedule maintenance window for patches.

Hacker attack

High

Keep current with patches; encrypt sensitive data; change passwords on a regular basis; enforce password standards; undertake vulnerability assessment.

Web users with incorrect access

High

Check and review current database grants; create an access control policy.

It is likely that this grid (or any other facilitation mechanism used to capture this detail) can grow quite large. It should be viewed as a brainstorming tool to assist in determining the scope of risk. As in the example, it is likely that the items under the Plan column may contain duplications that might occur when one risk can be mitigated by the same action as another risk. An example of this is a risk of external resources and internal resources holding inappropriate access to data. Whereas each presents a different threat to the database and potentially a different level of risk, one action that should be included in the plan for proposed mitigation of both is to review current database access levels and create an enforceable access control policy. The formation of this grid may assist in identifying the highest-priority items that should be addressed first (even before the plan is completed) and might lead to discovery of threats not currently on the corporate radar. As a first step before tackling the robust work of actually formulating the part of the plan that will serve as a blueprint for the DB2 database security policy, the grid will facilitate an assessment of where the corporation stands now with regard to database security and potentially assist in identification of any serious lapses. After the assessment of internal and external threats has been completed, the results should be summarized and organized to be used as input for the next steps. Determining the Authentication Method and User/Password Security Authentication for DB2 databases is handled by a security facility outside of DB2, such as the operating system, Kerberos, or other plug-in. Although it is not necessary at this point in the process to be specific as to the parameter settings (authentication is discussed in detail in Chapter 5, “Authorization—Authority and Privileges”), the overall authentication requirements should be documented. The discussion should include a determination as to where the authentication


29

should take place (that is, client, server, DB2 connect server, host) and whether encryption (Chapter 7, “Encryption [Cryptography] in DB2”) is required. Standards should be developed for naming conventions for groups and users. Part of this strategy should be that known default or easily identifiable group names and usernames are not allowed. Some that are commonly used in many DB2 shops (and should therefore be avoided) include the following • db2admin • db2as • db2inst1 • db2fenc1 Another important discussion regarding groups revolves around the DB2 group known as PUBLIC. DB2 comes with this group by default. This group can (and should) be locked down unless there is some documented reason for this group to maintain certain low-level privileges. Prior to DB2 9, this group always received a number of privileges from the moment the database was created. With DB2 9, an alternative for dealing with the PUBLIC group privileges is made available. When creating a new database, adding the keyword RESTRICTIVE changes the default behavior, and no privileges are automatically granted to the PUBLIC group. If this keyword is not used, the following permissions are available to the PUBLIC group after the database has been created: • CREATETAB • BINDADD • CONNECT • IMPLSCHEMA • EXECUTE with GRANT on all procedures in schema SQLJ • EXECUTE with GRANT on all functions and procedures in schema SYSPROC • BIND on all packages created in the NULLID schema • EXECUTE on all packages created in the NULLID schema • CREATEIN on schema SQLJ • CREATEIN on schema NULLID • USE on table space USERSPACE1 • SELECT access to the SYSIBM catalog tables • SELECT access to the SYSCAT catalog views • SELECT access to the SYSSTAT catalog views • UPDATE access to the SYSSTAT catalog views

30

Chapter 2


As you can see, the privileges for the PUBLIC group on a newly created database are significant. If discussions yield no valid reason for PUBLIC privileges, the RESTRICTIVE clause should be used for newly created databases. Excellent password security is one of the elements of a strong security plan. In addition to identifying the responsibility for password security enforcement and the mechanisms for change, the following topics should be considered: • Changes Will users change their own passwords? If not, how will they be notified of the changes? • Length of time between required resets/changes If not reset/changed, how long until lockout of the account? How many cycles must be completed before passwords can be reused? • Resets Who will hold responsibility for password resets? Will a secondary authentication be used to allow the user to reset it? Secondary authentication question answered correctly Biometric authentication Electronic device such as a key card • Lockouts How many password attempts before lockout? What forms and approvals are to be in place? Who will have the authority to retrieve a lost password or credential? In considering passwords, a discussion of composition standards for those passwords is necessary. The human factor in password issues is well recognized. If your users are allowed to create their own passwords, without any applicable standards, the strength of those passwords will be suspect. If complex passwords that are not easy to remember are instead assigned to users, in variably they will be written down someplace, and that overrides the strength of the complex password. One approach to this is to create a security password template. This provides the mechanism to ensure that the password meets certain standards, such as three capital letters, two numbers, one symbol, and two lowercase letters. However, this can be problematic. Consider that internal employees will know the template. This information could provide an unintended assist if an internal or former employee wanted to gain access through password hacking.


31

It is critical that forbidden passwords include usernames, employee IDs, dictionary words (in any language), and true words with numeric replacements of ones or zeros. All these are easily hacked by a brute-force approach. It’s easy to say that passwords should never be shared, but harder to enforce that standard unless there is some strength behind the security plan, policies, and procedures that can bring consequences to those who violate this essential security foundation. Passwords should also be expired, but this brings up the question “When?” Too-frequent password expiration is problematic because users are tempted to write them down somewhere. A longer time between password changes means a longer exposure period. Changing passwords on a regular interval can be beneficial, but if this actual interval is widely known, this, too, can be a risk. Would you really want a hacker to know that passwords expire on the first Saturday of every other month? Encryption of all passwords is a strong recommendation. DB2 provides easily implemented encryption security features to protect passwords (and more), as discussed in Chapter 7. As with all security features, knowledge of current industry standards and practices regarding password topics will provide the best guidance. As security evolves, so do the attempts to thwart that security, so keeping current through a proactive approach is wise. Discussing the Blueprint Now that you have summarized the results of the internal and external risk assessment for database security and addressed authentication, it is time to begin work on the part of the plan that will eventually be used as a foundation for creating the actual DB2 database security policies. At this point, the team needs to have a good understanding of the internal and external threats that should be addressed to protect the database. During this phase of the meeting process, the team should begin to discuss the security standards for all corporate DB2 databases. Depending on the structure, complexity, and size of the organization, this can be intricate with multiple considerations per division, per database, per machine, and so on. The goal of this part of the plan is to integrate information discovered in previous steps to facilitate creation of the DB2 database security policies. At this phase of the process, the team should begin to discuss a workable set of security standards and how they should be applied. Questions to be answered and topics to be codified in the plan include the following: • The ability to uniformly apply database security standards Are there needs for differing standards based upon …? Divisions OS types and levels File system storage versus raw devices Firewall

32

Chapter 2


VPN Federated Replication LDAP Are there special considerations for specific third-party applications? If so, how will these differences be identified and handled? • Access control plan A statement identifying responsibility and ownership Account/group setup Account tracking Terminations Changes Matrixes of access levels needed (see Table 2.3) For authorities For privileges Special Identification of necessary maintenance steps Approvals Forms Sign-offs • Identification of extremely sensitive information for special consideration As mentioned previously, matrixes can aid in identifying access requirements. You can then use these matrixes as input for the DB2 database security policies. The examples in Tables 2.3 and 2.4 consider specific access levels and decode, by group, the level(s) that should be applied. Although the examples represent true discussion points, the values assigned here are for a fictional company, and no special meaning should be ascribed to them. Table 2.3

Database Authorities Matrix

Instance Level

Corporate Tech Arch Group

Corporate DBAs

Division 1 Tech Group

Division 1 DBA Team Lead

Conversion Team

SYSADM

Y

N

N

N

N

SYSCTRL

N

Y

N

Y

N

SYSMAINT

N

Y

Y

Y

N

SYSMON

N

N

N

Y

N


33

Database Level

Corporate Tech Arch Group

Corporate DBAs

Division 1 Tech Group

Division 1 DBA Team Lead

Conversion Team

DBADM

N

Y

Y

Y

N

LOAD (with insert privilege)

N

N

N

N

Y

Table 2.4

Database Privileges Matrix Public

All Groups

Software Development

Conversion Group

ETL Group

Connect to database

N

Y

Y

Y

Y

Create new packages

N

N

Y

Y

Y

Create tables

N

N

N

Y

N

Unfenced stored procedures or UDFs

N

N

N

N

Y

Implicitly define schemas

N

N

N

N

N

Connect to database that is in quiesce state

N

N

N

N

Y

Allow user to create a procedure for use by other applications or users

N

N

Y

Y

Y

Definitions and detailed explanations of authorities and privileges are covered in Chapter 5.

You can build similar matrixes to assist in identification of the additional security privileges to be addressed in the DB2 database security policies. These could include the following: • Schema Create objects within the schema Alter objects within the schema Drop objects within the schema • Tablespace Create tables in a specific tablespace • Tables and views Control of a table or view Add columns

34

Chapter 2


Add or change comments Add a primary key Add a unique constraint Create or drop a table check constraint Select, insert, update, and/or delete rows Create indexes Export Create and drop foreign keys • Packages Rebind Execute Allow package privileges for others • Drop and control on indexes • Execute routines • Use and alter on sequences • Passthru (in a Federated database environment)

Next Steps Now that the plan has been visualized, it is time to put it to paper. In thinking about what has been covered, it should be obvious that some of the information provided in this living document could be sensitive in nature. It is detailing how your corporation plans to mitigate security risks for the database and, therefore, could provide information to hackers or an internal employee and become an unintended aid for the very risks the plan is meant to address. Think about the “security” of the database security plan document. It should be protected while it is being written. Leaving parts of it lying around while it is being typed is not appropriate. The persons doing the typing should be trusted employees, too. At a minimum, the electronic copies of the plan should be password protected. Because of the sensitivity of the information, it is best to disseminate the plan on an “as needed” basis. One possible scenario is to create a security library with all security documentation provided through a signed checkout process. Other steps such as limiting the use of the document to one room that does not have a copier and stamping each page with a highly specific watermark to verify authenticity could provide some measure of further security.

DB2 Database Security—Create the Policy

35

DB2 DATABASE SECURITY—CREATE THE POLICY DBAs are notoriously overworked. They are an integral part of the day-to-day database management work and serve as the technological wheels of the corporate vehicle. Given their usual desire to stay “hands-on” and the significant tasks that they face, DBAs seldom have the time or inclination for writing documentation. When security is not a priority, database security policies, if they are documented at all, are often vague and will likely suffer from poor implementation. Given the considerable security risks imposed by ad-hoc policies and spotty enforcement, committing the policies to writing and implementing them consistently and successfully is critical. Although a trial-and-error learning approach might work in some database areas, database security is not one of them. It is critical that the DBA who is tasked with creating and implementing the policies understands, and can intelligently implement, all aspects of the DB2 security policies. Auditing is another area that requires a robust comprehension of DB2. For these reasons, the database security policies should not be created or implemented until the DBA has a true comprehension of the available DB2 security options.

Using the Plan to Formulate the Policy If the DB2 database security plan is complete, the creation of the DB2 database security policies will be much easier. Yes, it is true that a database security policy can be put in place even though a database security plan was never created. However, creating only the policy without first laying the foundation of the plan leaves the database policy vulnerable. For example, there might not be a corporate sponsor to favor the necessary work effort, organizational “buy-in” would be missing, and database security efforts would not benefit from the strength of different perspectives. That said, if it just is not possible to get a team together and officially write a database security plan, at least writing the database security policy is the next best choice. Plan or no plan, the DB2 database security policies should be written down, not just implemented.

Review, Approve, Implement, Maintain Before sitting down to translate the information from the plan into workable database security policies, a structure should be in place to determine what reviews, approvals, auditing, and policy maintenance are needed. The goal here is to strengthen the process, not impede it. If the corporation has a technology security officer or group, that group should be part of the review, approval, and maintenance process. If no individual or group holds this authority, the CIO or CTO and/or DB2 team lead should be involved. Rather than have numerous levels of authority

36

Chapter 2


involved, the objective is to find the smallest common denominator of personnel with the appropriate level of authority and the ability to do the following: • Review the policies Do they match the objectives of the plan? Are the proposed policies able to be implemented as they are described? Are the appropriate parties tasked with implementing the policies? Are safeguards built in? Is the policy clearly written? Has change management been addressed? • Approve Who has the authority to approve the policies? Are multiple levels of approval desirable? • Implement Identification of personnel to implement Verification of successful implementation Appropriate change management • Audit Validation Quality assurance • Maintain What is the schedule for cyclical review of the policies? Who will maintain the physical security of the policies? Who will be allowed access to the policies? How will be policy itself be distributed and secured? How will changes be managed?

General Guidelines—Building the DB2 Database Security Policies When beginning to create a new DB2 database security policy, a good suggestion is to have a master document that supports all the standards and single or various subdocuments to address the exceptions or differences. This approach may ease regulatory compliance efforts because uniformity across environments will aid auditors as they review for compliance. One direction would be to create a master DB2 database security policy that covers all corporate instances and databases by stating the general, shared policy rules. Then, any exceptions or differences could be detailed separately and incorporated into the policy documents. The master

DB2 Database Security—Create the Policy

37

document might contain items such as the standards and naming conventions for instances and databases or how TCP/IP port numbers for instances are assigned. These are just examples to provide “thought points” for the task of creating the policies. As long as the written policies provide sufficient scope and clarity, the actual form that the final documentation takes is not significant. One major point to consider is how to keep the policies themselves secure. The security plan and policies and their working documents, if made available inappropriately, present a security threat to the organization. If the policies are stored on a network that does not provide sufficient security, for example, they might be compromised and used as a blueprint to devise ways to circumvent all the protections so diligently implemented. Likewise, copies of the security policies or their drafts, left lying on desktops, can be acquired improperly. Keeping the plan and policies secure is just as important as keeping the data itself from falling into the wrong hands. What to Include? The determination of what to include and exclude in the database security policies varies greatly depending on the organizational need. Common to most organizations are items such as naming standards, database-to-storage mappings, application-to-database mappings, and access controls. Beyond those topics, larger organizations typically need to include auditing and encryption, especially if they are under regulatory review. These topics are discussed in general terms here to give some insight on an approach to creating the policies. These topics are indented only to provide a starting point to initiate the process. The successful database security policy at your organization will be unique and a “custom fit” that cannot be easily facilitated by a generic blueprint. Naming Standards The most important considerations for creating naming standards are that 1. They exist. 2. They are not overly complex. 3. They are well documented. 4. They are not so transparent as to aid a hacker. 5. They are enforceable and enforced. Organizations without naming standards cause undue stress for DBAs whether in relation to security or not. It is so much easier, for example, to troubleshoot any security issues with stored procedures if the DBA knows that all stored procedures begin with the prefix SX_ and that they all are stored on a specific file system. If objects suddenly appear to be stored procedures, but do not begin with SX_ and are not on the appropriate file system, the irregularity is more easily discovered if standards are in place and if enforcement has been strict.

38

Chapter 2


Mappings While database, application, and storage mappings exist in most organizations as an aid to administration, the implicit security benefit is not always realized. Mappings can prove invaluable to facilitate identification of irregularities (whether accidental or intentional). If a recovery is required for any reason, you can use mappings to confirm that the environment is restored to the original configuration. Mappings for applications, databases, and storage should be included in the database security policies. Access Controls DB2 offers a rich complement of features that can provide a high level of granularity for enabling access controls. Because a thorough understanding of DB2 access control mechanisms is critical to a secure implementation, these topics are covered in depth in Chapter 5, and Chapter 6, “Label Based Access Control.” Once determined, access control mechanisms should be thoroughly documented in the database security policies. The goal should be a standardization of implementation that can be followed by anyone tasked with the work. The policy should spell out not only the initial implementation, but how to handle subsequent implementations. Auditing Another item for inclusion in the database security policies is auditing. (See Chapter 9, “Database Auditing and Intrusion Detection,” for a detailed discussion.) As you read in Chapter 1, “The Regulatory Environment,” auditing is a requirement for compliance mentioned by HIPAA, Sarbanes-Oxley, and Gramm-Leach-Bliley Acts. Many governmental agencies require an almost 100 percent auditing implementation. If auditing is required, whether natively in DB2 or by some other mechanism, this, too, should be detailed by the database security policies. The broad topics regarding auditing that the policy should (at a minimum) include are as follows: • What is audited? • How often will audit records be reviewed? • What personnel will be tasked with audit review? How will they be vetted or authorized? What technical skills will they need for the tasks? Who will they report to? • What storage media will be used and how will it be secured? • How long do audit records need to be kept? • What is the issue discovery reporting process?

Change Control—Things Are Gonna Change

39

Auditing might not be required for every database environment in the enterprise, but to the extent that it is, it should be well documented in the database security policies. Encryption If your organization is planning to use encryption, the database security policies should address how to determine which data is to be encrypted. It is more important to set standards for encryption rather than just list specifically what is initially encrypted. If the policy states, for example, that Table A, Column B must be encrypted, that provides instruction only for one situation. The policy should go further, setting standards that apply across all data, such as the following: • All names • All Social Security numbers • All dates of birth • All personnel actions • User IDs and passwords • Credit card numbers • Etc. Spelling out this information in the policies is necessary because few applications stay static. As new code is introduced and new database objects are created, the database policies can aid in providing a consistency point for encryption. If the requirement is that all SSNs be encrypted, for example, and the policy only states, “Encrypt all Social Security numbers in the Employee table,” what happens when another table is added that also holds Social Security numbers? With standards such as “All SSNs are encrypted,” there is more assurance that the policy will be effective.

CHANGE CONTROL—THINGS ARE GONNA CHANGE Throughout this chapter, we have been dealing with the “present” as if the “future” were never going to impact the process. Now it is time to realize that the future is not going to be ignored forever. It is highly likely that after the plan has been completed (or maybe before), after the policies have been “inked,” and after that secure database is in place, there will be changes. With any security implementation, there are always ways to improve, which translates into “change.” Then, there are the business changes that occur as a matter of routine for most enterprises. They also spell “change.” We cannot forget, too, that technology will advance, hackers will hack, businesses will acquire businesses, best practices will evolve, and employees will move on. To manage the change that is virtually guaranteed in any thriving enterprise, change control is essential. This is not just change control for the database (although that is essential), but also change control for the security architecture and its relevant documentation. At each step along the way, consider how change is going to be managed.

40

Chapter 2


LAST WORDS STOP

If you do not have executive sponsorship for your secure implementation, stop here and get it now. Without executive sponsorship, the odds of success are slim.

Security plans and database security policies are essential to creating and maintaining a robust security implementation. They must be effectively written, shared with appropriate personnel, updated when appropriate, and protected just as if they were classified data. They serve as documentation for auditors, management, and appropriate staff and will provide foundational guidance for DBAs and IT departments. Of course, every organization is different, and the security plan and database security policy must be tailored for the specific organizational need instead of striving to meet some arbitrary set of requirements. That is why the involvement of the appropriate personnel at the start of the creation process is crucial. These stakeholders should play an active role in the formulation of the plan, and from the plan, it should be easier for the DBAs to formulate the DB2 database security policies. Taking shortcuts by eliminating documentation introduces significant risk. Even if database security is effectively implemented, when documentation is bypassed, it is increasingly likely that normal changes, which inevitably take place as the application changes, will cause security items to be overlooked. With a security plan and DB2 database security policies, this unintentional oversight is less likely.

CHAPTER

3

Understanding Identification and Authentication—The First Line of Defense A n imaginary conversation between the DB2 database and the user ID: DB2:

“Who are you?”

User ID:

“Why, I am me, of course.”

DB2:

“But who can vouch for you?”

User ID:

“Just ask the DBA in the Super-Invisible Cape.”

FIRST WORDS:WHY IS AUTHENTICATION CRITICAL TO DATABASE SECURITY? When a user claims a specific identity, such as entering a user ID, this process is called identification. Authentication is the process by which the claimed user identity is validated. Authentication is the first line of defense for the DB2 database system; it serves as preventive control to stop any unwanted access to the database. The role authentication plays for DB2 is much like that of the firewall for the corporate network. It is there to protect and defend from unjustified access. You can think of authentication as the master lock for a house where business-critical data resides. (Think of the house as the database.) To access the data, one must have a key (authentication information) to unlock the door and gain entry. This assurance that the seeker of the data has the right key for this particular lock helps prevent unwanted access to the data. Imagine instead

41

42

Chapter 3 • Understanding Identification and Authentication—The First Line of Defense

that the door lock is broken or unintentionally left unlocked; then everyone, including the thieves (hacker or business spy), can go in. When the thieves are inside, the risk of a security exposure accelerates dramatically.

OVERVIEW OF THE DEFAULT DB2 AUTHENTICATION MECHANISM Prior to the release of DB2 8.2, authentication was the role of the operating system (or possibly Kerberos on Windows). DB2 assumed that the operating system of the platform it was running on was the definitive location for authentication. The general approach (which may still be used if desired) was to pass the user ID and password to the underlying operating system on the database server for validation depending on settings chosen for the Database Manager Configuration (DBM CFG) parameter. As of DB2 8.2, DB2 has implemented the security plug-in infrastructure whereby authentication is performed by security plug-in libraries that are dynamically loaded by DB2. For those who prefer the status quo, the existing operating system authentication mechanism is still made available via an IBM®-shipped security plug-in. In addition, the Kerberos authentication method (now a plug-in) was made more robust and provides additional platform support, including AIX®, Sun®, and Linux®. Providing even more ability to custom design security, there is the option to design, code, and implement a customized security plug-in to incorporate any authentication method or business logic. This has opened the door for third-party development of security plugins and enabled a virtually unlimited approach to customization of authentication control designs. Figure 3.1 illustrates how the operating system-based security plug-in verifies the user ID and password when the authentication type has been set to SERVER. (This is the default, out-of-thebox setting.) 1. When a user enters the user ID and password on the connect statement, the user ID and password flow to the database server. 2. The database server passes the user ID and password to the security plug-in. The security plug-in calls the operating system application programming interface (API) to validate the user ID and password. 3. The operating system validates the user ID and password and returns the results via the return code of the operating system API. The security plug-in translates the operating system API return code into one of the published security plug-in return codes. The security plug-in return code is returned back to the database server. 4. The database server will deny the user access to the database if the security plug-in return code indicates that the operating system failed to validate the user ID and

Authentication Type

43

password. Otherwise, the group membership plug-in will be loaded to acquire group membership for the user. The database server will then perform connection authorization checking by consulting the system catalog table SYSCAT.DBAUTH to verify whether the user or one of the groups (including the special group PUBLIC) that the user belongs to has the CONNECT privilege to the database. The user will be granted the access to the database if the sufficient CONNECT privilege is present in the system catalog table.

1 Server Side Security Plug-In 4

Database

User

3

2

Operating System

Figure 3.1

Authentication using operating system-based security plug-in

AUTHENTICATION TYPE The Database Manager Configuration parameter AUTHENTICATION is used to control where authentication takes place and what kind of authentication information (whether a user ID and password pair or a credential such as Kerberos ticket) will be used in the authentication process. Because this is an instance-level parameter, the specified authentication type applies to every database defined in the instance. Any connection to one of these databases will attempt to use this authentication type. However, DB2 does provide an option to override the authentication method at the client. The client can specify an optional authentication clause when cataloguing a database

44


to indicate an authentication type that differs from that of the server. After a negotiation process between the client and server, the final “agreed-upon” authentication type will surface or the connection will be refused if the types are not compatible. This negotiation process is discussed in more detail in a later section of this chapter.

What Authentication Type Should I Use? Authentication type selection is one of the key decisions that should be made according to the corporate security policy. Although authentication mechanisms are reconfigurable at any time (via DB2 configuration updates), the best approach is to do the research up front, know the specific options and combination of options available, and understand the technical ramifications and how they relate to specific business needs before starting any work to establish the database and application environments. Applications being deployed should also be understood before choosing an authentication mechanism, because there is no “one size fits all” when it comes to authentication. Does the data flow need to be encrypted? Is the database being accessed remotely, locally, via the Web? Will there be additional authentication beyond that offered by the database? These are all questions that, when answered, aid in establishing the “right” authentication method from the start.

Understanding Authentication—In General Currently, DB2 supports the following types of authentication methods: SERVER; CLIENT; SERVER_ENCRYPT; DATA_ENCRYPT; DATA_ENCRYPT_CMP; KERBEROS; KRB_SERVER_ ENCRYPT; GSSPLUGIN; GSS_SERVER_ENCRYPT. Table 3.1 summarizes the different types of authentication methods supported by DB2. Table 3.1

Authentication Methods Supported by DB2

Authentication Type

Location Where Authentication Occurs

SERVER

Database server.

ID and password are sent in plain text to the database server, where authentication takes place.

CLIENT

Client.

User ID and password are authenticated at the client. Note that this setting is discouraged unless a strong trust between the client and server can be established. This is explained in depth later in this section.

SERVER_ENCRYPT

Database server.

Encrypted user ID and encrypted password are sent to the database server, where authentication takes place.

Description

Authentication Type

45

Authentication Type

Location Where Authentication Occurs

DATA_ENCRYPT

Database server.

Same as SERVER_ENCRYPT, but certain sensitive data flowing between the client and server in the session is encrypted. This is explained in more detail in Chapter 7, “Encryption (Cryptography) in DB2.”

DATA_ENCRYPT_CMP

Database server.

Same as DATA_ENCRYPT with the exception that this authentication type allows compatibility with down-level products not supporting the DATA_ENCRYPT authentication type. These products are permitted to connect with the SERVER_ENCRYPT authentication type and without encrypting user data.

KERBEROS

KDC. (See the “Kerberos —An IBM-Shipped GSS API-Based Security Plug-In” section later in this chapter for more explanation of KDC.)

Using Kerberos authentication type where authentication takes place on a third-party server—KDC.

KRB_SERVER_ENCRYPT

KDC or database server depending on the result of the negotiation between the client and server. (See the section “Authentication Type Negotiation Between the Client and Server.”)

This authentication type supports both KERBEROS and SERVER_ENCRYPT.

GSSPLUGIN

Depends on the implementation of the GSS API-based security plug-in.

Uses GSS API-based security plugin as authentication method.

GSS_SERVER_ENCRYPT

Database server if SERVER_ ENCRYPT authentication type is chosen. Depends on the implementation of the GSS API-based security plug-in if GSSPLUGIN authentication type is chosen.

This authentication type supports both GSSPLUGIN and SERVER_ENCRYPT.

Description

46


If you have two different types of clients, one type supporting Kerberos or GSS API-based authentication mechanisms while the other type does not, the best course of action is to choose either KRB_SERVER_ENCRYPT or GSS_SERVER_ENCRYPT for authentication on the database server. This equips the database server to support two types of authentication mechanisms simultaneously. When one of the two values is specified on the request by the client connection attempt, the database server can actually authenticate the client using either the Kerberos/GSS API-based authentication mechanism or by using an encrypted user ID and password that is authenticated at the server. In general, client authentication is discouraged given this concern: How secure can a client be? Client authentication defeats the goal of centralized security management. If credential management is handled on the client side, a strong trust between client and server must exist. Consider an environment in which lots of laptops can plug into the company network any time. With client authentication, if the internal intruder manages to discover a user ID for one of the DB2 system administrators, all it takes to become a DB2 system administrator is to create a user ID of the same name locally on the laptop and then connect to the database. Because the user ID and password are authenticated on the client, the password does not even need to be the real password used by the administrator. Should I specify an authentication type on the CATALOG DATABASE command? When a database is cataloged on the client, the user is given an option to specify a preferred authentication type for the client to use. It is strongly suggested that the authentication type be set to the same value as the authentication type specified in the Database Manager Configuration on the database server. If the value is not known, the authentication type should not be specified on the CATALOG DATABASE command. A mismatch between the authentication type specified on the CATALOG DATABASE command on the client and the Database Manager Configuration parameter value on the server can prevent the DB2 client from successfully connecting to the database server and cause a failure with the following message: SQL30082N Attempt to establish connection failed with security reason "17" ("UNSUPPORTED FUNCTION"). SQLSTATE=08001

SRVCON_AUTH Database Manager Configuration Parameter If you have worked with the DB2 product for several releases, you might remember that formerly the instance (Database Manager Configuration) parameter AUTHENTICATION determined client and instance-level operation authorization. The term instance-level operation refers to the tasks required to maintain a database instance such as start database manager (db2start) or get Database Manager Configuration (GET DBM CFG). DB2 8.2 addressed the ability to segregate authentication via a new Database Manager Configuration parameter, SRVCON_AUTH. Previously, the parameter AUTHENTICATION had to perform two roles. On one hand, it indicated what authentication type to use to authenticate the client. On

Authentication Type

47

the other hand, it indicated what authentication method to use for instance-level operation authorization. The SRVCON_AUTH Database Manager Configuration parameter enables the administrator to separate these two tasks using different authentication methods. When specified, the SRVCON_AUTH value is used to dictate what authentication type will be used to authenticate the client, whereas the AUTHENTICATION value indicates what authentication method to use for instance-level operations. Why would you want to specify a value in SRVCON_AUTH? One reason becomes obvious if you are using Kerberos. If there is a requirement to authenticate all connections using Kerberos but the user ID and group information for the user performing any instance-level operations is defined locally to the database server, it might be a good idea to set SRVCON_AUTH to Kerberos and AUTHENTICATION to SERVER or SERVER_ENCRYPT. In this way, for any instance-level operation, additional traffic from the database server to the Kerberos Distribution Center (KDC) will be avoided. (Kerberos is explained in a later section in this chapter.) The default value for SRVCON_AUTH is NOT_SPECIFIED, which means that the Database Manager Configuration AUTHENTICATION value will be used. Changing the value for the SRVCON_AUTH parameter is accomplished by updating the Database Manager Configuration for this parameter. Remember to restart the database instance (db2stop and then db2start) for the new value(s) to take effect. In Figure 3.2, the SRVCON_AUTH parameter is shown being set to use the DATA_ENCRYPT authentication method. (see2@jimmy) /home/see2 $ db2 update dbm cfg using srvcon_auth data_encrypt DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

Figure 3.2

Setting the SRVCON_AUTH DBM parameter

Authentication Type Negotiation Between the Client and Server There must be some protocol to allow the client and the server to negotiate an authentication type. DB2 uses an open standard architecture called Distributed Relational Database Architecture (DRDA®). DRDA is a set of protocols to enable users to access distributed data, regardless of where it physically resides in an open and robust heterogeneous distributed database environment. The role DRDA plays for DB2 is much like that of the TCP/IP protocol for the network. If you want to gain in-depth knowledge about this topic, you can find the DRDA specifications in open group websites (www.opengroup.org/publications/catalog/c812.htm, www.opengroup. org/publications/catalog/c813.htm, www.opengroup.org/publications/catalog/c814.htm). You can find a simple tutorial at www.dbazine.com/db2/db2-mfarticles/mullins-drda. The DRDA protocol requires that a client must specify an authentication type when initiating a communication session with the server. Thus, DB2 extracts the authentication type from the database catalog AUTHENTICATION value that was specified when the catalog database command was issued.

48


Before reviewing the negotiation steps, consider the idea of a hybrid (either/or) authentication type. KRB_SERVER_ENCRYPT and GSS_SERVER_ENCRYPT are both supported hybrid authentication types. The KRB_SERVER_ENCRYPT authentication type provides the mechanism to allow the server to authenticate the client with either Kerberos security or the encrypted user ID/encrypted password combination. With the GSS_SERVER_ENCRYPT authentication type, the server can authenticate a client with either the GSS API-based security mechanism or an encrypted user ID/encrypted password combination. To avoid complication during the negotiation process, the client should specify an authentication type during database cataloguing if possible. The actual negotiation flow between the client and the database server is performed by DB2 internally, with errors returned whenever the negotiation fails. In the case where the authentication type is not specified when the database is cataloged on the client, DB2 chooses SERVER_ENCRYPT or CLIENT authentication as the initial “trial” authentication type depending on whether the user ID and password are specified. If the user ID and password are specified on the connect statement, DB2 initially picks the SERVER_ENCRYPT authentication type; otherwise, it picks the CLIENT authentication type. The authentication type is sent as part of the first DRDA flow to the database server. The database server looks at its Database Manager Configuration parameter AUTHENTICATION or SRVCON_AUTH to decide whether the authentication type proposed by the DB2 client is acceptable. If it is acceptable, the database server accepts the proposed authentication type and continues the authentication protocol steps; otherwise, the database server rejects the proposed authentication type and sends a list of server-supported authentication types it can accept back to the client. When the client receives the list of server-supported authentication types, it will first check whether the original authentication type was not specified. If not, meaning the CATALOG DATABASE command has specified an authentication type, the client terminates the attempt and returns the following message to the user: SQL30082N Attempt to establish connection failed with security reason "17" ("UNSUPPORTED FUNCTION"). SQLSTATE=08001

If the authentication type was not specified, the client checks the list of server-supported authentication types to see whether one of the types can be used by the client. An example of this is when the authentication type specified at the server is KRB_SERVER_ENCRYPT while the client has not specified any authentication type initially. Table 3.2 shows the information exchange between the client and server.

Authentication Type

49

Table 3.2 Authentication Type Negotiation Scenario 1

Steps

DB2 Client

1

Catalog the database without authentication type.

2

A connect statement is issued without user ID and password specified.

3

Picked CLIENT authentication as initial value.

4

Communication Flow Direction

➔ Client authentication

Server receives the request to use CLIENT authentication and checks the DBM CFG to see whether it is valid.

➔ List of server supported values: Kerberos authentication

Database server decides that

SERVER_ENCRYPT

authentication

4

Client acknowledges that the server has rejected its proposed authentication type and looks for the list of server supported values.

5a

Client determines it can handle Kerberos.

DB2 Database Server

➔ Kerberos authentication

KRB_SERVER_ENCRYPT and CLIENT authentication

are incompatible. Database server will reject the proposed authentication type and send a list of server supported authentication types (for example, Kerberos, server_encrypt) it can accept back to the client.

Server receives the request to use Kerberos authentication and checks the DBM CFG to see that it is okay to use. The authentication for this connection is based on the Kerberos mechanism. (continues)

50


Table 3.2 Authentication Type Negotiation Scenario 1 (Continued)

Steps

DB2 Client

5b

Client determines it cannot handle Kerberos. Client then proceeds to see whether it can use SERVER_ENCRYPT. Unfortunately, the user ID and password are not available, and therefore the client will terminate the attempt and return an error,


DB2 Database Server

SQLCODE -30082 reason code 17.

If the preceding scenario were modified slightly (with the user specifying the user ID and password on the CONNECT statement), the steps would change as follows. In this scenario, the authentication type specified on the database server is KRB_SERVER_ENCRYPT (that is, Kerberos SERVER_ENCRYPT). A remote client cataloged a database without specifying that the authentication was Kerberos. When a user attempts to connect to the database from the remote client specifying a user ID and password (user ID and password for the KDC) intending to use Kerberos authentication, the connection attempt might fail with this: SQL30082N Attempt to establish connection failed with security reason "24" ("USERNAME AND/OR PASSWORD INVALID"). SQLSTATE=08001

What happened? When a remote client attempts to connect with a user ID and password combination to a database that was not cataloged with a specific authentication type, the DB2 client sends out a request to the server to use the default authentication method, SERVER_ENCRYPT. Because the server actually accepts the SERVER_ENCRYPT authentication type, the server assumes that the client has submitted a user ID and password to be validated by the operating system on the database server. As expected, this causes an error if the user ID and password are not actually defined on the underlying operating system of the database server. To avoid this situation, the authentication type must be specified during the CATALOG DATABASE command on the client. Alternatively, if the user ID/password combination does match with the values on the database server, the connection will succeed. Table 3.3 shows details on the information exchange between the client and server:

Authentication Type

Table 3.3

51

Authentication Type Negotiation Scenario 2

Steps

DB2 Client

1

Catalog the database without specifying any authentication type.

2

A CONNECT statement is issued with user ID and password specified.

3

Picked SERVER_ENCRYPT authentication as initial value.


➔ SERVER_ENCRYPT

authentication

4

DB2 Database Server

Server receives the request to use client authentication and checks the DBM CFG to see whether it is valid. The database server proceeds. It assumes that the client’s intent was to use the server’s operating system to perform authentication.

➔

5a

SERVER_ENCRYPT

authentication accepted and proceed with the connection

➔ Invalid user ID and/or password

5b

6a

The client is authenticated with SERVER_ENCRYPT.

6b

The client will terminate the connection attempt and return SQLCODE -30082 reason code 17.

If the user ID and password are the same for both the a Kerberos KDC and database server’s operating system, the underlying operating system will successfully validate the user ID and password. The connection will succeed. (See Step 6a.) If the user ID and password are different between the Kerberos KDC and the database server’s operating system, the validation will not succeed, and an error will be returned. (See Step 6b.)

52


Specifying Authentication Type on the DB2 Connect Gateway You might optionally specify an authentication type when issuing the CATALOG DATABASE command on the DB2 connect gateway so that it will apply for all connections passed through the gateway. Changing the authentication type on a limited number of gateways may be substantially less work than changing it for all clients, especially in a large enterprise. If the authentication type cataloged at the gateway is not specified (NOTSPEC), DB2 defaults to SERVER authentication as the outbound authentication type from the gateway. However, if the server rejects SERVER authentication (for example, consider a DB2 server that is using SERVER_ENCRYPT), DB2 will attempt to match the server rejection with what the client sent. If the authentication type cataloged at the gateway is a value other than NOTSPEC, the outbound authentication type from the gateway will be whatever is specified on the gateway. In effect, the authentication type cataloged at the gateway acts as a filter that limits the authentication types allowed through. If the value specified on the gateway does not match with the server, the database server will reject the proposed authentication type and send back a list of “server-supported” authentication types. The DB2 connect gateway will terminate the connection when the server rejects the gateway proposed authentication type and will return the following error to the DB2 client: SQL30082N Attempt to establish connection failed with security reason "17" (“UNSUPPORTED FUNCTION"). SQLSTATE=08001

To avoid connection errors, it is strongly suggested that the gateway authentication type match the authentication type on the server unless it is NOTSPEC. There is one exception to this discussion. In the case of a multiple-partitioned database (DPF) where the client has set the DB2NODE registry variable to specify a specific connection partition (known as the Coordinator NODE) for connection attempts, the client will connect to the cataloged node but hop from there to the indicated node. In this scenario, DB2 will not use the authentication type cataloged at the gateway; the negotiation will be purely between the client and the server.

How to Determine the Authentication Type Used for a Connection At statement completion time for all SQL statements, a SQL Communications Area (SQLCA) data structure is returned to the application. If you dump out the SQLCA for the CONNECT statement (if you are using the DB2 command-line processor, you can issue your CONNECT statement with the -a option. See the example in Figure 3.3), the SQLERRD (5) field of the SQLCA returns the authentication type of the connection. The value is one of the following: 0

Authenticated on the server

1

Authenticated on the client

2

Authenticated using DB2 Connect

3

Authenticated using Distributed Computing Environment security services

4

Authenticated on the server with encryption

5

Authenticated using DB2 Connect with encryption

Introduction to Security Plug-Ins

53

6

Authenticated using Distributed Computing Environment security services or on the server with encryption

7

Authenticated using external Kerberos security mechanism

8

Authenticated using external Kerberos security mechanism or on the server with encryption

9

Authenticated using external GSS API plug-in security mechanism Authenticated using external GSS API plug-in security mechanism or on the server with encryption

10

Authentication not specified

255

In Figure 3.3, notice the SQLCA information. The SQLCA indicates a successful authentication to a database called kevins by a user newton using SERVER authentication. (That is, the SQLERRD fifth field is 0.) (see@jimmy) /home/see2 $ db2 –a connect to kevins user newton using R Database Connection Information Database server SQL authorization ID Local database alias

= DB2/6000 8.2.5 = NEWTON = KEVINS

SQLCA Information sqlcaid : sqlerrmc: sqlerrp : sqlerrd :

SQLCA sqlcabc: 136 sqlcode: 0 sqlerml: 44 ¨ ¨ ¨ ¨ ¨¨¨¨ ¨¨ 1y819yNEWTON yKEVINSyQDB2/6000y7y7y0y819y0y SQL08025 (1) 1 (2) 1 (3) 0 (4) 1 (5) 0 (6) 0 sqlwarn : (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) sqlstate:0000

Figure 3.3

Finding authentication type information in the SQLCA

INTRODUCTION TO SECURITY PLUG-INS In response to the increased need for state-of-the-art, up-to-the-moment flexible authentication architectures, DB2 security plug-ins were introduced. Security plug-ins are dynamic loadable libraries that DB2 invokes when performing authentication or group membership lookup. Security plug-ins are implemented at the instance level, and, therefore, a database within the instance will use the same set of security plug-ins.

54


Why Did DB2 Implement the Security Plug-In Architecture? By implementing the authentication and group membership lookup as a loadable security plug-in architecture, DB2 acquires a major flexibility and extensibility gain. It allows DB2 to deliver any new security authentication method quickly and make it release independent. For example, should DB2 decide to deliver a new security plug-in in release x+2, in general, the security plug-in can be copied to a DB2 client and server that are running on an earlier release (release x) that already supports the security plug-in architecture if the required Database Manager Configuration parameter is updated. The down-level DB2 client and DB2 server can also take advantage of the new security plug-in. By making APIs for security plug-in public, you have the flexibility of implementing your own security mechanisms and implementing your unique business logic requirement into the security plug-in. You can choose to build the security plug-in in-house or look to vendors or consultants to help implement your customized security plug-ins. Three factors of information can be used for authentication: • Factor 1 is something you know, such as a password or a PIN. • Factor 2 is something you have, such as an ATM card or a smart card. • Factor 3 is something you are, such as a fingerprint or retina scan. Authentication using only one factor of information is weak in protection. You may now implement a two-factor authentication by writing a customized security plug-in that communicates with smart card servers to authenticate a user entering a password displayed by the smart card (something that user has) after the user enters the PIN to the smart card (something that user knows). Because the smart card password is valid only for a short time, a replay attack should not be possible. An example of a smart card is the RSA® Smart Card 5200.

Type and Categories of Security Plug-Ins There are two categories of security plug-ins: authentication plug-ins (referred to here as an auth plug-ins) and group membership lookup plug-ins (referred to here as group plug-ins). They serve the purpose of authentication and group membership lookup for DB2. There are two types of auth plug-ins: • Client-side or server-side user ID/password-based auth plug-in • Client-side or server-side GSS API-based auth plug-in User ID/password-based auth plug-in implies that a user and password are used for authentication checking. This is easier to implement but is less flexible because only user IDs and passwords are used for authentication purposes, and there can only be one user ID/password-based auth plug-in on the client or the server. You can have more than one user ID/password-based auth


55

plug-in available in the directory, but the Database Manager Configuration parameters to enable it will accept only one name. The related Database Manager Configuration parameters are explained later in this chapter. It is not necessary to have both the client-side and the server-side customized auth plug-ins implemented. For example, if you use only SERVER or SERVER_ ENCRYPT authentication and do not require the Remap User ID feature on the client-side auth plug-in, you do not need a client-side customized auth plug-in on the DB2 client because all the authentication-related operations will be done on the database server. In this case, a server-side customized auth plug-in will suffice. GSS API-based auth plug-ins require a reasonable knowledge of the Generic Security Service application programming interface (GSS API) standard Version 2. This standard is documented in RFC 2743 (www.ietf.org/rfc/rfc2743.txt) and RFC 2744 (www.ietf.org/rfc/rfc2744.txt). GSS API is a generic API used to perform client/server authentication with credentials such as Kerberos tickets or Public Key Infrastructure (PKI) certificates. Its purpose is to address the issue of the similar, but incompatible, security services in use. When you implement the authentication mechanism using GSS API, the implementation should, in theory, be interoperable with various other security mechanisms. DB2 has implemented its Kerberos support by rewriting it as a GSS API-based auth plug-in. SPKM (Simple Public Key Mechanism) and LIPKEY (a Low Infrastructure Public Key mechanism using SPKM) that uses PKI are other examples of security mechanisms that you could implement using a GSS API-based auth plug-in. One advantage of the GSS API-based auth plug-in is that any authentication information, including binary information, can be transmitted between the client and server multiple times to complete the authentication process. GSS API-based auth plug-ins normally require authentication-related work to be done on both sides, and, therefore, a comparable version of the GSS API auth plug-in should be available at both the DB2 client and database server. Unlike user ID/password-based auth plugins, there can be more than one GSS API-based plug-in on either the DB2 client or the DB2 server. On the DB2 server, it is possible to specify a list of GSS API-based plug-ins in a preferred order. This list is sent to the client, and the client goes through the preferred order to find the first one that is available to the client on the list. Figure 3.4 shows four different DB2 clients that have different sets of GSS API-based plug-ins implemented and copied into the correct location. The DB2 server has a list of server-supported GSS API-based plug-ins specified in the DBM CFG srvcon_gssplugin_list in the preferred order. When client 1 connects to the server, the server returns the ordered list, and then goes through the server’s list of plug-ins in the specified order from left to right until it finds the one that is also found in the client security plug-in directory, and then selects it and communicates with the server to use the selected one. As a result, client 1 will use SPKM, client 2 will use LIPKEY, and client 3 will use SPKM. Client 4 will not be able to find one that matches the list, and, therefore, an error (SQLCODE -30082 reason code 32) is returned because there is no matching GSS API plug-in between this client and the database server.

56


DB2 Client #1 sqllib/security/plugin/client krb5.dll lipkey.dll spkm.dll

DB2 Client #2 sqllib/security/plugin/client krb5.dll lipkey.dll Database DB2 Client #3 sqllib/security/plugin/client

dbm cfg srvcon_gssplugin_list= spkm, kipkey

spkm.dll

DB2 Client #4 sqllib/security/plugin/client

racf.dll

Figure 3.4

Supporting multiple GSS API-based security plug-ins

Before writing a GSS API-based auth plug-in, the plug-in writer should have a good understanding of GSS API concepts and the APIs. You can find an overview of the GSSAPI at www.gnu.org/ software/gss/manual/html_node/GSS_002dAPI-Overview.html.

IBM-Shipped Default Plug-In IBM currently ships, by default, a client-side operating system–based auth plug-in (IBMOSauthclient), a server-side operating system–based auth plug-in (IBMOSauthserver), an operating system–based group plug-in (IBMOSgroup), and on the supported platforms, a Kerberos-based auth plug-in (IBMkrb5). Figure 3.5 shows the list of the IBM-shipped security plug-ins on the AIX platform.


$ ls 1s –R1 total 3 drwxr–xr–x 2 see build 201 Jun 27 11:58 drwxr–xr–x 2 see build 145 Jun 27 11:58 drwxr–xr–x 2 see build 201 Jun 27 11:58 ./client: total 2 drwxr–xr–x 1 see build 54 Jun 27 11:58 /../../../../common/lib/RS6000_64L/IBMOSauthclient.a drwxr–xr–x 1 see build 46 Jun 27 11:58 ./../common/lib/RS6000_64L/IBMkrb5.a

57

client group server

IBMOSauthclient.a–>.. IBMkrb5.a–>../../../.

./group: total 1 lrwxr–xr–x 50 Jun 27 11:58 IBMOSgroups.a–>../../ 1 see build ../../../common/lib/RS6000_64L/IBMOSgroups.a ./server: total 2 lrwxr–xr–x 54 Jun 27 11:58 IBMOSauthserver.a–>.. 1 see build /../../../../common/lib/RS6000_64L/IBMOSauthserver.a 1 see build 46 Jun 27 11:58 IBMkrb5.a–>../../../. lrwxr–xr–x ./../common/lib/RS6000_64L/IBMkrb5.a

Figure 3.5

List of IBM-shipped security plug-ins on the AIX platform

In the summer of 2006, IBM delivered a client-side Lightweight Directory Access Protocol (LDAP)-based auth plug-in, a server-side LDAP-based auth plug-in, and an LDAP-based group plug-in via the Web for customer download at www14.software.ibm.com/webapp/iwm/web/ preLogin.do?lang=en_US&source=swg-dm-db2ldap.

Client-Side Auth Plug-Ins on the Database Server The client-side auth plug-in needs to be installed on both the client and the server. The reason is that for local authorization (that is, authorization checking for instance-level operations such as db2start or db2trc), the plug-in that DB2 uses is the client plug-in on the database server. Therefore, you should have a client-side auth plug-in installed on your server that matches the type specified in the Database Manager Configuration parameter AUTHENTICATION. For example, if you have a database server where AUTHENTICATION is specified as Kerberos, you need to ensure the DBM CFG parameter CLNT_KRB_PLUGIN is set to either IBMkrb5 (IBMsupplied Kerberos plug-in) or the name of your customized Kerberos-based plug-in (either thirdparty vendor supplied or in-house built). You must also ensure that the Kerberos plug-in is installed into the client plug-in directory on the database server. Otherwise, instance-level operations such as db2start will fail with either SQLCODE of -1365 or SQLCODE of -1366.

58


Authorization ID Versus User ID Authorization ID is an internal ID representing an individual or group to which authorities and privileges within the database are granted. After a user has been authenticated, DB2 no longer uses the user ID or password for further checking (that is, authorization or privilege checking); instead, DB2 uses the authorization ID (auth ID). If using any IBM-shipped security plug-ins, the auth ID is always the uppercase version of the user ID. For a customized security plug-in, a user can choose to return a different value via the security plug-in API db2secGetAuthIDs. However, DB2 will uppercase the value. For example, if the API decides to return aBc as an auth ID for the user newton, DB2 will uppercase it to ABC. From this point on, the user newton will be known as ABC auth ID to DB2, and any privilege or authority checking will be made against ABC. There is a second type of authorization ID known as group auth ID. Group auth IDs refer to the list of uppercase auth IDs generated from the group membership list of the user. During the processing of the CONNECT statement, the group membership lookup will be performed right after authentication. A list of groups that a user is a member of is returned to DB2 via the group plugin API db2secGetGroupForUser. This list of groups is then uppercased and becomes the user’s group auth IDs. Group auth IDs are used for privilege or authority checking, with some exceptions. The exceptions and more details about different type of authorization IDs are discussed in Chapter 5, “Authorization—Authority and Privilege.”

Roles of the Different Categories of Security Plug-Ins A server-side auth plug-in (GSS API-based or user ID/password-based) performs authentication on the database server for incoming connection requests. It is also used to check whether an authorization ID is known to the plug-in. A client-side auth plug-in (GSS API-based or user ID/password-based) performs authentication on the DB2 client. It is also used to perform instance-level local authorization on the database server when instance-level commands, such as db2start, are executed. A group plug-in performs group membership lookup on both the client and the database server. It is also used to check whether an authorization ID is known to the plug-in.

DB2 Security Plug-In APIs The DB2 security plug-in APIs are fully covered in DB2 documentation, and DBAs, independent vendors, and developers can refer to the documentation when implementing a security plug-in. Figures 3.6, 3.7, and 3.8 outline the purpose of the APIs for the group plug-in, client-side auth plug-in, and server-side auth plug-in.


59

Group Plug-in Generate Group List for AUTHID

GROUP PLUG-IN

Check if group exists for an AUTHID.

Figure 3.6

Group membership lookup plug-in

Client-side Plug-in Identification and Authentication Get user name from default login context.*

Validate Password Userid/Password Only

Mutual Authentication

Remap userid/password CLIENT PLUGIN

Get default credential Handle. *

Generate a service ticket.

Process service principal name. *Implicit authentication or for local authorization

Figure 3.7

Client-side auth plug-in

Generate initial credentials.

GSS-API only

60


Server-side Plug-in Identification and Authentication

Userid/Password Only

Process Connection Details

Validate Password

Authorization ID Mapping

Report service principal name CLIENT PLUG-IN

Obtain Server credential handle.

GSS-API Only

Figure 3.8

Check if user exists for an AUTHID.

Process Service Tickets

.Generate mutual authentication t.oken

Server-side auth plug-in

GSS APIs In addition to the set of required DB2 security plug-in APIs, you also need to implement the following list of GSS APIs to complete a GSS API-based security plug-in. • List of client-side APIs gss_init_sec_context

Initiates a security context with a peer application

• List of server-side APIs gss_accept_sec_context

Accepts a security context initiated by a peer

application • List of common APIs on both the client side and server side gss_delete_sec_context

Deletes an established security context

gss_display_status

Converts a GSS API status code to text

gss_release_buffer

Deletes a buffer


61

Releases local data structures associated with a GSS API

gss_release_cred

credential Deletes internal format name

gss_release_name

• List of required types and structures (All types and structures are defined in the gssapiDB2.h header file in sqllib/include.) Structure to hold arbitrary length data, including character strings

gss_buff_desc gss_buffer_t

Pointer to gss_buffer_desc structure Opaque data type that identifies the credential data structure

gss_cred_id_t gss_ctx_id_t

Opaque data type that identifies one end of the GSS API security

context gss_name_t

Opaque data type that points to the internal representation of a principal

name OM_uint32

32-bit unsigned integer

• List of required definitions (All definitions are defined in the gssapiDB2.h header file in sqllib/include.) Delegation requested

GSS_C_DELEG_FLAG

Signifies that the gss_buffer_desc does not contain any data

GSS_C_EMPTY_BUFFER

Indicates a GSS major status code

GSS_C_GSS_CODE

Indicates that mechanism does not support context expiration

GSS_C_INDEFINITE

Indicates a GSS minor status code

GSS_C_MECH_CODE

Mutual authentication requested

GSS_C_MUTUAL_FLAG

GSS_C_NO_BUFFER Signifies that the gss_buffer_t variable does not point to a valid gss_buffer_desc structure GSS_C_NO_CHANNEL_BINDINGS GSS_C_NO_CONTEXT

No communication channel bindings

Signifies that the gss_ctx_id_t variable does not point to a

valid context GSS_C_NO_CREDENTIAL

Signifies that gss_cred_id_t variable does not point to a

valid credential handle Signifies that the gss_name_t variable does not point to a valid

GSS_C_NO_NAME

internal name GSS_C_NO_OID

Use default authentication mechanism

GSS_C_NULL_OID_SET GSS_S_COMPLETE

Use default mechanism

API completed successfully

GSS_CONTINUE_NEEDED Processing is not complete and the API must be called again with the reply token received from the peer

62


Security Plug-In-Specific Database Manager Configuration Parameters (DBM CFG Parameters) Security plug-in specific Database Manager Configuration parameters include those listed in Table 3.4. Table 3.4

Security Plug-In-Specific Database Manager Configuration Parameters

Name of the DBM CFG Parameter

Description

SRV_PLUGIN_MODE

Indicates whether authentication plug-ins run in a separate process. The only value supported currently is the default, UNFENCED.

GROUP_PLUGIN

Name of the group management plug-in library. If blank, the DB2-supplied OS-based group plug-in is used.

CLNT_PW_PLUGIN

Name of the client-side password authentication plug-in. If blank, this defaults to the DB2-supplied OS-based plug-in. Functions in this plug-in will also be used for connection if CLIENT authentication is used for the connection and local instance-level actions if the AUTHENTICATION parameter is set to SERVER, CLIENT, SERVER_ENCRYPT, DATA_ENCRYPT, or DATA_ENCRYPT_CMP.

CLNT_KRB_PLUGIN

Name of the client-side Kerberos plug-in. If blank, it is assumed that no Kerberos support is available. This plug-in will also be used for a connection if Kerberos authentication is used for the connection and local instance-level actions; so if the AUTHENTICATION parameter is set to KERBEROS or KRB_SERVER_ENCRYPT, this must be filled. On Windows platforms, this is filled with IBMkrb5 by default.

LOCAL_GSSPLUGIN

Name of the GSS API plug-in to be used for instance-level identification. Cannot be blank if AUTHENTICATION is set to GSSPLUGIN or GSS_SERVER_ENCRYPT.

SRVCON_PW_PLUGIN

Name of the server-side password authentication module that will be used for database connections and instance attachments. If blank, it defaults to the DB2-supplied OS-based plug-in.

SRVCON_GSSPLUGIN_LIST

Comma-separated list of the names of all GSS API-style plug-ins that the server can support. This list should be ordered by preference, with the most preferred plug-in first. This list will be used when SRVCON_AUTH is set to KERBEROS, KRB_SERVER_ENCRYPT, GSSPLUGIN, or GSS_SERVER_ENCRYPT.


63

The following is the output for the GET DATABASE MANAGER CONFIGURATION command when all parameters are set to their default values (out of the box): Client Userid/password Plugin (CLNT_PW_PLUGIN) = Client Kerberos Plugin (CLNT_KRB_PLUGIN) = Group Plugin (GROUP_PLUGIN) = GSS Plugin for Local Authorization (LOCAL_GSSPLUGIN) = Server Plugin Mode (SRV_PLUGIN_MODE) = UNFENCED Server List of GSS Plugins (SRVCON_GSSPLUGIN_LIST) = Server Userid/password Plugin (SRVCON_PW_PLUGIN) = Server Connection Authentication (SRVCON_AUTH) = NOT_SPECIFIED Database manager authentication (AUTHENTICATION) = SERVER

Enabling Security Plug-Ins If you are using only an operating system for your authentication and group membership lookup, it is not necessary to perform any of the following steps. The default values will handle the backward-compatibility. The only database manager configuration parameters that you might need to modify are SRVCON_AUTH and AUTHENTICATION to allow you to use a different authentication type for connection- versus instance-level authorization. The following four tables show a step-by-step guide to enable different types of security plug-ins on the client or the database server. The Kerberos plug-in can be enabled either as Kerberos authentication type or GSSPLUGIN authentication type. The determining factor is whether your client or server wants to support more than one type of GSS API-based security plug-in (only one of them can be Kerberos); you should use the GSSPLUGIN authentication plug-in enablement method. Table 3.5

1

Enabling User ID/Password Authentication Plug-Ins Steps on the Client

Steps on the Server

Place plug-in library in client plug-in directory. This step is not necessary if you are using the IBM-shipped operating system client-side authentication plug-in.

Place the plug-in in the server plug-in directory. This step is not necessary if you are using the IBM-shipped operating systembased server-side authentication plug-in.

Update CLNT_PW_PLUGIN with the client plug-in name.

Update SRVCON_PW_PLUGIN with the server plug-in name.

If CLNT_PW_PLUGIN is left blank, it will default to the IBM-provided plug-in, IBMOSauthclient. If you do not use CLIENT authentication and do not require the remap user ID feature on the client-side auth plug-in, this step is not necessary, and nothing is required on the client. (continues)

64

Table 3.5


Enabling User ID/Password Authentication Plug-Ins (Continued) Steps on the Client

2

Steps on the Server Set SRVCON_AUTH to a system authentication type (that is, CLIENT, SERVER, SERVER_ENCRYPT, DATA_ENCRYPT, and DATA_ENCRYPT_CMP). or Set SRVCON_AUTH to NOT_SPECIFIED and set authentication to a system authentication type. If SRVCON_PW_PLUGIN is left blank, it defaults to the IBM-provided plug-in, IBMOSauthserver.

Table 3.6

1

Table 3.7

Enabling Group Membership Lookup Plug-Ins Steps on the Client

Steps on the Server

Place plug-in library in client plug-in directory. This step is not necessary if you are using the IBM-shipped operating system group plug-in.

Place the plug-in in the server plug-in directory. This step is not necessary if you are using the IBM-shipped operating systembased group plug-in.

Update GROUP_PLUGIN with the name of the group plug-in.

Update GROUP_PLUGIN with the name of the group plug-in.

If GROUP_PLUGIN is left blank, it defaults to the IBM provided plug-in, IBMOSgroups.

If GROUP_PLUGIN is left blank, it defaults to the IBM-provided plug-in, IBMOSgroups.

Enabling GSS API Authentication Plug-Ins Steps on the Client

Steps on the Server

1

Place the plug-in library in the client plug-in directory.

Place the plug-in in the server plug-in directory.

2

Optional: Catalog a database indicating that the client will use only a GSS API plug-in for authentication (for example,

Update SRVCON_GSSPLUGIN_LIST with an ordered list of supported plug-in names. Then, you should enable the GSSPLUGIN authentication mechanism by either.

db2 catalog db testdb at node testnode authentication gssplugin).


65

Steps on the Client

Steps on the Server

Multiple plug-ins may exist on the client. In this case, the server dictates which one is used.

Setting SRVCON_AUTH to a GSSPLUGIN or Setting SRVCON_AUTH to NOT_SPECIFIED and AUTHENTICATION to GSSPLUGIN To perform local authorization: Place the client plug-in library in the client plug-in directory. Update LOCAL_GSSPLUGIN with the name of this plug-in.

Table 3.8

Enabling Kerberos Plug-Ins Steps on the Client

Steps on the Server

1

Place the plug-in library in the client Place the plug-in in the server plug-in directory. plug-in directory. This step is not necessary This step is not necessary if you are using the if you are using the IBM-shipped Kerberos IBM-shipped Kerberos plug-in. plug-in.

2

Update CLNT_KRB_PLUGIN with the name of the Kerberos plug-in.

Update SRVCON_GSSPLUGIN_LIST with the server Kerberos plug-in name.

If blank, DB2 assumes that the client is incapable of using Kerberos. The default Kerberos plug-in provided by DB2 is named IBMkrb5. For platforms supporting Kerberos, the IBMkrb5 library will already be present

in the client plug-in directory. 3

Optional: Catalog a database indicating that the client will use the Kerberos plug-in for authentication (for example, db2 catalog db testdb at node testnode authentication kerberos target principal service/ host@REALM).

Set SRVCON_AUTH to KERBEROS or KRB_SERVER_ENCRYPT. or Set SRVCON_AUTH to NOT_SPECIFIED and set AUTHENTICATION to KERBEROS or KRB_SERVER_ENCRYPT.

66


When Is the Security Plug-In Loaded by DB2? DB2 will load the client-side authentication security plug-in when a connection is issued on the DB2 client. DB2 preloads all the authentication server-side security plug-ins during the START DATABASE MANAGER operation; this is done to improve the performance of a connection. The group membership lookup is loaded whenever group membership information is required on the DB2 client or on the database server. If you are writing a security plug-in, one important piece of information is the fact the security plug-in on the client (including client-side auth plug-in and client-side group plug-in) is loaded with the privileges of the user ID that issued the connect statement or instance-level operation, and it might not have enough privilege to access information such as the password file. The security plug-in on the database server, including server-side auth plug-in and server-side group plug-in, are loaded with the instance owner privileges. Again, it could only access information that instance owners can access but cannot access information such as the password file that requires root access on UNIX or Administrators access on Windows. Thus, it might be necessary to write a separate program such as a daemon that runs with sufficient privileges and has the security plug-in communicate with the program to perform the required checking.

Other Features Available in Customized Security Plug-Ins A number of the new features listed here can be considered by the DBA when implementing customized security plug-ins: • Perform user ID, password and namespace remapping on the client. This is only applicable to user ID/password-based plug-ins. This feature is particular useful in a three-tier system where the Web server and the DB2 client form the middle tier. • Perform auth ID remapping on the server. This feature allows different user IDs to share the same authorization ID on the database server once authenticated. An example of where this feature could be used is when there are employees in a department who have rotating shifts and perform similar tasks every day requiring the same privileges. So, by using this feature, they can all be authenticated independently and can use the privileges associated with the common auth ID to perform their tasks. To find out which employee performed which task and when, DB2 allows the server-side plug-in to return the real name, which is then audited. For more information, refer to the db2secGetAuthid API. • User namespace is supported on all platforms. Two-part user IDs, such as DOMAIN\ user, on the connect statement are now possible. It can help to implement the separation of duties security principle for access control (as discussed in Chapter 5). • Refuse connections based on communication information. This feature can be used when you want to allow only a few IP addresses to be logged in to the database at a particular time.


67

• A simple early intrusion detection can be implemented using a customized plug-in. For example, code logic can be added to db2secValidatePassword API of a user ID/password-based auth plug-in to keep track of a large volume of incorrect user ID and password authentication requests. When this is found, it can then trigger some action such as sending an e-mail to the system administrator or security administrator. If the GSS API-based auth plug-in is used, this logic can be added to gss_accept_ sec_context API. • Implement client operating system–specific logic. If you want your DB2 Windows client to authenticate against a different KDC than the DB2 UNIX or Linux client, you can obtain the client operating system from the client information structure returned from the client information callback function.

The Basic Flow of GSS API and DB2 Security Plug-In API Table 3.9 provides a simplified illustration of the basic client-server flows involved in the GSS API authentication process used by DB2. Note that the tokens are binary data managed and used by the security mechanism, and only the underlying security mechanism is required to interpret them. Table 3.9

DB2 GSS API Authentication Process

Client

Server

1. Obtain client’s initial credentials if necessary (db2secGenerateInitialCreds); otherwise, obtain default login context (db2secGetDefaultLoginContext).

1. The server obtains its principal name and credential handle at plug-in initialization time (db2secServerAuthPluginInit). Note that on the server, plug-ins are loaded and initialized as part of the start database manager operation (db2start).

2. Process server principal name (db2secProcessServerPrincipalName). 3. Obtain credentials to send to server gss_init_sec_context). ➔

4. Verify and accept client credentials (gss_accept_sec_context). Return the mutual authentication token if requested. Note that if there is more information required, step 3 and step 4 can loop multiple times until either client or server has indicated that it will no longer accept more authentication tokens. (continues)

68


Table 3.9

DB2 GSS API Authentication Process (Continued)

Client

Server 5. Obtain the auth IDs for the principal initiating the context (db2GetAuthIDs) and obtain group membership information for the principal by calling group membership plugin (db2secGetGroupsForUser).

6. Perform mutual authentication if required (gss_init_sec_context).

➔

7. Delete context (gss_delete_sec_ context) and clean up by calling gss_ release_buffer, gss_release_ name, and db2secFreeToken. If the user ID and password is explicitly specified, DB2 will also call db2secFreeInitInfo during the cleanup phase.

7. Delete context (gss_delete_sec_ context) and clean up by calling db2secFreeToken. DB2 will also call the group membership plug-in API db2secFreeGroupList to clean up memory allocated during the call to get the group membership.

Figures 3.9 and 3.10 show how the authentication information can flow between the client and server and how either the client or server can stop the loop by returning GSS_S_COMPLETE on the APIs.

Restrictions Imposed on GSS API Plug-Ins by DB2 GSS API is a standard that DB2 supports. However, DB2 imposes restrictions on how the GSS API functions are implemented. Following are some of them: • The default security mechanism is assumed, and, therefore, there is no OID consideration. • The only GSS services requested in gss_init_sec_context () are mutual authentication and delegation. DB2 will request a ticket for delegation but will never use that ticket to generate a new ticket. • Only the default context time is requested. • Context tokens from gss_delete_sec_context () are not sent from the client to the server and vice versa. • Anonymity is not supported. • Channel binding is not supported.


Client GSSAPI plugin

69

DRDA AR

DRDA AS

Server GSSAPI plugin

gss_init_sec_context(NULL) NULL -> ctoken1 GSS_S_CONTINUE_NEEDED

1 - SECCHK (ctoken1)

gss_init_sec_context(stoken2)

2 - SECCHKRM(stoken2)

gss_accept_sec_context(ctoken1) ctoken1—> stoken2 GSS_S_CONTINUE_NEEDED

SECCHKCD(continue)

stoken2 –> ctoken3 GSS_S_CONTINUE_NEEDED

3 - SECCHK(ctoken3)



gss_accept_sec_context(ctoken1) ctoken3 –> stoken4 GSS_S_CONTINUE_NEEDED

SECCHKCD(continue)

stoken4 –> ctoken5 GSS_S_COMPLETE

5 - SECCHK(ctoken5)

gss_accept_sec_context(ctoken5) ctoken5 –> NULL GSS_S_COMPLETE

6 - SECCHKRM(NULL) SECCHKCD(success)

ACCRDG

Figure 3.9 tokens

Multiple flows where the client indicated it will no longer accept more authentication

Client GSSAPI plugin

DRDA AR

DRDA AS

Server GSSAPI plugin

gss_init_sec_context(NULL) NULL -> ctoken1 GSS_S_CONTINUE_NEEDED

1 - SECCHK (ctoken1)



gss_accept_sec_context(ctoken1) ctoken1—> stoken2 GSS_S_CONTINUE_NEEDED

SECCHKCD(continue)

stoken2 –> ctoken3 GSS_S_CONTINUE_NEEDED

3 - SECCHK(ctoken3)

gss_accept_sec_context(ctoken1)



GSS_S_COMPLETE

ctoken3 –> stoken4 SECCHKCD(success)

stoken4 –> NULL GSS_S_COMPLETE ACCRDG

Figure 3.10 tion tokens

Multiple flows where the server indicated it will no longer accept more authentica-

70


KERBEROS—AN IBM-SHIPPED GSS API-BASED SECURITY PLUG-IN Kerberos is one of the key single sign-on solutions on the market. It is based on an open standard. Kerberos is essentially a secure network authentication protocol that employs a system of shared secret keys and is able to provide robust security against impersonation and reply attacks. With Kerberos, passwords are never flown on the wire, and the server and client may authenticate one another (referred to as mutual authentication). A three-tier system is used in which encrypted tickets (provided by a separate server called the Kerberos Key Distribution Center, or KDC for short) are exchanged between the application server and client rather than text user ID and password pairs. These encrypted service tickets (credentials) are understood only by the client and the server, so there is minimal security risk, even in the event that the ticket is intercepted from the network. A client must perform two steps to communicate with a server. The first step is to acquire a “ticket-granting” ticket. This usually occurs when a user logs in to the system and issues the KINIT command to authenticate to the KDC. The second step is to acquire a “session ticket” that can be used to communicate with the server using the ticket-granting ticket. Figures 3.11 and 3.12 show a basic overview of how Kerberos works. Inside a KDC, there are two services and a KDC database. The database contains an entry called a principal and the associated encryption key for each registered user. The encryption key is derived from the user’s input password when it registers with the KDC. The two services are the authentication service (AS) and ticket-granting service (TGS). The authentication service as named is responsible for authenticating a user before giving the initial credential—the TGT. The TGS is responsible for granting tickets. During Kerberos authentication, the following eight steps are performed (the last two only if mutual authentication is requested): 1. Client requests a TGT by authenticating itself to the Kerberos AS via kinit on UNIX and Linux and by logging in to a domain on Windows. 2. The AS sends back the TGT to the client after the user has authenticated successfully. 3. With TGT, the client requests a service granting ticket (that is, session key) to access a server. 4. TGS generates a session key and then sends the key to the client (encrypted using the client’s private key). In addition, the KDC encrypts the session key, along with some information about the client, in the server’s private key (collectively the ticket) and provides it to the client. 5. The client encrypts an authenticator with the session key and sends that, together with the ticket, to the server. 6. The server decrypts the ticket and extracts the session key.

Kerberos—An IBM-Shipped GSS API-Based Security Plug-In

71

1. Request for TGT Client

Figure 3.11

2. KClient{SClient.KDC} + TGT=KKDC{SClientKDC + client info}

KDC

Requesting ticket-granting ticket (TGT)

1. Request for session key to access Server. 2. KClient{SClient,Server} + Ticket=KServer{SClient,Server + client info}

KDC

3. SClient.Server{authenticator} + ticket=KServer{SClient.Server + client info} Client

Figure 3.12

4. (Optional) SClient,Server{timestamp}

Server

Requesting session key and connecting to the server using the session key

7. If the server is requested to do so, it uses the session key to decrypt the authenticator, extract the timestamp from within the authenticator, encrypt the timestamp with the session key, and send it to the client. The return of this encrypted token constitutes the initiation of mutual authentication. 8. The client uses the session key to decrypt the token, and if the timestamp matches that from the authenticator, mutual authentication is considered successful. It is important to understand that Kerberos can perform only authentication, whereas the group membership lookup relies on other mechanisms such as the default server-side operating system–based group plug-in or LDAP group plug-in.

72


Authorization ID Mapping Consideration An authorization ID (auth ID) is derived from the first part of the principal name. For example: see/[email protected] will become SEE. So, the first part of the principal acted like a user ID, and, therefore, it must follow the user ID naming convention for DB2: • Character strings that represent names of database manager objects can contain any of the following: a–z, A–Z, 0–9, @, #, and $. • User IDs and groups may also contain any of the following additional characters when supported by the security plug-in: _, !, %, (, ), {, }, -, ., ^. • User IDs and groups containing any of the following characters must be delimited with quotations when entered through the command line processor: !, %, (, ), {, }, -, ., ^. • The first character in the string must be an alphabetic character, @, #, or $; it cannot be a number or the letter sequences SYS, DBM, or IBM. • User IDs cannot exceed 30 characters on Windows 32-bit operating systems and 8 characters on all other operating systems. • Group IDs cannot exceed 30 characters in length. On Windows platforms, the IBM-shipped Kerberos plug-in (IBMkrb5) assumes the @ character to be the domain separator. Therefore, @ cannot be used as part of the username. A principal name is in one of the two formats: name@REALM or name/instance@REALM. Because the first part of the principal name is used for authorization ID-derivation, it is possible that two principal names from the different Kerberos realms can be mapped to the same auth ID. For example: see/[email protected] and see/[email protected] will be mapped to the same auth ID SEE. It is also possible that two principal names from the same name but different instances map to the same auth ID. For example, see/[email protected]. com and see/[email protected] will be mapped to the same auth ID SEE. Therefore, it is recommended that a unique namespace for the name within all the trusted realms is maintained. This means all principals with the same name (first part of the principal name), regardless of the realm or instance, should belong to the same user.

Customized Kerberos-Based Security Plug-In If you have a need to include business logic or want to take advantage of some of the new features available to customized security plug-ins, you might choose to implement a customized version of the Kerberos-based security plug-in developed in-house or through a vendor. The source code of the UNIX/Linux IBM Kerberos auth plug-in is open to the public. It is located in sqllib/samples/security/plugins/IBMkrb5.c.

The Lightweight Directory Access Protocol (LDAP)

73

IBM-Shipped Kerberos Plug-In (IBMkrb5) IBMKrb5 on Windows platforms takes advantage of Windows native Kerberos support, and it

behaves the same way as earlier releases of DB2. IBMKrb5 on UNIX®/Linux® platforms makes use of the NAS® toolkit (IBM® Network Authenti-

cation Services toolkit, which is based on MIT Kerberos). It is supported only on platforms where the NAS toolkit is available. Starting with DB2 8.2, the supported platforms are AIX® 5.2 or later (32 bit or 64 bit), Solaris® 8 or later (32 bit or 64 bit), and Red Hat® Linux Advanced Server® 3 (Intel 32 bit). Starting on DB2 9, the platforms supported include AIX 5.2 (32 bit and 64 bit), AIX 5.3 (32 bit and 64 bit), Solaris 9 (32 bit and 64 bit), Solaris 10 (32 bit and 64 bit), Red Hat Enterprise Linux Advanced Server 4 (Intel 32 bit and 64 bit), and SUSE® Linux SLES® 9 (Intel 32 bit and 64 bit).

More Information about Kerberos Appendix B, “Kerberos,” briefly explains how to configure your system as a Kerberos environment that is ready for DB2. There is also a brief interoperability explanation between different platforms.

THE LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL (LDAP)—YET ANOTHER IBM-SHIPPED USER ID/PASSWORD-BASED SECURITY PLUG-IN The Lightweight Directory Access Protocol, better known as LDAP, is based on the X.500 standard, but is significantly simpler and more readily adapted to meet custom needs. Unlike X.500, LDAP supports TCP/IP, which is necessary for Internet access. The core LDAP specifications are all defined in RFCs. You can find a complete list of LDAP-related RFCs on the LDAPman RFC page (www.ldapman.org/ldap_rfcs.html). An LDAP directory can store a wide range of heterogeneous data in one tree: e-mail address, user management data, and much more. An LDAP directory is much like a hierarchical database. A well-known hierarchical database is IBM IMS. LDAP directories are heavily optimized for read performance, thus making it a good candidate for authentication and group membership lookup purposes. What the LDAP directories look like is up to your organization’s need. The application that uses these directories needs to be written based on the agreed-upon directories’ design. LDAP provides a way to centralize information on a server, thus making it an attractive identity management tool. Figure 3.13 is a sample LDAP directory tree that can be used to represent user and group information for authentication and group membership lookup purposes.

74

dn: 0=ibm.c=us objectclass: top objectclass: organization o: IBM

dn: ou=Sales.o=ibm.c=us

dn: cn=mgr1,o=ibm.c=us

dn: cn=db2grp,o=ibm,c=us

objectclass: OrganizationUnit ou: IT

objectclass: OrganizationUnit our: Sales

objectclass: groupOfNames cn: mgr1 member: uid=usr1,ou=IT,o=ibm,c=us uid=usr2,ou=Sales,o=ibm,c=us

objectclass: groupOfNames cn: db2grp member:cn=mgr1,o=ibm,c=us

group dn: uid=usr1,ou=IT,o=ibm,c=us

dn: uid=usr2,ou=Sales,o=ibm,c=us

objectclass: inetOrgPerson cn: usr1 sn: db2

objectclass: inetOrgPerson cn: usr2 sn: db2

member

Figure 3.13

A sample LADP directory tree

member

member group

nested group


dn: ou=IT.o=ibm.c=us

The Lightweight Directory Access Protocol (LDAP)

75

The root node is o=ibm, c=us. It means that all the users who belong to the IBM enterprise can be managed in this domain. And ou=IT,o=ibm,c=us is a branch node; it represents a department in IBM and can be used to manage the users in more detail. For example, we can search a user who is in the IT department directly from this branch node, and there is no need to always begin from the root node. Node uid=usr1,ou=IT,o=ibm,c=us is a leaf node that represents a user in DB2; it contains valid information, such as password, for this user. In this tree, there are also two group’s nodes: cn=mgr1,o=ibm,c=us and cn=db2grp,o=ibm,c=us. Both of them can be used in DB2 for authorization. We can assume a manager has a higher authority than a common employee on a salary database. Then, if usr1 and usr2 belong to group mgr1, both of them will have higher access authority on the salary database. On the other hand, cn=mgr1,o=ibm,c=us is a usual group with two members (uid=usr1,ou=IT,o=ibm,c=us and uid=usr2,ou=Sales,o=ibm,c=us), whereas cn=db2grp,o=ibm,c=us is a nested group with a member cn=mgr1,o=ibm,c=us, which is also a group. Using LDAP to perform authentication has a similar flow to that of using the underlying operating system for authentication with the exception that the user information is stored on a third server rather than locally on the database server. Figure 3.14 illustrates the connection flow using LDAP authentication.

1 Server-Side Security Plug-In 4

Database

User

3

2

LDAP Server

Figure 3.14

Authentication using IBM-shipped LDAP-based security plug-in

76


1. When a user enters the user ID and password on the connect statement, the user ID and password are flowed to the database server. 2. The database server passes the user ID and password into the security plug-in. The LDAP auth plug-in uses the supplied user ID and password to perform an LDAP bind against the LDAP server. If the bind succeeds, the user ID and password is validated as being correct. Otherwise, the user ID and password failed the validation. 3. The LDAP auth plug-in validates the user ID and password and returns one of the published security plug-in return codes to the database server. 4. The database server denies the user access to the database if the LDAP auth plug-in return code indicates that it failed to validate the user ID and password. Otherwise, the LDAP group membership plug-in (if group_plugin is set to use the LDAP group plug-in; otherwise, the operating system–based group plug-in will be used) will be loaded to acquire group membership for the user. The database server then checks the system catalog table SYSIBM.SYSDBAUTH to verify whether the user or one of the groups that the user belongs to has CONNECT privilege to the database. The user is granted the access to the database if the sufficient CONNECT privilege is present in the system catalog table. It is best to have Secure Sockets Layer (SSL) for the communication between the DB2 client or DB2 server and the LDAP server because sensitive data, such as user IDs and passwords, is sent over the wire.

IBM-Shipped LDAP Authentication and Group Membership Plug-In Independent of the product release, IBM has delivered a client-side LDAP-based auth plug-in, a server-side LDAP-based auth plug-in, and an LDAP-based group membership lookup plug-in via the Web. To learn how to configure the DB2 client and server and the LDAP server, refer the documentation that is part of the deliverable.

AUTHORING AND IMPLEMENTING CUSTOMIZED SECURITY PLUG-INS There are five steps to create a DB2 security plug-in. The following subsections explain each step in more detail.

Step 1: Include the Security Plug-In Header Files in Your Plug-In db2secPlugin.h and gssapiDB2.h are the two header files needed to implement customized security plug-ins. The gssapiDB2.h header file is needed only if you are building a GSS API plug-in. Figure 3.15 shows the location of the two required header files for implementing security plug-ins on a Windows system.

Authoring and Implementing Customized Security Plug-Ins

Figure 3.15

77

Security plug-in-related header files

Step 2:Write the APIs Constituting Your Plug-In Implement all the required APIs based on the type and categories of the security plug-in. The set of required APIs are well documented in DB2 documentation (and in the header file listed in Step 1). Initialization APIs for each type of plug-in return the set of function pointers for the rest of the implemented APIs. Listing 3.1 shows a sample implementation of db2secServerAuthPluginInit API for a user ID/password-based auth plug-in. Listing 3.1

Security Plug-In Initialization API

SQL_API_RC SQL_API_FN db2secServerAuthPluginInit( db2int32 version, void* server_fns, db2secGetConDetails* getConDetails_fn, db2secLogMessage* logMessage_fn, char** errormsg, db2int32* errormsglen) { struct userid_password_server_auth_functions_1 *fns = (struct userid_password_server_auth_functions_1*) server_fns; condetails_fn = getConDetails_fn; logMessage_Fn = logMessage_fn;

(continues)

78

Listing 3.1


Security Plug-In Initialization API (Continued)

fns->version = DB2SEC_API_VERSION; fns->plugintype = DB2SEC_PLUGIN_TYPE_USERID_PASSWORD; fns->db2secDoesAuthIDExist = &is_user; fns->db2secFreeErrormsg = &free_error_message; fns->db2secFreeToken = &free_token; fns->db2secGetAuthIDs = &getauthids; fns->db2secServerAuthPluginTerm = &terminate_plugin; fns->db2secValidatePassword = &validatePassword; /* Example on how to use logMessage_fn */ /* Will log the init successful information into db2diag.log at DIAGLEVEL 3 */ (logMessage_Fn)(DB2SEC_LOG_WARNING, "db2secServerAuthPluginInit successful", strlen(“db2secServerAuthPluginInit successful")); return DB2SEC_PLUGIN_OK; }

Step 3: Populate the Functions Pointer Structure Before Returning to DB2 The functions pointer returns pointers to all the APIs required for the particular plug-in library that you have implemented. For example, in the case of group plug-ins, it contains pointers to your implementations of the db2secDoesGroupExist, db2secFreeErrormsg, db2secFreeGroupListMemory, db2secGetGroupsForUser, and db2secPluginTerm APIs. Listing 3.2 shows a snippet of how the functions pointer can be populated for the group plug-in library. Listing 3.2

Populating the Function Pointer Structure

fns->version = DB2SEC_API_VERSION; fns->db2secDoesGroupExist = &is_group; fns->db2secFreeErrormsg = &free_error_message; fns->db2secFreeGroupListMemory = &free_group_list; fns->db2secGetGroupsForUser = &get_groups; fns->db2secPluginTerm = &terminate_plugin;

Step 4: Compile the Plug-In Source and Create a Shared Library After you finish coding your security plug-in, compile it as either a 32-bit or 64-bit loadable object to correspond with your DB2 instance. The library created must have the same name as the

Authoring and Implementing Customized Security Plug-Ins

79

plug-in name. Libraries must be shared libraries with the appropriate platform-specific extension. For example, if the name of your plug-in is myPlugin, the following extensions are required: • myPlugin.dll (Windows) • myPlugin.a (AIX) • myPlugin.so (Linux, AIX, Sun Solaris, HP-UX on IA64) • myPlugin.sl (HP-UX on PA-RISC) Libraries must be threading safe (re-entrant) and C linkage must be used (at least for the initialization functions).

Step 5: Place the Library in the Appropriate Directory Security plug-in libraries must be placed in specific directories: • Windows sqllib\security\plugin\\client sqllib\security\plugin\< instance name >\server sqllib\security\plugin\< instance name >\group

For the IBM-supplied default plug-ins sqllib\security\plugin\IBM\client sqllib\security\plugin\IBM\server sqllib\security\plugin\IBM\group

• 32-bit Linux/UNIX sqllib/security32/plugin/client sqllib/security32/plugin/server sqllib/security32/plugin/group

For the IBM-supplied default plug-ins sqllib/security32/plugin/IBM/client sqllib/security32/plugin/IBM/server sqllib/security32/plugin/IBM/group

In Linux/UNIX, similar directories for 64-bit libraries are used as above, except that the subdirectory name security64 is used rather than security32. On Windows 64-bit instances, both 32-bit and 64-bit plug-ins will be in the same directory, but the 64-bit plug-ins will be added with a

80


64 suffix; Using our previous example, the 32-bit plug-in will be myPlugin.dll while the 64-bit plug-in should be named as myPlugin64.dll.

NOTE Plug-ins located under the IBM subdirectory are reserved for the IBM-shipped default plug-ins. Any other customized plug-in placed in this directory will be lost the next time you apply a new Fixpack or release.

CASE STUDY: USING A CUSTOMIZED SECURITY PLUG-IN TO IMPLEMENT THE ABILITY TO CENTRALIZE USER ID AND PASSWORD AND GROUP MEMBERSHIP INFORMATION IN A DATABASE Identity management is costly and error prone because it is a highly manual process, especially when identity management is not centralized. Kerberos and LDAP are the two commonly used centralized repositories for identity. A third approach is to centralize the identity into a database.

Requirement Assume Company X has three different instances: inst1, inst2, and inst3. The company wants to have all user information—user ID, password, and group membership—for all three instances centralized.

Proposed Design A new instance called inst_auth is created for this matter. In this instance, we will create one database called dbauth that contains all the user information such as user ID, password, and authorization ID and group list in one single table. The password stored in the table is a hashed value of the actual password. MD5 and SHA are the well-known fixed-length one-way hashing functions. HAVAL is a variable-length one-way hashing algorithm. Because sensitive data will flow on the wire, the authentication type chosen for this instance, and therefore database dbauth is DATA_ENCRYPT, to ensure that the data and the authentication flow are all encrypted. Table 3.10 shows a proposed layout.

Case Study: Using a Customized Security Plug-In to Implement the Ability to Centralize User ID and Password and Group Membership Information in a Database.

Data

Data

81

Data

Server security plug-in for inst1

Inst_auth

Data

Data Data

Data

Data



Title An external invoked program (can be running daemon) that takes the information flowed from the server security plug-in and compares with the information fetched from the database in inst_auth

Figure 3.16

Using database to centralize the identity management

An administrative application should be designed and implemented. It is needed to perform continuous maintenance of the user information such as adding users, removing users, changing group information, changing passwords, and changing the authorization ID mapping for a user. A customized server user ID/password-based auth plug-in and a customized group membership lookup plug-in should be implemented and installed on the database server where each instance (inst1, inst2, inst3) resides. Any connection to the database in one of the three data instances will use these customized plug-ins because the Database Manager Configuration parameters work on an instance level.

82

Table 3.10

Table - Auth_Info

Unique Index

Check Constraint Ensuring the Number Cannot Be > 3

Char (1)

Integer

Unique Index

Check Constraint Ensuring the Number >=0

Data type

varchar (256)

varchar (256)

Date

Column name

userid

password

pw_expire_date

account_status number_ auth ID of_failed_ login

numGroup groupinfo

Sample row 1

user1

…

2007-0101

N

0

USER1

3

"\006GROUP1\ 007MYGROUP\ 008MYGROUP3"

Sample row 2

newton

…

2006-12-31 E

1

NEWTON

2

"\006GROUP1\ 008MYGROUP2"

Sample row 3

einstein

…

2007-03-12 L

3

EINSTEIN

0

NULL

varchar (256)

Integer

varchar (32672) nullable


Index or Constraint Requirement for the Individual Column

Check Constraint Ensuring Only N, E, or L Can Be Used for This Column (N = Normal, E = Expired, L = Locked Out)


83

An external program, either invoked by the plug-ins or running as a daemon, communicates with the above plug-ins. The task for this external program is to connect to the database dbauth and retrieve information from the table for a given user ID or auth ID.

Detailed Implementation Information Administrative Application The administrative application can be a GUI-based or a text menu–based application. It establishes a connection to the dbauth database (that resides in inst_auth instance) and uses SQL statements to interact with the table auth_info that resides in the database. The following is a list of tasks required: 1. Given a user ID, unlock the user account: db2 "UPDATE AUTH_INFO SET ACCOUNT_STATUS = 'N' WHERE USERID = "

2. Given a user ID, reset the number of failed login attempts: db2 "UPDATE AUTH_INFO SET NUMBER_OF_FAILED_LOGIN = 0 WHERE USERID = "

3. Given a user ID, reset the password and thus automatically update the password expiration date to 90 days after the reset. (This assumes the corporate policy has set password expiration at 90 days.) First, the new password is hashed by using the chosen hashing algorithm. Then issue this: db2 "UPDATE AUTH_INFO SET PASSWORD = WHERE USERID = "

And then this: db2 "UPDATE AUTH_INFO SET PW_EXPIRE_DATE = (CURRENT DATE + 90 DAYS) WHERE USERID = "

There is an alternative for the second update. An update trigger can be created on the column password that automatically updates the pw_expire_date. The syntax to create this trigger is as follows: db2 "CREATE TRIGGER NEW_EXPIRE AFTER UPDATE ON AUTH_INFO(PASSWORD) FOR EACH ROW MODE DB2SQL UPDATE AUTH_INFO SET PW_EXPIRE_DATE = (CURRENT DATE + 90 DAYS)."

4. Create a new user. A simple insert statement will do as long as all the information is formatted to the table layout. Once again, the password is hashed: db2 "INSERT INTO AUTH_INFO VALUES "

84


5. Delete an existing user: db2 "DELETE FROM AUTH_INFO WHERE USERID = "

6. Update the group information for a user: db2 "UPDATE AUTH_INFO SET NUMGROUPS = "

And: db2 "UPDATE AUTH_INFO SET GROUPINFO = "

7. Update the auth ID for a user. To simplify the work for the group plug-in, the design has placed the work of making the list of groups into the formatted string as required by DB2 (as stated in the db2secGetGroupsForUser API) in this administrative application. The group string is in a format listed on the Table 3.11 (required for the db2secGetGroupsForUser API), where the length is in the first byte followed by the group name and length of the second group followed by the group name and so on: db2 "update auth_info set authid = where userid = "

8. Reactivate an expired account: db2 "UPDATE AUTH_INFO SET ACCOUNT_STATUS = 'N' WHERE USERID = AND ACCOUNT_STATUS = 'E'"

9. Expire an account: db2 "UPDATE AUTH_INFO SET ACCOUNT_STATUS = 'E' WHERE USERID = "

The External Program or the Daemon This auxiliary program establishes a connection to the dbauth database residing in inst_auth instance and retrieves the row from the database based on the input value coming from the security plug-in. So, why doesn’t this design establish the connection within the security plug-in? The main reason is that the security plug-in is running unfenced in the database engine agent address space, which has the DB2 engine library loaded. If the security plug-in was also to perform the connection, the DB2 client library would need to be loaded, too, into the database engine agent address space. This can potentially cause undesired consequences such as corruption of the database engine. Therefore, an external program or daemon approach is strongly encouraged. As mentioned previously, there should be a daemon running on the database server for each instance. An alternative is to have a daemon application running locally on the database server at instance inst_auth and then have the security plug-in communicate with the daemon across the network with an agreed-upon port number. SSL should be considered if using the alternative approach (to protect the information sent across the network).


85

How the communication takes place between the daemon and the security plug-in is determined during implementation. One choice is to use a named pipe. The output from the daemon will include a security plug-in return code as listed in Appendix H, “Security Plug-In Return Codes,” or the Application Development Client Volume “Return codes for security plug-ins” section. Table 3.11 shows the tasks that this daemon must perform. Table 3.11

Tasks Performed by This Daemon

Task Task Number Description D1

User ID and password verification (optionally change password if the new password clause is used in the connect statement)

Input from the Security Plug-In

Output to the Security Plug-In

User ID and password hash value and optionally the hash of the new password

Security plug-in return code. If the return code is DB2SEC_ PLUGIN_OK,

DB2 will also return the group list information for this user.

Algorithm 1. Select the entire row where the user ID matches the input value and the column userid on table auth_info. 2. If no row is found, this user does not exist; return DB2SEC_PLUGIN_BADUSER.

3. Check whether account_ status = 'E' (expired). If so, return DB2SEC_ PLUGIN_UID_EXPIRED. 4. Check whether account_ status = 'L'. If so, return DB2SEC_PLUGIN_USER_ SUSPENDED.

5. Check whether pw_expire_ date 0, return the group list and DB2SEC_PLUGIN_OK.

You can find detailed implementation information for the group and server plug-in used in this case study in Appendix I, “Detailed Implementation for the Case Study in Chapter 3.”

SAMPLE SCENARIOS Sometimes, DBAs are presented with challenges requiring solutions that are not easily researched. For example, it is not every day that the DBA works on implementing a security plugin, let alone one that presents an especially challenging level of complexity. To facilitate comprehension, the following sample scenarios are played out to provide examples of ways to “cope” with some of the more challenging aspects of the technical DB2 security architecture.

88


Scenario 1: Mixed Use of Pre-8.2 and 9 Clients with the GSS API Plug-In In this scenario, the environment has a lot of DB2 clients. Some clients are plug-in enabled and some are not. The DBA wants to start rolling out the GSS API plug-in on the database server. Prior to using the GSS API plug-in, the clients were using client, server, or SERVER_ENCRYPT authentication. (The down-level client (prior to 8.2) is shown as c1, the DB2 9 client is shown as c2, and the DB2 9 server is shown as s1 to illustrate the scenario.) • Down-level client c1 1. No need to do anything if the database is not cataloged with AUTHENTICATION CLIENT or AUTHENTICATION SERVER. If cataloged with the authentication CLIENT or authentication SERVER, recatalog the database without specifying an authentication clause or use the authentication options SERVER_ENCRYPT. This client uses the SERVER_ENCRYPT authentication type for authentication, and the authentication will occurs using the server-side user ID/password-based auth plug-in. • DB2 9 client c2 1. Install the client-side GSS API plug-in(s) in the client plug-in directory. 2. Catalog the database specifying the authentication options with the authentication type GSSPLUGIN. In this scenario, a hybrid authentication type is used at the database server, so you must catalog the database with the authentication GSSPLUGIN; otherwise, it will default to use SERVER_ENCRYPT on the initial DRDA flow if you specified a user ID and password on the connect statement. See the section “Authentication Type Negotiation between the Client and Server” for more details. • DB2 9 server s2 1. Install the server-side GSS API plug-in(s) in the server plug-in directory. 2. Update DBM CFG parameter SRVCON_GSSPLUGIN_LIST with the ordered list of the supported GSS API plug-in names. Note that the list should be in the order of preference. 3. Update DBM CFG parameter SRVCON_AUTH to GSS_SERVER_ENCRYPT. After you update the SRVCON_AUTH to GSS_SERVER_ENCRYPT, the server handles the new clients using the GSS API plug-in and still uses SERVER_ENCRYPT to deal with other clients (including down-level clients) that do not support GSS API plug-in. 4. Restart the instance database manager by issuing a stop database manager (DB2STOP) and start database manager (DB2START).

Sample Scenarios

89

Scenario 2: DB2 9 Client Communicating with a Database in a Different Instance with a Different Authentication Setting In this scenario, there are three databases (dbase1, dbase2, dbase3) that belong to instances inst1, inst2, inst3, respectively. • For inst1 to use SRVCON_AUTH = SERVER_ENCRYPT 1. Install the server-side user ID/password-based plug-in (for example, server_upw) in the server plug-in directory. 2. Update the Database Manager Configuration parameter SRVCON_PW_PLUGIN with the name of the server-side user ID/password-based plug-in. 3. Update the Database Manager Configuration parameter SRVCON_AUTH to SERVER_ENCRYPT. 4. Restart the instance database manager by issuing a stop database manager (DB2STOP) and start database manager (DB2STOPT). • For inst2 to use SRVCON_AUTH = Kerberos 1. Install the server-side Kerberos based plug-in (for example, krb) in the server plugin directory. 2. Update the Database Manager Configuration parameter SRVCON_GSSPLUGIN_LIST with the name of the server-side Kerberos-based plug-in. 3. Update the Database Manager Configuration parameter SRVCON_AUTH to Kerberos. 4. Restart the instance database manager by issuing a stop database manager (DB2STOP) and start database manager (DB2START). • For inst3 to use SRVCON_AUTH = gssplugin 1. Install the server-side GSS API-based plug-in (for example, krb, gss1, gss2) in the server plug-in directory. 2. Update the Database Manager Configuration parameter SRVCON_GSSPLUGIN_LIST with the name of the server-side GSS API-based plug-ins in the order of preference. For example, assume you prefer gss2 to krb to gss1, and then update the Database Manager Configuration parameter using SRVCON_GSSPLUGIN_LIST 'gss2,krb, gss1'. Note: do not put spaces before or after the comma in the list; otherwise, it will be considered part of the security plug-in name. Notice that the krb can be the same Kerberos-based plug-in from inst2. Because Kerberos is implemented using GSS API infrastructure, it can be used as a GSS API plug-in. Update DBM CFG using SRVCON_GSSPLUGIN_LIST 'GSS2,KRB,GSS1'. 3. Update the Database Manager Configuration parameter SRVCON_AUTH to gssplugin.

90


4. Restart the instance database manager by issuing a stop database manager (DB2STOP) and start database manager (DB2START). • If the client wants to communicate with the databases in all three instances 1. Update the Database Manager Configuration parameter CLNT_PW_PLUGIN with the client-side user ID/password plug-in (for example, clnt_upw). This is an optional step because the authentication is done on the server. If you have implemented remap user ID capability in the client-side user ID/password plug-in, you must perform this step. 2. Update the Database Manager Configuration parameter CLNT_KRB_PLUGIN with the client-side Kerberos plug-in (for example, krb). 3. Install the client-side plug-ins (clnt_upw, krb, and gss2). In this scenario, we intentionally do not install the gss1 GSS API-based plug-in to simulate real-life situation where the server installed the superset of all GSS API-based plug-ins used by any client. 4. Catalog the database dbase1 (without specifying AUTHENTICATION or specify the authentication as SERVER_ENCRYPT). 5. Catalog the database dbase2 (without specifying AUTHENTICATION or specify the authentication as KERBEROS). 6. Catalog the database dbase3 (without specifying AUTHENTICATION or specify authentication as gssplugin). 7. Issue the statement db2 "connect to dbase1 user <userid> using <password>" ===>. This connection uses SERVER_ENCRYPT; while on the client, it uses clnt_upw (from clnt_pw_plugin), and on the server, it uses server_upw (from srvcon_pw_plugin). 8. Issue the statement db2 "CONNECT TO DBASE2 USER USING " ===>. This connection uses Kerberos; while on the client, it will use krb (from clnt_krb_plugin), and on the server, it will use krb (from srvcon_gssplugin_list). 9. Issue the statement db2 "CONNECT TO DBASE3 USER USING " ====>. This connection uses the gssplugin; on the client, it selects gss2 even though both gss2 and krb are listed. This is because the srvcon_gssplugin_list dictates the preference order. The server will then be notified by the client to use gss2. Therefore, both the client and the server will use gss2. Note that unlike the user ID/password plug-in case, the GSS API-based plug-in needs to have the same name on both client and the server.

Sample Scenarios

91

Scenario 3: Using Kerberos for Authenticating DB2 (Linux/UNIX/Windows) Client in an Environment That Also Has a DB2 for z/OS Client DB2 for z/OS can accept only Kerberos when acting as a server and cannot use Kerberos when acting as a client. In this case, there is no choice but to use two types of authentication for these two types of clients. You can accomplish this by using the KRB_SERVER_ENCYRPT authentication type for the z/OS client to enable SERVER_ENCRYPT authentication. The DB2 (Linux/UNIX/Windows) client will use Kerberos for authentication. If you would like to centralize the entire user set connecting from DB2 z/OS clients in a single location, using the LDAP server-side auth plug-in is a viable solution. One issue here is that the RACF ticket (Z/Series authentication credential) sent by DB2 z/OS must be customized to a short string per the DB2 (Linux/UNIX/Windows) password requirements. • DB2 for z/OS client c1 1. Make sure the client is set up to use encrypted user ID and encrypted password for authentication with the server. • DB2 (Linux/UNIX/Windows) client c2 1. Install the client-side Kerberos-based plug-in (for example, krb) in the client plug-in directory. 2. Catalog the database specifying the authentication options with the authentication type Kerberos. In this scenario, a hybrid authentication type is used at the database server, so you must catalog the database with the authentication Kerberos; otherwise, it will default to use SERVER_ENCRYPT on the initial DRDA flow if you specified a user ID and password on the connect statement. See the section “Authentication Type Negotiation Between the Client and Server” for more details. • DB2 (Linux/UNIX/Windows) server 1. Install the server-side Kerberos based plug-in (for example, krb) in the server plugin directory. 2. Install the IBM-shipped or customized server-side LDAP-based plug-in (for example, ldap_server) in the server plug-in directory. 3. Update the Database Manager Configuration parameter SRVCON_GSSPLUGIN_LIST with the name of the server-side Kerberos-based plug-in. 4. Update the Database Manager Configuration parameter SRVCON_PW_PLUGIN with the name of the server-side LDAP-based plug-in. 5. Update the Database Manager Configuration parameter SRVCON_AUTH to KRB_SERVER_ENCRYPT. 6. Restart the instance database manager by issuing a stop database manager (DB2STOP) and start database manager (DB2START).

92


SECURITY PLUG-IN DEPLOYMENT LIMITATIONS Some limitations apply when it comes to plug-ins. Although these change from release to release, the ones that a DBA might encounter in Version 9 are as follows: • The admin server (DAS) is not plug-in enabled. So, any action through the Control Center (or any other DB2 GUI tool) that occurs through the admin server (rather than over a database connection) prompts for a user ID and password that will be validated against the local operating system, /etc/passwd on UNIX). Unfortunately, when the Control Center prompts for a user ID and password, it is not clear whether it will be used for a database connection or to connect to the admin server, and it is often hard to predict which one will be used based on the action performed. • The Java client (JCC) does not support customized user ID/password-based security plug-ins for authentication or customized group lookup security plug-ins. • Other DB2 products such as DB2 on Z/Series®, I/Series®, or VM/VSE® do not support any form of security plug-ins. They also do not support the GSS API plug-in authentication methods except Kerberos. Note that DB2 on Z/Series does not support the Kerberos authentication type as a client. • Q replication does not work with security plug-ins. • If the initial credentials for the GSS API plug-in are expired, DB2 will not automatically renew them. • In a multi-tier situation, a client may connect to a server that, in turn, needs to connect a back-end server. To gain access to the back-end database server, either the client must obtain credentials to access the back-end database server and then pass them on to the intermediate server, or else the intermediate server must obtain the credentials to access the end server itself. Preferably, the credentials should be obtained using the client’s authority. This is known as credential delegation. Currently, DB2 does not support this.

LAST WORDS Think of authentication as the first soldier in the battle of DB2 database defense. Implementing a good authentication mechanism on your database system can prevent any unwanted or unauthorized access on the spot. Users must also play a big role here. No matter what authentication method you use, there is always additional authentication information (such as password) that the user must have. If the user fails to safeguard this authentication information, authentication will fail to fulfill its mission as a preventive control.

CHAPTER

4


it is confession time. How many of you DBAs out there spent hours playing Solitaire O kay, on Windows 3.1?

FIRST WORDS DB2 9 on Windows has come to the forefront as a robust solution for organizations standardizing on the Windows platform. As deployments on Windows platforms continue to increase, DB2 DBAs can expect to be asked to support these environments. If you are a UNIX or Linux DBA, the good news is that the majority of the code base for the DB2 product is primarily the same for Linux, UNIX, and Windows platforms, but there are some significant security differences based on operating systems. In a Windows environment, there may be considerable differences in the division of responsibilities between the DBA and systems administrator as compared to other operating system/DB2 combinations. It is more often the case that the Windows DBA will also be the Windows system administrator, and, therefore, the security burden, instead of being split between two distinct groups responsible for the day-to-day corporate infrastructure tasks, potentially, will be held by one group or even, in very small shops, one individual. This means that the DB2 Windows DBA holds an increasing responsibility for security for both the corporate database and the operating system where it lives. Such a nondivision of labor increases the potential for the subtleties of security to be overlooked. The Windows DB2 DBA should be encouraged to cross-train in administering a Windows operating system whether she will be functioning as a Windows system administrator or not. Windows

93

94

Chapter 4 • Securing DB2 on Windows

operating systems employ unique security features and introduce equally unique issues for the DBA tasked with protecting the DB2 databases. No matter what your platform preference, due diligence in setting up DB2 is required, so the additional training expenses can be cost-effective if the return on the investment is a stronger security implementation.

SCOPE OF THIS CHAPTER Windows installations of DB2 produce a database environment that is tightly entwined with the operating system. Making your Windows environment as secure as possible (hardening the operating system) provides increased security for the DB2 database environment. Conversely, failing to secure your Windows environment may make your DB2 database environment an attractive target. At the time this book was being written, the primary Windows operating system products in use for DB2 installations were Windows XP, Windows 2000, and Windows Server 2003. The comments and recommendations in this chapter refer primarily to DB2 9 installations on those product levels, but many topics will also be useful if the Windows operating system environment is a precursor or a successor to those levels. Much of this chapter deals heavily with the installation and initial setup of DB2 on Windows because the best place to start is at the beginning. If your environment is already instantiated, it is equally important to review the items documented and explained in the “installation” information to determine whether security improvements to your environment can be made post-install. The majority of the security items covered regarding installation can still be implemented even if the product has been installed for some time. Of course, when there is no luxury of performing a “clean” install, due diligence is an absolute requirement. When changing parameters and settings on a live system, the normal testing and quality-assurance steps cannot be avoided, and a lot of time and effort may be invested prior to making any change. Although this might make the task of post-configuring a DB2/Windows environment to incorporate security measures more challenging, it also makes it more important because the longer the exposure, the higher the likelihood of an incident. If your role is that of a DBA, you may or may not have the expertise to harden your Windows operating system environment, but you will be expected to have the DB2 9 product and all databases configured securely. This book can provide you with the DB2 pieces that are important as they relate to the Windows operating system environment, but it is important to understand that the implementation of security should be collaboration between the DBAs who know the database environment and personnel who understand the Windows operating system security measures. If you are “lucky” enough to be “both” of those people, you will need further study beyond the information provided here to hack-proof your operating system.

First Steps: Build in DB2 Security During Installation

95

Finally, although this chapter does deal specifically with topics exclusive to DB2 9 Windows environments, it does not redundantly cover topics already covered elsewhere in this book, so it is recommended that you review the content of the other chapters, too.

FIRST STEPS: BUILD IN DB2 SECURITY DURING INSTALLATION Heroes Welcomed Here If your manager asked you for a cost/benefit analysis on retrofitting DB2 security on Windows after the install versus installing DB2 with security in mind, which option would be most likely to appear cost-effective? Considering the extra work involved to test and certify the changes on a “working” system, if it is possible to build security at the install level, there will be an associated cost savings. Every manager out there likes to hear the term cost savings; so, if you want to be a hero, building security in from the start is the logical choice.

Documentation Is Necessary Prior to beginning the DB2 9 installation process, it is a good idea to document the planned approach. A step-by-step installation document can be used during the install to verify that important security steps were not forgotten in the haste to get the environment up and running. An added benefit from documenting the installation is that the DBA can refer to this document each time a patch or Fixpack is needed, review it in light of any new security recommendations, and use it as a foundation for subsequent DB2 installs. Surprisingly, not every DBA documents the installation process. It is understandable that for technically oriented individuals, writing documentation is not the fun part of the job. Fun or not, when it comes to security, it is wise to be able to answer the “how did you do it?” questions that inevitably arise when there is any indication that something is not working as planned, especially if you are playing the dual role of DBA and Windows administrator. One of the first lessons learned when on the receiving side of a security audit is that documentation from “the beginning of time” (or at least the beginning of the environment) until the moment of the audit is critical. Obviously, the documented installation information must be kept confidential and needs to be protected in the same manner you protect the company’s security policies (see Chapter 2, “DB2 Security—The Starting Point”). For any DB2 installation on a Windows platform, it is a good idea to document (at a minimum) the following: • All changes done to harden the Windows operating system prior to install • Windows operating system (and Service Patch) levels • Date of the installation • Name of the person(s) doing the installation

96


• Media used (for example, E.S.E. CD v 9.0 for Windows 32 bit) • Instance name/ID • User IDs/groups for the SYSADM, SYSMAINT, SYSCTRL, and SYSMON groups • ID used to do the install • Fenced ID • DAS (DB2 Administration Server) ID • A copy of the response file, if used • Documentation of all post-install changes to configuration values • Documentation of any post-install permission changes to files, accounts, groups, or DB2 directories

Thinking “Security”—Planning the Windows Install When planning the installation of DB2 on a Windows environment, it is important to consider security before beginning any actual setup work. A new, “clean plate” installation of DB2 provides an opportunity to build in security from the start, while retrofitting security into a Windows environment is an ongoing concern. First, consider the ID that will be used for the installation. The requirements for the installation ID are that the ID is either • An administrator via security access • An administrator ID on the local system • An administrator ID on the domain There are some differences in the way the DB2 install process defines default users and groups depending on whether the install is on Windows (versus UNIX environments). On Windows, the default ID, db2admin, is used for the DAS (DB2 Administration Server), the instance owner and the fenced owner. The db2admin ID is a well-known user ID; so if the defaults were not changed during the installation, this user ID should be changed immediately after the install. Fortunately, using only one shared ID for the instance owner, fenced owner, and DAS is not a requirement. The more robust approach is to use three different user IDs: one for the instance ID, one for the fenced ID, and a third for the DAS ID for the installation. This adds a layer of security depth for these high-level accounts. Although possible, the use of the Windows Control Panel for changing the DAS user ID after the installation is not recommended unless you know and are familiar with the changes necessary to


97

implement the access rights that will need to be reset after the change. Instead, the recommended approach for changing the user ID/password is to log on to the Windows machine using an account that has local administrator authority. Change the ID and password using the db2admin command syntax as follows: db2admin setid <userid> <password>

The user ID and password must match an existing user account holding local administrator authority; otherwise, an error is returned indicating that SQL4412N The logon user account for the DB2 Administration Server is invalid. A successful change will return SQL4402W The DB2ADMIN command was successful. One additional security consideration with the DAS is that by default it supports “search” (remote discovery) requests from clients. Although this provides an aid for communication setup, it also opens a security concern. A more secure way to enable communication pathways is to use a “cataloging” approach, either by commands or by tools such as the Configuration Assistant. Changing the DAS DISCOVER default of SEARCH to DISABLE after the installation of the product is recommended: db2 update admin cfg using discover disable

Response File A feature that provides an alternative method of installation (via a “response file”) can also provide enhanced security. Although the use of a response file is not exclusive to the Windows platform, in practicality its use is more prevalent on Windows installations. The DB2 response file is an editable text file that “feeds” the parameter values to the product during the installation. The response file requires specific ids for users and groups and does not use the defaults automatically. Editing the response file (or generating one) to supply the most secure options for the parameter values ensures that the DB2 9 installation process begins with a strong security base. If you decide to use response files, you have three options: 1. Use the DB2 Setup Wizard GUI and choose the Custom installation option. When prompted to Select the installation action, click the check box to Save your settings in a response file. You will be prompted to choose a name for the file and provide a path. As part of the installation process, the DB2 Setup Wizard saves the response file based on the parameters chosen during the DB2 setup process. (See Figure 4.1a, 4.1b, and 4.1c.)

98

Figure 4.1a

Figure 4.1b



Figure 4.1c

99

Saving the response file using the Setup Wizard

2. Use the Response File Generator. The Response File Generator utility is available only on Windows platforms. You can invoke it from the command line, and it has both optional and required parameters. Table 4.1 lists the options. db2rspgn –d z:\path -i –noctlsrv -nodlfm

Table 4.1

Flags for the db2rspgn Command

Switch

Required or Option

Definition

-d

Required

Indicates where the response file (and any instances files) will be written.

-i

Optional

This parameter can be used to specify specific instance(s). If not specified, all instances are included.

-noctlsrv

Optional

If specified, the control server instance profile will not be generated.

-nodlfm

Optional

When using data links, this parameter can optionally be set to avoid generating an instance profile for the Data Links File Manager instance.

When generated, you can modify the file as appropriate. At a minimum, you should modify the file indicating acceptance with the license agreement.

100


3. Modify the sample response file. The sample response files are text files and can be found on the installation CD in the \db2\windows\samples directory. All DB2 response files end with the .rsp extension, but the naming convention changes depending on the product being installed. Some of the product examples are db2ese.rsp (Enterprise Server Edition), db2wse. rsp (Workgroup Server Edition), db2exp.rsp (Express Edition), and db2pe.rsp (Personal Edition). The response file can be opened and edited using any text editor product such as Notepad. Initially, many of the lines are commented out with an asterisk (*). Editing the file and removing the leading asterisk for a specific line enables that parameter to be read during a response file installation. An Excerpt from a Sample Response File * General Options * ---------------PROD = ENTERPRISE_SERVER_EDITION INSTALL_OPTION = SINGLE_PARTITION LIC_AGREEMENT = DECLINE **You must change this to ACCEPT to indicate your acceptance of the license agreement before continuing. *FILE = C:\Program Files\IBM\SQLLIB *INSTALL_TYPE = TYPICAL, COMPACT, or CUSTOM **Default=TYPICAL . . . . * Select Language *----------------*LANG = DE ** German *LANG = DK ** Danish *LANG = FI ** Finnish *LANG = FR ** French *LANG = EN ** English . . . * Select Features (CUSTOM install option only) *----------------------------------------------*COMP = APPLICATION_DEVELOPMENT_TOOLS *COMP = IBM_JRE *COMP = IBM_JDK *COMP = LDAP_EXPLOITATION *COMP = CLIENT_TOOLS *COMP = DB2_WEB_TOOLS . . . *COMP = TCPIP_DB2_CLIENT_SUPPORT *COMP = TCPIP_DB2_LISTENER_SUPPORT * General information for instance to be created * ----------------------------------------------INSTANCE = DB2 DEFAULT_INSTANCE = DB2 DB2.NAME = DB2


*DB2.TYPE *DB2.FCM_PORT_NUMBER *DB2.MAX_LOGICAL_NODES *DB2.FEDERATED

= = = =

101

ESE, WSE, CLIENT, STANDALONE or SATELLITE 60000 4 YES or NO

* Default Instance Logon Settings

* ------------------------------*Enter the user name and password that will be used to administer the DB2 instance. *char(30) represents a word with a maximum of 30 characters. DB2.USERNAME = char(30) [char(20) for Windows NT] *DB2.DOMAIN = char(14) DB2.PASSWORD = char(14) *======================================================================= *The remaining settings in this response file are optional. ...

Response files use an asterisk (*) for comments. Remove the line’s leading asterisk to enable that option for installation.

Although numerous parameters are available for change within the response file, when it comes to security, the philosophy that less is more should be considered for the options actually installed for DB2. For example, do not install more language options than are needed to meet the company’s business need. Likewise, you would not want to switch every DB2 Profile Registry option on just to make sure everything was covered. The response file gives you an opportunity to plan and review each install option to be sure that your installation makes sense from both the application and security standpoints. Each product has its own sample response file, so it is best to match the sample response file to the product base being planned. If you prefer, you can create your own response file by using any text editor. When building the text file from scratch, remember that any items that are necessary for the install, but not included, will be set to defaults. Although sample product response files, on first glance, appear similar, the parameters listed in each are tailored to the product being installed. The examples in this chapter refer to the Enterprise Server Edition, Single Partition installation, and the install is presumed to be on a Windows platform. Security Parameters in the Response File Although not all response file items relate to security, working through a sample response file affords the opportunity to review available options and decide whether they pose a security issue for your environment. Even if you are installing using another method, reviewing the sample response file is an aid to understanding the wealth of configuration options available during a DB2 installation and how DB2 “plays” in your environment.

102


One particular advantage to generating the response file using either the Setup Wizard or the Response File Generator is that the resulting file will contain encrypted passwords, as shown in Figure 4.2.

Figure 4.2

Generated response file showing encrypted passwords

Although there are numerous items in the response file to consider, review the following, in particular, with security in mind. Response File Parameters DBM (Instance)-Level Parameters • DB2.AUTHENTICATION Authentication plays such a critical role in securing your DB2 environment that it is explained in detail in Chapter 5, “Authorization—Authority and Privileges.” It is important to understand the various configuration options for authentication and how to implement them in a manner that is most secure for the specific architecture being deployed. This is not the time to just trust that the default is “good enough.” It is important to delve into this topic until a complete understanding is obtained. • DB2.CATALOG_NOAUTH Consider leaving this parameter disabled by keeping the default value (No). When enabled, this would allow users who do not hold SYSADM, SYSCTRL, or SYSMAINT authority to catalog an instance, database, or an ODBC connection. Although allowing users to catalog connectivity in a development environment may be acceptable, it is risky to do so in a production environment. • DB2.DISCOVER This parameter makes it easier for developers and users to catalog communication to the database. In other words, communication pathways to the database can be determined if this parameter is enabled. To prevent a client from “discovering” the database on local and remote networks, change this parameter from its default of SEARCH to DISABLE. It is best to catalog specific connection information rather than allow clients to use discovery options. For a production environment, you should disable this option.


103

• DB2.DISCOVER_INST Similar to the previous DISCOVER option, this is an instance discovery option that is set to ENABLE by default. Changing this value to DISABLE will prevent unwanted detection of the instance. In production, you should disable this option. • DB2.TRUST_ALLCLNTS and DB2.TRUST_CLNTAUTH If the DBM AUTHENTICATION parameter is set to CLIENT, TRUST_ALLCLNTS and TRUST_CLNTAUTH are used in combination to determine where user connections are authorized. If the DBM AUTHENTICATION parameter is set to any value other than CLIENT, these two parameters are not used. The distinction is important. If AUTHENTICATION is set to CLIENT, TRUST_CLNTAUTH is set to CLIENT, and TRUST_ALLCLNTS is set to YES, for example, all trusted clients are considered to have been previously authenticated, and no user ID/password is needed and no extra verification is performed. A trusted client is assumed to be coming from an operating system that has the mechanisms in place to validate security credentials. An example of an operating system that is not considered to have this capability is Windows 98. The TRUST_ALLCLNTS parameter is commonly used for DRDA connections from DB2 for z/OS. If you set this parameter to DRDAONLY, all clients that do not connect from one of these DRDA connections are required to supply a user ID/password combination for authentication. Note that neither of these parameters is changeable from the defaults unless AUTHENTICATION has first been set to CLIENT. If you attempt to modify these settings in the response file and have not set AUTHENTICATION to CLIENT, you will receive the following message: SQL5154N The requested combination of configuration values for "authentication" and "trust_clntauth" is not allowed. Reason code = "1".

From a security standpoint, configuring AUTHENTICATION to CLIENT is strongly discouraged because this setting allows connections without requiring a user ID and password. • DB2.SYSADM_GROUP, DB2.SYSCTRL_GROUP, DB2.SYSMAINT_GROUP To provide the finest granularity of access for privileged system accounts, these three groups should be set up independently from each other. In the response file, assign a group name value to each of these groups so that groups for each will be created. After the install, use these groups to add user IDs based on specific, well-defined job roles. Users belonging to these groups hold high-level authorities on the database environment (as discussed in detail in Chapter 5).

104


Creating DB2 Privileged Groups Using the Response File DB2.SYSADM_GROUP DB2.SYSCTRL_GROUP DB2.SYSMAINT_GROUP

= IPASAGRP = IPBSCGRP = IPCSMGRP

Instance DB2 Registry Variables • DB2.DB2COMM Possible values for this communications parameter are TCPIP, APPC, NETBIOS, NPIPE, or blank. It is best to enable only those communication protocols that are actually needed by the application to prevent unnecessary exposure. If only TCP/IP is needed, it should be the only protocol enabled. Extended Security Parameters • DB2_EXTSECURITY This DB2 Profile Registry variable is available only for Windows environments. This feature installs by default unless its response file setting is changed to No. When enabled, an additional layer of protection deploys, locking down DB2 system files and preventing unauthorized access to DB2. (See Figure 4-3 for more on this topic.) • DB2_ADMINGROUP_NAME The response file default for this value is DB2ADMNS. This value is changeable. When specifying a name other than the default, if the group name does not exist, the installation creates it. If specifying a group name that already exists, the security policies for that group may be modified to comply with DB2 requirements for the group, thus potentially elevating privileges for users of the existing group. Any user who belongs to this group (and any local administrator account) has full control of the database. User IDs for DBAs and others that need full access should be added to this group after the install. • DB2_USERSGROUP_NAME This value defaults to DB2USERS if not defined. This value can be changed to indicate a different name for the DB2 Users group. Users that are assigned to this group generally have write and execute privileges on the databases. The install does not add users to this group; therefore, they must be added post install and prior to successful database access. Now that your customized response file is generated, consider how you are going to secure it. Just like every piece of information that could aid a hacker, the configured response file must be protected according to the security policy.

Designed Especially for Windows

105

DESIGNED ESPECIALLY FOR WINDOWS DB2 provides specific features to take advantage of the inherent operating system security structures in Windows environments.

Windows Domain\User DB2 supports two-part user IDs for Windows logins for both “connect” (to the database) and “attach” (to the instance) attempts. By the use of domain\user functionality, there is no need for a broadcast to all domain servers to authenticate the user on the Windows system. This provides a security benefit, too, because it adds a layer of complexity to a user login and might aid in preventing denial-of-service attacks.

Installation User ID The user ID chosen to perform the install of DB2 will not have native ability to run any DB2 commands unless the ID is either that of a local administrator or has been added to the DB2USERS or DB2ADMNS groups. The installation process can be used to create the DB2USERS and DB2ADMNS groups, but the installation user ID is denied privileges within the DB2 environment unless the user ID is specifically added to one or both of these groups (or is a local administrator). This “hands-off” approach between the installation user ID and the database environment adds depth to security. Unless there is a strong specific reason to do so, it is better to keep this user ID as an independent “install only” account. After the install, this ID should be moved from the Windows Administrator group to a less-privileged group such as Power Users. DB2_EXTSECURITY

Unless specifically deselected during an installation of DB2 9 on a Windows platform, extra operating system–based security features are enabled that modify the access control lists, Windows registry entries, and some runtime memory settings. These changes add depth to the security of the DB2 installation on Windows and restrict the rights that normal users have when accessing DB2 resources. With this functionality, DB2 builds a Windows registry key, DB2_EXTSECURITY, which sets a flag that determines whether DB2 runtime code security checks should be performed. This functionality applies only to normal users and not DBA or system administrator users. When enabled, the Windows registry variable DB2_EXTSECURITY will be set to Yes. When DB2_EXTSECURITY is enabled, access to DB2 specific Windows Services, DB2’s System Files, DB2 Window’s registry keys, and network shares are tightly controlled on the local Windows machine running DB2. Only users who belong to DB2ADMINS or DB2USERS groups or local administrators have access (see Figure 4.3).

106


Figure 4.3

The DB2_EXTSECURITY Windows registry setting

In addition to the option to enable this functionality during an install, the DB2_EXTSECURITY security features can be enabled via execution of the db2extsec.exe command. The executable is shipped with the product and is stored in the $installpath/SQLLIB/bin directory. This command, when run by a user ID with SYSADM authority, provides the same changes that are invoked when using the Setup Wizard in Typical mode and keeping the default for the Enable Operating System Security check box. The command can take three parameters: • /u (usergroup) • /a (admin group) • /r (reverse) db2extsec.exe /u DB2USERS /a DB2ADMNS

If you do enable these features via the db2extsec.exe command and later decide to back out the changes, the options to do so vary depending on whether other changes have been made since the db2extsec.exe command was run. 1. Prior to making any further changes, run the db2extsec.exe command again with the –r (reverse) option: db2extsec.exe -r

2. Alternatively, add the Windows Authenticated Users group to both the DB2ADMNS and DB2USERS group.

THE WINDOWS OPERATING SYSTEM—THE IMPORTANT STUFF You might be asking why this topic is included here. After all, items such as Windows accounts, services settings, and the Windows registry are part of the operating system, not part of DB2. Unfortunately, anyone who is interested in gaining inappropriate access to the databases housed in the Windows environment probably does not share this vision of a demarcation line between the

The Windows Operating System—The Important Stuff

107

two products. DB2 and Windows are separate only until the point DB2 is installed on Windows. Then, the two products develop a dependency on each other, or more specifically, DB2 develops a dependency on Windows to do its part in a fully functional robust security implementation. Going over the entire Windows Security Model would require another book. If you are familiar with this topic at all, you have an advantage over many DBAs. However, you do not have to personally understand every nuance of the Windows Security Model to securely implement DB2. Although it is a good idea to have access to an expert, you do not necessarily have to be one yourself. What you do need is enough information to understand the pieces that interact with DB2 and how they impact security for the database environment. If you want your database to be secure, in addition to all the DB2 security features you need to consider, you need to make sure Windows is hardened to the fullest extent possible. This is where the expertise of a knowledgeable Windows system administrator is invaluable. If you do not have a Windows system administrator, of if you are the Windows system administrator, this section presents a minimal overview of the items you need to check.

Review Windows Account Policy Settings Review the account policy settings for Windows security for appropriateness. You can find these accounts in the Windows Control Panel under Administrative Tools. • Passwords must meet complexity requirements. This setting should be changed from the default to require the use of complex passwords. When set to require complex passwords, all new or changed passwords are required to meet the following standards: Not be or contain the user’s account name Contain a mix of characters from at least three of these groups: Digits (0–9) Lowercase characters (English) Uppercase characters (English) Symbols (such as &, $, #,) Length of at least six characters Because most of today’s password-cracking programs can exhaust a six-characterlength passwords in minutes, often seconds, it is generally encouraged that an eightcharacter minimum should be set. • Enforce password history. To prevent reuse of the same passwords repeatedly, consider changing the default of 1 to a value of up to 24.

108


• Minimum password age. Consider setting this value to a minimum of two days. The goal is to prevent a situation where a user simply runs a script to set enough passwords in the history series to reach a point where an old password can be used again quickly. • Maximum password age. To enforce frequent changes of passwords, consider changing the maximum password age to 30 days (see Figure 4.4).

Figure 4.4

Changing the maximum password age

Lock Down and Protect Windows Accounts To protect from unwanted access to the Windows machine, review and mitigate the following items: • Default Administrator Account The Windows “Administrator” account is very well known and should be considered at risk. One way to thwart this vulnerability is to rename the existing Administrator account. To add an extra layer of protection, after renaming the original Administrator account, consider creating a safety net by re-creating the named Administrator account


109

with no privileges or rights assigned to the ID. This “decoy” Administrator account can prove useful when auditing for suspicious logins or discovering users attempting to upgrade their privileges. • Account Lockout Duration and Threshold The Account Lockout Duration and the Account Lockout Threshold settings work together to lock an account experiencing a frequent number of incorrect password attempts. For example, setting an Account Lockout Threshold of 3 and an Account Lockout Duration of 30 minutes means that after 3 login attempts using an incorrect password, the account in question will be locked for 30 minutes. A consideration should be made as to whether setting values for these parameters would open the enterprise to a denial-of-service attack because a massive influx of logons with an incorrect password would effectively lock out service for any accounts that were “hit’ for the length of time specified by the Account Lockout Duration. • Guest Accounts It is a good idea to verify that Guest accounts are, in fact, disabled even though that is the default. To be extra cautious, assign a strong password to the default Guest account, too (see Figure 4.5).

Figure 4.5

Verify that the Guest account is disabled

110


Lock Down Unneeded Features for the Windows Registry Locking down the Windows registry is typically something that should be attempted only by a knowledgeable Windows system administrator because mistakes can have serious implications to the health and well being of the machine and, therefore, the database. However, to the extent possible, the Windows registry for the machine housing the DB2 database environment should be protected from unwanted access. When thinking about the Windows registry, items that may impact security should be reviewed to see whether hardening their access is possible. Here are some examples of items to check: • Remote registry access. Although this parameter does drive Windows registry behavior, it is actually controlled as a Windows service. The Remote Registry service makes the Windows registry available to other users on the network. Consider stopping and then manually controlling this service via the Windows Control Panel, Administrative Tools, and Services screen. Doing so will prohibit changes to the registry unless the user is logged on to the machine locally. If remote registry access is not needed at all in your environment, consider disabling this service. Note that if this service is disabled, any services that depend on the Remote Registry service will fail to start at next reboot, so caution is advised if making this change (see Figure 4.6).

Figure 4.6

Windows Remote Registry service


111

• Review Windows registry keys. Another way to control which users are allowed remote access to the Windows registry is to change the registry itself. Again, caution is encouraged if this is the approach planned. The registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ SecurePipeServers\winreg can be modified to include only those groups or users who should have this access. Users and groups can also be added to specifically deny access. To access the permissions, find the key in the Windows registry, right-click, and choose Permissions (see Figure 4.7).

Figure 4.7

Changing the Windows registry WINREG permissions

112


• Review Windows/DB2 registry keys. Not all users require access to the DB2 Windows registry keys. Review the following keys and consider restricting the keys to Windows Administrators, SYSTEM, and DBA accounts where appropriate. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DB2

Windows Active Directory You can think of the Windows Active Directory as a type of logical phone book that stores information about system users. It provides a centralized location for the users and computer settings for the organization and allows Windows administrators to centralize policy implementation across the enterprise. Although not a requirement, DB2 can be used in conjunction with the Windows Active Directory, and the database instances and directories can be incorporated via configuration settings. This means that when you are using Active Directory, cataloging the instances and databases on client machines on the network is not required. Moving databases between servers is also easier to support because only the database directory at the Active Directory machine needs to be changed, and the changes will then be replicated across the other servers in the domain. In large environments, the features provided by Windows Active Directory can provide ease of administration for DB2, which makes its use attractive. When Windows Active Directory is enabled, DB2 objects are registered under the Computer container. To perform the registration, the user ID has to have privileges that can be conferred by membership in any of the Administrators, Domain Administrators, or Enterprise Administrators groups. Once registered, by default these objects are updatable by Administrators and readable by any authenticated user. Allowing any authenticated user to read the object information allows anyone to see information that would provide insight into where the instances and database “live.” To mitigate the security concerns, change the default permissions so that only selected, necessary user groups have permissions to read this information. You can do this by using the Active Directory Management Console (Microsoft Management Console).

The Local System Account (LSA) The LSA provides an “elevated privilege” account that does not need a password. On the surface, this sounds like a benefit because password maintenance is not required. The LSA account holds unlimited access, so there will be no tasks that cannot be accomplished with it. If your perspective is “ease of administration,” the LSA provides that ease. If your perspective is security, the LSA should not be used for DB2.

Other Considerations

113

Although DB2 can take advantage of the ease-of-use features of the Windows LSA for Windows services, or even for the DB2 install itself, obviously there are security concerns. Because the LSA is not required for the install or any DB2 services, instead consider using a domain name/user ID combination created explicitly for this purpose. If installing DB2 on a server that is not a domain controller, you can also use the domain name\user ID for the install or use a local user ID to avoid using the LSA. When creating an install account, verify that the account belongs to the Windows Administrator group and assign a strong password and advanced user rights for the following: • Act as part of the operating system • Debug programs • Log in as a service • Create a token object • Increase quotas • Lock pages in memory • Replace a process level token Because the install ID was created solely for the purpose of installing DB2, when the install is completed, the install ID can be removed from the Administrators group. Consider keeping the ID available for use with further Fixpack installs and move it back into the Administrators group only during those times when it is explicitly needed.

OTHER CONSIDERATIONS Physical Security for Windows Servers This topic is easy to overlook, and although it is not exclusively a concern for only Windows environments, the author’s experience indicates that Windows servers are more frequently left out of physical security planning and implementation. Although it is true that DBAs and system administrators do not often have responsibilities for physical security, they certainly pay the price if physical security leads to a breach. Regardless of who in the organization claims the physical security domain, it is important that someone does. Items to consider include the following: • Server rooms Access controls Console placement and protection Backup power supplies

114


Backup communication methods Security lighting with redundancy Guards or guarding mechanisms Alarms for intrusion detection, fire, power loss, and so on Protection against shoulder surfing Video of critical areas • Storage Lockable cabinets Document storage for sensitive written information Accessible by authorized individuals Backups in a central location and secured from being removed without permission

FIXPACKS, SERVICE PACKS, PATCHES—USE ’EM OR LOSE You have finally completed setting up the environment. All the security pieces have been reviewed, and you are satisfied that you have done your best to mitigate any security concerns. What’s next? Security should be thought of as a never-ending skirmish. As soon as you win one, start girding for battle for the next. Your Windows arsenal includes Windows service packs and patches and DB2 Fixpacks. As soon as a vulnerability is discovered, application vendors and hackers start working on it. The application vendors are rushing to mitigate the concern; the hackers are rushing to concern those who mitigate. Who will win? If history is any indicator, the application vendors will beat the hackers. They will release a patch before many (or in most cases, any) breaches occur. Sadly, however (and herein is the real issue), not every company will take advantage of the fix, so the hackers might win some because an available update was not installed, leaving the system to be compromised.

The Dilemma If you have done your homework and kept your documentation current, you have your initial install documents. Having done one install makes it easier to do the next. A DB2 Fixpack is just an install, so why not just go ahead and apply Fixpacks as they become available? Microsoft® also makes it easy to keep current fixes applied. They offer an automatic update service for Windows systems, and these can be silently pushed to the organization’s Windows machines without significant resources.

Last Words

115

So, what’s the dilemma? In an-ongoing concern, “slamming” in changes is usually not encouraged. Testing and a quality-assurance effort are obviously required. That is why being proactive is absolutely critical if you want your organization to continue to maintain its security edge. Building “security in” means nothing if you stop there. All the hard work, all the reviews, all the documentation, all the plans, all the policies go by the wayside if the necessary patches are not applied. For any application that interacts with the Windows operating system, this is especially true. As one of the more heavily used operating system products, it also attracts a lot of interest from the hacker community. Hackers have been at it long enough to feel “at home” on the Windows system. Like dealing with unwelcome guests, it is your goal to make them increasingly uncomfortable until they decide to more on to more-hospitable grounds. To lessen their comfort level, keep current on updates, patches, and Fixpacks.

LAST WORDS Although the information in this chapter relates to implementations of DB2 9 on Window machines, it does not encompass material covered elsewhere in this book, so reading the remaining chapters is encouraged. Security for DB2 9 in any environment should be considered from the moment the project is visualized. Building “security in” from the launch of the project provides a secure foundation, allowing the layering of security depth going forward. When you are following this approach, upfront analysis, planning, and documentation should precede any actual physical setup work. The DB2 response file provides robust information about the specific parameters that you can customize for the DB2 9 install. Regardless of the installation method, reviewing the DB2 response file with a focus on security is recommended. The parameters in this file can spur knowledge transfer, trigger thoughts on a security approach, and can provide a background for detailed discussions about how best to implement or retrofit security. The file can also serve as foundational documentation for the environment because it can include comments. A configured response must be protected in the same manner you would use to protect any security document that could provide a hacker with sensitive information. Given the symbiotic interaction between DB2 9 and the Windows operating system, a Windows system administrator should be consulted early in the analysis phase for insight and recommendations for hardening the Windows environment prior to installing the DB2 product base. If this is not possible and the DBA has to do these tasks, prior training regarding the Windows operating system is highly recommended. During the install, DB2 9/Windows-specific security features—including response files, db2_extsecurity, support for two-part names, and support for Active Directory—should be

116


considered. Windows settings and database environment settings should also be reviewed after the install. After the product has been installed, the process of security becomes an ongoing concern between the DBAs and the Windows system administrators. Review, mitigation, and test cycles should be the norm. Fixpacks, patches, and service packs should be tested and applied as soon as possible after their release as a part of a controlled approach to robust security in depth. Physical security should not be overlooked. Because of the decreasing size of hardware, machines housing highly sensitive information are getting smaller and smaller and may no longer qualify for a full “server room” treatment with controlled access. Without strong physical security controls, all the previous work to secure the database is moot because failure to control physical access is equivalent to turning over the keys to the database.

CHAPTER

5

Authorization—Authority and Privileges

I

have the authority, and it would be my privilege, to authorize your entry into the realm of DB2 security.

FIRST WORDS Remember the house in Chapter 3, “Understanding Identification and Authentication—The First Line of Defense”? We talked about the lock on the front door of the house as the first line of defense, just like authentication is the first line of defense for database security. What if each door inside the house had a lock, too? Locking individual rooms can be considered a second line of defense and is fundamental to a “defense-in-depth” security approach. In this analogy, each room’s lock represents an authorization requirement that determines whether an individual has the right to access a database object. Different tenants (users) have different keys (authority or privilege sets) that confer the right to access certain rooms (sets of data and database objects). This chapter discusses the different options and reviews some security best practices that can help in authority/privilege and object ownership management.

TERMINOLOGY Although the definitions of object owner and authorization ID (auth ID) might seem obvious, in fact, they are a little complicated. As you read through the remaining material in this chapter, you might want to refer to the following definitions to help clarify these terms.

117

118

Chapter 5 • Authorization—Authority and Privileges

Object Owner As you might expect, from a DB2 perspective, the object owner is the authorization ID identified to the system as owning the object. In other words, when any object is created, DB2 must assign an authorization ID as the owner of the newly created object. As such, that authorization ID is required by DB2 to maintain any required privileges for the specific object (if any) and, depending on the type of object, DB2 also provides certain implicit privileges on that object. Although the initial owner of an object is assigned by DB2 based on the authorization ID of the statement that created that object, you can change object ownership at any time by using the TRANSFER OWNERSHIP SQL statement. The consequences of an object owner losing privileges vary depending on the type of SQL object in question. With the exception of routines, if the object owner were to lose privileges required for accessing the underlying object, the SQL object would be dropped or would become inoperative. If the object is a routine, the REVOKE itself would fail with a SQLCODE of -478. To illustrate, authorization ID NEWTON has been granted SELECT privilege on table BOSS.T1. NEWTON then creates a view, NEWTON.V1, which selects from the table BOSS.T1. If the SELECT privilege on the table BOSS.T1 is revoked from NEWTON, the view NEWTON.V1 becomes inoperable (provided the PUBLIC group does not hold the required privilege). If the object is a routine (function, stored procedure, or method), the REVOKE SQL statement fails with SQLCODE of -478. For example, authorization ID NEWTON has been granted EXECUTE privilege on function BOSS.F1, and NEWTON creates a new function, NEWTON.F2, which is sourced from BOSS.F1. If PUBLIC does not hold the EXECUTE privilege on the function BOSS.F1, any attempt to revoke the EXECUTE privilege on function BOSS.F1 from NEWTON is restricted. SQLCODE of -478 will be received, and the REVOKE SQL statement will fail.

Authorization ID In Chapter 3, the difference between user ID and authorization ID (auth ID) was discussed. It is the authorization ID (and not the user ID) that is used for DB2 authorization purposes. The initial authorization ID for a connection is acquired as part of the authentication process and is typically the uppercase version of the user ID (unless customized logic within a customized authentication security plug-in is used). This type of authorization ID is referred to as a user authorization ID and represents a unique individual within DB2. There are also group authorization IDs, which represent a collection of individuals. The actual membership of each group is defined and controlled outside of the database. A list of relevant group auth IDs for any given user auth ID is gathered as part of the authentication process and is typically (unless a customized group plug-in is in use) the uppercase version of each group name associated with the external user ID.

Best Practices

119

The principles of primary authorization ID, secondary authorization ID, system authorization ID, session authorization ID, routine invoker authorization ID, routine definer authorization ID, package authorization ID, and statement ID are detailed in Appendix F, “Glossary for Authorization ID.”

Static SQL Object A static object is a SQL object that was created by an authorized user (initial owner of the object) using data definition language (DDL) or a static SQL statement. These objects are considered static because the required privileges of the object owner are checked on the underlying object only at the time of creation. After that, the object is considered valid as long as the object owner holds the privileges on the underlying object (that is, the privileges are not revoked using a REVOKE statement), and no additional checking is done on the subsequent use of the object.

BEST PRACTICES As with any technology project, someone has undoubtedly “been there, done that.” From a security standpoint, it is a good idea to seek out and emulate these best practices to avoid the pitfalls that others have already discovered. Let’s begin our research into best practices by reviewing some well-known principles of security and discovering how they apply to DB2. Authorization is the main security mechanism within the DB2 database to help you protect your data. When considering database authorization, it is important that you follow the three foundational principles of good security control: • Need to know • Least privilege • Separation of duties Equally important is having clearly defined processes for controlling and reviewing all privileges and authorities. This implies that you will have a thorough set of policies and procedures, as discussed in Chapter 2, “DB2 Security—The Starting Point.”

Need-to-Know One of the first security principles introduced in any security-based curriculum is “need to know.” Just as the name implies, this principle states that an individual should have access only to the data necessary to complete the tasks that fulfill his or her specific job roles within an organization. No extraneous information beyond that absolutely required should be provided. Need-toknow applies a standard of minimal information and, implicitly, minimal risk.

120


An example of applying the need-to-know principle is accomplished by creating a view to implement read access control for both the rows and columns on the underlying table. The view is created as a need-to-know enforcement, enabling the user to access only the required data rows or data columns. The users do not need to know what the CEO earns, so they will not be able to see that information when they retrieve rows from the view. Creating this type of view is actually quite simple. Using the HR.SALARY_TABLE as an example, you can create a view such as db2 "CREATE VIEW MY_SALARY AS (SELECT SALARY FROM HR.SALARY_TABLE WHERE EMP_NAME = SESSION_USER)"

And grant each employee SELECT privilege on the view: db2 "GRANT SELECT ON HR.MY_SALARY TO KEESA"

As a result, each employee can only retrieve the rows from the view that show his or her own salary information. The user keesa (with a user auth ID KEESA) can see her salary, but cannot see any other employee’s salary.

Least Privilege The security concept of “least privilege” requires that each individual is given (granted) only the most restrictive set of privileges needed for the performance of authorized tasks. This principle complements the need-to-know security privilege and is designed to further reduce risk. Least privilege enforces minimal rights as a “risk-limiting” approach. An example of applying least privilege is granting UPDATE privilege at the individual column level instead of granting the UPDATE privilege on the entire table. To illustrate, consider the JTB.HOURS table. The supervisor is tasked with updating the allowable sick leave time for each employee. To calculate the allowable sick leave, the supervisor needs to be able to read all rows and columns in the JTB.HOURS table but only needs to update one of them. Recognizing the concept of least privilege, the DBA applies restrictive rights, as follows: db2 "GRANT SELECT ON TABLE JTB.HOURS TO KEESA" db2 "GRANT UPDATE(SICK_LEAVE) ON TABLE JTB.HOURS TO KEESA"

Now, the user keesa (with a user auth ID KEESA) can read all the data in the table but can only update the SICK_LEAVE column. Another possible application of least privilege might involve using an alternative dynamic SQL authorization model such as DYNAMICRULES(BIND). In this scenario, only one authorization ID has the privileges required (the package owner). All others can gain privileges only when dynamic SQL is issued from within that particular package. (Of course, they must have EXECUTE privileges on that package.) In other words, if a package is bound with DYNAMICRULES(BIND), any user who has access to the package and runs it “inherits” the privileges associated with the authorization ID that bound the package. The inherited privilege is effective only within the scope of executing the package.

Best Practices

121

Separation of Duties The methodology of “separation of duties” applies a checks-and-balances approach to a secure implementation. The mechanisms of this security principle require that critical tasks be divided among two or more individuals to ensure that one person cannot independently complete tasks that would impose a security risk. Separation of duties among individuals decreases the likelihood of fraud (collusion excepted, of course). There are two types of separation of duties: static and dynamic. Static separation of duties imposes the restriction that one individual cannot have two conflicting job roles. Dynamic separation of duties imposes the restriction (at privilege execution time) by enforcing a policy that one individual cannot perform two conflicting job roles at the same time. You can use customized DB2 security plug-ins to implement dynamic separation of duties by separating each duty into different namespaces. (See Chapter 3 for information on security plugins.) For example, if Joe is a financial statement auditor but can also act as an accountant for a company, we can implement the two namespaces—auditor and accountant—and have the customized security plug-in use two different auth IDs depending on which namespace Joe is connected to. If Joe functions as an accountant for certain tasks, he connects using the Joe\accountant login. For this work, the auth ID JOE_ACCT allows him to act as an accountant, and he should not be able to access auditor-specific information. When Joe needs to perform his duty as an auditor, he connects as Joe\auditor. The auth ID JOE_AUDITOR is now in use, and Joe should be able to access only auditing information granted to the auth ID JOE_AUDITOR.

Processes to Control and Review Periodic review of privileges and object ownership, removal of unnecessary privileges, and appropriate approval for the addition of privileges are vital process flows to ensure that the basic security tenants of need-to-know, least privilege, and separation of duties are enforced and maintained. These principles are foundational for any secure implementation and should follow the written security policies and guidelines of the corporation. One extremely important role is that held by the DBA, who performs the task of allowing database and object access. This process of “granting” access is kin to opening the door to the database guests. As such, it is a key function for process control and review. Limiting the ability to apply database GRANTS to only those “security-knowledgeable” and responsible individuals is important to minimize risk. Obviously, these individuals must be required to follow the security policies and procedures to ensure that appropriate approval has been obtained before they begin the process of granting privileges. Using db2audit (discussed in Chapter 9, “Database Auditing and Intrusion Detection”) to capture SECMAINT events will provide an audit trail that can be reviewed to determine the grantor of any undesired privilege. Using this information (extracted from the db2audit logs) is highly recommended for auditing this type of critical security task because it will provide a layer of accountability and add depth to

122


your security implementation. The audit trail information can also be invaluable for process review and refinement because it can be used to raise questions such as “Why did our DBA have to GRANT READ on the SYSIBM tables to 30 new users?”

Avoid Granting to Groups For busy DBAs, it is tempting to grant authority and privilege to a group of users via the group authorization ID. This makes authority and privilege management much simpler but may violate the security principles of least privilege and need to know. Because group membership is assigned outside the database (see Chapter 3), assigning privileges and authorities to groups might mean that the DBA who grants to groups has to trust that those groups are properly maintained so that users inherit only the specific authorities they need and nothing more. Without adequate communication and controls, it is possible that a user may be assigned inappropriate or excessive group membership designations and, therefore, excessive privileges.

Due Diligence Authority or privilege should be granted based only on legitimate need-to-know reasons. The minimum required (least) authority or privilege should be granted. Thus, it is important for the DBAs to keep their knowledge current and understand all the available authorities and privileges available in DB2 before beginning the process of granting access. Consider, too, that application developers have conflicting priorities and do not always have security in mind during development. They might use a higher level of authority than required to make the testing and development effort smoother. Thus, it is important for the DBA to review any authority or privileges granted as part of the application installation or configuration to ensure it adheres to the least-privilege principle.

Documentation Made Easy (or at Least Easier) As mentioned in Chapter 2, policies must be put in place to document access controls. As part of this effort, READ and WRITE access for each table should be clearly defined. One method that is easy to implement and useful to facilitate the documentation effort is the COMMENT feature (an SQL construct). When creating comments, remember that the comment that is set will be stored in the DB2 system catalog tables and can be retrieved via appropriate DB2 SYSCAT views. For example, table comments are stored in SYSCAT.TABLES, index comments are stored in SYSCAT.INDEXES, and so on. Subsequent SQL statements can be used to retrieve this information by inspecting the

Best Practices

123

REMARKS column from the associated SYSCAT view. For example, to set a comment for the HR.SALARY_TABLE, issue this command: COMMENT ON HR.SALARY_TABLE IS 'ACCESS POLICY = ACC-1002; last reviewed 09/2006'

Once set, any user who has been granted SELECT on SYSCAT.TABLES can retrieve the comment by issuing this SQL statement: SELECT REMARKS FROM SYSCAT.TABLES WHERE TABSCHEMA = 'HR' AND TABNAME = 'SALARY_TABLE'

Using Schemas for Control and Management of Database Objects When managing a database that is shared by many functional areas/users within the company, it is important to be able to identify “who owns what.” One simple solution is to define a “wall” and develop a set of rules to ensure that whereas each functional area has access to their own objects, they are prevented from getting to objects on the other side of the wall. The DB2 schema can act as this wall. Schemas are database objects that provide the ability to group database objects together while still logically separating them within the same DB2 database. Schemas provide the ability to separately “name qualified” objects within the same database. To reduce the user’s access to only those database objects necessary for performance of their particular job functions, logically grouping the database objects into schemas facilitates the granting of appropriate access. The goal is to build a barrier for each functional area, allowing them to create, drop, and alter SQL objects of their own while logically remaining separate from other users’ objects. The need-to-know principle is observed because users only “know” about their own objects and only have access to their own objects within the schema. Of course, one way to provide this level of separation is to have a database for each user/project, but that would cause a management nightmare. The better alternative is to separate the database objects using different schemas. For example, if a database is used for code management (version control) purposes and there is more than one project occurring simultaneously, using separate schemas can avoid interference. Perhaps, both projects need a table with exactly the same name. It might not make sense from a versioning standpoint to share the table between the two projects. With two separate schemas, however, the two tables can be built, each with the same name, but stored in separate schemas. When appropriate access permissions are granted, each project uses its own independent version of the table. By default, the database-level authority IMPLICIT_SCHEMA is granted to PUBLIC unless the database is created using the RESTRICTIVE option (discussed later in this chapter). As a general rule, IMPLICIT_SCHEMA should be revoked from the PUBLIC group for several reasons because it provides the ability for any user to create a new schema whether the user realizes he or she has

124


done so. Many DBAs revoke this authority as a matter of course because it makes the task of schema management easier. IMPLICIT_SCHEMA authority can be revoked using the DB2 Control Center or by connecting to the database (to revoke IMPLICIT_SCHEMA, the user must hold DBADM or SYSADM authority) using the command line: db2 "REVOKE IMPLICIT_SCHEMA ON DATABASE FROM PUBLIC"

Obviously, those users who hold DBADM or SYSADM still have the ability to create any schema name that does not yet exist as deemed necessary. Regular users (unless they have been given additional authorities), however, can now create only a schema explicitly or implicitly that matches the authorization ID of the connection session (session authorization ID). For example, user boss (with user auth ID BOSS) cannot successfully issue the command CREATE SCHEMA ZURBIE despite the fact that the schema ZURBIE does not exist. Revoking IMPLICIT_SCHEMA from PUBLIC is a good practice in most database environments. If a schema name other than the one that matches the SESSION auth ID is needed (perhaps the schema name WEBSPHERE is needed, for example), the best approach is to contact the database administrator (DBADM) and security administrator (SECADM) to perform the following steps: 1. The DBADM user issues this: db2 "CREATE SCHEMA WEBSPHERE";

2. The schema WEBSPHERE is created and owned by the DBADM. 3. The SECADM user issues this: db2 "TRANSFER OWNERSHIP PRESERVE PRIVILEGE"

OF

SCHEMA

WEBSPHERE

TO

USER

BOSS

The schema is now owned by the authorization ID BOSS. The new owner, BOSS, can then revoke all the privileges that the DBADM has on the schema WEBSPHERE. (Note that DBADM is a super-privileged user in the database, so this will not stop any DBADM attempts to access any object in the transferred schema. However, this step helps reduce the unnecessary privilege, which is a step closer to the principle of least privilege.) If an identical set of objects is required by more than one user (as in the version control scenario discussed previously), DB2 provides the built-in function SYSPROC.ADMIN_COPY_SCHEMA to facilitate this task. This built-in function provides the ability to copy an arbitrary source schema (which may be different from the current schema) to an arbitrary target schema. This task may be accomplished with or without data and provides the option to transfer ownership of all new objects as part of the task. If the transfer ownership option is not specified, the owner of the target objects is the connected user. If a new owner is specified, however, ownership of the new objects is transferred to the new owner without additional effort.

Best Practices

125

Avoid Granting to PUBLIC Granting any authority or privilege to the special DB2 group PUBLIC implicitly provides any user with that same granted authority or privilege. In fact, the CONNECT privilege itself can be granted to PUBLIC, which would mean that any successfully authenticated user will have the ability to log on to the database. Although allowing the PUBLIC group to hold privileges and authorities might ease the DBA administrative burden, the security risk for any production (and most other) databases is typically far too great to tip the balance in favor of letting PUBLIC retain any authority. Obviously, the foundational least-privilege and need-to-know security principles are violated when the PUBLIC group holds authority or privilege. To avoid “overgranting” and assuming unnecessary risk, database privileges and authorities should be given only to a specific target, whether a single user or a group. The safest route, therefore, is to avoid granting any authority or privilege to PUBLIC and to revoke any privileges and authorities currently held by this group.

Restricting the PUBLIC from the Start With DB2 9, the DBA’s burden of revoking all PUBLIC grants has been taken into account. DBAs now have the option of creating any new databases using a new keyword option RESTRICTIVE. The use of this keyword during the CREATE DATABASE command means that the new database will be created without the normally granted PUBLIC privileges. In other words, the implicit grants to PUBLIC are omitted during the creation of the database. You can specify the keyword RESTRICTIVE on the CREATE DATABASE command or specify SQL_DB_RESTRICT_ACCESS_YES for the restrictive field in the SQLEDBOPTIONS data structure parameters embedded within the SQLEDBDESCEXT structure when using CREATE DATABASE API (that is, SQLECREA). You can find out whether the database is created with the restrictive set by querying the database configuration parameter RESTRICT ACCESS. Figure 5.1 shows an example of a database being created without restrictive option. This is verified by obtaining the value of the “Restrict access” database configuration parameter. C:\>db2 create db JRJTKB DB20000I The CREATE DATABASE command completed successfully. C:\>db2 get db cfg for JRJTKB : Restrict access

Figure 5.1

grep –i restrict = No

Determining whether the database was created via the “restrictive” clause

126


Without the Protection of “Restrictive” If the database were created without using the RESTRICTIVE option, or if it were migrated from a previous release, the RESTRICTIVE option is not available, and the PUBLIC group is likely to hold privileges that should make most DBAs nervous. Fortunately, you can revoke these. Before any REVOKE statements are performed to remove privileges from the PUBLIC group, the DBA might want to discover what rights this group actually has. This is a good practice because after privileges have been removed, they might need to be regranted to users or groups who had previously not specifically needed them because they could use the “inherited” privileges. One way to determine the privileges currently held by the PUBLIC group is to run the following SQL query. db2 "SELECT OBJECTSCHEMA, OBJECTNAME, OBJECTTYPE, PRIVILEGE FROM SYSIBMADM.PRIVILEGES WHERE AUTHID = 'PUBLIC'"

During a default database-creation operation, DB2 implicitly grants the following set of privileges to PUBLIC. (Some of the privileges exist only if the database was migrated from a previous version.) • CREATETAB privilege • BINDADD privilege • CONNECT privilege • IMPLSCHEMA privilege • EXECUTE with GRANT on all procedures in schema SQLJ • EXECUTE with GRANT on all functions and procedures in schema SYSPROC • EXCEUTE and BIND on all packages created in the NULLID schema • CREATEIN on schema SQLJ • CREATEIN on schema NULLID • USE on tablespace USERSPACE1 • SELECT access to the SYSIBM catalog tables • SELECT access to the SYSCAT catalog views • SELECT access to the SYSCATV82 catalog views • SELECT access to the SYSSTAT catalog views • UPDATE access to the SYSSTAT catalog views

Best Practices

127

Easy Public Revokes You can revoke PUBLIC privileges via REVOKE SQL statements or via the Control Center. If using the Control Center, the DBA can use the Show SQL option to view the SQL before it is applied. Because it is likely that these privileges will need to be regranted to specific users or groups, saving the SQL to a file is highly recommended. The file can serve as a foundation for regranting least privilege to specific users and groups. The Control Center example in Figure 5.2a, 5.2b, and 5.2c steps through the process of using the Control Center to save the SQL statements. In this example, only the CONNECT privilege REVOKE statement is shown because it was the only option selected to be revoked. However, there is no restriction on choosing multiple items to revoke simultaneously. In other words, the DBA can select as many (or as few) options as desired, and the SQL for all the options to be revoked will display when the Show SQL button is selected.

Figure 5.2a

128


Figure 5.2b

Figure 5.2c

Using the Control Center to save the SQL for PUBLIC revokes

Authorities

129

AUTHORITIES The complementary terms authority and privilege refer to mechanisms used to give an authorization ID the ability to perform an operation or access data. Let’s begin with clarifying these two terms. Authority is a predefined role or entity with certain privileges at the instance or database level. There are two types of authorities: instance-level authority and database-level authority. Privilege is held at the individual SQL object level inside the database. Figure 5.3 shows the hierarchy of authorities at the instance and database levels. Note in the diagram that the authority on the parent node encompasses the authority of the child node. SYSADM is the root authority of all authority and privileges except SECADM.

Instance-Level Authority There are four instance-level authorities: system administration authority (SYSADM), system control authority (SYSCTRL), system maintenance authority (SYSMAINT), and system monitor authority (SYSMON).

130

SYSADM

SYSCTRL DBADM

SYSMAINT

LOAD

CONNECT

BINDADD

CREATETAB

SECADM

CREATE_NOT_ FENCED_ROUTINE

SYSMON

Figure 5.3

Hierarchy of authorities

QUIESCE_ CONNECT


CREATE_EXTER NAL_ROUTINE

IMPLICITSHEMA

Authorities

131

Table 5.1 provides a brief summary and comparison of each instance authority level. Table 5.1

Instance-Level Authorities

Authority

Description

SYSADM

Highest level of administrative authority for DB2 Has control over all the resources created and maintained by the Database Manager for the instance Has implicit DBADM authority within any database under the instance Grants and revokes SECADM authority within any database under the instance Designed for DB2 administrators who need to have full access to utilities and data

SYSCTRL

Highest level of system control authority for DB2 Performs all operations affecting system resources for the instance Does not allow access to any data inside the database unless the user or group has been explicitly granted the privilege to access the data and the privilege to connect to the database Designed for users administrating instances that have sensitive data in one or more databases within the instance

SYSMAINT

Second highest level of system control authority for DB2 Performs maintenance operations on all the databases for the instance Does not allow access to any data inside the database unless the user or group has been explicitly granted the privilege to access the data and the privilege to connect to the database Designed for users maintaining databases in an instance where one or more databases contains sensitive data

SYSMON

Lowest level of system control authority for DB2 Takes database system monitor snapshots of the instance and any database inside the instance Cannot alter system resource usage Does not allow access to any data inside the database unless the user or group has been explicitly granted the privilege to access the data and the privilege to connect to the database Designed for users monitoring databases in an instance

Acquiring and Revoking Instance-Level Authority As in previous versions of DB2, instance-level authority is acquired via group membership. The groups themselves are typically set up and managed by the Linux, UNIX, or Windows system

132


administrators. The DBA’s role is to make sure that the appropriate group names for each of these highly privileged roles are then identified to DB2. Once the system authority groups are created, they are provided to DB2 via updates to the corresponding Database Manager Configuration (DBM) parameters: SYSADM_GROUP, SYSCTRL_ GROUP, SYSMAINT_GROUP, and SYSMON_GROUP. For example, if user "newton" (user auth ID “NEWTON”) belongs to the group build (group auth ID “BUILD”), and this group is designed as the system administrator group for a DB2 instance, the DBM would be updated with this information via the command: db2 "UPDATE DBM CFG USING SYSADM_GROUP BUILD"

After the UPDATE DBM CFG command completes successfully, any member of the group BUILD will be a SYSADM for the instance. Note that you must stop (db2stop) and restart (db2start) the instance after issuing the UPDATE DBM CFG command for the new parameter to take effect. Removing SYSADM authority for a particular user requires that user’s ID be removed from the SYSADM group. For example, when newton’s ID is removed from the build group by the AIX admin, newton’s days as a SYSADM are over. Things change. Fortunately, changing the SYSADM group to a completely different group can be accomplished at any time by issuing another update DBM CFG parameter command to set the value for the new group. If a new group, JTB_GRP, has been created by the AIX system administrator, for example, and should now replace the former group as the SYSADM group for the instance, the commands to accomplish this would be as follows: db2 "UPDATE DBM CFG USING SYSADM_GROUP JTB_GRP"; db2stop; db2start;

Now, the users who belong to the AIX group JTB_GRP hold SYSADM authority, and the users who belong to the previous group do not (unless their IDs have been moved into the new group). SYSADM (and DBADM)—Things to Avoid

As you can imagine, SYSADM and DBADM authorities deserve a lot of consideration given their high level of privilege. Individuals who hold these designations should also be individuals who are well versed in security as it applies to day-to-day database operations. In some special situations, performance of their daily tasks can introduce risk unless these individuals take care to avoid implicitly passing on elevated privileges. For example, a privileged user who holds SYSADM or DBADM authority is often tasked with performing operations such as precompiling or binding a package or creating a static SQL object. It

Authorities

133

is important to be aware that elevated privileges can be inadvertently passed to the end user during these types of operations. If a user holding DBADM were to issue the command db2 "BIND PACKAGE jtb.bnd"

the OWNER authorization ID for the bound package would be that of the user holding the DBADM authority. If you consider the risk of these types of “inherited” ownership operations, it becomes obvious that users holding DBADM should avoid being the owners of the package or the static SQL object to avoid passing on indirect inheritance of elevated privileges to the end user. Users holding DBADM can avoid this risk by specifying an appropriate value for the OWNER clause when precompiling or binding a package. To bind the package specifying an owner, the DBADM could call the BIND command as follows: db2 "BIND PACKAGE jtb.bnd OWNER KEESA"

Now, the owner of the package is the user keesa (with user auth ID "KEESA"), not the DBADM. In the case of object creation, the DBADM can use the SET SESSION_USER statement to create the object on behalf of the actual designated owner. As an example, to set this value before creating any new objects for the user auth ID "KEESA", the DBADM issues this command: db2 "SET SESSION_USER = KEESA"

All objects created in this SQL session will now be owned by user auth ID "KEESA". By not using SYSADM or DBADM as object owners, the principle of least privilege is enforced, and no additional authority or privileges are given to the end user indirectly. Note, too, that if a user holding SYSADM performs operations such as bind or precompile, DB2 will implicitly grant DBADM authority to the SYSADM. In most environments, these “super-privileged” authorities should be kept separate. Allowing the SYSADM to also hold DBADM would violate the principle of least privilege and would compromise inherent separation of duties. For this reason, allowing those users with SYSADM to “inherit” DBADM authority in this manner is strongly discouraged. Default Versus Security—Let Security Win This One All four database manager configuration parameters—SYSADM_GROUP, SYSCTRL_GROUP, SYSMAINT_GROUP, and SYSMON_GROUP—default to NULL for a new installation. Also, if the Database Manager Configuration is reset (db2 "reset dbm cfg") these values return to NULL. Think back to your first programming class. What does NULL mean exactly…the absence of something? Don’t let it mean the absence of security for your DB2 instance. On UNIX and Linux installations, a NULL value for the SYSADM_GROUP forces DB2 to allow SYSADM authority for any user who belongs to the primary group of the instance owner. If the primary group of the instance owner contains more than one user, any other users who also belong to that same primary instance owner group can act as SYSADM for this instance. To illustrate, if the IDs kbond and jbond are both part of the instance owner group instgrp, and the value for the

134


DBM parameter SYSADM_GROUP is left as the installation default (NULL), either jbond or kbond can act as SYSADM for this instance. Obviously, this may or may not be the desired result; but

either way, it is not a sound practice. On Windows installations, a NULL value for the SYSADM_GROUP means DB2 allows SYSADM operations by any user in the local administrators group on the local system. Again, the default might not provide a solid approach to securing DB2 instances. Although the instance will function even if the System groups are set to NULL, leaving these parameters at their defaults defies best security practices and is strongly discouraged. When things are “working,” it might be tempting to continue the status quo; so it is important to set these values right after any new instance is created. That way, when the environment is ready, the DBA does not have to make a maintenance window to assign the appropriate groups for the DBM.

Database-Level Authority Ten database-level authorities can be granted or revoked: • DBADM (database administrator) • SECADM (security administrator) • CONNECT • BINDADD • CREATETAB • CREATE_EXTERNAL_ROUTINES • CREATE_NOT_FENCED_ROUTINE • IMPLICIT_SCHEMA • LOAD • QUIESCE_CONNECT Table 5.2 provides a brief summary and comparison of each database authority level. Table 5.2

Database-Level Authorities

Authority

Description

DBADM

The second highest level of administrative privilege next to SYSADM. Privileges are restricted to an individual database within an instance. Designed for administrators who require full access to data and objects inside the database but do not require the maintenance capability that SYSCTRL or SYSMAINT possesses. (continues)

Authorities

Table 5.2

135

Database-Level Authorities (Continued)

Authority

Description It includes all the database-level authorities except SECADM and implicitly has all privileges within the database except those reserved for SECADM. When DBADM authority is granted to an auth ID, all other database level authorities except SECADM will also be implicitly granted to the same auth ID. After revoking the DBADM from an auth ID, the other implicitly granted database-level authorities remain, and they must be explicitly revoked from the auth ID as deemed necessary.

SECADM

A companion authority to DBADM. Provided to handle security matters inside the database such as transferring ownership of an object and creating, dropping, altering, granting, and revoking of objects that are part of LBAC. Does not allow access to any data unless explicitly granted. This authority possesses power that SYSADM or DBADM authority does not. Primarily used for security purposes.

CONNECT

Allows the user to connect to the database after successful authentication.

BINDADD

Allows the user to create new packages in the database.

CREATETAB

Allows the user to create a new table in the database.

CREATE_EXTERNAL_ROUTINE

Allows the user to create an external routine in the database. Note: CREATE_EXTERNAL_ROUTINE authority will be implicitly (automatically) granted to the same auth ID when the auth ID is granted the CREATE_NOT_FENCED_ROUTINE authority. CREATE_EXTERNAL_ROUTINE authority cannot be revoked from the auth ID if the auth ID still possesses the CREATE_ NOT_FENCED_ROUTINE authority.

CREATE_NOT_FENCED_ROUTINE

Allows the user to create a routine that is not fenced, meaning it is running inside the address space of an agent. Also referred to as a “trusted” routine.

IMPLICIT_SCHEMA

Allows the user to implicitly create schemas that do not already exist.

LOAD

Allows the user to invoke the load utility. Additional privileges on the target table may be required depending on the option specified.

QUIESCE_CONNECT

Allows the user to connect to the database while it is in a quiesced state.

136


Maintain Separation To ensure critical separation of security duties, a database administrator (DBADM) should not also hold security administrator authority (SECADM) or vice versa. If it is necessary to have a single user perform both these high-level security functions, other appropriate monitoring processes (including appropriate DB2 auditing of SECMAINT events) should be in place to provide accountability. Granting and Revoking Database-Level Authorities The SQL statement GRANT (database authorities) is used to grant database authority to a user auth ID (that is, USER clause), group auth ID (that is, GROUP clause), or PUBLIC. The SQL statement REVOKE (database authorities) is used to revoke a database authority from a user auth ID (that is, USER clause), group auth ID (that is, GROUP clause), or PUBLIC. Optionally, you can use the Control Center to grant and revoke database-level authorities. Some exceptions apply. For security reasons, DBADM authority cannot be granted to PUBLIC. SECADM authority, which should be conferred only to the most trusted individuals, can only be granted to a user auth ID and not to a group. Similar to instance-level authorities, only grant the minimum required (least) privilege necessary. For example, users should not be granted DBADM just because they need to load data into a table. In this case, users should be granted only the combination of LOAD authority and any required SELECT, INSERT, UPDATE, or DELETE privileges on the table. BY ALL Revocation Approach

When revoking an authority or a privilege, it is important to understand the BY ALL approach used by DB2. This means that the privilege(s) are revoked from the specified list of user or group auth IDs or PUBLIC regardless of who granted it. For example, the user auth ID SEE has been granted CREATETAB authority by database administrator 1. A System Administrator has subsequently granted user auth ID SEE DBADM authority (which automatically granted all other database-level authorities, including CREATETAB authority). After a privilege/authority review, user auth ID SEE has been found to have excess authority and privilege. All database authorities are revoked from authID SEE by the System Administrator who issues the following REVOKE SQL statement: db2 "REVOKE CONNECT, BINDADD, CREATETAB, CREATE_EXTERNAL_ROUTINE, CREATE_NOT_FENCED_ROUTINE, IMPLICIT_SCHEMA, LOAD, QUIESCE_CONNECT, DBADM ON DATABASE FROM USER SEE [BY ALL]"

BY ALL is the default regardless of whether you specify it. After the completion of the REVOKE statement, the CREATETAB authority granted by database administrator 1 is also implicitly revoked because of the BY ALL logic.

Authorities

137

How Can Current Authorities Be Determined? The GET AUTHORIZATIONS CLP command is an effective way to find out what authorities one currently holds. The DB2 API sqluadau also provides similar functionality, and it can be embedded in a program. Both the GET AUTHORIZATIONS command and the sqluadau API output exclude providing information for the SECADM authority. SECADM authority can be determined by reviewing the catalog view SYSCAT.DBAUTH. Listing 5.1 shows the output of the GET AUTHORIZATIONS command for the instance owner SEE who has just created a database. Listing 5.1

Get Authorizations Output

db2 => GET AUTHORIZATIONS Administrative Authorizations for Current User Direct SYSADM authority = NO Direct SYSCTRL authority = NO Direct Direct Direct Direct Direct

SYSMAINT authority DBADM authority CREATETAB authority BINDADD authority CONNECT authority

= = = = =

NO YES YES YES YES

Direct CREATE_NOT_FENC authority Direct IMPLICIT_SCHEMA authority Direct LOAD authority Direct QUIESCE_CONNECT authority Direct CREATE_EXTERNAL_ROUTINE authority Direct SYSMON authority Indirect SYSADM authority Indirect SYSCTRL authority

= = = = = = = =

YES YES YES YES YES NO YES NO

Indirect SYSMAINT authority Indirect DBADM authority Indirect CREATETAB authority

= NO = NO = YES

Indirect Indirect Indirect Indirect Indirect Indirect Indirect Indirect

= = = = = = = =

BINDADD authority CONNECT authority CREATE_NOT_FENC authority IMPLICIT_SCHEMA authority LOAD authority QUIESCE_CONNECT authority CREATE_EXTERNAL_ROUTINE authority SYSMON authority

YES YES NO YES NO NO NO NO

138


To find out whether the auth ID SEE has SECADM, connect to the database and issue the following SQL statement (assuming you have SELECT access privileges to the SYSCAT.DBAUTH view): db2 "SELECT SECURITYADMAUTH FROM SYSCAT.DBAUTH WHERE GRANTEE = 'SEE'"

Alternatively, you can discover all the database-level authorities granted to a particular auth ID by issuing the following SQL statement: db2 "SELECT GRANTOR, DBADMAUTH, SECURITYADMAUTH, CONNECTAUTH, BINDADDAUTH, CREATETABAUTH, EXTERNALROUTINEAUTH, NOFENCEAUTH, IMPLSCHEMAAUTH, LOADAUTH, QUIESCECONNECTAUTH FROM SYSCAT.DBAUTH WHERE GRANTEE = ''"

Direct Authority Versus Indirect Authority As you can see in the output from the GET AUTHORIZATIONS command in the preceding section, a user can obtain an authority by having it directly granted to their authorization ID. What may not be as obvious is that the authority can also be given indirectly if it is granted to a group authorization ID to which the user belongs or if the authority has been granted to PUBLIC. A user can have an authority from both direct and indirect sources. For example, by default, the database creator (the user that issues the CREATE DATABASE command) has both direct CREATETAB and indirect CREATETAB (via PUBLIC) authorities. Note that if the database is created with the RESTRICTIVE option, the database creator will not have CREATETAB via PUBLIC (indirect) authorities. Note that no one will have direct SYSADM, SYSCTRL, SYSMAINT, or SYSMON. This is because these authorities are acquired via group membership, which is external to DB2. Recall from Chapter 3 that group membership can be defined on the operating system if the default operating system–based group plug-in is used, via LDAP if the IBM-shipped LDAP-based group plug-in is used, or any other external mechanism as defined by a customized group plug-in.

PRIVILEGES SQL Objects and Their Privileges In Figure 5.4, privileges are organized into a hierarchy with the arrow pointing to the parent privilege on the left. For example, control privilege on a table includes all the other table-level privileges. On the right side of the graphic, the oval circle indicates which catalog view can be examined to determine the privileges that have been granted.

Privileges

139

Index

Control

Package

Control

SYSCAT. INDEXAUTH

DBADM

Bind, Execute SYSCAT. PACKAGEAUTH

Routine

Execute

Schema

Alterin, Createin, Dropin

Security Lable

All access, Read access, Write access

Sequence

Usage Alter

SYSCAT. SEQUENCEAUTH

Server

Pass through

SYSCAT. PASSTHRUAUTH

Tablespace

Use

SYSCAT. ROUTINEAUTH

SYSCAT. SCHEMAAUTH

SYSCAT. SECURITYLABELACCESS

Privileges Privileges

Table, view, nickname

Control

XSR Object

Usage

SYSCAT. TBSPACEAUTH Delete, Insert, Select, Update; Table, nickname onlyAlter, Index, References SYSCAT. TABAUTH SYSCAT. XSROBJECTAUTH

Privileges that are associated with a SQL object Privileges that are not associated with a SQL object Exemption (on one or all access rule for a specified LBAC security policy)

setsessionuser

Figure 5.4

DB2 privileges

Exemption

Setsessionuser

SYSCAT. SECURITYPOLICYEXEMPTIONS

SYSCAT. SURROGATEAUTHIDS

140


You can also obtain the privilege information using the PRIVILEGES administrative view. For example, to obtain the privilege granted for any procedure for all authorization IDs, you can issue the following: db2 "SELECT AUTHID, PRIVILEGE, OBJECTNAME, OBJECTSCHEMA FROM SYSIBMADM.PRIVILEGES WHERE OBJECTTYPE = 'PROCEDURE'"

Table 5.3 provides a brief summary and comparison of each privilege. Table 5.3

DB2 Privileges Summary

Object

Privilege

Description

Index

CONTROL

Allows the user to have control on the index. This privilege is used on drop index only.

Package

CONTROL

Allows the user to rebind, drop, and execute the package and grant package privileges to others.

BIND

Allows the user to bind or rebind the package or create a new version of the package.

EXECUTE

Allows the user to execute the package.

Routine (function, procedure and method)

EXECUTE

Allows the user to execute the routine.

Schema

ALTERIN

Allows the user to alter objects defined in that schema.

CREATEIN

Allows the user to create objects defined in that schema.

DROPIN

Allows the user to drop objects defined in that schema.

ALL ACCESS

Allows the user read and write access with the security label.

READ ACCESS

Allows the user read access with the security label.

WRITE ACCESS

Allows the user write access with the security label.

USAGE

Allows the user to use NEXTVAL and PREVVAL expressions for the sequence.

ALTER

Allows the user to alter sequence properties using ALTER SEQUENCE statement.

Server

PASSTHRU

Allows the user to access and use a specified data source in a pass-through mode in a federated environment.

Tablespace

USE

Allows the user to create tables in a specified tablespace.

Security label

Sequence

(continues)

Privileges

Table 5.3

141

DB2 Privileges Summary (Continued)

Object

Privilege

Description

Table, view, nickname, materialized query table (MQT), staging table

ALL

This keyword allows every available privilege, including CONTROL, to be granted to the user. The user has all rights to the object. Gives the user all privileges on the table, view, MQT, staging table, or nickname, and the ability to grant those privileges to others (except CONTROL). Allows the user to alter the definition of the table or the nickname.

CONTROL

ALTER

(table and nickname) DELETE

Allows the user to delete rows in the table, MQT, staging table, or updatable view. To delete a row from a nickname, the delete privilege on the nickname is required in addition to the required privilege at the data source for the delete operation.

INDEX (table

and nickname) INSERT

REFERENCES

(table) SELECT

UPDATE

XSR object

USAGE

Allows the user to create an index on a table or an index specification on a nickname. Allows the user to insert data into a table, an updatable view, an MQT, and a staging table and run the import utility against a table, an updatable view, an MQT, and a staging table. To insert or import into a nickname, the insert privilege on the nickname is required in addition to the required privilege at the data source for the delete operation. Allows the user to create or drop a foreign key referencing the table as parent. Allows the user to retrieve data, create encapsulated objects such as a view referencing the table, and run the export utility against the object. Allows the user to issue an update statement on the object. Allows the user to use the XML schema (XSR object). Currently, usage privilege on XSR objects can be granted only to PUBLIC.

Exemption on one or all access rules for a specified LBAC security policy

EXEMPTION

Allows the user to access a protected table without the exempted rule being enforced.

Setsessionuser

SETSESSIONUSER

Allows the user to use the SET SESSION AUTHORIZATION statement to set the session authorization ID to a specified authorization ID.

142


A security label access or exemption rule can be granted only to user auth IDs (USER). It cannot be granted to a group auth ID (GROUP) or PUBLIC. The setsessionuser privilege cannot be granted to PUBLIC. GRANTED WITH and CONTROL—More Than You Bargained For?

As mentioned previously, privileges can be granted or revoked using the Control Center or via SQL statements. Although DB2 makes granting easy, it is up to the DBA to truly understand both the explicit and implicit operations performed during this process to avoid granting more than intended. Specifying the WITH GRANT OPTION on the GRANT SQL statement allows the target authorization ID (that is, grantee) to, in turn, GRANT the received privileges to other user auth IDs or group auth IDs. The WITH GRANT OPTION can be specified on the GRANT SQL statement when granting privileges associated with packages, routines, schemas, sequences, tablespaces, tables, views, MQTs, staging tables, and nicknames. Note that using the WITH GRANT OPTION is a risky approach to take because the grants can cascade from one user to another. This is likely to violate the enterprise’s security policies and is not a good practice even in development environments. Using this option introduces some significant risk into the database environment. Tables, indexes, views, MQTs, staging tables, nicknames, and packages can be granted to users or groups with CONTROL privilege. CONTROL privilege provides the recipient with elevated privileges, including the ability to DROP the object in question or GRANT privileges to others. Given the breadth of the risk, allowing CONTROL privileges to be granted on objects in the database is not a sound security practice. Any attempt to grant the CONTROL privilege along with the WITH GRANT OPTION will result in a warning, and the WITH GRANT OPTION will not be applied for the CONTROL privilege. For packages, tables, views, MQTs, staging tables, and nicknames, granting CONTROL to an auth ID will cause all other object-level privileges to be granted to the auth ID, too. You cannot revoke individual privileges without first revoking the CONTROL privilege from the auth ID. To illustrate some of the pitfalls, consider the following scenario.

• User auth ID JBOND is successfully granted privileges as follows: SQL 1

db2 "GRANT SELECT, CONTROL ON TABLE DB2ASAM.EMPHIST_AUDIT TO USER JBOND"

Privileges

143

• The DBA runs the following SQL to determine the privileges held by JBOND: SQL 2 db2 "SELECT CHAR(TABSCHEMA,7) AS SCHEMA, CHAR(TABNAME,14) AS TABNAME, CHAR(CONTROLAUTH,1) AS C, CHAR(ALTERAUTH,1) AS A, CHAR(DELETEAUTH,1) AS D, CHAR(INDEXAUTH,1) AS X, CHAR(INSERTAUTH,1) AS I, CHAR(REFAUTH,1) AS R, CHAR(SELECTAUTH,1) AS S, CHAR(UPDATEAUTH,1) AS U FROM SYSCAT.TABAUTH WHERE GRANTEE = 'JBOND'"

• The DBA is confused to discover that JBOND has more privileges than expected: SCHEMA TABNAME C A D X I R S U ------- -------------- - - - - - - - DB2ASAM EMPHIST_AUDIT Y G G G G G G G

By granting CONTROL ON TABLE DB2ASAM.EMPHIST_AUDIT, the DBA also implicitly granted all these other privileges to JBOND and also gave JBOND the ability to grant those privileges to others. At this point, the DBA discovers that a mistake was made and that the user who should get CONTROL ON TABLE DB2ASAM.EMPHIST_AUDIT is actually KBOND. User JBOND should have only SELECT privilege on the table. • The DBA attempts to remove DELETE, INSERT, UPDATE, and REFERENCES privileges for user JBOND, but receives an error: SQL 3 db2 "REVOKE DELETE, INSERT, UPDATE, REFERENCES ON TABLE DB2ASAM.EMPHIST_AUDIT FROM USER JBOND" DB21034E The command was processed as a SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0558N An attempt to revoke a privilege from "JBOND" was denied because "JBOND" would still hold "CONTROL" authority. SQLSTATE=42504

• To REVOKE the extra privileges from JBOND, the DBA must first revoke CONTROL on the table: SQL 4 db2 "REVOKE CONTROL ON TABLE DB2ASAM.EMPHIST_AUDIT FROM USER JBOND" DB20000I The SQL command completed successfully.

• Now the DBA again runs SQL 3 to revoke DELETE, INSERT, UPDATE, and REFERENCES on the table from JBOND. This time, the command completes successfully. However, there is still a problem. When the DBA again runs SQL 2 to

144


recheck the privileges held by JBOND on the DB2ASAM.EMPHIST_AUDIT table, the user still has more privileges than desired: SCHEMA TABNAME C A D X I R S U ------- -------------- - - - - - - - DB2ASAM EMPHIST_AUDIT N G N G N N Y N

• The DBA realizes that the ALTER and INDEX privileges were also implicitly granted with the CONTROL privilege and now must be revoked: SQL 5 db2 "REVOKE ALTER,INDEX ON TABLE DB2ASAM.EMPHIST_AUDIT FROM USER JBOND"

• Rerunning SQL 2 to check again, the DBA determines that the inappropriate grants to user JBOND are now reversed and that SELECT is the only remaining privilege held by JBOND on the EMPHIST_AUDIT table: SCHEMA TABNAME C A D X I R S U ------- -------------- - - - - - - - DB2ASAM EMPHIST_AUDIT N N N N N N Y N

When it comes to granting privileges, less is definitely more. You should grant only the minimum required (least) privilege to the need-to-know user or group of users. For example, if the user needs to INSERT and UPDATE some rows in a table, you should grant only those two privileges to the user. Never grant more than required.

IMPLICIT GRANTED AUTHORITIES AND PRIVILEGES As briefly discussed in the preceding sections, implicitly granted authorities or privileges are automatically granted by DB2 when certain database operations are performed. Because these are granted outside the normal database policies and procedures, these implicit authorities or privileges should be well understood by the DBA and SECADM. These implicit privileges should be revoked if deemed necessary. All implicitly granted authorities or privileges will have SYSIBM (that is, DB2 system) as the grantor listed on the corresponding system catalog table. You can find out how many rows of these authorities or privileges existed in the database by invoking the following SQL statement: SELECT 'DATABASE' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.DBAUTH WHERE GRANTOR = 'SYSIBM' UNION SELECT 'TABLESPACE' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.TBSPACEAUTH WHERE GRANTOR = 'SYSIBM' UNION SELECT 'TABLE' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.TABAUTH WHERE GRANTOR = 'SYSIBM' UNION

Implicit Granted Authorities and Privileges

145

SELECT 'PACKAGE' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.PACKAGEAUTH WHERE GRANTOR = 'SYSIBM' UNION SELECT 'ROUTINE' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.ROUTINEAUTH WHERE GRANTOR = 'SYSIBM' UNION SELECT 'INDEX' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.INDEXAUTH WHERE GRANTOR = 'SYSIBM' UNION SELECT 'COLUMN' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.COLAUTH WHERE GRANTOR = 'SYSIBM' UNION SELECT 'SCHEMA' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.SCHEMAAUTH WHERE GRANTOR = 'SYSIBM' UNION SELECT 'PASSTHRU' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.PASSTHRUAUTH WHERE GRANTOR='SYSIBM' UNION SELECT 'SECURITY LABEL ACCESS' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.SECURITYLABELACCESS WHERE GRANTOR='SYSIBM' UNION SELECT 'SECURITY POLICY EXEMPTIONS' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.SECURITYPOLICYEXEMPTIONS WHERE GRANTOR='SYSIBM' UNION SELECT 'SEQUENCE' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.SEQUENCEAUTH WHERE GRANTOR='SYSIBM' UNION SELECT 'XSROBJECT' AS TYPE, COUNT(*) AS COUNT FROM SYSCAT.XSROBJECTAUTH WHERE GRANTOR='SYSIBM' ORDER BY 1, 2;

Table 5.4 summarizes the cases where implicit privileges are granted. Table 5.4

Implicit Privileges Summary Recipient of the Privileges/Authorities

Operation

Implicit Privileges/Authorities

Create a new database

DBADM and all database level authorities The creator of the database. except SECADM • CREATETAB authority PUBLIC unless the • BINDADD authority restrictive option is speci• CONNECT authority fied on CREATE • IMPLSCHEMA authority DATABASE. • EXECUTE with GRANT privilege on all procedures in schema SQLJ • EXECUTE with GRANT privilege on all functions and procedures in schema SYSPROC • BIND privilege on all packages created in the NULLID schema

(continues)

146

Table 5.4


Implicit Privileges Summary (Continued)

Operation


Create a new database.

• EXECUTE privilege on all packages created in the NULLID schema • CREATEIN privilege on schema SQLJ • CREATEIN privilege on schema

Recipient of the Privileges/Authorities

NULLID

• USE privilege on tablespace USERSPACE1

• SELECT privilege to access the SYSIBM catalog tables • SELECT privilege to access the SYSCAT catalog views • SELECT privilege to access the SYSCATV82 catalog views • SELECT privilege to access the catalog views • UPDATE privilege to update the SYSSTAT catalog views Grant DBADM to an auth ID.

All other database level authorities except The auth ID of the recipient of DBADM.

SECADM

Execute create schema statement.

CREATEIN, ALTERIN, DROPIN schema

Execute a create statement without qualifying the object name with the schema and the schema does not exist yet (that is, schema is implicitly created by DB2).

CREATEIN, ALTERIN, DROPIN schema

CREATEIN schema privilege

PUBLIC

Creating a table, creating an index, or binding a new package.

CONTROL privilege on the table or index

Initial owner of the object.

Create a view.

CONTROL privilege on the view if the user has CONTROL privilege for all the

privilege on newly created schema

privilege

The initial owner of the schema. If the authorization clause is specified, the initial owner is the specified authorization ID; otherwise, it is the session authorization ID. The initial owner of the object that causes the schema to be implicitly created.

or package. Initial owner of the view.

tables, views, and nicknames referenced in the view definition (continues)

Authorization Checking for SQL Statements

Table 5.4

147

Implicit Privileges Summary (Continued)

Operation


Create SQL stored procedure (packaged procedure).

CONTROL privilege on the hidden

internally generated package*

The first time SYSADM creates Assumes the SYSADM does not already a view, trigger, routine or binds have the required privilege or DBADM a new package. explicitly to perform the create or bind, and so DB2 implicitly grants DBADM

Recipient of the Privileges/Authorities Initial owner of the routine. SYSADM

*To find the hidden internally generated packages, execute the following query:

SELECT DEP.BNAME, DEP.BSCHEMA FROM SYSIBM.SYSDEPENDENCIES DEP, SYSCAT.PROCEDURES PROC WHERE PROC.PROCNAME = '' AND PROC.PROCSCHEMA = '' AND DEP.DTYPE = 'L' AND DEP.DNAME = PROC.SPECIFICNAME AND DEP.DSCHEMA = ''

AUTHORIZATION CHECKING FOR DB2 COMMANDS AND UTILITIES When invoking DB2 commands (such as an update on a Database Manager Configuration parameter) or utilities (such as LOAD) via the CLP or API interfaces, authorization checking is done at the time of execution of the command. The authorization ID used for checking is the system authorization ID. If a connection to a database or an attachment to the instance is required for the command or utilities, DB2 uses the authorization ID associated with the user ID that is used for the authentication (that is, the system authorization ID) regardless of whether a SET SESSION_USER SQL statement has been issued. If no connection or attachment is required, DB2 uses the authorization ID associated with the user ID that is currently logged on. Group privileges are also considered.

AUTHORIZATION CHECKING FOR SQL STATEMENTS To understand how authorization checking is done for SQL statements, you need to understand the statement authorization ID concept and the different authorization models available in DB2.

Statement Authorization ID This authorization ID is used for authorization checking for a SQL statement. The statement authorization ID is also the owner of the object when a DDL (data definition language) statement is issued to create a SQL object (such as CREATE VIEW). Packages, too, are owned by the statement authorization ID that performs the precompile or bind operation unless the OWNER option is specified as part of the precompile or bind command.

148


Different Authorization Models Available in DB2 Just as there are two different types of SQL (static and dynamic), there are two key SQL authorization models used in DB2. A static authorization model is used for authorization checking during the creation of static SQL objects. Static SQL object operations include operations such as CREATE VIEW and precompiling or binding (that is, bind time) for a package that contains static SQL statements. With a static SQL statement, the syntax is fully known at compile time. This differs from a dynamic SQL statement, where the exact SQL syntax is not known until the actual runtime execution. In the static authorization model, the user auth ID of the initial owner of the SQL object, which is the statement authorization ID, is used for authorization checking. Group privileges associated with the object’s initial owner are not considered. (The only exception is if the PUBLIC group holds the privilege.) The actual privilege checking is done during the SQL object creation, such as during the precompile or bind time, for a static SQL package. At runtime, the end user requires only access to the static object and does not need to hold any privileges on the underlying object. For example, if a package inserts a row into a table when called, the user needs EXECUTE privilege on the package and does not need to hold INSERT privilege on the underlying table. A dynamic authorization model is used for authorization checking during the execution or runtime of a package that contains dynamic SQL statements or any DDL statements that are not used to create static SQL objects. (See the “Group Privilege Restriction” section for the list of DDL statements used to create static SQL objects). The dynamic SQL authorization model depends on the package in which that dynamic SQL is executed and the value of the DYNAMICRULES option (dynamic SQL rules) specified when the package was precompiled or bound. If the dynamic SQL rule is not specified during the PRECOMPILE or BIND of a package that contains dynamic SQL statements, the dynamic authorization model will, by default, use the session authorization ID of the connected user as the statement authorization ID for authorization checking. Similarly, the user session auth ID will be used for authorization checking for DDL statement issued in the package. Group privileges are considered during authorization checking under this model. For more information on how the DYNAMICRULES option affects the authorization checking, refer to the “Dynamic SQL Rules” section. What about the SQL statement entered through the DB2 Command Line Processor (CLP), Call Level Interface (CLI), Java Database Connectivity (JDBC), or Control Center? Although they have packages associated with them, the SQL is entered at runtime. For this reason, these SQL statements are actually dynamic SQL statements because the syntax is not known until the user enters the statement. As a result, any SQL statement (submitted via CLP or Control Center or CLI or JDBC) will use the dynamic authorization model.


149

Retrieving the Group Membership List for a Given Authorization ID You can retrieve this list of groups of which a given authorization ID is a member by using the SYSPROC.AUTH_LIST_GROUPS_FOR_AUTHID table function. For example, if you want to retrieve the list of groups for auth ID NEWTON, issue the following query: db2 "SELECT * FROM TABLE (SYSPROC. AUTH_LIST_GROUPS_FOR_AUTHID ('NEWTON')) AS T"

Note that this function works only if you are using the operating system–based group membership lookup (such as the IBM-shipped group membership lookup plug-in). If you use another mechanism, such as the LDAP group membership lookup plug-in, the list of groups might not correspond to the list of groups obtained by DB2 during authentication. Group Privilege Restriction Sometimes, the privileges granted to a group are not checked. Privileges granted to a group auth ID are not considered for SQL objects (such as tables) referenced in the CREATE TABLE/ALTER TABLE ADD CHECK CONSTRAINT, CREATE FUNCTION, CREATE INDEX EXTENSION, CREATE METHOD, CREATE PROCEDURE, CREATE SCHEMA, CREATE TABLE, CREATE TRANSFORM, CREATE TRIGGER, CREATE VIEW, and DECLARE GLOBAL TEMPORARY TABLE statements or during the binding of a package that contains static SQL statements. When thinking about why group privileges are not always checked for certain static SQL, remember that group membership is managed outside of DB2. When a user’s membership in a group is altered, therefore, this information is not dynamically communicated to DB2. Instead, DB2 obtains updated group membership information for a user only when the user re-establishes a connection to the database (and after the group membership has changed). Static SQL statements inside an embedded program and static SQL objects require continued existence of privileges for their survival. This inability to be informed of changes in privileges resulting from changes in group membership would prevent DB2 from maintaining the security integrity of the database. As a protection, the required privileges of the initial OWNER are checked on the underlying object only at the time of creation and do not include the privileges the OWNER holds as a member of a group. After that, the object is considered valid as long as the initial OWNER holds the privileges (that is, the privileges are not revoked using a REVOKE statement) and no additional checking is done on the subsequent use of the object. The following static SQL objects are affected by this restriction: CHECK CONSTRAINTS FUNCTIONS INDEX EXTENSIONS MATERIALIZED QUERY TABLES

150


METHODS PROCEDURES SCHEMAS STAGING TABLES TRANSFORM GROUPS TRIGGERS VIEWS DECLARED GLOBAL TEMPORARY TABLES STATIC SQL IN A PACKAGE

When creating any of these listed static SQL objects, the initial OWNER might need one or more of the following privileges where group privileges are not considered: ALL ACCESS (or READ or WRITE ACCESS) on security label USAGE on the underlying XSR EXECUTE on the underlying function EXECUTE on the underlying procedure EXECUTE on the underlying method USAGE on the underlying sequence CONTROL on the underlying table or the underlying view or the underlying nickname SELECT, INSERT, UPDATE, or DELETE on the underlying table or the underlying view

The following four examples are common situations encountered by DB2 DBAs in the performance of their daily responsibilities. For simplicity, assume that user auth ID USER2 belongs to only one group dbuser (group auth ID DBUSER).

Example 1 The DBA needs to create an SQC embedded program. Inside the source file is the following static SQL statement: EXEC SQL INSERT INTO USER1.T1 VALUES (:hostvar1)

When user USER2 attempts to PRECOMPILE the PACKAGE, DB2 will only check to determine whether the INSERT privilege on USER1.T1 has been granted to USER2 or PUBLIC. Even though the INSERT privilege on USER1.T1 might have been granted to group DBUSER, DB2 will not take this privilege into account.


151

Example 2: View CREATE VIEW USER2.V1 AS SELECT * FROM USER1.T2

When user USER2 attempts to create the above view, DB2 will check only whether the SELECT privilege on USER1.T2 is granted to USER2 or PUBLIC. Even though the SELECT privilege on USER1.T2 might have been granted to the group DBUSER, DB2 will not take this privilege into account.

Example 3: SQL procedure CREATE PROCEDURE USER2.PROC1 (I INTEGER) LANGUAGE SQL SPECIFIC AX BEGIN INSERT INTO USER1.T1 VALUES (I + 1000); END%

When user USER2 attempts to create the above SQL procedure, DB2 will check only whether the INSERT privilege on USER1.T1 has been granted to USER2 or PUBLIC. Even though the INSERT privilege on USER1.T1 might already be granted to group DBUSER, DB2 will not take this privilege into account.

Example 4: Sourced function CREATE FUNCTION USER2.SOURCED1 (PARM1 SHORT) RETURNS SHORT SPECIFIC SOURCED1 SOURCE USER1.F1 (SHORT);

When user USER2 attempts to create the above function, DB2 will check only whether the EXECUTE privilege on USER1.F1 is granted to USER2 or PUBLIC. Even though the EXECUTE privilege on USER1.F1 might already be granted to group DBUSER, DB2 will not take this privilege into account.

In each of these examples, the group privileges will not be considered. Because groups are managed outside of the database, DB2 would not know whether the user had been removed from the group. Dynamic SQL Rules As mentioned earlier, dynamic SQL statements by default use the SESSION authorization ID of the connected user for any authorization checking (RUN behavior). Authorization checking

152


behavior can be altered if the DYNAMICRULES option is specified when a package is created. Six values can be specified for this option: BIND RUN DEFINEBIND DEFINERUN INVOKEBIND INVOKERUN

The last four values are dual values that behave differently in a standalone program versus inside a routine environment. As a result, the six DYNAMICRULES values are mapped to four different types of behaviors—RUN, BIND, DEFINE, and INVOKE—which affect the selection of the authorization ID used for checking privileges on the underlying objects and the default qualifier used for unqualified objects. The following table shows how the six different DYNAMICRULES values behave in two environments: inside a standalone program and inside a routine. Table 5.5

Dynamic SQL Rules Standalone Program Environment

Dynamicrules Value

Behavior of Dynamic SQL Statements

BIND

BIND behavior

RUN

DEFINEBIND

DEFINERUN

RUN behavior

BIND behavior

RUN behavior

Authorization ID Used for Checking Privileges on Underlying Objects

Routine Environment

Behavior of Dynamic SQL Statements

The implicit or explicit value of the OWNER BIND option

BIND behavior

ID of User Executing Package

RUN

The implicit or explicit value of the OWNER BIND option

DEFINE

ID of User Executing Package

DEFINE

behavior

behavior behavior

behavior

Authorization ID Used for Checking Privileges on Underlying Objects The implicit or explicit value of the OWNER BIND option ID of User Executing Package Routine definer (not the routine’s package owner) Routine definer (not the routine’s package owner)

(continues)


Table 5.5

153

Dynamic SQL Rules (Continued) Standalone Program Environment

Dynamicrules Value INVOKEBIND

Behavior of Dynamic SQL Statements BIND

behavior

INVOKERUN

RUN behavior

Authorization ID Used for Checking Privileges on Underlying Objects The implicit or explicit value of the OWNER BIND option ID of User Executing Package

Routine Environment

Behavior of Dynamic SQL Statements INVOKE

behavior

INVOKE

behavior

Authorization ID Used for Checking Privileges on Underlying Objects Current statement authorization ID when routine is invoked Current statement authorization ID when routine is invoked

Note that the following SQL statements are disallowed unless you are running in a RUN behavior: GRANT, REVOKE, ALTER, CREATE, DROP, COMMENT ON, RENAME, SET INTEGRITY, and SET EVENT MONITOR STATE. The DEFINEBIND, DEFINERUN, INVOKEBIND, and INVOKERUN DYNAMICRULES options behave differently if the package is run in the standalone environment versus being run inside a routine environment. The term routine environment implies that the package is associated with an external routine (external scalar function, external table function, external method, and external stored procedure) or a SQL procedure. Authorization checking is different between the four dynamic SQL statement behaviors. The INVOKE behavior (the routine environment) and the RUN behavior (the standalone environment) requires the SESSION authorization ID who executes/invokes the routine or the package to hold all the necessary privileges for the underlying objects via either the user authorization ID, group privileges, or PUBLIC. The DEFINE behavior (the routine environment) and the BIND behavior (the standalone environment) provide a level of authority or privilege encapsulation by checking the privileges of the underlying objects against the binder authorization ID of a package or the definer authorization ID of a routine. Group privileges are not considered in this authorization checking of the underlying objects. Of course, privilege granted to PUBLIC is considered as usual. The SESSION authorization ID executing/invoking the routine or the package is required only to have the EXECUTE privilege on the package or the routine via any of the following: user privileges, group privileges, or PUBLIC.

154


Using the DEFINE behavior and the BIND behavior allows a dynamic SQL statement to use the static authorization model. When using the DB2 Stored Procedure Builder or when using the command line to create SQL stored procedures, users might not be aware that the SQL procedures they create have actually been designed as package procedures. This means that DB2 will internally generate an SQC program and precompile, bind, and then link the package with the SQL procedure, all transparent to the user. Most stored procedures are created using static SQL in the procedure body. The following CREATE PROCEDURE statement is an example. CREATE PROCEDURE USER2.SP1 (I INTEGER) LANGUAGE SQL SPECIFIC AX BEGIN CALL USER1.SP2 (I); END%

Here is the CREATE PROCEDURE USER2.SP1 written using a dynamic SQL-based procedure body: CREATE PROCEDURE USER2.SP1 (I INTEGER) LANGUAGE SQL SPECIFIC AX BEGIN DECLARE STMT VARCHAR(300); DECLARE V1 INTEGER; SET STMT = 'CALL USER1.SP2 (I)'; PREPARE ST FROM STMT; EXECUTE ST INTO V1; END%

After being converted to a dynamic SQL-based procedure body, the internal procedure package that is created and associated with the SQL procedure can also make use of the DYNAMICRULES functionality if the registry variable DB2_SQLROUTINE_PREPOPTS is set to one of the six values: BIND, RUN, DEFINEBIND, DEFINERUN, INVOKEBIND, INVOKERUN. To set this registry variable, you can use the following syntax: db2set DB2_SQLROUTINE_PREPOPTS=""

For example, if you want to use the BIND behavior for your dynamic SQL in the stored procedure body, you need to set the registry variable using the following command: db2set DB2_SQLROUTINE_PREPOPTS="DYNAMICRULES BIND"

Because setting the registry variable requires a restart of the Database Manager and because it is applied to all databases in the database instance, DB2 provides an alternative to only set this option for the scope of a connection session. By using the built-in procedure SYSPROC.SET_ ROUTINE_OPTS, you can set the DYNAMICRULES option for only the current connection session. Execute the following CALL SQL statement to enforce the BIND behavior for your dynamic SQL in the stored procedure body (for any SQL procedure created in this session): CALL SYSPROC.SET_ROUTINE_OPTS('DYNAMICRULES BIND');


155

More Ways to Encapsulate In addition to using packages and routines as encapsulating objects, views and triggers can also eliminate the need to grant authorizations to underlying objects. Let’s revisit the view MY_SALARY as an example of a way to encapsulate privileges within a view object: CREATE VIEW MY_SALARY AS (SELECT SALARY FROM HR.SALARY_TABLE WHERE EMP_NAME = SESSION_USER)

Now that the MY_SALARY view limits the employee’s ability to see information beyond his or her need to know, grant each employee SELECT on the view. This eliminates the need to give the employee access to the underlying HR.SALARY_TABLE table. (Only the VIEW DEFINER needs access to the underlying table.) If it becomes necessary to remove access to salary information for a specific user, revoking the user’s SELECT privilege on the MY_SALARY view can be accomplished without affecting any other users. Similarly, triggers can function as encapsulating objects. In Listing 5.2, a trigger is designed to function as an auditor for the insertion activity. Listing 5.2

Example on how to use “Instead of ” Triggers for Auditing Purpose

-- A simple employee table CREATE TABLE EMPLOYEE (NAME VARCHAR (1024), EMPLNUM INTEGER, DEPTNUM INTEGER) -- The exception table to store bad record that is entered CREATE TABLE BADRECORD (NAME VARCHAR (1024), EMPLNUM INTEGER, DEPTNUM INTEGER, REQUESTORID VARCHAR (1024), DATEREQUEST TIMESTAMP, REJECTREASON VARCHAR(30)) -- The transaction_record table CREATE TABLE TRANSACTION_RECORD (EMPLNUM INTEGER, REQUESTORID VARCHAR (1024), DATEREQUEST TIMESTAMP) -- User only interface with this view CREATE VIEW EMPLOYEE_VIEW AS SELECT * FROM EMPLOYEE -- Instead of trigger on the view to function as encapsulating object and auditor CREATE TRIGGER INSERT_EMPLOYEE_V INSTEAD OF INSERT ON EMPLOYEE_VIEW REFERENCING NEW AS NEW_ROW FOR EACH ROW MODE DB2SQL BEGIN ATOMIC DECLARE INVALIDREASON VARCHAR(30); SET INVALIDREASON = CASE WHEN NEW_ROW.EMPLNUM IS NULL OR NEW_ROW.EMPLNUM >-GRANT EXEMPTION ON RULE--+-access-rule-+--FOR--policy-name---> '-ALL---------' >--TO USER--authorization-name--------------------------------->
TO USER <session authorization id>

This implies that one can have complete access to all protected data of such a policy. Exemption on all the write rules would be useful if a user needs to load data into a protected table. This exemption should be granted with extra precaution because granting exemption on all rules implies the user has full write access to the protected table. It is a best practice to revoke the exemption when the access is not needed.

The Security Plan for Protecting Data

177

THE SECURITY PLAN FOR PROTECTING DATA Security Plan Meeting Participants When designing an LBAC solution, the security administrator has to work with the database administrator to create a plan; decide what data is sensitive and needs to be protected, and how the data can be protected using the LBAC objects; and to determine who owns the table data and who officially requires access to the protected data. It is the job of the security administrator to create and maintain the LBAC objects. The security administrator also has the authority to grant security labels and exemptions to users, and revoke them if access is no longer needed. After the LBAC objects are created and granted to users, users can apply the security policy to protect tables with sensitive data. As discussed in Chapter 2, “DB2 Security—The Starting Point,” a security plan should be reviewed regularly to ensure sensitive data is protected and user access to protected data is properly granted.

Designing the Security Solution Designing an LBAC solution to protect table data involves several steps. First, you need to analyze and identify the security requirements: • Which table contains sensitive data • What data is sensitive and needs to be protected • The level of data restrictions required Then, you need to determine who is allowed to access the protected data and the level of access. After the security requirements have been established, the next step is to design the security solution with the LBAC objects. When designing the security solution, you need to consider the following: • The row and column security labels that need to protect the columns and rows • The user security labels that grant users the appropriate access • The security label components that create the security labels • Any exemptions required to bypass certain access restrictions

178

Chapter 6 • Label Based Access Control

Activity Overview for Implementing an LBAC Solution Implementing an LBAC solution requires the following steps: 1. Create the security label components, which are essential elements for creating the security policy in the next step. 2. After the security label components are created, define the LBAC security policies by specifying what security label components are to be used. 3. Then, create the security labels for the security policy using the elements of the security label components associated with the security policy. 4. With the security policy and security labels ready, the security administrator can grant security labels to users to create protected tables. 5. The SECADM then needs to grant the security labels to users for accessing the protected table. Currently, LBAC does not offer an approach to alter the security label format, base security policy attributes, or elements in a security label component. Therefore, the design phase for an LBAC solution is a crucial step to be sure security objects are created that meet the security needs. See Figure 6.3 for a graphical overview of the necessary steps to enable an LBAC solution.

Manipulating Data in Protected Tables

Authid with CREATE table privilege

179

SECADM

User

Create Security Label Component

Create Security Policy

Create Security Label

Grant security label to authid(U) to create protected tables

Create protected table

Grant security label to authid(U) to create protected tables

Grant Exemption on access rule to authid(U) if needed

Operate on Protected Table

Figure 6.3 The activity diagram demonstrates the workflow used to apply LBAC to enable access controls on database tables

MANIPULATING DATA IN PROTECTED TABLES Data manipulation includes read, write, and delete records. Actions are done by SELECT, INSERT, UPDATE, and DELETE SQL statements. When data is manipulated in protected tables, the user security label is compared with the security label protecting the row or column according to the access rules defined by the security policy.

180


Insert Data Records into Protected Tables To populate a protected table with data, you can use the INSERT statement to write one record at a time. Similar to inserting data to a regular table, the authorization ID of the statement must have INSERT privilege on the table. The authorization ID of the session needs the following to insert a record into a row protected table successfully: • Hold a security label with write access that belongs to the security policy which protects the table • May need to hold an exemption on one or more write access rules of the security policy that protects the table When inserting a record into a row protected table, you are not required to explicitly specify the security label for the DB2SECURITYLABEL column in the INSERT statement. By default, the security label granted to the user for write access is used. Users can also INSERT with any value that the LBAC write access rules allow them to. The DB2 system compares the user’s security label and the security label used for insertion based on the access rules used by the security policy. Depending on how the security policy is created, there are two possible outcomes if the write access rule is violated: • If the security policy is created with the option RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL, the INSERT operation fails and an error is returned. • If the OVERRIDE NOT AUTHORIZED WRITE SECURITY LABEL option is specified in the CREATE SECURITY POLICY statement, or no option is specified, the INSERT operation is successful. However, the default write security label is used rather than the security label specified by the user. No error is returned. When inserting a record into a column-protected table, one or more columns is attached to a security label. The user’s security label will be compared with the security label that protects the column. If the comparison fails, the record is not inserted into the table. A user can hold only one security label for read access and one security label for write access. Those security labels could be the same or different. If the user does not have a read security label but has a write security label, the user could still INSERT a record using the VALUES clause because such an INSERT requires only write access. However, the user cannot read the record after INSERT.

Retrieve Data Records from a Protected Table Data records are retrieved from a protected table in a number of ways, such as with SELECT statements. The authorization ID of the statement is required to have SELECT privilege on the table, and the session authorization ID needs to be granted with a security label with read access or exemption on read access rule in some cases.

Manipulating Data in Protected Tables

181

For tables with protected rows, each record (row) contains a security label. When a user issues a SELECT query on the protected table, the security label granted to the user for read access is compared with the security label in the record. The read access rule determines whether the record is returned in the result set. No error is returned if the user is not allowed to read a record. For tables with column protection, each protected column is attached to a security label. The security label is stored in the system catalog table SYSCAT.COLUMNS. When a user issues a SELECT query on a column-protected table, the security label granted to the user for read access will be compared with the security labels that are attached to the columns. The read access rule determines whether the user is allowed to read the column. If read access is not allowed, an error is returned and no rows will be returned.

Update Data Records in a Protected Table To update a table, the authorization ID of the statement is required to have UPDATE privilege on the table. Similar to inserting data records into a protected table, to successfully update records into a protected table, the session authorization ID must have been granted with a valid security label or exemption to read and write the record. Updating a row involves reading a row and writing new values to the row. Therefore, the user must hold a security label allows them to read the protected row, and a security label with write access or exemption to write new values to the protected field. If the user is updating unprotected fields, no security label with write access is required. When you are updating a table with a protected column, the access restrictions apply only when updating the protected column. If a table contains some protected columns, but no protected rows, users are not required to hold a security label with write access if they want to update unprotected columns. If executing an UPDATE statement does not update a record due to an LBAC restriction, the user may or may not see an error message. The behavior can be summarized as follows. Table 6.5

Result of UPDATE Operation Based on Read-and-Write Security Labels Granted

Has READ Access?

Has WRITE Access?

Result of UPDATE

Yes

Yes.

Successful

Yes

No, but has write security-label granted. Security policy is created with RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL option.

Fail with error SQL20402N. The authorization ID does not have the LBAC credentials to perform the UPDATE operation on the table. continues

182


Table 6.5 Result of UPDATE Operation Based on Read-and-Write Security Labels Granted (Continued) Has READ Access?

Has WRITE Access?

Yes

No, but has write security label granted. Security policy is created with OVERRIDE NOT AUTHORIZED WRITE SECURITY LABEL option.

Result of UPDATE Successful, but the write security label of the session authorization ID will be used in the UPDATE operation.

Yes

No write security label is granted.

Fail with error SQL20402N.

No

—

Failed because no row is fetched. SQL0100W returned.

Delete Data Records from a Protected Table To delete records from a table, the authorization ID of the statement is required to have DELETE privilege on the table, and the session authorization ID needs to be granted with a security label with read-and-write access, or exemption on the access rules in some cases. When a user attempts to delete some protected rows from a table, only the set of rows that the user is allowed to read and write can be removed from the table. If a user cannot read a row, the row appears to be invisible to the user and cannot be deleted. No error is returned. If a user can read the row, then, when trying to delete the row, the user’s write security label is compared to the security label that is protecting the row. If the user does not have write access to the row, the DELETE statement fails. Error SQL20264N is returned. When deleting rows in a table with protected columns, the user must have write access to all the protected columns in the table. Otherwise, SQL20264 is returned.

MANIPULATING DATA WITH SECURITY LABEL WITH SET SECURITY LABEL COMPONENT Inserting with a Security Label of SET Security Label Component An INSERT operation needs to satisfy the DB2LBACWRITESET access rule when a table is protected with security labels of the SET security label component. The DB2LBACWRITESET requires that the elements in the security label protecting the row/ column need to be a subset of the elements in the write security label of the session authorization ID to insert a record successfully.

Manipulating Data with Security Label with SET Security Label Component

183

Scenario The EMPLOYEE table contains sensitive data. Employees can view records of others in the same department. The SALARY column has restrictive access and can only be viewed by managers. Managers cannot write to the SALARY column. Note that for the sake of simplifying the example, all references to prerequisite privileges have been removed but the reader is reminded that table privileges are still required for any access to a protected table prior to LBAC enforcement. A security label component is created for protecting the EMPLOYEE table. • SLC_DEPT of SET component type is created with elements {‘D001’, ‘D002’, ‘D003’, ‘MGMT’} based on the departments in the company. A security policy EMPLOYEE_POLICY is created with SLC_ DEPT security label components, with the RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL option. The following security labels are created: Security Label Row security labels: EMPLOYEE _POLICY.SL_D001 EMPLOYEE _POLICY.SL_D002 EMPLOYEE _POLICY.SL_D003

Security label component elements D001 D002 D003

Column security labels: EMPLOYEE_POLICY.SL_MGMT

MGMT

User security labels: EMPLOYEE _POLICY.SL_D001_M EMPLOYEE _POLICY.SL_D002_M EMPLOYEE _POLICY.SL_D003_M

D001, MGMT D002, MGMT D003, MGMT

The EMPLOYEE table is protected by the EMPLOYEE_POLICY. The SEC_LABEL column stores the security label which identifies the department that an employee belongs to. The record for a manager would tag with the ‘MGMT’ element. The Salary column is protected by the SL_MGMT security label. The EMPLOYEE table contains the following records. Table 6.6

EMPLOYEE Table

EMPNO

FIRSTNME

LASTNAME

PHONE

SEC_LABEL

SALARY (Attached to SL_MGMT)

121

Joe

Cool

905-384-2642

SL_D001

65000

211

Ray

Summer

905-979-2321

SL_D002

60000

321

Jane

Lu

416-343-3432

SL_D003

70000 continues

184

Table 6.6


EMPLOYEE Table (Continued)

EMPNO

FIRSTNME

LASTNAME

PHONE

SEC_LABEL

SALARY (Attached to SL_MGMT)

111

Mike

Smith

416-343-3566

SL_D001_M

80000

212

Carol

Mo

647-804-2232

SL_D002_M

85000

311

Peter

San

416-784-3343

SL_D003_M

90000

Users of the EMPLOYEE table are granted with security labels. Table 6.7

Security Labels Granted to Session Authorization ID

Session authorization ID

Read security label

Write security label

JOEC

SL_D001

None

RAYS

SL_D002

None

JANEL

SL_D003

None

MIKES

SL_D001_M

SL_D001

CAROLM

SL_D002_M

SL_D002

PETERS

SL_D003_M

SL_D003

Example Mike tries to insert a record into the EMPLOYEE table by executing the following statement: INSERT INTO EMPLOYEE (EMPNO, FIRSTNME, LASTNAME, PHONE, SEC_LABEL) VALUES ('122', 'Katy', 'Sun', '905-212-5533', SECLABEL_BY_NAME('EMPLOYEE_POLICY', 'SL_D001'))

The INSERT operation is successful because the row security label contains only the element ‘D001’, which is the subset of his write security label {‘D001’}. Mike does not have the authority to write to the SALARY column because his write security label contains the ‘D001’ element only, but the SALARY column is protected by a security label with element ‘MGMT’. The INSERT would fail if the SALARY column is not nullable and does not have a default value.


185

The EMPLOYEE table now becomes this. Table 6.8

EMPLOYEE Table

EMPNO

FIRSTNME

LASTNAME

PHONE

SEC_LABEL

SALARY

121

Joe

Cool

905-384-2642

SL_D001

65000

122

Katy

Sun

905-212-5533

SL_D001

211

Ray

Summer

905-979-2321

SL_D002

60000

321

Jane

Lu

416-343-3432

SL_D003

70000

111

Mike

Smith

416-343-3566

SL_D001_M

80000

212

Carol

Mo

647-804-2232

SL_D002_M

85000

311

Peter

San

416-784-3343

SL_D003_M

90000

Example Mike is assisting Carol. He tries to insert a record for her department by issuing this: INSERT INTO EMPLOYEE (EMPNO, FIRSTNME, LASTNAME, PHONE, SEC_LABEL) VALUES ('216', 'Alex', 'Wood', '905-434-7454', SECLABEL_BY_NAME('EMPLOYEE_POLICY', 'SL_D002'))

Mike is holding a write security label with elements {‘D001’}. However, he is using a security label with security label component elements {‘D002’}. Because ‘D002’ is not in the subset of the user security label {‘D001’}, the DB2LBACWRITESET rule is violated. Because the EMPLOYEE_POLICY is created with the RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL option, the statement would fail during execution. SQL20402N is returned. The authorization ID does not have the LBAC credentials to perform the INSERT operation on table. No record is inserted. If EMPLOYEE_POLICY is created with the OVERRIDE NOT AUTHORIZED WRITE SECURITY LABEL option, the INSERT operation will succeed, but the SECL_LABEL column will be inserted with SL_D001 because it is the write security label granted to Mike.

Retrieve Data Records Protected by SET Security Label Component Elements When a table is protected with security labels of the SET security label component, a SELECT operation needs to satisfy the DB2LBACREADSET access rule.

186


The DB2LBACREADSET requires that the elements in the security label protecting the row/column need to be a subset of the elements in the read security label of the session authorization ID to insert a record successfully. When data is retrieved from a protected table, the read security label of the session authorization ID will be compared with the security label in the DB2SECURITYLABEL column and any security label attached to a protected column if a protected column is accessed. Example Joe is granted with the read security label SL_D001 when he issues the query SELECT * from EMPLOYEE

Access is denied because Joe does not have authority to read the SALARY column. SQL20264N is returned because the authorization ID does not have READ access to the SALARY column. Example Joe then queries the EMPLOYEE table by specifying the unprotected columns explicitly: SELECT EMPNO, FIRSTNME, LASTNAME, PHONE from EMPLOYEE

The SL_D001 is compared with the labels stored in the SEC_LABEL column. Table 6.9 the Rows

Joe’s Read Security Label Is Compared to Data Security Label for Read Access of

EMPNO

SEC_LABEL

Security Label Comparison

121

SL_D001

Allowed

122

SL_D001

Allowed

211

SL_D002

Not allowed: because SL_D001 does not contain element D002

321

SL_D003


111

SL_D001_M

Not allowed: because SL_D001 does not contain element MGMT

212

SL_D002_M

Not allowed: because SL_D001 does not contain element D002 and MGMT

311

SL_D003_M

Not allowed: because SL_D001 does not contain element D003 and MGMT

Therefore, two records are returned.


Table 6.10

187

Joe Can See the Two Rows in the EMPLOYEE Table

EMPNO

FIRSTNME

LASTNAME

PHONE

121

Joe

Cool

905-384-2642

122

Katy

Sun

905-212-5533

Joe cannot see other records because the row security labels used to protect other rows contain elements that Joe’s read security label does not have. Example Carol is granted with the SL_D002_M for read access. The security label contains the elements D002 and MGMT, which allow her to read rows protected by a security label that matches or is a subset of the two elements when she issues this query SELECT EMPNO, FIRSTNME, LASTNAME, PHONE, VARCHAR(SECLABEL_TO_CHAR('EMPLOYEE_POLICY', SEC_LABEL )), SALARY FROM CKMWONG.EMPLOYEE;

The SL_D002_M is compared with the security labels attached to protected column, SALARY, and the security label stored in the SEC_LABEL column. Table 6.11 Carol’s Read Security Label Is Compared to Data Security Label for Read Access of the Rows EMPNO

SEC_LABEL


121

SL_D001


122

SL_D001


211

SL_D002

Allowed

321

SL_D003


111

SL_D001_M


212

SL_D002_M

Allowed

311

SL_D003_M


188


The two records protected with security labels that contain any of the elements {‘D002’, ‘MGMT’} are returned. Table 6.12 Carol’s Read Security Label Is Compared to Data Security Label for Read Access of the Rows EMPNO

FIRSTNME

LASTNAME

PHONE

SEC_LABEL

SALARY

211

Ray

Summer

905-979-2321

SL_D002

60000

212

Carol

Mo

647-804-2232

SL_D002_M

85000

Example HR staff member, Nancy, is allowed to read all the records in the EMPLOYEE table. There are two ways to accomplish it: 1. Create a security label that contains all the elements. 2. Grant Nancy the DB2LBACREADSET exemption. Granting exemption is not recommended because the user can bypass the read access rules for SET security label components. You will lose control over the action of the user both for existing security labels and any security labels created in the future that is associated with the security policy.

Updating Data Records Protected by SET Security Label Component Updating protected records requires that the user has read and write access on the record. This implies that both DB2LBACREADSET and DB2LBACWRITESET access rules have to be satisfied. Example Peter holds the security label SL_D003_M for read access and SL_D003 for write access. When Peter issues the following UPDATE statement UPDATE EMPLOYEE SET LASTNAME = 'WHITE' WHERE EMPNO='321'

the row is protected by the security label SL_D003, which matches the user read security label. Because Peter is updating a nonprotected column, write security label is not required. The statement executed successfully.


189

Example Peter issues the following UPDATE statement: UPDATE EMPLOYEE SET LASTNAME = 'WHITE' WHERE EMPNO='211'

The row is protected by the security label SL_D002. The read security label that Peter holds does not contain the elements in SL_D002. Read access is violated. Message SQL0100W is returned. No row was found for SELECT, UPDATE, or DELETE; or the result of a query is an empty table. The table is not updated because Peter cannot read the row in the first place. Example Peter issues the following UPDATE statement: UPDATE EMPLOYEE SET SECLABEL = SECLABEL_BY_NAME('EMPLOYEE', 'SL_D001') WHERE EMPNO='321'

The statement fails. Peter holds the read security label SL_D003_M and thus is allowed to read the record. However, the DB2LBACWRITESET rule is violated because Peter holds the SL_D003 security label, which does not contain the element ‘D001’. Because the EMPLOYEE_POLICY is created with the RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL option, the statement would fail to execute. SQL20402N is returned because authorization ID does not have the LBAC credentials to perform the UPDATE operation on table. Example The current EMPLOYEE table contains the following Table 6.13

EMPLOYEE Table

EMPNO

FIRSTNME

LASTNAME

PHONE

SEC_LABEL

SALARY

121

Joe

Cool

905-384-2642

SL_D001

65000

122

Katy

Sun

905-212-5533

SL_D001

211

Ray

Summer

905-979-2321

SL_D002

60000

321

Jane

WHITE

416-343-3432

SL_D003

70000

111

Mike

Smith

416-343-3566

SL_D001_M

80000

212

Carol

Mo

647-804-2232

SL_D002_M

85000

311

Peter

San

416-784-3343

SL_D003_M

90000

190


Peter issues the following UPDATE statement: UPDATE EMPLOYEE SET PHONE ='905-423-8302' WHERE SECLABEL = SECLABEL_BY_NAME('EMPLOYEE', 'SL_D003')

Because Peter holds the SL_003_M security label for read access, the where clause in the UPDATE statement filters the result set to return one record. Table 6.14

Peter San Is Able to Read One Row

EMPNO

FIRSTNME

LASTNAME

PHONE

SEC_LABEL

SALARY

321

Jane

WHITE

416-343-3432

SL_D003

70000

Because Peter holds the SL_D003 security label for write access, the UPDATE is successful. Table 6.15

Peter San Is Able To Write to One Row

EMPNO

FIRSTNME

LASTNAME

PHONE

SEC_LABEL

SALARY

321

Jane

WHITE

905-423-8302

SL_D003

70000

Deleting Data Records Protected by SET Security Label Component Deleting a protected record requires the user to have read-and-write access to the record, which implies that both DB2LBACREADSET and DB2LBACWRITESET access rules have to be satisfied. Example Jane holds the security label SL_D003 for read access. When Jane issues the following DELETE statement DELETE FROM EMPLOYEE WHERE EMPNO = 321;

the statement fails to execute because Jane does not have write access on the SALARY protected column. SQL20264N is returned. The authorization ID does not have WRITE access to the SALARY column. Example Peter holds the security label sl_D003_M for read-and-write access. When Peter issues the following DELETE statement DELETE FROM EMPLOYEE WHERE EMPNO = 321;

Manipulating Data with Security Label with ARRAY Security Label Component

191

the row is protected by SL_D003, and the SALARY column is protected by SL_MGMT. Peter has READ access to the record where EMPNO equals ‘321’. However, Peter does not have WRITE access on the SALARY column because the WRITE security label SL_D003 does not contain the element ‘MGMT’. The statement failed with sqlcode SQL20264N. The authorization ID does not have WRITE access to the column SALARY column.

MANIPULATING DATA WITH SECURITY LABEL WITH ARRAY SECURITY LABEL COMPONENT Inserting with a Security Label Of ARRAY Component An INSERT operation needs to satisfy the DB2LBACWRITEARRAY access rule when a table is protected with security labels of the ARRAY security label component. The DB2LBACWRITEARRAY requires that the elements in the security label protecting the row/column cannot be higher than or lower than the elements in the write security label of the session authorization ID to insert a record successfully. INSERT is not allowed if the user’s security label value is higher or lower than the security label to be inserted.

Scenario A security label component SLC_SECLEVEL of ARRAY component type is created with elements [‘Sensitive’, ‘Confidential’, ‘Unclassified’]. A security policy ITEM_PRICING_POLICY is created with SLC_SECLEVEL security label component. One security label is created for each security level with names: SL_SENSITIVE, SL_CONFIDENTIAL, and SL_UNCLASSIFIED, for the security policy ITEM_PRICING_POLICY: Security Label: ITEM_PRICING_POLICY.SL_SENSITIVE ITEM_PRICING_POLICY.SL_CONFIDENTIAL ITEM_PRICING_POLICY.SL_UNCLASSIFIED

Component element: Sensitive Confidential Unclassified

The PRODUCT table is protected by the ITEM_PRICING_POLICY. Items that are going to be on special order for promotion are marked as SENSITIVE. Items that are new for the next season will be marked as CONFIDENTIAL. Items that are currently available are marked as UNCLASSIFIED.

192


General staff can query to see what products are available. Department managers are allowed to check any new items coming for the next season to plan ahead for space allocation. Store managers can see what items are on special order for promotion. The PRODUCT table also contains the clearance price, which is also marked as sensitive, and only store managers can access it. Department managers can change the price of products that are available on the shelf. The PRODUCT table contains the following records. Table 6.16

PRODUCT Table

ID

ITEM_NAME

PRICE

SEC_LABEL

Clearance (Protected by SL_SENSITIVE)

001

Jeans

25

SL_UNCLASSIFIED

8

002

Tees

15

SL_UNCLASSIFIED

4

003

Shoes

60

SL_CONFIDENTIAL

20

004

Plant

5

SL_CONFIDENTIAL

3

005

Carpet

100

SL_SENSITIVE

50

006

TV

300

SL_SENSITIVE

250

Users of the PRODUCT table are granted with the security labels as follows. Table 6.17

Security Labels Granted to Session Authorization ID

Session Authorization ID

Read Security Label

Harry

SL_SENSITIVE

Write Security Label SL_ SENSITIVE + Exemption on ARRAY WRITEDOWN

Randy

SL_SENSITIVE

SL_SENSITIVE

Ron

SL_CONFIDENTIAL

SL_CONFIDENTIAL

Jason

SL_UNCLASSIFIED

None


193

Example Harry tries to insert a record into the PRODUCT table by executing the following statement: INSERT INTO PRODUCT values (007, 'Lamp', 50, SECLABEL_BY_NAME('ITEM_PRICING_POLICY', 'SL_UNCLASSIFIED'), 30 )

The INSERT statement executes successfully because Harry holds the SL_SENSITIVE WRITE security label and is granted with ARRAY WRITEDOWN exemption. He can write to the SEC_LABEL column with the SL_UNCLASSIFIED security label and can insert a value into the Clearance column which is protected by SL_CONFIDENTIAL. The PRODUCT table now becomes as shown in Table 6.18. Table 6.18 PRODUCT Table ID

ITEM_NAME

PRICE

SEC_LABEL

Clearance (Nullable, Protected by SL_SENSITIVE)

001

Jeans

25

SL_UNCLASSIFIED

8

002

Tees

15

SL_UNCLASSIFIED

4

003

Shoes

60

SL_CONFIDENTIAL

20

004

Plant

5

SL_CONFIDENTIAL

3

005

Carpet

100

SL_SENSITIVE

50

006

TV

300

SL_SENSITIVE

250

007

Lamp

50

SL_UNCLASSIFIED

30

Example A customer returned some items that are no longer tracked in the PRODUCT table. Ron executed the following statement to add the item back to the table for tracking purpose: INSERT INTO PRODUCT (ID, ITEM_NAME, PRICE, SEC_LABEL) values (099, 'Sandal', 15, SECLABEL_BY_NAME('ITEM_PRICING_POLICY', 'SL_UNCLASSIFIED') )

Ron holds the write security label SL_CONFIDENTIAL. However, the DB2LBACWRITEARRAY WRITE access rule blocks him from writing with the security label SL_UNCLASSIFIED

194


because the element ‘Unclassified’ is lower than ‘Confidential’. The DB2LBACWRITEARRAY is violated if the row security label is higher or lower than the user security label. Besides, Ron’s WRITE security label blocks him from writing to the Clearance column which is protected by SL_SENSITIVE. The column security label has the element ‘Sensitive’ that ranks higher than ‘Confidential’. SQL20402N is returned. The authorization ID does not have the LBAC credentials to perform the INSERT operation on the table.

To allow Ron to write using SL_UNCLASSIFIED, you need to grant him with the DB2LBACWRITEARRAY WRITEDOWN exemption with the following statement: GRANT EXEMPTION ON RULE DB2LBACWRITEARRAY WRITEDOWN FOR ITEM_PRICING_POLICY TO USER RON

The PRODUCT table now becomes as shown in Table 6.19. Table 6.19

PRODUCT Table

ID

ITEM_NAME

PRICE

SEC_LABEL

Clearance (Nullable, Protected by SL_SENSITIVE)

001

Jeans

25

SL_UNCLASSIFIED

8

002

Tees

15

SL_UNCLASSIFIED

4

003

Shoes

60

SL_CONFIDENTIAL

20

004

Plant

5

SL_CONFIDENTIAL

3

005

Carpet

100

SL_SENSITIVE

50

006

TV

300

SL_SENSITIVE

250

007

Lamp

50

SL_UNCLASSIFIED

30

099

Sandal

15

SL_UNCLASSIFIED

Retrieve Data with a Security Label of ARRAY Security Label Component When a table is protected with security label of ARRAY security label component, a SELECT operation needs to satisfy the DB2LBACREADARRAY access rule. The DB2LBACREADARRAY rule requires the elements in the security label protecting the data to have equal or lower value than the elements in the read security label of the session authorization ID.


195

Example Harry is a store manager, and is granted with the SL_SENSITIVE security label. When Harry issues the query SELECT id, item_name, price, varchar(seclabel_to_char('ITEM_PRICING_POLICY', sec_label)), Clearance FROM PRODUCT

all records are returned. The SL_SENSITIVE security label contains the ‘Sensitive’ element from the SLC_SECLEVEL, which has the highest rank in the array. Therefore, Harry’s security label has the highest value and can read rows that are protected by security labels with a lower value. Example Ron is the department manager, and granted with the SL_CONFIDENTIAL security label. Ron issued the following query to retrieve the list of products: SELECT ID, ITEM_NAME, PRICE, SEC_LABEL from PRODUCT;

Table 6.20 Row

Compare Ron’s Read Security Label with the Product Security Label for Each

ID

SEC_LABEL

Security Label Comparison for Read Access

001

SL_UNCLASSIFIED

Allowed: ‘CONFIDENTIAL’ is higher than ‘UNCLASSIFIED’.

002

SL_UNCLASSIFIED


003

SL_CONFIDENTIAL

Allowed: Element values are equal.

004

SL_CONFIDENTIAL

Allowed: Element values are equal.

005

SL_SENSITIVE

Not allowed: ‘CONFIDENTIAL’ is lower than ‘SENSITIVE’.

006

SL_SENSITIVE

Not allowed: ‘CONFIDENTIAL’ is lower than ‘SENSITIVE’.

007

SL_UNCLASSIFIED


099

SL_UNCLASSIFIED


Six records are returned in the result set.

196

Table 6.21


Six Records Are Returned to Ron

ID

ITEM_NAME

PRICE

SEC_LABEL

001

Jeans

25

SL_UNCLASSIFIED

002

Tees

15

SL_UNCLASSIFIED

003

Shoes

60

SL_CONFIDENTIAL

004

Plant

5

SL_CONFIDENTIAL

007

Lamp

50

SL_UNCLASSIFIED

099

Sandal

15

SL_UNCLASSIFIED

Ron’s read security label contains the ‘Confidential’ element. The DB2LBACREADARRAY rule allows him to see rows protected by SL_CONFIDENTIAL and SL_UNCLASSIFIED, but he cannot access the rows protected with SL_SENSITIVE because ‘Confidential’ has a lower value than ‘Sensitive’. If Ron includes the Clearance column in the query, error SQL20264N will be returned because Ron does not have read access on the Clearance column protected by SL_SENSITIVE.

Update Data with a Security Label Of ARRAY Security Label Component Updating protected records requires the user to have read-and-write access on the record. This implies that both DB2LBACREADARRAY and DB2LBACWRITEARRAY access rules have to be satisfied. Example Ron has SL_CONFIDENTIAL for all access. Ron is granted with exemptions to WRITEDOWN. If Ron issues the following UPDATE statement: UPDATE PRODUCT SET CLEARANCE=5 WHERE ID='099'

the statement fails with SQL20264. Ron is not allowed to read the Clearance column because the ‘Confidential’ element has a lower value than the element ‘Sensitive’. Therefore, the UPDATE fails. Example If Ron tries to update the price of the ‘Sandal’ by issuing the following statement: UPDATE PRODUCT SET PRICE=10 WHERE ID='099'


197

Because Ron has read and write access to the PRICE column, the statement executes successfully. The record becomes as shown in Table 6.22. Table 6.22

One Record Is Returned to Ron

ID

ITEM_NAME PRICE SEC_LABEL

099

Sandal

10

Clearance (Protected by SL_SENSITIVE)

SL_CONFIDENTIAL

Note that the SEC_LABEL column is updated implicitly to SL_CONFIDENTIAL, the WRITE security label granted to Ron.

Delete Data with a Security Label of ARRAY Security Label Component Deleting a protected record requires the user to have read-and-write access to the record, which implies that both the DB2LBACREADARRAY and DB2LBACWRITEARRAY access rules have to be satisfied. Because the PRODUCT table contains a protected column, the session authorization ID who executes the DELETE statement is required to have write access to the protected column for the deletion to be successful. Example Ron tried to delete the product ‘Sandal’ by issuing this: DELETE FROM PRODUCT WHERE ID='099'

Ron cannot write to the protected column, Clearance. SQL20264 is returned. Ron does not have WRITE access to the CLEARANCE column. Example Randy holds the SL_SENSITIVE label for all access. If Randy executes the statement DELETE FROM PRODUCT

The records are checked as shown in Table 6.23.

198


Table 6.23 Randy’s Security Label Is Compared for Read-and-Write Access on the PRODUCT Table ID

SEC_LABEL

Security Label Comparison for Read Access

Security Label Comparison for Write Access

001

SL_UNCLASSIFIED

Yes: ‘SENSITIVE’ is higher

002

SL_UNCLASSIFIED

than ‘UNCLASSIFIED’.

No, write security label ‘SENSITIVE’ cannot write a row security label ‘UNCLASSIFIED’ unless WRITE-DOWN exemption is granted.

003

SL_CONFIDENTIAL Yes: ‘SENSITIVE’ is higher than ‘CONFIDENTIAL’.

004

SL_CONFIDENTIAL Yes: ‘SENSITIVE’ is higher than ‘CONFIDENTIAL’.

005

SL_SENSITIVE

006

SL_SENSITIVE

007

SL_UNCLASSIFIED

099

SL_UNCLASSIFIED

No, write security label ‘SENSITIVE’ cannot write a row security label ‘CONFIDENTIAL’ unless WRITE-DOWN exemption is granted.

Yes.

Yes.

Yes: ‘SENSITIVE’ is higher than ‘UNCLASSIFIED’.

No, write security label ‘SENSITIVE’ cannot write a row security label ‘UNCLASSIFIED’ unless WRITE-DOWN exemption is granted.

Therefore, Randy can read eight records but can only write two. Without LBAC ARRAY controls, Randy’s SQL statement would delete all the rows in the table. With LBAC controls, the SQL statement cannot be successful because the SQL operation cannot delete just the two rows that Randy has “write security” for and leave behind the remainder. The statement fails with SQL20402N. Randy does not have the LBAC credentials to perform the DELETE operation on the PRODUCT table. If Randy has WRITEDOWN exemption granted, the statement will succeed.

Manipulating Data with Security Label with TREE Security Label Component

199

Example Harry holds the SL_SENSITIVE security label for read and write, and has been granted with the ARRAY WRITEDOWN exemption. The security labels allow him to read and write all the rows in the PRODUCT table. If Harry executed the same DELETE statement, all the records in the table will be deleted.

MANIPULATING DATA WITH SECURITY LABEL WITH TREE SECURITY LABEL COMPONENT Insert Data with a Security Label Of TREE Security Label Component An INSERT operation needs to satisfy the DB2LBACWRITETREE access rule when a table is protected with security labels of the TREE security label component. The DB2LBACWRITETREE requires the user to have at least one element in the user security label that matches with the elements in the row security label used for the INSERT operation. INSERT is not allowed if none of the user’s security label values is equal to or an ancestor of one of the security labels to be inserted.

Scenario The SALES table contains records about sales from different regions. To restrict staff from accessing sales data of other regions, the SALES table needs to be protected. The security label component SLC_REGION is created to represent the different sales region, and will be used to protect the SALES table. The SLC_REGION contains HEAD_QUARTER as the root of the tree, followed by ‘EAST’, ‘WEST’, ‘CENTRAL’, as the child nodes, and the ‘CENTRAL’ region is divided into ‘CENTRAL_NORTH’ and ‘CENTRAL_SOUTH’. A security policy, REGION_POLICY is defined with the SLC_REGION security label component. Security labels are created for each of the elements in the SLC_REGION.

200


HEAD_QUARTER

WEST

CENTRAL

CENTRAL_SOUTH

EAST

CENTRAL_NORTH

Figure 6.4 The SALES regions of the organization is represent as a TREE security label component

The following security labels are created: Security Label: REGION_POLICY.SL_HQ REGION_POLICY.SL_EAST REGION_POLICY.SL_WEST REGION_POLICY.SL_CENTRAL REGION_POLICY.SL_CENTRAL_N REGION_POLICY.SL_CENTRAL_S REGION_POLICY.SL_REGIONS

Security Label Component: HEAD_QUARTER EAST WEST CENTRAL CENTRAL_NORTH CENTRAL_SOUTH EAST, WEST, CENTRAL

The SALES table has the following records. Table 6.24

SALES Table

ID

SALES_DATE

SALES_PERSON

SALES

REGION

SEC_LABEL

1

01/04/2006

LEE

2000

EAST

SL_EAST

2

11/04/2006

GOUNOT

3300

WEST

SL_WEST

3

30/04/2006

LUCCI

2320

CENTRAL_N

SL_CENTRAL_N

4

02/05/2006

SAI

1100

CENTRAL_S

SL_CENTRAL_S

5

20/05/2006

BROWN

2020

WEST

SL_WEST

Users of the SALES table are granted with the following security labels.


Table 6.25

201

Users’ Session Authorization IDs and the Security Labels Granted to Them

Responsibility

Session Authorization ID Read Security Label

Write Security Label

CEO

FRED

SL_HQ

None

Sales manager for East region

EASON

SL_EAST

SL_EAST

Sales manager for West region

WILLIAM

SL_WEST

SL_WEST

Sales manager for NANCY Central north region

SL_CENTRAL_N

SL_CENTRAL_N

Sales manager for Central region

CARL

SL_CENTRAL

SL_CENTRAL

General Manager for Sales

SEAN

SL_REGIONS

SL_REGIONS

Example EASON holds the SL_EAST for write access. He tries to insert a record into the SALES table as follows: INSERT INTO SALES (SALES_DATE, SALES_PERSON, SALES, REGION) values ('2006-05-24', 'Smith', 3200, 'EAST')

The INSERT statement executed successfully. The SEC_LABEL column is populated with the WRITE security label granted to EASON. The table becomes as shown in Table 6.26. Table 6.26

SALES Table

ID

SALES_DATE

SALES_PERSON

SALES

REGION

SEC_LABEL

1

01/04/2006

LEE

2000

EAST

SL_EAST

2

11/04/2006

GOUNOT

3300

WEST

SL_WEST

3

30/04/2006

LUCCI

2320

CENTRAL_N

SL_CENTRAL_N

4

02/05/2006

SAI

1100

CENTRAL_S

SL_CENTRAL_S

5

20/05/2006

BROWN

2020

WEST

SL_WEST

6

24/05/2006

SMITH

3200

EAST

SL_EAST

202


Example Carl, tries to update the SALES table on Nancy’s behalf for a sales record in CENTRALNORTH. Carl holds the SL_CENTRAL security label with contains the element ‘CENTRAL’. INSERT INTO SALES (SALES_DATE, SALES_PERSON, SALES, REGION, SEC_LABEL) values ('2006-05-24', 'Needs', 1200, 'CENTRAL_NORTH', SECLABEL_BY_NAME('REGION_POLICY', 'SL_CENTRAL_N') )

The statement executed successfully because the element ‘CENTRAL’ is the ancestor of ‘CENTRAL_NORTH’. Therefore, the DB2LBACWRITETREE access rule is satisfied. A new record is added to the SALES table. Table 6.27

SALES Table after Inserting a New Record

ID

SALES_DATE SALES_PERSON SALES

REGION

SEC_LABEL

1

01/04/2006

LEE

2000

EAST

SL_EAST

2

11/04/2006

GOUNOT

3300

WEST

SL_WEST

3

30/04/2006

LUCCI

2320

CENTRAL_NORTH

SL_CENTRAL_N

4

02/05/2006

SAI

1100

CENTRAL_SOUTH

SL_CENTRAL_S

5

20/05/2006

BROWN

2020

WEST

SL_WEST

6

24/05/2006

SMITH

3200

EAST

SL_EAST

7

24/05/2006

NEEDS

1200

CENTRAL_NORTH

SL_CENTRAL_N

Example Carl, is covering for William while William is on vacation. Carl tries to update the SALES table to add a sales record in the West region. Carl holds the SL_CENTRAL security label which contains the element ‘CENTRAL’. INSERT INTO SALES (SALES_DATE, SALES_PERSON, SALES, REGION, SEC_LABEL) values ('2006-05-25', 'GOUNOT', 2320, 'WEST', SECLABEL_BY_NAME('REGION_POLICY', 'SL_WEST') )

However, the SL_CENTRAL security label does not contain the element ‘WEST’ or its ancestor. Therefore, the statement failed with SQL20402N. Carl does not have the LBAC credentials to perform the INSERT operation on the SALES table.


203

If the REGION_POLICY is not created with the RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL option, however, a record will be inserted with the SEC_LABEL column containing the write security label of Carl; that is, SL_CENTRAL. In that case, no error message is returned. Example Nancy holds the SL_CENTRAL_N security label for all access. A sales order applies to the CENTRAL wide region. She tries to insert a record as follows: INSERT INTO SALES (SALES_DATE, SALES_PERSON, SALES, REGION, SEC_LABEL) values ('2006-05-25', 'White', 2000, 'CENTRAL', SECLABEL('REGION_POLICY', '(CENTRAL_NORTH, CENTRAL_SOUTH)') )

The INSERT statement is successful even though the security label that Nancy holds only contains the element ‘WEST’. The DB2LBACWRITETREE requires the user to have at least one element in the user security label that matches with the elements in the row security label used for the INSERT operation. Because the ‘WEST’ element matches, the record is inserted without error. The SALES table becomes as shown in Table 6.28. Table 6.28

SALES Table after Inserting a New Row

ID

SALES_DATE

SALES_PERSON SALES REGION

SEC_LABEL

1

01/04/2006

LEE

2000

EAST

SL_EAST

2

11/04/2006

GOUNOT

3300

WEST

SL_WEST

3

30/04/2006

LUCCI

2320

CENTRAL_NORTH

SL_CENTRAL_N

4

02/05/2006

SAI

1100

CENTRAL_SOUTH

SL_CENTRAL_S

5

20/05/2006

BROWN

2020

WEST

SL_WEST

6

24/05/2006

SMITH

3200

EAST

SL_EAST

7

24/05/2006

NEEDS

1200

CENTRAL_NORTH

SL_CENTRAL_N

8

24/05/2006

WHITE

2000

CENTRAL

SLC_REGION: (CENTRAL_ NORTH, CENTRAL_ SOUTH)

204


Retrieve Data with a Security Label of TREE Security Label Component When a table is protected with security label of TREE security label component, a SELECT operation needs to satisfy the DB2LBACREADTREE access rule. As with the DB2LBACWRITETREE rule, the DB2LBACREADTREE requires the user to have at least one element in the user security label that matches with the elements in the security label used to protect the data. SELECT is not allowed if none of the user’s security label values is equal to or an ancestor of the security label protecting the data.

Example The executive, Fred, is granted with security label REGION_POLICY.SL_HQ for read access. When Fred executes the query SELECT ID, SALES_DATE, SALES_PERSON, SALES, REGION, VARCHAR(SECLABEL_TO_CHAR('REGION_POLICY',SEC_LABEL)) FROM SALES

the query returns all the records in the SALES table because the HQ element is the root of the TREE, which is the ancestor of all elements. Example Nancy holds the SL_CENTRAL_N security label and issues the same query to retrieve the sales records. Table 6.29

Nancy’s Security Label Is Compared for Read Access on the SALES Table

ID

SEC_LABEL


1

SL_EAST

Not allowed: SL_CENTRAL_N does not contain element ‘EAST’.

2

SL_WEST

Not allowed: SL_CENTRAL_N does not contain element ‘WEST’.

3

SL_CENTRAL_N

Allowed.

4

SL_CENTRAL_S

Not allowed: SL_CENTRAL_N does not contain element ‘CENTRAL_SOUTH’.

5

SL_WEST

Not allowed: SL_CENTRAL_N does not contain element ‘WEST’.

6

SL_EAST

Not allowed: SL_CENTRAL_N does not contain element ‘EAST’. (continues)


205

Table 6.29 Nancy’s Security Label Is Compared for Read Access on the SALES Table (Continued) ID

SEC_LABEL


7

SL_CENTRAL_N

Allowed

8

SLC_REGION:(CENTRAL_NORTH, CENTRAL_SOUTH)

Allowed: SL_CENTRAL_N contains element ‘CENTRAL_NORTH’.

Therefore, three records are retrieved. Table 6.30

Records Returned to Nancy from the Query

ID

SALES_DATE


SEC_LABEL

3

30/04/2006

LUCCI

2320

CENTRAL_NORTH CENTRAL_NORTH

7

24/05/2006

NEEDS

1200

CENTRAL_NORTH CENTRAL_NORTH

8

24/05/2006

WHITE

2000

CENTRAL

CENTRAL_NORTH

Update Data with a Security Label of TREE Security Label Component Updating a protected record requires the session authorization ID to have read-and-write access on the record. This implies both DB2LBACREADTREE and DB2LBACWRITETREE access rules have to be satisfied. Example Carl holds the SL_CENTRAL security label for all access. He tries to fix the sales data of the record with ID ‘7’ by issuing this: UPDATE SALES SET SALES=2200, SEC_LABEL= SECLABEL('REGION_POLICY', SECLABEL_TO_CHAR('REGION_POLICY',SEC_LABEL)) WHERE ID='7'

The record is protected by SL_CENTRAL_N. SL_CENTRAL contains the element ‘CENTRAL’, which is the ancestor of CENTRAL_NORTH. Therefore, the statement executes successfully. Table 6.31

Record Is Updated in the SALES Column

ID

SALES_DATE


SEC_LABEL

7

24/05/2006

NEEDS

CENTRAL_NORTH

2200

CENTRAL_NORTH

206


Example Nancy holds the SL_CENTRAL_N security label for all access. She tries to update the sales record with ID ‘8’ by issuing this: UPDATE SALES SET SALES=2500 WHERE ID='8'

The record is protected by a security label with elements {‘CENTRAL_NORTH’, ‘CENTRAL_SOUTH’}. SL_CENTRAL_N contains the element ‘CENTRAL_NORTH’, which is one of the elements in the row security label. This satisfies the DB2LBACREADTREE access rule. Nancy tries to update an unprotected column. The write security label is updated in the SEC_LABEL column. The statement executes successfully.

Delete Data with a Security Label of TREE Security Label Component Deleting a protected record requires the session authorization ID to have read and write access on the record. This implies both DB2LBACREADTREE and DB2LBACWRITETREE access rules have to be satisfied. Example Eason issues a DELETE statement to remove the sales record protected by the ‘EAST’ security component element: DELETE FROM SALES

Only records that Eason has read-and-write credential access for will be deleted. If Eason has read access on some of the rows but does not have write access on those same rows, the DELETE operation fails. Table 6.32

Eason’s Security Label is compared for DELETE operation on the SALES table

ID

SEC_LABEL


1

SL_EAST

Allowed.

2

SL_WEST

Not allowed to read: SL_EAST does not contain element ‘WEST’.

3

SL_CENTRAL_N

Not allowed to read: SL_EAST does not contain element ‘CENTRAL_NORTH’.

4

SL_CENTRAL_S

Not allowed to read: SL_ EAST does not contain element ‘CENTRAL_SOUTH’.

5

SL_WEST

Not allowed to read: SL_ EAST does not contain element ‘WEST’.

6

SL_EAST

Allowed. (continues)

Use Case Scenario

207

Table 6.32 Eason’s Security Label is compared for DELETE operation on the SALES table (Continued) ID

SEC_LABEL


7

SL_CENTRAL_N

Not allowed to read: SL_EAST does not contain element ‘CENTRAL_NORTH’.

8

SLC_REGION: Not allowed: SL_EAST does not contain element (CENTRAL_NORTH, ‘CENTRAL_NORTH’ or ‘CENTRAL_SOUTH’. CENTRAL_SOUTH)

As a result, the records with ID 1 and 6 are deleted, because Eason only has read-and-write access on those two records. Example Sean issued the same DELETE statement. Sean holds the SL_REGIONS for read-and-write access. Therefore, he is allowed to read and write all records in the table. By issuing the DELETE FROM SALES

statement, all records will be deleted.

USE CASE SCENARIO Let’s walk through a scenario showing how LBAC can be used to impose access restrictions to table data. The Life Health Care Center is reviewing the HIPAA regulations dealing with the client visit record data storage that can be shared with health plan providers. For every client visit, a record is created in the database with information about the visit, diagnostic result, service provided, cost of the service, client’s health insurance provider, and so on. Information about the service provided and the cost is shared with the client’s health insurance provider for claim processing. Health insurance providers are allowed to read records of their clients but not others. The diagnostic results are highly confidential and should be handled only by the Health Care Center staff. Client visit records are to be stored in the VISIT_RECORD table, which is shown in Figure 6.5.

208


Confidential R&W

Health Insurance Company A Claims Processor Health Care Provider Staff

R

R&W

Health Insurance Company B Claims Processor

Figure 6.5 The VISIT_RECORD table. The confidential columns can be accessed by staff in the Life Health Care Center only. Health Insurance providers are restricted to read only the records of their clients.

Column name ---------------RECORDID CLIENTNO DATE *DIAGONSTIC SERVICE_DESC AMOUNT INSURER_ID CLAIMED

Type schema --------SYSIBM SYSIBM SYSIBM SYSIBM SYSIBM SYSTEM SYSIBM SYSIBM

Type name Length Scale Nulls ------------------ -------- ----- ---CHARACTER 6 0 No CHARACTER 6 0 No DATE 4 0 No CLOB 1048576 0 No VARCHAR 255 0 No DECIMAL 6 2 No CHARACTER 6 0 No DATE 4 0 No

Columns with an asterisk (*) contain confidential information. Table 6.33

Some of the Staff Who Can Access the VISIT_RECORD Table

Staff

Position

Henry

Life Health Care Center staff

Anson

Claims processor of health insurance company A (IC011)

Anna

Claims processor of health insurance company B (IC012)

Use Case Scenario

209

Based on this scenario, summarize your security requirements as follows in Table 6.34. Table 6.34

Security Requirements of Users with Various Responsibilities READ Access

WRITE Access

Life Health Care Center staff

Full access

Full access

Claims processor of insurance company

Only columns and their client records that are not confidential

No access

Analyzing Data Restrictions You need to determine how to restrict access to columns that are confidential, and restrict records to be read by a certain groups of people. You need to enforce the following restrictions: • Columns—Confidential columns can be read and written by Health Care Center staff only. Insurance company claims processors have no access to the confidential column. • Rows—Health Care Center staff can read and update all the records. Insurance company claims processors can read but cannot update client records of their insurance company. To restrict access to the column that is confidential, the column can be protected with a security label. To allow claims processors to access the records of their clients only, each row would be tagged with a security label that indicates the insurance company. The write restriction can be implemented by not granting write access security labels to the managers. On the table level, write restriction can also be implemented by revoking the write privileges to the table from the claims processors.

210


Table 6.35 Tag the Columns That Are Confidential with a Security Label to Make It Protected, and Tag Each Row with a Security Label to Apply Access Control Based on the Insurance Company

RECORDID CLIENTNO DATE

Row SERVICE Sec DIAGNOSTIC _DESC AMOUNT INSURER_ID CLAIMED Label

000010

C00101

2006/03/04 …

…

200

IC011

000011

A00721

2006/03/05 …

…

325

IC012

000012

L05031

2006/03/05 …

…

128

IC011

2006/03/04

Designing the Security Solution After determining the security requirements, design the security labels that will control access to the data in the VISIT_RECORD table. In designing a security solution, you need to consider the following: • Row and column security labels required for protecting the columns and rows • User security labels to grant the users the appropriate access • Security label components for creating the security labels Column Security Label For column protection, one column security label is required to tag the confidential column. The security label could simply be made up of a security label component with an element called ‘CONFIDENTIAL’. A SET type component can be used in this case. Row Security Labels For row protection, a security label is required to tag the rows based on the insurance company. Thus, one security label is required for each insurance company. The Life Health Care Center currently deals with five insurance companies. Given that there are five insurance companies, five security labels will be created to identify them. Health Care Center staffs are allowed to access all the rows. Thus, the security label component for creating these security labels could be structured as a TREE, with the Health Care Center as the root, and the insurance companies that deal with the Health Care Center as the child. User Security Label for the Health Care Center Staff The security label granted to the medical record analysts should allow them to read and write all records, including the confidential columns. Thus, the security label should include the elements from the column security label and the row security label that can access all rows.

Use Case Scenario

211

User Security Label for the Claims Processor of Health Insurance Providers The security label granted to the claims processor should allow them to read the records of their clients only. The security label should include the element of the insurance company ID. Security label Components A SET type security label component is required for the column security label, with one element ‘CONFIDENTIAL’. A TREE type security label component is required for the row security label, with ‘IC_ROOT’ as the root, and the insurance companies IDs ‘IC011’, ‘IC012’, ‘IC013’, ‘IC014’, and ‘IC015’ as the child elements.

Implementing the Security Solution Steps Overview 1. Define the security policies and labels. a. Define the security label components. b. Define the LBAC security policy. c. Define the security labels. 2. Create the VISIT_RECORD table by adding a security label column for the row level protection, mark the confidential columns as protected, and attach the security policy to the table. 3. Grant the appropriate security labels to the staff.

Step 1: Privilege and Authority Requirements Requires SECADM authority to create security objects. Step 1.1: Defining the Security Label Components From the analysis, two security label components are required. The security label components can be created using the following statement: CREATE SECURITY LABEL COMPONENT SLC_LEVEL SET {'CONFIDENTIAL'}

212


CREATE SECURITY LABEL COMPONENT SLC_INSURANCE TREE ('IC_ROOT' ROOT, 'IC011' UNDER 'IC_ROOT', 'IC012' UNDER 'IC_ROOT', 'IC013' UNDER 'IC_ROOT', 'IC014' UNDER 'IC_ROOT', 'IC015' UNDER 'IC_ROOT' )

Step 1.2: Defining the Security Policy After the security label component is created, the next step is to create the security policy. A security policy with a name VISIT_RECORD_POLICY that uses the SLC_LEVEL and SLC_INSURANCE security label components can be created using the following statement: CREATE SECURITY POLICY VISIT_RECORD_POLICY COMPONENTS SLC_LEVEL, SLC_INSURANCE WITH DB2LBACRULES RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL

Step 1.3: Defining the Security Label From the analysis, the following security labels are needed: • One column security label • Five security labels for row protection and for the insurance company claims processor • One user security label for Health Care Center staff The security labels can be created using the following statements: For column protection: CREATE SECURITY LABEL VISIT_RECORD_POLICY.SL_VISIT_RECORD COMPONENT SLC_LEVEL 'CONFIDENTIAL'

For row protection and insurance claims processors: CREATE SECURITY LABEL VISIT_RECORD_POLICY.SL_INSURANCE_IC011 COMPONENT SLC_INSURANCE 'IC011' CREATE SECURITY LABEL VISIT_RECORD_POLICY.SL_INSURANCE_IC012 COMPONENT SLC_INSURANCE 'IC012' CREATE SECURITY LABEL VISIT_RECORD_POLICY.SL_INSURANCE_IC013 COMPONENT SLC_INSURANCE 'IC013'

Use Case Scenario

213

CREATE SECURITY LABEL VISIT_RECORD_POLICY.SL_INSURANCE_IC014 COMPONENT SLC_INSURANCE 'IC014' CREATE SECURITY LABEL VISIT_RECORD_POLICY.SL_INSURANCE_IC015 COMPONENT SLC_INSURANCE 'IC015'

For Health Care Center staff: CREATE SECURITY LABEL VISIT_RECORD_POLICY.SL_HC_STAFF COMPONENT SLC_LEVEL 'CONFIDENTIAL', COMPONENT SLC_INSURANCE 'IC_ROOT'

Step 2: Creating the Protected VISIT_RECORD Table Privilege and Authority Requirements for the Creator of the Table: • CREATETAB authority. • Creator of the table should be granted with a security label that is associated with the VISIT_RECORD_POLICY. The security label will be used as the default value for the ROW_SEC_LABEL column. For example, assume the administrator holds the VISIT_RECORD_POLICY.SL_HC_STAFF security label. GRANT SECURITY LABEL VISIT_RECORD_POLICY.SL_HC_STAFF TO USER FOR ALL ACCESS

To secure the VISIT_RECORD table, all confidential columns need to be secured with the VISIT_RECORD_POLICY.SL_VISIT_RECORD security label. To secure the rows, a new column will be added to hold the security label for tagging the departments. The table can be protected by executing the following statement: CREATE TABLE VISIT_RECORD ( RECORDID CHARACTER (6), CLIENTNO CHARACTER(6), DATE DATE, DIAGONSTIC CLOB(1M) SECURED WITH SL_VISIT_RECORD, SERVICE_DESC VARCHAR(255), AMOUNT DECIMAL (6), INSURER_ID CHARACTER (6), CLAIMED DATE, ROW_SEC_LABEL DB2SECURITYLABEL) SECURITY POLICY VISIT_RECORD_POLICY

Upon successful execution of the statement, the VISIT_RECORD table is protected.

214

Column name ———————— RECORDID CLIENTNO DATE *DIAGONSTIC SERVICE_DESC AMOUNT INSURER_ID CLAIMED ROW_SEC_LABEL


Type schema ————SYSIBM SYSIBM SYSIBM SYSIBM SYSIBM SYSTEM SYSIBM SYSIBM SYSIBM

Type name ————————— CHARACTER CHARACTER DATE CLOB VARCHAR DECIMAL CHARACTER DATE DB2SECURITYLABEL

Length Scale Nulls ———— ——- ——6 0 No 6 0 No 4 0 No 1048576 0 No 255 0 No 6 2 No 6 0 No 4 0 No 4 0 No

where (*) are protected columns.

Step 3: Granting the Security Labels to the Staff Privilege and authority requirements: SECADM authority is required.

After the VISIT_RECORD table has been protected, no user can access the table until security labels are granted to them. Assume Henry, Anson, and Anna have read privilege on the table. To allow them to access the table, grant the SECURITY labels to the users with the following statements: GRANT SECURITY LABEL VISIT_RECORD_POLICY.SL_HC_STAFF TO USER HENRY FOR ALL ACCESS GRANT SECURITY LABEL VISIT_RECORD_POLICY.SL_INSURANCE_IC011 TO USER ANSON FOR READ ACCESS GRANT SECURITY LABEL VISIT_RECORD_POLICY.SL_INSURANCE_IC012 TO USER ANNA FOR READ ACCESS

Runtime Usage This section explains some of the runtime scenarios after the VISIT_RECORD table is protected. Example 1 Assume the VISIT_RECORD has the following records.

Use Case Scenario

Table 6.36

215

The VISIT_RECORD Table

RECORDID CLIENTNO DATE

SERVICE INSURER Row Sec DIAGNOSTIC _DESC AMOUNT _ID CLAIMED Label

000010

C00101

2006/03/04

…

…

200

IC011

2006/03/04 SL_ INSURANCE_ IC011

000011

A00721

2006/03/05

…

…

325

IC012


000012

L05031

2006/03/05

…

…

128

IC011


* DIAGNOSTIC column is protected by SL_VISIT_RECORD.

Henry holds the SL_HC_STAFF security label for all access. The SL_HC_STAFF security label contains the SLC_LEVEL:(‘CONFIDENTIAL’), and SLC_INSURANCE:(‘IC_ROOT’). He tries to read the VISIT_RECORD table by issuing this: SELECT * from VISIT_RECORD;

Henry has read access to the protected column because his read security label contains ‘CONFIDENTIAL’. For row access, because ‘IC_ROOT’ is the ancestor element of ‘IC011’ and ‘IC012’, Henry can read all the rows in the table. The statement executed successfully. All records of the VISIT_RECORD table are returned. Example 2 Henry tries to insert a record into the VISIT_RECORD table by issuing the following: INSERT INTO VISIT_RECORD (RECORDID, CLIENTNO, DATE, DIAGONSTIC, AMOUNT, INSURER_ID, ROW_SEC_LABEL) VALUES ('000329', 'C00902', '2006-04-25', 'Require blood test', 233, 'IC012', SECLABEL_BY_NAME('VISIT_RECORD_POLICY', 'SL_IC012'))

To insert the record, two write access controls are in effect. • Write to protected column ‘DIAGNOSTIC’ • Write the row security label: IC012 Henry has write access to the protected column because his write security label contains ‘CONFIDENTIAL’. For row access, because ‘IC_ROOT’ is the ancestor element of ‘IC011’ and ‘IC012’, Henry can insert the record into the table. The statement executed successfully.

216


Example 3 Anson holds the security label SL_INSURANCE_IC011 for read access. Anson tries to read the VISIT_RECORD table by issuing this: SELECT * from VISIT_RECORD;

To successfully read the records, Anson needs read access on the protected column and read access on the rows. The read security label that Anson holds does not contain the ‘CONFIDENTIAL’ element. This violates the DB2LBACREADSET access rule on the protected column. Query execution failed with SQL20264N. ANSON does not have READ access to the column “DIAGONSTIC” of the VISIT_RECORD table.

Anson tries to read the unprotected columns in the VISIT_RECORD table by issuing the following: SELECT RECORDID, CLIENTNO, DATE, SERVICE_DESC, AMOUNT, INSURER_ID, CLAIMED FROM VISIT_RECORD;

Because Anson is not accessing the protected column, only the row security labels will be checked. Table 6.37

Anson’s Security Label Is Compared for Read Access on the VISIT_RECORD Table

RECORDID Row Sec Label

Access Allowed?

000010

SL_INSURANCE_IC011

Allowed. Equal value.

000011

SL_INSURANCE_IC012

Not allowed. Violates the DB2LBACREADTREE rule. SL_INSURANCE_IC011 does not contain ‘IC012’, nor is an ancestor of ‘IC012’.

000012

SL_INSURANCE_IC011

Allowed. Equal value.

000329

SL_INSURANCE_IC012

Not allowed. SL_INSURANCE_IC011 does not contain ‘IC012’.

The statement executed successfully. Two records with RECORDID ‘000010’ and ‘000012’ are returned.

Managing Security Objects

217

Example 4 Anna holds the SL_INSURANCE_IC012 security label for read access. Anna tries to manipulate record in the VISIT_RECORD table. First she queries for the record: SELECT INSURER_ID from VISIT_RECORD WHERE CLIENTNO='A00721';

Anna is accessing the unprotected column, so only the row access control will be checked. The record with CLIENTNO ‘A00721’ is protected by SLC_INSURANCE_IC012. The user security label matches the value. The statement executed successfully. The value of INSURER_ID is returned. Anna then tries to update the value of the INSURER_ID. UPDATE VISIT_RECORD SET AMOUNT = 400 WHERE CLIENTNO='A00721'

Anna does not have WRITE security label. Therefore, she does not have authority to write to the VISIT_RECORD table. Access violation error SQL20402N is returned. Anna does not have the LBAC credentials to perform the UPDATE operation on the table VISIT_RECORD. The same statement executed by Henry will be successful because Henry has read-and-write access to the record.

MANAGING SECURITY OBJECTS After a security solution is designed and implemented, the setup has to be maintained and reviewed. The following are some general tasks that a security administrator would perform: • Review the definitions of the security objects created • Review the security objects that are no longer in use and remove them

Review the Definition of Security Objects Review Security Labels Security label objects information can be accessed from the SECURITYLABELS catalog view. The definition of a security label can be retrieved using the following statement: SELECT SECLABELID, SECLABEL_TO_CHAR('<policy-name>',seclabel) FROM SYSCAT.SECURITYLABELS WHERE SECLABELNAME=''

218


Review Security Policies Security policy information can be accessed from the SECURITYPOLICIES catalog view. To retrieve the list of security label components used by a security policy, use the following statement: SELECT COMPNAME FROM SYSCAT.SECURITYPOLICIES P, SYSCAT.SECURITYLABELCOMPONENTS C, SYSCAT.SECURITYPOLICYCOMPONENTRULES R WHERE P.SECPOLICYID = R.SECPOLICYID and R.COMPID=C.COMPID and P.SECPOLICYNAME='<policy-name>'

Review Security Label Components Security label component information can be accessed from the SECURITYLABELCOMPONENTS catalog view. To retrieve the list of component elements of a security label component, use the following statement: SELECT ELEMENTVALUE, PARENTELEMENTVALUE FROM SYSCAT.SECURITYLABELCOMPONENTELEMENTS E, SYSCAT.SECURITYLABELCOMPONENTS C WHERE E.COMPID=C.COMPID and C.COMPNAME='' ORDER BY PARENTELEMENTVALUE

If security objects are no longer in use, the objects can be dropped.

Dropping Security Labels To drop a security label, it must no longer be in use. A security label is not in use if • The security label is not granted to any user. • The security label is not being used in a protected table. To check whether a security label is granted to any user, run the following query: SELECT GRANTEE FROM SYSCAT.SECURITYLABELACCESS WHERE SECLABELID = (SELECT SECLABELID FROM SYSCAT.SECURITYLABELS WHERE SECLABELNAME = '' AND SECPOLICYID = (SELECT SECPOLICYID FROM SYSCAT.SECURITYPOLICIES WHERE SECPOLICYNAME = '<policy-name>'))

Managing Security Objects

219

To check whether a security label is used in a protected table, run this query: SELECT TABNAME, COLNAME FROM SYSCAT.COLUMNS WHERE SECLABELNAME = (SELECT SECLABELNAME FROM SYSCAT.SECURITYLABELS WHERE SECLABELNAME ='' AND SECPOLICYID = (SELECT SECPOLICYID FROM SYSCAT.SECURITYPOLICIES WHERE SECPOLICYNAME = '<policy-name'>))

If both queries return empty result sets, the security label can be dropped using the drop statement: DROP SECURITY LABEL <security-label-name>

Otherwise, the statement will return the following: SQL20404N The security label object “<security label>” cannot be dropped because it is currently in use. Reason code “1.”

Dropping Security Policy An LBAC security policy is not in use if • It is not used in any of the protected tables. • There are no security labels associated with the security policy. • There is no exemption granted on any of the access rules. To check whether a security policy is used by any protected tables, issue the following statement: SELECT TABNAME FROM SYSCAT.TABLES WHERE SECPOLICYID = (SELECT SECPOLICYID FROM SYSCAT.SECURITYPOLICIES WHERE SECPOLICYNAME = '<security-policy>' )

To list the existing security labels that are associated with a security policy, use the following statement: SELECT SECLABELNAME FROM SYSCAT.SECURITYPOLICIES S, SYSCAT.SECURITYLABELS L WHERE L.SECPOLICYID = S.SECPOLICYID AND S.SECPOLICYNAME= '<security-policy>'

220


To check whether an exemption is granted on rules used by a security policy, use this statement: SELECT GRANTEE, ACCESSRULENAME FROM SYSCAT.SECURITYPOLICYEXEMPTIONS WHERE SECPOLICYID = (SELECT SECPOLICYID FROM SYSCAT.SECURITYPOLICIES WHERE SECPOLICYNAME = '<security-policy>' )

If all three queries return empty result sets, the security policy can be dropped using the drop statement: DROP SECURITY POLICY <security-policy>

Otherwise, SQL20405N will be returned: SQL20405N The security policy object “<security-policy>” cannot be dropped because it is currently in use. Reason code “1.”

Dropping Security Label Component A security label component is not in use if no security policy is referring to it. To check whether a security policy is referring to a security label component, use the following query: SELECT SECPOLICYNAME FROM SYSCAT.SECURITYPOLICIES WHERE SECPOLICYID = (SELECT SECPOLICYID FROM SYSCAT.SECURITYPOLICYCOMPONENTRULES WHERE COMPID = (SELECT COMPID FROM SYSCAT.SECURITYLABELCOMPONENTS WHERE COMPNAME = '') )

If the query returns an empty result set, the security label component can be dropped using the drop statement: DROP SECURITY LABEL COMPONENT

Otherwise, SQL20406N will be returned: The security label component object “” cannot be dropped because it is part of a security policy. SQLSTATE=42893

Managing User Access to Protected Data

221

MANAGING USER ACCESS TO PROTECTED DATA Some general tasks for the LBAC security administrator include the following: • Checking for authorization ids granted with a particular security label • Managing the list of authorization ids that hold exemption granted on a security policy • Changing user privilege (for example, from accessing protected tables) A user needs to be granted with security labels and exemptions to access protected data. To manage user security labels, you must have SECADM authority. User access to security label information can be found in the SYSCAT.SECURITYLABELACCESS catalog view. A user can be granted one security label of each access type per security policy.

Granting Security Labels to Users The security administrator defines multiple security labels to protect a table and to grant user access. Before granting a security label to a user, the security administrator may need to view the security labels that belong to a security policy using the following query: SELECT SECLABELNAME FROM SYSCAT.SECURITYLABELS WHERE SECPOLICYID = (SELECT SECPOLICYID FROM SYSCAT.SECURITYPOLICIES WHERE SECPOLICYNAME = '<policy-name>' )

To check whether a security label is granted to a user, issue the following query: SELECT SECLABELNAME FROM SYSCAT.SECURITYLABELS WHERE SECLABELID= ANY (SELECT SECLABELID FROM SYSCAT.SECURITYLABELACCESS WHERE GRANTEE ='CKMWONG' AND SECPOLICYID = (SELECT SECPOLICYID FROM SYSCAT.SECURITYPOLICIES WHERE SECPOLICYNAME='<policy-name>') )

To grant a security label to a user, the syntax is as follows: >>--GRANT SECURITY LABEL--security-policy-name.security-label-name---> .---FOR ALL ACCESS---. >--TO USER---authorization-name---+--------------------+------------->< +--FOR READ ACCESS---+ '--FOR WRITE ACCESS--'

222


Granting Exemptions to Users To check whether an exemption is granted to a user of a security policy, issue the following query: SELECT ACCESSRULENAME, ACTIONALLOWED FROM SYSCAT.SECURITYPOLICYEXEMPTIONS WHERE SECPOLICYID =(SELECT SECPOLICYID FROM SYSCAT.SECURITYPOLICIES WHERE SECPOLICYNAME = '<policy-name>' ) AND GRANTEE =''

To grant an exemption to a user, the syntax is as follows: >>--GRANT EXEMPTION ON RULE--+--DB2LBACREADARRAY------------------+---> +--DB2LBACREADTREE-------------------+ +--DB2LBACREADSET--------------------+ +--DB2LBACWRITEARRAY WRITEDOWN-------+ +--DB2LBACWRITEARRAY WRITEUP---------+ +--DB2LBACWRITETREE------------------+ +--DB2LBACWRITESET-------------------+ +---------------ALL------------------+ >--FOR--label-pol-name--TO--USER--authorization-name----------------->
>-REVOKE EXEMPTION ON RULE--+-access-rule-+--------------------> '-ALL---------' >--FOR--policy-name--FROM USER--authorization-name------------->
.------------------------------------------------. V .-COLUMN-. | >--+-ALTER--+--------+--| column-alteration |-------+-----> +-ADD SECURITY POLICY--policy-name------------------------>< column-alteration: |--column-name---------------------------------------> +-SECURED WITH--security-label-name-----------------------+

Alter table T2 to make it a protected table with the BONUS column protected with security label SL_CONFIDENTIAL with the following ALTER TABLE statement: ALTER TABLE T2 ALTER COLUMN BONUS SECURED WITH SL_CONFIDENTIAL ADD SECURITY POLICY DATA_ACCESS_POLICY

Defining a column of type DB2SECURITYLABEL fails if a table does not have a security policy associated with it. Error SQL20391N is returned. LBAC cannot be applied to the column because there is no security policy associated with the table.

Altering Table Protection: Adding Row Protection Row protection is used to restrict access to rows in a table. When rows are protected by security labels, users granted with security labels will be able to access some rows but not others depending on the security label being granted to them.

Managing Protected Tables

225

To add row protection to a table, you have to do the following: • Add a column of type DB2SECURITYLABEL to store the security label. • Attach a security policy to the table if the table is not already protected. The privileges held by the session authorization ID of the statement must include at least a security label with write access from the security policy associated with the table. For existing rows in the table, the value of the security label column defaults to the security label for write access of the session authorization ID at the time the ALTER statement that adds a row security label column is executed. ALTER TABLE --table-name------------------------------------> .-COLUMN-. >--+-ADD--+-+--------+--|--column-name --DB2SECURITYLABEL+--> >--+-ADD SECURITY POLICY--policy-name----------------------->
.------------------------------------------------. V .-COLUMN-. | >--+-ALTER--+--------+--| column-alteration |-------+-----> column-alteration: |--column-name--- DROP COLUMN SECURITY --------------|

Alter table T2 to make it a protected table with the BONUS column protected with security label SL_CONFIDENTIAL with the following ALTER TABLE statement: ALTER TABLE T2 ALTER COLUMN BONUS DROP COLUMN SECURITY

226


Altering Table Protection: Alter the Security Policy of a Protected Table In DB2 9, security objects cannot be altered after they are created. In cases where security label components represent some dynamic structure (for instance, an organization tree), elements could change over time. To update a protected table with new security label component definitions, the protected table has to be altered to drop the old security policy and attach the new security policy with the following steps: 1. Create the new security label components. 2. Create the new security policy. 3. Create the new security labels. 4. Alter the protected table T1: a. Drop the current security policy, say ‘Policy_1’. b. If the table is row protected, rename the DB2SECURITYLABEL column, say SEC_LABEL to SEC_LABEL_old. c. Attach the new security policy, say ‘Policy_2’. d. If the table is row protected, add a new DB2SECURITYLABEL column, SEC_LABEL. Then update the security label values as follows: UPDATE T1 SET SEC_LABEL = SECLABEL('Policy_2', SECLABEL_TO_CHAR('Policy_1', DB2SECURITYLABEL(SEC_LABEL_old)) )

e. Drop the SEC_LABEL_old column if it is not needed. 5. After the protected table has been altered, the old security labels granted to users that are no longer applicable should be revoked, and new security labels should be granted to restore user access to the protected table. 6. Security objects that are no longer in use can be discarded.

Remove Protection from Protected Tables To remove protection from a protected table, the administrator can simply detach the security policy from the protected table. After the security policy is detached, protected columns lose their protection. If the table has row protection, the column with data type DB2SECURITYLABEL is changed to VARCHAR(128) FOR BIT DATA. After the column is changed to VARCHAR, the column can be removed from the table. To detach a security policy from a protected table, follow the ALTER TABLE syntax: >>-ALTER TABLE--table-name---DROP SECURITY POLICY------->
>-db2audit--+-configure--+-reset-------------------+--------------------------+->< | '-| Audit Configuration |-' | +-describe--------------------------------------------------------+ +-extract--| Audit Extraction |-----------------------------------+ +-flush-----------------------------------------------------------+ +-prune--+-all--------------------------------------------------+-+ | '-date--YYYYMMDDHH--+--------------------------------+-' | | '-pathname--Path_with_temp_space-' | +-start-----------------------------------------------------------+ '-stop------------------------------------------------------------' Audit Configuration: |--+-----------------------------+--+---------------------+-----> '-scope--+-all--------------+-' '-status--+-both----+-' | .-,------------. | +-success-+ | V | | '-failure-' '---+-audit----+-+-' +-checking-+ +-objmaint-+ +-secmaint-+ +-sysadmin-+ +-validate-+ '-context--' >--+-----------------------+------------------------------------| '-errortype--+-audit--+-' '-normal-' Audit Extraction: |--+-file--output-file---------------------+--------------------> '-delasc--+---------------------------+-' '-delimiter--load-delimiter-' >--+----------------------------+-------------------------------> | .-,------------. | | V | | '-category----+-audit----+-+-' +-checking-+ +-objmaint-+ +-secmaint-+ +-sysadmin-+ +-validate-+ '-context--' >--+-------------------------+--+---------------------+---------| '-database--database-name-' '-status--+-success-+-' '-failure-'

Figure 9.1

db2audit statement syntax

From Analysis to Physical Design

281

db2audit Step by Step Step 1: Configure The first step to enable db2audit in a new environment is configuring the db2audit facility options. Because the db2audit configuration is effective at the instance level and applies to all databases housed in that instance, the configuration steps can begin any time after the instance is created and may preexist creation of any databases. The instance does not need to be started prior to configuring db2audit, it just needs to exist. During the instance creation, a security subdirectory is created underneath the primary instance path. You will notice that the db2audit.cfg configuration file and the db2audit.log file (when created) will be placed in the instance’s security subdirectory. Configuration options for the db2audit facility should be chosen based on the analysis done previously and should be designed to capture only information that is pertinent to the task at hand. As you read through each of the configuration options explained here in detail, be aware that choosing some of the db2audit configuration options may result in large amounts of data being generated when the db2audit trails are extracted. Selectively choosing only those options that are actually necessary is the best strategy. The actual task of configuring the db2audit facility is surprisingly easy (even though the thought that goes into choosing the options can be highly complex). Any user who holds SYSADM authority can use basic command syntax to set the configuration. The basic syntax follows: db2audit CONFIGURE SCOPE <scope> STATUS <status> ERRORTYPE <errortype>

The CONFIGURE keyword indicates a planned parameter modification of the db2audit.cfg file, which is stored in the instance’s SECURITY subdirectory. It is possible to update this file via the db2audit facility commands even when the instance is shut down. If the instance is not running and changes are made to the configuration information, those changes take effect the next time the instance is started. If the instance is running when the configuration changes are made, the changes take effect dynamically. The db2audit CONFIGURE keyword can also be used to reset the db2audit facility configuration back to the defaults or to facilitate recovery if something has happened to the original db2audit.cfg file. To perform this action, run this command: db2audit configure reset

Use caution if you need to run the RESET command. After the db2audit configuration is reset, the db2audit facility must be explicitly restarted using the DB2AUDIT START command. The reset command also changes the SCOPE and STATUS of the db2audit facility back to their defaults, which may not be the desired effect.

282

Chapter 9 • Database Auditing and Intrusion Detection

The SCOPE parameter refers to the type(s) of auditing you plan to initiate. There are several categories or combinations of categories that can be chosen to participate in the scope of the audit. Based on the analysis of the auditing requirement, the SCOPE options relate to the type(s) of auditing required to fulfill the business need. If the command is run to reset the db2audit configuration, the db2audit facility SCOPE reverts to the default, which is to enable every scope category except CONTEXT. It is important to stress that when considering SCOPE options that can be invoked, remember that turning on more auditing than required is not a sound practice. Both performance and the size of the db2audit trail logs are impacted by the choices made for the db2audit SCOPE parameter. Given the importance of making appropriate choices regarding scope, each option of the SCOPE parameter is discussed in significant detail under the heading “Scoping Out Scope” later in this chapter. STATUS refers to the logging of events that failed or succeeded or if the event will be logged regardless of its success or failure. When thinking about the STATUS parameter, it is imperative to understand that this option applies to all the items chosen for the SCOPE of the audit. In other

words, the DBA cannot pick and choose some events to be audited for only success while other events are logged only for failure. Choosing the STATUS option, therefore, can necessitate auditing for both success and failure even though the requirements are to audit only successful events for some of the SCOPE options and only failed events for other scope options. The STATUS option applies globally to all chosen options of the SCOPE parameter. The only exception to the db2audit status rule relates to the auditing of CONTEXT events. CONTEXT events occur before the status of the audited operation can be determined; therefore, if CONTEXT events are being captured, they are logged regardless of the setting for the STATUS parameter. One more caution about the STATUS option. If the db2audit facility configuration is reset, STATUS reverts to the default and logs only failed events until reconfigured. ERRORTYPE deals with the db2audit facility’s management of errors. It determines whether SQL errors trapped by the db2audit facility can be ignored or if they should be returned to the user. When set to AUDIT, all errors are managed by DB2 with any negative SQLCODES returned to the user. When explicitly set to NORMAL (the default) or when the db2audit facility configuration is reset, any errors generated by the db2audit facility are ignored and only those errors associated with the operation actually being performed are returned to the user.

Scoping Out Scope The SCOPE parameter of the db2audit command allows the DBA to choose how wide a net to cast when it comes to auditing events. Seven categories of SCOPE events can be audited either separately or in combination. AUDIT How do you audit db2audit? The AUDIT scope option provides a significant security depth for any organization using the db2audit facility. This option provides the mechanism used to capture evidence of any changes made to the db2audit facility itself. Setting this SCOPE


283

option guarantees that any attempts to extract the recorded events to the audit trail logs will be captured. Given the criticality of ensuring that the AUDIT configuration settings stay as designed and that only authorized SYSADM users extract the resulting audit trails, this is a strong security failsafe mechanism that should be turned on in most DB2 environments. Figure 9.2 shows an example of the AUDIT scope functionality. Here, the db2audit facility scope is configured to verify AUDIT events, and the db2audit facility is started. The db2audit facility places the generated audit records into the db2audit.log file, which must be converted into a human readable format prior to review. This is done using the db2audit EXTRACT options. The extraction, by default, is made to a flat (text) file, named db2audit.out, unless other options are specified. Extracting the db2audit records and loading the resulting data into tables is also an option (discussed later in this chapter); but for this example, accepting the extraction defaults works. Unless otherwise specified, DB2 stores the extracted db2audit.out file in the insthome/security subdirectory. C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit configure scope audit AUD0000I

Operation succeeded.

C:/Program Files\IBM\SQLLIB\DB2ASAM\secuity>db2audit start AUD0000I


C:/Program Files\IBM\SQLLIB\DB2ASAM\secuity>db2audit extract AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\secuity>more db2audit.out timestamp=2005-11-11-21.22.50.369000;category=AUDIT;audit event=START; event correlator=0;event status=0; userid=db2asam;authid=DB2ASAM;

Figure 9.2

Scope = audit

One of the best ways to learn about each of the db2audit facility scope options is to understand the record layout for the resulting audit trail. In the record layout for the AUDIT SCOPE, shown in Figure 9.3, all possible values that trigger an event for the audit scope are listed on the Audit Event line. Knowing the events that are captured when setting this scope value aids the DBA in both the decision-making process for db2audit setup and the review process to determine what events normally occur in the day-to-day business operations. It is a good idea to print or have ready access to the Record Layouts for each of the scope options and refer to them when deciding which audit scope options to configure. In addition to finding these record layouts in the DB2 Information Center (http://publib.boulder.ibm.com/ infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.doc/welcome.htm), see Appendix C, “DB2 Audit Scope Record Layouts,” for a complete listing of the record layouts for all the db2audit scope categories.

284


NAME

FORMAT

Timestamp

CHAR(26)

DESCRIPTION Date and time of the audit event.

Category

CHAR(8)

Category of audit event. Possible values are: AUDIT

Audit Event

VARCHAR(32)

Specific Audit Event. Possible values include: CONFIGURE, DB2AUD, EXTRACT, FLUSH, PRUNE, START, STOP, and UPDATE_ADMIN_CFG

Event Correlator

INTEGER

Correlation identifier for the operation being audited. Can be used to identify what audit records are associated with a single event.

Event Status

INTEGER

Status of audit event, represented by an SQLCODE where Successful event > = 0 Failed event < 0

User ID

VARCHAR(1024)

User ID at time of audit event.

Authorization ID

VARCHAR(128)

Authorization ID at time of audit event.

Figure 9.3

Audit record layout

CHECKING The primary purpose of the CHECKING option is to determine authorization attempts. Finding a CHECKING audit event in the extracted audit logs indicates that an attempt has been made to access, change, or, in some manner, manipulate a DB2 object or function. This audit option would be desired in most auditing scenarios to see what activity has been authorized for database objects and what authorization attempts were made without success. This option is one that can lead to a significant amount of audit trail data being collected, especially if every successful and failed authorization attempt is logged. The amount of data generated by the CHECKING scope is typically not one for one. For example, several CHECKING audit records may exist for a single SQL statement. Because the information collected via the CHECKING option is typically essential to determining unexpected or unusual occurrences that might indicate a security concern, the volume of data collection may be a secondary concern depending upon the environment. Figure 9.4 shows a sequence of events for the CHECKING scope that are captured by the db2audit.log during a connection to the Sample database and the successful creation of a new index. In this example, notice that more than one event is logged for the CHECKING audit events even though the only actions were to connect to the database and create the index. These multiple records show the actual authorization steps that DB2 does “under the covers” as they are captured by the db2audit facility. In this example, notice that the steps were as follows: 1. A user ID holding SYSADM authority connected to the SAMPLE database. 2. An attempt to EXECUTE an internal DB2 package was authorized. 3. Authorization was approved to CREATE the object. 4. CREATIN privilege was checked to determine whether authorization existed to create the index in the specified schema.


285

C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit configure scope checking status both AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit start AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2 connect to sample Database Connection Information Database server SQL authorization ID Local database alias

= DB2/NT 8.2.3 = DB2ASAM = SAMPLE

C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2 ”create index dbasam.empl1 on db2asam.employee(newcol)” DB20000I The SQL command completed successfully. C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit extract AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASALM\security>more db2audit.out timestamp=2005-11-11-09.12.30.035000;category=CHECKING;audit event=CHECKING_OBJECT; event correlator=2;event status=0; database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051111141229;application name=db2bp.exe; object NAME=SAMPLE;object type=DATABASE; access approval reason=SYSADM;access attempted=CONNECT; timestamp=2005-11-11-09.12.40.430000;category=CHECKING;audit event=CHECKING_OBJECT; event correlator=3;event status=0; database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051111141229;application name=db2bp.exe; package schema=NULLID;package name=SQLC2E06; package section=0;object schema=NULLID;object name=SQLC2E06;object type=PACKAGE; access approval reason=OBJECT;access attempted=EXECUTE; timestamp=2005-11-11-09.12.40.440001;category=CHECKING;audit event=CHECKING_OBJECT; event correlator=3;event status=0; database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051111141229;application name=db2bp.exe; package schema=NULLID;package name=SQLC2E06; package section=0;object schema=NULLID;object name=EMPLOYEE;object type=TABLE; access approval reason=OBJECT;access attempted=CREATE; timestamp=2005-11-11-09.12.40.440002;category=CHECKING;audit event=CHECKING_OBJECT; event correlator=3;event status=0; database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051111141229;application name=db2bp.exe; package schema=NULLID;package name=SQLC2E06; package section=0;object name=DB2ASAM;object type=SCHEMA; access approval reason=SYSADM;access attempted=CREATEIN; timestamp=2005-11-11-09.12.55.882000;category=CHECKING;audit event=CHECKING_FUNCTION; event correlator=0;event status=0; userid=db2asam;authid=DB2ASAM; application id=*LOCAL_APPLICATION;application name=db2audit.exe; package schema=NULLID;package name=SQLC2E06; object type=INSTANCE; access approval reason=SYSADM;access attempted=MEMBER_OF_SYS_GROUP;

Figure 9.4

Scope = checking

Also, notice that the db2audit.exe was called in an attempt to extract the audit records. This function was successfully authorized because the ID was a member of the SYSADM group. There is a difference in how db2audit records generate for the CHECKING option depending on the type of SQL and whether it is static or dynamic. If dynamic DML (for example, INSERT,

286


UPDATE) SQL statements are run, CHECKING audit records generate at the time the SQL statement is prepared or when an EXECUTE IMMEDIATE request is made. The statement can then be run by the same user repeatedly if it remains in cache without further CHECKING events occur-

ring, unless there has been a change in the system catalog tables relating to privileges. If change occurs in the catalog tables concerning privileges, the dynamic SQL statement creates further CHECKING events when it is called again. If the DML SQL is in a package (static), the CHECKING event for the SQL occurs at the time the package is precompiled, bound, or rebound to the database regardless of whether the package is explicitly bound by the user or implicitly bound by DB2. Although a package may contain more than just DML SQL, during complication, CHECKING events will be generated only for DML. An exception for static DML regarding the timing of the CHECKING event occurs when the VALIDATE RUN bind option is specified. Because this option means that the DML SQL is compiled at runtime, a CHECKING event is generated at runtime. DDL statements, such as grants or revokes, always generate a CHECKING event whenever the statements run. Given the nature of DDL statements and the risk associated with grant and revoking privileges, this is a strong plus for the CHECKING scope option. OBJMAINT The Object Maintenance (OBJMAINT) option should not be confused with the CHECKING option, although they may appear to be similar at first. Although both deal with database objects, the OBJMAINT option guarantees that objects that are dropped or created are logged

as an audited event. This option is not likely to spur large volumes of data collection in most database environments and can yield solid benefits if database objects start to appear or disappear. Even if there is no known security concern, this option can be useful as a way to track down changes made in an environment with many DBAs and developers. In Figure 9.5, the db2audit facility was configured with audit only OBJMAINT events. Because the db2audit facility started previously, the configuration change took place immediately. After the db2audit facility configuration change, a table (named work) was created successfully and the audit trail was extracted. In the resulting output, notice that the audit category OBJMAINT was responsible for the capture of this audited event. SECMAINT Part of any database auditing and intrusion detection effort should include capturing any changes being made to authorities or privileges. If database privileges, including DBADM authority, are granted or revoked, using the SECMAINT scope option ensures that those changes are logged. Another critical piece provided by this option is the capture of any changes made in the Database Manager Configuration to those groups that have the highest authorities. Any changes to the SYSADM_GROUP, SYSCTRL_GROUP, SYSMAINT_GROUP, SYSMON, or SECADM Database Manager Configuration parameters are logged if the db2audit facility SECMAINT category is active. Inappropriate changes to these values could signify a major security breach, so most enterprises will want to enable this option.


287

C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit configure scope objmaint status both AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2 ”create table db2asam.work(hours smallint, days smallint)” DB20000I The SQL command completed successfully. C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit extract AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>more db2audit.out timestamp=2005-11-13-22.16.48.577000;category=OBJMAINT;audit event=CREATE_OBJECT; event correlator=43;event status=0; database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051114004917;application name=db2bp.exe; package schema=NULLID;package name=SQLC2E06; package section=0;object schema=DB2ASAM;object name=WORK;object type=TABLE

Figure 9.5

Scope = objmaint

An example of SECMAINT at work is shown in Figure 9.6. The db2audit facility was configured to audit both successful and failed SECMAINT attempts. Although connected to the SAMPLE database, a successful attempt was made to grant DBADM authority on the database to the user BONDRE. The audit events were then extracted to the db2audit.log, which shows that the event was logged. Because DBADM authority grants significant privilege on the database, this type of event should be of interest in most environments. The volume of data generated when SECMAINT events are logged is highly dependent on the number and types of grants and revokes being issued. Many production environments are fairly stable regarding privileges and authorities; so in those environments, the volume of data generated by enabling SECMAINT would not be large. However, a number of authorities, if changed, will be captured by this option. If table select authority is granted and revoked frequently, for example, each change in authority will be logged if SECMAINT is on. Review the topic “List of Possible SECMAINT Privileges or Authorities” in Appendix D, “DB2 Audit—Additional Documentation,” for a complete list of items that generate an audit event when SECMAINT is enabled. C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit configure scope secmaint status both AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2 grant dbadm on database to bondre DB20000I The SQL command completed successfully. C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit extract AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>more db2audit.out timestamp=2005-11-14-10.52.54.360001;category=SECMAINT;audit event=GRANT; event correlator=10;event status=0; database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051114153958;application name=db2bp.exe; package schema=NULLID;package name=SQLC2E06; package section=0;object name=SAMPLE;object type=DATABASE; grantor=DB2ASAM;grantee=BONDRE;grantee type=USER;privilege=DBADM;

Figure 9.6

Scope = secmaint

288


Because system administration operations are performed at the highest level of privilege, they represent a critical flashpoint in determining unexpected or unwarranted security compromises. The db2audit facility’s SYSADMIN scope option ensures that audit records are written any time a SYSADM, SYSMAINT, or SYSCTRL operation is performed. These operations can be as major as dropping a database. Given the consequences if these high-level accounts become compromised due to a security breach, it is a good idea to enable this option for most environments. The volume of data collected depends upon the activity of these higher-level activities. Some environments log very few events in this category, whereas others log them frequently, especially if the DB2 LOAD utility is used frequently. SYSADMIN

One example of using the SYSADMIN events to gather information is illustrated in Figure 9.7. In this case, a user with SYSADM authority has changed the db2audit configuration to record all SYSADMIN events. Because db2audit.exe commands are run by users with SYSADM authority, they will be captured by this setting. It is obvious that enabling the SYSADMIN audit category helps ensure the integrity of the db2audit facility in addition to recording events for any operation required to be initiated by a user with SYSADM authority. For a full list of these operations, see the topic “List of Possible SYSADMIN Audit Events” in Appendix D. After you review the possible SYSADMIN auditable events, you will have a better understanding regarding the volume of data generated by enabling this db2audit facility setting in a particular instance environment. C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit configure scope sysadmin status both AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit extract AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>more db2audit.out timestamp=2005-11-14-14.20.55.920000;category=SYSADMIN;audit event=DB2AUDIT; event correlator=0;event status=0; userid=db2asam;authid=DB2ASAM; application id=*LOCAL_APPLICATION;application name=db2audit.exe; timestamp=2005-11-14-14.21.04.634000;category=SYSADMIN;audit event=DB2AUDIT; event correlator=0;event status=0; userid=db2asam;authid=DB2ASAM; application id=*LOCAL_APPLICATION;application name=db2audit.exe;

Figure 9.7

Scope = sysadmin

VALIDATE The VALIDATE scope option of the db2audit facility is designed to generate audit records when validating users and their associated groups or when retrieving system security information. Setting this scope option to audit both successes and failures will probably generate significant volumes of audit trail data because this check is done for each connection attempt. For example, review the output in Figure 9.8. Notice the number of lines generated for this db2audit scope during a connection to the Sample database.


C:\Program Files\IBM\SQLLIB\DB2ASAM\securitydb2audit configure scope validate status both AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\securitydb2 connect to sample user bondre Enter current password for bondre: Database Connection Information Database server SQL authorization ID Local database alias

= DB2/NI 8.2.3 = BONDRE = SAMPLE

C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit extract AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>more db2audit.out timestamp=2005–11–14–15.51.08.593000;category=VALIDATE;audit event=GET_USERID; event correlator=0;event status=0; userid=db2asam;authid=DB2ASAM;execution id=DB2ASAM; application id=*LOCAL_APPLICATION;application name=db2audit.exe; auth type=SERVER;plugin name=IBMOSauthclient; timestamp=2005–11–14–15.51.08.623000;category=VALIDATE;audit event=GET_GROUPLIST; event correlator=0;event status=0; userid=db2asam;authid=DB2ASAM;execution id=DB2ASAM; application id=*LOCAL_APPLICATION;application name=db2audit.exe; auth type=NOT_SPEC;plugin name=IBMOSgroups; timestamp=2005–11–14–15.51.08.653000;category=VALIDATE;audit event=GET_USERID; event correlator=0;event status=0; userid=db2asam;authid=DB2ASAM;execution id=DB2ASAM; application id=*LOCAL_APPLICATION;application name=db2audit.exe; auth type=CLIENT;plugin name=IBMOSauthclient; timestamp=2005–11–14–15.51.08.864000;category=VALIDATE;audit event=AUTHENTICATION; event correlator=1;event status=0; userid=db2asam;authid=DB2ASAM;execution id=DB2ASAM; application id=*LOCAL.DB2ASAM;051114205108;application name=db2audit.exe; auth type=SERVER;plugin name=IBMOSauthserver; timestamp=2005–11–14–15.51.08.864000;category=VALIDATE;audit event=AUTHENTICATION; event correlator=0;event status=0; userid=db2asam;authid=DB2ASAM;execution id=DB2ASAM; application id=*LOCAL_APPLICATION;application name=db2audit.exe; auth type=CLIENT;plugin name=IBMOSauthclient; timestamp=2005–11–14–15.51.28.141000;category=VALIDATE;audit event=AUTHENTICATION; event correlator=2;event status=0; database=SAMPLE;userid=bondre;authid=BONDRE;execution id=DB2ASAM; application id=*LOCAL.DB2ASAM.051114205128;application name=db2bp.exe; auth type=SERVER;plugin name=IBMOSauthserver; timestamp=2005–11–14–15.51.28.452000;category=VALIDATE;audit event=CHECK_GROUP_MEMBERSHIP; event correlator=2;event status=—1092; database=SAMPLE;userid=bondre;authid=BONDRE;execution id=DB2ASAM; application id=*LOCAL.DB2ASAM.051114205128;application name=db2bp.exe; auth type=NOT_SPEC;plugin name=IBMOSgroups; timestamp=2005–11–14–15.51.28.452001;category=VALIDATE;audit event=CHECK_GROUP_MEMBERSHIP; event correlator=2;event status=—1092; database=SAMPLE;userid=bondre;authid=BONDRE;execution id=DB2ASAM; application id=*LOCAL.DB2ASAM.051114205128;application name=db2bp.exe; auth type=NOT_SPEC;plugin name=IBMOSgroups; timestamp=2005–11–14–15.51.28.462000;category=VALIDATE;audit event=CHECK_GROUP_MEMBERSHIP; event correlator=2;event status=—1092; database=SAMPLE;userid=bondre;authid=BONDRE;execution id=DB2ASAM; application id=*LOCAL.DB2ASAM.051114205128;application name=db2bp.exe; auth type=NOT_SPEC;plugin name=IBMOSgroups; timestamp=2005–11–14–15.51.28.462001;category=VALIDATE;audit event=CHECK_GROUP_MEMBERSHIP; event correlator=2;event status=—1092; database=SAMPLE;userid=bondre;authid=BONDRE;execution id=DB2ASAM; application id=*LOCAL.DB2ASAM.051114205128;application name=db2bp.exe; auth type=NOT_SPEC;plugin name=IBMOSgroups; timestamp=2005–11–14–15.51.37.625000;category=VALIDATE;audit event=GET_USERID; event correlator=0;event status=0; userid=db2asam;authid=DB2ASAM;execution id=DB2ASAM; application id=*LOCAL_APPLICATION;application name=db2audit.exe; auth type=SERVER;plugin name=IBMOSauthclient; timestamp=2005–11–14–15.51.37.655000;category=VALIDATE;audit event=GET_GROUPLIST; event correlator=0;event status=0; userid=db2asam;authid=DB2ASAM;execution id=DB2ASAM; application id=*LOCAL_APPLICATION;application name=db2audit.exe; auth type=NOT_SPEC;plugin name=IBMOSgroups;

Figure 9.8

Scope = validate

289

290


Although the VALIDATE option may provide an additional level of assurance, beyond what is offered by the hosting operating system, that the user is valid, the cost of the overhead may be too great to make its use feasible. A test using this parameter may be a good idea to gauge the benefits and costs of incorporating the VALIDATE scope into your auditing solution. By default, the db2audit CONTEXT scope is set to false. This scope setting, when enabled for both success and failure, is more likely than any other to generate large amounts of audit trail data. The benefit of the CONTEXT switch is that it provides a way to interpret the audit trail information because an entire group of operations can be tied to a specific database operation. This can be done via the value in the “event correlator field.” The CONTEXT db2audit option does just as the name implies and provides a “context” or framework for the audit trail information. One of the ways it provides this framework is to include the specific SQL within the record. Because the SQL can be quite lengthy, and because it may repeat in the record for events such as a PREPARE and a DESCRIBE, setting the db2audit facility to audit CONTEXT should be carefully considered in light of the anticipated volume of data. CONTEXT

Figure 9.9 shows a very simplistic example of what the DBA might expect to see when auditing CONTEXT. In this example, the db2audit facility was configured to audit CONTEXT events (only) for both successes and failures. After the change took effect dynamically, a simple SQL query was run. Notice that five audit records were extracted for only this one transaction. Also notice that the SQL that was run is shown in its entirety twice, once in the prepare step and again in the describe step. Step 2:Verify and Display the db2audit Configuration Settings At any time prior to or after the db2audit configuration is set, the configured settings can be verified by running the db2audit describe command. This command displays the current settings for all the db2audit configuration options. In the example in Figure 9.10, notice that the db2audit facility is active (db2audit start has been run), every db2audit configuration option has been turned on for this instance, both successes and failures are being audited, and the audit errortype is set to "normal." Step 3:Start the db2audit Facility When the configuration is complete (and optionally verified by the describe command), the db2audit facility starts. The db2audit facility has to be explicitly started and stopped and functions independently of the instance commands, db2start and db2stop. The only users who have the authority to start or stop the db2audit facility are those who hold SYSADM authority. The commands to start and stop db2audit are simply db2audit start db2audit stop


291

C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2 ”select count(*) from syscat.tables t, syscat.columns c where t.tabname = ‘TABLES‘ and t.tabschema = ‘SYSCAT‘ and t.tabname in (select c.tabname from syscat.columns where c.colname = ‘TYPE‘)” 1_________ 1 1 record(s) selected. C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit extract AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>more db2audit.out timestamp=2005–11–14–17.09.01.232000;category=CONTEXT;audit event=PREPARE; event correlator=3; database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051114220824;application name=db2bp.exe; package schema=NULLID;package name=SQLC2E06; package section=201;text=select count(*) from syscat.tables t, syscat.columns c where t.tabname = ‘TABLES‘ and t.tabsc hema = ‘SYSCAT‘ and t.tabname in (select c.tabname from syscat.columns where c.colname = ‘TYPE); timestamp=2005–11–14–17.09.01.292000;category=CONTEXT;audit event=OPEN_CURSOR; event correlator=4 database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051114220824;application name=db2bp.exe; package schema=NULLID;package name=SQLC2E06; package section=201;text=SQLCUR201; timestamp=2005–11–14–17.09.01.332000;category=CONTEXT;audit event=DESCRIBE; event correlator=5; database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051114220824;application name=db2bp.exe; package schema=NULLID;package name=SQLC2E06; package section=201;text=select count(*) from syscat.tables t, syscat.columns c where t.tabname = ‘TABLES‘>;and t.tabsc hema = ‘SYSCAT‘ and t.tabname in (select c.tabname from syscat.columns where c.colname = ‘TYPE‘);

timestamp=2005–11–14–17.09.01.342000;category=CONTEXT;audit event=CLOSE_CURSOR; event correlator=6 database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051114220824;application name=db2bp.exe; package schema=NULLID;package name=SQLC2E06; package section=201;text=SQLCUR201;

timestamp=2005–11–14–17.09.01.342001;category=CONTEXT;audit event=COMMIT; event correlator=6 database=SAMPLE;userid=db2asam;authid=DB2ASAM; application id=*LOCAL.DB2ASAM.051114220824;application name=db2bp.exe; package schema=NULLID;package name=SQLC2E06; package section=0;

Figure 9.9

Scope = context

C:\>db2audit describe DB2 AUDIT SETTINGS: Audit active: “TRUE“ Log errors: “TRUE“ Log success: “TRUE“ Log audit events: “TRUE“ Log checking events: “TRUE“ Log object maintenance events: “TRUE“ Log security maintenance events: “TRUE“ Log system administrator events: “TRUE“ Log validate events: “TRUE“ Log context events: “TRUE“ Return SQLCA on audit error: “FALSE“ AUD0000I


Figure 9.10

DB2AUDIT describe

To verify that the db2audit facility has been successfully started or stopped, review the return code, which, when successful, will display the following: AUD0000I


292


The db2audit describe command can also be used to verify that the db2audit facility has been started or stopped. Step 4: Resume Normal Operations Now that the db2audit facility has been configured, verified, and started, normal processing begins to initiate audited events. This is a good time to monitor database performance and compare response times to those achieved prior to starting db2audit. If you begin to notice performance degradation, you can extract the audit records to see what activities are being logged and formulate a performance-tuning strategy based on the workload. Step 5: Handle Pending Audit Records Prior to performing an extraction of the audited events, the DBA needs to ensure that all pending audit records have been flushed to disk. There are two ways to ensure this. One is to guarantee that all db2audit records are written to disk synchronously as a matter of course. The other option is to use a db2audit facility command to flush all records from the audit buffer. The option to ensure that audit records are written synchronously as they occur is handled by the audit_buf_sz parameter for the instance’s Database Manager Configuration. Leaving this

value set at its default setting of zero guarantees that no audit records are held in the audit buffer but are instead written directly to disk. In other words, if this parameter is set to zero, there will be no pending audit records. Note that if the audit_buf_sz parameter is changed, the change does not take effect until the next time the instance is stopped and started. The size range for the audit_buf_sz parameter is set in units of 4KB pages and can be set from zero (no buffering) to a maximum value of 65,000 pages. If the audit_buf_sz parameter has been set to some value other than zero and the instance has been stopped and started, the db2audit facility will utilize an audit buffer and write the audit records asynchronously. Although performance can be enhanced by allowing audit event records to be buffered prior to writing them to disk, the downside to this approach is that records in the audit buffer at the time of an instance crash might be lost. Each organization will have to weigh the pros and cons of setting the audit_buf_sz against their security requirements. If the audit_buf_sz is zero (synchronous mode), it is possible to lose one audit record (only the current record is at risk) during an unplanned system outage event. Alternatively, if audit_buf_sz is greater than zero (asynchronous mode), all the records in the audit buffer will be lost during a crash. This is the classic dilemma of performance versus security and one that has to be resolved on a case-by-case basis. If you decide to allow the audit records to be buffered, it is advisable to do some benchmarks to determine which setting performs best for your environment. In the code example that follows, commands were run to set the audit_buf_sz parameter to create and use 32,700 4KB pages (approximately 128MB) to buffer audit records:


293

db2 update dbm cfg using audit_buf_sz 32700; db2 terminate; db2stop force; db2start;

If the audit_buf_sz is greater than zero, prior to performing an extraction of the audit records, it is a good idea to flush any buffered writes to disk. This can be accomplished using the following syntax while attached to the instance as a user with SYSADM authority: db2audit flush

When this command is run, any records in the audit buffer will be written to disk. Step 6: Extracting the Audit Records To provide an extra level of security, the audit records are written to the db2audit.log in the instancehome/security subdirectory. These records must be extracted using the db2audit facility by a user with SYSADM authority to make them available for review. When extracting the audit records, you may notice that the db2audit.log can grow quickly, so disk space may be a consideration. Adequately sizing for db2audit.log considerations is a challenging endeavor because the size of the db2audit.log is based on numerous variables. If you notice that your db2audit.log is filling up disk space faster than planned, you might consider mounting the sqllib/security subdirectory to a different machine (with dedicated disks). When ready to extract the audit trails, there are two major approaches to consider. The first approach is to generate the audit trails as text (or flat) files. The other is to generate the audit trails as ASCII files that can then be loaded into tables. Using the default extraction options will result in the generation of a file named db2audit.out. This text file format can then be reviewed using any available text editor. Because reviewing flat files manually can be a rather laborious chore, a second extraction option is available allowing the data to be formatted in a way that permits loading the data into tables within a database. To use the default option to extract records into the db2audit.out file, while logged on as a user with SYSADM authority, run the following command: db2audit extract

A new file, db2audit.out, will be created in the insthome/security subdirectory. When running this command, if the db2audit.out file already exists, the db2audit facility will return an error and an informational message, as shown in Figure 9.11. C:\>db2audit extract AUD0021N ”C:\PROGRA~1\IBM\SQLLIB\DB2ASAM\security\db2audit.out” already exists. It could be generated by previous db2au dit operation. Make sure that it does not contain any information you need, remove it and then retry the command. AUD0001N

Operation failed.

Figure 9.11

An extraction attempt fails when db2audit.out already exists

294


This is a protection mechanism to make sure that the extraction does not overwrite a file that is still needed. When the file db2audit.out is no longer in the insthome/security subdirectory, the extraction command can be successfully run again. If preferred, you may provide a filename and a path when doing the extraction. This option allows some flexibility over naming conventions that may provide an organizational benefit. For example, if you want to create a directory to store a week’s worth of audit data at a time, you could extract each day’s audit trails using a naming convention that included the date of the extraction. Your naming convention could also include the specific category or scope options that were extracted. Figure 9.12 shows an example. C:\audit>db2audit extract file c:\audit\aud.20061113.audit category audit AUD0000I


C:\audit>db2audit extract file c:\audit\aud.20061113.sysadmin category sysadmin AUD0000I


C:\audit>ls –ltr total 5 –rw–rw–rw 1user –rw–rw–rw 1user

Figure 9.12

group group

1036 Nov 12 21:34 aud.20061113.audit 2209 Nov 12 21:35 aud.20061113.sysadmin

Employing a naming standard for db2audit trails

When extracting the audit records, there is no requirement to extract every category if multiple categories have been audited. It is also possible to extract only success or failure events. In Figure 9.12, for example, although all categories are being audited, the SYSADM has chosen to extract only AUDIT and SYSADMIN events and has chosen to place each of these types of events in different text files in the directory c:\audit. Because the status option was not specified in the command, both successful and failed events were extracted by default. Many organizations prefer to extract their audit trail information in a format that allows the data to be loaded into tables. Doing so provides the ability to query the information with SQL rather than have to parse through text files. To format the output of the audit trail in delimited ASCII using the default options, run this command: db2audit extract delasc

The output is placed in the security subdirectory. Notice in Figure 9.13 that each category has a corresponding .del file even if there were no audit records recorded for that event. Also, a .del file is generated for each category whether that category is being audited or not.


295

C:\Program Files\IBM\SQLLIB\DB2ASAM\security>db2audit extract delasc AUD0000I


C:\Program Files\IBM\SQLLIB\DB2ASAM\security>ls –ltr total 18 –rw–rw–rw 1user group 4096 Nov 13 00:58 –rw–rw–rw 1user group 5114 Nov 13 00:59 –rw–rw–rw 1user group 0 Nov 13 00:59 –rw–rw–rw 1user group 0 Nov 13 00:59 –rw–rw–rw 1user group 825 Nov 13 00:59 –rw–rw–rw 1user group 189 Nov 13 00:59 –rw–rw–rw 1user group 0 Nov 13 00:59 –rw–rw–rw 1user group 2389 Nov 13 00:59 –rw–rw–rw 1user group 4014 Nov 13 00:59

Figure 9.13

db2audit.cfg db2audit.log context.del checking.del audit.del objmaint.del secmaint.del sysadmin.del validate.del

Extracting audited events to ASCII files

The db2audit command syntax provides the ability to specify ASCII file extraction for only specific categories, for only successful or failed events, and allows the specification of a delimiter other than the default (0xff) if desired. To illustrate, here is a command that can be run to extract the audit trail for the Sample database for only OBJMAINT events and sets the character string delimiter to ;. db2audit extract delasc delimiter ; category objmaint database sample

When the extraction is complete, the files can subsequently be loaded into any database, not necessarily one associated with the audit trail data. After a decision has been made to load the audit data into a database, it is a good idea to either store the information in a database created exclusively for that purpose or, at a minimum, create a separate schema in an existing database to house the audit information tables. This provides an extra layer of security for the data because privileges can be granted and revoked more easily when this data is segregated from the normal transactional tables. To create a new schema, connect to the appropriate database and run this command: db2 create schema <schema_name>

Prior to running any of the DDL to create the tables, be sure to set the schema so that the tables will be created appropriately. The command to set the schema is as follows: db2 set current schema <schema_name>

After the schema is set, you can run the DDL to create the tables. Although the DDL is included in this chapter, you can always find the most current version of the DDL on the IBM DB2 Information Center (http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com. ibm.db2.udb.doc/welcome.htm). When looking for the DDL in the DB2 Information Center, search on the topic “Creating tables to hold the DB2 audit data.”

296


— Sample DDL to create all the db2audit tables — For loading db2audit trail information CREATE TABLE AUDIT (TIMESTAMP CHAR(26), CATEGORY CHAR(8), EVENT VARCHAR(32), CORRELATOR INTEGER, STATUS INTEGER, USERID VARCHAR(1024), AUTHID VARCHAR(128)) ; CREATE TABLE CHECKING (TIMESTAMP CHAR(26), CATEGORY CHAR(8), EVENT VARCHAR(32), CORRELATOR INTEGER, STATUS INTEGER, DATABASE CHAR(8), USERID VARCHAR(1024), AUTHID VARCHAR(128), NODENUM SMALLINT, COORDNUM SMALLINT, APPID VARCHAR(255), APPNAME VARCHAR(1024), PKGSCHEMA VARCHAR(128), PKGNAME VARCHAR(128), PKGSECNUM SMALLINT, OBJSCHEMA VARCHAR(128), OBJNAME VARCHAR(128), OBJTYPE VARCHAR(32), ACCESSAPP CHAR(18), ACCESSATT CHAR(18), PKGVER VARCHAR(64)); CREATE TABLE OBJMAINT (TIMESTAMP CHAR(26), CATEGORY CHAR(8), EVENT VARCHAR(32), CORRELATOR INTEGER, STATUS INTEGER, DATABASE CHAR(8), USERID VARCHAR(1024), AUTHID VARCHAR(128), NODENUM SMALLINT, COORDNUM SMALLINT, APPID VARCHAR(255), APPNAME VARCHAR(1024), PKGSCHEMA VARCHAR(128), PKGNAME VARCHAR(128), PKGSECNUM SMALLINT, OBJSCHEMA VARCHAR(128), OBJNAME VARCHAR(128), OBJTYPE VARCHAR(32), PACKVER VARCHAR(64)); CREATE TABLE SECMAINT (TIMESTAMP CHAR(26), CATEGORY CHAR(8),


297

EVENT VARCHAR(32), CORRELATOR INTEGER, STATUS INTEGER, DATABASE CHAR(8), USERID VARCHAR(1024), AUTHID VARCHAR(128), NODENUM SMALLINT, COORDNUM SMALLINT, APPID VARCHAR(255), APPNAME VARCHAR(1024), PKGSCHEMA VARCHAR(128), PKGNAME VARCHAR(128), PKGSECNUM SMALLINT, OBJSCHEMA VARCHAR(128), OBJNAME VARCHAR(128), OBJTYPE VARCHAR(32), GRANTOR VARCHAR(128), GRANTEE VARCHAR(128), GRANTEETYPE VARCHAR(32), PRIVAUTH CHAR(18), PKGVER VARCHAR(64)) ; CREATE TABLE SYSADMIN (TIMESTAMP CHAR(26), CATEGORY CHAR(8), EVENT VARCHAR(32), CORRELATOR INTEGER, STATUS INTEGER, DATABASE CHAR(8), USERID VARCHAR(1024), AUTHID VARCHAR(128), NODENUM SMALLINT, COORDNUM SMALLINT, APPID VARCHAR(255), APPNAME VARCHAR(1024), PKGSCHEMA VARCHAR(128), PKGNAME VARCHAR(128), PKGSECNUM SMALLINT, PKGVER VARCHAR(64)) ; CREATE TABLE VALIDATE (TIMESTAMP CHAR(26), CATEGORY CHAR(8), EVENT VARCHAR(32), CORRELATOR INTEGER, STATUS INTEGER, DATABASE CHAR(8), USERID VARCHAR(1024), AUTHID VARCHAR(128), EXECID VARCHAR(1024), NODENUM SMALLINT, COORDNUM SMALLINT, APPID VARCHAR(255), APPNAME VARCHAR(1024), AUTHTYPE VARCHAR(32), PKGSCHEMA VARCHAR(128), PKGNAME VARCHAR(128),

298


PKGSECNUM SMALLINT, PKGVER VARCHAR(64), PLUGINNAME VARCHAR(32)); CREATE TABLE CONTEXT (TIMESTAMP CHAR(26), CATEGORY CHAR(8), EVENT VARCHAR(32), CORRELATOR INTEGER, DATABASE CHAR(8), USERID VARCHAR(1024), AUTHID VARCHAR(128), NODENUM SMALLINT, COORDNUM SMALLINT, APPID VARCHAR(255), APPNAME VARCHAR(1024), PKGSCHEMA VARCHAR(128), PKGNAME VARCHAR(128), PKGSECNUM SMALLINT, STMTTEXT CLOB(2M), PKGVER VARCHAR(64)) ; COMMIT;

With the tables built, loading the extracted audit data is the next step. This task is easily handled using the DB2 LOAD utility. Following the preceding example and using a semicolon as a delimiter, the following LOAD command could be used to load the data: db2 “load from checking.del of del modified by chardel; insert into audit.checking”

If the audit data were extracted using the default delimiter, the syntax would change slightly and the command would be as follows: db2 “load from context.del of del modified by chardel0xff insert into audit.context”

Another LOAD utility option that can prove valuable is the ability to replace the table data with the newly extracted data with a single command. Because the goal is to review the information, not just load it into tables, queries should be designed and run to retrieve the audit information. When the queries are run, however, and the results are analyzed (and depending on your organization’s requirements for keeping archived audit information), the data in these tables may no longer be needed. Rather than delete reviewed data that is no longer needed (a SQL delete operation incurs transaction logging overhead), using a LOAD REPLACE operation is advisable. The load utility also offers the ability to incorporate RUNSTATS as part of the load process. Having current runstats will help speed SQL query retrieval and should be considered either as part of the load operation or as a separate step. The load utility has a wealth of options. Obviously, the DBA should review the load utility syntax prior to running this command, especially if the data volumes are expected to be large or if optional parameters are desired.


299

Step 7: Prune Audit Records from the Current Audit Log The db2audit.log can grow quite large depending on the db2audit facility settings and transaction volume. After the audit records have been extracted, and optionally archived or moved to tables, pruning the db2audit.log is advisable. As a safeguard, only a user who holds SYSADM authority can perform this step. There are two primary ways to accomplish this task. The first is to prune all audit records by using this command: db2audit prune all;

The second option is to prune using a date and hour parameter. An example follows: db2audit prune 2006112008

Notice that the date format for the prune command is YYYYMMDDHH. All audit records that have a timestamp later than that supplied to the prune command will continue to be written to the db2audit.log and will be available for the next extraction operation. Pruning the db2audit.log in this manner immediately after an extraction prevents the situation where the same audit records are extracted a second time. One More Tip for Working with db2audit When planning the number of databases per instance, consider giving each database its own instance. Because the db2audit facility works at the instance level and is configured for all the databases in the instance, limiting the number of databases per instance provides a better level of granularity.

Triggers DB2 triggers are robust and can be designed to function as database auditing mechanisms. Some organizations do all their auditing with triggers. This can be a plus or a minus. On the plus side, DB2 triggers are typically easy to design, can be written “in-house” by the DBA team, and may provide good performance. On the negative side, triggers can be dropped by the DBAs, they are not fired during a DB2 load utility operation, and they will be invalidated if a trigger-dependent object is dropped. In addition, if more than one trigger is defined for one type of triggering statement, such as an update, the triggers are fired in the order of their creation. Therefore, is it better to consolidate multiple triggers into one if the result depends on the trigger firing sequence. If your auditing requirements are minimal, using DB2 triggers might accomplish the desired results, but care should be taken in complex environments. For example, at the beginning of this chapter in Table 9.2, the HRDB database requirements for auditing were found to be limited in scope. Only five tables met the requirement for database auditing. In this situation, using triggers might provide a viable solution. If the requirement had been to audit all 147 tables in the database, db2audit would have been a better choice. Following the example of the HRDB database, and specifically the EmpHist table requirement that any deletes should be captured, the steps to create a trigger to provide this functionality are

300


fairly straightforward. As an example, the following steps document the process that was used to create the trigger to satisfy the audit requirement for the EmpHist table. 1. Determine the structure of the current EmpHist table so that the trigger can be designed to accommodate it: — DDL Statements for table "DB2ASAM "."EMPHIST" CREATE TABLE "DB2ASAM "."EMPHIST" ( "EMPLID" CHAR(5) , "DEPT" CHAR(5) , "DOB" DATE , "TERM_DATE" DATE ) IN "USERSPACE1" ;

2. Create a new table to hold the audit information and add columns to hold the current user and session id that initiated the delete: C:\audit>db2 "create table db2asam.emphist_audit like db2asam.emphist" C:\audit>alter table db2asam.emphist_audit add column user char(28) add column session char(28);

3. Insert some records into the EMPHIST table for testing: insert into db2asam.emphist values ('10001', 'DBA01', '01/31/1980', '04/20/2004'), ('19001', 'ABF01', '02/28/1965', '07/10/2001'), ('09001', 'ABF99', null , '12/10/1999'), ('21001', 'CDF90', null , '06/10/1996');

4. Design the trigger and save it to a file named emphist.trig.sql: CREATE TRIGGER db2asam.emphist_trig after delete on db2asam.emphist referencing old as prev for each row mode db2sql BEGIN ATOMIC INSERT into db2asam.emphist_audit values (prev.emplid, prev.dept, prev.dob, prev.term_date, current_user, session_user); end@

5. While connected to the database, build the trigger: C:\audit>db2 -td@ -vf emphist.trig.sql

6. Verify that the trigger works as expected: C:\audit>db2 "select * from db2asam.emphist_audit" EMPLID DEPT DOB TERM_DATE USER SESSION ——— ——- ————— ————— ———————- ——————0 record(s) selected. C:\audit>db2 "select * from db2asam.emphist" EMPLID DEPT DOB TERM_DATE ——— ——- ————— ————— 10001 DBA01 01/31/1980 04/20/2004 19001 ABF01 02/28/1965 07/10/2001 09001 ABF99 12/10/1999 21001 CDF90 06/10/1996 4 record(s) selected.


301

C:\audit>db2 "delete from db2asam.emphist where emplid = '21001'" DB20000I The SQL command completed successfully. C:\audit>db2 "select * from db2asam.emphist" EMPLID DEPT DOB TERM_DATE ——— ——- ————— ————— 10001 DBA01 01/31/1980 04/20/2004 19001 ABF01 02/28/1965 07/10/2001 09001 ABF99 12/10/1999 3 record(s) selected. C:\audit>db2 "select * from db2asam.emphist_audit" EMPLID DEPT DOB TERM_DATE USER SESSION ——— ——- ————— ————— ——————— ———————— 21001 CDF90 06/10/1996 BONDR BONDR 1 record(s) selected.

When designing triggers for your environment, especially if this is an unfamiliar task, the DB2 Control Center offers a GUI option that makes the task easier. Regardless of which process you use to create your triggers, it is important to validate that they work, so testing is important. Also, remember that because triggers become invalid if any object on which they are dependent is dropped, you may need to rebuild triggers from time to time.

DB2 Recovery Expert for Multiplatform Some auditing requirements are more challenging than others. The requirement to restore data that has been mistakenly or maliciously changed is one of the more demanding requirements. If the requirement just refers to recoverability, DB2 has a native ability to recover the database to a point in time before the transaction in question occurred. If the requirement is the ability to reverse an erroneous transaction or two, restoring a database to accomplish that task is a considerable amount of overkill that can cause an unwanted database outage. Of course, if you knew which transactions were subject to going awry, triggers could be coded to save the data prior to allowing the transaction to commit. Then, update statements could be used to return the original data to its rightful place. Typically, that is not the case and predicting the future is still a skill beyond the scope of even the best DBA. One tool that allows the database to continue with business as usual while wayward transactions are corrected is the DB2 Recovery Expert for Multiplatform. This tool enables recovery of altered, corrupted, incorrect, or missing database assets without an outage. This tool is not part of the DB2 product but is a separately licensed product.

Stored Procedures, UDFs, and Other Programmatic Approaches to Auditing DB2 stored procedures have become easy to code because of great improvements in the Stored Procedure Builder GUI interface. Incorporating stored procedures, user-defined functions, and other programmatic approaches into an auditing solution is certainly an option. If your specific

302


audit requirements are minimal, it might even be possible to meet them with programmatic constructs alone.

Monitoring, Reporting, and Analyzing One of the most challenging facets of auditing is after everything is set up and running. Getting things set up is a single scope process. Continuing to be vigilant is a way of life. Being vigilant means that monitoring has to be done every day. Reports must be generated and reviewed. Analysis of the audited information must be undertaken. Abnormal events must be flagged and investigated. If there is no monitoring, no reporting, and no analysis, there is also no auditing.

LAST WORDS Database auditing should not be done until the analysis and requirements have been finalized and documented. Auditing just for auditing sake may leave an organization at greater peril than no auditing at all. Resist the urge to respond with a crisis mentality and, instead, educate your managerial audience on the appropriate steps to ensure a successful, secure implementation. Frequently, DBAs are reluctant to implement database auditing for fear of performance degradation. This is a common fear but one that does not have to be realized if the auditing is implemented appropriately. Although it is true that auditing every event might cause some observable degradation in database responsiveness, it is seldom the case that every database event must be audited. This means that it is important to know “what is important” for the specific organization. When handed the requirements, continue the process analysis. Find a way to summarize and condense requirements. Look for ways to reuse audit solutions to decrease complexity. The db2audit facility provides significant, configurable functionality. Before using this tool, it is important that the DBA understand the tool and that it is implemented appropriately. Working with the db2audit facility in a safe environment until the DBA becomes comfortable with the necessary skill set is strongly encouraged prior to implementation in a production environment. DB2 triggers can be used for database auditing as long as their inherent risks and limitations are understood and mitigated. DB2 triggers are probably more effective for limited auditing than as a 100 percent solution. Other programmatic measures may be used for database auditing, such as DB2 stored procedures or user-defined functions provided they can be coded effectively. You can purchase an additional product, DB2 Recovery Expert for Multiplatforms, if there is a need for wayward transaction recovery without a database outage. The task of database auditing is not just setting up the necessary structures and turning on a switch. The setup steps are merely the precursor to auditing. It is the monitoring and the review that actively forms the actual database audit.

CHAPTER

10


many pieces does it take to make a whole? The DBA’s answer: “It depends.” If you H ow are a DBA who manages a DPF environment, your invisible cape must be very thick indeed.

FIRST WORDS Security management for a single-partition environment is quite challenging, but multipartition databases require special considerations. What steps can you take to ensure that any machine-tomachine communications are as secure as possible?

SECURE SHELL (SSH) FOR DATA-PARTITIONING FEATURE ON UNIX With the DB2 Data-Partitioning Feature (DPF) on UNIX platforms, DB2 instances must execute commands at all partitions in db2nodes.cfg. For example, to start or stop DB2 instances, DB2 sends the actual db2start and db2stop commands to all partitions identified in the db2nodes.cfg file to be processed locally at the partition. A remote shell utility is necessary to flow the commands to those partitions. Other examples of remote processing are db2_all or rah utilities, which are sent to all partitions identified in the db2nodes.cfg file to be executed locally. Currently, DB2 supports both remote shell (RSH) and secure shell (SSH) to run these commands remotely. RSH is a program used to execute commands on a remote host. It has largely been replaced by SSH because of security concerns. RSH sends password and data in an unencrypted form, making it vulnerable to interception. Also, the rhosts mechanism used by RSH for trusted logon is

303

304

Chapter 10


vulnerable to spoofing because it does not have a means to authenticate the remote client. In comparison, SSH validates the identity of both sender and receiver much more reliably by using public key cryptography. Before we discuss how to activate SSH for DB2 on UNIX platforms, you first need to understand how to configure the SSH environment. In general, SSH is invoked by passing the remote username, address, and the command to be executed as arguments: % ssh [user@]hostname [command]

The user@ and command arguments are optional. If the username is omitted, the username of the local account is used. The command argument is the command to be executed on the remote host. If it is omitted, the default login shell is executed. If the remote host’s hostname is not in the known-hosts list, SSH prompts the user, asking whether to add it to the list and continue. If another authentication method such as public key authentication is not set up, SSH prompts you for the remote password. If the command is omitted, the remote login shell is executed. SSH supports many types of authentication. Public key authentication and host-based authentication are the types that can be used with DB2. For DB2 to work properly with SSH, the instance owner’s ID on the different physical partitions should be set up using trusted hosts so that the instance owner ID can log in to the account on any partitions (on any participating machine) without needing to enter a password.

THE SETUP STEPS In the following subsection, we first explore the general procedures necessary to set up public key and host-based authentication. Then, we cover setting up SSH for the DB2 DPF environment. To facilitate our discussion, assume that only two physical partitions are defined in the db2nodes.cfg for the database instance, machineA and machineB, respectively, with different fully qualified domain names and IP addresses. Machine Name

Fully Qualified Domain Name IP Address

machineA

machineA.domain

192.168.1.1

machineB

machineB.domain

192.168.1.2

Although the following examples are accurate on Linux platforms, some commands may vary on different platforms.

The Setup Steps

305

Public Key Authentication (per User Account) Public key authentication requires a key pair for each user account from which to execute the SSH command. The private key stays on the client machine, and the public key is copied to the server. Figure 10.1 shows the general procedures for setting public key authentication. Figure 10.2 shows the procedure used when setting public key authentication for DB2 DPF.

Figure 10.1

Figure 10.2

General procedure for setting public key authentication

Procedure for setting public key authentication for DB2 DPF

306

Chapter 10


Host-Based Authentication (per Machine) With host-based authentication, the host keys and a list of trusted hosts establish authenticity. Figure 10.3 shows the steps to set up host-based authentication.

Figure 10.3

Setting up host-based authentication

To determine whether public key or host-based SSH is best for your environment, consider the information in the following subsections.

The Setup Steps

307

Public Key Authentication Pros: • More secure because only the specified user account has access. • More flexible because usernames on the server and client do not have to be the same. • Root access is not required for configuration. Con: • More difficult to set up when there are lots of accounts. Host-Based Authentication Pro: • Easier to set up when lots of accounts require access to another host. Cons: • If one trusted host is compromised, all trusted hosts become vulnerable. • Root access is required for configuration. The database administrator needs to choose the appropriate method based on the corporate security policy that is applied to DB2 DPF on UNIX systems.

How to Configure DB2 to Use SSH As mentioned previously, the SSH utility is more secure than the RSH utility. For DB2 to use SSH, the DBA must set the DB2 registry variable DB2RSHCMD to the SSH executable. This is done with the db2set command, as shown in Figure 10.4.

Figure 10.4

Setting the DB2RSHCMD registry variable

After the DB2RSHCMD value has been set to use SSH, when DB2 issues internal commands such as db2start/db2stop or external commands such as db2_all (where the commands will be executed remotely), the SSH utility is chosen. After you have set the DB2RSHCMD registry variables, you must restart the instance so that the new setting will be in effect on the database server.

308

Chapter 10

SSH for Data Partitioning on UNIX Platforms

In some configurations on UNIX platforms, SSH may take much longer to authenticate than RSH. If DB2 does not receive a response from the remote nodes in the expected time frame, communication failure will be reported. To address this authentication timing issue, you can set another registry variable, DB2RSHTIMEOUT, to specify the amount of time, in seconds, that DB2 will wait to establish any single RSH connection before assuming there is a communication failure. Note that this registry variable will be used only when DB2RSHCMD is also set. Furthermore, this is a per-remote-command timeout; so, for instance, in a DB2 environment with an eightnode configuration, if the registry variable DB2RSHTIMEOUT is set to 4 seconds, the total cumulative time to establish all the remote connections may be up to 32 seconds. See an example of setting the DB2RSHTIMEOUT value in Figure 10.5.

Figure 10.5

Setting DB2RSHTIMEOUT registry variable

LAST WORDS Although only applicable in a DB2 DPF UNIX environment, machine-to-machine communication via SSH is strongly recommended. SSH adds depth to your secure DB2 DPF implementation and should be deployed whenever the implementation calls for multinode processing.

CHAPTER

11

Database Security— Keeping It Current

I

f DB2 database security were your boss, she would constantly be asking, “What have you done for me lately?”

FIRST WORDS Maintenance is a bore. If you own a home, you know that without preventive and necessary maintenance, the value of your home will decrease year after year. So, even though no one wants to do maintenance, it is a necessary duty to protect and preserve what you have. Would you really invest a million dollars in a home and never bother to keep it clean? It’s the same concept with DB2. Database security can be a challenge to set up, but when completed, the task of keeping it secure is never ending. This chapter deals with those requisite and perpetual needs and gives hints and tips to help you maintain that secure environment that everyone has worked so hard to foster.

DILIGENCE With every software product, there is the potential for discovery of previously unknown security vulnerabilities. These types of discoveries can be identified in several different ways. For example, IBM may identify vulnerabilities during additional development or testing. Outside security firms or persons who work with the product also may identify vulnerabilities. In a worstcase scenario, if there were a new type of attack or threat perpetrated or proposed, the act itself would also point toward a new vulnerability that would result in a mitigation effort.

309

310

Chapter 11


Although vulnerabilities native to the DB2 product have, so far, been few, vigilance is always necessary, especially because the effort to gain inappropriate database access is so tempting. Reading the numerous high-profile headlines documenting any of the recent security breaches resulting in lost or compromised personal information simply underscores the attractiveness of the data that is housed in databases to thieves, hackers, and disgruntled employees. If a vulnerability involving or threatening DB2 is identified that requires action or mitigation, IBM announces the vulnerability and provides a solution, either in the form of advice or through the release of a Fixpack. As a rule of good practice, it is important for the DB2 DBA to be aware of the issuance of an IBM DB2 alert or the release of a new Fixpack, regardless of whether the issue is security related.

DB2 User Community Resources Fortunately, IBM provides several ways to be kept aware regarding critical information about DB2. To be proactive and make sure information is received as soon as it is released, sign up for e-mailed alerts at www-306.ibm.com/software/support/einfo.html (see Figure 11.1). After you sign up, if new vulnerabilities are discovered, e-mailed specifics will be sent directly to you via “alert” e-mails so that you can take appropriate action immediately.

Figure 11.1

Subscribing to DB2 e-mail alerts

Diligence

311

The DB2 support page provides a wealth of information and can be used to research any issue, including those related to security. It is also a portal to download Fixpacks. You can reach the main DB2 support page at www-306.ibm.com/software/data/db2/udb/support/. The DB2 9 information center is another valuable tool for researching security settings (in addition to being a powerful tool for understanding DB2 in general). You can access it via http://publib. boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.doc/welcome.htm. Another great source of information is provided via RSS (Really Simple Syndication) news reader feed. Using a news reader tool (many are freely available), you can keep current via “pushed” DB2 information. Although this is not necessarily limited to security information, it is a valuable tool to keep current on product information. To subscribe, navigate your Internet browser to www-306.ibm.com/software/data/db2/udb/support/. Choose the RSS option (news feed of new content), as shown in Figure 11.2, and follow the instructions to subscribe.

Figure 11.2

Subscribing to the DB2 RSS news feed

A free resource that posts articles of a security nature is the DB2 Magazine. This magazine is a premier resource for information specific to DB2 and provides informative articles written by individual contributors and by industry-recognized experts. You can access the DB2 Magazine site via www.db2mag.com/. In addition to the IBM resources, DBAs worldwide routinely review the DB2-L list maintained by the International DB2 Users Group (IDUG). This list is not exclusive to security issues, but if

312

Chapter 11


you are a subscriber (a free registration is required), you can post questions regarding DB2 security or any other DB2 topic of interest. The URL is www.idugdb2-l.org/archives/db2-l.html.

Security Information on the Web Beyond the normal DB2 informational resources, many forums and websites can prove to be extremely useful for learning about security and for discovering how to mitigate newly found vulnerabilities. Any search on a major search engine can provide a wealth of information. For a start, considering visiting the following (listed in no particular order): http://isc.sans.org/ www.nsa.gov www.securiteam.com/ www.ittoolbox.com/ www.securityfocus.com/ www.microsoft.com/security/default.mspx www.cccure.org http://iase.disa.mil/index2.html

FIXPACKS Fixpacks hold the code that updates DB2 installations. IBM creates Fixpacks to update product features and make any necessary repairs to product code, whether security related or not. Keeping current with DB2 Fixpacks is one of the best ways to guard against security vulnerabilities and provides the extra benefit of making sure your DB2 installation is always at the most current product level. If a security vulnerability is discovered, IBM will recommend a product update via a Fixpack. Fixpacks are tied to the product version and operating system. For example, a Fixpack for Windows operating systems should not be applied to a DB2 installation on a UNIX system and vice versa. Each Fixpack includes all necessary documentation including information on prerequisites and typically includes Release Notes, a Readme file, and a detailed list of all items fixed through the application of the Fixpack. Each of the items fixed or upgraded via the Fixpack installation is known as an APAR (Authorized Program Analysis Report). Reviewing the APAR list will provide information on the items “fixed” in the Fixpack and, if security vulnerabilities are being mitigated via the Fixpack, they will be mentioned in this list.

Keeping Current Goes Beyond DB2

313

One word of caution is necessary regarding Fixpacks. Applying Fixpacks in production environments without proper testing may result in unwanted problems. It is always best to apply Fixpacks in development and test environments first, with an appropriate testing cycle to ensure that the new DB2 level does not conflict with the current production software. Most software vendors offer “certification” on certain code levels of DB2 that may lag behind the Fixpack release and make it unrealistic to apply a newly released Fixpack. The Fixpack “go/no go” decision becomes ever more difficult if security vulnerabilities have been mitigated in a Fixpack release, because the risk of not applying the Fixpack must be considered. Keep in mind that if the security vulnerability has a fix and that fix has been published (as in the case of a Fixpack release or an IBM alert), it is only a matter of time before some exploit of that vulnerability is introduced into the wild.

KEEPING CURRENT GOES BEYOND DB2 Although the focus of this book is DB2 security, remember that few environments are simple these days. It is likely that any mid-to-large enterprise environment has more than one database product and multiple software applications. Throw in operating systems into the mix and there is sufficient complexity to keep any security junkie happy. Even if your role is “only” that of DB2 DBA, keeping an eye on the rest of the environment should be a consideration if possible. If you want to be a hero, saving the company from a security lapse should accomplish that goal, whether the “save” is DB2 related or not. Consider the entire architecture, not just the databases, when thinking about current and timely application of upgrades and fixes. Third-party applications and operating systems typically publish upgrade/bug fix information on their websites prior to public product or fix releases. The task to check these resources should be formally assigned to someone in the enterprise. Subscriptions (e-mail or postal mail) to product security release information, available as a free service from most vendors, are one way to ensure that information on vulnerabilities and their appropriate fixes is received as it becomes available. Consider subscribing to e-mails for all products used at your organization even if it is not your primary responsibility. The information may be redundant because someone else in the organization may have received it; but the reality is that with heavy workloads being a norm in many shops, not all e-mails get someone’s attention. Make it your job to see that “fixable” vulnerabilities do not become hacks, regardless of whether the vulnerability is directly related to your daily tasks. It is important to remember that the enterprise databases are actually the goal of most hacks regardless of whether they are initiated at the database level or via another application or method.

314

Chapter 11


MIXED DATABASE ENVIRONMENTS If there is more than one database product in an enterprise, the task of database security takes on several additional facets. Not only will the DBA need to keep current on DB2 security and all the supporting technical architecture, but he will also potentially have to be a security expert on other database products. Because each database product brings new security challenges, managing a mixed database environment requires a heightened awareness of all the “players,” their plusses and minuses in the realm of security and their willingness to provide patches quickly should a new vulnerability be discovered. Much like breaking the string holding a necklace of pearls, it takes only a small amount of damage to cause some serious issues. Your database environment is most likely only as secure as your least-secure database product. If you are a DBA tasked with managing databases in a mixed environment and want to maintain the strongest possible security architecture, consider these points: • Consolidate database products wherever possible. Do the analysis necessary to determine the smallest common denominator of database products that will provide functionality for all enterprise applications. If you support three database products, eliminating one will reduce your exposure by a third, so this effort can be highly effective from a security standpoint. • Eliminate databases that are not needed. Believe it or not, many companies actually keep databases around that are not being used. Attempt to discover and eliminate these. Do an inventory of databases and their “owners.” Make those owners justify keeping their databases around. Although this is a good idea even if only supporting one database product, it is especially useful in mixed database models because eliminating unused databases may also eliminate the need for multiple database product support. • Make a strong case for standardizing on one database product. Standardizing on one database product may not prevent the need for extra product support, but not standardizing encourages extra product support. Do the research to determine the product that offers the best security for your organization and present a strong case to management.

VULNERABILITY ASSESSMENTS As part of an active security awareness exercise, consider performing vulnerability assessments that include all managed databases on a regular basis. Alternatively, you can purchase services or applications that provide information and detail for areas that need security improvements.

Intrusion Detection

315

When performing a vulnerability assessment, you are attempting to look at your technical infrastructure in the same way that a hacker or disgruntled employee would view it. You are attempting to find flaws in the security defense, not just in the databases, but throughout the enterprise. Because DBAs are so involved in the day-to-day operations, it is hard for them to notice minor security flaws the way a hacker would. For this reason, it is usually best to either use purchased tools for this task or hire specialists to perform the vulnerability assessments.

INTRUSION DETECTION Perimeter-based intrusion detection is typically the most deployed technological enterprise solution to discover attacks. Because managing this is not typically a DBA responsibility, it might not be immediately clear why this topic would be included in a chapter on keeping DB2 security current. If thinking of the data in the database as the “target” of an intrusion attempt, however, it becomes clear that the DBA has a major role in both being aware of attacks and preventing future attacks (keeping current). Perimeter-based security focuses on external attacks and is a strong component for any security architecture. Unfortunately, if this is the only approach taken, the possibility of an internal-based attack might be overlooked. If recent news reports are any indication, internal attacks are actually more prevalent than external ones. After all, what better way to download millions of credit card numbers than to secure a position at a financial institution with legitimate access to the information? All it takes is a few keystrokes from a SQL query to gain the information if the employee has trusted access to the data. When thinking about intrusion detection from the DBA standpoint, first realize that the discovery of an attack is after the attack. If an attack is underway, by definition, attack prevention has failed. When looked at from that viewpoint, now the goal shifts to terminating the attack as close to its initiation as possible. The good news is that DB2 offers several ways to aid the DBA in discovering intrusion attempts, both from internal and external sources. Of course, DB2 auditing (discussed in Chapter 9, “Database Auditing and Intrusion Detection”) easily lends itself to aid in intrusion detection. The other mechanisms discussed in Chapter 9, such as triggers and stored procedures, can also be used. If you haven’t already done so, read that information when thinking about setting up intrusion detection mechanisms. What might not be as obvious is that you can use DB2 snapshots to aid in intrusion detection, too. Although DB2 snapshots are typically used with a goal of performance improvement, they provide useful information that, with analysis, can aid in the security effort. One issue to consider when thinking about intrusion detection is that the intrusion will most likely present as an abnormality. Discovering abnormalities is possible only when you understand the norms, so just issuing snapshots, hoping for some “needle in the haystack,” is not an

316

Chapter 11


effective approach. Like most security processes, this one requires some analysis, maintenance, review, and change to keep it current. If there is a table in the database that has credit card numbers and addresses, for example, it might be a good table to study via snapshots. The TABLE snapshot may be highly valuable when used as a way to discover values outside of the normal ranges for table reads. If on Monday through Saturday, the number of rows read from the table is typically 8,000 and on Sunday the rows read is typically 1,000, you have the basis for norms. If those numbers begin to increase for reasons not related to business growth, you might have an abnormality that you should research. Another example is using snapshots to gather all dynamic SQL (although you have to be aware of a potential performance hit) in conjunction with setting the STATEMENT monitor switch. If the DBA knows, for instance, that a sensitive table is accessed only via a stored procedure launched by the application, but suddenly sees that an unrecognized or poorly formed SQL statement has been running against that table, discovery action could be initiated. Obviously, the DB2 audit facility provides functionality similar to the information that can be gathered using snapshots, but because not all corporations run a DB2 audit, or don’t fully utilize it, snapshots can provide some measure of intrusion detection discovery when properly thought out and initiated. To learn more about all the functionality of DB2 snapshots, including how to set the necessary monitor switches for information gathering, see the DB2 Information Center at http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.doc/we lcome.htm or read about the topic in the DB2 Command Reference.

PREPARE FOR A BREACH If a breach occurs, despite all your valiant efforts, don’t panic. Undoubtedly, your heart rate and blood pressure will rise, but giving in to despair will not enable the type of response that is necessary. As with most situations in life, if you are prepared for any eventuality, it is easier to achieve a positive outcome. Prepare yourself and your organization now for the possibility of a breach. The best way to prepare for dealing with a hack is to practice a response. A highly effective way to ensure preparedness is to simulate a response to a breach of highly sensitive data. Before beginning this type of “trial run,” it is a good idea to create a checklist of items that need to be completed in the event of a breach. During the exercise, someone should function as an observer, noting any items that are not on the checklist (but should be), items that should be improved, items that should be removed, and items that are effective as written.

Preparing for the Future

317

In preparing for a response to a breach, preparation topics often overlooked include the following: • Keep a current list of all individuals who must be contacted in the event of a breach. If a breach occurs, who would you call? Do you have current contact information for those individuals? Should you call each person on the list or delegate that task to others? Who should be called first, second, and so on? How is the list to be stored? If electronically, what happens if the system is so compromised that the contact list cannot be accessed? Is the list maintained in a current state? Is the list reviewed regularly? Is there a secondary call list for individuals who might not need to be initially involved, but whose expertise will be needed to validate systems after the initial triage? Also, consider that the corporation’s attorneys, law enforcement, and regulatory bodies should be notified in most cases. • What is the scope of the breach? A breach could be minor or a worst-case scenario. In recent news, we have seen occasions where thousands of credit card numbers have been stolen and cases where only minor intrusions occurred. Until the scope of the breach is determined, it is difficult to formulate an action plan. Determining the scope of the breach should be a top priority. Consider who should be involved in the discovery process. More than a small number of individuals may actually be detrimental to the process. For example, a breach might have caused the databases to go or be taken offline. To perform “discovery,” the DBAs are using terminal access. If there is limited availability of terminal access, individuals who do not have terminal access may actually deter the work of those who do. Keep this group of individuals as small as possible to effectively do the work required. This is one case where “more” is not “better.” • Should the databases be taken offline? If the databases are still online after a breach, this could be a tough decision to make. If data was stolen, taking the database offline could prevent further intrusions, but such an action could also put a company out of business. A good approach is to meet with management prior to the simulation and formulate a list of guidelines that would best serve your organization. In most organizations, attorneys should also be involved in these types of discussions.

PREPARING FOR THE FUTURE It would be great if each of us knew what security vulnerabilities were coming so that we could be prepared beforehand. Because that is not possible, however, a good plan is to make ourselves as knowledgeable about past and present threats as possible while considering how these threats might “morph” into even stronger future threats.

318

Chapter 11


When implementing a new database architecture, some normal operations, such as contingency planning, can also be a valuable exercise if applied to potential future threats. Think about contingencies to mitigate today’s concerns, as well as potential concerns five years forward. As an example of “thinking forward” for security, when creating a new database environment, the DB2 DBA may implement Label Based Access Control (LBAC), even though there is no formal requirement to do so. Although extra work might be required, the DBA knows that LBAC is inherently more secure than the official requirement and that database security will benefit now and in the future. The cost/benefit ratio might not be evident now but might be very evident at some point in the future. Consider planning a formal time on a quarterly or more-frequent basis, to do an evaluation of security as it applies to DB2 and the technical architecture in place in your organization. Approach your personal “security” education as a life-long learning experience. Ask questions, read newly released books and articles, study the news, and remain on guard so that the future doesn’t catch you unprepared to protect your databases.

LAST WORDS Security is not just a function of the original setup and installation. It is an ongoing task. It is important that those tasked with database security keep a focus on current security, an understanding of the successes and failures of the past, and an ability to look toward the future. This involves continuous diligence, a curiosity that inspires a commitment to continuous learning cycles, and an approach that includes keeping up with current events and news about security vulnerabilities.

CHAPTER

12

Final Thoughts: Security— The Human Factor

as human emotions, the reasons to consider the human factor in any security setA stingvaried are just as important as building the technological foundation for a secure architecture.

FIRST WORDS No security implementation would be complete without addressing the human factor. Throughout this book, the focus has been on the “geeky” side of DB2 security or, in some cases, the “managerial” side of security, both of which are critical. Until humans (and the strong emotions that drive them) can be eliminated from the security equation, security planning has to factor all the varieties of human intervention into building a secure environment. Think of it this way: No matter what technology is used, a human is at the heart and soul of every security exploit. Security is not merely about the technology. It’s about the technology and the people. If anything, this topic is as much on psychology and social norms as it is on security technology, but because an all encompassing road map of the human mind has yet to be graphed into a data model, DBAs must have an awareness of the human security risks so that, at a minimum, they don’t foster occasions for a security compromise. Because humans are so complex, it would be easy to throw up your hands and admit defeat when it comes to hardening your environment against the human factor. Certainly, no one can ever be completely prepared for the variety of intellectual mechanizations that can result in a “datacompromised” situation. Admitting defeat and walking away, however, is not an option if you want to continue receiving paychecks.

319

320

Chapter 12


Although it is challenging to work to protect ourselves from the human factor, if we use history as our guide, we can take steps to either mitigate the best known of these issues or to prevent them all together.

EDUCATION AND AWARENESS It would be difficult to overstress the importance of education when it comes to security. Although educating the technologists is always important, this topic is not referring to education just for the technologists, but education for the people who are often forgotten when planning a secure enterprise. For example, it is easy to plan on educating management regarding security policies and procedures because they are so “visible,” but what about the end users? How about the receptionist who greets visitors or answers the phone? How about your sales force? How about the janitor who empties the trash? Basically, all those who interact with or work near the secure system should receive some level of security education and should be required, in writing, on an annual basis, to agree (in terms proposed by the company attorneys) that they have been made aware of the company’s security policies and that they will not violate them.

For Geeks Only It is expected that technologists will understand the technology they support. Throw security into the mix and the knowledge to claim expertise in both DB2 and security is significant, requiring a breadth of experience well beyond the requirements of the technology itself. Why? Because those who would initiate a security exploit against databases are evolving and learning from the past. Even if the technologist is keeping pace learning about the new features of each DB2 product release and maintaining a security awareness, the new ways that humans will attempt to exploit the product are limited only if they have not been thought up. The minute the thought enters the brain of someone looking to compromise a DB2 database, the technologist who is trying to keep security intact is at a disadvantage. There is no such thing as too much experience or too much education when it comes to security. Consider recent history to recognize how quickly technology has changed. In 1971, a computer was a huge machine that, in many cases, provided less actual computing power than a child’s calculator does today. Security exploits were nonexistent. Now, as you look at your subcompact notebook computer, think back to the headlines of the last year … the credit card numbers stolen by the hundreds of thousands, the identities that were exposed, the financial transgressions aided by improper use of computers … and recognize the exponential change in what is only a short span of time for humanity. For technologists, life-long learning is a requisite. If you love what you do and are good at it, you probably already realize this and already understand that this continual learning cycle serves not just your own career, but the well-being of the organization that employs you. If you are committed to obtaining the most solid foundation in DB2, you will probably attend IBM classes and

Education and Awareness

321

conferences, study online materials, read books on the product, and try to find a mentor. Likely, these are all available to you, provided you have the funds to cover any associated costs. But, is that enough? Whereas in the past it might have been, now the DB2 DBA needs to reach out and learn about the ways that security can be improved and study ways that it has been compromised. You can no longer ignore educating yourself regarding security, both internal and external to the databases you are employed to administer. Product knowledge is absolutely essential, but an overarching understanding of security, including keeping up with current affairs, is vital. The DB2 DBA should consider supplementing the normal avenues for database administration learning with coursework in security. The ways to do this are varied and can be anything from subscribing to security-focused newsgroups, taking college courses on the topic, reading current books and magazines on the subject, attending boot camps, or taking week-long, focused classes. Finding this information could not be easier. A search on any major search engine will turn up numerous hits for security-related coursework and newsgroups. One caution, however, is that an education in security is a moving target, so your choices for education need to be reviewed periodically to determine whether they are staying on the cutting edge of the topic. As part of your continuing education, consider checking out these sites for topics on security: www.governmentsecurity.org/ http://niap.nist.gov/ www.cert.org/ www.zdnet.com www.ittoolbox.com/ http://groups.google.com/ www.linuxsecurity.com/

For the “Normal” Folks It’s obvious that the technology staff of any organization, in addition to being savvy about the products they support, needs to be aware of any security implications. It is also pretty obvious that personnel whose primary purpose within the organization actually is security needs to have a solid education and experiential focus on every aspect of security. What might not be so obvious are the educational needs of all the “others.” Those are the “normal” folks whose work lives do not necessarily revolve around technology and who don’t keep abreast of the most current hack and how it is being played out. Security training for all personnel should occur annually if not more often. True, this is not the role of the DB2 DBA; but if individuals in your organization are not made aware of proper security procedures, this will impact your job in some negative way at some point. For example, if a

322

Chapter 12


receptionist who inputs data into the DB2 database becomes lax and leaves her password taped to her keyboard in plain view, she has invited anyone who desires the opportunity to access (at a minimum) the same data that she does. If an intrusion occurs, the DB2 DBA is going to be inundated with work. Situations where employees are terminated, without following proper security safeguards, are also ripe for security exposure that would impact the DBAs. So, despite it not being a DB2 DBA’s job to provide adequate security training for all staff, it is in his or her best interest to raise the issue to management if the training has not been provided or is not comprehensive enough.

SOCIAL ENGINEERING It is a positive social condition, the desire to help others, which often leads to our security downfall when the root cause is “social engineering.” Social engineering, or the ability to employ societal norms to a dishonest advantage, is too seldom taken seriously when thinking about security. If you do not think that social engineering is a threat to your secure enterprise, think back to the last time you saw a stranger at work. You probably rationalized that the person was there for a valid reason. Perhaps, you thought the person was selling something or was a new employee; but your first thought was probably not, “This is the person who is going to try to gain access to our secure databases.” You applied your bias to the situation and assumed that the stranger was “safe.” It is just human nature that we attribute to others the thoughts, values, and social norms that we ourselves hold. Because we would never employ devious means to secure access, we assume others would not either. Given this tendency, social engineering can be a highly effective means to gather enough information to gain privileged access. Individuals who plan to use social engineering as a ploy know the nature of humans. They understand our innate desire to help. They know that we attribute our own traits to others. They understand that fear is a driving force. They understand our desire to avoid personally embarrassing situations. They devote time and energy to knowing these things so that they can use them to their advantage. The best defense against social engineering is an awareness of the vulnerabilities that the social engineer attempts to exploit. None of us is too smart to be manipulated given the right set of circumstances, but we can raise our awareness regarding these types of exploits so that they lose effectiveness or become enough of a challenge to drive the social engineer elsewhere. Role playing is one highly effective way to reinforce defenses against this type of exploit. Solid training is another.

Publish and/or Perish?

323

STEP ON A CRACK—BREAK SECURITY’S BACK In America, young children have a saying, “Step on a crack, break your mother’s back.” With each step they take, they work to avoid stepping on any cracks in the sidewalk for fear that their mother might suffer ill effects. Cracks in security, no matter how small, can result in a security break. While a 100 percent security success rate is unattainable, it should always be the goal. Just like the child’s diligence to protect their mother, the organization must proceed through every initiative with security in focus, and it should be as a first thought, not an afterthought. Businesses, and the humans who control them, always realize that the bottom line determines success or failure. It is a normal human condition to narrowly focus on the avenues that appear to best represent success, which, in this case, is measured by financial goals. Unfortunately, because security initiatives can deplete the bottom line, they are sometimes deliberately left “wanting” in pursuit of a larger “black” number on a balance sheet. In the past, many organizations have “gotten away with it” and ignored security while fattening their profits. They had no breaches and no one was the wiser. This brings to mind another human condition. We have a tendency to judge the future based on the past. If, in the past, your organization had no effective security in place, and there was no breach, the historical view is that it is not needed, and the impetus will be to maintain the status quo. Inertia may set in. Or, perhaps, there is a security focus now, but because there has been no breach, funding for future initiatives doesn’t include line items for security. This is a shortsighted view, however, and is equivalent to gambling with the company’s assets. Consider this personal note on the human factor and security. If you want to maintain your continued employment but you see that security is suffering due to inertia, take the initiative. It might not be as difficult as you believe to make something positive happen. Sometimes, it just takes one person to rally the troops.

PUBLISH AND/OR PERISH? Have you ever thought, as you watched the news, that current criminal events seems to mirror the story lines of prime-time detective shows? Was the pretend murder scenario that played before millions of viewers only a few weeks ago eerily similar to the real murder on the news channel tonight? It is hard to know for sure whether a correlation exists between fictional portrayals of events and the impetus for a corresponding copy of those events, but a casual observation seems to make the point that one does.

324

Chapter 12


This potential relationship between a portrayal and an actual event makes for an interesting discourse when thinking about security. Did the fictionalized account of the crime lead to the real crime? Was a thought planted by the fictional story that was nurtured until it became the root cause for a real event? Are security breaches, when published, leading to copycat attempts? If your organization participates in a simulation of a security breach, should you publish the results? The usual answer is “probably not.” Why? Because publishing the results of your simulation provides clues to how to breach your defenses. How often have you seen companies publish, for example, that a simulated penetration test on their defenses was breached in less than 60 seconds? You’re not likely to ever see this type of information willingly exposed to the world for fear that the information would encourage real security exploits. On the other hand, what about information on “real” security breaches? We’ve all seen those, but seldom have we seen the initial news release originating from the company that experienced the breach. Typically, a news agency has published the details of the breach, and then the company reacts to the initial news with a press release of its own. It seems that the organizations experiencing the breach are not inclined to publish until the events are exposed by others. Fortunately, the releases, whether by the organization or the news media, typically do not provide enough details for others to pick up on the exploit, but instead give generalities (such as 30,000 credit card numbers were stolen). Unfortunately, the publicity may encourage copycats who will see whether they can repeat the exploit either at the same company or on a new victim. In addition to current and proposed regulatory requirements regarding security breaches that result in an impact on individual’s lives, the company needs to weigh the impact of publishing or not publishing should a breach occur. Both options present risk and both present opportunities. Do Not Publish Like all of us, managers need to have a strong sense of self-preservation and don’t enjoy admitting that mistakes were made. It could never be a pleasant experience to call up a major news organization and admit that “under your watch” a security breach occurred. If the breach were small, it might not even be newsworthy, but “small” is in the eyes of the beholder. Aside from the normal tendency to not deliver bad news unnecessarily, however, there might be valid reasons to keep quiet about security breaches. For example, the FBI might be doing an investigation into the matter, and public disclosure could weaken their position. This is an obvious situation where no information should be published and does not require any further analysis to make a decision. However, there are often areas where an argument to keep the information quiet is not as black and white. For example, perhaps the breach was completely internal (an inside job), it has been rectified, the offenders were appropriately dealt with, and preventive steps have been taken. Is it valid to keep the breach from the public? One of the major reasons that many companies do not

Last Words

325

publish is fear of the resulting negative pressure on the stock price or the fear of increased outside scrutiny. Is the fear of a stock decline enough to warrant keeping the breach quiet? The reward with this “don’t publish” strategy is obvious. The information is not disseminated; therefore, to the outside world, no breach occurred. This is the “keep the secret” defense and is one that is the most frequently used. There is no public “black eye” and no stock-price drop. The significant risk with this strategy is that the secret will leak in an embarrassing public display that will harm the corporation more than had it openly disclosed the facts as soon as it was appropriate to do so. Publish Many years ago in the United States, a product-tampering scare caught the nation’s attention. Somehow, Tylenol®, a widely used over-the-counter drug, had been laced with poison. When the initial reports came out, it could have ruined the manufacturer, Johnson & Johnson. Even though the company quickly realized that the product tampering had probably only occurred in Illinois and that the rest of the country could still safely consume Tylenol, Johnson & Johnson embarked on a massive publicity campaign and took extraordinary measures to inform the public and ensure safety. These public measures are now widely cited as having saved the company from certain financial disaster. Apply that same thought process to the argument of the company willingly admitting being on the wrong side of a security incident. Conversely, if the breach is big enough to be “hushed up,” it is also big enough to cause some serious negative reactions when it is, eventually, found out. Companies that do practice public disclosure in an appropriate manner and in a timely fashion may be able to win the public’s trust with limited negative reaction. Your company may even benefit in the long run because the public may trust it to be honest. Most people prefer to do business with corporations that they consider trustworthy. The significant risks of this strategy is that it will not be perceived well by the public or even that it will spur others to test out the vulnerability by attempting a hack themselves. As usual, the decision of whether to publish or keep silent on security breaches can be made only after an effective analysis of the entire scope of the situation has been completed. To the question “publish or not?” the answer is “it depends.”

LAST WORDS Technology alone can never be the master of security. Only when recognizing the full scope and interplay of technology and the human factors surrounding all security aspects will the complete picture emerge.


APPENDIX

A


T

his appendix lists some of the enterprise security packages that the DB2 DBA may encounter, along with some associated URLs. It is not an all-encompassing list: • IBM Tivoli® Risk Manager Tivoli Risk Manager enables you to integrate application, operating system, and network security approaches. It can provide risk alerts from firewalls, routers, networks, host- and application-based intrusion detection systems, desktops, and vulnerabilityscanning tools via one central console. For more information, see www-306.ibm.com/software/tivoli/products/risk-mgr/ • IBM Tivoli Identity Manager As the product name implies, Tivoli Identity Manager is a targeted solution useful for securely automating the complete user management cycle. Tivoli Identity Manager handles user account and password management and includes robust security compliance and regulatory reporting options. For more information, see www-306.ibm.com/software/tivoli/products/identity-mgr/index.html • IBM Tivoli Access Manager Tivoli Access Manager provides authentication and authorization functionality. It enables you to implement a single sign-on (SSO) solution and eases the administrative burden by allowing the centralization of enterprise security management.

327

328

Appendix A


For more information, see the following websites: www-306.ibm.com/software/tivoli/sw-bycategory/subcategory/SWI10.html www-306.ibm.com/software/tivoli/products/access-mgr-e-bus/ www-306.ibm.com/software/tivoli/products/access-mgr-operating-sys/ www.devx.com/ibm/Article/26683

APPENDIX

B

Kerberos

Most of this appendix information was sourced from the developerWorks article “DB2 UDB security, Part 6: Configure Kerberos for authentication on DB2 UDB for Linux, UNIX, and Windows” at www-128.ibm.com/developerworks/db2/library/techarticle/dm-0603see/index. html.

CONFIGURING THE NAS KIT ON UNIX®/LINUX® SYSTEMS FOR THE IBMKRB5 PLUG-IN Step 1: Set up the KDC server. This guide assumes that you use the NAS kit for the KDC server. If you use another KDC server, refer the installation guide for your KDC software. For AIX, you can get the NAS server kit from the AIX installation bonus CD. Note that NAS server is available only for the AIX platform at the time of this writing. Steps to set up the NAS server - KDC: 1. 2.

Install the latest version of Network Authentication Service server from CD or download it as part of the AIX expansion pack. Configure the KDC server by the following command: /usr/krb5/sbin/config.krb5 -S -d domain -r realm (where realm is the realm you will be using).

3.

Start the KDC server by running: /usr/krb5/sbin/start.krb5

329

330

Appendix B

Kerberos

Step 2: Set up the NAS client. IBMkrb5 only supports NAS clients. Red Hat Linux

AIX

Solaris

You can obtain the NAS client kit from the AIX installation bonus CD or download it from as part of the AIX expansion pack.

DB2 requires Solaris Operating Environment 8 or later with IBM Network Authentication Service (NAS) client v1.3 or higher. For Solaris Operating Environment 10, NAS client v1.4.0.4 or later is required.

a.

Download the NAS client package from the NAS Kit download site link in the “Useful Links Section” and install the package.

From v82 on, DB2 requires Red Hat Enterprise Linux Advanced Server 3 (Intel 32 bit only) with IBM Network Authentication Service (NAS) v1.4 or higher. From v9 on, DB2 requires Red Hat Enterprise Linux Advanced Server 4 or Suse SLES 9 (Intel 32 bit and 64 bit) with IBM Network Authentication Service (NAS) v1.4.0.4 or higher.

b.

Set up the krb5 configuration file.

Issue the following commands to set up the client: /usr/krb5/sbin/config.

Solaris NAS does not ship with the

krb5 -C -r realm -d domain -c KDC -s kadmin_server. The config.krb5 creates the configuration file krb5.conf under /etc/krb5/.

config.krb5

executable; therefore, it requires you to manually edit the configuration file at /etc/krb5/ krb5.conf. Please

ensure that the edited file is /etc/krb5/ krb5.conf and not /etc/krb5.conf. You must also add the default realms, domain_realm, and so on to the file. Solaris supports only Single DES. Please ensure the krb5 configuration on both the NAS client and NAS server are modified to take this into consideration.

Configuring the NAS Kit on UNIX/Linux Systems for the IBMKrb5 Plug-In

331

Step 3: Create server principals (service principals) in the KDC. To use NAS, ensure that you add /usr/krb5/bin and /usr/krb5/sbin into the PATH of environment before any other Kerberos in your system. You might already have other Kerberos software installed when you install Red Hat Linux. To create a server principal, follow these steps: 1.

Issue the command /usr/krb5/sbin/kadmin on the DB2 server machine to start any kadmin session using the admin principals.

2. After the kadmin prompt, issue addprinc principal_name. The server principal name for the DB2 UDB instance is assumed to be /@REALM. This principal must be able to accept Kerberos security contexts, and it must exist before starting the DB2 UDB instance because the server name is reported to DB2 UDB by the plug-in at initialization time. 3.

Create an entry for the server principal in the keytab file. You are required to run the kadmin as root from the DB2 server machine. Otherwise, you may need to copy the keytab file to the DB2 server machine. Under the kadmin prompt, issue ktadd server_principals. The default keytab file is local under /etc/krb5/krb5.keytab, and it is readable only by the root. You are required to change the permission of the file to readable by the DB2 instance ID. If you want to change the local of the keytab file, you can use the NAS environment variable KRB5_KTNAME and add KRB5_KTNAME to db2envlist registry variable.

Step 4: Create Kerberos users (client principals). The principal may be found in either a two-part or multipart format (that is, name@REALM or name/instance@REALM). Because the name part will be used in the authorization ID (AUTHID) mapping, the name must adhere to the DB2 database naming rules. This means that the name may be up to 30 characters long, and it must adhere to the existing restrictions on the choice of characters used. Create the user principal by using addprinc under kadmin. Step 5: Set up the DB2 side to use Kerberos authentication. Chapter 3, “Understanding Identification and Authentication—The First Line of Defense,” provides a good explanation of this.

332

Appendix B

Kerberos

Step 6: Authenticate yourself to the KDC for both the DB2 client and server. Client

Server

To connect to the DB2 server, you must use the user principal as the username. For example: db2 connect to sample

To start DB2, log in to the DB2 server machine and run kinit, get the ticket for the instance ID, and then run db2start.

user boss/db2inst using password

Or you can run kinit first before obtaining the credentials. Then, you can connect to the DB2 without using a password.

CONFIGURING THE WINDOWS® CLIENT AND DOMAIN CONTROLLER TO ENABLE THE WINDOWS NATIVE KERBEROS ENVIRONMENT Setting up the DB2 client and server on Windows 2000 and later using Kerberos is trivial. All domain users are equivalent to Kerberos principals, and Active Directory acts as the KDC. Step 1: Set up the KDC. Basically, you need to set up a Windows 2000 (or later) server as a domain controller that has Active Directory enabled. The command to upgrade a Windows server to a domain controller is dcpromo. See the “How to promote and demote domain controllers in Windows 2000” link in the “Useful Links” section later in this chapter for more details. Requirements: Windows 2000 (or later) server with the Active Directory Setup: 1.

Enable the Active Directory.

2.

It is recommended that the domain name be in uppercase to facilitate compatibility with non-Windows Kerberos.

Step 2: Configure the Kerberos configuration file. Microsoft Active Directory uses DNS for Kerberos name mapping; therefore, there is no configuration file. Step 3: Create Kerberos users (client principals) and server principals (service principals) in the KDC. To add users and service principals in Active Directory, use the GUI tools on the Active Directory server machine. Click Manage User Accounts and Group Settings to bring up the Active Directory Users and Computers menu screen. Then, right-click the Users folder and create a new user (for example, “see”). Next, create another user (for example, “db2serv”) for the service principal.

Interoperability

333

Step 4: Set up the server key table (keytab) file. DB2 does not use a keytab file on Windows. The system automatically handles storing and acquiring the credentials handle for a service principal. Step 5: Set up the DB2 side to use Kerberos authentication. Chapter 3 provides a good explanation of this. Step 6: Authenticate yourself to the KDC for both the DB2 client and server. To authenticate to the Active Directory KDC, all you have to do is log on to the domain. Requirements: Windows 2000 (or later) workstation that is a part of a Windows 2000 or later domain Setup: 1.

Be sure your machine is a member of a domain. Log on to the machine as a domain user.

2.

On the server, start the DB2 service as a domain user (maybe started as the SYSTEM account if the client and server are both Windows machines that are part of the same domain).

Log on to the DB2 client machine using the domain account, and log on to the DB2 server machine using the domain account db2serv. Then, start the DB2 service on the DB2 server using that domain account as follows: Go to Control Panel, Administrative Tools, Services. Then, find the DB2 - service, right-click, go to Properties, Logon tab, and then be sure the domain user has been specified (and not Local System Account).

INTEROPERABILITY DB2 using Kerberos works in the following configurations: Table B.1

DB2 LUW Version 8.2 (Stinger Release) and Its Subsequent Fixpacks

AIX 5.1, AIX 5.2, Solaris 8, Solaris 9 RHEL AS 3, Win2000

↔

AIX 5.1, AIX 5.2, Solaris 8, Solaris 9 RHEL AS 3, Win2000 I/Series

→

Z/Series

334

Appendix B

Table B.2

Kerberos

DB2 LUW Version 9 (Viper Release) and Its Subsequent Fixpacks

AIX 5.2, AIX 5.3, Solaris 9, Solaris 10 Suse SLES 9 (2.6 Kernel), RHEL AS 4 (2.6 Kernel), Win2000

↔

AIX 5.2, AIX 5.3, Solaris 9, Solaris 10, Suse SLES 9 (2.6 Kernel), RHEL AS 4 (2.6 Kernel), Win2000 I/Series

→

Z/Series

The following table shows the difference between DB2 running on LUW, Z/Series, and I/Series in terms of Kerberos support.

Z/Series

I/Series

Linux/UNIX

Windows

What is required on the system

Requires Network Authentication and Privacy Service (NAPS)

Requires V5R2 and Network Authentication Service

Requires IBM Network Authentication Service

Domain controller that has Active Directory enabled

Mutual authentication

Does not support mutual authentication

Supports mutual authentication



Principal to user mapping

Done through RACF

Done through EIM (Enterprise Identity Mapping)

Done through KDC (NAS server)

Done through the domain controller

Server only or client with Kerberos

Can act as a server Can act as a server or client with or client with Kerberos Kerberos

Supports Kerberos Can act as a server as a client or a server or both

USEFUL LINKS Kerberos general references: • Kerberos FAQ www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html • MIT Kerberos http://web.mit.edu/kerberos/www/index.html • Microsoft Kerberos (SSPI) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/security_ support_provider_interface_sspi_.asp

Useful Links

335

• J. Kohl and C. Neuman, “RFC 1510: The Kerberos Network Authentication Service (V5),” Internet Engineering Task Force, 1993 www.ietf.org/rfc/rfc1510.txt • Sharing a Secret: How Kerberos Works www.computerworld.com/computerworld/records/images/pdf/kerberos_chart.pdf Kerberos interoperability on different operating systems • Microsoft Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx • Kerberos on zOS and OS390 http://shareweb.share.org/proceedings/sh98/data/S1723.PDF • How to set up Kerberos interoperability between RACF on z/OS and Windows 2000 / XP domains (see Chapter 3 [3.7, 3.8]) www.redbooks.ibm.com/abstracts/sg246540.html?Open • Interoperability with Microsoft Windows 2000 Active Directory and Kerberos Services http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnactdir/html/ kerberossamp.asp NAS kit download site: • NAS kit Kerberos client for Solaris and Linux download www6.software.ibm.com/dl/dm/dm-nas-p Other related references: • Authenticating to AIX Using Kerberos http://publib16.boulder.ibm.com/pseries/en_US/aixbman/security/kerberos_auth_only_ load_module.htm • Configuring DB2 UDB with VAS for Active Directory authentication http://rc.vintela.com/topics/howto/db2/ • DB2 Authentication with Kerberos http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2. udb.doc/admin/c0011990.htm • Understand the DB2 Universal Database security plug-ins www.ibm.com/developerworks/db2/library/techarticle/dm-0512chong/

336

Appendix B

Kerberos

• Step-by-Step Guide to Managing Active Directory www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/ activedirectory/stepbystep/admng.mspx • How to promote and demote domain controllers in Windows 2000 http://support.microsoft.com/kb/q238369/

APPENDIX

C


Table C.1

Audit Record Layout for AUDIT Events

Name

Format

Description

Timestamp

CHAR(26)

Date and time of the audit event.

Category

CHAR(8)

Shows that this is an AUDIT event.

Audit event

VARCHAR(32)

Specific audit event. Possible values include CONFIGURE, DB2AUD, EXTRACT, FLUSH, PRUNE, START, STOP, and UPDATE_ADMIN_CFG.

Event correlator

INTEGER

Correlation identifier for the operation being audited. Can be used to identify what audit records are associated with a single event.

Event status

INTEGER

Status of audit event, represented by a SQLCODE where successful event > = 0; failed event < 0.

User ID

VARCHAR(1024)


Authorization ID

VARCHAR(128)


337

338

Table C.2

Appendix C


Audit Record Layout for CHECKING Events

Name

Format

Description

Timestamp

CHAR(26)


Category

CHAR(8)

Shows that this is a CHECKING event.

Audit event

VARCHAR(32)

Specific audit event. Possible values include CHECKING_OBJECT, CHECKING_FUNCTION, and CHECKING_TRANSFER.

Event correlator

INTEGER


Event status

INTEGER


Database name

CHAR(8)

Name of the database for which the event was generated. Blank if this was an instance-level audit event.

User ID

VARCHAR(1024)


Authorization ID

VARCHAR(128)


Origin node number

SMALLINT

Node number at which the audit event occurred.

Coordinator node number

SMALLINT

Node number of the coordinator node.

Application ID

VARCHAR (255)

Application ID in use at the time the audit event occurred.

Application name

VARCHAR (1024) Application name in use at the time the audit event occurred.

Package schema

VARCHAR (128)

Schema of the package in use at the time of the audit event.

Package name

VARCHAR (128)

Name of package in use at the time the audit event occurred.

Package section number

SMALLINT

Section number in package being used at the time the audit event occurred. (continues)

Appendix C


Table C.2

339

Audit Record Layout for CHECKING Events (Continued)

Name

Format

Description

Object schema

VARCHAR (128)

Schema of the object for which the audit event was generated.

Object name

VARCHAR (128)

Name of object for which the audit event was generated.

Object type

VARCHAR (32)

Type of object for which the audit event was generated.

Access approval reason

CHAR(18)

Indicates the reason why access was approved for this audit event.

Access attempted

CHAR(18)

Indicates the type of access that was attempted.

Package version

VARCHAR (64)

Version of the package in use at the time that the audit event occurred.

Checked authorization VARCHAR(128) ID

Authorization ID is checked when it is different than the authorization ID at the time of the audit event.

340

Table C.3

Appendix C


Audit Record Layout for OBJMAINT Events

Name

Format

Description

Timestamp

CHAR(26)


Category

CHAR(8)

Shows that this is an OBJMAINT event.

Audit event

VARCHAR(32)

Specific audit event. Possible values include CREATE_OBJECT, RENAME_OBJECT, DROP_OBJECT, and ALTER_OBJECT. ALTER_OBJECT events are generated only when altering protected tables.

Event correlator

INTEGER


Event status

INTEGER


Database name

CHAR(8)

Name of the database for which the event was generated. Blank if this is an instance-level audit event.

User ID

VARCHAR(1024)


Authorization ID

VARCHAR(128)


Origin node number

SMALLINT



SMALLINT


Application ID

VARCHAR (255)


Application name


Package schema

VARCHAR (128)


Package name

VARCHAR (128)

Name of the package in use at the time the audit event occurred.


SMALLINT

Section number in package being used at the time the audit event occurred. (continues)

Appendix C


Table C.3

341

Audit Record Layout for OBJMAINT Events (Continued)

Name

Format

Description

Object schema

VARCHAR (128)

Schema of the object for which the audit event was generated.

Object name

VARCHAR (128)

Name of object for which the audit event was generated.

Object type

VARCHAR (32)


Package version

VARCHAR (64)

Version of the package in use at the time the audit event occurred.

Security policy name

VARCHAR(128)

The name of the security policy if the object type is TABLE and that table is associated with a security policy.

Alter action

VARCHAR(32)

Specific alter operation. Possible values include the following: ADD_PROTECTED_COLUMN ADD_COLUMN_PROTECTION DROP_COLUMN_PROTECTION ADD_ROW_PROTECTION ADD_SECURITY_POLICY

Protected column name

VARCHAR(128)

If the alter action is ADD_COLUMN_PROTECTION or DROP_COLUMN_PROTECTION, this is the name of the affected column.

Column security label

VARCHAR(128)

The security label protecting the column specified in the field Column Name.

Security label column name VARCHAR(128)

Name of the column containing the security label protecting the row.

342

Table C.4

Appendix C


Audit Record Layout for SECMAINT Events

Name

Format

Description

Timestamp

CHAR(26)


Category

CHAR(8)

Shows that this is a SECMAINT event.

Audit event

VARCHAR(32)

Specific audit event. Possible values include GRANT, REVOKE, IMPLICIT_GRANT, IMPLICIT_REVOKE, SET_SESSION_USER, UPDATE_DBM_CFG, and TRANSFER_OWNERSHIP.

Event correlator

INTEGER


Event status

INTEGER


Database name

CHAR(8)

Name of the database for which the event was generated. Blank if this is an instance-level audit event.

User ID

VARCHAR(1024)


Authorization ID

VARCHAR(128)


Origin node number

SMALLINT


Coordinator node number SMALLINT


Application ID

VARCHAR (255)


Application name

VARCHAR (1024)

Application name in use at the time the audit event occurred.

Package schema

VARCHAR (128)


Package name

VARCHAR (128)



SMALLINT

Section number in package being used at the time the audit event occurred.

Appendix C


Table C.4

343

Audit Record Layout for SECMAINT Events (Continued)

Name

Format

Description

Object schema

VARCHAR (128)

Schema of the object for which the audit event was generated. If the object type field is ACCESS_RULE, this field contains the security policy name associated with the rule. The name of the rule is stored in the field Object Name. If the object type field is SECURITY_LABEL, this field contains the name of the security policy that the security label is part of. The name of the security label is stored in the field Object Name.

Object name

VARCHAR (128)

Name of object for which the audit event was generated. If the object type field is ACCESS_RULE, this field contains the name of the rule. The security policy name associated with the rule is stored in the field Object Schema. If the object type field is SECURITY_LABEL, this field contains the name of the security label. The name of the security policy that it is part of is stored in the field Object Schema.

Object type

VARCHAR (32)


Grantor

VARCHAR (128)

Grantor ID.

Grantee

VARCHAR (128)

Grantee ID for which a privilege or authority was granted or revoked.

Grantee type

VARCHAR (32)

Type of the grantee that was granted to or revoked from. Possible values include USER, GROUP, or BOTH.

Privilege or authority

CHAR(18)

Indicates the type of privilege or authority granted or revoked. (continues)

344

Table C.4

Appendix C


Audit Record Layout for SECMAINT Events (Continued)

Name

Format

Description

Package version

VARCHAR (64)


Access type

VARCHAR(32)

The access type for which a security label is granted. Possible values are as follows: READ WRITE ALL

Assumable AuthID

VARCHAR(128)

When the privilege granted is a SETSESSIONUSER privilege, this is the authorization ID that the grantee is allowed to set as the session user.

Appendix C


Table C.5

345

Audit Record Layout for SYSADMIN Events

Name

Format

Description

Timestamp

CHAR(26)


Category

CHAR(8)

Shows that this is a SYSADMIN event.

Audit event

VARCHAR(32)

Specific audit event. Possible values are numerous and include START_DB2, STOP_DB2, and UPDATE_DBM_CFG. A detailed list of SYSADMIN audit events is included in Appendix D (List of Possible SYSADMIN Audit Events).

Event correlator

INTEGER


Event status

INTEGER


Database name

CHAR(8)


User ID

VARCHAR(1024)


Authorization ID

VARCHAR(128)


Origin node number

SMALLINT



SMALLINT


Application ID

VARCHAR (255)


Application name

VARCHAR (1024)

Application name in use at the time the audit event occurred.

Package schema

VARCHAR (128)


Package name

VARCHAR (128)



SMALLINT


Package version

VARCHAR (64)


346

Table C.6

Appendix C


Audit Record Layout for VALIDATE Events

Name

Format

Description

Timestamp

CHAR(26)


Category

CHAR(8)

Shows that this is a VALIDATE event.

Audit event

VARCHAR(32)

Specific audit event. Possible values include GET_GROUPS, GET_USERID, AUTHENTICATE_PASSWORD, VALIDATE_USER, and GET_USERMAPPING_FROM_PLUGIN.

Event correlator

INTEGER


Event status

INTEGER


Database name

CHAR(8)


User ID

VARCHAR(1024)


Authorization ID

VARCHAR(128)


Execution ID

VARCHAR(1024)

Execution ID in use at the time of the audit event.

Origin node number

SMALLINT


Coordinator node number SMALLINT


Application ID

VARCHAR (255)


Application name


Authentication type

VARCHAR (32)

Authentication type at the time of the audit event.

Package schema

VARCHAR (128)


Package name

VARCHAR (128)

Name of package in use at the time the audit event occurred. (continues)

Appendix C

Table C.6


347

Audit Record Layout for VALIDATE Events (Continued)

Name

Format

Description


SMALLINT


Package version

VARCHAR (64)


Plug-in name

VARCHAR(32)

The name of the plug-in in use at the time the audit event occurred.

348

Table C.7

Appendix C


Audit Record Layout for CONTEXT Events

Name

Format

Description

Timestamp

CHAR(26)


Category

CHAR(8)

Category of audit event. Possible values are CONTEXT.

Audit event

VARCHAR(32)

Specific audit event. Possible values are numerous and include CONNECT, GET_DB_CFG, and ATTACH. A detailed list of CONTEXT audit events is included in Appendix D (List of Possible CONTEXT Audit Events).

Event correlator

INTEGER


Database name

CHAR(8)


User ID

VARCHAR(1024)


Authorization ID

VARCHAR(128)


Origin node number occurred.

SMALLINT

Node number at which the audit event.


SMALLINT


Application ID

VARCHAR (255)


Application name


Package schema

VARCHAR (128)


Package name

VARCHAR (128)



SMALLINT


Statement Text (statement)

CLOB (2M)

Text of the SQL or XQuery statement, if applicable. Null if no SQL or XQuery statement text is available.

Package version

VARCHAR (64)


APPENDIX

D

DB2 Audit – Additional Documentation

Table D.1

Audit Record Object Types Based on Audit Events

Object Type

CHECKING Events

OBJMAINT Events

SECMAINT Events

NONE

X

X

X

TABLE

X

X

X

VIEW

X

X

X

ALIAS

X

X

FUNCTION

X

X

X

INDEX

X

X

X

X

INDEX EXTENSION PACKAGE

X

PACKAGE CACHE

X

X

X

X

DATA_TYPE NODEGROUP

X

X

SCHEMA

X

X

X

STORED_PROCEDURE

X

X

X

METHOD_BODY

X

X

X

BUFFERPOOL

X

X

SEQUENCE

X

X

TABLESPACE

X

X

X (continues)

349

350

Table D.1

Appendix D


Audit Record Object Types Based on Audit Events (Continued)

Object Type

CHECKING Events

OBJMAINT Events

EVENT_MONITOR

X

X

SECMAINT Events

X

TRIGGER DATABASE

X

INSTANCE

X

X

FOREIGN_KEY

X

PRIMARY_KEY

X

UNIQUE_CONSTRAINT

X

CHECK_CONSTRAINT

X

WRAPPER

X

X

SERVER

X

X

X

NICKNAME

X

X

X

USER MAPPING

X

X

SERVER OPTION

X

X

TYPE&TRANSFORM

X

X

TYPE MAPPING

X

X

FUNCTION MAPPING

X

X

SUMMARY TABLES

X

X

X

X

JAR_FILE ALL

X

REOPT_VALUES

X

SECURITY_LABEL

X

X

SECURITY_POLICY

X

X

SECURITY_LABEL_COMPONENT

X X

ACCESS_RULE XSR object

X

X

X

Appendix D

Table D.2


351

List of Possible CONTEXT Audit Events

CONNECT

SET_APPL_PRIORITY

CONNECT_RESET

RESET_DB_CFG

ATTACH

GET_DB_CFG

DETACH

GET_DFLT_CFG

DARI_START

UPDATE_DBM_CFG

DARI_STOP

SET_MONITOR

BACKUP_DB

GET_SNAPSHOT

RESTORE_DB

ESTIMATE_SNAPSHOT_SIZE

ROLLFORWARD_DB

RESET_MONITOR

OPEN_TABLESPACE_QUERY

OPEN_HISTORY_FILE

FETCH_TABLESPACE

CLOSE_HISTORY_FILE

CLOSE_TABLESPACE_QUERY

FETCH_HISTORY_FILE

OPEN_CONTAINER_QUERY

SET_RUNTIME_DEGREE

CLOSE_CONTAINER_QUERY

UPDATE_AUDIT

FETCH_CONTAINER_QUERY

DBM_CFG_OPERATION

SET_TABLESPACE_CONTAINERS

DISCOVER

GET_TABLESPACE_STATISTIC

OPEN_CURSOR

READ_ASYNC_LOG_RECORD

CLOSE_CURSOR

QUIESCE_TABLESPACE

FETCH_CURSOR

LOAD_TABLE

EXECUTE

UNLOAD_TABLE

EXECUTE_IMMEDIATE

UPDATE_RECOVERY_HISTORY

PREPARE

PRUNE_RECOVERY_HISTORY

DESCRIBE

SINGLE_TABLESPACE_QUERY

BIND

LOAD_MSG_FILE

REBIND

UNQUIESCE_TABLESPACE

RUNSTATS

ENABLE_MULTIPAGE

REORG

DESCRIBE_DATABASE

REDISTRIBUTE

DROP_DATABASE

COMMIT

CREATE_DATABASE

ROLLBACK

ADD_NODE

REQUEST_ROLLBACK

FORCE_APPLICATION

IMPLICIT_REBIND

352

Table D.3

Appendix D


List of Possible SYSADMIN Audit Events

START_DB2

ROLLFORWARD_DB

STOP_DB2

SET_RUNTIME_DEGREE

CREATE_DATABASE

SET_TABLESPACE_CONTAINERS

ALTER_DATABASE

UNCATALOG_DB

DROP_DATABASE

UNCATALOG_DCS_DB

UPDATE_DBM_CFG

UNCATALOG_NODE

UPDATE_DB_CFG

UPDATE_ADMIN_CFG

CREATE_TABLESPACE

UPDATE_MON_SWITCHES

DROP_TABLESPACE

LOAD_TABLE

ALTER_TABLESPACE

DB2AUDIT

RENAME_TABLESPACE

SET_APPL_PRIORITY

CREATE_NODEGROUP

CREATE_DB_AT_NODE

DROP_NODEGROUP

KILLDBM

ALTER_NODEGROUP

MIGRATE_SYSTEM_DIRECTORY

CREATE_BUFFERPOOL

DB2REMOT

DROP_BUFFERPOOL

DB2AUD

ALTER_BUFFERPOOL

MERGE_DBM_CONFIG_FILE

CREATE_EVENT_MONITOR

UPDATE_CLI_CONFIGURATION

DROP_EVENT_MONITOR

OPEN_TABLESPACE_QUERY

ENABLE_MULTIPAGE

SINGLE_TABLESPACE_QUERY

MIGRATE_DB_DIR

CLOSE_TABLESPACE_QUERY

DB2TRC

FETCH_TABLESPACE

DB2SET

OPEN_CONTAINER_QUERY

ACTIVATE_DB

FETCH_CONTAINER_QUERY

ADD_NODE

CLOSE_CONTAINER_QUERY

BACKUP_DB

GET_TABLESPACE_STATISTICS

CATALOG_NODE

DESCRIBE_DATABASE

CATALOG_DB

ESTIMATE_SNAPSHOT_SIZE (continues)

Appendix D

Table D.3


353

List of Possible SYSADMIN Audit Events (Continued)

CATALOG_DCS_DB

READ_ASYNC_LOG_RECORD

CHANGE_DB_COMMENT

PRUNE_RECOVERY_HISTORY

DEACTIVATE_DB

UPDATE_RECOVERY_HISTORY

DROP_NODE_VERIFY

QUIESCE_TABLESPACE

FORCE_APPLICATION

UNLOAD_TABLE

GET_SNAPSHOT

UPDATE_DATABASE_VERSION

LIST_DRDA_INDOUBT_TRANSACTIONS

CREATE_INSTANCE

MIGRATE_DB

DELETE_INSTANCE

RESET_ADMIN_CFG

SET_EVENT_MONITOR

RESET_DB_CFG

GRANT_DBADM

RESET_DBM_CFG

REVOKE_DBADM

RESET_MONITOR

GRANT_DB_AUTHORITIES

RESTORE_DB

REVOKE_DB_AUTHORITIES REDIST_NODEGROUP

Table D.4

List of Possible CHECKING Access Approval Reasons

0x0000000000000001 ACCESS DENIED Access is not approved; rather, it was denied. 0x0000000000000002 SYSADM Access is approved; the application or user has SYSADM authority. 0x0000000000000004 SYSCTRL Access is approved; the application or user has SYSCTRL authority. 0x0000000000000008 SYSMAINT Access is approved; the application or user has SYSMAINT authority. 0x0000000000000010 DBADM Access is approved; the application or user has DBADM authority. (continues)

354

Table D.4

Appendix D


List of Possible CHECKING Access Approval Reasons (Continued)

0x0000000000000020 DATABASE PRIVILEGE Access is approved; the application or user has an explicit privilege on the database. 0x0000000000000040 OBJECT PRIVILEGE Access is approved; the application or user has an explicit privilege on the object or function. 0x0000000000000080 DEFINER Access is approved; the application or user is the definer of the object or function. 0x0000000000000100 OWNER Access is approved; the application or user is the owner of the object or function. 0x0000000000000200 CONTROL Access is approved; the application or user has CONTROL privilege on the object or function. 0x0000000000000400 BIND Access is approved; the application or user has BIND privilege on the package. 0x0000000000000800 SYSQUIESCE Access is approved; if the instance or database is in quiesce mode, the application or user may connect or attach. 0x0000000000001000 SYSMON Access is approved; the application or user has SYSMON authority. 0x0000000000002000 SECADM Access is approved; the application or user has SECADM authority. 0x0000000000004000 SETSESSIONUSER Access is approved; the application or user has SETSESSIONUSER authority.

Appendix D

Table D.5


355

List of Possible CHECKING Access Attempted Types

The following is the list of possible CHECKING access attempted types. If audit event is CHECKING_TRANSFER, the audit entry reflects that a privilege is held or not. 0x0000000000000001 CONTROL Attempt to verify if CONTROL privilege is held. 0x0000000000000002 ALTER Attempt to alter an object or to verify if ALTER privilege is held if audit event is CHECKING_TRANSFER. 0x0000000000000004 DELETE Attempt to delete an object or to verify if DELETE privilege is held if audit event is CHECKING_TRANSFER. 0x0000000000000008 INDEX Attempt to use an index or to verify if INDEX privilege is held if audit event is CHECKING_ TRANSFER. 0x0000000000000010 INSERT Attempt to insert into an object or to verify if INSERT privilege is held if audit event is CHECKING_TRANSFER. 0x0000000000000020 SELECT Attempt to query a table or view or to verify if SELECT privilege is held if audit event is CHECKING_TRANSFER. 0x0000000000000040 UPDATE Attempt to update data in an object or to verify if UPDATE privilege is held if audit event is CHECKING_TRANSFER. 0x0000000000000080 REFERENCE Attempt to establish referential constraints between objects or to verify if REFERENCE privilege is held if audit event is CHECKING_TRANSFER. 0x0000000000000100 CREATE Attempt to create an object. 0x0000000000000200 DROP Attempt to drop an object. (continues)

356

Table D.5

Appendix D


List of Possible CHECKING Access Attempted Types (Continued)

0x0000000000000400 CREATEIN Attempt to create an object within another schema. 0x0000000000000800 DROPIN Attempt to drop an object found within another schema. 0x0000000000001000 ALTERIN Attempt to alter or modify an object found within another schema. 0x0000000000002000 EXECUTE Attempt to execute or run an application or to invoke a routine, create a function sourced from the routine (applies to functions only), or reference a routine in any DDL statement or to verify if EXECUTE privilege is held if Audit Event is CHECKING_TRANSFER. 0x0000000000004000 BIND Attempt to bind or prepare an application. 0x0000000000008000 SET EVENT MONITOR Attempt to set event monitor switches. 0x0000000000010000 SET CONSTRAINTS Attempt to set constraints on an object. 0x0000000000020000 COMMENT ON Attempt to create comments on an object. 0x0000000000040000 GRANT Attempt to grant privileges on an object to another user ID. 0x0000000000080000 REVOKE Attempt to revoke privileges on an object from a user ID. 0x0000000000100000 LOCK Attempt to lock an object. 0x0000000000200000 RENAME Attempt to rename an object. 0x0000000000400000 CONNECT Attempt to connect to an object. (continues)

Appendix D

Table D.5


357


0x0000000000800000 Member of SYS Group Attempt to access or use a member of the SYS group. 0x0000000001000000 Access All Attempt to execute a statement with all required privileges on objects held (only used for DBADM/SYSADM). 0x0000000002000000 Drop All Attempt to drop multiple objects. 0x0000000004000000 LOAD Attempt to load a table in a tablespace. 0x0000000008000000 USE Attempt to create a table in a table space or to verify if USE privilege is held if audit event is CHECKING_TRANSFER. 0x0000000010000000 SET SESSION_USER Attempt to execute the SET SESSION_USER statement. 0x0000000020000000 FLUSH Attempt to execute the FLUSH statement. 0x0000000040000000 STORE Attempt to view the values of a reoptimized statement in the EXPLAIN_PREDICATE table. 0x0000000400000000 TRANSFER Attempt to transfer an object. 0x0000000800000000 ALTER_WITH_GRANT Attempt to verify if ALTER with GRANT privilege is held. 0x0000001000000000 DELETE_WITH_GRANT Attempt to verify if DELETE with GRANT privilege is held. 0x0000002000000000 INDEX_WITH_GRANT Attempt to verify if INDEX with GRANT privilege is held. 0x0000004000000000 INSERT_WITH_GRANT Attempt to verify if INSERT with GRANT privilege is held. (continues)

358

Table D.5

Appendix D



0x0000008000000000 SELECT_WITH_GRANT Attempt to verify if SELECT with GRANT privilege is held. 0x0000010000000000 UPDATE_WITH_GRANT Attempt to verify if UPDATE with GRANT privilege is held. 0x0000020000000000 REFERENCE_WITH_GRANT Attempt to verify if REFERENCE with GRANT privilege is held. 0x0000040000000000 USAGE Attempt to use a sequence or an XSR object or to verify if USAGE privilege is held if audit event is CHECKING_TRANSFER.

Table D.6

List of Possible SECMAINT Privileges or Authorities

0x0000000000000001 Control Table Control privilege granted or revoked on a table or view. 0x0000000000000002 ALTER TABLE Privilege granted or revoked to alter a table. 0x0000000000000004 ALTER TABLE with GRANT Privilege granted or revoked to alter a table with granting of privileges allowed. 0x0000000000000008 DELETE TABLE Privilege granted or revoked to drop a table or view. 0x0000000000000010 DELETE TABLE with GRANT Privilege granted or revoked to drop a table with granting of privileges allowed. 0x0000000000000020 Table Index Privilege granted or revoked on an index. 0x0000000000000040 Table Index with GRANT Privilege granted or revoked on an index with granting of privileges allowed. 0x0000000000000080 Table INSERT Privilege granted or revoked on an insert on a table or view. (continues)

Appendix D

Table D.6


359

List of Possible SECMAINT Privileges or Authorities (Continued)

0x0000000000000100 Table INSERT with GRANT Privilege granted or revoked on an insert on a table with granting of privileges allowed. 0x0000000000000200 Table SELECT Privilege granted or revoked on a select on a table. 0x0000000000000400 Table SELECT with GRANT Privilege granted or revoked on a select on a table with granting of privileges allowed. 0x0000000000000800 Table UPDATE Privilege granted or revoked on an update on a table or view. 0x0000000000001000 Table UPDATE with GRANT Privilege granted or revoked on an update on a table or view with granting of privileges allowed. 0x0000000000002000 Table REFERENCE Privilege granted or revoked on a reference on a table. 0x0000000000004000 Table REFERENCE with GRANT Privilege granted or revoked on a reference on a table with granting of privileges allowed. 0x0000000000020000 CREATEIN Schema CREATEIN privilege granted or revoked on a schema. 0x0000000000040000 CREATEIN Schema with GRANT CREATEIN privilege granted or revoked on a schema with granting of privileges allowed. 0x0000000000080000 DROPIN Schema DROPIN privilege granted or revoked on a schema. 0x0000000000100000 DROPIN Schema with GRANT DROPIN privilege granted or revoked on a schema with granting of privileges allowed. 0x0000000000200000 ALTERIN Schema ALTERIN privilege granted or revoked on a schema. 0x0000000000400000 ALTERIN Schema with GRANT ALTERIN privilege granted or revoked on a schema with granting of privileges allowed. (continues)

360

Table D.6

Appendix D



0x0000000000800000 DBADM Authority DBADM authority granted or revoked. 0x0000000001000000 CREATETAB Authority CREATETAB authority granted or revoked. 0x0000000002000000 BINDADD Authority BINADD authority granted or revoked. 0x0000000004000000 CONNECT Authority CONNECT authority granted or revoked. 0x0000000008000000 Create not fenced Authority Create not fenced authority granted or revoked. 0x0000000010000000 Implicit Schema Authority Implicit schema authority granted or revoked. 0x0000000020000000 Server PASSTHRU Privilege granted or revoked to use the pass-through facility with this server (federated database data source). 0x0000000100000000 Table Space USE Privilege granted or revoked to create a table in a tablespace. 0x0000000200000000 Table Space USE with GRANT Privilege granted or revoked to create a table in a tablespace with granting of privileges allowed. 0x0000000400000000 Column UPDATE Privilege granted or revoked on an update on one or more specific columns of a table. 0x0000000800000000 Column UPDATE with GRANT Privilege granted or revoked on an update on one or more specific columns of a table with granting of privileges allowed. 0x0000001000000000 Column REFERENCE Privilege granted or revoked on a reference on one or more specific columns of a table. (continues)

Appendix D

Table D.6


361


0x0000002000000000 Column REFERENCE with GRANT Privilege granted or revoked on a reference on one or more specific columns of a table with granting of privileges allowed. 0x0000004000000000 LOAD Authority LOAD authority granted or revoked. 0x0000008000000000 Package BIND BIND privilege granted or revoked on a package. 0x0000010000000000 Package BIND with GRANT BIND privilege granted or revoked on a package with granting of privileges allowed. 0x0000020000000000 EXECUTE EXECUTE privilege granted or revoked on a package or a routine. 0x0000040000000000 EXECUTE with GRANT EXECUTE privilege granted or revoked on a package or a routine with granting of privileges allowed. 0x0000080000000000 EXECUTE IN SCHEMA EXECUTE privilege granted or revoked for all routines in a schema. 0x0000100000000000 EXECUTE IN SCHEMA with GRANT EXECUTE privilege granted or revoked for all routines in a schema with granting of privileges allowed. 0x000020000000000 EXECUTE IN TYPE EXECUTE privilege granted or revoked for all routines in a type. 0x0000400000000000 EXECUTE IN TYPE with GRANT EXECUTE privilege granted or revoked for all routines in a type with granting of privileges allowed. 0x000080000000000 CREATE EXTERNAL ROUTINE CREATE EXTERNAL ROUTINE privilege granted or revoked. 0x0001000000000000 QUIESCE_CONNECT QUIESCE_CONNECT privilege granted or revoked. (continues)

362

Table D.6

Appendix D



0x0004000000000000 SECADM Authority SECADM authority granted or revoked. 0x0040000000000000 SETSESSIONUSER Privilege SETSESSIONUSER granted or revoked. 0x0080000000000000 Exemption Exemption granted or revoked. 0x0100000000000000 Security label Security label granted or revoked.

APPENDIX

E


he National Institute of Standards and Technology (NIST) published a series of securityreadiness review checklists for major database vendors such as IBM DB2. The DB2 Database Security Readiness Review Checklist is located at http://checklists.nist.gov/repository/ category.html.

T

From time to time, DB2 will also publish an advisory security-readiness checklist at the IBM developerWorks website: www-128.ibm.com/developerworks/db2/zones/db2udb/. In addition, there are many security consideration sections in the DB2 documentation that are centralized here for easier access.

SECURITY CONSIDERATIONS (SOURCED FROM ADMINISTRATION GUIDE: IMPLEMENTATION) Gaining Access to Data Through Indirect Means The following are indirect means through which users can gain access to data they may not be authorized for: • Catalog views. The DB2 catalog views store metadata and statistics about database objects. Users with SELECT access to the catalog views can gain some knowledge about data that they may not be qualified for otherwise. For example, some of the table statistics stored in the catalog views such as HIGH2KEY, LOW2KEY, and the column distribution statistics can reveal information about table data. For better security, users should

363

364

Appendix E


make sure that only qualified users have access to the catalog views. In earlier versions of DB2 UDB, SELECT access on the catalog views is granted to PUBLIC by default. In v9.1, users can choose whether SELECT access to the catalog views is granted to PUBLIC or not via the new RESTRICT_ACCESS option on the CREATE DATABASE command. • Visual explain. Visual explain shows the access plan chosen by the query optimizer for a particular query. The visual explain information also includes statistics about columns referenced in the query. As with the catalog views, statistics can reveal information about tables’ content. • Explain snapshot. The explain snapshot is compressed information that is collected when a SQL statement is explained. It is stored as a binary large object (BLOB) in the EXPLAIN_STATEMENT table, and contains, among other things, column statistics. As mentioned earlier, column statistics can reveal information about table data. For better security, access to the explain tables should be granted to qualified users only. • Log reader APIs. A user authorized to run an API that understands the format of a log record can gain access to data in such logs. For example, a user with DBADM authority can execute the DB2READLOG API to gain access to data in the log files. Replication. The replication “Capture” program is an example user of the DB2READLOG API above. Users should be aware that replication moves data from a source location to a target location. For better security, users must ensure that the target location is at least as secure as the source location. • Exception tables. When loading data into a table and an exception table has been specified for storing data rows in error (for example, rows with an invalid security label), users with access to such exception table can gain knowledge about information that otherwise may not be authorized for. For better security, the exception table should be dropped when the data rows in error are fixed and copied back to the table being loaded. Alternatively, access to the exception table should be granted only to authorized users. • Backup tablespace/database. Users with the authority to run the backup command can run such command to take a backup of a database or a tablespace and restore such data somewhere else. Like with replication, this is the general problem of compromising data security by allowing data to be moved from one location to another. • Set session authorization. In earlier versions of DB2 UDB, a user with DBADM authority can set the session authorization to any database user using the SET SESSION AUTHORIZATION SQL statement. In DB2 v9.1, this is no longer possible. A user must be explicitly authorized by the security administrator (SECADM) to set the session authorization to another database user. However, when migrating an existing database to DB2 UDB v9.1, a user with existing explicit DBADM authority (that is, granted in SYSCAT.DBAUTH) will be assigned the ability to set the session authorization to any

Security Considerations (Sourced from Administration Guide: Implementation)

365

database user (in order not to break any existing application). Thus, a DBADM, who is not qualified to access labeled data, could gain access to such data by setting the session authorization to a qualified user. For more-restrictive security, the security administrator can override this setting using the REVOKE SETSESSIONUSER SQL statement. Refer to the SQL Reference changes for more information on granting and revoking set session privileges. • High Performance Unload (HPU). HPU is a utility that does not ship with DB2 but can be purchased separately. It is a utility that enables you to unload data from a table. DB2 does not enforce access control when HPU is used to unload a table. • Statement and deadlock monitoring. As part of the DB2 deadlock monitoring activity, values associated with parameter markers are written to the monitoring output when the WITH VALUES clause is specified. Thus, a user with access to the monitoring output may gain access to information for which he or she might not be authorized. • Traces. A trace can contain table data. Thus, a user with access to such trace may gain access to information that he or she might not be authorized for. • Dump files. To help in debugging certain problems, DB2 may generate some dump files in the SQLLIB\DB2DUMP directory. These dump files may or may not contain table data. If they do, users with access to such dump files may gain access to information that they may not be authorized for. • db2dart. The db2dart tool examines a database for architectural correctness and reports any encountered errors. The tool can access table data, and DB2 does not enforce access control for such access (other than the authority to run the db2dart tool). Thus, users with access to the db2dart output may gain access to information that they may not be authorized for. • REOPT BIND option. When the REOPT BIND option is specified, an explain snapshot information for each reoptimizable incremental bind SQL statement is placed in the explain tables at runtime. The explain will also show input data values. • db2cat. The db2cat tool is used to dump a table’s packed descriptor. The table’s packed descriptor contains, among other things, statistics about the table and its columns. Statistics can reveal information about a table’s content. Thus, users who run the db2cat tool may gain access to information that they may not be authorized for.

Default Privileges Granted upon Creating a Database The following are the default privileges granted when a database is created: 1. SYSIBM.SYSDBAUTH The database creator is granted the following privileges: DBADM

366

Appendix E


CREATETAB CREATEROLE BINDADD CONNECT NOFENCE IMPLSCHEMA LOAD EXTERNALROUTINE QUIESCECONNECT

The special group PUBLIC is granted the following privileges: CREATETAB BINDADD CONNECT IMPLSCHEMA

2. SYSIBM.SYSTABAUTH The special group PUBLIC is granted the following privileges: SELECT on all SYSCAT, SYSIBM, and SYSCATV82 tables SELECT and UPDATE on all SYSSTAT tables 3. SYSIBM.SYSROUTINEAUTH The special group PUBLIC is granted the following privileges: EXECUTE with GRANT on all procedures in schema SQLJ EXECUTE with GRANT on all functions and procedures in schema SYSFUN EXECUTE with GRANT on all functions and procedures in schema SYSPROC EXECUTE on all table functions in schema SYSIBM EXECUTE on all other procedures in schema SYSIBM 4. SYSIBM.SYSPACKAGEAUTH The database creator is granted the following privileges: CONTROL on all packages created in the NULLID schema BIND with GRANT on all packages created in the NULLID schema EXECUTE with GRANT on all packages created in the NULLID schema The special group PUBLIC is granted the following privileges: BIND on all packages created in the NULLID schema EXECUTE on all packages created in the NULLID schema 5. SYSIBM.SCHEMAAUTH The special group PUBLIC is granted the following privileges: CREATEIN on schema SQLJ CREATE IN on schema NULLID

Windows Platform Security Considerations for Users (Sourced from Administration Guide: Implementation)

367

6. SYSIBM.TBSPACEAUTH The special group PUBLIC is granted the following privileges: USE on tablespace USERSPACE1

UNIX PLATFORM SECURITY CONSIDERATIONS FOR USERS (SOURCED FROM ADMINISTRATION GUIDE: IMPLEMENTATION) The DB2 database does not support root acting directly as a database administrator. You should use su - as the database administrator. For security reasons, we recommend you do not use the instance name as the Fenced ID. However, if you are not planning to use fenced UDFs or stored procedures, you can set the Fenced ID to the instance name instead of creating another user ID. The recommendation is to create a user ID that will be recognized as being associated with this group. The user for fenced UDFs and stored procedures is specified as a parameter of the instance creation script (db2icrt ... -u ). This is not required if you install the DB2 Clients or the DB2 Software Developer’s Kit.

WINDOWS PLATFORM SECURITY CONSIDERATIONS FOR USERS (SOURCED FROM ADMINISTRATION GUIDE: IMPLEMENTATION) System administration (SYSADM) authority is granted to any valid DB2 database user account that belongs to the local Administrators group on the machine where the account is defined. By default in a Windows domain environment, only domain users who belong to the Administrators group at the domain controller have SYSADM authority on an instance. Because DB2 always performs authorization at the machine where the account is defined, adding a domain user to the local Administrators group on the server does not grant the domain user SYSADM authority to the group.

NOTE: In a domain environment such as is found in Windows, DB2 only authenticates the first 64 groups that meet the requirements and restrictions, and to which a user ID belongs.You may have more than 64 groups. To avoid adding a domain user to the Administrators group at the PDC, you should create a global group and add the users (both domain and local) that you want to grant SYSADM authority.To do this, enter the following commands: DB2STOP DB2 UPDATE DBM CFG USING SYSADM_GROUP global_group DB2START

368

Appendix E


SECURITY CONSIDERATIONS IN AN LDAP ENVIRONMENT (SOURCED FROM ADMINISTRATION GUIDE: IMPLEMENTATION) Before accessing information in the LDAP directory, an application or user is authenticated by the LDAP server. The authentication process is called binding to the LDAP server. It is important to apply access control on the information stored in the LDAP directory to prevent anonymous users from adding, deleting, or modifying the information. Access control is inherited by default and can be applied at the container level. When a new object is created, it inherits the same security attribute as the parent object. An administration tool available for the LDAP server can be used to define access control for the container object. By default, access control is defined as follows: • For database and node entries in LDAP, everyone (or any anonymous user) has read access. Only the directory administrator and the owner or creator of the object has read/write access. • For user profiles, the profile owner and the directory administrator have read/write access. One user cannot access the profile of another user if that user does not have directory administrator authority.

NOTE: The authorization check is always performed by the LDAP server and not by DB2. The LDAP authorization check is not related to DB2 authorization. An account or auth ID that has SYSADM authority may not have access to the LDAP directory. When running the LDAP commands or APIs, if the bind distinguished name (bindDN) and password are not specified, DB2 binds to the LDAP server using the default credentials, which may not have sufficient authority to perform the requested commands, and an error will be returned. You can explicitly specify the user’s bindDN and password using the USER and PASSWORD clauses for the DB2 commands or APIs.

SECURITY CONSIDERATIONS FOR ACTIVE DIRECTORY (SOURCED FROM ADMINISTRATION GUIDE: IMPLEMENTATION) The DB2 database and node objects are created under the computer object of the machine where the DB2 server is installed in the Active Directory. To register a database server or catalog a data-

Security Considerations for Routines (Sourced from SQL Guide)

369

base in the Active Directory, you need to have sufficient access to create or update the objects under the computer object. By default, objects under the computer object are readable by any authenticated users and updatable by administrators (users who belong to the Administrators, Domain Administrators, and Enterprise Administrators groups). To grant access for a specific user or a group, use the Active Directory Users and Computer Management Console (MMC) as follows: 1. Start the Active Directory Users and Computer administration tool (Start > Program > Administration Tools > Active Directory Users and Computer). 2. Under View, select Advanced Features. 3. Select the Computers container. 4. Right-click the computer object that represents the server machine where DB2 is installed and select Properties. 5. Select the Security tab, and then add the required access to the specified user or group. The DB2 registry variables and CLI settings at the user level are maintained in the DB2 property object under the User object. To set the DB2 registry variables or CLI settings at the user level, a user needs to have sufficient access to create objects under the User object. By default, only administrators have access to create objects under the User object. To grant access to a user to set the DB2 registry variables or CLI settings at the user level, use the Active Directory Users and Computer MMC as follows: 1. Start the Active Directory Users and Computer administration tool (Start > Program > Administration Tools > Active Directory Users and Computer). 2. Select the User object under the Users container. 3. Right-click the User object and select Properties. 4. Select the Security tab. 5. Add the username to the list by using the Add button. 6. Grant Write access and Create All Child Objects access. 7. Using the Advanced setting, set permissions to apply to This Object and All Child Objects. 8. Select the Allow Inheritable Permissions from Parent to Propagate to This Object check box.

SECURITY CONSIDERATIONS FOR ROUTINES (SOURCED FROM SQL GUIDE) Developing and deploying routines provides you with an opportunity to greatly improve the performance and effectiveness of your database applications. There can, however, be security risks if

370

Appendix E


the deployment of routines is not managed correctly by the database administrator. The following sections describe security risks and means by which you can mitigate these risks. The security risks are followed by a section on how to safely deploy routines whose security is unknown.

Security Risks • NOT FENCED routines can access database manager resources. NOT FENCED routines run in the same process as the database manager. Because of their close proximity to the database engine, NOT FENCED routines can accidentally or maliciously corrupt the database manager’s shared memory, or damage the database control structures. Either form of damage will cause the database manager to fail. NOT FENCED routines can also corrupt databases and their tables.

To ensure the integrity of the database manager and its databases, you must thoroughly screen routines you intend to register as NOT FENCED. These routines must be fully tested, debugged, and exhibit no unexpected side effects. In the examination of the routine, pay close attention to memory management and the use of static variables. The greatest potential for corruption arises when code does not properly manage memory or incorrectly uses static variables. These problems are prevalent in languages other than Java and .NET programming languages. To register a NOT FENCED routine, the CREATE_NOT_FENCED_ROUTINE authority is required. When granting the CREATE_NOT_FENCED_ROUTINE authority, be aware that the recipient can potentially gain unrestricted access to the database manager and all its resources. NOTE: NOT FENCED routines are not supported in Common Criteria– compliant configurations. • FENCED THREADSAFE routines can access memory in other FENCED THREADSAFE routines. FENCED THREADSAFE routines run as threads inside a shared process. Each of these

routines is able to read the memory used by other routine threads in the same process. Therefore, it is possible for one threaded routine to collect sensitive data from other routines in the threaded process. Another risk inherent in the sharing of a single process is that one routine thread with flawed memory management can corrupt other routine threads, or cause the entire threaded process to crash. To ensure the integrity of other FENCED THREADSAFE routines, you must thoroughly screen routines you intend to register as FENCED THREADSAFE. These routines must be fully tested, debugged, and exhibit no unexpected side effects. In the examination of the

Security Considerations for Routines (Sourced from SQL Guide)

371

routine, pay close attention to memory management and the use of static variables. This is where the greatest potential for corruption lies, particularly in languages other than Java. To register a FENCED THREADSAFE routine, the CREATE_EXTERNAL_ROUTINE authority is required. When granting the CREATE_EXTERNAL_ROUTINE authority, be aware that the recipient can potentially monitor or corrupt the memory of other FENCED THREADSAFE routines. • Write access to the database server by the owner of fenced processes can result in database manager corruption. The user ID under which fenced processes run is defined by the db2icrt (create instance) or db2iupdt (update instance) system commands. This user ID must not have write access to the directory where routine libraries and classes are stored (in UNIX environments, sqllib/function; in Windows environments, sqllib\function). This user ID must also not have read or write access to any database, operating system, or otherwise critical files and directories on the database server. If the owner of fenced processes does have write access to various critical resources on the database server, the potential for system corruption exists. For example, a database administrator registers a routine received from an unknown source as FENCED NOT THREADSAFE, thinking that any potential harm can be averted by isolating the routine in its own process. However, the user ID that owns fenced processes has write access to the sqllib/function directory. Users invoke this routine, and unbeknownst to them, it overwrites a library in sqllib/function with an alternative version of a routine body that is registered as NOT FENCED. This second routine has unrestricted access to the entire database manager, and can thereby distribute sensitive information from database tables, corrupt the databases, collect authentication information, or crash the database manager. Ensure the user ID that owns fenced processes does not have write access to critical files or directories on the database server (especially sqllib/function and the database data directories). • Vulnerability of routine libraries and classes. If access to the directory where routine libraries and classes are stored is not controlled, routine libraries and classes can be deleted or overwritten. As discussed in the preceding bulleted item, the replacement of a NOT FENCED routine body with a malicious (or poorly coded) routine can severely compromise the stability, integrity, and privacy of the database server and its resources. To protect the integrity of routines, you must manage access to the directory containing the routine libraries and classes. Ensure that the fewest possible number of users can access this directory and its files. When assigning write access to this directory, be aware

372

Appendix E


that this privilege can provide the owner of the user ID unrestricted access to the database manager and all its resources. • Deploying potentially insecure routines. If you happen to acquire a routine from an unknown source, be sure you know exactly what it does before you build, register, and invoke it. It is recommend that you register it as FENCED and NOT THREADSAFE unless you have tested it thoroughly and it exhibits no unexpected side effects. If you need to deploy a routine that does not meet the criteria for secure routines, register the routine as FENCED and NOT THREADSAFE. To ensure that database integrity is maintained, FENCED and NOT THREADSAFE routines: • Run in a separate DB2 process, shared with no other routines. If they abnormally terminate, the database manager will be unaffected. • Use memory that is distinct from memory used by the database. An inadvertent mistake in a value assignment will not affect the database manager. • Security of external routine library or class files. External routine libraries are stored in the file system on the database server and are not backed up or protected in any way by the DB2 database manager. For routines to continue to successfully be invoked, it is imperative that the library associated with the routine continues to exist in the location specified in the EXTERNAL clause of the CREATE statement used to create the routine. Do not move or delete routine libraries after creating routines; doing so will cause routine invocations to fail. To prevent routine libraries from being accidentally or intentionally deleted or replaced, you must restrict access to the directories on the database server that contain routine libraries and restrict access to the routine library files. You can do this by using operating system commands to set directory and file permissions.

SECURITY CONSIDERATIONS FOR DB2 ADMINISTRATION SERVER (DAS) ON WINDOWS (SOURCED FROM ADMINISTRATION GUIDE: IMPLEMENTATION) You might need to change the user ID under which the DAS service runs on Windows. After creating the DAS, you can set or change the logon account using the db2admin command as follows: db2admin setid <username> <password>

where <username> and <password> are the username and password of an account that has local Administrator authority. Before running this command, you must log on to a computer using an account or user ID that has local Administrator authority.

Security Considerations for User Mapping Plug-In for a Federated Environment

373

NOTE: Recall that passwords are case-sensitive. A mixture of upperand lowercase is allowed, which means that the case of the password becomes very important. On Windows, you should not use the Services utility in the Control Panel to change the logon account for the DAS, because some of the required access rights will not be set for the logon account. Always use the db2admin command to set or change the logon account for the DAS.

SECURITY CONSIDERATIONS FOR USER MAPPING PLUG-IN FOR A FEDERATED ENVIRONMENT (SOURCED FROM WEBSPHERE INFORMATION INTEGRATION DOCUMENTATION) When developing and using your plug-in, you are sending sensitive user IDs and passwords between multiple sources. You can protect your information by restricting access to code, auditing plug-in usage, and encrypting communication. You must develop your plug-in to use security settings that match the security settings that are used by your external repository. You should choose an external repository that allows you to encrypt sensitive information that is stored. The user mapping cryptography class must contain the encryption schema and secret key that allows for decrypting and decoding the passwords. You should restrict access to the source code of the plug-in so that this information stays secure. If auditing is turned on, any attempt to access a user mapping through plug-in by the federated server has a VALIDATE audit record. You can configure the db2audit tool to capture VALIDATE records: db2audit configure scope VALIDATE. You can also protect the communication between the federated server and the external repository by using a Secure Sockets Layer (SSL). When you create your configuration file for the user mapping plug-in, you can specify that the plug-in uses SSL to protect communications.


APPENDIX

F


(Contributed by DB2 security guru Paul Bird) authorization ID A term used to refer to a DB2-compatible ID (that is, an ID that follows the guidelines for DB2 authorization IDs) used for authorization purposes. Typically, it refers to both the primary and secondary authorization IDs when referring to privilege checking and only the primary authorization ID when referring to object ownership. primary authorization ID This term refers to the main authorization ID to be considered for authorization purposes and is the ID used for any catalog entries for object owner/definer and for any audit records generated. It usually represents a user’s authorization ID. secondary authorization ID This term refers to the collection of IDs associated with the primary authorization ID that can be used to supplement the primary authorization ID’s privileges where allowed by DB2. (Secondary authorization IDs are not always considered such as in the case of static SQL.) These IDs represent groups. The secondary authorization IDs are associated to the primary authorization ID through external associations (that is, unknown to DB2) where they represent external groups. The number of secondary authorization IDs is variable (and can be zero). Any group authorization IDs are requested by DB2 as required and remain associated with the primary authorization ID for the life of the communication with DB2. (That is, they are cached.) DB2 does not reflect any changes to the external associations subsequent to the commencement of that communication. (That is, changes to groups do not get reflected inside DB2 while the communication to DB2 is active.) For a connection, group information is requested immediately after the authentication stage of CONNECT processing.

375

376

Appendix F:


system authorization ID As part of the authentication process, an authorization ID compatible with DB2’s naming requirements is produced to represent the external user ID within DB2. This ID is referred to as the system authorization ID and is used to do any initial authorization checking such as checking for CONNECT privilege during CONNECT processing. This ID represents the user who created the connection in DB2-compatible terms. The SYSTEM_USER special register can be used to see the current value of this ID. The system authorization ID cannot be changed at this time. session authorization ID This is the authorization ID used for any session authorization checking subsequent to the initial checks performed during CONNECT processing. After a connection has been established, the session authorization ID represents the current user of the connection in DB2-compatible terms. The default value of the session authorization ID is the value of the system authorization ID. The SESSION_USER special register can be used to see the current value of this ID. The old USER special register is a synonym for SESSION_USER. The session authorization ID can be changed through use of the SET SESSION AUTHORIZATION statement. (Routine) invoker authorization ID This is the authorization ID that was the statement authorization ID for the statement that invoked a SQL routine. (Routine) definer authorization ID This is the authorization ID that is listed in the system catalogs as the definer of the SQL routine that has been invoked. package authorization ID This is the authorization ID that was used to bind a package to the database. This ID is obtained from the value of the OWNER bind option. This ID is sometimes referred to as the package binder or package owner. statement authorization ID This is the authorization ID associated with a specific SQL statement that is to be used for any authorization requirements and for determining object ownership (where appropriate). It takes its value from the appropriate source authorization ID depending on the type of SQL statement, as follows: Static SQL

The relevant package authorization ID is used.

Dynamic SQL (from nonroutine context)

If the value for the DYNAMICRULES option for the issuing package is RUN, the relevant session authorization ID is used. If the value for the DYNAMICRULES option for the issuing package is BIND, the relevant package authorization ID is used.

Appendix F:


377

If the value for the DYNAMICRULES option for the issuing package is DEFINERUN or INVOKERUN, the relevant session authorization ID is used. If the value for the DYNAMICRULES option for the issuing package is DEFINEBIND or INVOKEBIND, the relevant package authorization ID is used. Dynamic SQL (from routine context)

If the value for the DYNAMICRULES option for the issuing package is DEFINERUN or DEFINEBIND, the relevant definer authorization ID is used. If the value for the DYNAMICRULES option for the issuing package is INVOKERUN or INVOKEBIND, the relevant invoker authorization ID is used.

The CURRENT_USER special register can be used to see the current value of this ID. The statement authorization ID cannot be changed directly by the end user; it is changed automatically by DB2 to reflect the nature of each SQL statement.


APPENDIX

G

LBAC-Related SYSCAT Views

Table G.1

Definition of SYSCAT.SECURITYLABELACCESS Catalog View

Column Name

Type Schema

Type Name

Length

Scale

Nulls

GRANTOR

SYSIBM

VARCHAR

128

0

No

GRANTEE

SYSIBM

VARCHAR

128

0

No

GRANTEETYPE

SYSIBM

CHARACTER

1

0

No

SECLABELID

SYSIBM

INTEGER

4

0

No

SECPOLICYID

SYSIBM

INTEGER

4

0

No

ACCESSTYPE

SYSIBM

CHARACTER

1

0

No

GRANT_TIME

SYSIBM

TIMESTAMP

10

0

No

Table G.2

Definition of SYSCAT.SECURITYLABELS Catalog View

Column Name

Type Schema

Type Name

Length

Scale

Nulls

SECLABELNAME

SYSIBM

VARCHAR

128

0

No

SECLABELID

SYSIBM

INTEGER

4

0

No

SECPOLICYID

SYSIBM

INTEGER

4

0

No

SECLABEL

SYSPROC

DB2SECURITYLABEL

0

0

No

CREATE_TIME

SYSIBM

TIMESTAMP

10

0

No

REMARKS

SYSIBM

VARCHAR

254

0

Yes

379

380

Table G.3

Appendix G


Definition of SYSCAT.SECURITYPOLICIES Catalog View

Column Name

Type Schema

Type Name

Length

Scale

Nulls

SECPOLICYNAME

SYSIBM

VARCHAR

128

0

No

SECPOLICYID

SYSIBM

INTEGER

40

No

NUMSECLABELCOMP

SYSIBM

INTEGER

4

0

No

RWSECLABELREL

SYSIBM

CHARACTER

1

0

No

NOTAUTHWRITE SECLABEL

SYSIBM

CHARACTER

1

0

No

CREATE_TIME

SYSIBM

TIMESTAMP

10

0

No

REMARKS

SYSIBM

VARCHAR

254

0

Yes

Table G.4

Definition of SYSCAT.SECURITYLABELCOMPONENTS Catalog View

Column Name

Type Schema

Type Name

Length

Scale

Nulls

COMPNAME

SYSIBM

INTEGER

128

0

No

COMPID

SYSIBM

INTEGER

4

0

No

COMPTYPE

SYSIBM

CHARACTER

1

0

No

NUMELEMENTS

SYSIBM

INTEGER

4

0

No

CREATE TIME

SYSIBM

TIMESTAMP

10

0

No

REMARKS

SYSIBM

VARCHAR

256

0

Yes

Table G.5

Definition of SYSCAT.SECURITYLABELCOMPONENTELEMENTS Catalog View

Column Name

Type Schema

Type Name

Length

Scale

Nulls

COMPID

SYSIBM

INTEGER

4

0

No

ELEMENTVALUE

SYSIBM

VARCHAR

32

0

No

ELEMENTVALUEENCODING

SYSIBM

VARCHAR

32

0

No

ELEMENTVALUEENCODING

SYSIBM

CHARACTER

8

0

No

PARENTELEMENTVALUE

SYSIBM

VARCHAR

32

0

Yes


Table G.6

381

Definition of SYSCAT.SECURITYPOLICYCOMPONENTRULES Catalog View

Column Name

Type Schema

Type Name

Length

Scale

Nulls

SECPOLICYID

SYSIBM

INTEGER

4

0

No

COMPID

SYSIBM

INTEGER

4

0

No

ORDINAL

SYSIBM

INTEGER

4

0

No

READACCESSRULENAME

SYSIBM

VARCHAR

128

0

No

READACCESSRULETEXT

SYSIBM

VARCHAR

512

0

No

WRITEACCESSRULENAME

SYSIBM

VARCHAR

128

0

No

WRITEACCESSRULETEXT

SYSIBM

VARCHAR

512

0

No

Table G.7

Definition of SYSCAT.SECURITYPOLICYEXEMPTIONS Catalog View

Column Name

Type Schema

Type Name

Length

Scale

Nulls

GRANTOR

SYSIBM

VARCHAR

128

0

No

GRANTEE

SYSIBM

VARCHAR

128

0

No

GRANTEETYPE

SYSIBM

CHARACTER

1

0

No

SECPOLICYID

SYSIBM

INTEGER

4

0

No

ACCESSRULENAME

SYSIBM

VARCHAR

128

0

No

ACCESSTYPE

SYSIBM

CHARACTER

1

0

No

ORDINAL

SYSIBM

INTEGER

4

0

No

ACTIONALLOWDED

SYSIBM

CHARACTER

1

0

No

GRANT_TIME

SYSIBM

TIMESTAMP

10

0

No


APPENDIX


383

H

APIs That Can Return

0

DB2SEC_PLUGIN_OKAY

The plug-in executed successfully.

All APIs

-1

DB2SEC_PLUGIN_UNKNOWNERROR

The plug-in encountered an unexpected error.

All APIs

-2

DB2SEC_PLUGIN_BADUSER

The ID passed in as input is not defined to the external world.

db2secGenerateInitialCred, db2secValidatePassword, db2secRemapUserid, db2secGetGroupsForUser

-3

DB2SEC_PLUGIN_INVALIDUSERORGROUP

No such user or group. This is db2secDoesAuthIDExist, not treated as an error by DB2; db2secDoesGroupExist it is used on a grant statement to figure out whether an authorization ID is a user authorization ID or a group authorization ID.

-4

DB2SEC_PLUGIN_USERSTATUSNOTKNOWN

Unknown user status. This is db2secDoesAuthIDExist not treated as an error by DB2; it is used on a grant statement to figure out whether an authorization ID is a user ID or group ID.

-5

DB2SEC_PLUGIN_GROUPSTATUSNOTKNOWN

Unknown group status. db2secDoesGroupExist This is not treated as an error by DB2; it is used on a grant statement to figure out whether an authorization ID is a user ID or group ID.


Meaning

Appendix H

Define Value the Return Code

384

Return Code


-6

DB2SEC_PLUGIN_UID_EXPIRED

User ID expired.

db2secValidatePassword, db2GetGroupsForUser, db2secGenerateInitialCred

-7

DB2SEC_PLUGIN_PWD_EXPIRED

Password expired.

db2secValidatePassword , db2GetGroupsForUser, db2secGenerateInitialCred

-8

DB2SEC_PLUGIN_USER_REVOKED

User revoked.

db2secValidatePassword, db2GetGroupsForUser

-9

DB2SEC_PLUGIN_USER_SUSPENDED

User suspended.

db2secValidatePassword, db2GetGroupsForUser

-10

DB2SEC_PLUGIN_BADPWD

Bad password.

db2secValidatePassword, db2secRemapUserid, db2secGenerateInitialCred

-11

DB2SEC_PLUGIN_BAD_NEWPASSWORD

Bad new password.

db2secValidatePassword, db2secRemapUserid

-12

DB2SEC_PLUGIN_CHANGEPASSWORD_ NOTSUPPORTED

Change password not supported.

db2secValidatePassword, db2secRemapUserid, db2secGenerateInitialCred

-13

DB2SEC_PLUGIN_NOMEM

Plug-in attempted to allocate memory, but no more memory is left.

All APIs

-14

DB2SEC_PLUGIN_DISKERROR

Plug-in encountered a disk error.

All APIs

-15

DB2SEC_PLUGIN_NOPERM

Plug-in attempt to access a file failed because of the wrong permission on the file.

All APIs 385

Meaning



Appendix H

Return Code


Meaning


-16

DB2SEC_PLUGIN_NETWORKERROR

Plug-in encountered a net work error.

All APIs

-17

DB2SEC_PLUGIN_CANTLOADLIBRARY

Plug-in is unable to load a required library

db2secGroupPluginInit, db2secClientAuthPluginInit, db2secServerAuthPluginInit

-18

DB2SEC_PLUGIN_CANT_OPEN_FILE

Plug-in is unable to open and read a file for a reason other than a file missing or file permission.

All APIs

-19

DB2SEC_PLUGIN_FILENOTFOUND

Plug-in is unable to open and read a file because the file is missing from the file system.

All APIs

-20

DB2SEC_PLUGIN_CONNECTION_DISALLOWED The plug-in is refusing the connection because of the restriction on which the database is allowed to connect or which the TCP/IP address can connect to a specific database.

-21

DB2SEC_PLUGIN_NO_CRED

(GSS API plug-in only) Initial client credential is missing.

db2secGetDefaultLoginCon text, db2secServerAuthPluginInit

-22

DB2SEC_PLUGIN_CRED_EXPIRED

(GSS API plug-in only) Client credential has expired.

db2secGetDefaultLoginCon text, db2secServerAuthPluginInit

-23

DB2SEC_PLUGIN_BAD_PRINCIPAL_NAME

(GSS API plug-in only) The principal name is invalid.

db2secProcessServerPrincipalName

386

Return Code

All server-side plug-in APIs

Appendix H Security Plug-In Return Codes

Meaning


-24

DB2SEC_PLUGIN_NO_CON_DETAILS

This return code is returned by the db2secGetConDetails callback (that is, from DB2 to the plug-in) to indicate DB2 is unable to determine the client’s TCP/IP address.

db2secGetConDetails

-25

DB2SEC_PLUGIN_BAD_INPUT_PARAMETERS

Some parameters are not valid or missing when the plug-in API is called.

All APIs

-26

DB2SEC_PLUGIN_INCOMPATIBLE_VER

The version of the APIs reported by the security plug-in is not compatible with DB2.

db2secGroupPluginInit, db2secClientAuthPluginInit, db2secServerAuthPluginInit

-27

DB2SEC_PLUGIN_PROCESS_LIMIT

The plug-in runs out of resources when attempting to create a new process.

All APIs

-28

DB2SEC_PLUGIN_NO_LICENSES

The plug-in encountered a user license problem. Possible that the underlying mechanism license has reached the limit.

All APIs



Appendix H

Return Code

387


APPENDIX

I


GROUP PLUG-IN To implement a group plug-in, application programming interfaces (APIs) are required. Note that when DB2 called the Init function, it passed a callback function db2secLogMessage where the plug-in code can log debugging or diagnostic information to db2diag.log.

db2secGroupPluginInit 1. Assign all the function addresses to the function pointers. 2. Set plugintype = DB2SEC_PLUGIN_TYPE_GROUP. 3. Set the version based on the version of the security plug-in API you are using. It is suggested that you use the latest version number (that is, the define DB2SEC_API_ VERSION from the header file db2secPlugin.h).

389

390

Appendix I

Listing I.1


A Sample Listing for the db2secGroupPluginInit API

#ifdef __cplusplus extern “C” #endif SQL_API_RC SQL_API_FN db2secGroupPluginInit( db2int32 void* db2secLogMessage* char** db2int32*

version, group_fns, logMessage_fn, errormsg, errormsglen)

{ db2secGroupFunction_1* fns = (db2secGroupFunction_1*)group_fns; fns->version fns->db2secDoesGroupExist fns->db2secFreeErrormsg fns->db2secFreeGroupListMemory fns->db2secGetGroupsForUser

= = = = =

DB2SEC_API_VERSION; &Log_is_group; &Log_free_error_message; &Log_free_group_list; &Log_get_groups;

fns->db2secPluginTerm return (DB2SEC_PLUGIN_OK);

= &Log_terminate_plugin;

}

db2secPluginTerm (Internal Name: Log_terminate_plugin) You need to do nothing because the plug-in did not do anything special on the initialization function.

db2secGetGroupsForUser (Internal Name: Log_get_groups) 1. Check the token input parameter. If it is not null, it should contain the group list for this authenticated user. The plug-in should just return the token as the group list and DB2SEC_PLUGIN_OK as the return code. Otherwise, continue to Step 2. 2. Establish communication with the daemon. 3. Send the auth ID from the input parameter to request the daemon to look for the group list. (D4) 4. Allocate memory for storing the group list to be returned to the caller if the number of groups is greater than zero. 5. Return the group list and return code that is replied by the daemon.

Appendix I

Server Authentication Plug-In

391

db2secDoesGroupExist (Internal Name: Log_is_group) Return DB2SEC_PLUGIN_GROUPSTATUSNOTKNOWN for simplicity because it will be quite hard to find if a given auth ID is the uppercase version of the group in one of the group lists in the database. As a result, you must specify the target auth ID type (USER or GROUP) when issuing a grant statement.

db2secFreeGroupListMemory (Internal Name: Log_free_group_list) Free the group list memory allocated in Step 3 of db2secGetGroupsForUser.

db2secFreeErrormsg (Internal Name: Log_free_error_message) Free the memory that is allocated for returning error messages for the other plug-in APIs.

SERVER AUTHENTICATION PLUG-IN To implement a server authentication plug-in, the following APIs are required. Just like the group plug-in, a callback function db2secLogMessage will be made available to the server authentication plug-in. In addition, DB2 provides yet another callback function called db2secGetConDetails that allows the plug-in to retrieve the information about the client that is attempting to establish the connection. Information such as the IP address and the network protocol used is made available for the server plug-in.

db2secServerAuthPluginInit 1. Assign all the function addresses to the function pointers. 2. Set plugintype = DB2SEC_PLUGIN_TYPE_USERID_PASSWORD. 3. Set the version based on the version of security plug-in API you are using. It is suggested that you use the latest version number (that is, the define DB2SEC_API_ VERSION from the header file db2secPlugin.h). Listing I.2

A Sample Listing for the db2secServerAuthPluginInit API

#ifdef __cplusplus extern “C” #endif SQL_API_RC SQL_API_FN db2secServerAuthPluginInit( db2int32 version, void* server_fns, db2secGetConDetails* getConDetails_fn, db2secLogMessage* logMessage_fn, char** errormsg, db2int32* errormsglen)

392

Appendix I


{ struct userid_password_server_auth_functions_1 *fns = (struct userid_password_server_auth_functions_1*) server_fns;

— global variable condetails_fn and goto_LogMessage condetails_fn = getConDetails_fn; goto_LogMessage = logMessage_fn; fns->version = DB2SEC_API_VERSION; fns->plugintype = DB2SEC_PLUGIN_TYPE_USERID_PASSWORD; fns->db2secDoesAuthIDExist = &Log_is_user; fns->db2secFreeErrormsg = &Log_free_error_message; fns->db2secFreeToken = &Log_free_token; fns->db2secGetAuthIDs = &Log_getauthids; fns->db2secServerAuthPluginTerm = &Log_terminate_plugin; fns->db2secValidatePassword return (DB2SEC_PLUGIN_OK);

= &Log_validatePassword;

}

db2secServerAuthPluginTerm (Internal Name: Log_terminate_plugin) Nothing to do because the plug-in did not do anything special on the initialization function.

db2secValidatePassword (Internal Name: Log_validatePassword) 1. Calculate the hash value for the password in the input parameter. 2. If a new password is specified, calculate the hash value for the new password. 3. Establish communication with the daemon. 4. Send the user ID, the password hash value, and optionally a new password hash value to request that the daemon validates the password and retrieves the group list if validation is successful. (D1) 5. If the return code is not DB2SEC_PLUGIN_OK, the output token will be null. Otherwise, allocate memory to store the retrieve group list. This allocated memory will be freed when db2secFreeToken is called after performing a group lookup for the authenticated user.

Appendix I

Server Authentication Plug-In

393

db2secGetAuthIDs (Internal Name: Log_getauthids) 1. Establish communication with the daemon. 2. Send the userid from the input parameter to request the daemon for auth ID lookup. (D2) 3. Return the auth ID and return code that are returned by the daemon.

db2secDoesAuthIDExist (Internal Name: Log_is_user) 1. Establish communication with the daemon. 2. Send the auth ID from the input parameter to request that the daemon check that this user auth ID exists in the database. (D3) 3. Return the return code that is returned by the daemon.

db2secFreeToken (Internal Name: Log_free_token) Free the memory that is allocated to contain the token. In our design, the token is the group list for the authenticated user. If any user authenticated successfully, the token is the group list string.

db2secFreeErrormsg (Internal Name: Log_free_error_message) Free the memory that is allocated for returning an error message for the other plug-in APIs.


Index A access control. See also LBAC (Label Based Access Control) in LDAP, 368 for PUBLIC group during implementation, 260-266 under Sarbanes-Oxley Act of 2002, 10 security policy creation, 38 Account Lockout Duration setting (Windows), 109 Account Lockout Threshold setting (Windows), 109 account policy settings, Windows security, 107-108 accounts (Windows), locking down, 108-109 Active Directory, securing, 112, 368-369 administrative application for identity management case study, 83-84 Administrator account (Windows), locking down, 108 ADMIN_COPY_SCHEMA stored procedure, LBAC support, 233 altering protected tables (LBAC), 234 APAR (Authorized Program Analysis Report), 312 APIs for customized security plug-ins, 77-78 application vulnerabilities, discovering, 313 approving security policies, authority for, 35-36 ARRAY security label component (LBAC), 167 access rules example, 173 deleting data records, 197, 199 inserting data records, 191-194 retrieving data records, 194-196 updating data records, 196-197 AS (authentication service), Kerberos, 70 asymmetric cryptography, 239 attacks, response to, 316-317 audit record layouts AUDIT events, 337 CHECKING events, 338-339 CONTEXT events, 348 OBJMAINT events, 340-341 SECMAINT events, 342-344 SYSADMIN events, 345 VALIDATE events, 346-347 audit record object types, 349-350

AUDIT scope option, db2audit utility, 282-284, 337 auditing, 269-271 design phase, 276-301 granting privileges, 121 under HIPAA (Health Insurance Portability and Accountability Act), 14-15 planning for, 271-276 under Sarbanes-Oxley Act of 2002, 9 in security policy creation, 38-39 auth IDs. See authorization IDs auth plug-ins, 54 client-side auth plug-ins, 57-59 GSS API-based auth plug-ins, 55-56 client-server flow in, 67-69 enabling, 64 Kerberos, 70-73, 329-336 mixed use clients scenario, 88 restrictions on, 68 server-side auth plug-ins, 58, 60 user ID/password-based auth plug-ins, 54 enabling, 63-64 LDAP (Lightweight Directory Access Protocol), 73-76 authentication client authentication, 46-47 DATA_ENCRYPT authentication method, 241 DATA_ENCRYPT_CMP authentication method, 242-243 under HIPAA (Health Insurance Portability and Accountability Act), 15 host-based authentication, setting up for SSH (Secure Shell) data partitioning, 306-307 importance of, 41 instance-level operations, 46 mutual authentication, 70 by operating system, 42-43 of passwords, 257-258 public key authentication, setting up for SSH (Secure Shell) data partitioning, 305, 307 security plug-ins. See security plug-ins

395

396

AUTHENTICATION parameter (response files), 102 authentication requirements, security plan creation, 28 authentication service (AS), Kerberos, 70 authentication type, 43 for catalog database command, setting, 46 on DB2 connect gateway, 52 determining for connections, 52-53 hybrid authentication types, 48 list of supported authentication methods, 44, 46 negotiation between client and server, 47-51 selecting, 44 SRVCON_AUTH Database Manager Configuration parameter, 46-47 authorities database-level authorities, 134-136 determining with GET AUTHORIZATIONS command, 137-138 direct authority, indirect authority versus, 138 granting/revoking when changes take effect, 156-158 hierarchy of, 129-130 implicitly granted authorities, 144-145, 147 instance-level authorities, 129-134 object ownership management, 158-162 privileges versus, 129 for reviewing/approving/implementing/ maintaining security policies, 35-36 authorization, indirect access, 363-365 authorization checking for DB2 command/utilities, 147 for SQL statements, 147-156 authorization ID mapping, Kerberos, 72 authorization IDs defined, 118-119, 375 object owner, defined, 118 orphan authorization ID, 158-159 retrieving group membership list for, 149 session authorization ID, LBAC enforcement, 171 statement authorization ID, 147 system authorization ID, 147 types of, 375-377 user IDs versus, 58, 118 Authorized Program Analysis Report (APAR), 312 awareness, human factor in security, 320-322

Index

B backup command, 364 backups importance of, 2-3 LBAC support, 234 under Sarbanes-Oxley Act of 2002, 10-11 best practices, 119 documentation, 122-123 due diligence, 122 granting group privileges, 122 granting PUBLIC privileges, 125-128 “least privilege” principle, 120 “need to know” principle, 119-120 process control and review, 121-122 schemas, 123-124 “separation of duties” principle, 121 Bond, Rebecca, 2-3 BY ALL keywords, revoking database-level authorities, 136

C cached dynamic SQL, LBAC support, 234 case sensitivity of passwords, 373 case studies. See also sample scenarios identity management, 80-87, 389-393 LBAC, 207-217 catalog database command, setting authentication type, 46 catalog views, 363 CATALOG_NOAUTH parameter (response files), 102 cell-level encryption, 247-248 change control, 39-40 changes to authorities/privileges, when become effective, 156-158 CHECKING scope option, db2audit utility, 284-286, 338-339, 353, 355 client, negotiation of authentication type, 47-51 client authentication, 46-47 client-server flow in GSS API auth plug-ins, 67-69 client-side auth plug-ins, 57-59 COBIT (Control Objectives for Information and related Technology) framework, 8 column protection, 224-225 column security labels (LBAC), 169 column-level encryption, 246-247 column-level table protection (LBAC), 170 command syntax, db2audit utility, 279-299

Index

comments, creating in SQL, 122-123 Committee of Sponsoring Organizations of the Treadway Commission (COSO), 8 comparing encrypted data, 252-253 compiling customized security plug-ins, 78 compliance. See regulations CONFIGURE keyword, db2audit utility, 281 configuring DB2 for SSH (Secure Shell) data partitioning, 307-308 db2audit utility, 281-291 Windows for Kerberos, 332 connect statement, user IDs/passwords in, 239-241 connections authentication type, determining, 52-53 special connection IDs, password authentication, 257 CONTEXT scope option, db2audit utility, 290-291, 348, 351 Control Center, copying protected tables (LBAC), 233 Control Objectives for Information and related Technology (COBIT) framework, 8 CONTROL privileges, WITH GRANT OPTION and, 142-144 copying protected tables (LBAC), 233 corporate sponsorship for auditing, 271 CREATE_NOT_FENCED_ROUTINE database-level authority, 135 credential delegation, 92 cryptography, 238-239. See also encryption customized security plug-ins, creating, 76-78, 80 customizing Kerberos, 72

D daemon for identity management case study, 84-87 DAS (DB2 Administration Server), 96-97, 372 data partitioning with SSH (Secure Shell), 303-308 data records. See records (LBAC) database auditing. See auditing database backups, LBAC support, 234 database communication with different instances/authentication settings scenario, 89-90 Database Manager Configuration parameters NULL values for, 133-134 security plug-ins, 62-63 SRVCON_AUTH parameter, 46-47 database objects, schemas in security best practices, 123-124 database security plans. See security plans

397

database-level authorities granting and revoking, 136 list of, 134-135 separation of DBADM and SECADM authorities, 136 databases, default privileges for creating, 365, 367 DATA_ENCRYPT authentication method, 241 DATA_ENCRYPT_CMP authentication method, 242-243 DB2 commands, authorization checking, 147 configuring for SSH (Secure Shell) data partitioning, 307-308 connect gateway, authentication type, 52 e-mail alerts, 310 encryption. See encryption implementation. See implementation maintenance. See maintenance security plug-ins. See security plug-ins support web page, 311 utilities, authorization checking, 147 DB2 9 information center, 311 DB2 Administration Server. See DAS DB2 Anonymous Resolution under HIPAA (Health Insurance Portability and Accountability Act), 16-17 DB2 Data-Partitioning Feature (DPF). See data partitioning with SSH (Secure Shell) DB2 database security plans. See security plans DB2 Database Security Readiness Review Checklist, 363 DB2 for Windows, 95-106 DB2 for z/OS clients, Kerberos sample scenario, 91 DB2 Recovery Expert, 11 DB2 Recovery Expert for Multiplatform, 301 DB2-L mailing list, 311 db2audit utility audit record object types, 349-350 command syntax, 279-299 configuring, 281-291 extracting audit records, 293-298 functionality of, 278 intrusion detection, 277 multipartition environments, 278 pending audit records, 292-293 pruning audit records, 299 SCOPE parameter, 337-348, 351-355 securing, 278-279

398

starting, 290, 292 testing, 277-278 verifying configuration settings, 290-291 db2cat tool, 365 DB2COMM parameter (response files), 104 db2dart tool, 365 db2look command, LBAC support, 236 DB2_ADMINGROUP_NAME parameter (response files), 104 DB2_EXTSECURITY parameter (response files), 104 DB2_EXTSECURITY Windows registry key, 105-106 DB2_USERSGROUP_NAME parameter (response files), 104 DBA responsibilities auditing planning, role in, 273-276 under HIPAA (Health Insurance Portability and Accountability Act), 14-17 password maintenance, 257-258 under Sarbanes-Oxley Act of 2002, 8-13 system administrator responsibilities versus, 93-94 DBADM database-level authority, separation from SECADM authority, 132-133, 136 deadlock monitoring, 365 decryption, 248-249 DECRYPT_BIN function, 244, 248-249 DECRYPT_CHAR function, 244, 248-249 default privileges upon database creation, 365, 367 deleting. See also dropping data records from protected tables (LBAC), 182, 190-191, 197, 199, 206-207 protection from protected tables (LBAC), 226-227 deployment limitations, security plug-ins, 92. See also implementation design, implementation and, 259-260 design phase for auditing, 276-277 DB2 Recovery Expert for Multiplatform, 301 db2audit utility command syntax, 279-299 db2audit utility functionality, 278 intrusion detection, 277 monitoring the auditing, 302 multipartition environments, 278 securing db2audit utility, 278-279 stored procedures, 301 testing db2audit utility, 277-278 triggers, 299-301

Index

Diffie-Hellman Exchange algorithm, 238 direct authority, indirect authority versus, 138 disabling search on DAS (DB2 Administration Server), 97 disaster planning, importance of, 2-3 DISCOVER parameter (response files), 102 DISCOVER_INST parameter (response files), 103 discovery for auditing, 271-272 disk data encryption, 243-244 comparing encrypted data, 252-253 examples of usage, 246-249 noncharacter data types, 251-252 password hints, 249-251 SET ENCRYPTION PASSWORD statement, 246 SQL built-in functions, 244-245 Distributed Relational Database Architecture (DRDA), 47 documentation of DB2 for Windows installation, 95-96 in security best practices, 122-123 usefulness during implementation, 256 domain\user IDs, Windows support for, 105 DPF (DB2 Data-Partitioning Feature). See data partitioning with SSH (Secure Shell) DRDA (Distributed Relational Database Architecture), 47 dropping. See also deleting column protection from protected tables (LBAC), 225 protected tables (LBAC), 227 security label components (LBAC), 220 security labels (LBAC), 218-219 security policies (LBAC), 219-220 due diligence (security best practices), 122 dump files, 365 dynamic authorization model, 148 dynamic separation of duties security principle, 121 dynamic SQL rules, authorization checking, 151-154

E editing sample response files, 100 education, human factor in security, 320-322 enabling security plug-ins, 63-65 encapsulating objects, authorization checking for SQL statements, 155-156 ENCRYPT function, 244, 249-251

Index

encryption, 239. See also cryptography for disk data, 243-253 under HIPAA (Health Insurance Portability and Accountability Act), 15 for network data, 241-243 as part of cryptography, 238 under Sarbanes-Oxley Act of 2002, 11-12 security policy creation, 39 for user IDs/passwords in connect statement, 239-241 ERRORTYPE parameter, db2audit utility, 282 evalution of future security needs, 317-318 exception tables, 364 exemptions (LBAC), 169-170 access rules example, 175-176 granting, 222 revoking, 222 explain snapshot, 364 EXPLAIN statement, LBAC support, 236 exporting data records from protected tables (LBAC), 232 external routine libraries, 372 extracting audit records, db2audit utility, 293-298

F Federal Information Security Management Act (FISMA), 18-19 federated environments, user mapping plug-ins, 373 fenced processes, write access, 371 FENCED THREADSAFE routines, 370 FISMA (Federal Information Security Management Act), 18-19 Fixpacks, 114-115, 312-313 functions pointer, populating, 78 future security needs, evaluation of, 317-318

G GAAP (Generally Accepted Accounting Principles), 8 gateway. See DB2 connect gateway Generic Security Service. See GSS GET AUTHORIZATIONS command, 137-138 GETHINT function, 245, 249-251 global groups, creating, 367 Gramm-Leach-Bliley Act of 1999 (GLBA), 17-18 granting database-level authorities, 136 exemptions (LBAC), 222 group privileges, 122

399

privileges auditing of, 121 implicitly granted authorities/privileges, 144-145, 147 when changes take effect, 156-158 WITH GRANT OPTION, 142-144 PUBLIC privileges, 125-128 security labels (LBAC), 221 group auth IDs, 58, 118 group membership list, retrieving, 149 group plug-ins, 54, 58-59 enabling, 64 identity management case study, 389-391 group privileges checking for SQL statements, 149-151 granting, 122 groups global groups, creating, 367 naming conventions, security plan creation, 29-30 GSS API-based auth plug-ins, 55-56, 60-61 client-server flow in, 67-69 enabling, 64 Kerberos, 70-73, 329-336 mixed use clients scenario, 88 restrictions on, 68 Guest Account (Windows), locking down, 109

H header files, customized security plug-ins, 76-77 Health Insurance Portability and Accountability Act. See HIPAA High Performance Unload (HPU), 365 hints for passwords, 249-251 HIPAA (Health Insurance Portability and Accountability Act), 13-17 host-based authentication, setting up for SSH (Secure Shell) data partitioning, 306-307 HPU (High Performance Unload), 365 human factor in security, 319-325 Hurricane Katrina, 2-3 hybrid authentication types, 48

I IBM Tivoli Access Manager, 327 IBM Tivoli Identity Manager, 327 IBM Tivoli Risk Manager, 327 IBM-shipped security plug-ins, 56-57

400

IBMKrb5 plug-in configuring NAS kit, 329-332 support for, 73 identification, 41 identity management case study, 80-87, 389-393 implementation, 255 design and, 259-260 documentation from previous projects, usefulness of, 256 password authentication and maintenance, 257-258 performance considerations, 267 prioritizing sensitive data, 258-259 PUBLIC group access control, 260-266 security policies and, 35-36, 256 for upgrades/migrations/scalability projects, 267 when to start, 259 IMPLICIT_SCHEMA database-level authority, 135 implicitly granted authorities/privileges, 144-147 importing data records into protected tables (LBAC), 232 indirect access, 363-365 indirect authority, direct authority versus, 138 information gathering checklist, security plan creation, 24-25 insecure routines, 372 inserting data records into protected tables (LBAC), 180, 182-185, 191-194, 199-203 with views (LBAC), 231 installation client-side auth plug-ins, 57 DB2 for Windows, 95-104 installation user IDs, 105, 112-113 instance-level authorities, 129-134 instance-level operations, authentication, 46 internal controls (Sarbanes-Oxley Act of 2002), 7-8 interoperability, Kerberos support, 333-334 intrusion detection, 277, 315-316

J–K Johnson & Johnson, Tylenol product-tampering incident, 325 KDC (Kerberos Key Distribution Center), 70 Kerberos, 70-73, 329-336 authentication steps, 70-71 authorization ID mapping, 72

Index

customizing, 72 in DB2 for z/OS client environment scenario, 91 IBMKrb5 plug-in, 73, 329-332 NAS kit, configuring on UNIX/Linux systems, 329-332 source code, 72 support for, 333-334 Windows, configuring for, 332 Kerberos Key Distribution Center (KDC), 70 Kerberos plug-ins, enabling, 65

L LBAC (Label Based Access Control), 165-166 ADMIN_COPY_SCHEMA stored procedure, 233 architecture of, 166-171 case study, 207-217 database backups, 234 db2look command, 236 enforcement, 171-176 EXPLAIN statement, 236 under HIPAA (Health Insurance Portability and Accountability Act), 16 MQTs (materialized query tables), 232 protected tables. See protected tables (LBAC) referential integrity constraints, 234, 236 security label components, 218-220 security labels, 217-219 security plans, 177-179 security policies, 218-220 staging tables, 232 typed tables, 232 user access management, 221-223 views, 227-231 LDAP (Lightweight Directory Access Protocol), 73-76, 368 “least privilege” security principle, 120 legal issues. See regulations libraries, shared, 78-80 Lightweight Directory Access Protocol. See LDAP Linux. See UNIX/Linux systems listings db2secGroupPluginInit API, 390 db2secServerAuthPluginInit API, 391 GET AUTHORIZATIONS command output, 137 populating the function pointer structure, 78 security plug-in initialization API, 77 triggers used for auditing purposes, 155-156

Index

LOAD database-level authority, 135 LOAD utility, 298 loading data records into protected tables (LBAC), 232-233 security plug-ins, 66 log reader APIs, 364 LSA (Local System Account), 112-113

M maintenance, 309 discovering vulnerabilities, 309-313 evaluation of future needs, 317-318 Fixpacks, 312-313 intrusion detection, 315-316 mixed database environments, 314 preparation for attack response, 316-317 security policies, authority for, 35-36 vulnerability assessments, 314-315 mappings authorization ID mapping, Kerberos, 72 security policy creation, 38 materialized query tables (MQTs), LBAC support, 232 meeting facilitation tools, security plan creation, 27-28 meeting goals, security plan creation, 26-27 meeting participants. See team members migrations, implementation for, 267 mixed database environments, maintenance, 314 monitoring auditing process, 302 output, 365 MQTs (materialized query tables), LBAC support, 232 multipartition environments, db2audit utility, 278 mutual authentication, 70

N naming conventions security plan creation, 29-30 security policy creation, 37-38 user IDs, 72 NAS kit, configuring on UNIX/Linux systems, 329-332 “need to know” security principle, 119-120 negotiation of authentication type, 47-51 network data encryption, 241-243 New Orleans, 2-3 noncharacter data types, encryption, 251-252

401

NOT FENCED routines, 370 NULL values for database manager configuration parameters, 133-134

O object owner, defined, 118 object ownership management, 158-162 OBJECTOWNERS administrative view, 159 OBJMAINT scope option, db2audit utility, 286-287, 340-341 operating system authentication by, 42-43 vulnerabilities, discovering, 313 orphan authorization ID, 158-159

P package authorization ID, defined, 376 packages authorization checking for SQL statements, 152-154 LBAC support, 234 parameters in response files, 101-104 partitioned tables, LBAC support, 234 partitions, multipartition environments (db2audit utility), 278. See also data partitioning with SSH (Secure Shell) PASSWORDHINT parameter (ENCRYPT function), 249-251 passwords authentication, 257-258 case sensitivity, 373 cell-level encryption, 247-248 column-level encryption, 246-247 in connect statement, encryption, 239-241 decryption, 248-249 password hints, 249-251 security plan creation, 30-31 SET ENCRYPTION PASSWORD statement, 246 Windows security, 107-108 patches, importance for security, 114-115 PCAOB (Public Company Accounting Oversight Board), 8 pending audit records, db2audit utility, 292-293 performance considerations, implementation and, 267 perimeter-based intrusion detection, 315-316 physical security for Windows systems, 113-114 planning for auditing, 271-276. See also security plans policies. See security policies

402

populating functions pointer, 78 preparation for attack response, 316-317 primary authorization ID, defined, 375 prioritizing sensitive data for implementation, 258-259 Private Key Cryptography, 238 privileges authorities versus, 129 default privileges upon database creation, 365, 367 determining, 140 granting auditing of, 121 when changes take effect, 156-158 WITH GRANT OPTION, 142-144 group privileges checking for SQL statements, 149-151 granting, 122 hierarchy of, 138-139 implicitly granted privileges, 144-145, 147 list of, 140-141 object owner, defined, 118 object ownership management, 158-162 PUBLIC privileges, 125-128 of security plug-ins, 66 process control and review (security best practices), 121-122 protected tables (LBAC), 170-171 altering, 234 column protection, 224-225 copying, 233 deleting data records, 182 with ARRAY security label component, 197, 199 with SET security label component, 190-191 with TREE security label component, 206-207 deleting protection, 226-227 dropping, 227 enforcement, 171-176 exporting data, 232 importing data, 232 inserting data records, 180 with ARRAY security label component, 191-194 with SET security label component, 182-185 with TREE security label component, 199-203

Index

loading data, 232-233 retrieving data records, 180-181 with ARRAY security label component, 194-196 with SET security label component, 185-188 with TREE security label component, 204-205 reviewing, 223 row protection, adding, 224-225 security policies, changing, 226 updating data records, 181-182 with ARRAY security label component, 196-197 with SET security label component, 188-190 with TREE security label component, 205-206 user access management, 221-223 pruning audit records, db2audit utility, 299 pseudo databases under Sarbanes-Oxley Act of 2002, 12 Public Company Accounting Oversight Board (PCAOB), 8 PUBLIC group access control during implementation, 260-266 security plan creation, 29-30 public key authentication, setting up for SSH (Secure Shell) data partitioning, 305, 307 Public Key Cryptography, 239 PUBLIC privileges, 125-128 publishing security breaches, 323-325

Q–R querying. See retrieving data records QUIESCE_CONNECT database-level authority, 135 read access rules (LBAC), 171-172 records (LBAC) deleting from protected tables, 182, 190-191, 197, 199, 206-207 exporting from protected tables, 232 importing into protected tables, 232 inserting into protected tables, 180, 182-185, 191-194, 199-203 with views, 231 loading into protected tables, 232-233

Index

retrieving from protected tables, 180-181, 185-188, 194-196, 204-205 with views, 227-231 updating in protected tables, 181-182, 188-190, 196-197, 205-206 recovery under Sarbanes-Oxley Act of 2002, 10-11 referential integrity constraints, LBAC support, 234, 236 Registry (Windows), locking down, 110-112 regulations FISMA (Federal Information Security Management Act), 18-19 Gramm-Leach-Bliley Act of 1999 (GLBA), 17-18 HIPAA (Health Insurance Portability and Accountability Act), 13-17 reasons for, 5-6 Sarbanes-Oxley Act of 2002, 6-13 Remote Registry service (Windows), 110 Remote Shell (RSH), 303 removing. See deleting; dropping REOPT BIND option, 365 replication, 364 RESET command, db2audit utility, 281 Response File Generator utility, 99 response files, 97-104 RESTRICTIVE keyword, granting PUBLIC privileges, 125 retrieving data records from protected tables (LBAC), 180-181, 185-188, 194-196, 204-205 with views (LBAC), 227-231 return codes, security plug-ins, 384-387 reviewing protected tables (LBAC), 223 security label components (LBAC), 218 security labels (LBAC), 217 security policies, 35-36, 218 revoking database-level authorities, 136 exemptions (LBAC), 222 instance-level authorities, 131-132 privileges/authorities when changes take effect, 156-158 PUBLIC privileges, 126-128 security labels (LBAC), 222

403

routine classes, 371 routine definer authorization ID, defined, 376 routine invoker authorization ID, defined, 376 routine libraries, 371 routines authorization checking for SQL statements, 152-154 security considerations, 369-372 row protection, adding to protected tables (LBAC), 224-225 row security labels (LBAC), 169 row-level table protection (LBAC), 170 RSA encryption, 239 RSH (Remote Shell), 303 RSS feeds for DB2 information, 311

S sample response files, 100-101 sample scenarios. See also case studies authorization checking for SQL statements, 150-151 database communication with different instances/authentication settings, 89-90 deleting data records with ARRAY security label component, 197, 199 with SET security label component, 190-191 with TREE security label component, 206-207 granting privileges, 142-144 inserting data records with ARRAY security label component, 191-194 with SET security label component, 183-185 with TREE security label component, 199-203 Kerberos in DB2 for z/OS client environment, 91 mixed use clients with GSS API plug-in, 88 retrieving data records with ARRAY security label component, 195-196 with SET security label component, 186-188 with TREE security label component, 204-205

404

updating data records with ARRAY security label component, 196-197 with SET security label component, 188-190 with TREE security label component, 205-206 Sarbanes-Oxley Act of 2002, 6 DBA responsibilities, 8-13 internal controls, 7-8 sections 302 and 404, 7 SARBOX. See Sarbanes-Oxley Act of 2002 scalability projects, implementation for, 267 scenarios. See sample scenarios schemas in security best practices, 123-124 SCOPE parameter, db2audit utility, 282 AUDIT option, 282-284, 337 CHECKING option, 284-286, 338-339, 353, 355 CONTEXT option, 290-291, 348, 351 OBJMAINT option, 286-287, 340-341 SECMAINT option, 286-287, 342-344 SYSADMIN option, 288, 345, 352-353 VALIDATE option, 288-290, 346-347 search, disabling on DAS (DB2 Administration Server), 97 SEC (Securities and Exchange Commission), 8 SECADM database-level authority, separation from DBADM authority, 136 SECMAINT scope option, db2audit utility, 286-287, 342-344 secondary authorization ID, defined, 375 Secure Shell. See SSH securing db2audit utility, 278-279 Securities and Exchange Commission (SEC), 8 security best practices, 119-128 breaches, publishing, 323-325 human factor in, 319-325 implementation. See implementation maintenance. See maintenance Windows security features, 106-115 security considerations Active Directory, 368-369 default privileges upon database creation, 365, 367 indirect access, 363-365 LDAP, access control, 368 routines, 369-372

Index

user mapping plug-ins, 373 for users, 367 security label components (LBAC), 167-168 dropping, 220 reviewing, 218 security labels (LBAC), 168-169 dropping, 218-219 granting, 221 reviewing, 217 revoking, 222 security plans basing security policies on, 35 change control, 39-40 creating, 22-23 authentication requirements, 28 components of, 26-27 information gathering checklist, 24-25 meeting facilitation tools, 27-28 meeting goals, 26-27 naming conventions, 29-30 passwords, 30-31 securing written plans, 34 security standards, 31-34 team members, 23-24 importance of, 21-22 LBAC, 177-179 security plug-ins, 53 advantages of, 54 APIs, 58 authorization ID versus user ID, 58 categories of, 54-56 client-server flow in GSS API authentication, 67-69 client-side auth plug-ins, 57-59 creating, 76-78, 80 Database Manager Configuration parameters, 62-63 deployment limitations, 92 enabling, 63-65 features available, 66-67 group plug-ins, 58-59 GSS APIs, 60-61 IBM-shipped security plug-ins, 56-57 identity management case study, 80-87, 389-393 Kerberos, 70-73, 329-336 LDAP (Lightweight Directory Access Protocol), 73-76 loading, 66

Index

operating system-based authentication plug-ins, 42 privileges of, 66 restrictions on GSS API auth plug-ins, 68 return codes, 384-387 sample scenarios, 88-91 server-side auth plug-ins, 58, 60 security policies change control, 39-40 creating, 35-39 implementation and, 256 LBAC, 168 changing on protected tables, 226 dropping, 219-220 reviewing, 218 security readiness checklist, 363 security risks, grid for outlining, 27-28 security standards, security plan creation, 31-34 segregation of duties under Sarbanes-Oxley Act of 2002, 10 selecting authentication type, 44 sensitive data, prioritizing for implementation, 258-259 “separation of duties” security principle, 121 server, negotiation of authentication type, 47-51 server-side auth plug-ins, 58, 60 identity management case study, 391-393 service packs, importance for security, 114-115 session authorization, 364 session authorization ID defined, 376 LBAC enforcement, 171 session ticket, Kerberos, 70 SET ENCRYPTION PASSWORD statement, disk data encryption, 246 SET security label component (LBAC), 167 access rules example, 174 deleting data records, 190-191 inserting data records, 182-185 retrieving data records, 185-188 updating data records, 188-190 SET SESSION AUTHORIZATION statement, 364 Setup Wizard GUI, creating response files, 97 shared libraries, 78-80 snapshots for intrusion detection, 315-316 social engineering, human factor in security, 322 source code for Kerberos, 72 SOX. See Sarbanes-Oxley Act of 2002

405

special connection IDs, password authentication, 257 SQL built-in functions, disk data encryption, 244-245 comments, creating, 122-123 object ownership. See object ownership management statements, authorization checking, 147-156 static SQL objects, defined, 119 SQLCA (SQL Communications Area), 52-53 SRVCON_AUTH Database Manager Configuration parameter, 46-47 SSH (Secure Shell), data partitioning with, 303-308 staging tables, LBAC support, 232 standards. See security standards starting db2audit utility, 290, 292 statement authorization ID, 147, 376 static authorization model, 148 static separation of duties security principle, 121 static SQL objects, defined, 119 STATUS parameter, db2audit utility, 282 stored procedures for auditing, 301 symmetric cryptography, 238 SYSADM instance-level authority, 133 SYSADM_GROUP parameter (response files), 103 SYSADMIN scope option, db2audit utility, 288, 345, 352-353 SYSCAT.SECURITYLABELACCESS catalog view, 379 SYSCAT.SECURITYLABELCOMPONENTELEMENTS catalog view, 380 SYSCAT.SECURITYLABELCOMPONENTS catalog view, 380-381 SYSCAT.SECURITYLABELS catalog view, 379 SYSCAT.SECURITYPOLICYCOMPONENTRULES catalog view, 381 SYSCAT.SECURITYPOLICYEXEMPTIONS catalog view, 381 SYSCAT.TABLES view, access control to, 261-262 SYSCTRL instance-level authority, 131 SYSCTRL_GROUP parameter (response files), 103 SYSIBM tables, access control to, 260 SYSMAINT instance-level authority, 131 SYSMAINT_GROUP parameter (response files), 103

406

system administrator responsibilities versus DBA responsibilities on Windows systems, 93-94 system authorization ID, 147, 376

T team members, security plan creation, 23-24 testing db2audit utility, 277-278 TGS (ticket-granting service), Kerberos, 70 TGT (ticket-granting ticket), Kerberos, 70 Tivoli Access Manager, 327 Tivoli Identity Manager, 327 Tivoli Risk Manager, 327 traces, 365 training. See education, human factor in security transferring object ownership, 159-162 TREE security label component (LBAC), 168 access rules example, 175 deleting data records, 206-207 inserting data records, 199-203 retrieving data records, 204-205 updating data records, 205-206 triggers for auditing, 299-301 authorization checking for SQL statements, 155-156 TRUST_ALLCLNTS parameter (response files), 103 TRUST_CLNTAUTH parameter (response files), 103 Tylenol product-tampering incident, 325 typed tables, LBAC support, 232

U UNIX/Linux systems configuring NAS kit, 329-332 SSH (Secure Shell) data partitioning, 303-308 users, 367 updating data records in protected tables (LBAC), 181-182, 188-190, 196-197, 205-206 upgrades, implementation for, 267 user access management (LBAC), 221-223 user authorization IDs, defined, 118 user ID/password-based auth plug-ins, 54 enabling, 63-64 LDAP (Lightweight Directory Access Protocol), 73-76 user IDs authorization IDs versus, 58, 118 in connect statement, encryption, 239-241 for DB2 for Windows installation, 96-97

Index

DBA user IDs, password maintenance for, 257-258 domain\user IDs, Windows support for, 105 installation user IDs, 105, 112-113 naming conventions, 72 user mapping plug-ins, 373 user security labels (LBAC), 169 user-designed pseudo databases under Sarbanes-Oxley Act of 2002, 12 users naming conventions, security plan creation, 29-30 UNIX platform, 367 Windows platform, 367

V VALIDATE scope option, db2audit utility, 288-290, 346-347 verifying db2audit configuration settings, 290-291 views authorization checking for SQL statements, 155-156 LBAC support, 227-231 visual explain, 364 vulnerabilities assessments, 314-315 discovering, 309-313

W–Z websites for security information, 312 Windows configuring for Kerberos, 332 DAS (DB2 Administration Server), 372 DB2 for Windows, 95-106 DBA versus system administrator responsibilities, 93-94 security features, 106-115 users, 367 WITH GRANT OPTION for privileges, 142-144 write access by fenced processes, 371 write access rules (LBAC), 172-173 write-down exemptions (LBAC), 176 write-up exemptions (LBAC), 176 written security plans, securing, 34 written security policies, securing, 36-37 z/OS clients, Kerberos sample scenario, 91

Understanding DB2 9 Security

DB2 9 Fundamentals Certification Study Guide

IBM DB2 Version 9 New Features

Solaris 9 Security

Solaris 9 Security (Networking)

Security Protocols, 9 conf

UNDERSTANDING TURKEY’S SECURITY DISCOURSE

Understanding Global Security

Database Partitioning, Table Partitioning, and Mdc for DB2 9

DB2 Developer's Guide

DB2 Universal Development Guide

Understanding 8-9-Year-Olds (Understanding Your Child)

Security Threat Mitigation and Response: Understanding Cisco Security MARS

Understanding the Preschooler (Rethinking Childhood , vol. 9)

Information Security Applications, 9 conf., WISA 2008

Computer Security - ESORICS 2004, 9 conf

DB2 Universal Database Certification Guide

Understanding Homeland Security: Policy, Perspectives, and Paradoxes

MySQL to DB2 Conversion Guide

XQuery und SQL XML in DB2-Datenbanken

IBM DB2 9.7 Advanced Application Developer Cookbook

DB2 9 for Linux, UNIX, and Windows: DBA Guide, Reference, and Exam Prep (6th Edition)

Up and Running With DB2 for Linux

A Complete Guide to DB2 Universal Database

Beginning DB2: From Novice to Professional

DB2 Olap Server - Theory and Practices

DB2 Version 8: The Official Guide

DB2 for Solaris: The Official Guide

IBM DB2 9.7 Advanced Administration Cookbook (RAW)

Implementing Database Security and Auditing: Includes Examples for Oracle, SQL Server, DB2 UDB, Sybase

Chasing Phantoms: Reality, Imagination, and Homeland Security Since 9 11

Understanding DB2 9 Security

DB2 9 Fundamentals Certification Study Guide

IBM DB2 Version 9 New Features

Solaris 9 Security

Solaris 9 Security (Networking)

Security Protocols, 9 conf

UNDERSTANDING TURKEY’S SECURITY DISCOURSE

Understanding Global Security

Database Partitioning, Table Partitioning, and Mdc for DB2 9

DB2 Developer's Guide

DB2 Universal Development Guide

Understanding 8-9-Year-Olds (Understanding Your Child)

Security Threat Mitigation and Response: Understanding Cisco Security MARS

Understanding the Preschooler (Rethinking Childhood , vol. 9)

Information Security Applications, 9 conf., WISA 2008

Computer Security - ESORICS 2004, 9 conf

DB2 Universal Database Certification Guide

Understanding Homeland Security: Policy, Perspectives, and Paradoxes

MySQL to DB2 Conversion Guide

XQuery und SQL XML in DB2-Datenbanken

IBM DB2 9.7 Advanced Application Developer Cookbook

DB2 9 for Linux, UNIX, and Windows: DBA Guide, Reference, and Exam Prep (6th Edition)

Up and Running With DB2 for Linux

A Complete Guide to DB2 Universal Database

Beginning DB2: From Novice to Professional

DB2 Olap Server - Theory and Practices

DB2 Version 8: The Official Guide

DB2 for Solaris: The Official Guide

IBM DB2 9.7 Advanced Administration Cookbook (RAW)

Implementing Database Security and Auditing: Includes Examples for Oracle, SQL Server, DB2 UDB, Sybase

Chasing Phantoms: Reality, Imagination, and Homeland Security Since 9 11

Recommend Documents