【図解】RADIUSプロトコルがよくわかる！認証・認可・アカウンティングの基本

会社のWi-FiやVPNの設定をしていると、必ずと言っていいほど「RADIUSサーバ」という言葉が出てきます。クラウドのサービスにはブラウザでログインする時代なのに、なぜネットワークの入口ではRADIUSが使われ続けているのでしょうか。

この記事では、RADIUSが「なぜ必要なのか」から始めて、AAA（認証・認可・アカウンティング）の考え方、登場人物とやり取りの流れ、よく混同されるLDAPやSAMLとの違い、最近の脆弱性と対策までを、図を使って順番に説明します。

なぜRADIUSが必要なのか

ユーザー情報を1か所で管理するため

社員100人の会社に、無線LANのアクセスポイント（AP）が10台あるとします。APそれぞれにユーザー名とパスワードを登録して接続を許可する方法でも、動かすことはできます。ただ、社員が1人退職するたびに10台すべてから削除しなければならず、1台でも消し忘れれば、退職した人が社内のネットワークに入れてしまいます。

そこで、「この人を入れてよいか」の判断をAP自身ではなく、1台の専用サーバに任せます。APは接続しようとした人の情報をサーバに送り、返ってきた答えに従って通すか止めるかを決めるだけです。この「問い合わせ」に使われる決まりごと（プロトコル）が、RADIUS（Remote Authentication Dial-In User Service）です。

マンションにたとえると、各部屋の住人が来客を自分で確かめるのではなく、エントランスのオートロックと管理人室がまとめて確かめるイメージです。RADIUSは、この「入口で確かめる仕組み」をネットワークで実現しています。

ブラウザが使えない「入口」で判定するため

「ログインならSAMLやOpenID Connectでよいのでは」と思うかもしれません。これらはブラウザでWebアプリにログインするための仕組みで、使うにはすでにネットワークにつながっていて、ログイン画面を表示できることが前提です。

ところが、PCやスマホがWi-Fiにつなごうとしている瞬間は、まだネットワークの中に入れていません。IPアドレスもなく、ブラウザで何かを表示することもできません。この段階で「入れてよいか」を判定するのが、AP・スイッチ・VPN装置といった入口の機器と、その問い合わせ先のRADIUSサーバです。

図2のように、①でネットワークに入るときの門番がRADIUS、②で中に入ってからアプリにログインするときの仕組みがSAMLやOpenID Connectです。どちらが新しいかではなく、守っている場所が違います。このため、クラウドのサービスが主流になった今でも、無線LANの802.1X認証やVPNの入口ではRADIUSが使われています。

AAA：RADIUSが担う3つの仕事

ネットワークの入口では、「この人は本人か」を確かめるだけでは足りません。入れた後に「どこまで使わせるか」を決め、「いつ、どれだけ使ったか」を記録しておく必要もあります。この3つをまとめて、それぞれの英語の頭文字からAAA（トリプルエー）と呼びます。RADIUSは、このAAAを実現するためのプロトコルです。

AAA	確かめること	具体例	入館にたとえると
Authentication （認証）	あなたは誰か、本人か	ユーザー名とパスワード、電子証明書の確認	受付で社員証を確認する
Authorization （認可）	あなたは何をしてよいか	接続先VLANの指定、通信を制限するフィルタ、接続時間の上限	入れるフロアを決める
Accounting （アカウンティング）	いつ、どれだけ使ったか	接続の開始・終了時刻、接続時間、送受信したデータ量の記録	入退館の記録を残す

特に混同しやすいのが認証と認可です。認証は「本人確認」、認可は「本人とわかった人に与える権限」です。同じ社員でも、営業部の人と開発部の人とで入れるネットワークを分けたい、といった要件は認可で実現します。

RADIUSの登場人物

RADIUSの仕組みには、次の4つの登場人物が出てきます。名前の付け方に少しクセがあるので、ここで整理しておきます。

登場人物	役割	具体例
ユーザー（端末）	ネットワークにつなぎたい人とその機器。802.1Xでは「サプリカント」と呼びます	社員のPC、スマホ
RADIUSクライアント（NAS）	端末が最初につながる入口の機器。端末から受け取った情報をRADIUSサーバに送り、答えに従って通すか止めるかを決めます	無線LANのAP、スイッチ、VPN装置
RADIUSサーバ	問い合わせを受けて、許可・拒否と、許可する範囲を判定します	Windows ServerのNPS、FreeRADIUS、Cisco ISE など
ユーザーDB	ユーザー名・パスワードやグループ情報を持つ台帳。RADIUSサーバが照会します	Active Directory、LDAPサーバ、RADIUSサーバ内のユーザー一覧

端末とNASの間はRADIUSではない

図3のとおり、端末からNASへ資格情報（ユーザー名・パスワードや証明書）を渡す区間では、RADIUSは使いません。この時点の端末はまだネットワークに入れておらず、IPアドレスを持っていないこともあるためです。

無線LANや有線LANの802.1X認証では、IPを使わずにレイヤ2（LANの中）で認証のやり取りを運ぶEAPOL（EAP over LAN）を使います。端末が送ったEAPのメッセージを、NASがRADIUSのEAP-Message属性に詰め替えてRADIUSサーバに中継します。NASは中身の判定をせず、橋渡し役に徹している、と考えるとわかりやすいです。

接続から切断までの流れ

社員がPCを社内のWi-Fiにつなぐ場面を例に、最初の接続から切断までのやり取りを順番に見ていきます。紺の矢印がRADIUSのメッセージです。

端末がNASに接続を求める（①）

PCが社内のSSIDにつなごうとすると、APはまだ通信を通さず、まず資格情報を求めます。PCはユーザー名・パスワードや電子証明書を、802.1X（EAPOL）でAPに渡します。

NASがRADIUSサーバに問い合わせる（②）

APは受け取った情報をAccess-RequestというRADIUSのメッセージに入れ、RADIUSサーバのUDP 1812番に送ります。メッセージには、ユーザー名のほか、どのNASのどのポートからの要求か、端末のMACアドレスなども入ります。

RADIUSサーバは、あらかじめ登録したNASからの要求だけを受け付けます。NASとRADIUSサーバは「共有シークレット」という合言葉を互いに設定しておき、これを使ってメッセージが本物かを確かめます。共有シークレットが一致していないと、認証は成功しません。

RADIUSサーバが判定する（③④）

RADIUSサーバは、ADなどのユーザーDBに照会して本人かどうかを確かめ（認証）、所属グループなどから許可する範囲を決めます（認可）。802.1Xの場合は、サーバと端末の間でEAPのやり取りが何往復か続くため、その間はサーバがAccess-Challengeを返し、NASが次のAccess-Requestを送る、という形で中継が繰り返されます。

判定結果をNASに返す（⑤⑥）

判定結果は、次のどれかのメッセージで返ります。

メッセージ	意味	NASの動き
Access-Accept	許可。接続先VLANなどの指示（属性）を付けて返せる	指示どおりに通信を通す
Access-Reject	拒否（パスワードが違う、アカウントが無効など）	接続を拒否する
Access-Challenge	追加の情報が必要（ワンタイムパスワードの入力、EAPの続きなど）	端末とのやり取りを続け、もう一度問い合わせる

Access-Acceptを受け取ったAPは、PCの通信を通し始めます。PCはここで初めてDHCPでIPアドレスをもらい、普通に通信できるようになります。

利用の記録を送る（⑦⑧）

通信を通し始めると、APはAccounting-Request（開始＝Start）をRADIUSサーバのUDP 1813番に送り、サーバは受け取った印にAccounting-Responseを返します。切断したときにはStop、設定によっては接続中に途中経過（Interim-Update）も送られます。Stopには接続時間や送受信したデータ量が入るため、「Aさんは何時から何時まで、どのAPにつながっていたか」を後から確認できます。

RADIUSのメッセージとポート番号

ここまでに出てきたメッセージを一覧にします。RADIUSのメッセージは先頭のCode（1バイト）の値で種類が決まります。パケットキャプチャで確認するときの手がかりになります。

メッセージ	Code	向き	用途
Access-Request	1	NAS → サーバ	認証・認可の問い合わせ
Access-Accept	2	サーバ → NAS	許可（属性で認可の内容を伝える）
Access-Reject	3	サーバ → NAS	拒否
Accounting-Request	4	NAS → サーバ	利用状況の報告（Start／Stop など）
Accounting-Response	5	サーバ → NAS	報告の受領
Access-Challenge	11	サーバ → NAS	追加の情報を求める

通信	ポート番号
認証・認可	UDP 1812
アカウンティング	UDP 1813

RADIUSだからできること

RADIUSは「入れる／入れない」を決めるだけではありません。ネットワーク機器と直接やり取りするので、通信そのものの扱いを変えることができます。ここが、Webアプリのログインの仕組みでは代わりにならない部分です。

人によって入るネットワークを変える（ダイナミックVLAN）

Access-AcceptにVLAN番号を入れて返すと、NASはその端末を指定されたVLANに入れます。同じSSID、同じスイッチにつないでも、営業部の人はVLAN 10、開発部の人はVLAN 20、のように所属に応じて分けられます。

VLANの指定には、標準では次の3つの属性を組み合わせて使います（RFC 3580）。

属性	値	意味
Tunnel-Type	VLAN（13）	VLANを指定することを示す
Tunnel-Medium-Type	802（6）	IEEE 802（イーサネットなど）のネットワークであることを示す
Tunnel-Private-Group-ID	VLAN番号（例：10）	入れるVLANの番号

このほか、通信を制限するフィルタ名を返すFilter-Idや、ベンダー独自の属性（Vendor-Specific）を使って、ACLの適用や管理者権限の付与などを指示することもできます。

つながっている途中で権限を変える・切断する

通常のRADIUSは、NASが問い合わせてサーバが答える一方通行です。これを拡張したのがRFC 5176で定義されているCoA（Change of Authorization）とDisconnect-Requestで、サーバ側から接続中のセッションに対して「権限を変えて」「切断して」とNASに指示できます。通信はUDP 3799番を使います。

たとえば、セキュリティ製品がマルウェアに感染したPCを見つけたときに、そのPCを隔離用のVLANに移す、といった運用に使われます。対応しているかどうかは機器によって違うので、使う場合はNASとサーバ両方の対応を確認してください。

ネットワーク機器への管理者ログイン

ルータやスイッチ、ファイアウォールに管理者がログインするときの認証にもRADIUSを使えます。管理者のアカウントを機器ごとに作らずに済み、退職や異動のときも1か所の変更で済みます。なお、コマンドごとに実行を許可する、といった細かい制御が必要な場合はTACACS+が使われることもあります。

LDAP・SAML・OAuthとの違い

認証まわりのプロトコルは名前が似ていて混同しやすいのですが、それぞれ守る場所と役割が違い、組み合わせて使うものです。

プロトコル	主な役割	使われる場面	たとえ
RADIUS	ネットワークに入るときのAAA	無線LAN・有線LANの802.1X、VPN、機器の管理者ログイン（UDP 1812/1813）	建物の入館ゲート
LDAP	ユーザー情報（ディレクトリ）の検索と照合	ADやLDAPサーバへの問い合わせ（TCP 389、LDAPSは636）	社員名簿
SAML	Webアプリのシングルサインオン	ブラウザでクラウドサービスにログインするとき	各部屋の前で見せる入館パス
OAuth 2.0 OpenID Connect	OAuthはAPIを使う権限の受け渡し（認可）。OpenID ConnectはOAuthの上にログイン（認証）を加えたもの	アプリ間のデータ連携、「Googleでログイン」など	用途を限った合鍵を渡す

実際の会社では、これらを次のように組み合わせて使います。

• 社員がWi-Fiにつなぐと、APがRADIUSでRADIUSサーバに問い合わせます。
• RADIUSサーバは、裏側のActive DirectoryにLDAPなどで「このユーザーとパスワードは正しいか」「どのグループか」を確認します。
• ネットワークに入った後、ブラウザでクラウドサービスを開くと、SAMLやOpenID Connectでシングルサインオンします。

RADIUSとLDAPの違いは特に聞かれることが多いので、一言でまとめると「RADIUSは入口の機器からの問い合わせ窓口、LDAPは名簿の検索方法」です。NASとADの間にRADIUSサーバを置くことで、VLANの指定やアカウンティングといったネットワーク向けの機能が使えるようになります。

RADIUSの弱点と、いま見直したい対策

RADIUSの暗号化は部分的

RADIUSは1990年代に作られたプロトコルで、通常はUDPで暗号化されずに流れます。共有シークレットとMD5を使って隠されるのはパスワード（User-Password属性）などごく一部で、ユーザー名やMACアドレスなどほかの属性はそのまま読めます。応答が本物かどうかの確認（Response Authenticator）にもMD5が使われています。

BlastRADIUS（CVE-2024-3596）

2024年7月、このMD5の弱さを突く攻撃「BlastRADIUS」が公表されました。NASとRADIUSサーバの通信経路に入り込んだ攻撃者が、MD5の衝突を利用して、サーバが返したAccess-Reject（拒否）をAccess-Accept（許可）に書き換えられる、というものです。成功すると、パスワードを知らなくてもネットワークや機器に入れてしまいます。

攻撃にはRADIUSの通信経路に入り込む必要があるため、すぐに誰でも悪用できるものではありません。ただ、RADIUSの通信が拠点間やインターネットを通る構成や、管理されていないネットワークを経由する構成では注意が必要です。

対策

対策	内容
RADIUSサーバとNASを更新する	各ベンダーからBlastRADIUS向けの修正が出ています。サーバを先に、続けてNASを更新します。
Message-Authenticator属性を必須にする	すべての要求と応答にMessage-Authenticator属性（属性番号80、HMAC-MD5で計算）を付け、付いていないメッセージは捨てる設定にします。応答では最初の属性として入れます。サーバ側とNAS側の両方で「必須」にして初めて効果があります。
RADIUSの通信経路を守る	RADIUSの通信は管理用ネットワークなど信頼できる経路に限定し、拠点間はVPNで保護します。共有シークレットは長く推測しにくい値にします（RFC 2865では16バイト以上を推奨）。
RADIUS over TLS（RadSec）を使う	RADIUSの通信全体をTLSで暗号化します（RFC 6614、TCP 2083）。長期的な対策で、対応している機器どうしで使えます。

まとめ

RADIUSは、ネットワークの入口で「入れてよいか」「どこまで使わせるか」「いつ、どれだけ使ったか」を1か所で管理するためのプロトコルです。ブラウザでのログインが当たり前になった今でも、ブラウザが使えないネットワークの入口では、RADIUSが門番の役割を担っています。

項目	ポイント
なぜ必要か	ユーザー情報を1か所で管理し、ネットワークに入る前（ブラウザが使えない段階）で判定するため
AAA	認証＝本人確認、認可＝権限（VLANなど）、アカウンティング＝利用の記録
登場人物	端末、RADIUSクライアント（NAS＝AP・スイッチ・VPN装置）、RADIUSサーバ、ユーザーDB。RADIUSを話すのはNASとサーバだけ
メッセージ	Access-Request／Accept／Reject／Challenge、Accounting-Request／Response
ポート	認証・認可はUDP 1812、アカウンティングはUDP 1813、CoAはUDP 3799
ほかとの違い	RADIUSは入口、LDAPは名簿の検索、SAML・OpenID ConnectはWebアプリのログイン
セキュリティ	BlastRADIUS対策として、機器の更新とMessage-Authenticatorの必須化。長期的にはRADIUS over TLS