企業ネットワークアクセスの課題:事前共有鍵に依存した運用の限界
一般的なブランチオフィスに入ると、多くの場合は単一の事前共有キー(WPA2/WPA3 Personal)で運用されているオフィスWi-Fiを目にするはずです。会議室のホワイトボードにそのキーが無造作に書かれていることも珍しくありません。また有線LAN側を見ても、会議室のスイッチポートが完全に管理されないまま開放されているケースが多々あります。
このような構成は、従業員の異動や退職が発生した瞬間に破綻します。社員の退職、外部委託先プロジェクトの終了、あるいは社用ノートPCの紛失といった事態に直面したとき、情報システム部門は過酷な二者択一を迫られます。250台のノートPC、80台のスマートフォン、そして多数のIoTセンサーを探し出してパスフレーズをすべて再設定するか、あるいはリスクを承知で放置するかです。
根本的な原因は、対称型認証情報の共有にあります。事前共有キーには「ユーザー識別」の概念がありません。アクセスポイントやスイッチ側では、接続してきたのが誰なのか、またその端末がエンドポイントセキュリティポリシーに準拠しているかどうかを判断できません。
機器側が把握できるのは、クライアントから正しいパスフレーズが送信されたという事実だけです。MACアドレスフィルタリングも実質的な防御にはなりません。airodump-ngなどの無償ツールを使えば、正規のMACアドレスは2分足らずで特定できます。そこから攻撃者はip link set dev wlan0 addressを実行して自身のネットワークカードを偽装し、社内の内部VLANへと容易に侵入できてしまいます。
この問題を根本から解決するには、集中型RADIUSサーバーと連携したポートベースのネットワークアクセス制御(IEEE 802.1X)が必要です。Linux上で動作するFreeRADIUSは、このアイデンティティファーストな認証基盤を支える強力なバックボーンとなります。
認証方式の比較:PSK vs PEAP-MSCHAPv2 vs EAP-TLS
静的なパスワードからの脱却にあたっては、適切なEAP(Extensible Authentication Protocol)方式の選択が不可欠です。本番環境で一般的に採用される方式には、主に以下の3つがあります。
- WPA-Personal (PSK): 単一の共有シークレットですべてのエンドポイントを保護します。5分程度で設定できバックエンドサーバーも不要ですが、ユーザー単位の監査ログは一切残せず、侵害された1台の端末だけアクセス権を取り消すことも不可能です。
- PEAP-MSCHAPv2 (EAP-PEAP): サーバーが確立した暗号化TLSトンネル内で、ユーザーが通常のActive DirectoryやLDAPの認証情報を用いてサインインします。広く普及しておりエンドユーザーにとっても利便性が高い一方、認証情報の窃取攻撃にさらされやすい弱点があります。もし従業員がルートCA検証をスキップした不正アクセスポイントに接続してしまうと、
eaphammerなどのツールによりMS-CHAPv2のチャレンジ/レスポンスを傍受され、オフラインでクラックされる危険性があります。 - EAP-TLS (RFC 5216): 証明書による相互認証方式です。プライベートCA(認証局)から発行されたX.509デジタル証明書を使用し、RADIUSサーバーとクライアントが互いを検証し合います。電波上にも有線ケーブル上にも、パスワードが流れることは一切ありません。
ネットワーク認証方式のメリットとデメリット
| 認証方式 | 主なメリット | 運用のトレードオフ |
|---|---|---|
| WPA2/WPA3 PSK | わずか数分で導入可能。専用サーバーを必要とせず、レガシー機器や組み込みIoTデバイスと幅広く互換性を維持できます。 | ユーザーに対する説明責任が皆無。パスフレーズが漏洩した場合、すべての端末を手動で更新するのに膨大な作業工数がかかります。 |
| PEAP-MSCHAPv2 | IDの一元管理が可能。クライアント証明書を発行することなく、LDAPやActive Directoryへ直接連携できます。 | 旧来のMS-CHAPv2の暗号的脆弱性を引き継ぎます。悪意のある不正アクセスポイント(Evil Twin)や認証情報の抜き取り攻撃に脆弱です。 |
| EAP-TLS | パスワードスプレー攻撃やフィッシングに対して完全な耐性を保持。暗号化された相互信頼により、ユーザープロンプトなしで起動時にシームレスに自動接続できます。 | PKI(公開鍵暗号基盤)の構築が必須。証明書のライフサイクルを管理するために、IntuneやJamfなどのMDMソリューションが必要となります。 |
推奨アーキテクチャ:FreeRADIUSとEAP-TLSの組み合わせ
EAP-TLSは、企業向けWi-Fi(WPA-Enterprise)および物理スイッチポート(802.1X有線)において、最もクリーンで堅牢なアクセス制御モデルを実現します。内部での認証フローは以下の通りです。
- サプリカント(Supplicant)(クライアントPCやモバイル端末)が、無線アクセスポイントまたはエッジスイッチへ
EAPoL-Startフレームを送信します。 - オーセンティケータ(Authenticator)(アクセスポイントやスイッチ)が、EAPペイロードをUDP RADIUSパケットにカプセル化し、ポート1812経由でFreeRADIUSへ転送します。
- 認証サーバー(Authentication Server)(FreeRADIUS)が、クライアントと直接暗号化TLSハンドシェイクを確立します。FreeRADIUSは信頼されたルートCAと照合してクライアント証明書を検証し、クライアント側もRADIUSサーバー証明書を検証します。
- 暗号論的な信頼が確立されると、FreeRADIUSは
Access-Acceptフレームを返します。この応答にはTunnel-Private-Group-Id = "30"などの動的RADIUS属性を含めることができ、該当ユーザーを隔離された開発用VLANや社内用VLANへと自動的に割り振ることが可能です。
導入ガイド:Linux上でFreeRADIUSとEAP-TLSを構築する手順
本ガイドでは、Ubuntu 24.04 LTSおよびDebian 12環境において、FreeRADIUS 3.2.xとOpenSSLを使用した構成手順を解説します。
ステップ1:FreeRADIUSと暗号化ツールのインストール
sudo apt update
sudo apt install -y freeradius freeradius-utils openssl
# 後ほどデバッグモードで対話的に起動できるよう、システムサービスを一度停止します
sudo systemctl stop freeradius
ステップ2:プライベートPKIの生成
FreeRADIUSには/etc/freeradius/3.0/certs/配下にサンプルのブートストラップスクリプトが用意されていますが、独自に証明書を発行することで、鍵長、暗号スイート、有効期限などを完全にコントロールできます。
# 証明書用の安全な作業ディレクトリを作成
sudo mkdir -p /etc/freeradius/3.0/pki
cd /etc/freeradius/3.0/pki
# 1. ルートCAの秘密鍵(4096-bit RSA)と自己署名証明書(有効期限5年)を生成
sudo openssl genrsa -aes256 -out ca.key 4096
sudo openssl req -x509 -new -key ca.key -sha256 -days 1825 -out ca.pem \
-subj "/C=US/ST=Texas/L=Austin/O=CoreInfra/CN=CoreInfra-Root-CA"
CAの秘密鍵の暗号化やクライアント向けPKCS#12バンドルのエクスポートに使用するパスフレーズを生成する際は、toolcraft.app/ja/tools/security/password-generatorのパスワードジェネレーターを使用しています。すべてブラウザ上で完結して生成されるため、サーバー用パスワードのデータがネットワーク経由で外部へ送信される心配がありません。
# 2. FreeRADIUSサーバー用の2048ビット秘密鍵と証明書署名要求(CSR)を生成
sudo openssl genrsa -out server.key 2048
sudo openssl req -new -key server.key -out server.csr \
-subj "/C=US/ST=Texas/L=Austin/O=CoreInfra/CN=radius.internal.lan"
# ルートCAを使用してサーバー証明書に署名(有効期間2年)
sudo openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial \
-out server.pem -days 730 -sha256
# 3. Diffie-Hellmanパラメータの生成(TLS暗号ネゴシエーションに必要)
sudo openssl dhparam -out dh 2048
# 4. テスト用クライアント端末の証明書を生成
sudo openssl genrsa -out client-laptop01.key 2048
sudo openssl req -new -key client-laptop01.key -out client-laptop01.csr \
-subj "/C=US/ST=Texas/L=Austin/O=CoreInfra/[email protected]"
# クライアント証明書に署名(有効期間1年)
sudo openssl x509 -req -in client-laptop01.csr -CA ca.pem -CAkey ca.key -CAcreateserial \
-out client-laptop01.pem -days 365 -sha256
# クライアント証明書、秘密鍵、ルートCAをパスワード保護されたPKCS#12(.p12)コンテナにバンドル
sudo openssl pkcs12 -export -out client-laptop01.p12 \
-inkey client-laptop01.key -in client-laptop01.pem -certfile ca.pem
ステップ3:ファイルパーミッションの保護
秘密鍵をFreeRADIUSに読み込ませる前に、ローカルの他ユーザーから不正に参照されないようアクセス権限を設定します。
sudo chown -R freerad:freerad /etc/freeradius/3.0/pki
sudo chmod 640 /etc/freeradius/3.0/pki/*
sudo chmod 600 /etc/freeradius/3.0/pki/*.key
ステップ4:FreeRADIUSのEAPモジュール設定
テキストエディタで/etc/freeradius/3.0/mods-available/eapを開きます。tls-config tls-commonブロックを更新し、生成した鍵と証明書を指定します。MTUの小さいWANトンネル経由でフラグメント化されたRADIUSパケットがドロップするのを防ぐため、fragment_size = 1024の指定は維持してください。
eap {
default_eap_type = tls
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
max_sessions = 4096
tls-config tls-common {
private_key_file = /etc/freeradius/3.0/pki/server.key
certificate_file = /etc/freeradius/3.0/pki/server.pem
ca_file = /etc/freeradius/3.0/pki/ca.pem
dh_file = /etc/freeradius/3.0/pki/dh
fragment_size = 1024
check_crl = no
cipher_list = "DEFAULT@SECLEVEL=2"
tls_min_version = "1.2"
tls_max_version = "1.3"
}
tls {
tls = tls-common
}
}
ステップ5:clients.confでネットワークアクセス機器(NAD)を定義
エッジスイッチや無線アクセスポイントは、RADIUSクライアント(オーセンティケータ)として機能します。/etc/freeradius/3.0/clients.confにて、それぞれのIPサブネットと共有シークレットを設定・許可します。
# フロアスイッチ(Cisco Catalystスタック)
client corporate_switches {
ipaddr = 10.10.20.0/24
secret = K9x#mP4$vL2@qR8!
nas_type = cisco
}
# エンタープライズWi-Fiアクセスポイント
client wifi_access_points {
ipaddr = 10.10.30.50
secret = T7y&wE3#nB9*kM5$
shortname = ap-hq-floor2
}
ステップ6:デバッグモードでの起動と動作検証
初期セットアップ時はsystemdのサービスログを追うのではなく、FreeRADIUSをフォアグラウンドのデバッグモードで直接実行します。これにより、EAPパケットのやり取りを1行ずつリアルタイムに確認できます。
sudo freeradius -X
デーモンが設定モジュールを読み込み、UDPポート1812(認証)および1813(アカウンティング)にバインドされると、リクエスト待機状態を示すメッセージが出力されます。
Ready to process requests
テスト対象の端末にclient-laptop01.p12をインポートします。macOSの場合はファイルをダブルクリックして「キーチェーンアクセス」に登録します。Windowsの場合はダブルクリックして証明書インポートウィザードを起動し、「現在のユーザー」ストアへインポートします。その後、社内の802.1X用SSIDに接続するか、802.1Xが有効化されたスイッチポートにLANケーブルを接続してください。
すると、freeradius -Xを実行しているターミナルにTLSハンドシェイクのログが流れ始めます。およそ300ミリ秒以内に、以下のようなログが表示されるはずです。
Sending Access-Accept Id 1 from 10.10.10.5:1812 to 10.10.30.50:41255
Finished request 0. Done processing request.
正常に認証が完了することを確認できたら、Ctrl+Cを押してデバッグモードを終了します。その後、バックグラウンドのsystemdサービスとしてFreeRADIUSを有効化・起動します。
sudo systemctl enable --now freeradius
EAP-TLSを導入していれば、端末紛失時にも迅速に対応できます。対象端末のクライアント証明書を失効させるだけで即座にアクセスを遮断でき、全社的なパスワードリセットを強いられたり、他のユーザーの業務を妨げたりすることもありません。

