POST_START
Removing Temporary Elevated Production Privileges
I recently had to address a security concern where a group of incident responders had been granted temporary MODIFY privileges on the production.sales.orders table. These privileges were initially issued to allow them to investigate a data integrity issue, but the incident had been resolved, and the elevated access was no longer needed. My task was to remove these privileges to ensure that no unnecessary access remained in the system.
Revoking the Privilege
I started by running the REVOKE MODIFY ON TABLE production.sales.orders FROM `incident-responders` command. This step was critical to formally remove the elevated privileges and ensure that the incident responders could no longer modify the table.
REVOKE MODIFY ON TABLE production.sales.orders FROM `incident-responders`;
I saw a representative result like this:
result
Revoke applied successfully; the requested privilege is no longer granted.
The system confirmed that the privilege had been successfully revoked, which was a good sign that the operation was completed as expected.
Verifying the Privileges
To make sure that the privileges had been removed, I ran the SHOW GRANTS ON TABLE production.sales.orders command. This step was important to verify that the incident responders were no longer listed as having MODIFY access.
SHOW GRANTS ON TABLE production.sales.orders;
I saw a representative result like this:
principal | actionType | objectType
data_analysts | SELECT | TABLE
data_engineers | MODIFY | TABLE
From this output, I confirmed that the incident responders were no longer listed, and that only the data_engineers still had MODIFY privileges. This validated that the revocation had been applied correctly.
Checking the Audit Trail
As part of my thoroughness, I also checked the audit log to see if there were any recent actions involving the production.sales.orders table. This helped me understand the usage pattern and ensure that no unauthorized changes had occurred after the incident was resolved.
SELECT * FROM system.access.audit WHERE request_params LIKE '%production.sales.orders%' ORDER BY event_time DESC;
I saw a representative result like this:
event_time | user_identity | action_name | request_params
2026-09-11 14:32:10 | analyst@demo.com | commandSubmit | {table: production.sales.customers}
2026-09-11 14:31:55 | engineer@demo.com | getTable | {table: production.sales.customers}
These entries showed that no recent actions had been taken on the production.sales.orders table, which aligned with the fact that the incident was resolved and access had been revoked.
Conclusion
By following these steps, I ensured that the temporary elevated privileges were properly removed and that the system remained secure. This process reinforced the importance of regularly reviewing and revoking access when it’s no longer needed, especially in production environments where data integrity is crucial.


Leave a Reply