IBM Db2 Security: Authentication, Authorisation, Encryption and Audit

IBM Db2 gives administrators a layered set of security controls, from separate security and data authorities to row-level policies, native encryption and an audit facility, and each one only protects data once the customer configures it. Db2 holds core records for banks, insurers, retailers and governments, and much of the access to it comes from application servers, batch jobs and service accounts rather than people. This guide covers how authentication and authorisation work in Db2 for Linux, UNIX and Windows (LUW), with notes on Db2 for z/OS: the authority model and separation of duties, trusted contexts for middle-tier service accounts, row and column access control (RCAC), label-based access control (LBAC), native encryption, TLS and the audit facility. It is for database administrators, security architects and auditors who run Db2. For controls that apply to every database engine, read the Database Security Guide; this page stays on Db2-specific settings.

This is an independent guide from NHI Mgmt Group, based on IBM's public documentation as of November 2026. It is not sponsored or reviewed by IBM. Product features change, so confirm settings against IBM's current documentation.

Key takeaways

• Split security from data: SECADM manages security without inherent access to table data, and only SECADM can grant DBADM, ACCESSCTRL, DATAACCESS and SECADM, so give these authorities to different people.
• Start restrictive: a database created with the RESTRICTIVE option skips the default grants to PUBLIC (such as CONNECT, CREATETAB and BINDADD), so every privilege becomes a deliberate grant.
• Keep end-user identity: trusted contexts let an application server switch to the real user on an existing connection, so the database sees the person, not one shared service account.
• Policies at the row and column: RCAC row permissions and column masks apply to every user, including DATAACCESS holders, once SECADM activates them on a table.
• Encrypt and audit by design: native encryption covers databases, logs and backups with a master key held outside Db2, and the audit facility plus audit policies record security events for review.

How identity and access work in IBM Db2

Db2 separates authentication (who you are) from authorisation (what you can do). On LUW, authentication is delegated to the operating system, Kerberos or a GSS-API security plug-in; Db2 then checks the resulting authorisation ID against administrative authorities, privileges, role and group memberships, and LBAC credentials. Object ownership also carries implicit privileges.

Authentication type

The database manager parameter authentication sets where and how users are authenticated. The default is SERVER.

For Java clients using SERVER_ENCRYPT, IBM documents the DB2AUTH registry variable value JCC_ENFORCE_SECMEC to reject clear-text password connections (Db2 10.5 Fix Pack 4 and later). The separate srvcon_auth parameter can set a different type for incoming connections; check that it matches your intent.

Privileges, roles and PUBLIC

• Privileges: granted to users, groups, roles or PUBLIC. CONTROL on a table, view, index or package lets the holder grant privileges on it.
• Roles: database objects managed by SECADM. Grant privileges to roles, then roles to people and service accounts; this keeps reviews readable.
• PUBLIC: covers all users, including future ones. IBM notes that a privilege granted to a name with no matching user or group can be inherited if one is later created with that name, so remove grants to retired names.
• WITH GRANT OPTION: lets the grantee pass a privilege on. Revoking from the grantee does not revoke onward grants, so use it sparingly.
• Static SQL: packages run static SQL with the package owner's privileges; dynamic SQL follows the DYNAMICRULES bind option. Know who owns production packages.

Admin roles and privileged access

The database creator receives DBADM, SECADM, ACCESSCTRL and DATAACCESS by default. Our recommended first step on any new database is to grant SECADM to a named security administrator, then revoke the creator's surplus authorities so no single ID holds both security and data rights.

• Separation of duties: give SYSADM to platform operators, SECADM to the security team, DBADM to database administrators and DATAACCESS only to the application roles that need it. Use EXPLAIN or SQLADM for performance staff who do not need data.
• Db2 for z/OS: set the SEPARATE_SECURITY subsystem parameter to YES so that only SECADM can grant ACCESSCTRL, System DBADM, DATAACCESS and CREATE_SECURE_OBJECT, and only SECADM can turn RCAC on or off, even where SYSADM is held. Pair this with your external security manager; see the Mainframe Identity and RACF Security Guide.
• Break-glass: keep a sealed SYSADM-group or SECADM account in your privileged access vault with dual control. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

Most Db2 traffic comes from application servers, ETL tools, batch jobs and reporting services. These are non-human identities, and they often hold more privilege than any person.

Trusted contexts for middle tiers

A trusted context, created by the security administrator, defines a trust relationship with an external entity using three attributes: SYSTEM AUTHID (the connecting ID), ADDRESS (IP address or domain name) and ENCRYPTION (data stream encryption). On Db2 for z/OS, trust attributes can also include an IP subnet, a SERVAUTH security zone or, for local clients, a job or task name.

• Restore accountability: on an explicit trusted connection, the application server can switch the current user to the real end user, with or without re-authentication, so audit records and privileges reflect the person.
• Scope privilege to the path: assign a role to the trusted context. Privileges in that role apply only to connections that match, so a stolen service account password used from another host does not carry them.
• Write row policies around it: RCAC can test VERIFY_TRUSTED_CONTEXT_ROLE_FOR_USER so rows are visible only through the approved application path.

Service account hygiene

• One account per application: never share a service ID across applications; map each to its own role.
• Credentials out of code: store service passwords in a secrets manager and rotate them; our recommendation is every 90 days or on staff change for shared operational accounts. See the Database Credential and Access Security Guide.
• Package ownership: production packages run static SQL as their owner, so make a dedicated, non-login ID the owner rather than a developer.
• Batch on z/OS: batch jobs and started tasks run under their own IDs. See the Mainframe Service Accounts and Batch Job Identity Guide.

Fine-grained access: RCAC and LBAC

• Who manages it: only SECADM creates, alters, enables and activates permissions and masks. Permissions and masks are created disabled by default.
• No built-in bypass: RCAC applies to every user, including DATAACCESS holders, which is what makes it useful against over-privileged service accounts.
• Secured objects: functions and triggers used with RCAC tables are marked SECURED by SECADM or a delegate; review these as code that can see protected data.
• LBAC exemptions: exemptions bypass label rules for specific users; grant them rarely and review them with privileged access.

Logging and detection

Db2 auditing has two layers. At instance level, SYSADM uses the db2audit tool to configure scope and status. At database level, SECADM uses CREATE AUDIT POLICY and the AUDIT statement to attach policies to the database, tables, authorities, users, groups, roles or trusted contexts.

• Defaults: db2audit audits all instance categories except CONTEXT by default; set status to capture both success and failure for SECMAINT, VALIDATE and SYSADMIN.
• Protect the trail: set datapath and archivepath to directories only the instance owner can write, archive regularly with db2audit archive, and extract to delimited files or syslog for your SIEM.
• errortype: audit returns audit facility errors to the caller, so operations fail when auditing fails; normal ignores them. Choose audit where an audit gap is unacceptable.

Metrics that show the controls are working (our recommendations):

1. Number of IDs holding DATAACCESS, DBADM or SECADM, reviewed quarterly, trending down.
2. Percentage of client connections using TLS.
3. Percentage of sensitive tables with RCAC activated.
4. Days since last audit log archive and SIEM ingestion check.
5. Service accounts connecting outside their trusted context, per month.

See the Database Audit Log Detection Guide for detection rules.

Hardening baseline

Encryption

• Native encryption: encrypts databases, transaction logs and backups before they reach disk. A data encryption key (DEK), unique per database and per backup, encrypts the data; a master key (MK) held in a keystore outside Db2 encrypts the DEK.
• Keystore choice: a local PKCS #12 file, or a centralised KMIP 1.1 or later key manager, or a supported PKCS #11 hardware security module. One keystore per instance. Prefer centralised key management for production so keys are separated from database hosts.
• Rotation: rotating the master key re-protects the DEK without re-encrypting data. Our recommendation is at least annual master key rotation and on any suspected key exposure. See the Database and Storage Encryption Guide.

TLS

• Create a GSKit key database, then set ssl_svr_keydb, ssl_svr_stash, ssl_svr_label and ssl_svcename (a port separate from svcename, not 443).
• Set DB2COMM=SSL for TLS only, or SSL,TCPIP during migration, then restart the instance. TLS needs the connection concentrator off.
• For NIST SP 800-131A alignment, IBM documents ssl_versions=TLSV12, cipher suites of at least 112-bit strength via ssl_cipherspecs, and a certificate with an RSA key of at least 2048 bits and a SHA-2 signature.

Rollout order

1. Inventory: list every holder of SYSADM group membership, SECADM, DBADM, ACCESSCTRL, DATAACCESS and grants to PUBLIC from the SYSCAT views.
2. Audit first: configure db2audit and database audit policies so later changes are recorded.
3. Separate duties: assign SECADM to the security team and revoke surplus creator authorities.
4. Restrict PUBLIC: create new databases with RESTRICTIVE; on existing ones, revoke PUBLIC grants in a test copy first and replay application tests.
5. TLS: run SSL and TCPIP together, move clients, then set DB2COMM to SSL only. Roll back by re-adding TCPIP.
6. Trusted contexts and RCAC: pilot on one application; create permissions disabled, test, then enable and activate. Deactivate to roll back.
7. Encryption: configure the keystore, then encrypt new databases or restore backups into encrypted databases during a maintenance window.
8. Patching: apply IBM fix packs and security updates promptly through your normal change process.

Common misconfigurations

• Creator keeps everything: the ID that created the database still holds SECADM, DBADM and DATAACCESS years later. Hand SECADM to the security team and trim the rest.
• Grants to PUBLIC left in place: non-restrictive databases give PUBLIC CONNECT, CREATETAB and BINDADD; review and revoke what applications do not need.
• One service ID for every application: a single high-privilege ID makes audit records meaningless. Use per-application IDs, roles and trusted contexts.
• RCAC defined but not activated: permissions and masks are created disabled, and nothing is enforced until the table is activated. Check SYSCAT views after every change.
• Audit logs on a writable share: archive paths that DBAs can edit undermine the trail. Restrict them to the instance owner and ship copies to the SIEM.
• TLS beside an open TCPIP port: enabling SSL while keeping TCPIP indefinitely leaves a clear-text path; set a date to remove it.

Practitioner checklist

• Assign SECADM to a named security administrator and revoke surplus creator authorities.
• Keep DBADM, DATAACCESS and SECADM with different people; review holders quarterly.
• Create new databases with RESTRICTIVE and review PUBLIC grants on existing ones.
• Give each application its own service ID, role and trusted context; vault and rotate its credentials.
• Activate RCAC on sensitive tables and review SECURED functions and triggers.
• Configure db2audit and database audit policies; archive and ship logs to the SIEM.
• Enable TLS with TLSV12 and plan removal of the clear-text port.
• Turn on native encryption with a centralised keystore and rotate master keys.
• On z/OS, set SEPARATE_SECURITY to YES and align with your external security manager.
• Apply IBM fix packs and security updates promptly.

Standards and references

• IBM Docs: Db2 authorities overview
• IBM Docs: Db2 authorization, privileges and object ownership
• IBM Docs: authentication configuration parameter
• IBM Docs: Trusted contexts and trusted connections
• IBM: Db2 best practices, row and column access control
• IBM Docs: Overview of Db2 native encryption
• IBM Docs: db2audit command
• IBM Docs: Db2 for z/OS SECADM authority

Related NHI Mgmt Group resources: Database Security Guide · Database Credential and Access Security Guide · Database Audit Log Detection Guide · Least Privilege Techniques Guide