個人用アクセストークンと生きる：所有、期限、ローテーション

すべてのトークンは人に属する

個人用アクセストークンは名前のある人に、その人の名前で発行され、その人がすでに持つ Tableau パーミッションを正確に運びます。それがガバナンス境界を築く価値のあるものにしています：それで行われることはすべて所有者がどのみちできたことで、下流のすべての監査行はその名前を正直に運びます。

それはトークンを、技術的なオブジェクトではなく管理上のオブジェクトにもします。所有者がいて、所有者にはチームがあり、チームには当番表があります。このページのほぼすべての厄介なことは、そのひとつの事実から続きます。

持つ価値のある最初のアーティファクトは登録簿です：トークンごとに一行、それが動かすジョブ、それに責任を負う人、保存場所、期限日を記して。4行は書くのに10分で、さもなければ午前ひとつかかる問いに答えます。それはこういう問いです：これを失効させたら、何が止まるか。

トークンごとに1つのライブセッション、そしてそれを織り込んで計画する

Tableau Cloud はトークンごとに1つのライブセッションを許します。そのトークンを使う新しいサインインは、その前のセッションを終わらせます。ひとりが使っている間は快適で、2つのものが使った瞬間に厄介になります。

スイートはその振る舞いに逆らうのではなく、それを中心に作られています。ゲートウェイは一度サインインし、単一の Tableau セッションを発行し、そのひとつのセッションを各ツールに渡します。ツールは、同じトークンでそれぞれ再びサインインして前のサインインを無効にする代わりに、それを共有します。

同じルールが長いジョブの振る舞いを形作ります。Cloud のソースに対する移行実行が承認される前に、事前チェックのプレビューがはっきりそう言います：この実行専用のトークンを、他の何も使わない名前で使い、スケジュール、ブラウザタブ、2台目のデバイスがそれを共有していないことを確かめてください。実行は認証の失敗を間隔を置いたラウンドで再試行します：1回の衝突は生き残れますが、同じトークンでサインインし続けるクライアントはやはりそれを飢えさせます。Server のソースはひとつのトークンでの同時セッションを許容するため、何年も無害だった習慣が、初めての Cloud 実行でチームを驚かせることがあります。

スケジュールされたジョブと人が互いに干渉しているように見えるのは、たいていこれで、断続的な製品の不安定さとして現れ、実際にはそうである認証情報の問題にはめったに見えません。他の何かを調べる前に、各側がどのトークンを持っているかを確かめてください。

期限が自動化に何をするか

トークンには期限があり、その上に築かれた自動化は、二度と口にすることなくその日付を継承します。失敗は期限切れの瞬間ではなく、次のスケジュール実行で届きます。トークンが死んでから誰かがそれを聞くまでの隙間は、丸々ひとつの周期です。月次のジョブなら、それはひと月です。

2つの設定は、想定するのではなく自分のサイトで読む価値があります：トークン発行時に管理者が設定した期限と、使われずに置かれたトークンにサイトが何をするか。四半期ごとのジョブを動かすトークンは一生の大半を遊んで過ごし、それがチームを引っかける組み合わせです。

スケジュール実行が個人用トークンからサービス認証情報にフォールバックできるところでは、設計上の対応は小さく決定的です：どの認証情報が実際に認証したかが実行に記録され、行に表示されます。その記録がなければ、静かなフォールバックは修理されないままで、問題はフォールバック自体が失敗したときにだけ表面化します。

失敗した実行も次の発火を準備します：進まなくなったスケジュールは永久に期限到来のままで、ランナーはそれに手を伸ばし続けます。

トークンの所有者が去るとき

アカウントが消え、トークンもともに消えます。それは正しい振る舞いで、同時に、退職者チェックリストのどこにも現れないまま、いくつもの無人ジョブが一斉に止まる瞬間でもあります。

Tableau サイトの人は6種類のものを所有できます：ワークブック、パブリッシュ済みデータソース、フロー、プロジェクト、サブスクリプション、更新タスク。トークンは7つ目で、他の6つと違い、トークンはどのプロジェクトツリーにもまったく現れません。その人が所有するコンテンツを扱うのと同じ1時間の中で扱ってください。さもなければ、スケジュールが代わりに見つけてくれます。

• 再割り当てにはコンテンツを所有できる相手が要ります：Creator ティアのロール、パブリッシュを許された Explorer、または管理者ロール。その集合の外の相手はロールの不一致で、実行が途中まで進んでからではなく、計画の段階で捕まえる価値があります。
• すべての項目に名前のある新しい所有者が付きます。再割り当ての相手は常に必須です：コンテンツは動かされ、途中で削除されることはありません。
• 埋め込まれた認証情報を運ぶコンテンツは別にフラグが立ちます。データソースを新しい所有者に渡しても、その接続は再認証されないからです。
• ライセンスは解放されるときに記録する価値があります。サイトロールはティアに対応し、実行は回収されたものを記録します。3か月後に財務との会話が尋ねる数字です。

オフボーディングとトークンの衛生は、両端から見た同じ規律です。各トークンに責任を負う人を名指しする登録簿は、退職者の会話を調査ではなく参照に変えます。

作業を動かしたままトークンをローテーションする

ローテーションは交換として行うとうまくいきません。重ね合わせとして行えば、何事もなく済みます。

1. まず新しいトークンを発行する。動かすジョブの名前で、その場で書き留める新しい期限とともに。
2. 古いトークンがある場所にインストールする。インストールは前の認証情報に加わるのではなく、置き換える。
3. ジョブを一度手で実行し、行を読む。個人用トークンが認証したと言っていなければならず、サービス認証情報ではない。
4. その行が緑になってから初めて、古いトークンを失効させる。
5. 新しい期限を共有カレンダーに2週間早く入れ、その項目をリマインダーではなく作業そのものとして扱う。

インストールの段階は、作業が進行中でも安全に行えます。固定された認証情報は一時ファイルに書かれてから所定の場所に移されるので、ローテーションの最中に始まった実行は、古い認証情報か新しい認証情報のどちらかを読み、ファイルの半分を読むことは決してありません。

3つ目の段階が人の飛ばすもので、何かを証明する唯一の段階です。実行がサービス認証情報で成功したなら、個人用トークンはすでに壊れていて、ローテーションは何もテストしておらず、あなたはたった今、証拠を失効させたところです。

ホスト型のデプロイメントで管理者がトークンを固定しているところでは、サインアウトの操作は意図的に隠されています。次のページ読み込みがどのみち再接続するからです。その認証情報は代わりに管理コンソールで変えます。探す人が思いつく場所です。

誰もサインインしていないとき、認証情報はどこにあるか

このスイートの秘密はセッション限りで、それは誰もいない午前2時半にジョブを動かさなければならなくなるまで、きれいに成り立ちます。例外は明示的で、狭く、頼る前に理解しておく価値があります。

• スケジューラーはスケジュール、周期、保持を保持します。意図的に、自身の認証情報は保持しません。
• 秘密はサーバー側で解決され、サインインし、目当てのものを取得し、再びサインアウトする短命のエンドポイントに渡されます。
• 固定されたトークンは保存時に暗号化され、決してログに書かれず、ブラウザに二度と返されません：ステータス呼び出しはトークンの名前だけを返します。クリックひとつで削除できます。
• マシンキーのもとで、各ユーザースコープは固有の導出キーで自身の認証情報を封印します。ある人のトークンは、別の人のものを使って読めません。

そのリストの一行は、見た目以上の仕事をしています。スケジュールが指すサイトはリクエストから読まれるのではなく、ライブセッションからサーバー側で刻印されます。それを設定できる呼び出し側は、他人の認証情報を持ったまま、スケジュール実行を別のサイトに向けられてしまうからです。

忙しい四半期を生き残るルーティン

1. 誰かが加わったり去ったりしたときに登録簿をレビューする。誰も守らない四半期ごとの周期ではなく。
2. すべての無人ジョブに固有のトークンを与える。人と共有することが、誰も説明できないサインアウトを生む。
3. スケジュール実行に記録された認証情報を月に一度読む。2分で、静かなフォールバックが表面化する唯一の場所です。
4. 重ね合わせでローテーションする：発行し、インストールし、1回の実行を証明し、それから失効させる。
5. 失効させたトークンの行を残し、その隣に日付を書く。履歴が、次の調査を短くするものです。

すべてが普通のことです。認証情報の管理のうち、どのインターフェースも誰にも促さない唯一の部分です。一度書き留めて、保ってください。