Chapter 19: Key Takeaways

These are the essential points from Chapter 19 that you will need throughout the rest of this book and throughout your career managing DB2 security. If you can explain each of these clearly and from memory, you have a solid foundation for designing and implementing enterprise database security.

Core Concepts to Remember

  1. DB2 separates authentication from authorization. Authentication is always external — RACF on z/OS, operating system or LDAP or Kerberos on LUW. Authorization is always internal — managed through GRANT/REVOKE statements and stored in the DB2 system catalog. DB2 never stores passwords. This separation delegates identity verification to specialized systems while keeping access control within the database engine.

  2. The principle of least privilege is not a suggestion — it is a regulatory requirement. Every user, application, and process should have exactly the privileges needed to perform its function. In regulated industries (banking, healthcare, finance), excessive privilege is an audit finding. DB2's granular privilege model — database, schema, table, column — exists precisely to support this principle.

  3. Roles are the correct way to manage privileges at scale. Individual GRANT statements to individual users do not scale and are impossible to audit. Roles create named collections of privileges that map to job functions. Role hierarchies mirror organizational structures. When an employee changes roles, you change role membership — not dozens of individual privileges.

  4. SECADM and DBADM must be separate. The person who defines access control policies (SECADM) must not be the same person who accesses the data those policies protect (DBADM). This separation of duties is fundamental to financial regulation (SOX), healthcare regulation (HIPAA), and payment card standards (PCI-DSS). A single individual holding both authorities is a compliance violation.

  5. RCAC provides security that cannot be bypassed. Unlike view-based security (which is circumvented by direct table access), RCAC row permissions and column masks are enforced directly on the base table regardless of access path. When row access control is activated, DB2 implicitly denies all row access unless a permission explicitly allows it. Column masks transform sensitive values based on the querying user's role.

  6. Activating RCAC without permissions locks everyone out. This is the single most dangerous mistake in RCAC deployment. When you activate row access control on a table, DB2 applies a deny-by-default rule. If no row permissions exist, no one — including DBADM — can see any data. Always create permissive rules before activation.

  7. Trusted contexts are essential for three-tier applications. Without trusted contexts, every request through an application server appears to come from the service account, destroying individual accountability. Trusted contexts allow the application to switch the DB2 auth ID to the actual end user, enabling per-user RCAC enforcement, per-user audit trails, and per-user privilege checking.

  8. Audit is not optional in regulated industries. Audit policies record who accessed what data, when, and from where. The ERROR TYPE AUDIT clause ensures that no unaudited access can occur. Audit logs must be protected from modification, retained per regulatory requirements, and archived independently from database backups.

  9. Encryption protects data at rest and in transit — both are required. Native database encryption (LUW) or z/OS data set encryption protects data on disk. SSL/TLS protects data moving between client and server. Neither alone is sufficient. Column-level encryption adds an additional layer for especially sensitive fields like credit card PANs, but adds complexity and should be used judiciously.

  10. Security is an architecture, not a feature. Authentication, authorization, RCAC, trusted contexts, encryption, and audit work as layered defenses. A failure at one layer does not compromise the entire system. Design security from the ground up, test every layer independently, and verify the complete model end-to-end.

What to Carry Forward

As you proceed through the remaining chapters, keep these security principles in mind:

  • Every new table needs a security classification. When you create a table, immediately determine: Who should read it? Who should write to it? Does it contain PII or regulated data? Does it need RCAC? Does it need audit? Answering these questions at design time is orders of magnitude easier than retrofitting security later.

  • Performance and security must coexist. RCAC row permissions add predicates to every query. Audit policies add I/O for every logged operation. Encryption adds CPU overhead. These costs are real but manageable. Design your indexes to support RCAC predicates. Size your audit storage. Use hardware crypto on z/OS. Never sacrifice security for performance — but design for both.

  • Test security as rigorously as functionality. A security rule that permits too much access is worse than no rule at all, because it creates a false sense of protection. Test every RCAC permission with every role. Verify column masks show the correct values for every user type. Confirm audit policies capture the required events. Automate these tests and run them after every deployment.

  • Document everything for auditors. Security configurations that exist only in the catalog are difficult for auditors to assess. Maintain external documentation of your security model: role definitions, privilege assignments, RCAC rules, audit policies, and encryption configurations. Treat this documentation as a controlled artifact that is updated with every security change.

Platform-Specific Reminders

z/OS

  • Authentication is always through RACF (or ACF2/Top Secret)
  • RACF profiles in the DSNR class control plan execution authority
  • Installation SYSADM is set in DSNZPARM, not through SQL GRANT
  • Audit records go to SMF (record types 101, 102, 142)
  • Encryption leverages hardware Crypto Express adapters
  • LBAC is more commonly used on z/OS for formal classification schemes

LUW

  • Authentication type is set via the AUTHENTICATION database manager configuration parameter
  • SYSADM is granted to members of the OS group specified by SYSADM_GROUP
  • SECADM is granted through SQL: GRANT SECADM ON DATABASE TO USER ...
  • Audit records are written to files and extracted with db2audit
  • Native database encryption is available from Db2 11.1+
  • SSL/TLS uses IBM GSKit (gsk8capicmd_64)

Preview of Chapter 20

In the next chapter, you will learn about performance monitoring and tuning — a topic that intersects directly with security. You will discover:

  • How to use DB2 monitoring tools to identify performance bottlenecks
  • How RCAC predicates appear in access plans and how to optimize them
  • How audit policy overhead affects transaction throughput
  • How to balance security requirements with performance SLAs
  • How to use EXPLAIN to understand the impact of security features on query plans

Security that prevents users from doing their jobs will be circumvented. Performance that comes at the cost of security will eventually be breached. The next chapter teaches you to achieve both.

Return to Chapter 19 | Continue to Further Reading