Atlassian Cloud Data Architecture
- Kwang Seob Jeong
How data is stored
With AWS, we have availability zones (AZ) in multiple regions worldwide. The multi-zone high availability is the first line of defense for geographic and environmental risks. Jira and Confluence data is located in the region closest to where the majority of your users are located upon sign-up. We currently offer data residency in the US and EU regions, as well as Australia, with plans to add additional regions.
We use the snapshot feature of Amazon Relational Database Service (RDS) to create automated daily backups of each RDS instance. Amazon RDS snapshots are retained for 30 days with support for point-in-time recovery and encrypted with AES-256 encryption. Backup data is stored and replicated to multiple data centers within a particular AWS region.
Learn more about our cloud infrastructure.
How data flows
We host a number of platform and product services that are used across our solutions. This includes platform capabilities that are shared across multiple Atlassian products, such as Media and Identity, and experiences such as our Editor, and product-specific capabilities, like Jira Issue service and Confluence Analytics. Typically, an Atlassian product consists of multiple "containerized" services that are deployed on AWS using Micros.
On top of our cloud infrastructure, we built and operate a multi-tenant micro-service architecture. In a multi-tenant architecture, a single service serves multiple customers, including databases and compute instances required to run our cloud products. Each shard (essentially a container) contains the data for multiple tenants, but each tenant's data is isolated and inaccessible to other tenants. It is important to note that we do not offer a single-tenant architecture.
While our customers share a common cloud-based infrastructure when using our cloud products, we have measures in place to ensure they are logically separated so that the actions of one customer cannot compromise the data or service of other customers.
Learn more about our cloud platform architecture.
As a company with a global customer base and operations, Atlassian must be able to transfer and access data around the world. We comply with the General Data Protection Regulation (GDPR) and offer customers a robust international data transfer framework as part of our Data Processing Addendum to ensure lawful data transfer outside of the European Economic Area (EEA).
Atlassian is also committed to protecting customer data privacy and rights by only responding to law enforcement requests after a comprehensive legal review. We publish an annual Transparency Report about government requests for users' data.
Learn more about our GDPR compliance and Privacy Policy.
How data is secured
Since we leverage a multi-tenant architecture, we can layer additional security controls into the decoupled application logic. We’ve also built additional preventative controls into our products that are fully hosted on our Atlassian platform. The primary preventative controls include:
Service authentication and authorization
Tenant context service
Key management
Data encryption
Our platform uses a least privilege model for accessing data. This means that all data is restricted to only the service responsible for saving, processing, or retrieving it. For example, the media services, which allow you to have a consistent file upload and download experience across our cloud products, have dedicated storage provisioned that no other services at Atlassian can access. Any service that requires access to the media content needs to interact with the media services API. As a result, strong authentication and authorization at the service layer also enforces strong separation of duties and least privilege access to data. We use JSON web tokens to ensure signing authority outside of the application, so our identity systems and tenant context are the source of truth. Tokens can’t be used for anything other than what they are authorized for.
The tenant context service (TCS) ensures requests to any microservices contain metadata about the customer - or tenant - that is requesting access. Service authentication and authorization is applied, where an explicit allowlist determines which services may communicate and authorization details specify which commands and paths are available. This limits potential lateral movement of a compromised service. Your data is also safeguarded through something that we call an edge - virtual walls that we build around our software. When a request comes in, it is sent to the nearest edge. Through a series of validations, the request is either allowed or denied.
At Atlassian, we use the AWS Key Management Service (KMS) for key management. To further ensure the privacy of your data, KMS is the originator and secret store for these keys. An owner is assigned for each key and is responsible for ensuring the appropriate level of security controls is enforced on keys. Atlassian-managed keys are rotated upon relevant changes of roles or employment status. Soon, we will offer bring your own key (BYOK) encryption, giving you the ability to encrypt your cloud product data with self-managed keys in AWS KMS.
Customer data in our Atlassian cloud products is encrypted in transit over public networks using TLS 1.2+ with perfect forward secrecy (PFS) to protect it from unauthorized disclosure or modification. Data drives on AWS servers holding customer data and attachments use full disk, industry-standard AES-256 encryption at rest. PII transmitted using a data-transmission network are subject to appropriate controls designed to ensure that data reaches its intended destination.
Learn more about security controls.
Ref