Resources

/

ACP Lab Notes

[Part 48] Delegating Only Necessary Work to External Maintenance Staff

Approvals · Auditing · Operations

November 13, 2026

When delegating database checks externally, I first consider access scope. Checking status needs no modification privileges, and completed work provides no reason to retain access.

 

A test user played the external operator, requested read access, obtained separate approval, checked one order, and lost access after revocation. I tested the whole sequence.

 

1. Stating the Database and Task First

The task was simply checking order 41001’s status and amount, using existing lab data and accounts rather than real customer records.

 

The operator’s DB Access Request selected only DB Privilege Account Lab, Read-Only, and a reason specifying status checks, no changes, and revocation afterward.

 

Access expiry was that day. The approver could inspect purpose, scope, and deadline as well as database name.

 

Screen 1. One database, Read-Only, deadline, and reason in the request.
Screen 1. One database, Read-Only, deadline, and reason in the request.

2. Approval Becomes Usable Read Access

Using the existing rule, Demo Approver reviewed the request and commented approval for order-status inspection.

 

Approved status retained separate requester/approver and processing times, providing a basis for later handovers or investigation.

 

Screen 2. Reviewed request marked Approved.
Screen 2. Reviewed request marked Approved.

The operator now saw Read-Only, Select, and expiry at 23:59:59. No duplicate administrator grant was needed.

 

Screen 3. Read-only privileges and expiration reflected in the user view.
Screen 3. Read-only privileges and expiration reflected in the user view.

3. Reads Work, Changes Do Not

Connect opened SQL Editor; order 41001 returned READY and KRW 25,000, satisfying the requested check.

 

Screen 4. Approved access reads the order status and amount.
Screen 4. Approved access reads the order status and amount.

An UPDATE on the same order was denied for missing UPDATE permission. A source-data check confirmed unchanged status and amount.

 

‘Please only inspect’ became an actual enforced scope without also granting write access.

 

Screen 5. UPDATE beyond Read-Only is denied on the same connection.
Screen 5. UPDATE beyond Read-Only is denied on the same connection.

4. Revoking Access as Soon as Work Ends

I revoked only this task’s granted access, leaving the user’s unrelated privileges intact.

 

The refreshed user list no longer showed the database. The already-open editor’s same SELECT also reported no query privilege for the connection.

 

I revoked immediately instead of waiting for scheduled expiry, useful when maintenance finishes early.

 

Screen 6. Revocation blocks reads even in the open SQL editor.
Screen 6. Revocation blocks reads even in the open SQL editor.

5. Evidence from Request to Revocation

Access Control Logs showed a grant at 13:41:48 and revocation at 13:44:24, distinguishing request-based grant from administrator revocation.

 

Screen 7. Approved read grant and post-work revocation history.
Screen 7. Approved read grant and post-work revocation history.

Query Audit showed successful reads and the blocked UPDATE, with database account, table, SQL, and reason. It traced actual activity, not just granted access.

 

Screen 8. Successful read and denied UPDATE statement/reason in Query Audit.
Screen 8. Successful read and denied UPDATE statement/reason in Query Audit.

External maintenance became one flow: request purpose/scope, approve, perform permitted reads, revoke, and retain approver and SQL evidence.

 

What appealed most was enabling work with clear boundaries: allow necessary checks, prevent unauthorized changes, and clean up finished access, verified in one inspection.