Questions on user context and auditing for background job execution for SaaS application

Question

I have some questions related with user context and auditing for background job execution for SaaS application.

Let's say an admin user scheduled a background job through UI. When the job start running, this job requires to run with a user context, for such case I have following questions:

Question 1: should this job use the admin user in the user context? If so, how about if this is a recurring job and the user leave the company later on and the user account is expired? The job execution will be failed.

Question 2: if the background job need to trigger some code that have permission check logic inside, should we make sure the admin user has been granted with those permissions? Otherwise, the job execution will be failed.

Question 3: if this job will update some PII (personal identifiable information) data, we would like to create audit log for example for GDPR compliance. Should we create an audit log with this admin user as the updater?

I saw some solutions will request end user to provide a technical user when schedule a job. That user is pre-created in the system and usually customer will guarantee this technical user is not expired and with all the permissions granted. However, if we do so, when we create the audit log, should we use the user who triggered the job as the updater or use the technical user?

I am very confused. I would like to know the best practice and pro and cons with different solutions.

Thanks!

Answer 1

I would recommend separating the job scheduling from the job itself.

First, you should audit when an admin creates the job schedule and any time any admin changes or stops the job. If Admin Alice creates the job, you would have that record in the audit trail. If Admin Bob comes along and makes changes, you would audit those changes to the job. It doesn't matter if Alice leaves the company, she's the one who created the job and you would want that reflected in the audit log.

It could also be useful to have change control over the configuration. Presumably, Alice and Bob aren't creating and scheduling jobs without some outside request. Having a project management or issue tracking tool to capture the incoming request and any kind of reviews or approvals to accept the request and make the change could be helpful. If your system supports it, you can even capture the reason for the job scheduling changes and refer to the identifier from the issue tracking tool for more information.

For auditing the job itself, if it's a long-running recurring job, that seems like something that you would want to use a service account for. You can record whatever the job does as being associated with the service account. If you havethe capability to search the audit log, you can deal with queries about what the job did separately from how the job has been managed, or choose to combine those two into a time-ordered sequence of events showing everything about the job.

By using a service account rather than tying it to the admin's account, you don't have to worry about what happens if the account expires because the admin changes roles or leaves the company. You can also deal with cases with multiple admins who are updating the job, such as if Alice creates the job, then Bob modifies the schedule, and both Alice and Bob are with the company.

In my experience, the service account is not one that can be logged into via the user interface. Scripts that run as a service have full read/write access to everything and would be configured to return the correct things. This would be different than one-off jobs that may use the requester's account permissions and groups to determine what work to do.

Demonstrating control over access to administrator accounts and permissions, change management of the job configuration, audit logging of jobs and job configurations, audit logging of job actions, and the ability to connect job actions to the job configuration history should satisfy legal and regulatory requirements.