3 Solid Security Controls That Atlassian Uses To Protect 300,000+ Customers Data and Privacy
And What you can learn from
Cloud security isn’t just a feature, it’s a shared responsibility.
Atlassian secures the data of over 300,000+ enterprises across its cloud. But the real lesson isn’t just how Atlassian does it, it’s what you can borrow for your own architecture.
In this deep dive, we’ll look at the four patterns Atlassian relies on
Multi-tenant isolation with TCS(Tenant Context Service)
Encryption at Scale
Zero-trust IAM
Disclaimer: All technical details in this post are derived from Atlassian’s official documentation. All credit goes to the Atlassian Team. The links to the original articles and sources are present in the references section at the end of the post. I've attempted to analyse the details and provide my input about them. If you spot any inaccuracies or omissions, please leave a comment, and I will do our best to fix them.
Why Cloud Data Protection Needs Rethinking
As organizations scale, they don’t just accumulate users, they accumulate products and applications.
The average enterprise runs 100–200+ apps. Each new app multiplies the risk of
Inconsistent security policies across apps owned by different business units.
Shadow IT risks, where apps are procured and used without IT oversight.
Unauthorised access exposure, since more people, devices, and services are requesting access to critical data.
Atlassian argues that data protection can’t just focus on infrastructure—it must span people, apps, and automation.
1. Multi-tenant isolation with TCS(Tenant Context Service)
Atlassian serve cloud products to multiple customers through shared cloud-infrastructure via Multi-tenant architecture.
Multi-tenant SaaS models introduce a core risk: customer data crossing boundaries(Tenant).
Atlassian mitigates this with the Tenant Context Service (TCS).
TCS helps maintain data security so that data is isolated and inaccessible to other tenants with strict logical separation.
What TCS does ?
Assigns each tenant a unique ID.
Stores metadata
Which databases the tenant is in
What licenses the tenant has
What features they can access
Ensures every request to Jira or Confluence is tagged with the correct tenant ID.
When a customer accesses Jira or Confluence cloud, the TCS uses the tenant ID to collate that metadata.
If a micro-service malfunctions, it cannot accidentally query or expose another customer’s data.
This protects against cross-tenant data leakage.
2. Encryption at Scale
Atlassian secure customer data by encrypting it at rest and transit
In transit: TLS 1.2+ with PFS(Perfect Forward Secrecy)
At rest: AES-256 with AWS KMS
But encryption in Atlassian Cloud is more than just an at-rest and in-transit. It is layered system built on AWS Key Management Service (KMS).
AWS KMS Integration
All cryptographic keys used for encryption and decryption are managed through AWS KMS.
By design, these keys are backed by Hardware Security Modules (HSMs) , comply with NIST Cryptographic Module Validation Program (CMVP), ensuring that key storage and handling meet federal-grade standards.
Envelope Encryption
Atlassian applies envelope encryption across both data-in-transit and data-at-rest. For each service, unique data keys are created.
Access is governed through an implicit-deny model, meaning only explicitly authorized services can request encryption or decryption, thus preventing cross-service misuse of keys.
Disk and Volume Encryption
Volume or disk-level encryption is implemented wherever necessary, especially for resources like databases and object stores managed via AWS services.
Key Rotation for Reduced Attack Surface
Both master KMS keys and service-specific data keys are periodically rotated.
Data keys are subject to a dual threshold rotation policy: they are reissued after five million operations or 24 hours, whichever comes first.
This sharply reduces the potential blast radius if a key were ever compromised.
3. Zero Trust IAM
Identity is the new perimeter. Atlassian layers multiple IAM defenses to ensure both service-to-service authentication and user access management remain tightly controlled.
Here’s how Atlassian IAM Stack looks like -
Least privilege by default → Services can only access what their role permits (e.g., media content access must interact with Media Service API).
JWT-based service authentication → Every service call is signed and scoped, limiting the blast radius even if a token is compromised.
Tenant-aware data access → All requests to micorservices must include tenant metadata(context). If the context is missing, the request will be rejected.
ASAP (Atlassian Service Authentication Protocol) → An internal protocol that authenticates services using signed tokens. Combined with explicit service allowlists, it blocks lateral movement in the event of a compromised microservice.
References
Chat Soon,
-Kushal
❤️ Loved it? → Refer it to a friend or drop a ‘Like‘ below.
🥳 Just joined? → Start here: Ultimate Learning Guide for CyberSecurity Beginners.
💡 Have ideas? → Hit reply and tell me how I can make this more useful for you.