Der eine Notausgang

Die Versuchung, es „nur schnell" direkt zu machen

Jedes Sicherheitskonzept hat eine Schwachstelle, und meistens ist es nicht die Technik, sondern die Abkürzung, die jemand nimmt, weil sie gerade bequemer ist. Bei einem System wie JiCo wäre diese Abkürzung leicht zu nehmen: ein curl-Befehl, der direkt gegen die Jira-API geht, ein zweiter API-Token, der neben JiCo in einem anderen Werkzeug liegt, ein Skript, das „nur dieses eine Mal" an der Schleuse vorbeigreift, weil es schneller geht.

Das Tückische an solchen Abkürzungen ist, dass sie im Moment harmlos aussehen. Niemand denkt beim Kopieren eines Tokens daran, dass er damit zwei fundamentale Schutzmechanismen gleichzeitig ausser Kraft setzt — die Schwärzung personenbezogener Daten vor dem Modell, und die menschliche Freigabe vor jeder Änderung. Ein Direktpfad an Jira vorbei macht beide Schleusen wirkungslos, auf einen Schlag, ohne dass irgendjemand das als bewusste Entscheidung getroffen hätte.

Terminal-Nutzung ist erwünscht — die Frage ist nur, wohin sie zeigt

Das heisst nicht, dass JiCo das Terminal verbietet oder misstrauisch beäugt. Im Gegenteil: Wer ein Kommando lieber selbst tippt, statt es über einen Chat-Dialog auszulösen, soll das können — für viele erfahrene Nutzer ist das sogar der natürlichere, schnellere Weg. Die Frage ist nicht, ob ein Terminal-Befehl ausgeführt wird. Die Frage ist, wohin dieser Befehl zeigt.

Und hier liegt der eigentliche Kniff: Der curl-Befehl, den JiCo für eine Freigabe ausgeben wird, zeigt nicht auf Jira. Er zeigt auf JiCo selbst, abgesichert mit einem Einmal-Token, das genau für diese eine Aktion gültig ist und danach verfällt. JiCo führt die Aktion dann so aus, wie sie ohnehin ausgeführt worden wäre, wenn man sie über die Oberfläche bestätigt hätte: geprüft, protokolliert, und nur auf dem aktuellen, gerade noch einmal nachgelesenen Stand des Tickets. Der Komfort des Terminals bleibt erhalten. Die beiden Schleusen bleiben ebenfalls erhalten. Man muss sich zwischen beidem nicht entscheiden. Dieser Terminal-Weg ist entschieden, aber noch nicht gebaut; heute geben Sie im Panel oder mit jico approvals frei.

Der eine Weg, der wirklich direkt ist — und warum er trotzdem existiert

Vorgesehen ist ein zweiter Weg, der tatsächlich ungeschützt direkt gegen Jira geht: der Roh-Export, ebenfalls entschieden, aber noch nicht gebaut. Anders als die versehentliche Abkürzung von oben ist das kein Versehen und kein Geheimnis, sondern der eine ausdrücklich benannte und markierte Notausgang im ganzen System. Er existiert, weil es reale Situationen gibt, in denen jemand einen kompletten, ungefilterten Datenexport braucht — für eine externe Prüfung etwa, oder eine Migration, bei der die üblichen Schleusen schlicht nicht das richtige Werkzeug sind.

Drei Dinge unterscheiden diesen Notausgang von einer stillen Umgehung: Er wird nur auf ausdrückliche, bewusste Anforderung genutzt, nie automatisch oder als Vorgabe. Er kommt ohne die Garantien der beiden Schleusen — wer ihn nutzt, weiss, dass er sie gerade verlässt. Und der Export selbst wird im Audit-Trail protokolliert, sodass niemand später überrascht davon sein kann, dass er stattgefunden hat.

Der Unterschied zwischen diesem markierten Notausgang und einem stillen Umgehen der Schleusen ist kein technischer, sondern ein ehrlicher: Eine Grenze, die man offen als Grenze benennt, kann man später verantworten — gegenüber einem Auditor, einer Datenschutzbeauftragten, sich selbst. Eine Grenze, die im Kleingedruckten verschwindet oder gar nicht erst dokumentiert ist, wird irgendwann zum Vorwurf, meistens genau dann, wenn es am unangenehmsten ist.

Ein Muster, das über JiCo hinausreicht

Wer schon einmal in einer IT-Abteilung gearbeitet hat, kennt das Grundmuster dieses Problems auch ausserhalb von JiCo: Es ist dieselbe Dynamik, die überall dort entsteht, wo eine offizielle, kontrollierte Lösung existiert und gleichzeitig ein bequemerer, weniger kontrollierter Weg technisch möglich bleibt. Schatten-IT entsteht fast nie aus böser Absicht — sie entsteht, weil jemand unter Zeitdruck den Weg nimmt, der gerade am wenigsten Reibung erzeugt, ohne die Konsequenz im Moment zu Ende zu denken.

Der einzig wirksame Hebel gegen dieses Muster ist selten eine zusätzliche Verbotsregel, die ohnehin niemand liest, bevor er sie übertritt. Er besteht darin, den kontrollierten Weg so bequem zu machen, dass die Abkürzung ihren eigentlichen Vorteil verliert. Genau das versucht der Terminal-Weg über JiCo zu leisten: Wer sowieso lieber tippt statt klickt, soll dafür keinen Umweg über eine zweite, ungeschützte Verbindung nehmen müssen — der bequeme Weg und der kontrollierte Weg sollen möglichst derselbe Weg sein.

Wo die Grenze wirklich verläuft — und wo sie das absichtlich nicht tut

Ganz zu Ende gedacht gehört auch die unbequemere Wahrheit dazu: Ein zweiter, persönlicher Jira-Zugang neben JiCo — ein API-Token, das jemand in ein anderes Werkzeug einträgt, weil es gerade praktisch erscheint — liest an JiCo vorbei. Für den reinen Leseweg lässt sich das mit den Mitteln von JiCo allein nicht technisch verhindern. Es ist eine Frage der Einrichtung der Arbeitsumgebung im Unternehmen, nicht eine Frage der Architektur des Werkzeugs selbst — vergleichbar mit einem Türschloss, das nichts nützt, wenn jemand daneben ein Fenster offen lässt.

Der Schreibweg ist davon nicht betroffen, und das ist der entscheidende Unterschied. Ohne den Weg über JiCo gibt es keine Freigabe-Schleuse zu passieren, und ohne Freigabe schreibt niemand — auch kein zweiter Zugang kann diesen Mechanismus umgehen, weil er gar nicht erst mit ihm in Berührung kommt.

Diese Grenze steht hier bewusst offen im Fliesstext, nicht als Fussnote im Kleingedruckten. Ein Produkt, das für sich beanspruchen würde, jeden denkbaren Datenabfluss zu verhindern, wäre in genau dem Moment widerlegt, in dem jemand im Unternehmen einen zweiten, ungeschützten Zugang einrichtet — und ein findiger Prüfer würde diesen Widerspruch in zehn Minuten finden. JiCo beansprucht das deshalb nicht. Es macht den durch JiCo geführten Weg zum bequemeren, sichereren, besser dokumentierten Weg — nicht zum einzigen technisch möglichen. Der Unterschied zwischen diesen beiden Versprechen ist klein in der Formulierung und gross in der Glaubwürdigkeit.