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
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!
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,
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.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
@Manon Soubies-Camy is an engineer who has been an avid Atlassian user since 2014. She helps companies of all sizes transform the way they work with the Atlassian stack, including Jira and Confl...
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!
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