Un jeton est facile à créer et facile à oublier, et c’est de l’oubli que viennent les pannes. À qui appartient un jeton, ce que son expiration fait à une tâche que personne ne surveille, ce qui se passe quand son propriétaire part, et comment le renouveler sans interruption.
Mis à jour · 7 min de lecture
Un jeton d’accès personnel est délivré à une personne nommée, en son nom, et il porte exactement les permissions Tableau que cette personne a déjà. C’est ce qui en fait une base solide pour une frontière de gouvernance : tout ce qui est fait avec lui est quelque chose que son propriétaire aurait pu faire de toute façon, et chaque ligne d’audit en aval porte honnêtement son nom.
Cela fait aussi du jeton un objet administratif, pas technique. Il a un propriétaire, le propriétaire a une équipe, et l’équipe a un planning. Presque tout ce qui est gênant sur cette page découle de ce seul fait.
Le premier artefact à avoir est un registre : une ligne par jeton, nommant la tâche qu’il fait tourner, la personne qui en répond, l’endroit où il est stocké, et sa date d’expiration. Quatre lignes prennent dix minutes à écrire et répondent à la question qui autrement prend une matinée, à savoir : si je révoque ceci, qu’est-ce qui s’arrête.
Tableau Cloud n’autorise qu’une session active par jeton. Chaque nouvelle connexion avec ce jeton met fin à la session précédente, ce qui est confortable tant qu’une seule personne l’utilise et gênant dès que deux choses l’utilisent.
La suite est construite autour de ce comportement plutôt que contre lui. La passerelle se connecte une fois, crée une seule session Tableau, et remet cette session unique à chaque outil. Les outils la partagent au lieu de se reconnecter chacun avec le même jeton et d’invalider la connexion précédente.
La même règle façonne le comportement d’une longue tâche. Avant qu’une exécution de migration contre une source Cloud soit approuvée, l’aperçu préalable le dit en toutes lettres : utilisez un jeton dédié à cette exécution, sous un nom que rien d’autre n’utilise, et assurez-vous qu’aucune planification, aucun onglet de navigateur ni aucun second appareil ne le partage. L’exécution réessaie les échecs d’authentification par vagues espacées : une collision est survivable, mais un client qui continue de se reconnecter avec le même jeton finira quand même par l’affamer. Une source Server tolère des sessions concurrentes sur un jeton, ce qui explique qu’une habitude inoffensive pendant des années puisse surprendre une équipe lors de sa première exécution Cloud.
Une tâche planifiée et une personne qui semblent se gêner mutuellement, c’est généralement cela, et cela se présente comme une instabilité intermittente du produit, rarement comme le problème d’identifiant que c’est. Vérifiez quel jeton chaque côté détient avant d’enquêter sur quoi que ce soit d’autre.
Un jeton a une expiration, et une automatisation bâtie dessus hérite de cette date sans jamais la mentionner à nouveau. La panne arrive alors à la prochaine exécution planifiée plutôt qu’au moment de l’expiration. L’écart entre la mort du jeton et le moment où quelqu’un en entend parler est une cadence complète. Sur une tâche mensuelle, c’est un mois.
Deux réglages valent la peine d’être lus sur votre propre site, pas supposés : l’expiration qu’un administrateur a fixée quand le jeton a été émis, et ce que votre site fait d’un jeton resté inutilisé. Un jeton qui fait tourner une tâche trimestrielle passe l’essentiel de sa vie inactif, ce qui est la combinaison qui piège les équipes.
Là où une exécution planifiée peut se rabattre du jeton personnel vers un identifiant de service, la réponse de conception est petite mais décisive : l’identifiant qui s’est réellement authentifié est enregistré sur l’exécution et affiché sur la ligne. Sans cet enregistrement, un repli silencieux reste non réparé, et le problème ne fait surface que quand le repli lui-même échoue.
Une exécution en échec arme quand même la suivante : une planification qui cesse d’avancer reste indéfiniment due, et l’exécuteur continue de la relancer.
Le compte s’en va et le jeton avec lui. C’est le comportement correct, et c’est aussi le moment où plusieurs tâches sans surveillance s’arrêtent d’un coup sans qu’aucune n’apparaisse dans la liste de départ.
Une personne sur un site Tableau peut posséder six sortes de choses : des classeurs, des sources de données publiées, des flux, des projets, des abonnements et des tâches de rafraîchissement. Ses jetons sont une septième, et contrairement aux six autres, un jeton n’apparaît dans aucune arborescence de projets. Traitez-le dans la même heure que le contenu qu’elle possède, ou une planification le trouvera pour vous.
Le départ d’un utilisateur et l’hygiène des jetons sont la même discipline vue par les deux bouts. Un registre qui nomme la personne responsable de chaque jeton transforme la conversation de départ en recherche plutôt qu’en enquête.
La rotation tourne mal quand elle est faite comme un échange. Faite comme un chevauchement, elle passe inaperçue.
L’étape d’installation est sûre à réaliser pendant que du travail est en cours. Un identifiant verrouillé est écrit dans un fichier temporaire puis déplacé à sa place, si bien qu’une exécution qui démarre en pleine rotation lit soit l’ancien identifiant, soit le nouveau, et jamais la moitié d’un fichier.
L’étape trois est celle que l’on saute, et c’est la seule étape qui prouve quelque chose. Si l’exécution réussit sur l’identifiant de service, le jeton personnel est déjà cassé, la rotation n’a rien testé, et vous venez de révoquer votre preuve.
Là où un jeton est verrouillé par un administrateur pour un déploiement hébergé, la commande de déconnexion est délibérément masquée, parce que le chargement de page suivant le reconnecterait de toute façon. Cet identifiant se change dans la console d’administration, qui est là où quiconque le cherche pensera à regarder.
Les secrets dans cette suite ne durent que le temps d’une session, ce qui tient proprement jusqu’à ce qu’une tâche doive tourner à deux heures et demie sans personne. L’exception est explicite, étroite, et mérite d’être comprise avant de s’y fier.
Une ligne de cette liste fait plus de travail qu’il n’y paraît. Le site vers lequel pointe une planification est estampillé côté serveur depuis la session active, jamais lu depuis la requête, parce qu’un appelant capable de le définir pourrait viser une exécution planifiée vers un autre site tout en détenant l’identifiant de quelqu’un d’autre.
Tout cela est ordinaire. C’est la seule partie de la gestion des identifiants qu’aucune interface n’invite jamais personne à faire. Écrivez-le une fois et gardez-le.
Deux identifiants Tableau qui font deux métiers différents. L’un porte les permissions d’une personne. L’autre étend une capacité de la plateforme. Choisir le bon garde aux commandes de qui voit quoi un modèle de permissions que vous avez mis des années à construire.
Une personne s’en va. Son nom reste sur des classeurs, des planifications et des abonnements, et plusieurs d’entre eux tombent en panne sans un bruit. Ce qu’elle détient, ce qui casse, et l’ordre qui garde la licence récupérable.
Une affirmation est une phrase. Une preuve est quelque chose qu’une seconde personne peut vérifier sans vous demander. Ce qu’une piste d’audit doit contenir, ce qu’un hachage prouve réellement, et ce qu’il faut exiger de tout outil qui prétend en produire une.