Jira Service Accounts and Security

[Clark Everson]

are there any industry standards for bot user account security when people request access for those bots to have access to secure information? Or any suggestion on a policy? We’re trying to make a policy for bot accounts that need access to information users who use the bot would t typically have. And what approval process tends to look like?
Also policy for how to share a bot account and who takes responsibility, ie password manager etc.

[Daniel Ebers]

Hi Clark,

there is a lot that could be said about.
So, here are just some thoughts.

Within Jira you can specify roles - from my opinion a separate role for Service Accounts that is put into (at least every newly created) Jira project works best. In this role a defined group holding all Service Accounts is put. Using this a Project Administrator is going to get the best possible flexibility to adjust settings (I will cover that in a second).

Using Permission Schemes you can then restrict/allow several actions that the Service Accounts can do in the Jira projects - this works best together along with the beforementioned roles in projects.

Common scenario is to let the Service Accounts do a few things by default - in case one specific should have further permissions the Project Administrator has to "empower" them (putting to a role with more permissions then the standard which might only allows to 'browse' but not to 'edit'). It works also the other way around: if a Project Administrator under no circumstance wants to accepts Service Account access the role can be emptied - no access is possible anymore.

For a policy it depends. Probably the most realistic approach is to count them as they would be employees by default.

One best practice is to prohibit users to use Service Accounts for daily tasks like commenting, editing issues, etc. IF not done programmatically by a bulk update script utilizing API for example. Why? Nobody would be able to identify who inserted a comment when it's name is generic.
Rule could be: users are not allowed to login through the frontend - ONLY via REST API using Service Accounts.

More on a organisational level:
It is always a good idea to record (using a Jira issue) who requested an account for what reason, who is responsible. You also can ask if you can see the code that will be used to access REST API using the specific Service Account.
As soon as you have gathered all information it might make sense to put them to a confluence page.
With a due date (every year/every month/quarterly - depending on your environment) you can check in with the initial requestor if the account is still needed and ask if something changed or needs to be changed from their perspective.
You could also require that you will disable an account if the regular interview cannot be held for whatever reason that is not in your responsibility (saves a lot of energy!) and/or the account will be disabled if the responsible contact is not available anymore and nobody seems to "care".

Cheers,
Daniel