グラント
最終検証日：
翻訳: 竹洞 陽一郎
グラントは、ネットワーク層とアプリケーション層の権限を統一されたフレームワークに統合する、Tailscaleの拡張されたアクセス制御システムです。
グラントを使うと、各ユーザーやデバイスがアクセスできるリソースと、接続後に実行できる操作を正確に定義できます。
グラントは、ゼロトラストと最小権限の原則に沿った、Tailscaleのデフォルト拒否（deny-by-default）のアプローチに従います。
グラントは、ACLでできることをすべて行えるうえに、アプリケーションレベルの権限とルートフィルタリングを実現します。
詳しくは、グラント vs. ACLを参照してください。
始める準備はできましたか? はじめにガイドを確認するか、すでにACLを使用している場合は移行ガイドを参照してください。
メリットとユースケース
グラントは、ネットワークとアプリケーションの権限を単一のシステムに統合することで、従来のアクセス制御方式に比べて大きな利点をもたらします。
この統合されたアプローチにより、複雑さが軽減され、tailnet全体でより一貫性のあるセキュリティモデルを実現できます。
グラントを使うと、以下のようなことができます。
- デバイスが接続できるホストと、接続後にそのホスト上で動作するアプリケーションに対して持つ権限を定義する。
- ユーザーロール、デバイスポスチャ、その他の文脈的な要因に基づいて、きめ細かな権限を実装する。
viaによるルーティングの認識を使って、アクセス制御ポリシーを拡張する。
よくあるユースケース向けのグラントの例を参照してください。
実装の基本
グラントは、どのユーザーやデバイス（送信元）が、どのリソース（宛先）にアクセスでき、接続後にどのようなケイパビリティを持つかを明示的に定義する、という原則に基づいて動作します。
各グラントは、以下の3つの中核的な要素で構成されます。
- 送信元（Source）: アクセスを要求するユーザーまたはデバイス。
- 宛先（Destination）: アクセス対象のリソース。
- ケイパビリティ（Capabilities）: 宛先にアクセスする際に送信元に付与される権限。これらは、ネットワークケイパビリティ（
ipフィールド）とアプリケーションケイパビリティ（appフィールド）にグループ化されます。
グラントを扱う際は、ネットワーク層とアプリケーション層という2つの異なるレイヤーで作業することになります。
ネットワーク層は、デバイス間の接続に関する、IPアドレス、ポート、プロトコルを指します。
アプリケーション層は、ユーザーがアクセスできる特定の機能やデータソースなど、アプリケーション自体の内部でのケイパビリティを指します。
この2層構造のアプローチにより、ネットワークのみの権限よりも、包括的なアクセス制御が可能になります。
各グラントは、送信元（src）、宛先（dst）、そして少なくとも1種類の権限（ネットワーク権限のip、またはアプリケーション権限のapp）を含むグラント構文を使用します。
この基本構造は、デバイスポスチャのチェック（srcPosture）や、ルーティングの指定（via）といった追加オプションで拡張できます。
送信元と宛先
送信元（src）と宛先（dst）は、tailnet内で誰が何にアクセスできるかを定義します。
どちらのフィールドも、ユーザー、デバイス、グループ、IPアドレス範囲を識別する、幅広いセレクターを受け付けます。
送信元には、次のようなセレクターを指定できます。
- 個々のユーザー向けの、特定のメールアドレス（
name@example.com）。 - ユーザーグループ向けの、グループ（
group:engineering）。 - デバイスグループ向けの、タグ（
tag:database）。 - 管理者向けの、ロール（
autogroup:admin）。
同様に、宛先も同じ種類のセレクターに加え、autogroup:internetや（Tailscale Service用の）svc:web-serverのような特別なセレクターを使って定義できます。
詳しくは、グラントの構文リファレンスを参照してください。
ネットワークケイパビリティ
ネットワークケイパビリティは、tailnet内のデバイス間の基本的な接続性を制御します。
これらの権限は、デバイスが接続を確立できるかどうか、また、どのプロトコルとポートを使用できるかを定義します。
グラントのipフィールドは、ネットワーク層のケイパビリティを指定し、プロトコルとポートのレベルでアクセスを定義できます。
特定のポート、ポート範囲、またはプロトコル全体に対してアクセスを許可できます。
例えば、"ip": ["tcp:443", "udp:53"]は、宛先のTCPポート443（HTTPS）とUDPポート53（DNS）へのアクセスを許可します。
詳しくは、グラントの構文リファレンスを参照してください。
アプリケーションケイパビリティ
アプリケーション層のケイパビリティは、基本的な接続性にとどまらず、デバイスが接続を確立した後に許可する操作を定義します。
宛先デバイス上で動作するアプリケーションは、tailnet経由のリクエストからこれらのケイパビリティを読み取り、リクエスト元の認証・認可に利用できます。
これらのケイパビリティにより、ロールベースのアクセス制御システムと同様に、アプリケーション内の機能アクセスをきめ細かく制御できます。
appフィールドは、"domainName/capabilityName"という形式で、アプリケーション層のケイパビリティを指定します。
例えば、"tailscale.com/cap/tailsql"は、TailSQLアプリケーション用のケイパビリティを識別します。
各ケイパビリティには、デバイスがアクセスできるデータソースや許可する操作など、具体的な権限を定義するパラメーターを含められます。
このアプローチにより、ゼロトラストの原則をアプリケーション層にまで拡張し、接続されたアプリケーションに対して最小権限の原則を徹底します。
詳しくは、グラントの構文リファレンスを参照してください。
制約と考慮事項
グラントは強力なアクセス制御機能を提供しますが、留意すべき重要な考慮事項がいくつかあります。
- アプリケーション層のケイパビリティは、Tailscaleではなく、各アプリケーション自身によって定義されます。各アプリケーションは、自身のケイパビリティとパラメーターを文書化し、グラントで定義されたアプリケーションケイパビリティに反応するロジックを実装する責任を負います。
- Tailscaleのポリシーエンジンは、アプリケーションケイパビリティのパラメーターを、不透明なJSONオブジェクトとして扱います。アプリケーションケイパビリティオブジェクトが有効なJSONであることのみを検証し、パラメーターの内容自体は検証しません。
- デバイスポスチャのチェックは、グラントの送信元（
src）にのみ適用され、宛先（dst）には適用されません。 - グラントとレガシーなACLは、同じtailnetポリシーファイル内で共存できます。ほとんどのユースケースでは、グラントを優先することが推奨されるベストプラクティスです。
詳しくは、グラントの制約と考慮事項を参照してください。
次のステップ
次に何をすべきか迷っていますか? 以下のような選択肢を検討してください。
- 現在のアクセス制御モデルを見直し、グラントを使ってよりきめ細かな権限へ移行できる機会を見つける。
- グラントの作成を試してみる。
- グラントの例を参照する。
- 他のポリシー要素とグラントを統合する方法については、tailnetポリシーファイルのドキュメントを参照する。
- コンテキストに応じたアクセスポリシーのためにデバイスポスチャのチェックとグラントを統合したり、
viaでルーティングの認識を追加したりする。 - tailnetポリシーファイルの管理にGitOpsワークフローの導入を検討する。