Hardening existing Confluence for Internet deployment

Hello all. I'm looking for advice to pass on to our (outsourced) IT support. We have a LAN Confluence working already, with Internal (private) pages as well as 1 or 2 new Spaces we wish the public to see. For assorted reasons, we are considering shfiting this whole Confluence deployment to (say) a DMZ and locking it down, so that only the 2 'customer' Spaces are viewable by "the public" - but internal people will still have the same access to the other Spaces.

Is there a Guide on preparing our Confluence for this change? I'm thinking of what used to be called "hardening" of apps in Ye Olde Days :-) Any ideas welcomed. Thanks

4 answers

1 accepted

4 votes
Accepted answer

Hi David,

One idea I know other customers have used is to have a private wiki (which you already do) where the spaces for another instance of confluence, (public with anonymous access) is used as a publish site for those spaces. The publish add-on can be used, or space export/import can be used also:


The public wiki needs only an administrator, maybe a space admin or two, and then anonymous access for all your public users. This would keep the license count need to the 10 user seat not really adding a substancial cost ($10 which is donated straight to charity :) ).

Then there is no sensitive information in the public wiki, it can be placed in a DMZ area with no connections to your companies super-secret wiki and should be very easy to maintain with the add-on or using scheduled space export/import and some simple scripts.

Hope this helps!

Hi David,

I don't believe we have any documentation for this but one method would be to use a web server or proxy to limit access to certain parts of the wiki as a further hardenning against external threats from the DMZ. For example, I would have thought that you could use Apache to prevent users from hitting any parts of the wiki that you don't want them to be able to access but I'm sorry to say that my knowledge of Apache isn't sufficient to advise on the exact configurations to use but the access control options should point you in the right direction.

Confluence provides relatively few tools to protect itself against external threats, so I would strongly recommend that you implement the usual hardenning approaches using external components to mitigate the threat before it is able to access the application.

All the best,

Check permissions and make sure that edit for all users is off. ;)

Thanks again everyone. It seems the requirments are changing and we are now looking at a subset of the pages and using Confluence on Demand. Watch this Space (see what I did there?)

I'm not across the Karma system fully, so apologies if I haven't done the right thing via you kind people.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Dec 18, 2018 in Confluence Cloud

Happy holidays from our team to yours!

Hi Community!  2018 was filled with changes for our team, both big and small, and we've taken a lot of time to both celebrate our wins and recognize areas of improvement. One thing that we're a...

462 views 3 18
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you