Atlassian Connect: die Sicherheit von Add-ons

In der Einführung in Atlassian Connect haben wir gesehen, dass Add-ons eigene Anwendungen sind, die von verschiedenen Anbietern betrieben werden und über das Internet mit der Atlassian-Anwendung kommunizieren. Besonders im Unternehmenskontext stellt sich die Frage nach der Sicherheit und Vertraulichkeit der Daten. Diese Aspekte wollen wir in diesem Artikel genauer beleuchten.

Wir benutzen JIRA als Beispiel, die Überlegungen treffen aber auf alle Connect-Anwendungen (z.B. Confluence, HipChat, Bitbucket) zu.

Der Überblick

Wir betrachten im weiteren Verlauf vier verschiedene Bereiche, in denen der Sicherheitsaspekt eine Rolle spielt. Einen Überblick gibt das folgende Bild:

Insbesondere wollen wir im Zusammenhang mit Sicherheit die folgenden Punkte genauer beleuchten:

1. die Kommunikation zwischen Atlassian-Anwendungen und Add-ons
2. das Berechtigungskonzept der Atlassian-Plattform
3. die Anforderungen an das Connect Add-on
4. Schutz privater Add-ons

Kommunikation zwischen den beiden Anwendungen

Wie bereits beschrieben, interagieren die Anwendungen über öffentliche Netze, daher muss die Kommunikation zwischen den beiden Systemen abgesichert werden. Die Daten werden über das Internet gesendet und dürfen weder verfälscht noch von Dritten ausgelesen werden. Connect unterstützt zwei Sicherheitsmechanismen für die Kommunikation: HTTPS und JWT .

Bevor wir näher auf diese beiden Mechanismen eingehen, muss zum Verständnis noch ein anderer Punkt erwähnt werden. Ein Connect-Add-on unterliegt einem Lifecycle, für dessen Phasen Webhooks registriert werden können. Während der Installation des Add-ons findet über einen solchen Webhook der Austausch der Sicherheitsinformationen statt. Diese enthalten auch ein Geheimnis, welches im weiteren Verlauf wichtig wird.

Für Add-ons, die im Marketplace gelistet werden sollen, ist die gesicherte Übertragung mittels HTTPS verpflichtend. Damit werden die Daten verschlüsselt übertragen und können nicht von Unbefugten ausgelesen werden. Die Verschlüsselung muss die gesamte Kommunikation umfassen, also auch die Übertragung des Add-on Descriptors und ganz besonders den Austausch der Sicherheits-Informationen bei der Installation.

Außerdem wird zur Signierung der Nachrichten JWT eingesetzt. Damit wird eine Authentifizierung umgesetzt, denn es kann für jede Nachricht geprüft werden, ob sie vom angegebenen Absender stammt. Für die Erstellung dieser Signatur wird das bei der Installation ausgetauschte Geheimnis genutzt.

REST-Anfragen an die JIRA-API müssen immer signiert sein, ansonsten werden sie wie anonyme Nutzer behandelt, die keinen oder nur minimale Berechtigungen haben. Durch die Signatur weiß die Anwendung, von wem die Anfrage kommt und kann weitere Sicherheitsprüfungen durchführen (siehe nächster Abschnitt).

Auch bei eingehenden Nachrichten im Add-on sollte die Signatur geprüft werden. Die Atlassian-Anwendung signiert jede Nachricht, die Prüfung dieser Signatur liegt aber in der Verantwortung des Add-on Entwicklers. Nur wenn er diese verifiziert, kann er sicher sein, dass die Anfrage von einem authentifizierten Partner kommt. Für die Erstellung und Prüfung der Token bietet Atlassian fertige Bibliotheken an.

Berechtigungen

Atlassian Connect unterstützt die Vergabe von Berechtigungen an einzelne Add-ons. Dies wird über einen eigenen Add-on Nutzer realisiert, der genau wie ein normaler Nutzer konfiguriert werden kann. Dieser Nutzer wird jedoch nicht auf die in der Lizenz freigeschalteten Nutzer aufgerechnet.

Grundlegende Anforderungen wie “Lesen” und “Schreiben” von Daten können die Add-ons in ihrem Descriptor angeben, diese werden “Scopes” genannt. Um beispielsweise Daten in der Anwendung zu verändern, muss zwingend der zugehörige Scope “write” angegeben sein.

Die angeforderten Scopes werden bei der Installation aufgelistet und müssen vom Administrator bestätigt werden. Auch wenn bei einer Aktualisierung neue Scopes hinzukommen, muss der Administrator erst bestätigen, dass diese gewährt werden sollen.

Sicherheit des Add-ons

Nachdem wir nun die Kommunikation und den Zugriff auf die Kern-Anwendung betrachtet haben, wird es Zeit sich der Sicherheit in der zweiten Anwendung zu widmen. Was nützt die sichere Kommunikation, wenn das Add-on selbst offen wie ein Scheunentor ist?

Ein für Anwender kritischer Punkt ist die Speicherung von Kundendaten im Add-on. Dazu müssen Anbieter eine Erklärung zur Datensicherheit im Marketplace veröffentlichen. Atlassian gibt auch hierfür Empfehlungen und Richtlinien vor, die Umsetzungsverantwortung liegt aber beim Anbieter des Add-ons. Bei der Speicherung ist grundlegend zu beachten, dass die Daten getrennt nach Mandanten (verschiedene Cloud-Instanzen verschiedener Kunden) gespeichert werden. Die Daten selbst müssen natürlich gegen Zugriffe und Manipulationen durch Dritte geschützt werden.

Dieser letzte Punkt gilt ganz allgemein für die ganze Webanwendung und das zugrundeliegende System. Aufgrund der vielfältigen Möglichkeiten, solch eine Anwendung zu implementieren und zu betreiben kann es an dieser Stelle nur ganz allgemeine Hinweise zur Absicherung geben. Es gibt einige bekannte Angriffszenarien , die immer nach dem gleichen Prinzip ablaufen und für deren Vermeidung Empfehlungen vorhanden sind. Details können den verlinkten Seiten entnommen werden.

Neben dem Schutz vor direkten Angriffen auf das Add-on ist für den Anwender auch die Ausfallsicherheit bedeutsam. Wenn ein Add-on nicht verfügbar ist, kann dies die Arbeit des Kunden deutlich einschränken. Deshalb muss der durchgehende Betrieb sichergestellt werden. Da ein Add-on von mehreren Cloud-Instanzen aufgerufen wird, können auch keine individuellen Wartungsfenster vereinbart werden. Im Gegenteil, die Kunden können weltweit verstreut sein und in völlig unterschiedlichen Zeitzonen arbeiten. Auch hier liegt es wieder in der Verantwortung des Anbieters, für die ständige Verfügbarkeit zu sorgen.

Weiterhin muss der Schutz vor Datenverlust bei Hardwareausfällen gewährleistet werden. Dazu müssen beispielsweise Redundanzen und Backups eingerichtet werden.

Private Add-ons im Marktplatz

Für Kunden, die ihre intern genutzten Add-ons selbst schreiben wollen, bietet Atlassian einen Weg, diese als “private Add-ons” im Marktplatz zu listen. Für den Fall, dass das Add-on gar nicht im Marktplatz auftauchen soll, gibt es außerdem noch einen weiteren Weg.

Dreh- und Angelpunkt für alle Add-ons ist der Atlassian Marktplatz. Speziell für den Fall privater Add-ons gibt es nun zwei Optionen:

Das Add-on wird als “privat” im Marketplace gelistet und ist somit nur für den Anbieter sichtbar. Für die Installation in JIRA wird ein separates Token benötigt, mit dem das Add-on sichtbar gemacht werden kann. Die Token können auf einer eigenen Seite verwaltet werden und gelten jeweils nur für eine Instanz. 

Zur Einbindung des Add-ons in JIRA muss der Administrator außerdem explizit private Add-ons erlauben. Danach kann die eigene Erweiterung wie gewohnt über den Marktplatz installiert werden. 

Diese erste Option bedeutet einen gewissen Aufwand. Sie bietet den Vorteil, dass Atlassian ein Monitoring für die Verfügbarkeit des Add-ons durchführt und warnt, wenn ein Plugin nicht erreichbar ist. 

Die zweite Option besteht darin, das private Add-on im Entwicklungsmodus einzubinden. Dieser erlaubt die Installation ohne eine Registrierung im Marktplatz. Allerdings ist dieser Weg von Atlassian nicht für den Livebetrieb vorgesehen. So gibt es beispielsweise kein Monitoring und auch die Absicherung des Add-ons gegen die Nutzung durch Dritte ist schwieriger, da keine gültigen Lizenzinformationen übertragen werden können.

Zusammengefasst gibt zwei Pfade, mit denen private Add-ons in Applikationen eingebunden werden können. Während die Nutzung von privaten Add-ons bei geschäftskritischen Prozessen die bessere Wahl ist, bietet die Einbindung von unkritischen Add-ons über den Entwicklungsmodus einen schnellen und unkomplizierten Einstieg.

Der letzte Blick gilt noch einmal der Frage, wie private Add-ons bereit gestellt werden. Auch wenn der Name „privates Add-on“ dies vielleicht nicht suggeriert, muss dennoch auch dieses Add-on über eine Internet-Schnittstelle eingebunden werden wie jedes andere öffentliche Add-on auch. Es ist daher unabdingbar, auch bei privaten Add-ons auf die richtige Absicherung zu achten.

Ergebnis

Wie man im Artikel sieht, gibt es sehr viele Punkte, die einen Einfluss auf die Sicherheit des Add-ons haben. Es ist aber auch zu bedenken, dass Server-Add-ons nicht pauschal als sicher eingestuft werden können. Auch diese können große Sicherheitslücken beinhalten. Und auch das Hosting einer JIRA Server Instanz durch den Anwender birgt Risiken, wenn er sich nicht damit auskennt.

Die Frage, ob Connect-Add-ons sicher(er) sind, lässt sich also nicht pauschal beantworten. Atlassian unterstützt die Anbieter durch die Bereitstellung von Bibliotheken und den Zwang zu verschlüsselter Kommunikation. Es werden Empfehlungen gegebenen, und in der Dokumentation gibt es einen eigenen Punkt zum Thema Sicherheit. Der größte Teil der Verantwortung liegt aber beim Anbieter der Erweiterung. Dieser muss auf viele Dinge achten und vieles richtig machen, dann können die Add-ons durchaus als sicher gelten. Die Überprüfung für den Nutzer ist hier aber sehr schwer, er muss dem Anbieter vor allem Vertrauen entgegenbringen.