Close
Diese Seite in deiner Sprache anzeigen?
Alle Sprachen
Sprache auswählen
Atlassian Cloud

Atlassian Cloud-Architektur und betriebliche Praktiken

Erfahre mehr über die Atlassian Cloud-Architektur und die von uns verwendeten betrieblichen Praktiken

Inhaltsverzeichnis

Einführung

Atlassian cloud apps and data are hosted on industry-leading cloud provider Amazon Web Services (AWS). Our products run on a platform as a service (PaaS) environment that is split into two main sets of infrastructure that we refer to as Micros and non-Micros. Jira, Confluence, Jira Product Discovery, Statuspage, Guard, and Bitbucket run on the Micros platform, while Opsgenie and Trello run on the non-Micros platform.

Cloud-Infrastruktur

Atlassian Cloud-Hosting-Architektur

Wir nutzen Amazon Web Services (AWS) als Cloud-Serviceanbieter und seine hochverfügbaren Rechenzentrumseinrichtungen in mehreren Regionen weltweit. Jede AWS-Region ist ein separater geografischer Standort mit mehreren, isolierten und physisch getrennten Gruppen von Rechenzentren, den sogenannten Availability Zones (AZs).

Wir nutzen die Rechen-, Speicher-, Netzwerk- und Daten-Services von AWS, um unsere Produkte und Plattformkomponenten zu entwickeln, wodurch wir die von AWS angebotenen Redundanzfunktionen wie Availability Zones und Regionen nutzen können.

Verfügbarkeitszonen

Die Availability Zones sind durch ihr Design weitgehend vor Ausfällen geschützt und gegenüber den anderen Zonen isoliert. Sie sind über ein kostengünstiges, latenzarmes Netzwerk mit anderen Availability Zones in derselben Region verbunden. Diese Hochverfügbarkeit in mehreren Zonen stellt die erste Verteidigungslinie gegen geografische und umgebungsbedingte Risiken dar und sorgt dafür, dass ein Service, der in Deployments mit mehreren Availability Zones ausgeführt wird, den Ausfall einer Availability Zone problemlos übersteht.

Jira und Confluence nutzen den Deployment-Modus in mehreren Verfügbarkeitszonen für Amazon RDS (Amazon Relational Database Service). In einem derartigen Deployment stellt Amazon RDS ein synchrones Standby-Replikat in einer anderen Verfügbarkeitszone der gleichen Region bereit, um Redundanz und Failover-Funktionalität zu gewährleisten. Das Failover der Verfügbarkeitszone ist automatisiert und dauert in der Regel 60 bis 120 Sekunden, sodass Datenbankoperationen so schnell wie möglich ohne Administratoreingriff wieder aufgenommen werden können. Opsgenie, Statuspage, Trello und Jira Align verwenden ähnliche Deployment-Strategien, wobei es beim Replikat- und Failover-Timing geringfügige Abweichungen gibt.

Datenstandort

Jira- und Confluence-Daten sind der Region am nächsten, in der sich die Mehrheit deiner Benutzer angemeldet hat. Die Bitbucket-Daten befinden sich in zwei unterschiedlichen Availability Zones in der Region USA Ost.

Uns ist jedoch bewusst, dass einige von euch Daten an einem bestimmten Ort aufbewahren müssen, daher bieten wir Datenresidenz-Optionen an. Derzeit ist die Datenresidenz für Jira, Jira Service Management, Jira Product Discovery und Confluence in 11 Regionen verfügbar, darunter die USA, die EU, Großbritannien, Australien, Kanada, Deutschland, Indien, Japan, Singapur, Südkorea und die Schweiz. In unserer Dokumentation erfährst du mehr über Datenresidenz und welche Produktdaten darunter fallen. Zusätzlich kannst du unserer Roadmap folgen, um über das Thema Datenresidenz und Erweiterungen um neue Produkte, Regionen und Datentypen auf dem Laufenden zu bleiben.

Daten-Backups

We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our cloud apps, and specifically referring to you and your application data, we also have extensive backup measures in place. We use the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.

Amazon RDS-Snapshots werden 30 Tage lang aufbewahrt. Sie unterstützen die zeitpunktspezifische Wiederherstellung (Point-in-Time Recovery) und sind mit dem AES-256-Standard verschlüsselt. Die Backup-Daten werden nicht extern gespeichert, sondern in mehreren Rechenzentren innerhalb einer bestimmten AWS-Region repliziert. Zudem werden unsere Backups alle drei Monate getestet.

Für Bitbucket werden Speicher-Snapshots 7 Tage lang aufbewahrt. Die zeitpunktspezifische Wiederherstellung (Point-in-Time Recovery) wird unterstützt.

We don’t use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted work items, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product.

Sicherheit im Rechenzentrum

AWS verfügt über mehrere Zertifizierungen zum Schutz seiner Rechenzentren. Diese Zertifizierungen beziehen sich auf die physische Sicherheit und die Umgebungssicherheit, die Systemverfügbarkeit, den Netzwerk- und IP-Backbone-Zugriff, die Kundenbereitstellung und das Problemmanagement. Der Zugang zu den Rechenzentren ist auf autorisiertes Personal beschränkt und wird durch biometrische Identitätsprüfungen kontrolliert. Vor Ort sorgen außerdem Wachpersonal, Videoüberwachungsanlagen, Zugangsschleusen und weitere Einbruchsschutzmaßnahmen für Sicherheit.

Architektur der Cloud-Plattform

Architektur für verteilte Services

With this AWS architecture, we host a number of platform and product services that are used across our solutions. This includes platform capabilities that are shared and consumed across multiple Atlassian products, such as Media, Identity, and Commerce, experiences such as our Editor, and product-specific capabilities, like Jira Work Item service and Confluence Analytics.

Architektur der Atlassian-Plattform

Abb. 1

Atlassian-Entwickler stellen diese Services entweder über Kubernetes oder eine intern entwickelte Platform as a Service (PaaS) namens Micros bereit, die automatisch die Bereitstellung von Shared Services, Infrastruktur, Datenspeichern und deren Verwaltungsfunktionen, einschließlich Sicherheits- und Compliance-Kontrolle, orchestriert (siehe Abbildung 1 oben). Typischerweise besteht ein Atlassian-Produkt aus mehreren "containerisierten" Services, die mithilfe von Micros oder Kubernetes auf AWS bereitgestellt werden. Atlassian-Produkte verwenden Kernplattformfunktionen (siehe Abbildung 2 unten), die vom Anforderungsrouting bis hin zu binären Objektspeichern, Authentifizierung/Autorisierung, transaktionalen benutzergenerierten Inhalten (UGC) und Entitätsbeziehungsspeichern, Data Lakes, allgemeiner Protokollierung, Anforderungsablaufverfolgung, Beobachtbarkeits- und Analyseservices reichen. Diese Microservices basieren auf genehmigten technischen Stacks, die auf Plattformebene standardisiert sind:

Überblick über Atlassian-Microservices

Abb. 2

Mehrmandantenarchitektur

On top of our cloud infrastructure, we built and operate a multi-tenant micro-service architecture along with a shared platform that supports our products. In a multi-tenant architecture, a single service serves multiple customers, including databases and compute instances required to run our cloud apps. Each shard (essentially a container – see figure 3 below) 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.

Speicherung von Daten in einer Mehrmandantenarchitektur

Abb. 3

Unsere Microservices basieren auf dem Prinzip der geringsten Rechte und sollen die Tragweite von Zero-Day-Exploits einschränken, um die laterale Verbreitung innerhalb unserer Cloud-Umgebung zu reduzieren. Jeder Microservice verfügt über seinen eigenen Datenspeicher, auf den nur mithilfe eines Authentifizierungsprotokolls für diesen spezifischen Service zugegriffen werden kann. Das bedeutet, dass kein anderer Service Lese- oder Schreibzugriff auf diese API hat.

Wir haben uns auf die Isolation von Microservices und Daten konzentriert, anstatt jedem Mandanten eine fest zugeordnete Infrastruktur zur Verfügung zu stellen. Denn dies würde für viele Kunden den Zugriff auf den engen Datengeltungsbereich eines einzelnen Systems begrenzen. Die Entkopplung der Logik und die Datenauthentifizierung und -autorisierung auf der Anwendungsebene dienen als zusätzlicher Sicherheitskontrollpunkt, wenn Anforderungen an diese Services gesendet werden. Wenn daher ein Microservice kompromittiert wird, bleibt der erlangte Zugriff auf die Daten beschränkt, die ein bestimmter Service benötigt.

Bereitstellung und Lebenszyklus von Mandanten

Wenn ein neuer Kunde bereitgestellt wird, löst eine Reihe von Ereignissen die Orchestrierung verteilter Services und die Bereitstellung von Datenspeichern aus. Diese Ereignisse können im Allgemeinen einem von sieben Schritten im Lebenszyklus zugeordnet werden:

1. Commerce-Systeme werden sofort mit den neuesten Metadaten und Zugriffskontrollinformationen für diesen Kunden aktualisiert. Anschließend richtet ein Bereitstellungs-Orchestrierungssystem den "Status der bereitgestellten Ressourcen" durch eine Reihe von Mandanten- und Produktereignissen auf den Lizenzstatus aus.

Mandantenereignisse

Diese Ereignisse betreffen den gesamten Mandanten. Sie können sich auf eines der folgenden Szenarien beziehen:

  • Erstellung: ein Mandant wird erstellt und für brandneue Sites verwendet
  • Zerstörung: ein ganzer Mandant wird gelöscht

Produktereignisse

  • Aktivierung: nach der Aktivierung von lizenzierten Produkten oder Apps von Drittanbietern
  • Deaktivierung: nach der Deaktivierung bestimmter Produkte oder Apps
  • Aussetzung: nach der Aussetzung eines bestimmten vorhandenen Produkts, wodurch der Zugriff auf eine bestimmte Site deaktiviert wird
  • Aufheben der Aussetzung: nach der Aufhebung der Aussetzung eines bestimmten vorhandenen Produkts, wodurch der Zugriff auf eine Site ermöglicht wird
  • Lizenzaktualisierung: enthält Informationen zur Anzahl der Arbeitsplatzlizenzen für ein bestimmtes Produkt sowie dessen Status (aktiv/inaktiv)

2. Erstellung der Kunden-Site und Aktivierung der richtigen Produktauswahl für den Kunden. Das Konzept einer Site ist ein Container für mehrere Produkte, die für einen bestimmten Kunden lizenziert sind (z. B. Confluence und Jira Software für .atlassian.net).

Überblick über den Site-Container

Abb. 4

3. Bereitstellung von Produkten auf einer Kunden-Site in der angegebenen Region.

Wenn ein Produkt bereitgestellt wird, wird der Großteil seines Inhalts in der Nähe des Zugriffsorts der Benutzer gehostet. Um die Produktleistung zu optimieren, schränken wir die Datenbewegung nicht ein, wenn ein Inhalt weltweit gehostet wird. Wir können Daten nach Bedarf zwischen Regionen verschieben.

Für einige unserer Produkte bieten wir auch Datenresidenz an. Datenresidenz ermöglicht es Kunden, zu wählen, ob Produktdaten weltweit verteilt oder an einem unserer definierten geografischen Standorte gespeichert werden.

4. Erstellung und Speicherung der Kunden-Site und der Kernmetadaten und Konfiguration der Produkte.

5. Erstellung und Speicherung der Site und Produktidentitätsdaten wie Benutzer, Gruppen, Berechtigungen usw.

6. Bereitstellung von Produktdatenbanken innerhalb einer Site, z. B. Jira-Produktfamilie, Confluence, Compass und Atlas.

7. Bereitstellung von lizenzierten Apps für das Produkt/die Produkte.

Überblick über die Bereitstellung einer Kunden-Site in unserer verteilten Architektur

Abb. 5

Abbildung 5 oben zeigt, wie die Site eines Kunden in unserer verteilten Architektur bereitgestellt wird, nicht nur in einer einzigen Datenbank oder einem Speicher. Dazu gehören mehrere physische und logische Speicherorte, an denen Metadaten, Konfigurationsdaten, Produktdaten, Plattformdaten und andere zugehörige Site-Informationen gespeichert werden.

Mandantentrennung

While our customers share a common cloud-based infrastructure when using our cloud apps, 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.

Je nach Anwendung verfolgt Atlassian hier unterschiedliche Ansätze. Im Fall von Jira und Confluence Cloud setzen wir auf das Konzept "Tenant Context" (Mandantenkontext), um Kunden logisch zu isolieren. Umgesetzt wird es im Anwendungscode und verwaltet über den von uns entwickelten TCS (Tenant Context Service). Das Konzept stellt Folgendes sicher:

  • Die ruhenden Daten jedes Kunden werden logisch getrennt von denen der anderen Mandanten aufbewahrt.
  • Alle Anfragen, die über Jira oder Confluence verarbeitet werden, verfügen über eine mandantenspezifische Ansicht, sodass andere Mandanten davon nicht betroffen sind.

Vereinfacht gesagt speichert der TCS für die einzelnen Mandanten der Kunden einen Kontext. Der Kontext für jeden Mandanten ist mit einer eindeutigen ID verknüpft, die zentral vom TCS gespeichert wird, und enthält eine Reihe von Metadaten, die mit diesem Mandanten verknüpft sind. Diese enthalten z. B. Informationen dazu, in welchen Datenbanken sich der Mandant befindet, welche Lizenzen der Mandant hat, auf welche Funktionen er zugreifen kann sowie eine Reihe anderer Konfigurationsinformationen. Wenn ein Kunde auf Jira oder Confluence Cloud zugreift, stellt der TCS die Metadaten anhand der Mandanten-ID zusammen und verknüpft diese dann mit allen Aktionen, die der Mandant im Sitzungsverlauf in der Anwendung vornimmt.

Atlassian-Edges

Ihre Daten werden außerdem durch etwas geschützt, das wir als Edge bezeichnen. Das sind virtuelle Wände, die wir um unsere Software herum errichten. Wenn eine Anfrage eingeht, wird sie an den nächstgelegenen Edge gesendet. Über verschiedene Validierungsverfahren wird die Anfrage entweder zugelassen oder abgelehnt.

  • Sie kommt bei dem Atlassian-Edge an, der dem Benutzer am nächsten ist. Der Edge überprüft die Sitzung und Identität des Benutzers mithilfe deines Identitätssystems.
  • Der Edge ermittelt anhand von Daten in den TCS-Informationen, wo sich deine Produktdaten befinden.
  • Er leitet die Anfrage an die Zielregion weiter, wo sie zu einem Rechenknoten gelangt.
  • Der Knoten verwendet das Mandantenkonfigurationssystem, um Informationen wie die Lizenz und den Datenbankort zu ermitteln, und fragt verschiedene andere Datenspeicher und Services (z. B. die Medienplattform, die Bilder und Anhänge hostet) nach Daten ab, die für die Bearbeitung der Anfrage erforderlich sind.
  • Die ursprüngliche Benutzeranfrage erhält dann Informationen, die aus früheren Abfragen anderer Services zusammengetragen wurden.

Sicherheitskontrollen

Because our cloud apps leverage a multi-tenant architecture, we can layer additional security controls into the decoupled application logic. A per-tenant monolithic application wouldn’t typically introduce further authorization checks or rate limiting, for example, on a high volume of queries or exports. The impact of a single zero-day is dramatically reduced as the scope of services are narrowed.

Daneben haben wir weitere vorbeugende Kontrollen in unsere Produkte integriert, die vollständig auf unserer Atlassian-Plattform gehostet werden. Zu den primären vorbeugenden Kontrollen zählen:

  • Authentifizierung und Autorisierung von Services
  • Tenant Context Service
  • Schlüsselmanagement
  • Datenverschlüsselung

Authentifizierung und Autorisierung von Services

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 allows you to have a consistent file upload and download experience across our cloud apps, 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.

Wir verwenden JWTs (JSON-Web-Token), um die Signaturberechtigung außerhalb der Anwendung sicherzustellen und damit unsere Identitätssysteme und den Mandantenkontext zur zentralen Informationsquelle zu machen. Token dürfen ausschließlich für die Zwecke verwendet werden, für die sie autorisiert sind. Wenn von dir oder jemandem in deinem Team ein Microservice oder Shard abgerufen wird, werden die Token an dein Identitätssystem übermittelt und verglichen. Durch diesen Prozess wird sichergestellt, dass das Token aktuell und signiert ist, bevor die entsprechenden Daten freigegeben werden. Sollte ein Service kompromittiert werden, begrenzen diese Autorisierungs- und Authentifizierungsregeln für den Zugriff auf Microservices den Schaden deutlich.

Natürlich wissen wir, dass Identitätssysteme manchmal kompromittiert werden können. Um dieses Risiko zu mindern, wenden wir zwei Mechanismen an. Zum einen sind der TCS und die Identitätsproxys hochgradig repliziert. Wir haben ein TCS-Sidecar für fast jeden Microservice und verwenden Sidecar-Proxys, die sich von der Identitätsautorität ableiten, sodass mehrere Tausend dieser Services gleichzeitig ausgeführt werden. Falls in einem oder mehreren Services anormales Verhalten auftritt, können wir dieses schnell erkennen und das Problem beheben.

Darüber hinaus warten wir nicht darauf, dass jemand eine Schwachstelle in unseren Produkten oder unserer Plattform entdeckt. Wir identifizieren diese Szenarien aktiv, damit sie nur minimale Auswirkungen auf dich haben. Zudem laufen eine Reihe von Sicherheitsprogrammen, damit Sicherheitsbedrohungen erkannt, gefunden und entsprechende Maßnahmen eingeleitet werden können.

Tenant Context Service

Wir stellen sicher, dass Anfragen an Microservices Metadaten zu dem Kunden oder Mandanten enthalten, der den Zugriff anfordert. Dieser Vorgang wird als Tenant Context Service bezeichnet. Die Informationen hierfür kommen direkt aus unseren Bereitstellungssystemen. Wenn eine Anfrage gestartet wird, wird der Kontext im ausgeführten Servicecode, der zur Autorisierung des Benutzers verwendet wird, gelesen und internalisiert. Sämtliche Service- und damit Datenzugriffe in Jira und Confluence erfordern diesen Mandantenkontext, andernfalls wird die Anfrage abgelehnt.

Die Authentifizierung und Autorisierung von Services erfolgt über ASAP (Atlassian Service Authentication Protocol). Eine explizite Positivliste legt fest, welche Services kommunizieren dürfen, und Autorisierungsdetails geben an, welche Befehle und Pfade verfügbar sind. Auf diese Weise werden laterale Bewegungen bei der Kompromittierung eines Service eingeschränkt.

Die Authentifizierung und Autorisierung von Services sowie der Ausgang werden von diversen fest zugeordneten Proxys gesteuert. Auf diese Weise haben Schwachstellen im Anwendungscode keinen negativen Einfluss auf diese Kontrollen. Für die Remotecodeausführung wäre die Kompromittierung des zugrunde liegenden Hosts und die Umgehung von Docker-Containergrenzen erforderlich, nicht nur die Möglichkeit, die Anwendungslogik zu ändern. Stattdessen markiert unsere Angriffserkennung auf Hostebene Diskrepanzen.

Diese Proxys beschränken das Ausgangsverhalten basierend auf dem beabsichtigten Verhalten des Service. Services, die keine Webhooks aussenden oder mit anderen Microservices kommunizieren müssen, wird dies untersagt.

Datenverschlüsselung

Customer data in Atlassian cloud apps is encrypted during transmission utilizing TLS 1.2 or higher, incorporating perfect forward secrecy (PFS) to safeguard against unauthorized information disclosure and data modification. We adhere to NIST-recommended TLS 1.2+ protocols, which enforce the use of strong ciphers and key lengths as supported by the browser.

Kundendaten, einschließlich Anhängen, die in Cloud-Services wie Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie und Trello gespeichert sind, werden im Ruhezustand mit der branchenüblichen AES-256-Verschlüsselung geschützt.

Die Übertragung personenbezogener Daten (PII) wird durch Verschlüsselung und robuste Datenzugriffskontrollen geschützt. So wird sichergestellt, dass Daten sicher an ihren Bestimmungsort übertragen werden. In der Richtlinie zur Kryptografie und Verschlüsselung von Atlassian werden die Prinzipien für die Implementierung von Verschlüsselung und Kryptografie aufgeführt, um Risiken im Zusammenhang mit der Speicherung und Übertragung von personenbezogenen Daten zu minimieren. Die Verschlüsselungsalgorithmen zum Schutz personenbezogener Daten entsprechen der Klassifizierungsstufe der PII gemäß dem internen Datensicherheits- und Informationslebenszyklus-Management von Atlassian. Dadurch wird sichergestellt, dass vertrauliche Daten auf der Grundlage ihrer Klassifizierung angemessen geschützt sind. Wie wir Kundendaten sammeln, teilen und verwenden, kannst du auf unserer Seite zum Datenschutz nachlesen.

Wenn du über zusätzliche Datenverschlüsselungsfunktionen auf dem Laufenden bleiben möchtest, wirf einen Blick in unsere Cloud-Roadmap.

Verwaltung kryptografischer Schlüssel

Atlassian Cloud nutzt AWS Key Management Service (KMS) zur Verwaltung kryptografischer Schlüssel, die für die Datenverschlüsselung und -entschlüsselung verwendet werden. Diese KMS-Schlüssel sind durch Schlüsselmaterialien gesichert, die in Hardware-Sicherheitsmodulen (HSMs) gespeichert sind, die durch das NIST Cryptographic Module Validation Program validiert wurden. Der Secure-by-Design-Ansatz von AWS KMS mit FIPS-validierten HSMs bietet hohe Sicherheit bei der Schlüsselverwaltung. Dadurch wird verhindert, dass AWS- oder Atlassian-Mitarbeiter Klartext-Schlüsselmaterialien in KMS oder den HSMs abrufen können.

Die Envelope-Verschlüsselung wird auf Daten während der Übertragung und auf gespeicherte Daten angewendet. Für jeden Dienst werden Datenschlüssel erstellt, und nur die autorisierten Dienste dürfen im Rahmen einer impliziten Verweigerung verschlüsseln oder entschlüsseln. Die Datenschlüssel werden dann zum Schutz "umhüllt" (durch die entsprechenden KMS-CMK-Ressourcen verschlüsselt).

Die Verschlüsselung auf Datenträger- oder Festplattenebene wird nach Bedarf implementiert, insbesondere für Ressourcen wie Datenbanken und Objektspeicher, die direkt über AWS-verwaltete Dienste verwaltet werden. Die für diese Verschlüsselung verwendeten kryptografischen Schlüssel werden von denselben HSM-Quellen bereitgestellt und geschützt.

Sowohl KMS-Schlüssel als auch Datenschlüssel werden regelmäßig rotiert, um Angriffsflächen zu minimieren. Wenn ein KMS-Schlüssel rotiert wird, können die vorhandenen Datenschlüssel, die mit den alten oder vorherigen Versionen der KMS-Schlüssel verschlüsselt wurden, nur mit den alten KMS-Schlüsseln entschlüsselt werden. In der Zwischenzeit werden alle neuen Datenschlüssel, die nach der KMS-Schlüsselrotation erstellt werden, mit der neuen, aktiven Version des KMS-Schlüssels verschlüsselt und entschlüsselt. Die Verwaltung der Datenschlüsselrotation wird durch Nutzungsbeschränkungen geregelt, die als maximale Betriebsdauer oder maximale Nutzungsdauer (TTL) angegeben werden können. Zum Beispiel kann ein Datenschlüssel nach Erreichen von fünf Millionen Operationen oder nach 24 Stunden rotiert werden, je nachdem, was zuerst eintritt. Multiregionale KMSs und sichere Schlüsselcaches werden implementiert, um eine hohe Verfügbarkeit und das gewünschte Leistungsniveau zu erreichen.

Weitere Informationen findest du in diesem Blog.

Customer-managed keys (CMK)

To give you greater control over the encryption of your Atlassian app data, we are gradually rolling out Customer-managed keys (CMK), our most advanced encryption offering, to eligible customers. CMK is an encryption key model that allows you to create and manage cryptographic keys in your own AWS KMS account, so that you can encrypt and decrypt app data at rest in the Atlassian cloud. It provides additional visibility and control over encryption key management without introducing performance overhead or negatively impacting user experience. This is due to the efficient, secure caching mechanism employed by Atlassian systems. Learn more about CMK here.