Tailscaleのtailnet lockが保護する範囲

Tailnet lock が保護する範囲

Tailnet lock は、Tailscale 自身の coordination server がデバイスを tailnet に追加することを阻止する Tailscale の機能です。有効にすると、ノードは、すでに信頼しているマシンに保持された鍵で署名されていない node key を拒否します。そのため、control plane は引き続き鍵を配布できますが、メンバーを新たに作成することはできません。この主張の範囲を限定しているのは意図的なものです。Tailnet lock が保護するのはデバイスが参加する時点であり、鍵をすでに盗まれたデバイスには何も作用しません。

通常の tailnet では、各ノードが独自の WireGuard 鍵を生成し、秘密鍵を外部に送信することはありません。すべてのクライアントが接続する control plane である coordination server は公開鍵を配布し、各ノードに所属メンバーを通知します。これは Tailscale の coordination server と鍵の配布 が基盤とする設計であり、Tailscale がトラフィックを暗号化する鍵を保持しない理由でもあります。一方で、control plane がメンバーシップを単独で決定することも意味します。control plane を掌握した攻撃者は、追加の node key を tailnet に公開できます。プロトコルには、注入された鍵と正規の鍵をノードが見分ける仕組みがないため、ノードはその鍵に対しても暗号化してしまいます。

脅威モデルを正確に定義する

tailnet lock が想定する攻撃者は、coordination server を制御できる主体です。Tailscale のインフラの侵害、同社内部の悪意ある関係者、Tailscale に行動を強制する命令が該当します。この攻撃者に対してのみ、tailnet lock は「ノードを追加できる」から「追加できず、その試みを検出できる」へと結果を変えます。

仕組みは、利用者が管理する署名チェーンです。各 signing node は tailnet lock key (TLK) をローカルで生成し、そのデバイス内に保持します。tailnet には、権限の更新を追記専用で記録する tailnet key authority (TKA) が作成され、各ノードはそのログのコピーを保持します。現在信頼されている TLK による有効な署名なしで到着した node key は拒否されるため、その peer は接続できず、locked out として表示されます。Tailscale の white paper は結果を明確に示しています。tailnet lock を有効にした tailnet に対して、Tailscale のインフラは未承認のノードを追加できず、その試みは検出してブロックできます。

ただし、対象外となる点が 4 つあります。ほとんどの tailnet では、対象となる脅威よりも、次の 4 つのほうが重要です。

• 盗難されたデバイス。 署名から分かるのは、信頼された管理者がある時点でその node key を承認したことだけです。現在その laptop を誰が所持しているかは分かりません。
• 侵害された signing node。 Tailscale 自身の制限事項にも明記されています。tailnet lock key はデバイス内に保存されるため、デバイスを取得した攻撃者はその key も取得できます。signing node は、root SSH key を保持するマシンと同じように扱う必要があります。これは SSH key の生成、保存、ローテーション で説明した運用と同じです。
• サービス拒否。 white paper では、tailnet lock が保護するのは未承認ノードであり、サービス拒否ではないと明記されています。悪意のある control plane は、更新の配布を停止して接続を切断できます。ただし、tailnet のメンバーになることはできません。
• 最初の 5 分間。 次のセクションで説明します。ここは見落とされやすい部分です。

tailnet lock が trust on first use である理由

tailnet lock を有効にすると、最初の信頼済みキーのセットは、信頼の対象から外そうとしている相手である control plane を経由して各ノードに届きます。各ノードは初回に通知された内容を受け入れ、その後はそれを適用します。Tailscale のホワイトペーパーでは、この欠落を次のように説明しています。tailnet lock を初めて有効にしたとき、各ノードは control plane から送信された tailnet lock の初期状態に依存します。その時点ですでに control plane が侵害されていれば、攻撃者のキーを含むキーセットを登録でき、その後の署名はすべて正当なものとして検証されます。

これは trust on first use（TOFU）です。初回接続時に受け入れる SSH ホストキーのフィンガープリントと同じモデルです。照合する外部の認証機関はないため、確認は手動で行う必要があり、実施するのはあなたです。

tailscale lock status

有効化した後、複数のノードでこれを実行します。各ノードが報告する信頼済みの tlpub: 値を、署名ノードが実際に出力したキーと比較します。確認に使う通信経路は tailnet に依存しないものにしてください。悪意のあるキーセットを登録した control plane は、確認に使っているチャットの内容も見られるためです。これは 10 分で終わる一度だけの作業であり、何も保護していない lock とあなたの間にある唯一の防壁です。

有効化する前に確認すること

• 継続して使用するすべてのノードで、Tailscale v1.46.1 以降が必要です。これは、Tailscale のドキュメントで tailnet lock に必要な最小バージョンとして示されているバージョンです。各ノードで tailscale version を実行してください。一度登録したまま忘れがちな router や appliance も対象です。
• signing node は少なくとも2台選択する必要があります。これは形式的な要件ではありません。signing key はこれらのデバイス上に保存されるため、signing node が1台だけだと、そのディスクが故障しただけで、tailnet に新しいマシンを追加できなくなります。
• Android デバイスは signing node として使用できません。署名処理を実行できないためです。
• tailnet lock と device approval は相互排他的な機能です。tailnet ですでに手動のデバイス承認を必須にしている場合、両方を併用するのではなく、どちらかを選択する必要があります。
• Tailscale のドキュメントでは、2026年9月時点で Personal プランと Enterprise プランに tailnet lock が掲載されています。セキュリティレビューでこの制御を導入すると約束する前に、利用中のプランを確認してください。

tailnet lock を有効にする方法

管理コンソールがコマンドを生成し、管理者がそれをマシン上で実行します。どちらか一方だけでは機能しません。

1. 管理コンソールで Device management ページを開き、tailnet lock を有効にします。
2. tailnet lock のキーを信頼するノードを選択します。物理的にアクセスできるハードウェア上のノードを、少なくとも2台選びます。
3. 無効化用 Secret を1つ Tailscale support に送信するか決めます。回答する前に、次のセクションを読んでください。
4. コンソールが生成した tailscale lock init コマンドをコピーします。このコマンドには、選択した署名ノードごとに1つの tlpub: 引数が含まれます。
5. その署名ノードのいずれかで実行します。

tailscale lock init "tlpub:SIGNING_NODE_1_KEY" "tlpub:SIGNING_NODE_2_KEY"

tailnet 内にすでに存在するすべてのノードは、初期化時に信頼済みキーで署名されるため、正常に動作していたものが停止することはありません。変わるのは新しいノードです。ロックされた tailnet に参加するマシンには、署名されていないノードキーが設定されます。そのマシン上で tailscale lock status を実行すると、その状態が表示されます。

This node is LOCKED OUT by tailnet-lock, and action is required to establish connectivity.

管理コンソールにも同じ状態が Locked out バッジで表示されます。machines-list フィルターの property:locked-out を使うと、該当するノードを一度にすべて検索できます。ロックアウトされたノードのステータス出力には、修正に必要なコマンドも正確に表示されます。その行をコピーし、署名ノードで実行します。

tailscale lock sign "nodekey:NODE_KEY" "tlpub:ROTATION_KEY"

署名ノードは時間とともに変わるため、2つのコマンドを使い分けます。tailscale lock add tlpub:<key> は新しい署名ノードを信頼します。tailscale lock remove tlpub:<key> は署名ノードを退役させます。デフォルトでは、退役したキーが署名したノードに再署名するため、それらのノードは動作し続けます。これを抑止するには --re-sign=false を指定します。署名ノードが退役ではなく盗難に遭った場合は、tailscale lock revoke-keys tlpub:<key> が必要です。このコマンドは、残りの署名ノードで --cosign と --finish を使いながら段階的に実行されます。tailscale lock log --limit 20 では直近の権限履歴が表示されます。ノードがロックアウトされ、誰も変更を覚えていない場合は、ここを確認します。

無効化シークレット10個と、そこがリスクになる理由

tailscale lock initは、無効化シークレットを10個表示します。これらは初期化時に1度だけ表示され、その後は二度と表示されません。どれか1つを使うだけで、tailnet 全体で tailnet lock が無効になります。

tailscale lock disable "DISABLEMENT_SECRET"

Tailscale のドキュメントには、その結果が明確に記載されています。無効化シークレットをすべて失い、Tailscale サポートにも1つ提供していなければ、tailnet は復旧できません。実際の状況を考えてみてください。2台の署名ノードは、消去されたノート PC と削除された VPS です。新しいノードキーに署名することも、署名ノードを追加することも、ロックを無効にすることもできません。tailnet は既存メンバーに対して動作し続けますが、新しいメンバーは永久に受け入れません。解決するには、新しい tailnet を構築し、すべてを再登録する必要があります。

そのため、シークレットはリカバリコードと同じように保管してください。少なくとも2つのコピーを、どちらも tailnet に到達できることに依存しない場所に保管し、そのうち1つはオフラインで保管します。tailnet 経由でしかアクセスできないサーバーに保存したコピーは、バックアップとは呼べません。

サポートにシークレットを提供するかどうかは、デフォルトのままにせず、実際に判断してください。シークレットを1つ Tailscale サポートに送ると、Tailscale は tailnet lock を無効にできます。これは、この機能が制限するために存在する相手に、保証の一部を戻すことになります。一方で、保管していたファイルや台帳を失っても tailnet が終わることはありません。VPN ベンダーが侵害された場合にどうなるかを第三者リスクのレビューで確認されたため tailnet lock を有効にしたのであれば、シークレットを送らないでください。管理者の入れ替わりに備え、ノードの参加をデバイスに結び付けたいという理由で有効にしたのであれば、シークレットを送り、安心して運用できます。

自動プロビジョニングが失敗する理由と修正方法

これは、チームが 1 週間以内に直面する問題です。ロックされた tailnet では、起動して tailscale up を実行するマシンが通常の auth key で参加すると、アクセスを拒否された状態になります。自動化処理は成功を報告し、ノードはコンソールに表示されますが、何もそのノードに到達できません。署名はノードの作成後ではなく、作成前に行う必要があります。つまり、auth key に署名します。

AUTH_KEY="tskey-auth-xxxxxxxxxxxxxxxx"
tailscale lock sign $AUTH_KEY

この処理は signing node で実行します。署名済みの auth key が出力されます。この署名済みの値を、イメージ、cloud-init ファイル、または Terraform 変数から tailscale up --auth-key に渡します。この値で作成したノードは、署名済みの状態で参加するため、すぐに到達可能になります。

問題に遭遇する前に、2 つの失敗パターンを把握しておくと役立ちます。1 つ目は、署名処理が並行実行に適していないことです。tailscale/tailscale リポジトリの Issue 15266 では、2025 年 3 月に報告された事例として、並行する tailscale lock sign の呼び出しが空の署名済みキーを返した Terraform 実行について説明されています。この結果、一部のノードはアクセスを拒否された状態で起動し、残りは正常に動作しました。報告者は、呼び出しの間に短い待機時間を設け、1 回につき 1 つのキーだけを署名する方法で回避しました。自動化処理では、キーを保存する前に、コマンドが空でないキーを返したことを確認してください。

2 つ目は、署名済み auth key が状態を残すことです。署名すると authority にキーが追加され、そのキーは作成したノードを削除した後も残ります。2025 年 7 月の Issue 16607 では、デプロイメントごとに新しいキーへ署名する自動化処理が、authority の上限に達した事例を説明しています。

network-lock modify failed: modify network-lock keys: generating checkpoint: generated update was invalid: checkpoint state: too many keys (552, max 512)

この時点では、tailnet にキーを追加することも、余分なキーを削除することもできません。削除自体が authority の更新であり、有効な checkpoint の生成が必要だからです。マシンごとに署名するのではなく、少数のキーに署名して再利用してください。また、tailscale lock log を定期的に確認し、キー数を把握しておくことが重要です。知らないうちに上限へ達して初めて気付く状態は避けてください。

一時ノードと CI ノードには計画が必要です

ログアウト時に tailnet から自分自身を削除する一時ノードもノードです。そのため、他のノードと通信するには署名が必要です。デプロイを実行するために tailnet に参加する CI ジョブには、長期間稼働するサーバーと同じように、事前署名済みの認証キーが必要です。CI ではノードの作成と削除が最も多く発生するため、前述のキーの蓄積による問題も特に深刻になります。

実用的な構成は、署名済みで再利用可能な一時認証キーを 1 つ用意し、CI の Secret ストアに保存する方法です。キーは各ジョブではなく、決めたスケジュールでローテーションします。ローテーションのたびに権限側でキーを 1 つ消費します。この数は事前に計画できます。ジョブごとに署名すると、552 個のキーが生成されます。

同じ考え方は、他のマシンのトラフィックを中継するサーバーにも当てはまります。VPS からプライベート範囲を広告するサブネットルーターは、その背後にあるすべてのアドレスを代理します。その位置に挿入されたノードは、1 台のホストを大きく超える範囲に到達できます。署名済みキーでプロビジョニングし、完全自動化された処理経路から外すべきなのは、このようなサーバーです。

2 つの緊急解除方法と、それぞれの動作

tailscale lock disable <disablement-secret> は tailnet 全体で tailnet lock を無効にします。10 個の秘密のいずれかが必要です。authority 自体に問題がある場合に使用します。

tailscale lock local-disable

tailscale lock local-disable はノード単位の解除方法ですが、その適用範囲は誤解されがちです。実行したノードで tailnet lock の強制を停止するため、そのノードは署名されていない鍵を持つピアを受け入れるようになります。ただし、他のノードがそのノードの署名されていない鍵を受け入れるようになるわけではありません。接続を拒否されたサーバーで local-disable を実行しても、そのサーバーに到達できるようにはなりません。そのため Tailscale のドキュメントでは、tailnet が実質的に tailnet lock を無視するよう、各ノードでこのコマンドを実行するよう説明しています。現在署名できないノードに対する緊急解除手順として使用し、その後でノードに適切な署名を付け、強制を無効にしたままにしないでください。

tailnet lock を有効にすべき人と、すべきでない人

人が離職した後もノードの追加制御を維持する必要がある場合は、有効にしてください。tailnet lock がない場合、コンソールで管理者権限を持つ人なら誰でもマシンを追加できます。tailnet lock を有効にすると、マシンの追加には信頼済みの署名キーを保持するデバイスも必要になります。そのため、退職した管理者のコンソールアクセスを無効化し忘れても、その管理者がノードを追加することはできません。顧客の第三者リスクに関する質問票で、VPN ベンダーがネットワークに参加するのを何が防ぐのか尋ねられる場合も、有効にしてください。この制御なら、約束ではなく仕組みで回答できます。

ノート PC、スマートフォン、VPS だけを使う1人構成の tailnet では、有効にしないでください。その tailnet に対する現実的な脅威は、Tailscale が侵害されることではなく、自分が tailnet へのアクセスを失うことです。tailnet lock では、正しく保管し続ける必要がある秘密情報が10個追加されます。それらを失うと復旧できません。直面していないリスクを下げるために、実際に直面しているリスクを高めることになります。どの署名デバイスを誰が保持しているかを管理できていない小規模チームにも、同じことが当てはまります。まずその台帳管理を整えてください。tailnet lock は、恒久的な障害モードを伴う台帳管理だからです。

Headscale は別の方法で同じ問いに答えます

第三者がネットワークのメンバーを決めることが問題であれば、答えは 2 つあります。Tailnet lock を使うと、Tailscale の調整サーバーは残したまま、メンバーを追加する権限を取り除けます。自分でホストするオープンソースの調整サーバー Headscale を運用する場合は、サーバー自体を置き換えます。その代わり、サーバーを運用する権限と作業の両方を自分で担います。パッチ適用、バックアップ、そして午前 2 時に自分で復旧する障害対応が必要です。どちらが抽象的に見てより安全というわけではありません。自分で引き受けたい障害を基準に選んでください。制約を加えたホスト型のコントロールプレーンを使うか、自分で運用するコントロールプレーンを使うかの選択です。

FAQ

tailnet lock は何を実際に阻止しますか？

Tailscale の coordination server が tailnet にノードを追加することを阻止します。tailnet lock を有効にすると、ノードキーは、管理下にある signing node が tailnet lock key で署名した後にのみ受け入れられます。そのため、侵害された control plane はキーを配布できても、メンバーを追加することはできません。ノード間の通信は、coordination server が保持しない WireGuard key によってすでにエンドツーエンドで暗号化されているため、追加の暗号化を行う機能ではありません。また、デバイスの盗難、signing node の侵害、tailnet へのサービス提供を単に停止する control plane への対策にもなりません。

10 個すべての disablement secret を失うとどうなりますか？

secret は tailscale lock init の実行時に 1 回だけ表示され、その後は再表示されません。すべてを失い、Tailscale support にも 1 つ送っていない場合、ドキュメントでは tailnet を復旧できないとされています。実際には signing node も失うと、別のノードキーに署名できず、lock を無効化することもできません。そのため、先に進む唯一の方法は、新しい tailnet を作成し、すべてのデバイスを再登録することです。tailnet が稼働していなくても利用できる場所に 2 部を保管し、そのうち 1 部はオフラインで保管してください。

新しいデバイスごとに手動で署名する必要がありますか？

いいえ。ノードではなく auth key に署名します。signing node でキーをエクスポートして tailscale lock sign $AUTH_KEY を実行し、コマンドが表示する署名済みの値を、イメージまたはプロビジョニングツール内の tailscale up --auth-key に渡します。この方法で作成したノードは、署名済みの状態で参加します。マシンごとに 1 つずつ作成するのではなく、再利用可能なキーを少数だけ署名してください。署名済みキーを追加するたびに、ノードの削除後も残る authority にキーが追加されるためです。また、authority には 512 個のキー上限があり、実際の運用で自動化によって上限に達した例があります。

tailnet lock は device approval と同じですか？

いいえ。両者は相互排他的な機能のため、同時に実行することはできません。device approval は admin console で行うポリシーチェックです。新しいデバイスにアクセスを許可する前に管理者がチェックボックスを選択し、coordination server がその判断を適用します。tailnet lock は、自分のノードが、自分のハードウェアに保管したキーを使って実行する暗号学的なチェックです。そのため、coordination server が悪意を持つ場合でも機能します。device approval は、人を管理するための軽量な制御です。tailnet lock は、ベンダーについて問われる問題に答える機能です。