If you are serious about keeping your Data Center secure and high performing, then making sure your API is not being hammered and that data is not moving in and out of the API without your control.

Quote

Sharing is caring, but only when done responsibly.

In Data Center, we can control what is happening in our API in several areas:

1. Account - allow us to control what accounts have product access and can create tokens to be used to connect with the API
2. Rate Limiting - allow us to define what connections we allow and how many calls they can make before they get throttled.
3. Allow list - allow us to control from where we will allow connections.
4.  

Account

The first thing you want to do is make sure that you control the accounts used to connect to your API. You do this by creating local accounts following a special standard, so you set the account name and email. This will ensure that you are in control of the account and no one can access it or reset the password to gain access.

Example:

• Username: SAINT001
• Full Name: SAINT001
• Email: SAINT001@yourcompany.com

Once the account has been created, you log in as that user using the Switch user function in the User Admin section. Go to Profile ⇾ Personal access tokens and create a token for that user. Make sure it expires in 6 months, or a year. The length depends on how often you want to set up the review of all integrations to make sure the integrations are still active and the documentation of the integration is up to speed.

Rate Limiting

Rate Limiting have two purposes in our setup: limit the amount of requests that integrations can make to prevent performance issues and to control what accounts can access the API.

Enable Rate Limiting and set it to Block all requests. If you have an old Jira with a lot of unknown integrations, or if people are treating it is a playground, then first set it to Limit Requests. This way you can turn down the number of requests, so people notice that something is happening, so they contact you about it.

This is assuming their integration actually has been built with response management and rate limiting support, which they should if they know what they are doing. If they don't, then they actually pose a danger to your Jira, and they should not connect to it anyway.

Once you have activated this, and it is blocking all requests, then no one can access the API. This is not what we want, so we add all our integration accounts to the Exemptions list. This will allow those accounts to connect to the API again.

Set the rate limiting to whatever limit makes sense in general, depending on the configuration of your hosting hardware and perceived impact from the number of integrations you have. If you see that an integration account show up in the List of limited accounts repeatedly, then talk to the integration owner and see if there is a problem, or if that integration need a more generous rate limit.

Allow list

The Allow list will give you the ability to further control access to your API by preventing access from any source that does not match what you have defined. This prevents someone from gaining access to one of the integration account to connect from outside what you have defined.

It also prevents users to share their integration account and token with other groups in your organization, which you should absolutely not allow.

The Allow list should be activated, and the settings should be set to allow authenticated users. You can then add domain names, exact matches, wildcard expressions and regular expressions. Be careful when adding wildcard expressions since users will often request whole networks and that will reduce the effectiveness of your allow list.

Always be as specific as possible. This means that it is far better to add a dozen specific endpoints than adding a wildcard for a full subnet.

Access to data

As a Jira administrator, you should have no involvement when it comes to managing access in Jira. All licenses should be managed by your AD, even if you are a small company, and all project access should be managed by the teams that work in those projects.

This is very important because if you are responsible for licenses and project access, then you are also legally responsible for how the integrations handle the data they have access to.

Make sure that all Jira projects are hidden by default!

I know that sharing is caring, but oversharing is not something you want to spend time in jail for. Make sure that all projects have the same settings for this, and that is that all Jira projects are hidden unless you have a role in that project.

This ensures that integrations also can only access the data that they have access through by the teams manually giving that account a role in their project.

If you absolutely must have everything open to everyone in the organization, but still want to restrict the integration accounts only, then that can be done with AD groups. Just assign all employees in the organization an AD group, and then use that in your permission settings to give all employees access to every project.

Since the integration accounts are local, they will not have that group (unless you stupidly add it of course, but that kind of defeats the purpose of having it...). This way those accounts still need to be assigned a role, and you are able to control the data they have access to.

Secure, Compliant and responsible

These three simple words should always be your mantra when you are working as an administrator in Jira and for integrations they are extra important.

If you do not control your API's, then you not only risk exposing things that should not be exposed. This can be secret projects or god forbid information about your internal infrastructure or customers that a malicious hacker can exploit.

You also risk legal actions based on how the information your Jira provide to other systems, should they use them incorrectly. While Jira in itself do not handle a lot of sensitive data, the tickets themselves can have a lot of this, especially if your users have requested custom fields that hold this kind of information.

And finally, I think everyone can see that if anyone in your organization can connect to your API and do whatever they want, there is only a matter of time before this will start impacting performance.

At the end of the day, it is your job to make sure your Jira is Secure, Compliant and that you configure it responsibly.

--

These are very small steps you can take to secure your API access, and there are other ways as well. Do you have additional steps on how to secure Jira API, or do you think this is not the way to do it?

Sign off in the comments!