ACLとは

詳細な図解

ACLを読むときの前提

ACL（Access Control List）は、通信を許可するか拒否するかを、送信元、宛先、プロトコル、ポート、方向などの条件で並べた制御リストです。多くの機器では上から順に評価され、最初に一致した行の動作が採用されます。

ネットワーク設計では、ACLは単なるセキュリティ設定ではなく、どのセグメント間通信を業務として認めるかを表す設計資料でもあります。ルーターのインターフェースACL、スイッチの管理アクセス制御、Firewallのポリシー、クラウドのNetwork ACLでは評価位置や状態管理が異なるため、同じACLという言葉でも適用箇所を先に確認します。

変更作業では、許可行を追加する前に、既存のdeny、暗黙deny、上位ルール、戻り通信、ログ取得の有無を見ます。疎通だけを目的に広いany許可を入れると、後の棚卸しで削除判断が難しくなります。

設計で確認する条件

ACLを設計するときは、送信元、宛先、サービス、方向、適用インターフェース、評価順を同じ表で扱います。送信元だけ、ポートだけを切り出すと、実際の通信経路と設定がずれやすくなります。

Cisco系の標準ACLと拡張ACL、名前付きACL、クラウドのNACL、Firewallポリシーでは指定できる条件が違います。ワイルドカードマスクを使う機器では、サブネットマスクと反転して考える必要があるため、対象範囲を開始IPと終了IPへ展開して確認すると誤設定を減らせます。

• 送信元、宛先、プロトコル、ポート、方向を1行で確認する。
• ACLを適用する場所が入口側か出口側かを明記する。
• クラウドNACLのようなステートレス制御では戻り通信も別行で見る。

投入前レビューで残す証跡

ACL変更の証跡には、変更前後のconfig差分、対象ACL名または番号、追加・削除する行、評価順、ヒットカウント、関連チケット、作業後の確認コマンドを残します。行番号を使う機器では、挿入位置が1行ずれるだけで既存通信を止めることがあります。

作業後は疎通結果だけでなく、想定した許可行にヒットしているか、意図しないdenyログが増えていないかを見ます。ログを出しすぎるACLは調査に便利な一方で、CPU負荷やログ費用、ノイズ増加につながるため、恒久運用に残すかは別に判断します。

• 投入前後のACL全体と差分を保存する。
• ヒットカウント、denyログ、許可ログを時刻付きで残す。
• 戻し手順では削除行だけでなく挿入位置も確認する。

FirewallやSecurity Groupとの違い

Firewallは通信制御の機能全体や装置を指すことが多く、ACLはその中で評価されるルールリストとして使われます。Security Groupは多くのクラウドでステートフルに動作し、戻り通信を自動的に許可します。一方でNACLはステートレスなことが多く、戻り通信の許可を明示する必要があります。

この違いを混同すると、オンプレ機器では通るのにクラウド側で戻りが落ちる、またはSecurity Groupでは不要だった戻りポートの設計がNACLで漏れる、といった障害になります。ACLという表記を見たら、まずどの製品やサービスのACLなのかを確認します。

• ステートフルかステートレスかを確認する。
• 暗黙denyの位置とログの出方を確認する。
• 上位Firewall、ルート、NATとの評価順を分けて見る。

よくある事故と防ぎ方

ACLの事故は、広すぎる許可よりも、順序、方向、戻り通信、範囲表記の勘違いで起きることが多いです。特に先頭付近にdenyを追加する作業、any anyの一時許可、管理アクセス制御、SNMPやNTPなど運用系通信の許可変更は影響が見えにくくなります。

レビューでは、通信要件を業務名、所有者、期限と結び付けます。設定行だけを見ても、その通信が必要かどうかは判断できません。例外許可には削除条件を付け、作業後に不要になった許可を消せる形で記録します。

• 広いany許可には理由、期限、削除条件を付ける。
• 既存denyより前に挿入する変更は影響範囲を再確認する。
• 運用系通信、監視通信、管理アクセスは別枠で棚卸しする。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能