Improved API security and expanded authentication policy controls for all cloud customers

[#1]

Hi Atlassian Community,

My name is Kunwar, and I am a product manager responsible for cloud security here at Atlassian.

We know that the cybersecurity landscape is constantly evolving, so you need stronger controls to boost your data security approach. That’s why we’re enhancing API security and default authentication policies to provide all Atlassian cloud customers with stronger control and visibility into data access to safeguard their data. Let me walk you through what’s changed and what this means for you.

Improved API Security: What’s changing?

When users at your organization access Atlassian product data via APIs, you need control and visibility over the API tokens and SCIM API keys generated to prevent data security risks. We’ve made 5 key enhancements that are available now and have one in EAP.

• Expiry for API tokens and SCIM API keys: user API tokens and SCIM API keys now have a default one-year expiry from creation to ensure that access privileges are only temporary and must be actively renewed. This will help reduce the likelihood of security incidents resulting from unused or forgotten API tokens and SCIM API keys. Atlassian Guard admins can also set the expiration date for user API tokens in an authentication policy, choosing an expiration between 1 and 365 days. This will apply to members in the policy with API tokens

         

• Adding scopes to API tokens/API Keys: when creating an API token, users can configure which products and related OAuth scopes which the API token can access, along with the level of access, such as specifying read-only access for Jira data. API keys allow admins to act on behalf of their organization to access the admin APIs and consume audit logs, query policies (to ensure compliance), and query users to identify their account IDs. When creating an API key, admins can restrict access to only the necessary permissions. Adding scopes restricts access to only what is necessary, helping to reduce the scale of any potential security incidents.

• Manage orphan API keys (admins only): admins will be notified about keys created by former admins who are no longer part of the organization, enhancing security and transparency at your organization.

         

• Early Access Program: Service accounts: reduce admin overhead with service accounts by eliminating the need to maintain passwords, SSO, or 2FA for accounts that are only created to run scripts and integrations. If you’re interested in participating in the EAP, please email me (ksingh7@atlassian.com) to learn more.

Default authentication policy

To further strengthen user access control, we’re extending the following controls in default authentication policies to all cloud customers:

• Block/allow API tokens - control whether users can create new or use existing API tokens to authenticate to your organization’s product data.

• Enforcing 2FA - require users to setup and use a second verification step when logging into Atlassian products, or make it optional.

• Bulk revoke API tokens - bulk revoke API tokens for all users in an authentication policy instead of deleting them one at a time.

       

These security updates mark another step in providing you with added controls to help you secure your organization’s data in Atlassian cloud. We’re always looking to hear from you, so please share any questions or comments below.

Cheers,

Kunwar

[Dirk Ronsmans]

Interesting news @Kunwardeep Singh !

Especially looking forward to "Adding scopes to API tokens/API Keys", I'm assuming that besides selecting a product that this would also imply that we can limit api tokens to a specific instance only? 

Especially for Solution Partners where we have access (and usually substantial access) to many environments it will be great to limit a token to just a single instance/customer environment and minimize the risk that way.

Also looking forward to the EAP for Service accounts and what that would entail. At the moment we are forced to create dummy accounts just to setup an api token so I'm hopefull that this will somehow allow us to create api tokens linked to the organization with specific permissions while not directly linked to an account (or atleast not an account that has to be linked to a proper mailbox) 

[Christian Schneider]

Working for a psychiatry in Switzerland, we manage lots of different applications, interfacing to each other. Service Accounts are a vitale part of all application and simplify the management. Love to hear that Atlassian will implement server accounts as well! Is there a feature request that I could follow? (I do not have the time to be first mover, but I would like to closely follow the developments.)

[s_weber]

Awesome, glad to see this coming! When are you aiming for GA?

We already take part in several EAP, so unfortunately we cannot take part.

[ricardo_silva]

Nice:) Do the service accounts need a valid email address?

[__ Jimi Wikman]

I love this @Kunwardeep Singh !
The EAP for service account sounds super exciting indeed!

I was wondering, have you considered a rate limiter functionality as in DC for Cloud?