Atlassian Cloud-Architektur und betriebliche Praktiken

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. Uns ist jedoch bewusst, dass einige von euch Daten an einem bestimmten Ort aufbewahren müssen, daher bieten wir Datenresidenz an. Derzeit bieten wir Datenresidenz in den USA und in EU-Regionen sowie Australien an und wir planen, demnächst weitere Regionen hinzuzufügen. Um weitere Informationen zu erhalten und dich für Updates anzumelden, kannst du unsere Seite zur Datenresidenz besuchen.

Die Daten für Bitbucket befinden sich in zwei unterschiedlichen Availability Zones in der Region USA Ost.

Daten-Backups

Atlassian verfolgt ein umfassendes Backup-Programm. Dieses schließt unsere internen Systeme ein, bei denen unsere Backup-Maßnahmen in Einklang mit den Anforderungen zur Systemwiederherstellung erstellt wurden. Wir bieten ebenso umfangreiche Backup-Maßnahmen für unser Cloud-Sortiment, insbesondere für dich und deine Anwendungsdaten. Wir nutzen die Snapshot-Funktion von Amazon RDS (Relational Database Service), um automatische tägliche Backups jeder RDS-Instanz anzulegen.

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.

Wir verwenden diese Backups nicht, um von Kunden veranlasste, destruktive Änderungen rückgängig zu machen, wie zum Beispiel von Skripten überschriebene Felder oder gelöschte Vorgänge, Projekte oder Sites. Um Datenverlust zu vermeiden, empfehlen wir regelmäßige Backups. Weitere Informationen zur Erstellung von Backups findest du in der Supportdokumentation zu deinem Produkt.

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 ausschließlich 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 für verteilte Services

Mit dieser AWS-Architektur hosten wir eine Reihe von Plattform- und Produktservices, die in unseren Lösungen zum Einsatz kommen. Dazu gehören Plattformfunktionen, die von mehreren Atlassian-Produkten wie Media, Identity, Commerce und unserem Editor gemeinsam genutzt werden, sowie produktspezifische Funktionen wie Jira-Issue-Service und Confluence Analytics.

Mehrmandantenarchitektur

Zusätzlich zu unserer Cloud-Infrastruktur haben wir eine mehrmandantenfähige Microservice-Architektur zusammen mit einer geteilten Plattform, die unsere Produkte unterstützt, aufgebaut und betrieben. In einer Mehrmandantenarchitektur bedient ein einziger Service mehrere Kunden, einschließlich Datenbanken und Recheninstanzen, die für die Ausführung unserer Cloud-Produkte erforderlich sind. Jeder Shard (im Wesentlichen ein Container – siehe Abbildung 3 unten) enthält die Daten für mehrere Mandanten, aber die Daten jedes Mandanten sind isoliert und für andere Mandanten nicht zugänglich. Bitte beachte, dass wir keine Einzelmandantenarchitektur anbieten.

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).

Mandantentrennung

Unsere Kunden greifen auf eine gemeinsame cloudbasierte IT-Infrastruktur zu, wenn sie unsere Cloud-Produkte nutzen. Wir haben daher Maßnahmen für eine logische Trennung ergriffen, damit die Aktionen eines Kunden die Daten oder Services anderer Kunden nicht gefährden.

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.

Authentifizierung und Autorisierung von Services

Für unsere Plattform wenden wir für den Datenzugriff das Prinzip der geringsten Rechte an. Das bedeutet, dass nur der Service Zugriff erhält, der für das Speichern, Verarbeiten oder Abrufen der jeweiligen Daten zuständig ist. Beispielsweise haben wir für unsere Medienservices, die dir eine konsistente Funktonalität beim Datei-Upload und -Download in allen unseren Cloud-Produkten bieten, fest zugeordneten Speicher bereitgestellt, auf den keine anderen Atlassian-Services Zugriff haben. Jeder Service, der Zugriff auf die Medieninhalte benötigt, muss mit der API für Medienservices interagieren. Demzufolge sorgt eine sichere Authentifizierung und Autorisierung auf Serviceebene außerdem für eine strikte Aufgabentrennung und den Datenzugriff nach dem Prinzip der geringsten Rechte.

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

Kundendaten in Atlassian Cloud-Produkten werden bei der Übertragung über öffentliche Netzwerke mithilfe von TLS 1.2+ mit PFS (Perfect Forward Secrecy) verschlüsselt, um sie vor einer unautorisierten Veröffentlichung oder Modifikation zu schützen. Unsere Implementierung von TLS setzt die Verwendung starker Verschlüsselungen und Schlüssellängen voraus, sofern diese vom Browser unterstützt werden.

Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie, and Trello use full disk, industry-standard AES-256 encryption at rest.

PII (persönlich identifizierbare Informationen), die über ein Datenübertragungsnetzwerk übermittelt werden, unterliegen angemessenen Kontrollen. So wird sichergestellt, dass Daten ihr beabsichtigtes Ziel erreichen. In der internen Richtlinie zur Kryptografie und Verschlüsselung von Atlassian sind allgemeine Prinzipien für von Atlassian implementierte Verschlüsselungs- und Kryptografiemechanismen festgelegt, die Risiken im Zusammenhang mit der Speicherung von PII und ihrer Übertragung in Netzwerken reduzieren sollen. Der Algorithmus, der zur Verschlüsselung von PII verwendet wird, muss die Klassifizierungsstufe der PII gemäß dem internen Datensicherheits- und Informationslebenszyklus-Management von Atlassian berücksichtigen. 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.

Schlüsselmanagement

Wir bei Atlassian nutzen den AWS KMS (Key Management Service) für das Schlüsselmanagement. Um den Schutz deiner Daten weiterhin zu gewährleisten, ist KMS der Ersteller und geheime Speicher dieser Schlüssel. Der Verschlüsselungs-, Entschlüsselungs- und Schlüsselmanagementprozess wird im Rahmen interner Prüfprozesse regelmäßig von AWS untersucht und verifiziert. Jedem Schlüssel wird ein Besitzer zugewiesen, der dafür zuständig ist, dass Schlüssel angemessenen Sicherheitskontrollen unterzogen werden. Die von Atlassian verwalteten Schlüssel werden bei maßgeblichen Änderungen der Rolle oder des Beschäftigungsstatus von Mitarbeitern geändert.

Wir nutzen auch eine Envelope-Verschlüsselung. AWS hat den Hauptschlüssel, den wir niemals sehen können, und jede Schlüsselverschlüsselungs- oder Entschlüsselungsanfrage erfordert die richtigen AWS-Rollen und -Berechtigungen. Wenn wir mit der Envelope-Verschlüsselung Schlüssel für einzelne Kunden erstellen oder generieren, nutzen wir unterschiedliche Datenschlüssel für unterschiedliche Datentypen in unseren Datenspeichern. Darüber hinaus verfolgen wir einen Verschlüsselungsansatz für die interne Anwendungsebene, bei dem Backup-Datenschlüssel in anderen AWS-Regionen bereitgestellt werden. Schlüssel werden jährlich automatisch rotiert, sodass derselbe Datenschlüssel für nicht mehr als 100.000 Datenelemente verwendet wird.

In Kürze werden wir die BYOK-Verschlüsselung (Bring Your Own Key) anbieten, mit der du deine Cloud-Produktdaten mit selbstverwalteten Schlüsseln in AWS KMS verschlüsseln kannst. Mit BYOK hast du die vollständige Kontrolle über die Verwaltung deiner Schlüssel und kannst den Zugriff jederzeit für deine eigenen Endbenutzer und für Atlassian-Systeme gewähren oder widerrufen.

AWS KMS kann in AWS CloudTrail in deinem AWS-Konto integriert werden, um dir Protokolle zur Schlüsselnutzung bereitzustellen. Diese Lösung ermöglicht die Verschlüsselung deiner Daten auf verschiedenen Anwendungsebenen, wie Datenbanken, Dateispeichern sowie unseren internen Zwischenspeichern und Ereigniswarteschlangen. Dieser Prozess hat keine negativen Konsequenzen für die Nutzbarkeit des Produkts.