Keep your team and content safe with IP allowlisting for Atlassian Premium

[#1]

The level of access and control enterprise companies need today to keep their teams and information safe in the cloud is paramount. And it’s no wonder, in 2019, over 4 billion records were exposed by data breaches—just in the first half of the year. As companies scale, the room for bad actors grows with it as you allow more employees, vendors, and contractors to have access to your systems.

To support our admins in proactively managing security at scale, and to keep our customers and their information safe, IP allowlisting is now generally available to all of our Jira Software, Confluence, and Jira Service Desk Premium customers.

Keep sites secure with IP allowlisting

After sifting through hundreds of pieces of feedback and meeting with dozens of admins who manage Atlassian products at scale, we know that our customers have stringent security requirements and need their products to only be accessible by trusted company networks.

In late May we launched a beta program for IP allowlisting, and we’re excited to announce that it’s now available to all Premium customers! IP allowlisting keeps teams and their content secure by ensuring that use of Atlassian Premium products are restricted to VPN and office networks, even for external collaborators, and allows secure access for content consumers.

Access from sanctioned company networks

The risk companies expose themselves to when users access their Jira and Confluence sites from unprotected networks can be high and costly. Now, enterprise and regulated organizations can require all end-users to access Atlassian products from sanctioned company networks. If you have agreements with your own customers about the security of their data, rest assured it won’t be leaving the building.

Secure your external collaborators

Outside of traditional user permissions controls, there is very little admins can do to protect their organization from risky usage of external collaborators. Admins can’t enforce SSO, two step verification, session duration, or password policies on these accounts the same way they can for managed accounts (ie accounts with email addresses from the verified domain). With IP allowlisting, admins get much needed relief with the confidence that product access is restricted to specific networks, even for external accounts.

To add and access your allowlists, please visit admin.atlassian.com > Security > IP allowlisting. From here, add up to 100 IP addresses or network blocks per allowlist.

Learn more about IP allowlisting from our public documentation page, or if you have any suggestions for insights you’d like to see in the future, please leave a comment below and we’ll investigate it for our roadmap!

New to Premium? Learn more here.

[Sachin]

Thank you for the post @Rak Garg ! This is great news.

[Lyndon Leong]

Thanks! @Rak Garg

[Taranjeet Singh]

This is a great security feature @Rak Garg ! Thanks for sharing this post. Is this feature going to be available for Atlassian Cloud Standard licensing as well?

[Kesha Thill]

Hey @Taranjeet Singh ! As of now, we only have plans to have this available in our Premium and Enterprise plans for Jira Software, Confluence, and Jira Service Desk.

[Glen Ritchie]

This is an insult to small business and until this comes to Standard and Free tiers, Cloud is not an option.

Basic security should be default, not a premium extra.

[WCI IT]

I don't disagree.  This seems like some basic level security yah'll.  Part of why we self host is to protect our data.  Since you are effectively forcing us to the cloud it seems like you should also provide some security so we can ensure our data is safe as a trade off.

[Bobby Bermudez]

I hope we can see this on the Standard plans as well.

[tcurtis]

@Rak Garg and @Kesha Thill here we are two years later and you have no response to a basic question?  Its not a hard one.  Why force users to the cloud to rip data security from them, yet have a solution, only to not allow that solution to be leveraged unless we pay for a "Premium" license...  Which for a small business is pretty damn Premium (AKA Expensive).

[tcurtis]

@Rak Garg @Kesha Thill @Taranjeet Singh 

Rak and Kesha -- How about a real answer?  Im not going away?  I think the community deserves a real answer as to why you would force us to the cloud then strip away a basic reason for self hosting only to add it in as a premium feature.  You know what we call that???  We call that a money grab, and as long as it remains unanswered  its despicable.  Atlassian makes a KILLING off of their customers, dont pretend you dont.  The problem is that that killing you make is framed by market quotes like "Subscription revenue grew faster, but that was offset by losses in legacy businesses."  You know why you lose legacy business???  Because YOU DONT, APPARENTLY, listen to your customers much.  I've seen stale topics and stale requests, and stale issues.  Stale security concerns are a problem.  There are all kinds of market indicators that make it pretty clear that you need to right your house and LISTEN to your customers.  PAY ATTENTION.

[Florian Edian]

Hi @Rak Garg!

Does the filtering works on anonymous access Confluence content?

Thanks,
Florian

[ROK]

@Florian Edian , just checked and no - it doesn't. What a shame - would have helped to make confluence spread out more within our company.

[eric_gagnon_banq]

From my own testing early 2024 anonymous space access are also blocked.

Also not documented as an exception here : https://support.atlassian.com/security-and-access-policies/docs/specify-ip-addresses-for-product-access/

[Tomislav Tobijas _Koios_]

I'm jumping in here just to confirm what @eric_gagnon_banq said - it seems that if you set anonymous access and IP allowlisting, those pages/spaces will also be unreachable unless you're on allowlisted IPs.

This is what it looks like if you try to open a 'public' space from a device using a public IP that is not listed in the IP allowlist configuration.

[eric_gagnon_banq]

Our use-case was that we have many employes that are using Confluence anonymously to access internal org procedures and guides we dont want to expose directly on internet. It would be prohibitive to give an account to all of these "reader" users.

A negative impact is that all the traffic of users that are working remotly need to go through vpn with a performance tax.

We also have the inconvenience of not being able to give access to users out of the org (something that we where not able to provide with our self-hosted server).

We could have done things differently (generating static sites?) but our goal was to complete the migration to cloud asap so it was a good enough solution.

[Tomislav Tobijas _Koios_]

Hah, like I'm looking at the mirror on this one:

Our use-case was that we have many employes that are using Confluence anonymously to access internal org procedures and guides we dont want to expose directly on internet. It would be prohibitive to give an account to all of these "reader" users.

A negative impact is that all the traffic of users that are working remotly need to go through vpn with a performance tax.

I have exactly the same case here 😅

I was thinking of alternative solutions such as guest accounts (although it depends on the number of paid seats), or just connecting everything with JSM and having all these things that need to be 'public' visible as knowledge base materials in the help center 🤔

Anyway, cheers for the insight @eric_gagnon_banq !