Overbroad DDL Block Rule Breaks the Monthly Schema Migration
Policy PROD_DB2_ACCESS on a collector has 35 rules. Rule 10 blocks any DDL when DB user matches APP* and object schema is PAYROLL. Rule 20 logs all other activity. A monthly schema migration runs as APP_MIGRATE from the scheduler host 10.20.30.40 using the program db2batch. Last month the migration failed with an authorization error at the first CREATE INDEX. The DBA disabled rule 10 for 45 minutes, and the migration succeeded. Audit found the disable action but no record of the blocked DDL in the access report. The security team will not approve another global disable. The migration window is the first Saturday 01:00-03:00. The application team can provide a dedicated service account but cannot change the scheduler host. Design a policy change that permits the migration while preserving evidence and minimizing risk.
1. What rule change would you make, and where in the rule order? Include conditions and action.
Read the worked answer
Add a higher-priority exception rule before rule 10, not a modification of the broad block. Conditions: DB User = APP_MIGRATE; Source Program = db2batch; Client IP = 10.20.30.40; Day/Time = Saturday 01:00-03:00; Object schema = PAYROLL; Command = DDL. Action = Allow in the access policy. Keep rule 10 for all other APP* users. Because access policy and audit policy are separate, do not remove audit logging; verify the audit policy still logs APP_MIGRATE DDL. If the deployment uses a combined policy, add an explicit Log action or companion rule. Use a group for the PAYROLL objects so the exception is narrow and reviewable.
2. How would you test and roll back the change without another global disable?
Read the worked answer
Clone the policy to a staging collector with a representative Db2 test instance, or apply the exception first with an alert-only/log-only counterpart and monitor hits. Run the exact db2batch migration in a test window. Confirm the exception rule hits, rule 10 does not, and the audit report shows the DDL. Rollback is to disable the new exception rule, not rule 10. Keep a break-glass local admin path and a change record.
3. What evidence should the auditor see after the change?
Read the worked answer
Auditor evidence: policy version history showing the new rule above rule 10, change ticket and approver, rule hit counts for APP_MIGRATE during the window, audit report of the DDL, and confirmation that rule 10 remained enabled for other APP* users. Also show that no global disable occurred. This demonstrates least privilege and preserves the control.