5.5ネットワークセキュリティ設計の構成要素

エンタープライズのセキュリティ設計は、単一の万能機器ではなく役割の違う仕組みを層に重ねることで成立します。境界で怪しい通信を止める仕組み、端末そのものの健全性を担保する仕組み、内部の横移動（ラテラルムーブメント）を止める仕組み、そして回線区間の盗聴を防ぐ仕組みはそれぞれ別物です。ENCOR では各要素の定義よりも、「この要件（例：IP アドレス設計を変えずに部門間通信を止めたい／隣接スイッチ間の盗聴を防ぎたい）にはどれが正解か」という適材適所の判断が問われます。

5.5.1脅威防御とエンドポイントセキュリティ

• 脅威防御は、既知の攻撃シグネチャを検知してインラインで遮断する IPS、未知の検体を隔離環境で実行して挙動から判定するサンドボックス、外部の脅威インテリジェンス（Talos 等の評価情報）によるレピュテーションフィルタを組み合わせる。IDS は検知/通知のみで遮断しないという区別は繰り返し問われる。
• エンドポイントセキュリティは端末側の防御。従来型のシグネチャベース対策に加え、EDR（Endpoint Detection and Response）が挙動の記録と事後追跡・隔離を担う。ネットワーク接続時に OS パッチ・マルウェア対策の稼働状況を確認するポスチャ評価（ISE と連携）は、基準を満たさない端末を検疫 VLAN へ隔離し是正を促す。
• 次世代ファイアウォール（NGFW）は、ポート/プロトコルだけでなくアプリケーション識別（同じ 443 上の異なるアプリを区別）とユーザ識別（ID 基盤と連携し「誰が」で制御）を行い、IPS 機能や URL フィルタを統合する。「HTTPS を許可した結果すべてのアプリが通ってしまう」という従来型 FW の限界を埋めるのが要点。

5.5.2TrustSec（SGT によるグループベース制御）

• TrustSec は、認証時に端末/ユーザへSGT（Security Group Tag）を割り当て、IP アドレスやサブネットではなく「グループ」でポリシーを書く仕組み。ポリシーは SGACL としてマトリクス（送信元 SG × 宛先 SG）で表現され、ISE が集中管理する。アドレス設計とポリシーを分離できるのが最大の価値である。
• 従来の ACL ベース設計では、部門を分けるたびにサブネットを切り直し、ACL 行が増え続け、移転や増員のたびに全機器の ACL を追随させる必要があった。TrustSec なら端末がどのサブネットにいても SGT が同じなら同じポリシーが適用されるため、IP 設計を変えずに部門間通信を止めるといった要件に直接応えられる。SD-Access のポリシー層でもこの SGT が使われる。
• SGT は認証（802.1X／RADIUS）と結びついて割り当てられ、装置間ではインライン tagging や SXP で伝搬される。運用上は「誰がどのグループか」の分類の正しさがポリシーの正しさを決めるため、ID 基盤との統合とグループ設計が実装の中心になる。

5.5.3MACsec（802.1AE のホップ単位暗号化）

• MACsec（IEEE 802.1AE）は L2 のイーサネットフレームを暗号化する仕組みで、ホップ単位（リンク単位）に適用される。スイッチ間、あるいは端末とアクセススイッチ間といった隣接ノード間の回線区間で機密性と完全性を確保し、配線盗聴やタップによる傍受を防ぐ。鍵管理は MKA（MACsec Key Agreement） が担う。
• IPsec との違いが頻出：IPsec は L3 のエンドツーエンド（あるいはゲートウェイ間）でパケットを暗号化し、経路上のルータを跨いで保護する。MACsec は各ホップで復号され次のホップで再暗号化されるため、経路全体を通した端点間の秘匿ではない。「WAN 越しの拠点間を暗号化」なら IPsec、「キャンパスの隣接スイッチ間の盗聴防止」なら MACsec が適切。
• TrustSec と MACsec は役割が異なる点に注意する。TrustSec は「誰と誰が通信してよいか」というアクセス制御、MACsec は「回線上で読まれないか」という機密性であり、どちらか一方が他方を代替することはない。実際の設計では両者を併用し、SGT で許可された通信を MACsec で保護する構成をとる。

あなたは製造業のキャンパス刷新で、次の3要件を同時に満たす設計を求められました。(1) 経理部門の端末から研究開発部門のサーバへの通信を止めたい。ただし部門は各フロアに混在しており、サブネットの切り直しは業務影響が大きく不可。(2) 建屋間の配管を通るスイッチ間リンクでの盗聴を防ぎたい。(3) 私物端末がパッチ未適用のまま業務ネットワークに入るのを防ぎたい。まず (1) を従来型の ACL で解こうとすると、部門がサブネットに一致していないため端末ごとにホストACLを書く羽目になり、席替えのたびに全機器を追随させる運用破綻が見えます。ここは TrustSec の出番で、802.1X 認証時に経理には SGT=Finance、開発サーバには SGT=RnD-Server を割り当て、SGACL マトリクスで Finance→RnD-Server を deny すれば、端末がどのサブネットのどのフロアにいてもポリシーが追随します。IP 設計を触らずに済むのが決定的な利点です。次に (2) は暗号化の要件ですが、ここで「IPsec トンネルをスイッチ間に張る」と考えるのは筋が悪く、要求されているのは隣接ノード間の物理リンクの保護なので、MACsec（802.1AE）を該当リンクに有効化し MKA で鍵を管理するのが適切です。MACsec は各ホップで復号・再暗号化されるため端点間の秘匿にはなりませんが、配管内のタップに対する防御という要件には正確に一致します。逆に、WAN 越しの拠点間を守るなら MACsec ではなく IPsec を選ぶべきで、「どの区間を守りたいか」がプロトコル選定を決めます。最後に (3) は端末の健全性の問題なので、TrustSec でも MACsec でもなく ポスチャ評価（ISE 連携）が該当し、パッチや対策ソフトの基準を満たさない端末を検疫 VLAN に隔離して是正後に本ネットワークへ入れます。ここで「NGFW を強化すれば全部解決する」と考えるのは典型的な誤りです——NGFW は境界でのアプリ/ユーザ識別と脅威防御に優れますが、キャンパス内部の横移動を SGT の粒度で止めることも、リンク上の盗聴を防ぐことも、端末の健全性を担保することもできません。要件ごとに守る対象（誰と誰の通信か／回線か／端末の状態か）を見極め、対応する仕組みを重ねるのが設計判断の核心です。

5.5.4この節のまとめ

• 脅威防御は IPS（インライン遮断・IDS は検知のみ）＋サンドボックス＋脅威インテリジェンス、NGFW はアプリ/ユーザ識別と IPS を統合して境界を守る
• TrustSec は SGT でグループ単位のポリシー（SGACL）を書き、IP アドレス設計と分離して横移動を抑止する。エンドポイントセキュリティ（EDR・ポスチャ評価）は端末の健全性を担保し非準拠端末を検疫する
• MACsec（802.1AE）は L2 のホップ単位暗号化（各ホップで復号・再暗号化）で隣接リンクの盗聴を防ぎ、経路を跨ぐ端点間の暗号化は L3 の IPsec が担う——守る区間で使い分ける