チャタリングとは？ 10分でわかりやすく解説

ACLとは

ACL（Access Control List）は、ネットワーク機器がパケットを転送する際に、「通す／通さない」を判断するためのルール一覧です。ルーターやL3スイッチ、ファイアウォールなどに設定し、インターフェースを通過するトラフィックを条件に基づいて許可（permit）または拒否（deny）します。

ACLは“リスト”であり、パケットがルールの条件に一致した時点で、そのルールの動作（許可／拒否）が適用されます。これにより、利便性とセキュリティのバランスを保ちながら通信を整理できます。

なお、ACLは製品やOS（例：Cisco IOS、Juniper、各種クラウド）によって表現や機能が少しずつ異なりますが、「条件に合う通信だけを通す」「合わない通信は止める」という考え方自体は共通です。

ACLが必要な理由

ACLが必要とされる理由は大きく分けて2つあります。1つは、不要な通信を通さないことでネットワークの無駄を減らし、設計意図どおりの通信経路を保つこと。もう1つは、許可すべき通信を明確にし、不正なアクセスや想定外の到達を抑えることです。

ネットワークは多数の機器が相互に通信する場です。何も制限しないと、想定外の到達経路が生まれたり、管理の目が届かない通信が増えたりします。ACLは「ここまでは通す」「ここから先は通さない」を境界として作り、運用を安定させるための基本要素になります。

ACLの基本的な動作

ACLは、インターフェースに入ってくる（または出ていく）パケットに対して、上から順にルールを評価します。ルールが複数ある場合でも、最初に一致したルールが採用され、以降のルールは評価されません。したがって、ルールの順序は動作と運用性に直結します。

また、実装によって呼び方は異なりますが、一般的にACLには「どのルールにも一致しなかった通信は拒否する」という前提（いわゆる暗黙の拒否）が存在します。つまり、許可したい通信は、明示的にpermitとして書く必要があります。

ACLがセキュリティに与える影響

ACLを適切に設定すると、特定の送信元・宛先・プロトコル・ポートなどの条件で通信を制限でき、不要な到達性を減らすことができます。これは、侵入後の横展開（ラテラルムーブメント）を抑えたい場面でも有効です。

ただし、ACLは万能ではありません。アプリケーション層の可視化やユーザー単位の制御など、より高度な制御は別の仕組み（FW、IPS/IDS、ZTNA、認証・認可、マイクロセグメンテーション等）と組み合わせて考える必要があります。ACLは「まず押さえるべき基本の制御」として位置づけるのが現実的です。

標準ACLと拡張ACL

ACLにはいくつかの種類がありますが、学習・運用の入り口としてよく取り上げられるのが標準ACLと拡張ACLです（主にCisco系の用語として知られています）。違いは「どこまで条件にできるか」にあります。

標準ACL

標準ACLは、基本的に送信元IPアドレスを条件にして許可／拒否を行う形式です。たとえば「この送信元から来る通信は通す」「この送信元は通さない」といった、比較的シンプルな制御に向きます。

標準ACLは条件が粗くなりやすいため、設計上は「宛先に近い位置（出口側）」で適用して、影響範囲を必要最小限にする考え方がよく使われます。

また、Cisco IOSの古典的な番号付きACLでは、標準ACLは1〜99、1300〜1999といった範囲の番号が割り当てられます（ただし、現在は機種やOSによって差があり、名前付きACLを使う運用も一般的です）。

拡張ACL

拡張ACLは、より細かい条件で制御できます。代表的には、送信元IP・宛先IPに加え、プロトコル（TCP/UDP/ICMP等）、送信元／宛先ポート、場合によってはTCPフラグなどを条件にできます。

拡張ACLは「この宛先のこのポートだけ許可する」など、要件に合わせた精密な制御ができる一方で、ルールが増えると管理が難しくなり、機器によっては評価コスト（処理負荷）も増えます。必要な粒度を見極め、無理に細かくしすぎないことが重要です。

Cisco IOSの古典的な番号付きACLでは、拡張ACLは100〜199、2000〜2699が割り当てられます。こちらも同様に、現場では名前付きACLが使われることも多く、番号範囲の知識は「背景として知っておく」程度で十分な場合があります。

標準ACLと拡張ACLの違い

まとめると、標準ACLは「送信元IP中心でざっくり制御」、拡張ACLは「送信元・宛先・プロトコル・ポートまで見て細かく制御」です。要件が「誰から来たか」だけで足りるなら標準ACLで良い一方、「どこ宛ての何の通信か」まで制御したいなら拡張ACLが向きます。

ACLのタイプを選ぶポイント

ACLのタイプは、まず要件を言葉にしてから選ぶとブレにくくなります。たとえば次のように整理します。

• 制御したいのは送信元だけか、宛先やポートまで必要か
• 例外通信（業務で必要な通信）は何か
• ルールの増加に運用が耐えられるか

拡張ACLは強力ですが、増えすぎると運用が破綻しやすくなります。「必要十分な粒度」を狙い、設計と保守の両方が回る形にするのが現実的です。

ACLの適用方向

ACLは、インターフェースを通過するパケットの「どの方向」に適用するかで挙動が変わります。一般的にインバウンドとアウトバウンドの2つとして整理されます。

インバウンド

インバウンドは、インターフェースに入ってくるパケットに対してACLを適用する方法です。パケットがルーティングや転送の判断に進む前にフィルタリングできるため、不要な通信を早い段階で落とせます。

「不要な通信をネットワーク内部に入れたくない」「境界で落としたい」という目的では、インバウンド適用が選ばれやすいです。

アウトバウンド

アウトバウンドは、インターフェースから出ていくパケットに対してACLを適用する方法です。ルーティングや転送の結果として送出される通信を制御するイメージになります。

特定の宛先へ向かう通信をまとめて制御したい場合など、設計によってはアウトバウンドの方が分かりやすいこともあります。

インバウンドとアウトバウンドの考え方

どちらが正しいというより、どこで落とすと分かりやすいか、影響範囲をどう絞るかで決めます。たとえば、拡張ACLは「送信元に近い場所で落とす」ことで、不要な通信がネットワーク内を流れる前に止められます。標準ACLは条件が粗いので「宛先に近い場所で絞る」方が安全です。

また、機器の処理負荷は「イン／アウト」だけで単純に決まりません。ルール数、マッチのしやすさ、ハードウェア支援の有無などの要因が大きいので、実機・実環境での検証も含めて判断するのが確実です。

ACLのベストプラクティス

ACLは書けるようになって終わりではなく、運用で崩れない形にすることが重要です。ここでは、実務で効きやすい基本を整理します。

よくあるミスを避ける

ACLで起きがちなトラブルは、だいたい次の3つに集約されます。

• 順序のミス：意図しないルールに先にマッチしてしまう
• 例外の抜け：必要な通信のpermitが不足して遮断してしまう
• 影響範囲の過大：適用場所が悪く、広範囲に通信断を起こす

「deny anyを入れたから安全」という発想も危険です。どの実装でも最後は拒否に寄ることが多い一方で、許可すべき通信を漏らすと業務影響が出るため、先に“許可の棚卸し”を行うのが近道です。

設計前に通信を言語化する

ACLは「何を守るか」「何を通すか」が曖昧だと破綻します。最低限、次を整理してから書くと安定します。

• 守る対象：どのサーバー／セグメント／サービスか
• 許可する通信：誰が、どこへ、何のプロトコル／ポートで行くのか
• 例外：運用・監視・更新など、止めると困る通信は何か

この整理ができると、ルールは自然に「許可を先に書き、最後は拒否する」という形に収束します。

順序と粒度を整える

ACLは上から評価されるため、よくマッチするルールや影響が大きいルールは、意図が明確になるように並べます。粒度は細かすぎても粗すぎても困るので、「守りたい対象」に対して必要十分に絞るのが基本です。

特に拡張ACLは、ポートやプロトコルを条件にできる分だけ増殖しやすいので、似たルールが増え始めたら、設計意図そのものを見直す合図だと考えると運用が楽になります。

変更手順と確認をセットにする

ACLは変更が事故につながりやすい設定です。だからこそ、次のような確認をセットにすると安定します。

• 変更前後で、許可されるべき通信が通るか（疎通試験）
• 監視・バックアップ・管理系の通信が止まっていないか
• ログやカウンタで、想定外に落ちている通信がないか

「書けた」より「変更しても壊れない」をゴールにすると、ACLは一段使いやすくなります。

ACLの位置づけと今後の運用

現場では、ACLだけで全てを守るのではなく、ファイアウォールやクラウドのセキュリティグループ、ゼロトラスト設計などと組み合わせて多層で守るのが一般的です。その中でACLは、ネットワークの基本制御として今も重要な役割を担っています。

運用の観点では、ルールの棚卸しや、通信要件の更新、変更管理の整備が効いてきます。ACLを「書きっぱなし」にせず、設計意図が追える状態を保つことが、長期的な安全性と安定性につながります。

FAQ