Minimum Permissions for Scan Accounts

Forcepoint DSPM IBM DB2 structured data connectors scan DB2 data sources to enable cataloging and classification. This section outlines the minimum Db2 permissions needed for a scan account, helping customers create a least-privilege user instead of relying on SYSADM or a DBADM equivalent account.

Applies to: Db2 LUW 11.5 and later (on-prem / IaaS ).

Connection Prerequisites
Requirement Reason
Network reachability to the Db2 server host:port (default 50000) Establish TCP connection
A Db2 user (typically OS-authenticated) with CONNECT on the target database Establish JDBC connection

The connector uses the IBM Db2 JDBC driver (db2jcc). No system-level authorities (SYSADM, SYSCTRL, SYSMAINT, SYSMON) are required.

How Db2 handles SYSCAT views

SYSCAT.* catalog views are readable by PUBLIC by default. Granting CONNECT on the database is therefore sufficient for the scan account to read all catalog views the connector relies on, provided PUBLIC access to SYSCAT has not been revoked in the environment.

If a hardened Db2 instance has revoked PUBLICSELECT on SYSCAT views, the catalog views listed under each operation below must be granted explicitly (see fallback script below).

Operations and Required Permissions

  1. Connection test and database metadata
    Operation Catalog views read Minimum grant
    Test connection   GRANT CONNECT ON DATABASE
    Schema enumeration SYSCAT.SCHEMATA Implicit via PUBLIC
    Table/view listing & JDBC getTables/getColumns SYSCAT.TABLES, SYSCAT.COLUMNS Implicit via PUBLIC
    Primary/foreign key detection SYSCAT.KEYCOLUSE, SYSCAT.TABCONST, SYSCAT.REFERENCES Implicit via PUBLIC
    Approximate row count SYSCAT.TABLES (CARD column) Implicit via PUBLIC
    Approximate table size SYSCAT.TABLES, SYSCAT.TABLESPACES, SYSCAT.INDEXES Implicit via PUBLIC
  2. Data sampling
    Operation Tables read Minimum grant
    TABLESAMPLE SYSTEM row sample Target user table/view SELECT on the target table/view
    First-N-rows fallback (FETCH FIRST N ROWS ONLY) Target user table/view SELECT on the target table/view
    Column payload sampling Target user table/view SELECT on the target table/view
  3. Trustee (users, groups, and roles) extraction
    Operation Catalog views read Minimum grant
    List users & groups SYSCAT.DBAUTH Implicit via PUBLIC
    List roles and recursive role memberships SYSCAT.ROLEAUTH, Implicit via PUBLIC

    Db2 distinguishes users (GRANTEETYPE = 'U'), groups ('G') and roles ('R') in SYSCAT.DBAUTH. The connector enumerates all three and classifies them accordingly.

  4. Permissions extraction
    Operation Catalog views read Minimum grant
    Database-level authorities SYSCAT.DBAUTH Implicit via PUBLIC
    Schema-level grants SYSCAT.SCHEMAAUTH Implicit via PUBLIC
    Table-level grants SYSCAT.TABAUTH Implicit via PUBLIC
    Column-level grants SYSCAT.COLAUTH Implicit via PUBLIC
    Admin-authority holders (DBADM, SECADM, SQLADM, WLMADM, DATAACCESS, ACCESSCTRL, CREATESECURE) SYSCAT.DBAUTH Implicit via PUBLIC

Granting data access

The scan account must be granted full read access to the entire datasource. Db2 has no built-in read-only "data reader" role, so the closest single-grant analog is the DATAACCESS database authority:
GRANT DATAACCESS ON DATABASE TO USER FP_USER;

DATAACCESS grants implicit SELECT, INSERT, UPDATE, DELETE on all user tables (current and future). The connector only issues SELECT statements — it never modifies data — so the effective use is read-only. If strict read-only enforcement is required by policy, customers can explicitly REVOKE INSERT, UPDATE, DELETE on user tables after granting DATAACCESS.

Consolidated grant script
-- 1) The scan account FP_USER must exist at the OS / LDAP layer (Db2 authenticates externally)

-- 2) Allow JDBC login
GRANT CONNECT ON DATABASE TO USER FP_USER;

-- 3) Data + metadata access — full read access to the entire datasource
GRANT DATAACCESS ON DATABASE TO USER FP_USER;
If PUBLIC access to SYSCAT has been revoked in your environment, also grant:
GRANT SELECT ON
    SYSCAT.SCHEMATA, SYSCAT.TABLES, SYSCAT.TABLESPACES, SYSCAT.INDEXES,
    SYSCAT.COLUMNS, SYSCAT.KEYCOLUSE, SYSCAT.TABCONST, SYSCAT.REFERENCES,
    SYSCAT.DBAUTH, SYSCAT.ROLEAUTH, SYSCAT.SCHEMAAUTH, SYSCAT.TABAUTH, SYSCAT.COLAUTH
TO USER FP_USER;

Verification

Connect as FP_USER and run:
-- Connection + authorities overview
SELECT GRANTEE, DATAACCESSAUTH, DBADMAUTH, CONNECTAUTH FROM SYSCAT.DBAUTH WHERE GRANTEE = 'FP_USER';

-- Metadata & data scan
SELECT COUNT(*) FROM SYSCAT.SCHEMATA;
SELECT TABSCHEMA, TABNAME, CARD FROM SYSCAT.TABLES WHERE TYPE IN ('T','V') FETCH FIRST 5 ROWS ONLY;
SELECT * FROM <SCHEMA>.<TABLE> FETCH FIRST 10 ROWS ONLY;

-- Trustee scan
SELECT GRANTEE, GRANTEETYPE FROM SYSCAT.DBAUTH FETCH FIRST 5 ROWS ONLY;
SELECT GRANTEE, GRANTEETYPE, ROLENAME FROM SYSCAT.ROLEAUTH FETCH FIRST 5 ROWS ONLY;

-- Permissions extraction
SELECT * FROM SYSCAT.SCHEMAAUTH FETCH FIRST 5 ROWS ONLY;
SELECT * FROM SYSCAT.TABAUTH FETCH FIRST 5 ROWS ONLY;
SELECT * FROM SYSCAT.COLAUTH FETCH FIRST 5 ROWS ONLY;

All queries should return without SQL0551N (privilege violation). Empty result sets are acceptable when the underlying object has no matching rows.

What is not required

The scan account does not need any of the following:

  • SYSADM, SYSCTRL, SYSMAINT, SYSMON (system-level authorities)

  • DBADM, SECADM, SQLADM, WLMADM, ACCESSCTRL (database-level admin authorities)

  • BINDADD, CREATETAB, IMPLICIT_SCHEMA, LOAD, EXTERNALROUTINE, CREATE_EXTERNAL_ROUTINE

  • ALTER, CONTROL, INDEX, REFERENCES on any object.