Questions about Key management, Storage, IP restriction, and Encryption

[Volkan Kaya]

Hi,

Our initial questions for before we can consider your cloud option are as follows:

About access:

• Is it possible to enforce IP restriction for your cloud option?
• or, is it possible to enforce geo restriction for your cloud option?

About storage:

• How do you store attachments? if on disk, how do you protect them from access of Atlassian employees? Moreover, how do you make sure AWS employees does not have access to data?
• How do you make sure that no Atlassian employee can access to attachments or data any given time?

About Encryption:

• How do you protect encryption keys?
• How does your application consumes encryption keys?
• What happens if a key or key container is compromised?
• Does any Atlassian employee has access to customer keys?
• What happens if a key or key container is lost (by you or by customer)? how do you backup them, and how do you protect the backup? Who has access to backup? what is your procedure to restore the backup?
• What is the mode of AES-256 disk encryption?

About sensitive data:

• What is the main reason why customers cannot put sensitive data on your cloud option?
• for bitbucket: how do you make sure the source code of a application is accessible only by your customer?

Data classification:

• how do you enforce data classification?

About data residence:

• How do you make sure the of the customer data stays always in the required geo location?
• What is the recovery plan if the pinned DC is not accessible or has a disaster situation?

Once we have answer for our initial questions, we might ask further questions.

Kind Regards

[RJ Gazarek]

Hi @Volkan Kaya !  Just letting you know we see your question, your question spans multiple different people in our department, so we're working to gather those people to help answer, so we may be delivering the answers in parts as we enter, for example, I'll address your data residency questions.  Some of these questions we already have answered in our data management articles, so we'll point you to those to read since they're pretty thorough.  Hang tight!

[RJ Gazarek]

Hi @Volkan Kaya 

For your questions regarding the encryption, access control, backups, and general data protection: please have a look through this comprehensive security page on our Trust site:

• https://www.atlassian.com/trust/security/security-practices#keeping-data-secure 

I've directly linked to the part of the page regarding "keeping data secure" but there is a ton of information on that page on how we manage security and how seriously we take protecting your data. 

After you've had a read through that, if you have more questions that aren't answered on there, we'll do our best to answer them.  

With respect to control over your own user's access, like IP restriction, have a look at these pages:

• https://support.atlassian.com/organization-administration/docs/ip-addresses-and-domains-for-atlassian-cloud-products/
• https://www.atlassian.com/software/access
• https://support.atlassian.com/security-and-access-policies/docs/understand-atlassian-access/

Regarding your data residency question:

Have a look at our documentation currently on Data Residency, as it'll give you a good overview of what types of data we permanently store within the region.  

• https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency-and-realms/

On your question about why you can't store sensitive data in the cloud, that ultimately is a decision for you and your company.  In general, our policy is more about not having sensitive personal data stored in the cloud, because of how you have to control that data for your customers.  And ultimately, it's probably better for you to alter some of the work practice and have that data stored locally.  For example, if you're a healthcare company, rather than attaching a copy of a patient record to a confluence page or jira ticket, you should store that locally, and just have a local link on your confluence/jira page - so that you can always ensure who is accessing that specific highly sensitive data, and make sure that only your employees ever can access it and only from within the borders of your country.  If that's required by your local/country regulations.  

I think the links above cover most of what you're looking for, or asking.  If I've missed something, please let me know, or if you have follow up questions, let us know that too. 

[Filiberto Selvas]

Hello @Volkan Kaya , 

When you asked

"

• What is the main reason why customers cannot put sensitive data on your cloud option?

"

Are you referring in specific to the limitations placed by our terms of services?   If not I would appreciate if you can clarify 

[v.kaya]

Hi,

Yes I am referring in specific to the limitations placed by our terms of services.

I reduces Atlassian's liability in case something goes wrong, on the other hand it give impression that you can't guarantee protection of sensitive information.

It is little confusing.

[Ching Lee]

About Access:

• Is it possible to enforce IP restriction for your cloud option? 
  • We have IP allowlist feature for our cloud solution: https://support.atlassian.com/security-and-access-policies/docs/specify-ip-addresses-for-product-access/
• or, is it possible to enforce geo-restriction for your cloud option?
  • I am not quite sure what you mean by geo-restriction. Do you mean users can only access the Atlassian cloud from certain geos? In most cases, customers can make sure that the right access of data by enabling 2FA , or set up certain access control, or require users to access Atlassian Cloud via VPN. 

[v.kaya]

I understand, IP restriction (IP allowlisting in Atlassian terms) is a premium option. 

Geo-restriction is IP restriction based on a region.  For example company can reduce their jira implementation to be access only from let say Germany.

Although it is not as strict as IP restriction, geo-restriction can reduce attack possibility by bringing extra barrier that attacker or abuser must pass. 

[RJ Gazarek]

@v.kaya I don't think we offer geo-restriction, but honestly, it doesn't offer much security, since it's very easy to spoof your IP as coming from any country around the world with a very simple VPN connection.  Your best bet is to implement IP restriction, to make sure that connections are only being made from your company's network. 

[v.kaya]

from security point of view I do agree. From GDPR compliance perspective, geo-restriction can have added value on client side. by this data access can be only from EU.

[RJ Gazarek]

From a perception perspective that's probably true. In reality, anyone can just spoof their IP and access the data from anywhere in the world.  I still think in both cases your best bet is to have IP Whitelisting, and then making sure that employees who are traveling are VPN'd into your company's network (which is within the country) so they can access Jira/Confluence.  

Also I don't believe the GDPR says that data can't be accessed from outside the country ever, or that it can't leave the country ever, that would also be a very difficult thing to do given the way the internet works in general. 

[Ching Lee]

About storage:

• How do you store attachments? if on disk, how do you protect them from access of Atlassian employees? Moreover, how do you make sure AWS employees do not have access to data?
  • We have encryption at rest. That means all the attachments are encrypted with Atlassian encryption keys. If you are interested in bring-your-own-key encryption, please reach out to me. I can share our roadmap with you. 
• How do you make sure that no Atlassian employee can access attachments or data at any given time?
  • We have a lot of policies and tools in place to make sure that there is no unauthorized access to customer data. First, we will request consent from customers if we absolutely have to have access to their data in order to resolve support issues. We also have strict policies in place to make sure that we have extensive logging for any production data access. Feel free to reach out to us for more information in this area. 

[v.kaya]

to be able to give feedback on this, I need to have more information about the my questions about the encryption. 

[Ching Lee]

About Encryption:

• How do you protect encryption keys?
• How does your application consumes encryption keys?
• What happens if a key or key container is compromised?
• Does any Atlassian employee has access to customer keys?
• What happens if a key or key container is lost (by you or by customer)? how do you backup them, and how do you protect the backup? Who has access to backup? what is your procedure to restore the backup?
• What is the mode of AES-256 disk encryption?

Please Download this white paper. for more information. 

I will have to find experts in this area to fully answer your questions. 

[v.kaya]

This white paper is for managers and does not give detailed information about how encryption of sensitive data works. 

If I can get more technical information I can give better feedback for this section.

[RJ Gazarek]

Hi Kaya - did you read through our Trust and Security page that I linked above? https://www.atlassian.com/trust/security/security-practices#encryption-of-data 

[RJ Gazarek]

@v.kaya another area you can look for answers is in our CSA: https://cloudsecurityalliance.org/star/registry/atlassian/

[v.kaya]

I read your security policies, however there is nowhere you explain how jira handles encryption and decryption of attachments. if it is only disk encryption, anyone who has access to OS has access to the files, so disk encryption does not protect the files from atlassian access.

[RJ Gazarek]

Oh correct, as with any cloud vendor, there are always people within the company that CAN access the data.  However, our data access policies are extremely strict, monitored, and logged - and we only access your data if you give us permission to do so, for instance in the event of a support ticket where you need help doing something in the product.  On our trust page, we talk about this here: https://www.atlassian.com/trust/security/security-practices#controlling-access-to-customer-data

I'd encourage you to go through the trust/security page I've been linking and read it all from top to bottom.  A lot of your questions are answered there, and then if there are further questions beyond that, I'll see if we can find some answers for you. 

[RJ Gazarek]

Additionally, as Ching mentioned earlier, we are looking to bring BYOK to our products, where you would be managing the encryption key.  So even though we still have access to the data, you control the key.  If you're interested in that, let Ching know!