ACLからグラントへの移行

ACLの記述をグラントの構文へ変換する

最終検証日：2026年9月2日
翻訳: 竹洞 陽一郎

tailnetポリシーファイルは、Tailscaleネットワークにおけるアクセスの定義の基礎となるものです。
従来は、ネットワーク層の権限をACLで管理していました。
現在は、より強力な代替手段としてグラントが提供されています。

ACLは今後も使い続けられますが、ベストプラクティスとして推奨されるのはグラントです。
このページでは、移行の利点、変換の例、移行時のベストプラクティスを説明します。

ACLとグラントの違い

ACLとグラントはどちらも、最小権限とデフォルト拒否の考え方に基づいています。
ただし、ACLはネットワーク層の権限だけを扱い、宛先とポートを1つのフィールドにまとめて記述します。また、actionフィールドが必須です（指定できる値はacceptのみです）。
この構造は、tailnetの規模が大きくなるほど複雑になります。

グラントは、ネットワーク層とアプリケーション層の権限を共通の構文で扱います。
宛先とポート・プロトコルを別のフィールドに分けることで可読性が上がり、冗長なactionフィールドも不要になります。
両者の比較については、グラントとACLの比較を参照してください。

グラントへ移行する利点

ネットワーク層とアプリケーション層の権限を扱える

ACLはネットワーク層で接続の可否を決めるだけですが、グラントは接続が確立した後、宛先のアプリケーションで何ができるかも指定できます。

構文が分かりやすい

宛先とポートの指定が分離されるため、ポリシーファイルの読み書きと保守が容易になります。

経路を制御できる

グラントのviaフィールドにより、サブネットルーター、Exit Node、アプリコネクタのどれを経由させるかを制御できます。誰が何にアクセスできるかだけでなく、どの経路でアクセスするかまで指定できます。詳細はViaによる経路の制御を参照してください。

ACLとグラントの対応

基本的な変換パターン

変換の手順は2つです。

1. actionフィールドを削除します。
2. 宛先に含まれていたポートと、protoフィールドのプロトコルを、ipフィールドにまとめます。

変換前（ACL）:

"acls": [
  {
    "action": "accept",
    "src": ["group:eng"],
    "dst": ["tag:web-server:443"],
    "proto": "tcp",
  }
]

変換後（グラント）:

"grants": [
  {
    "src": ["group:eng"],
    "dst": ["tag:web-server"],
    "ip": ["tcp:443"],
  }
]

ACLでプロトコルを指定していない場合は、グラントでも省略します。

複数のポートを指定していた場合は、ipに並べます。

"acls": [
  {
    "action": "accept",
    "src": ["group:eng"],
    "dst": ["tag:web-server:80", "tag:web-server:22"],
  }
]

"grants": [
  {
    "src": ["group:eng"],
    "dst": ["tag:web-server"],
    "ip": ["80", "22"]
  }
]

宛先が異なるタグを指していた場合は、タグごとに別のグラントを作成します。

"acls": [
  {
    "action": "accept",
    "src": ["group:eng"],
    "dst": ["tag:web-server:80", "tag:dev-server:22"],
  }
]

"grants": [
  {
    "src": ["group:eng"],
    "dst": ["tag:web-server"],
    "ip": ["80"]
  },
  {
    "src": ["group:eng"],
    "dst": ["tag:dev-server"],
    "ip": ["22"]
  }
]

これを1つのグラントにまとめると、両方のタグに対して両方のポートを許可することになり、権限の範囲が変わってしまいます。

管理コンソールで変換する

1. 管理コンソールのAccess controlsページを開きます。
2. JSON editorを選択します。
3. Convert ACLs to grantsの下にあるConvert to grantsを選択します。
4. 変換されたグラントを確認します。aclsセクションが削除され、同等のgrantsに置き換わります。
5. Saveを選択して適用します。

• ポリシーファイルにaclsセクションがない場合、ボタンは表示されたままですが無効になります。
• 変換は確認のダイアログなしで即座に反映されるため、保存前に内容を確認してください。
• ポリシーファイルの変更はすべて構成監査ログに記録されるため、元に戻すこともできます。

手作業で変換する

1. すべてのACLのエントリーを洗い出し、機能や保護対象のリソースごとに分類します。
2. 各エントリーについて、次の作業を行います。
   • ACLのsrc配列をそのまま使って、新しいグラントを作成します。
   • グラントにdst配列を作成します。
   • グラントにip配列を作成します。
3. ACLのdst配列の各要素について、次のように分解します。
   • コロン（:）で区切り、宛先とポートに分けます。
   • コロンより前の宛先をdst配列に追加します。
   • ACLにprotoフィールドがある場合は、ポートにそのプロトコルを付けます（例: "tcp:80"、"tcp:443"）。
   • protoフィールドがない場合は、プロトコルを付けずにポートだけを指定します。
   • できあがった文字列をip配列に追加します。
4. ACLにsrcPosture配列がある場合は、そのままグラントへコピーします。

宛先ごとに必要なポートが異なる場合は、宛先ごとに別のグラントを作成してください。権限の範囲が明確になります。
複雑なポリシーでは、機能領域ごとに順を追って変換すると、リスクを抑えられ、問題の切り分けも容易になります。
すべての変換を終えたら、ポリシーファイル全体を見直し、必要な権限がすべて維持されているかを確認してください。

変換のパターン別の例

ワイルドカード

"acls": [
  {
    "action": "accept",
    "src": ["group:prod"],
    "dst": ["tag:database:*"],
  }
]

"grants": [
  {
    "src": ["group:prod"],
    "dst": ["tag:database"],
    "ip": ["*"],
  }
]

IPアドレスの範囲とCIDR表記

CIDR表記はdstフィールドに残し、プロトコルとポートの指定をipフィールドへ移します。

"acls": [
  {
    "action": "accept",
    "src": ["group:devops"],
    "dst": ["192.0.2.0/24:22"],
    "proto": ["tcp"],
  }
]

"grants": [
  {
    "src": ["group:devops"],
    "dst": ["192.0.2.0/24"],
    "ip": ["tcp:22"],
  }
]

オートグループ

autogroup:memberやautogroup:selfのようなオートグループのセレクターは、特別な扱いをせずそのまま変換できます。

"acls": [
  {
    "action": "accept",
    "src": ["autogroup:member"],
    "dst": ["autogroup:self:*"],
  }
]

"grants": [
  {
    "src": ["autogroup:member"],
    "dst": ["autogroup:self"],
    "ip": ["*"],
  }
]

セレクターの一覧は、ターゲットとセレクターを参照してください。

SSHルール

Tailscale SSHは、ACLともグラントとも別のsshセクションを使います。
移行の際、SSHルールは元の形式のまま維持してください。

移行内容をテストする

• ポリシーファイル内にテストを記述し、移行後のポリシーが意図したアクセスを許可しているかを検証します。
• 管理コンソールのエディタにあるPreview rulesタブで、適用前に変更内容を確認します。詳細はアクセス制御ポリシーの編集を参照してください。

グラント運用のベストプラクティス

• 関連する権限をまとめ、コメントで各セクションの目的を説明することで、グラントを論理的に整理します。
• 規模の大きな組織では、段階的に移行します。まず基本的なACLの変換から始め、複雑なルールを順に移行し、アプリケーションケイパビリティの追加は最後に行います。
• 特にアプリケーション層のケイパビリティについては、構成と設計の理由を文書化してください。ポリシーを理解・変更する担当者の引き継ぎが容易になります。

よくある問題

権限が不足する

ACLからグラントへの変換内容を再確認してください。ipフィールドに一部のポートやプロトコルを書き漏らす、複数のACLをまとめる際に宛先を落とす、といった誤りが起きやすい箇所です。

グラントが重複して意図より広いアクセスになる

構成が複雑な場合、グラントの重複によって想定外のアクセスが生じることがあります。特にipフィールドでワイルドカードや範囲を使っている箇所を確認してください。

詳細は、グラントのトラブルシューティングを参照してください。

原文：Migrate from ACLs to grants（Tailscale公式ドキュメント）