【テクニカル・上級編】 ネットワークアクセスコントロール(NAC:Network Access Control)の802.1X認証基盤 – サイバーセキュリティとプライバシー保護実践ガイド

境界の崩壊と802.1Xの真実:なぜ「認証」は単なる門番に過ぎないのか

ネットワークの世界において、「境界」という概念はすでにレガシーだ。社内LANに繋がれば安全などという幻想は、数年前にランサムウェアの水平移動(Lateral Movement)によって完全に打ち砕かれた。我々インフラアーキテクトが今向き合うべきは、どのパケットが「信頼できる実体」から発せられたかを、L2レイヤーのミリ秒単位で判定する冷徹な仕組みだ。

今回は、ゼロトラストの起点となる 802.1X 認証基盤について、教科書の行間にある「パケットの鼓動」を紐解いていく。

—

1. EAPパケットの深淵:TLSハンドシェイクを極限までチューニングする

802.1X 認証の本丸は EAP-TLS だ。しかし、多くの現場でこの認証が「遅い」「タイムアウトする」と悲鳴が上がる。原因の多くは、MTU制限によるフラグメンテーションと、TLSハンドシェイクの冗長性にある。

EAP-TLS では、サーバー証明書やクライアント証明書が EAP-Response/Identity を経由して流れる。巨大な証明書チェーンを抱えたまま、デフォルトの MTU(1500バイト)でパケットを送りつければ、L2スイッチのバッファは瞬く間に枯渇する。

最適化の勘所

認証を加速させるには、以下のチューニングが必須だ。

  • EAPフラグメンテーションの有効化: RADIUSサーバー側でパケットサイズを調整し、L2の Frame-Check-Sequence エラーを誘発しないサイズ(1024バイト程度)に切り分ける。
  • TLSセッション再開(Session Resumption): 認証の度にフルハンドシェイクを行うのはリソースの無駄だ。Session ID または Session Ticket を活用し、2回目以降の認証を数ミリ秒で完結させる。
# FreeRADIUSでのチューニング例 (eap.conf)
# 断片化を明示的に制御し、再送を減らす
eap {
    tls-config tls-common {
        # セッションキャッシュの保持時間を設定
        cache {
            enable = yes
            lifetime = 86400 # 24時間
        }
        # パケットのフラグメンテーションサイズを固定
        fragment_size = 1024
    }
}

—

2. 隔離VLANへの自動割り当て:動的VLAN制御の泥臭い罠

認証成功時に RADIUS から返される Tunnel-Type 属性に基づき、スイッチポートを「隔離VLAN」から「本番VLAN」へ切り替える。これは美しいフローだが、現場では DHCP の挙動に足をすくわれることが多い。

VLANが切り替わった瞬間、クライアントのNICは Link Down/Up を検知する。この時、OSの DHCPクライアント が古いVLANのリース情報を引きずったままパケットを投げると、ネットワーク内で「迷子パケット」が大量発生し、ACLのログが埋め尽くされる。

実装上の鉄則

スイッチ側で Change of Authorization (CoA) を適切にトリガーし、強制的に DHCP Discover を再送させる設定を忘れてはならない。

# Cisco IOSでのCoAトリガー設定の要点
aaa server radius dynamic-author
 client 192.168.1.10 server-key 0 <秘密鍵>
!
# ポートの再認証を強制し、VLAN割り当て変更後にリンクをリセットする
interface GigabitEthernet1/0/1
 authentication event fail action authorize vlan 999  # 隔離VLAN
 authentication event no-response action authorize vlan 999

—

3. 脆弱性回避:EAP-PEAPの「偽装」を封じる

EAP-TLS が導入できないレガシー環境では EAP-PEAP が使われることが多いが、これは MS-CHAPv2 の弱点を突かれるリスクを常に孕んでいる。

攻撃者は RADIUS サーバーになりすまし、クライアントからハッシュ化された資格情報を奪取しようとする。これを防ぐには、クライアント側で「サーバー証明書の検証」を強固に設定し、Trusted Root CA 以外の接続をOSレベルで遮断するしかない。

セキュリティ専門家が推奨するプロファイル設定(Windows/GPO)

1. サーバー証明書の検証を必須化: サーバー名(FQDN)を明示的に指定し、一致しない場合は接続を拒否する。
2. 認証プロトコルの制限: MS-CHAPv2 を許可しつつ、暗号化レベルを最強に設定し、中間者攻撃(MITM)の余地を排除する。

—

4. 最後に:インフラ屋が目指すべき「見えない防御」

ネットワークセキュリティの真髄は、ユーザーが「自分が認証されていること」すら意識させない透明性にある。

RTT(Round Trip Time)を削り、TLSのハンドシェイクを最適化し、RADIUS の応答をサブミリ秒に近づける。この積み重ねが、結果として「認証によるネットワークの不快感」を排除し、セキュリティポリシーを現場に浸透させる唯一の鍵となる。

パケットは嘘をつかない。L2のフレームに刻まれた認証のフラグが、あなたのネットワークを本当に守っているのか、今一度 tcpdump を回して確認してみてほしい。その静かなパケットの連なりの中に、次世代のゼロトラストへの答えが隠されているはずだ。

—
*筆者注:本記事のコード例は、特定の環境下での動作を保証するものではありません。実装の際は必ずラボ環境での検証と、パケットキャプチャによる挙動確認を怠らないようにしてください。*

コメント

タイトルとURLをコピーしました