Ein Token ist leicht erstellt und leicht vergessen, und das Vergessen ist, woher die Ausfälle kommen. Wem einer gehört, was sein Ablauf mit einem Job macht, den niemand beobachtet, was passiert, wenn der Eigentümer geht, und wie man einen ohne Lücke rotiert.
Aktualisiert · 7 Min. Lesezeit
Ein Personal Access Token wird für eine namentlich bekannte Person ausgestellt, in ihrem Namen, und er trägt genau die Tableau-Berechtigungen, die diese Person ohnehin hat. Das macht ihn wert, eine Governance-Grenze darauf zu bauen: Alles, was damit getan wird, hätte der Eigentümer ohnehin tun können, und jede Audit-Zeile nachgelagert trägt ehrlich seinen Namen.
Es macht den Token auch zu einem administrativen Objekt, nicht zu einem technischen. Er hat einen Eigentümer, der Eigentümer hat ein Team, und das Team hat einen Dienstplan. Fast alles Unangenehme auf dieser Seite folgt aus dieser einen Tatsache.
Das erste Artefakt, das sich lohnt, ist ein Register: eine Zeile pro Token, mit dem Job, den er antreibt, der verantwortlichen Person, dem Ort, an dem er gespeichert ist, und dem Ablaufdatum. Vier Zeilen brauchen zehn Minuten und beantworten die Frage, die sonst einen Vormittag kostet, nämlich: Wenn ich das widerrufe, was bleibt stehen.
Tableau Cloud erlaubt eine aktive Sitzung pro Token. Jede neue Anmeldung mit diesem Token beendet die Sitzung davor, was bequem ist, solange eine Person ihn nutzt, und unangenehm in dem Moment, in dem es zwei Dinge sind.
Die Suite ist um dieses Verhalten herum gebaut, nicht dagegen. Das Gateway meldet sich einmal an, prägt eine einzige Tableau-Sitzung und reicht diese eine Sitzung an jedes Tool weiter. Die Tools teilen sie, statt sich jeweils erneut mit demselben Token anzumelden und die Anmeldung davor ungültig zu machen.
Dieselbe Regel prägt, wie sich ein langer Job verhält. Bevor ein Migrationslauf gegen eine Cloud-Quelle freigegeben wird, sagt die Vorabprüfung es in genau diesen Worten: Nutzen Sie einen Token, der diesem Lauf gewidmet ist, unter einem Namen, den nichts anderes nutzt, und stellen Sie sicher, dass kein Zeitplan, kein Browser-Tab und kein zweites Gerät ihn teilt. Der Lauf wiederholt Authentifizierungsfehler in gestaffelten Runden: Eine Kollision ist überlebbar, aber ein Client, der sich immer wieder mit demselben Token anmeldet, wird ihn trotzdem aushungern. Eine Server-Quelle toleriert gleichzeitige Sitzungen auf einem Token, und deshalb kann eine Gewohnheit, die jahrelang harmlos war, ein Team beim ersten Cloud-Lauf überraschen.
Ein geplanter Job und eine Person, die sich gegenseitig zu stören scheinen, sind meist genau das, und es zeigt sich als unregelmässiges Produktflattern und sieht selten wie das Berechtigungsproblem aus, das es ist. Prüfen Sie, welchen Token jede Seite hält, bevor Sie irgendetwas anderes untersuchen.
Ein Token hat ein Ablaufdatum, und eine darauf gebaute Automatisierung erbt dieses Datum, ohne es je wieder zu erwähnen. Der Ausfall kommt dann beim nächsten geplanten Lauf an, nicht im Moment des Ablaufs. Die Lücke zwischen dem Sterben des Tokens und dem Moment, in dem jemand davon hört, ist ein voller Zyklus. Bei einem monatlichen Job ist das ein Monat.
Zwei Einstellungen sollte man auf der eigenen Site lesen, nicht annehmen: das Ablaufdatum, das ein Administrator beim Ausstellen des Tokens gesetzt hat, und was Ihre Site mit einem Token macht, der ungenutzt herumlag. Ein Token, der einen vierteljährlichen Job antreibt, verbringt den grössten Teil seines Lebens untätig, und das ist die Kombination, die Teams kalt erwischt.
Wo ein geplanter Lauf vom persönlichen Token auf eine Dienstberechtigung zurückfallen kann, ist die Designantwort klein, aber entscheidend: Welche Berechtigung tatsächlich authentifiziert hat, wird am Lauf festgehalten und in der Zeile gezeigt. Ohne dieses Protokoll bleibt ein stiller Rückfall unrepariert, und das Problem taucht erst auf, wenn der Rückfall selbst scheitert.
Ein gescheiterter Lauf stellt trotzdem seinen nächsten Auslöser scharf: Ein Zeitplan, der nicht mehr vorrückt, bleibt dauerhaft fällig, und der Runner greift immer wieder danach.
Das Konto geht, und der Token geht mit ihm. Das ist korrektes Verhalten, und es ist auch der Moment, in dem mehrere unbeaufsichtigte Jobs auf einmal stehen bleiben, ohne dass einer davon in der Austrittscheckliste erscheint.
Eine Person auf einer Tableau Site kann sechs Arten von Dingen besitzen: Arbeitsmappen, veröffentlichte Datenquellen, Flows, Projekte, Abonnements und Aktualisierungsaufgaben. Ihre Tokens sind eine siebte, und anders als die anderen sechs taucht ein Token in keinem Projektbaum auf. Kümmern Sie sich in derselben Stunde darum wie um die Inhalte, die ihr gehören, sonst findet ein Zeitplan ihn für Sie.
Offboarding und Token-Hygiene sind dieselbe Disziplin, von zwei Enden betrachtet. Ein Register, das die für jeden Token verantwortliche Person nennt, macht aus dem Austrittsgespräch ein Nachschlagen statt einer Untersuchung.
Rotation geht schief, wenn sie als Tausch durchgeführt wird. Als Überlappung durchgeführt ist sie ereignislos.
Der Installationsschritt ist sicher, während Arbeit läuft. Eine festgeschriebene Berechtigung wird in eine temporäre Datei geschrieben und dann an ihren Platz verschoben, sodass ein Lauf, der mitten in der Rotation startet, entweder die alte oder die neue Berechtigung liest und nie die Hälfte einer Datei.
Schritt drei ist der, den die Leute überspringen, und es ist der einzige Schritt, der irgendetwas beweist. Wenn der Lauf mit der Dienstberechtigung gelingt, ist der persönliche Token bereits kaputt, die Rotation hat nichts getestet, und Sie haben gerade Ihren Beleg widerrufen.
Wo ein Token von einem Administrator für eine gehostete Bereitstellung festgeschrieben ist, wird die Abmeldeschaltfläche absichtlich ausgeblendet, denn der nächste Seitenaufruf würde ihn ohnehin wieder verbinden. Diese Berechtigung wird stattdessen in der Admin-Konsole geändert, wo jeder, der sie sucht, auch nachsehen würde.
Geheimnisse in dieser Suite gelten nur für die Sitzung, was sauber hält, bis ein Job um halb drei laufen muss, ohne dass jemand da ist. Die Ausnahme ist ausdrücklich, eng und es wert, verstanden zu werden, bevor Sie sich darauf verlassen.
Eine Zeile in dieser Liste leistet mehr, als sie aussieht. Die Site, auf die ein Zeitplan zeigt, wird serverseitig aus der laufenden Sitzung gestempelt, nie aus der Anfrage gelesen, denn ein Aufrufer, der sie setzen könnte, könnte einen geplanten Lauf auf eine andere Site richten, während er die Berechtigung von jemand anderem hält.
All das ist gewöhnlich. Es ist der eine Teil der Berechtigungsverwaltung, zu dem keine Oberfläche je jemanden auffordert. Schreiben Sie es einmal auf und behalten Sie es.
Zwei Tableau-Berechtigungen, die zwei verschiedene Aufgaben erledigen. Die eine trägt die Berechtigungen einer Person. Die andere erweitert eine Plattformfähigkeit. Die richtige zu wählen hält ein Berechtigungsmodell, das Sie über Jahre aufgebaut haben, dafür zuständig, wer was sieht.
Eine Person geht. Ihr Name bleibt auf Arbeitsmappen, Zeitplänen und Abonnements, und mehrere davon fallen lautlos aus. Was sie hält, was bricht, und die Reihenfolge, die die Lizenz wiederherstellbar hält.
Eine Behauptung ist ein Satz. Ein Beleg ist etwas, das eine zweite Person prüfen kann, ohne Sie zu fragen. Was ein Audit-Trail enthalten muss, was ein Hash wirklich beweist, und was Sie von jedem Tool verlangen sollten, das behauptet, einen zu erzeugen.