Jira Data Center - Encryption at Rest and Transit

[Alfredo Negrete]

Looking for information on how Jira Data Center handles data Encryption at Rest and Transit.  Most of the information I'm finding is on the cloud.

[Craig Davies]

That is totally up to you. If you've enabled TLS on the platform, that you host, then you have encryption in the transit.

If you've encrypted the storage, then you've got encryption at rest.

Self hosted means you define how you want the encryption to work.

[Alfredo Negrete]

Thanks

[Solomon Gifford]

For encryption in transit, use HTTPS with TLS 1.2 or higher and Perfect Forward Secrecy (PFS) enabled.  You'll want to also make sure that all outgoing calls (integrations) are also protected the same way.

Expanding on Metin Savignano's answer, the database is one that's often overlooked.  You need to enable SSL/TLS communication from the application to the database. 

For encryption at rest, this can be done at the container or filesystem layer with something like eCryptfs, at the machine layer with something like bitlocker, or at the storage layer by enabling encryption on the SAN.   Public cloud offerings like AWS have these options (see Jim Knepley's answer).

For customers that need secure Atlassian Datacenter hosting while they prepare to go to cloud, Valiantys Federal has offerings, including their FedRAMP SecureCloud.  (Disclaimer, I work for Valiantys).

[Metin Savignano]

This is a complex subject, and there are several levels and areas of description to consider.

Encryption at rest

Jira Data Center is provided as an application product. Like many similar self-hosted web applications, the product itself does not provide full encryption at rest; rather, the platform that Jira runs is expected to, if desired. When we speak of encryption at rest, the aspects we need to look at are

• database encryption 
• file system encryption
• hardware encryption

Database encryption isn't really an application-level requirement. For example, for PostgreSQL databases, there is PostgreSQL TDE that can provide a solution. Other databases will have similar solutions. Possibly it is enough to use Full Disk Encryption for the storage device your database resides on. It really depends on your threat model – what exactly do you want to be protected from.

Full disk encryption can also be used to encrypt the data on the machine that Jira runs on. It is usually an option of the operating system. Hardware encryption refers to the built-in encryption of HD and SDD storage itself.

Encryption in transit

Confidential data are transferred from and to Jira in multiple ways. What comes in our mind is the data transferred via the web, which should definitely be protected by TLS (i.e. by using https to access Jira). 

What tends to be overlooked is data transferred via email, like the notification emails that often contain confidential information, too. Jira can also receive and process incoming mail that may have the same issues. The minimum requirement must be to make sure that all involved mail servers enforce TLS connections to transfer the emails. However, please let me make you aware of the fact that TLS does not provide end-to-end-encryption from the perspective of the email itself which may remain unencrypted. The crucial part being that the emails will be stored unencrypted on the mail server (often for a long time). To address this aspect of encryption in transit, you need to additionally set up email encryption, for example by using the S/Notify Email Encryption for Jira app. Disclaimer: this app is provided by our company.

Eventually, it depends on the possible attack scenarios that you are looking at.

Feel free to ask back if questions remain.

[Jim Knepley - ReleaseTEAM]

Hi @Alfredo Negrete 

@Craig Davies is correct, encryption with Data Center products is up to you.

If you're hosting in AWS, it can be easier to build out a completely encrypted solution:

• Application Load Balancers (ALB) support modern TLS protocols and ciphers.
• You can encrypt the EBS volume that your EC2 instances are running on.
• RDS Aurora supports encrypting the database and TLS connections.
• EFS supports encrypting stored data and has a neat trick to encrypt NFS connections.
• AWS Backups of RDS and EFS can both be encrypted.

Beyond that, since VPC traffic is already encrypted by being a software-defined network, you almost don't need all the TLS stuff (but I use it anyway).