セキュリティのベストプラクティス
最終検証日：
翻訳: 竹洞 陽一郎
Tailscaleには、ネットワークを堅牢化するためのセキュリティ機能が多数あります。
このドキュメントでは、それらの機能を効果的に活用するためのベストプラクティスをまとめます。
Tailscale自体のセキュリティアーキテクチャや内部的な保護策の概要については、Tailscaleのセキュリティ（英語）を参照してください。
基本的な対策
基本的な対策は、適用範囲が広く、費用対効果の高いセキュリティ向上策です。
Tailscaleクライアントを速やかに更新する
- 新機能とセキュリティ修正を受け取るために、Tailscaleクライアントを最新の状態に保ってください。
- アップデート確認機能を使うと、ネットワーク上の各デバイスにインストールされているクライアントのバージョンを把握できます。
- 自動更新を有効にすれば、クライアントの更新を自動化できます。
詳細は、クライアントの更新（英語）を参照してください。
セキュリティ情報を購読する
Tailscaleは、プラットフォームに影響する脆弱性情報を公開しています。
セキュリティ情報のRSSフィードを購読してください。
アカウントに連絡先が登録されている場合は、直接通知も届きます。
セキュリティ問題の通知先メールアドレスを設定する
- 連絡先設定で、セキュリティ問題の通知先メールアドレスを設定してください。
- 設定していない場合、Tailscaleはtailnetのオーナーのメールアドレスを既定の通知先とします。
- 複数の管理者に通知するには、
security@example.comのようなメーリングリストのアドレスを使ってください。
GitHubをIDプロバイダとして使っている場合、通知を受け取るにはメールアドレスを手動で追加する必要があります。
設定手順は、連絡先設定（英語）を参照してください。
IDプロバイダでMFAを有効にする
Tailscaleの認証に使うIDプロバイダ側で、多要素認証（MFA）を有効にしてください。
可能であれば、ハードウェアトークンを用いたMFAを優先してください。
Tailscaleは、MFAポリシーを含めてIDプロバイダの認証設定をそのまま引き継ぎます。
詳細は、多要素認証（英語）を参照してください。
アクセス制御ポリシーを定義する
- 職務内容と最小権限の原則に基づいて、アクセスルールを作成してください。
- アクセス制御ポリシーでは、どのユーザー、グループ、IPアドレス、CIDR、ホスト、タグが相互に通信できるかを指定します。
- IPアドレスベースのルールではなく、ユーザーのアイデンティティに基づくロールベースのアクセス制御を実装してください。
アクセス制御ポリシーでグループを使う
ポリシーファイル内で、職務内容ごとにユーザーをグループにまとめてください。
ユーザーとグループのプロビジョニングを有効にすれば、IDプロバイダのグループを自動的に同期できます。
同期されたグループを使うことで、従業員の異動や退職の際のアクセス管理が容易になります。
グループの定義方法は、tailnetポリシーファイルの構文リファレンスを参照してください。
アクセス制御ポリシーでタグを使う
- デバイスの所有者ではなく、用途に基づいてタグを割り当ててください。
- デバイスのタグは所有者が変わっても維持されるため、再設定の手間を減らせます。
- 認証キーを使って、デバイスの認証時にタグを付与できます。
詳細は、タグの利用を参照してください。
Tailscale SSHでcheckモードを使う
リスクの高いSSH接続や、特権ユーザーによるアクセスには、再認証を要求してください。
checkモードでは、アクセスを許可する前に再認証を求め、その後12時間（または指定した期間）は再認証なしで接続できます。
この機能はTailscale SSHの接続にのみ利用できます。
設定は、アクセス制御ポリシーのSSHルールでactionフィールドにcheckを指定します。
詳細は、Tailscale SSHを参照してください。
Tailscale SSHでセッション録画を使う
- セッションレコーダーは、tailnet内にDockerコンテナとして配置します。
- 録画データはレコーダーノードへ直接ストリーミングされ、Tailscaleのインフラストラクチャがその内容にアクセスすることはありません。
- 録画の保存先には、Dockerホストのディスク、またはAmazon S3およびS3互換サービスを設定できます。
- この機能はTailscale SSHの接続にのみ利用できます。
詳細は、Tailscale SSHセッション録画（英語）を参照してください。
構成監査ログを確認する
構成監査ログには、tailnetの設定変更が、実行者・アクション・対象リソース・タイムスタンプとともに記録されます。
管理操作を監視するために、定期的にログを確認してください。
長期保管が必要な場合は、Tailscale APIを使ってログをエクスポートできます。
詳細は、構成監査ログを参照してください。
tailnetのイベント通知を受け取る
Webhookを使って、tailnetのイベントを購読できます。
ポリシーファイルの更新、ノードの追加、ユーザー管理の変更などのイベントに対応しています。
通知はSlackなどの外部アプリケーションへ送信できます。
詳細は、Webhooks（英語）を参照してください。
退職時にユーザーをオフボーディングする
- 退職するユーザーは、オフボーディング手続きの一環として停止または削除してください。
- オフボーディングにより、デバイスの認可、APIキー、認証キーへのアクセス権が失効します。
- IDプロバイダとの連携により自動化することも、手動で停止することもできます。
- 手順は、IDプロバイダの種類やSCIMの利用有無によって異なります。
詳細は、ユーザーのオフボーディング（英語）を参照してください。
高度な対策
高度な対策は、すべての環境に当てはまるとは限りません。
設定の手間が大きいものや、セキュリティ・ネットワークに関する高度な知識を要するものも含まれます。
テストを使う
アクセス制御ポリシーが意図どおりに機能するかを検証するテストを記述してください。
テストにより、ポリシー更新後に権限を誤って失効させたり、意図せずリソースを露出させたりする事故を防げます。
テストは、アクセス制御ポリシーのファイル内に記述します。
記述方法は、tailnetポリシーファイルの構文リファレンスを参照してください。
Adminロールを割り当てる
- ロールベースのアクセス制御を使って、管理業務を分担してください。
- 利用できるロールは、Admin、Network admin、IT admin、Billing admin、Auditorです。
- 各ロールは、変更できる設定の範囲がそれぞれ限定されています。
- 設定は、管理コンソールのUsersページで行います。
詳細は、ユーザーロールを参照してください。
デバイス承認を有効にする
新しいデバイスがネットワークへアクセスする前に、手動での確認と承認を必須にできます。
デバイス承認により、信頼された業務管理下のデバイスだけが接続する状態を確保できます。
設定は、管理コンソールのDevice managementページで行います。
ノードキーの有効期限をカスタマイズする
一定間隔での再認証を強制することで、キーの定期的なローテーションを実現できます。
既定の有効期限は180日です。
より厳格な要件がある組織は、この期間を短縮できます。
設定は、管理コンソールのDevice managementページで行います。
詳細は、キーの有効期限を参照してください。
ネットワーク境界を保護する
Tailscale以外の通信を制限するため、ネットワークとデバイスの両方のレベルでファイアウォールを配置してください。
Tailscaleはノード間の通信をエンドツーエンドで暗号化しますが、Tailscale以外の通信を保護するものではありません。
ネットワーク全体を保護するには、ファイアウォールの設定が不可欠です。
詳細は、ファイアウォールとの連携（英語）を参照してください。
Tailscaleで必要となるポートについては、必要なファイアウォールポートも参照してください。
HTTPSを有効にする
社内向けのWebサービスにも、パブリックな認証局が発行するTLS証明書を使ってください。
公的に検証可能なTLSにすることで、ブラウザのセキュリティ警告を避けられ、利用者の体験も改善します。
Tailscaleのノード間通信はエンドツーエンドで暗号化されていますが、ブラウザは検証可能な証明書を必要とします。
設定は、管理コンソールのDNSページで行います。
証明書は証明書の透明性（Certificate Transparency）ログに記録されるため、マシン名に機密情報を含めないでください。
オンデマンドアクセスを使う
ジャストインタイムのアクセス要求を導入すると、一時的で取り消し可能なリソースアクセスを付与できます。
Tailscaleが対応するオンデマンドアクセス製品と連携させて利用します。
Tailscaleが制御するリソースへのアクセス管理に適しています。
詳細は、ジャストインタイムアクセスを参照してください。
使っていないOAuthクライアントを削除する
不要になったOAuthクライアントは、定期的に棚卸しして削除してください。
使われていないクライアントは、認証情報が漏洩した場合のリスクとなります。
管理は、管理コンソールのTrust credentialsページで行います。
使っていないAPIキーと認証キーを削除する
不要なAPIキーと認証キーは、定期的に棚卸しして削除してください。
キーが漏洩すると、不正なユーザーやデバイスを追加される可能性があります。
1台のデバイスを認証するだけの場面では、使い捨ての認証キーの利用を検討してください。
管理は、管理コンソールのKeysページで行います。
詳細は、認証キーを参照してください。
DNSリバインディング攻撃を防ぐ
HTTPサービスへの受信リクエストでは、HTTPのHostヘッダーを検証してください。
DNSリバインディング攻撃は、悪意のあるWebページがクライアント側のスクリプトを実行し、tailnet内のノードを攻撃する手法です。
HTTPS化されていないHTTPサービスが影響を受けます。HTTPSサービスには組み込みの保護が働きます。
HTTPリクエストの処理では、Hostヘッダーの許可リストを実装してください。
GET /resource HTTP/1.1 Host: www.example.com
MagicDNSを使う場合は、次のようなHostヘッダーになります。
Host: webserver.example2.ts.net
GitOpsでアクセス制御ポリシーの更新を管理する
- tailnetポリシーファイルを管理コンソールの外にあるコードリポジトリで保管し、そちらを正とします。
- 保護ブランチとレビュー必須の設定により、ポリシー変更を統制します。
- アクセス制御の変更にバージョン管理と監査証跡を残せます。
- GitHub ActionsとGitLab CIに対応しています。
- 承認の一元化と、適用前のテスト実行の必須化という利点があります。
詳細は、GitOps（英語）を参照してください。
Infrastructure as CodeでTailscaleを構成する
- IaCツールを使って、Tailscaleのインフラをプログラムから展開・管理します。
- 障害時に、一貫した構成や以前の構成へ迅速に切り替えられます。
- TerraformとPulumiに対応しています。
- ポリシーファイル、DNS設定、認証キーの生成、デバイスのプロパティなどを設定できます。
- APIへのアクセスをIaCツールに限定することで、構成管理を一元化できます。
詳細は、Terraformプロバイダー（英語）およびPulumiプロバイダー（英語）を参照してください。
デバイスポスチャを使う
デバイスポスチャチェックにより、デバイスの信頼性を評価できます。
クライアントのバージョン、OS、ディスク暗号化といったセキュリティ関連の属性に基づいて、アクセスを制限できます。
Enterpriseプランでは、地理的位置に基づくアクセス制限も利用できます。
リモートワークのセキュリティ確保、BYODポリシー、ゼロトラストの実装といった用途に適しています。
詳細は、デバイスポスチャを参照してください。
ネットワークフローログを使う
- ネットワークフローログを有効にすると、ノード間の接続パターンを分析できます。
- クライアントが必要なバージョンであり、かつロギングが有効（
--no-logs-no-supportモードではない）である必要があります。 - ログはTailscale API経由で取得します。
- 定期的にログを確認してください。
- 長期的な分析や保管のために、ログをエクスポートしてください。
詳細は、ネットワークフローログを参照してください。
マルチユーザーシステムでの利用を制限する
複数ユーザーが使うデバイスでTailscaleを共有すると、ユーザー間でアクセスが及ぶリスクが生じます。
これはLinux、Windows、macOSのいずれにも当てはまります。
ユーザーがログアウトせずにアカウントを切り替えた場合、アクセスが共有された状態になります。
組織としてtailnetへのアクセス共有を許容できる場合を除き、Tailscaleの導入は単一ユーザーのデバイスに限定することを推奨します。