Best Practices for Configuring Confluence Security

This page outlines a number of approaches you can use to make your Confluence site as secure as possible. There are many things to consider, such as the configuration of your underlying operating systems, application servers, database servers, network, firewall, routers, etc. It would be impossible to outline all of them here.

On this page:

Best practices

Not everything in this guide will be applicable to your environment, but the principles described can be adapted to most environments.

It's worth noting that none of these practices can provide 100% security. They are measures to reduce impact and to slow down an intruder in case your system does become compromised.

Subscribe to advisory alerts

Subscribe to advisory alerts and keep technical contact details up to date to make sure you receive security advisory alerts and other important technical updates. 

Atlassian email and privacy preferences 

Secure your installation and data directories

It's important to make sure your Confluence installation directory, home directory, and any storage locations you may define for attachments, space exports, or data pipeline exports are secure. 

We strongly recommend you:

  • run Confluence with a dedicated non-root user account.
  • limit the user accounts who can access any Confluence directories. 

To find out how to do this, see Creating a Dedicated User Account on the Operating System to Run Confluence

You should also monitor your binaries. If an attacker compromises an account on your system, they will usually try to gain access to more accounts. This is sometimes done by adding malicious code, such as by modifying files on the system. Consider how you might regularly verify that no malicious changes have been made.

Secure your database

Make sure the Confluence database user (and all datasource database users) only have the amount of database privilege they really need.

Limit database access to just the Confluence host (using iptables or built in database security tools). Refer to your database documentation to find out how to do this.

Limit access to administrator functions

As a general rule, you should keep the number of Confluence administrators as low as possible, and review these user accounts every so often to make sure the access level is still appropriate. 

  • Avoid shared administrator or user accounts, and easily guessed usernames like 'admin'.
      
  • Provide administrators with two separate accounts, to allow them to separate day-to-day work such as creating pages, from administration tasks.

  • Limit the number of people in the confluence-administrators group. Members of this 'super group' can access all admin functions and access all content, including restricted pages. Consider limiting the members of this group and instead create a new group with system administrator global permissions. 
    Learn about the confluence-administrators super group
     
  • Use secure administrator sessions to require admins to re-enter their password to access admin functions, and set a short timeout for the administrator session. 
    Learn how to turn on secure administrator sessions
     
  • Use Apache to lock down the administration interface to specific IP addresses. This can be used as a template for your reverse proxy of choice.
    Using Apache to limit access to the Confluence administration interface.

Limit incoming and outgoing connections

There are a number of ways you can limit incoming and outgoing connections, including using firewalls and proxy servers. 

  • Use the allowlist to limit incoming and outgoing connections to avoid Server-Side Request Forgery (SSRF) attacks. Confluence relies on the allowlist for things like macros, that may be displaying content from external sites. 
    Learn how to turn on the allowlist

Manage user accounts

Good user management practices can help prevent user accounts being compromised. 

  • Consider integrating Confluence with an identity provider for single sign-on and two-factor authentication.
    Learn about the various SSO options available
     
  • Disable user accounts when people leave your organisation. If required, you can also delete user accounts which will replace their name with an anonymized ID.  
    Delete and disable users
     
  • Restrict the number of users with powerful roles or group memberships. If only one department should have access to particularly sensitive data, then restrict access to the data to only those users. Do not let convenience over-rule security. Do not give all staff access to sensitive data when there is no need.
     
  • Use personal access tokens for integrations. This provides your users a more secure way to authenticate API requests than basic authentication (username and password)
    Learn how to manage personal access tokens

Limit login attempts and monitor access and activity

There are several things you can do to reduce the risk of brute force or denial of service attacks. 

Perform regular security audits

Regular security audits can help you identify potential threats, and also provide an opportunity to review your security policies and procedures. 

  • Know who can help if a security breach occurs. What is the process if a potential threat is identified?
     
  • Perform 'what if' planning exercises. Consider questions like 'What is the worst thing that could happen if a privileged user's password were stolen while on vacation? What can we do to minimize damage?'.
     
  • Document your security measures, and regularly monitor that all measures are still in place, and are adequate. For example after upgrading or migrating, someone may forget to apply the rule to the new system or version. 
     
  • Perform a security check-up when preparing for a major upgrade. It's a good time to check your current configuration against our current recommendations. 
Last modified on Aug 17, 2021

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.