RADIUSとは？ 認証の仕組みや導入のメリットなどを解説

はじめに

RADIUSは、無線LANやVPN、有線LAN（IEEE802.1X）などの接続ポイントで、認証・認可・利用記録（AAA）を外部サーバーへ集約するプロトコルです。ネットワーク機器はRADIUSクライアントとしてRADIUSサーバーへ問い合わせ、接続可否に加えて、VLANやACLなどの接続条件を受け取れます。

RADIUSの価値は、接続時の判定をまとめて管理できる点にあります。無線LAN、VPN、有線LANで認証ルールをばらばらに持たせず、誰の接続を許可するか、どのセグメントへ収容するか、どの条件を適用するかをそろえやすくなります。一方で、RADIUSを導入しただけで通信経路全体が暗号化されたり、接続後の横展開対策まで自動的に完結したりするわけではありません。

• できること：接続時の認証、接続条件の返却、利用記録の集約
• できないこと：通信経路全体の自動暗号化、接続後の到達範囲や横展開対策の完結
• 最初に確認すべき点：認証方式、返却する属性、到達性、ログ設計、冗長化

本記事で扱うRADIUSは、ネットワーク認証プロトコルとしてのRADIUS（Remote Authentication Dial-In User Service）です。英単語の「半径」や同名の一般用語とは別物として、ネットワークアクセス制御の文脈で説明します。

モバイルPCやスマートデバイス、テレワークの普及により、企業は「誰が、どの端末で、どの接続ポイントから接続してきたか」を判断し、その判断結果を説明できる設計を求められるようになりました。RADIUSは、その接続時制御を支える代表的な方式です。

株式会社ソリトンシステムズでも、RADIUS認証アプライアンス「NetAttest EPS」を開発しており、さまざまなお客様にご利用いただいています。

RADIUSとは

RADIUS（ラディウス）は「Remote Authentication Dial-In User Service」の略称で、ネットワークアクセスにおける認証・認可・利用記録（AAA）を扱うプロトコルとして利用されています。RADIUSは1990年代に商用実装として普及し、その後IETFのRFCとして標準化され、改訂や拡張を経ながら現在に至りました。代表的な仕様として、認証・認可を扱うRFC 2865、利用記録（アカウンティング）を扱うRFC 2866があります。

RADIUSを理解するときに重要なのは、単なる用語の定義ではなく、接続時に何を確認し、何を返し、何を記録するのかです。認証だけでなく、接続後の条件付けと記録まで扱える点が、単なるID照合の仕組みとの違いです。

• できること：接続時に認証を行い、VLANやACLなどの接続条件を属性として返し、機器側がそれを解釈して制御できる。利用状況の記録も扱える
• できないこと：RADIUSを使っただけで通信経路が自動的に暗号化されるわけではない。接続後の内部横展開対策や端末ふるまい監視は別設計が必要
• よくある使い方：企業無線LAN（WPA2-Enterprise／WPA3-Enterprise）、VPN、IEEE802.1X（有線LAN）

RADIUSが向くケース・向かないケース

• 向くケース：無線LAN、VPN、有線LANで認証ルールを統一し、接続条件やログも含めて接続時に管理したい場合
• 特に向くケース：部署、端末種別、接続元に応じて、VLANやACLなどの条件を切り替えたい場合
• 向かない前提：RADIUS単体で通信経路の保護、端末の安全性確認、接続後の横展開対策まで完結させようとする設計
• 導入前に決めること：認証方式、返却する属性、障害時の切替方法、ログの保管先、冗長構成の取り方

802.1X・EAPとの違い

• 802.1X：端末とネットワーク機器の間で、接続を許可するかを判断する枠組み
• EAP：本人確認のやり取りをどう行うかを定める方式群
• RADIUS：ネットワーク機器と認証サーバーの間でAAAの問い合わせと応答を運ぶ仕組み

RADIUSは多くの実装でUDPを用い、一般に認証はUDP/1812、アカウンティングはUDP/1813が使われます。歴史的経緯でUDP/1645、UDP/1646が残っている環境もあり、環境によってはCoA/Disconnect（Change of Authorization）で別ポートを使う場合もあります。ファイアウォールやACLの設計では、どのネットワーク機器がRADIUSサーバーへ到達できるのかを、ポート設計とセットで明確にしておく必要があります。

また、RADIUSではRADIUSクライアントとRADIUSサーバーの間でShared Secret（共有鍵）を設定し、メッセージの検証や一部情報の秘匿化に用います。ただし、ここで保護できるのはパケット全体ではなく、仕様上の一部です。つまり、RADIUSを使っているだけで通信経路上の盗聴や改ざんに十分対応できるとは限りません。経路が信頼できない場合は、後述するRadSec（RADIUS over TLS/DTLS）や、閉域・VPNなど別の層での保護も含めて検討します。

RADIUSは比較的シンプルな実装で、多くのネットワーク機器が外部認証連携の仕組みとして対応しています。複数のスイッチ、無線LANアクセスポイント、VPN装置などに分散しがちなアクセス管理をRADIUSサーバー側へ集約できるため、設定の一貫性を保ちやすく、運用効率の向上につながります。

一方で、RADIUSは接続時の判定に適した仕組みである反面、設計を誤ると、認証に成功したユーザーへ過剰な到達範囲を与えるネットワークになり得ます。どのVLANへ収容するのか、どのACLを適用するのか、どの時間帯・どの拠点からの接続を許可するのかといった認可設計が曖昧だと、運用時に「なぜ許可されたのか」を説明しづらくなります。

なお、後継プロトコルとして「直径」を意味するDiameterがあり、名称の対比から両者が並べて語られることがあります。ただし、Diameterが常にRADIUSの置き換えになるわけではありません。実際の選定では、用途、要件、既存機器の対応状況が優先されます。

AAAモデル

RADIUSは、ネットワークアクセス制御を行うAAAモデルに基づく代表的な仕組みとして知られています。AAAとは、以下の3つの機能の頭文字を取ったもので、ネットワーク上でのアクセス管理を整理する基本的な枠組みです。

• Authentication（認証）
  利用を要求してきた人物や端末が、許可された正当なユーザーまたは端末であるかを確認します。IDとパスワードに加え、デジタル証明書やワンタイムパスワードなど、複数要素を組み合わせる設計も採用されます。
• Authorization（認可）
  認証に成功したユーザーや端末に対して、利用可能なサービスやアクセス可能な範囲を定めます。RADIUSでは認証結果とあわせてVLANやACLなどの条件を返す運用が多い一方で、どの条件を返すかは設計ポリシーに依存します。
• Accounting（利用記録）
  認可されたユーザーや端末が、いつ、どのようにネットワークを利用したかの記録を取る機能です。RADIUSは歴史的に接続時間や通信量の集計にも用いられてきた経緯があり、利用記録の仕組みが仕様として整備されています。

AAAを認証だけの話で終わらせず、認可と利用記録まで含めて理解しておくと、設計・運用、ログ解析、ポリシー調整、監査対応で判断しやすくなります。RADIUS導入の目的が接続時の制御なのか、利用状況の追跡なのかによって、必要な属性やログ設計は変わります。

AAAと属性の関係

RADIUSがやり取りする情報は、属性（Attribute）という単位で表されます。認証・認可・利用記録がどのように組み立てられるかを把握すると、設計やトラブル対応で確認すべき点が明確になります。

AAAの各処理は、RADIUSにおける属性として表現され、認証要求、応答、利用記録（Accounting）といった通信の中でやり取りされます。ユーザーID、接続元情報、認可内容、利用状況など、RADIUSが扱う情報の多くは属性として整理されています。

RADIUSの設計やトラブル対応では、どの属性が送られ、どの属性が返り、機器側がそれをどう解釈するかを確認することが重要です。同じVLAN返却でも、機器ベンダーや設定によって参照する属性が異なることがあり、意図しないセグメントへ収容される原因になります。属性は仕様で定義される標準属性に加え、後述するVSA（ベンダー固有属性）も存在するため、運用ではログと設定を属性単位で突き合わせる場面があります。

実務では、どの機器が認証要求を送信したのか、どのSSIDやポートから来たのかを表す属性も重要です。NAS-IP-AddressやNAS-IdentifierはどのRADIUSクライアントかを見分ける材料になり、Called-Station-Idは無線LANでSSIDやBSSIDにひもづく値として扱われることがあります。トラブル時は、ユーザー名だけでなく、どの接続ポイントから来た要求かを追える設計が必要です。

属性は設計の幅を広げる一方で、条件分岐が増えるほど運用が難しくなります。属性の応答条件を増やしすぎると、トラブル時にどの条件分岐に該当したのかを追う必要が出てきます。まずはVLANやACLなど、運用で説明しやすい軸から段階的に増やすと、複雑化を抑えやすくなります。

認証を担う属性

ユーザーがネットワークにアクセスしようとすると、RADIUSクライアントはRADIUSサーバーにAccess-Requestパケットを送信します。このパケットには、User-NameやUser-Passwordなど、認証に必要な基本情報を表す属性が含まれます。

代表的な属性の一つにCalling-Station-Idがあります。これは接続元を識別するための属性で、用途や運用によって扱われる内容が変わります。無線LAN環境では、Calling-Station-Idに端末のMACアドレスを設定する運用があり、ユーザーIDと接続元情報の両方を照合した認証設計も可能です。

ただし、MACアドレスは環境によって詐称され得るため、これだけで端末の正当性を保証できるわけではありません。証明書ベースの方式（EAP-TLSなど）や端末管理と組み合わせ、どの条件を必須とするかを整理します。端末識別を重視する場合は、MACアドレスだけに依存せず、証明書、端末登録、管理状態など、偽装しにくい材料を優先します。

認可に使われる属性

RADIUSサーバーが認証に成功すると、Access-Acceptパケットで応答が返されます。この応答には、ユーザーに対してどのようなネットワーク利用を許可するかを示す属性が含まれ、これが認可の役割を果たします。

所属部門や利用目的に応じて動的にVLANを割り当てる場合は、Tunnel-TypeやTunnel-Private-Group-IDなどの属性でVLAN情報を通知します。また、Filter-Idを指定することで、接続後に適用するアクセス制御を制御することも可能です。こうした属性は、単に接続を許可するかどうかだけでなく、どの条件で接続を許可するかを具体化するために用いられます。

認可設計で重要なのは、許可の粒度を曖昧にしないことです。例えば、社員であれば一律に許可する設計では、退職、休職、権限変更の反映遅れがリスクになります。属性は便利な一方で、条件分岐が増えすぎると運用しにくくなるため、まずはVLAN、ACL、時間帯などの軸を絞って段階的に増やすのが現実的です。加えて、機器側でどの属性を参照しているかを事前に検証すると、想定外の収容を減らせます。

利用状況を記録する属性

接続が確立したあとは、その利用状況を記録するAccounting処理が行われます。この際、Accounting-Requestパケットが使用され、Acct-Session-Id、Acct-Status-Type、Acct-Input-Octetsなどのアカウンティング属性が含まれます。RADIUS AccountingはRFC 2866として仕様化されています。

実運用では、開始（Start）・終了（Stop）に加えて、一定間隔で途中経過を送るInterim-Update（中間更新）を利用する設計もあります。これにより、いつから接続しているかだけでなく、現在も接続中か、通信量が急増していないかといった観点で把握しやすくなり、インシデント対応や利用状況分析に役立ちます。

一方で、Interim-Updateの間隔を短くしすぎるとログ量が増え、保管・分析基盤の負担が上がります。監査・障害対応で必要な粒度と、日常運用で扱える粒度のバランスを取ることが必要です。

ベンダー固有属性

RADIUSの設計の幅を支える仕組みとして、VSA（Vendor-Specific Attribute：ベンダー固有属性）があります。これは、ネットワーク機器ベンダーなどが独自に定義する属性で、標準仕様だけでは表現しきれない制御を実現するために用いられます。ベンダー独自のQoS設定や詳細なアクセス制御条件などを指定するケースがあります。

VSAを活用すると、RADIUSサーバーは単に認証するかどうかを判断するだけでなく、ネットワーク機器の動作も含めた細かな制御を行えます。その一方で、VSAは機器依存になりやすく、将来の機器更改やマルチベンダー構成で設計が複雑化する場合があります。どこまでを標準属性でそろえ、どこからをVSAに寄せるのかを決めておくと、長期運用での手戻りを減らせます。

RADIUSは多くの情報を属性という単位で扱い、AAAモデルの各機能を実現しています。どのタイミングで、どの属性が送受信されるのかを理解しておくことは、RADIUS認証のトラブル対応や運用見直しで役に立ちます。

RADIUSの利用シーン

現在のRADIUSは、無線LAN、VPN、有線LAN（802.1X）など、企業ネットワークの接続ポイントで接続可否を判定する用途で使われています。接続可否だけでなく、返却する属性によってセグメントやアクセス条件も切り替えられるため、接続ポイントが増えてもルールをそろえやすい点が特長です。

もともとはダイヤルアップ接続の認証・認可・利用記録を一連で扱う用途で普及しましたが、ネットワークの無線化と分散化が進むにつれて、企業ネットワーク全体の接続制御へ利用範囲が広がりました。

利用シーンを整理する際は、接続ポイントの種類と返したい接続条件をセットで考えると見通しがよくなります。無線LANならSSIDや端末種別、有線LANならポート種別や設置場所、VPNなら接続元や認証強度といったように、接続ポイントごとに確認したい情報と返したい条件が変わるためです。

ダイヤルアップ認証での活用

1990年代は、電話回線を使ってISPに接続し、利用時間に応じて課金や利用管理が行われる環境が一般的でした。この流れの中で、ユーザー認証、アクセス制御、利用記録を一括して扱う仕組みとしてRADIUSが採用されました。現在、ダイヤルアップ接続の利用は大きく減少していますが、一部のレガシー環境では引き続きRADIUSが用いられる場合があります。

ダイナミックVLAN環境の実現

RADIUSは、対応するスイッチや無線LANアクセスポイントと組み合わせることで、ダイナミックVLAN（Dynamic VLAN）構成を実現できます。これは、端末やユーザーの属性に応じてVLANを動的に割り当て、適切なネットワークセグメントへ自動的に接続させる仕組みです。

認証時にRADIUSサーバーがVLAN情報を属性として応答することで、ネットワーク機器はそのユーザーに応じたVLAN設定を適用します。これにより、部署や業務内容に応じたアクセス制御が可能となり、ネットワークのセキュリティと管理性の向上につながります。

一方で、ダイナミックVLANは属性を返せば自動的に安全になる仕組みではありません。想定と異なる属性を機器が参照していると、意図しないVLANへ収容されます。運用開始前に、実機でどの属性を見ているか、どの優先順位で解釈されるかを確認しておくと、想定外の動作を減らせます。

企業無線LAN環境のセキュリティ強化

RADIUSは、企業の無線LAN環境において標準的な認証基盤として利用されることが多い仕組みです。特にWPA2-EnterpriseやWPA3-Enterpriseでは、RADIUSと連携したEAP（Extensible Authentication Protocol）による認証を用いる構成が一般的です。

EAP認証では、ID／パスワードやデジタル証明書を用いた方式を用途に応じて選択できます。証明書ベースの方式は、パスワード漏えいリスクを抑えやすい一方で、証明書配布や失効管理といった運用が重要になります。ID／パスワード系は導入しやすい反面、認証強度の確保や多要素認証との組み合わせを検討する必要があります。

無線LANは電波が届く範囲から接続試行が可能になるため、接続時の判定が弱いとリスクに直結しやすい分野です。SSIDの使い分け、端末種別の切り分け、証明書運用の体制などを、認証方式の選定と同じくらい重要な設計項目として扱います。

有線LANの端末判定

有線LANでも、IEEE 802.1Xを用いることで、物理ポートへ接続しただけで社内ネットワークを利用できる状態を避け、端末やユーザーの認証を接続時に行う構成を取れます。会議室やフリーアドレス環境のように、ポートの利用者が固定されない場合は特に、802.1XとRADIUSの組み合わせが有効です。

運用面では、ユーザー認証と端末認証（マシン認証）の扱いを決めておくことが重要です。社給端末は端末証明書で収容し、社外端末は限定セグメントへ収容する、といった設計が考えられます。さらに、プリンターやIoT機器など、人がログオンしない端末をどう扱うかも、802.1X設計では先に決めておく必要があります。

リモートアクセス時の認証

テレワークやモバイルワークの普及により、VPNを経由して社内システムへアクセスするケースが一般的になっています。RADIUSはVPNゲートウェイと連携し、ユーザーの認証処理を担います。

ワンタイムパスワードなどの多要素認証と組み合わせることで、パスワード漏えいやリプレイ攻撃に対する耐性を高め、安全なリモートアクセス環境の構築に役立ちます。RADIUSに対応したVPN装置であれば、RADIUSサーバー側の設定を活用して導入しやすい点も特長です。

VPNでは、接続時の認証強度に加えて、接続後にどこまで到達させるかも重要です。RADIUS側で返す属性（VLAN、ACLなど）と、VPN側のアクセス制御をどう分担するかを決めておくと、例外が増えにくい設計になります。

RADIUSの認証方式

RADIUSの認証方式を考えるときは、RADIUS、802.1X、EAPの役割を分けて捉える必要があります。混同を避けると、方式選定が暗号強度だけの話ではないことが分かります。

RADIUSには、初期から存在するシンプルな認証方式に加え、EAPを利用した拡張方式が広く利用されています。企業ネットワークでは、盗聴やなりすまし対策の観点から、EAPを用いた方式、特に802.1Xと組み合わせた方式を採用するケースが一般的です。

注意したいのは、「RADIUSの認証方式」と言った場合に、RADIUSそのもののパスワード取扱いと、EAPで実施するユーザー認証が混同されやすい点です。RADIUSは認証要求を運ぶ役割として振る舞う場面も多く、実際の本人確認はEAPの方式（PEAP、EAP-TLSなど）に依存します。そのため、方式選定では、どのEAP方式を使うか、証明書運用をどうするか、端末管理とどう組み合わせるかまで含めて検討します。

• 802.1X：端末とネットワーク機器の間で、接続を許可するかを判断するための枠組み
• EAP：本人確認のためのやり取りの方式。ID／パスワード、証明書などの選択肢を持つ
• RADIUS：ネットワーク機器と認証サーバーの間でAAAの問い合わせと応答を運び、認証結果と接続条件を返す

この整理を押さえると、検討すべき点が見えやすくなります。端末に証明書を配布できる体制があるかはEAP方式の選定に直結し、認証後にどのVLANへ収容するかはRADIUSが返す属性と機器側の解釈に直結します。方式の選択は、暗号強度だけでなく、運用体制と機器側の実装まで含めた判断になります。

初期からの認証方式

拡張された認証方式（EAP系）

IEEE 802.1Xの普及により、RADIUSはEAPと連携する構成が一般化しました。802.1X環境では、端末（サプリカント）、ネットワーク機器（オーセンティケータ）、認証サーバー（RADIUS）が役割分担し、RADIUSは認証結果と接続条件を返す役割を担います。

EAP方式は、どれか一つを万能な方式として選ぶものではありません。端末管理の可否、証明書運用の体制、想定する接続ポイント（無線、有線、VPN）といった現実条件との整合で選びます。また、方式ごとに確認すべき点が異なるため、認証失敗時にどこを確認するかまで含めて設計しておくと、運用フェーズでの手戻りを減らせます。

無線LAN・リモートアクセスで認証が重要になる理由

2022年6月に実施した「企業ネットワーク及び関連システムに関する調査」では、無線LANやテレワーク環境の運用が進んでいる状況が示されています。こうした環境の拡大に伴い、ネットワークへの接続可否を適切に制御する認証の重要性は高まっています。

無線LANやリモートアクセスは利便性が高い一方で、利用者や端末の真正性を適切に判定できなければ、不正アクセスや情報漏えいのリスクが高まります。接続時の判定が弱いと、一度接続を許可された後に不要な範囲まで到達できる状態を招きやすく、ネットワーク全体の被害が大きくなるおそれがあります。

この状況で必要なのは、認証の仕組みを整えるだけでなく、認証結果をもとに到達可能な範囲を制御することです。つまり、認証強度の話と同時に、認可（VLAN、ACLなど）の話をセットで考える必要があります。RADIUSは、無線LAN、VPN、有線LANなどの接続制御ポイントに認証を集約し、認可も含めて制御できるため、こうした課題に対する選択肢になります。

一方で、接続時の制御が厳密になるほど、運用に求められる品質も上がります。認証サーバーに障害が発生すると接続できない利用者が増える、設定ミスが広範囲に影響する、といった基盤特有のリスクが出てきます。次項では、RADIUSがどのように連携して判定するのかを整理し、後段で可用性の高い接続制御のための設計ポイントにも触れます。

RADIUS認証の仕組み

RADIUS認証は、ユーザー、RADIUSクライアント、RADIUSサーバーという3つの要素によって構成されます。これらが役割を分担しながら連携することで、ネットワークへのアクセス可否を制御します。

• ユーザー：ネットワークに接続しようとする利用者および端末
• RADIUSクライアント：ユーザーからの接続要求を受け取り、RADIUSサーバーに認証要求を中継するネットワーク機器（無線LANアクセスポイント、VPN装置など）
• RADIUSサーバー：受信した認証要求に基づいて認証・認可処理を行うサーバー

ユーザーが直接通信を行う相手はRADIUSクライアントであり、通常、RADIUSサーバーとユーザーが直接通信することはありません。この分離により、ネットワーク機器側の設定をRADIUSへ問い合わせる形に統一しやすくなり、拠点や機器が増えてもアクセス制御の一貫性を保ちやすくなります。

RADIUS認証では、3者が以下の手順でやり取りを行います。

1. ユーザーがネットワークへのアクセスを要求する
2. RADIUSクライアントがユーザーに対して認証情報の提示を求める
3. ユーザーが認証情報を提示する
4. RADIUSクライアントが受け取った情報を用いて、RADIUSサーバーにAccess-Requestを送信する
5. RADIUSサーバーが認証・認可処理を行い、その結果（Access-Accept／Access-Reject／Access-Challenge）をRADIUSクライアントに返す
6. RADIUSクライアントが認証結果に基づいて、ユーザーへのネットワーク接続を許可または拒否する

一般的には、Access-Acceptの場合にのみ、ユーザーはネットワークへの接続を許可されます。加えて、Access-Acceptに含まれる属性により、VLANやACLなどの接続条件が適用される場合があります。つまりRADIUSは、単に接続を許可するかだけではなく、どの条件で許可するかまで制御できる仕組みです。

利用記録を使う場合は、認証とは別にAccounting-Request/Responseで接続の開始、終了、途中経過が記録されます。設計時に、どのタイミングで記録を残すか、ログの保管先をどうするかを決めておくと、監査・インシデント対応の場面で判断がぶれにくくなります。

仕組みの理解で見落とされがちなのが、Rejectの原因はRADIUSサーバー側だけに限らないという点です。Shared Secret不一致、到達性（ファイアウォールやACL）、タイムアウト設定、証明書の信頼関係など、接続を制御する機器側や経路側の要因でも、結果として接続に失敗します。後段のチェックリストでは、最初に確認すべき項目を整理します。

このようにRADIUS認証では、認証処理を接続時に集中的に制御できるため、社内ネットワークや無線LAN、VPN環境に不正なユーザーや端末が接続することを防ぐ仕組みとして機能します。

RADIUSのメリット

RADIUS認証を導入すると、企業ネットワークの安全性向上と運用効率の改善を同時に図りやすくなります。メリットは、接続制御の強化と運用の見通しのよさに大きく分けられます。

セキュリティ強化

多くのRADIUSサーバー製品は、ワンタイムパスワードや証明書認証といった認証方式に対応しています。これにより、従来のID／パスワード認証のみに依存した環境と比べ、なりすましや認証情報漏えいのリスクを下げやすくなります。

特に、無線LANやVPNといった接続制御ポイントにRADIUSを配置することで、不正なユーザーや端末の接続抑止に役立ち、情報漏えいリスクの抑制が期待できます。加えて、認可（VLAN、ACLなど）を併用できる設計にすると、接続時の判定結果を接続後の到達範囲に反映しやすくなります。

認証情報の一元管理

RADIUSサーバーを利用することで、複数のネットワーク機器やサービスに分散していた認証情報を一元的に管理できます。Active Directory（AD）やLDAPと連携可能な構成であれば、Windowsログオンと同じID／パスワードを用いた無線LANやVPNの認証も実現しやすくなり、管理者の運用負荷軽減とユーザー利便性の向上を両立できます。

一元管理の利点は、単に情報を集約できることだけではありません。権限変更や退職などのライフサイクル管理を、接続時の認証にも反映しやすくなる点が運用上は重要です。逆に、反映経路が複雑なままだと、退職後も接続が許可されるといった事態につながるため、連携方式と反映タイミングは最初に決めておく必要があります。

認証ポリシーの設計幅

RADIUS認証では、ユーザー属性、端末情報、接続元ネットワークなどの条件に応じて、認証方式やアクセス制御の内容を切り替えることが可能です。社内ネットワークからの接続はID／パスワード認証とし、社外からのアクセスには多要素認証を必須とするなど、リスクに応じたポリシー設計が行えます。

このとき注意したいのは、例外を増やしすぎないことです。条件分岐が増えるほど、なぜこのユーザーがこのVLANに収容されたのか、なぜこの時間帯だけ許可されたのかを追いづらくなり、運用負荷が上がります。セキュリティ要件と運用性のバランスを見ながら、ポリシーを段階的に整備する設計が現実的です。

負荷分散と可用性の確保

認証基盤を一元化する場合、アクセス集中による負荷や障害時の影響範囲を考慮する必要があります。RADIUSは大規模環境での利用実績があり、サーバーの二重化や分散配置に対応した製品が多く存在します。そのため、可用性を確保しつつ安定した認証サービスを提供できる点もメリットです。

ただし、可用性はサーバーを二重化しただけでは十分ではありません。接続制御機器側のリトライ設定、経路の冗長性、ログの欠損対策など、周辺設計まで含めて初めて可用性の高い接続制御になります。次章で冗長構成の考え方を整理します。

冗長構成の重要性と実現方法

認証サーバーは、ネットワークへの接続可否を判断する中核的な役割を担っています。そのため、RADIUSサーバーに障害が発生すると、無線LANやVPNといったネットワークサービス全体を利用できなくなる可能性があります。これは、認証が利用できず、接続を制御できない状態であり、影響範囲が想定以上に広がることがあります。

こうしたリスクを避けるためには、RADIUSサーバーを冗長構成とし、単一障害点（Single Point of Failure）を排除することが重要です。多くのRADIUSサーバー製品は複数台構成による冗長化や負荷分散に対応しており、特定のサーバーに障害が発生した場合でも、認証サービスを継続できるよう設計できます。

さらに、RADIUSクライアント側でも複数のRADIUSサーバーを登録しておく運用が一般的です。これにより、プライマリサーバーが応答しない場合にはセカンダリサーバーへ認証要求を切り替えられ、ネットワーク利用への影響を抑えられます。

設計時は、二重化だけで完了とせず、次の点まで確認しておくとトラブルを減らせます。

• フェイルオーバー時に、認証ポリシーやユーザー情報が同じ状態に保たれるか
• 切替に要する時間と、クライアント側のリトライ設定が整合しているか
• 監査・運用上必要なログが冗長構成でも欠損しないか

加えて、RADIUSはUDPで運ばれることが多く、通信遅延やパケットロスがあると、認証が断続的に失敗することがあります。冗長化だけでなく、ネットワーク経路とタイムアウト設計も含めて、可用性の高い接続制御に整えることが重要です。UDPだから不安定と決めつけるのではなく、設定と監視で扱える範囲に収めます。

実務では、障害の切り分けを容易にするために、監視とログの設計も冗長化の一部として扱います。サーバーの死活だけでなく、認証成功率、Reject率、応答遅延の増加を確認できるようにしておくと、サービス影響が広がる前に兆候を把握しやすくなります。冗長構成は、復旧できるだけでなく、異常の兆候に早く気づける設計にすると運用が安定します。

RADIUS運用で想定したい脅威

RADIUSは、無線LANやVPN、有線LAN（802.1X）といった接続制御ポイントで認証・認可を集約できる一方、接続制御に関わるがゆえに、設計や運用の甘さがそのままリスクとして表れやすい面もあります。重要なのは、RADIUS自体を危険な仕組みと捉えることではなく、どのような前提や設定のときに、どのような脅威が成立しやすいのかを把握しておくことです。

本章では、運用で想定しておきたい代表的な脅威をまとめつつ、それぞれに対して設計・運用でどこに注意を払うべきかを整理します。攻撃手順の解説ではなく、防御視点での整理として読み進めてください。

認証情報の漏えいと推測

RADIUSは接続時の制御に関わるため、ID／パスワード、ワンタイムパスワード、証明書といった認証要素が狙われやすくなります。特に、ID／パスワードに依存した構成では、認証情報の漏えいや使い回し、推測による不正試行がリスクとして現実的です。

このリスクに対しては、RADIUSを導入するだけでなく、多要素認証の併用、証明書ベース方式の検討、失敗回数に応じた制御、ログ監視といった運用を組み合わせることが重要です。接続時の認証失敗が増えていないかを可視化できる設計にしておくことで、被害の拡大を防ぎやすくなります。

EAP設定不備によるなりすましリスク

無線LANや有線LANで802.1Xを用いる場合、RADIUSはEAP認証を中継・判定する役割を担います。このとき、実際の本人確認の強度はEAP方式の選択や端末側の設定に大きく依存します。

端末側でサーバー証明書の検証が正しく行われていない場合、正しい認証サーバーであることを確認しないまま接続してしまう余地が生まれます。RADIUS側の設定だけでなく、端末側の信頼設定や証明書運用まで含めて設計対象とすることが、なりすましリスクを抑えるうえで欠かせません。

RADIUSクライアントなりすまし

RADIUSでは、無線LANアクセスポイントやVPN装置などのRADIUSクライアントと、RADIUSサーバーとの間でShared Secretを用いて通信を行います。この共有鍵の管理が不十分な場合、意図しない機器からの認証要求を受け付けてしまうリスクが生じます。

そのため、RADIUSクライアント登録では、どの機器が、どこから要求を送るのかを明確にし、送信元IPなどを許可制御していることも前提に、識別情報を厳密に管理します。加えて、定期的な鍵の見直しや、不要になった機器登録の洗い出しも、長期運用では欠かせません。

通信経路上での盗聴や改ざん

従来のRADIUSはUDPを用いることが多く、通信経路全体が暗号化されるわけではありません。そのため、信頼できないネットワークを経由する構成では、通信内容の盗聴や改ざんといったリスクを考慮する必要があります。

この点に対しては、閉域網やVPNによる経路保護に加え、RADIUS over TLS/DTLS（RadSec）の採用が検討対象になります。どの対策が必要かは、RADIUSクライアントとサーバーの配置関係やネットワーク構成に依存するため、どの経路が信頼できるのかを整理したうえで判断します。

認可設計の不備による過剰な権限付与

RADIUSは、認証に成功したユーザーに対してVLANやACLなどの条件を返すことで、接続後の到達範囲を制御できます。一方で、この認可設計が粗いと、認証に成功したユーザーへ必要以上に広いネットワーク到達範囲を与えることがあります。

このリスクは、外部からの攻撃というよりも、設計ミスによる内部リスクの拡大として表れやすい点が特徴です。最初から細かく分けすぎる必要はありませんが、どの属性で、どの単位まで許可するのかを明確にし、段階的に見直していく運用が求められます。

RADIUSを巡るリスクの多くは、設定・運用の前提が曖昧なまま使われていることに起因します。脅威の理解を確認手順へ反映することで、運用が安定しやすくなります。

RadSecによるセキュリティ拡張

RadSecは、一般にRADIUS over TLSを指す呼称として使われることが多い言葉です。文脈によっては、RADIUS over DTLSを含めて、RADIUS通信をTLS/DTLSで保護する方式群を指す場合もあります。RADIUS over TLSはRFC 6614、RADIUS over DTLSはRFC 7360で規定されています。

従来のRADIUSでは、認証にUDP/1812、アカウンティングにUDP/1813が使われるのが一般的です。歴史的にはUDP/1645、UDP/1646が使われていた時期もあります。一方、RADIUS over TLSでは、デフォルトの宛先ポートとしてTCP/2083が規定されています。

なお、RADIUS/TLSおよびRADIUS/DTLSについては、2025年公開のRFC 9765でRADIUS/1.1が定義されました。RADIUS/1.1はALPNを用い、RADIUS over TLS/DTLSに残っていたMD5依存を取り除くための transport profile として位置づけられています。現場での採用可否は、製品対応、運用要件、既存構成との互換性を確認して判断します。

RadSecで軽減されるリスクの例

盗聴リスク

従来のRADIUS通信では、通信経路上の盗聴により、ユーザー名や接続条件などが観測されるリスクが残ります。RadSecではTLS/DTLSで通信経路を暗号化するため、第三者による傍受・解析を困難にし、盗聴リスクの低減が期待できます。

改ざんや中間者リスク

RadSecでは、TLS/DTLSによる暗号化に加えて、証明書検証を通じて通信相手の正当性確認を行う前提を置けます。これにより、通信への割り込みや内容改ざんの難易度が上がり、信頼できない経路をまたぐ構成で特に効果が期待できます。

DoSへの考え方

RadSecは、通信を暗号化してなりすましや改ざんを難しくしますが、可用性攻撃に対してそれだけで完結する対策ではありません。実務では、接続制御機器側の制御、ファイアウォールの設計、レート制限、監視といった運用面の対策と組み合わせて、接続制御全体として耐性を高めることが重要です。

RadSecを採用する際の注意点

RadSecを導入するには、RadSecに対応したRADIUSサーバーと、RADIUSクライアント（スイッチ、無線LANアクセスポイント、VPN装置など）の双方が必要です。いずれか一方が非対応の場合、従来のRADIUS通信にフォールバックするか、RadSec自体を利用できない点に注意が必要です。

また、TLS/DTLSによる暗号化処理が加わることで、従来のUDPベースのRADIUSと比べてCPU負荷や通信遅延が増加する可能性があります。大量の認証要求が発生する環境では、性能検証やキャパシティ設計を事前に行います。

さらに、RadSecではサーバー証明書、構成によってはクライアント証明書の発行・更新・失効管理が必要になります。証明書運用の体制が十分でない場合、管理負荷や運用リスクが高まる可能性があります。そのため、導入にあたってはセキュリティ強化の効果と運用コストのバランスを踏まえた設計が求められます。

実務では、RadSecを使うかどうかを二択で考えるよりも、まずRADIUS区間の経路が信頼できるかを確認し、必要なら閉域、VPN、RadSecなどの手段を組み合わせてリスクを下げる発想が現実的です。どこまで保護すれば要件を満たすかという観点で整理すると、選定しやすくなります。

設計と運用のチェックリスト

RADIUSは標準的な仕組みですが、現場では接続できない、断続的に認証が失敗する、想定と違うVLANに収容されるといった問題が起きます。製品やベンダーを問わず共通しやすい見落としポイントを、設計と運用の観点で整理します。導入検討の段階でも、この章を確認しておくと手戻りを減らせます。

RADIUSクライアント登録と識別

• 送信元の識別：どの機器がRADIUSリクエストを送るのかを整理し、RADIUSサーバー側で許可する送信元（IP、NAS-Identifierなど）を明確にします。拠点追加や機器更改で送信元が変わると、突然Rejectになることがあります。
• Shared Secretの整合：Shared Secretの不一致は、基本的で頻度が高いトラブル要因です。機器側とサーバー側で同じ文字列になっているか、余計な空白が混ざっていないかまで確認します。
• 到達性の確認：UDP/1812（認証）とUDP/1813（Accounting）が、接続制御を担う機器からサーバーへ到達できるかを事前に確認します。経路が複雑な環境では、ファイアウォールやACLのどこで遮断されているかの切り分け設計も重要です。

タイムアウトとリトライの設計

• タイムアウトが短すぎる：RADIUSはUDPで運ばれることが多く、遅延や瞬間的なロスがあると断続的な認証失敗につながります。接続制御を担う機器側のタイムアウトとリトライ回数を、ネットワーク条件に合わせて設計します。
• リトライが多すぎる：再送を増やしすぎると、障害時にサーバー負荷が高まり、全体が不安定になることがあります。冗長構成の切替時間との整合も含めて調整します。
• 拠点差の扱い：特定拠点だけ不安定な場合は、サーバーの問題と決めつけず、経路品質、NAT、回線帯域など、機器からサーバーまでの条件を見直します。

認可の応答と機器側の解釈

• VLAN属性：標準属性で返すのか、VSAを使うのかは機器側の実装に依存します。機器が参照する属性の種類と優先順位を、検証で確認します。
• ACLの適用単位：Filter-Idなどで制御できても、実際にどのタイミングで適用されるか、既存の設定と衝突しないかは機器側の動作次第です。意図した到達範囲になっているかを、接続後の疎通で確認します。
• 条件分岐の増やしすぎ：例外が増えるほど説明責任が難しくなります。最初は少ない軸（部署、端末種別など）から始め、運用できる範囲で段階的に拡張します。

Accountingとログ設計

• Interim-Updateの間隔：短くすると可視性は上がりますが、ログ量も増えます。監査・障害対応で必要な粒度に合わせて設計します。
• ログの保管先：冗長構成でも欠損しないように、保管と集約の方針を決めます。必要な期間、検索性、権限管理まで含めると、運用が安定します。
• 見たい情報の定義：ユーザー名だけでなく、接続ポイント（NAS、SSID、ポート）を追えるようにしておくと、インシデント時の切り分けが速くなります。

証明書運用と端末側の信頼

• 証明書チェーン：EAP-TLSやPEAPでは、サーバー証明書を端末が正しく信頼できるかが前提になります。中間証明書の扱いも含めて確認します。
• 失効と更新：証明書の失効・更新が運用に乗っていないと、突然接続できない端末が増える原因になります。期限管理と配布の仕組みを用意します。
• 端末管理との関係：証明書方式は、配布・更新できる体制がないと成立しません。BYODやゲストが混在する場合は、SSIDやVLANを分ける設計とセットで考えます。

よくある失敗

• Shared Secretが一致していない：入力ミス、余計な空白、機器更改時の引き継ぎ漏れで発生します。最初に確認すべき基本項目です。
• 証明書の信頼関係が崩れている：PEAPでサーバー証明書が信頼されていない、EAP-TLSで証明書チェーンが不完全、証明書が失効済みといった原因があります。
• 属性の解釈違いで想定外の収容が発生する：VLAN返却やACL適用で、機器が参照する属性が想定と違い、意図しないネットワークへ収容されることがあります。

チェックリストは、トラブルをゼロにするためのものではなく、切り分けの順番を短くするためのものです。RADIUSは接続制御の基盤になりやすい分、問題が起きると影響が大きくなります。だからこそ、最初に確認すべき点が整理されているだけでも、復旧にかかる時間は変わります。

RADIUSサーバーの形態

RADIUSを導入する際には、認証機能そのものだけでなく、想定される同時接続数や認証頻度、可用性要件、他システムとの連携範囲などを踏まえて、適切なRADIUSサーバーの形態を選ぶ必要があります。代表的な選択肢は、ソフトウェア導入型、内蔵型、専用アプライアンス型、クラウドサービス型の4つです。

形態選びで重要なのは、どれが一律に優れているかではなく、自社の運用体制と要件に合うかです。証明書運用まで含めて担えるか、冗長構成をどう保守するか、ログをどこまで保持・検索するかといった条件で、現実的な選択肢が変わります。

汎用サーバーへのソフトウェア導入型

LinuxやWindowsなどの汎用OS上にRADIUSサーバーソフトウェアを導入する方式は、自由度が高く、細かなポリシー制御や既存システムとの密接な連携が可能です。一方で、OSやミドルウェアの脆弱性対応、パッチ適用、障害時の復旧設計（バックアップ・リストア、BCP対応）などを含めた運用管理は自社で担う必要があります。中規模以上の環境では、運用体制と設計方針を事前に明確にしておくことが重要です。

ネットワーク機器への内蔵型

小規模環境や検証用途では、無線LANアクセスポイントやUTM製品などに内蔵されたRADIUS機能を利用するケースもあります。初期設定や運用が容易である反面、利用可能な認証方式や連携機能、処理性能には制約がある場合が多く、LDAP連携や証明書認証に対応できないこともあります。将来的な拡張や認証基盤の集約を見据える場合には注意が必要です。

専用アプライアンス型

企業ネットワークで広く採用されているのが、RADIUS認証専用に設計されたアプライアンス製品です。安定稼働を重視した構成になっていることが多く、認証基盤としての役割に集中しやすい点が特長です。

専用アプライアンスでは、Active Directory／LDAP連携、証明書運用、ログ管理やレポート機能などが統合されている場合があり、比較的少ない運用負荷で信頼性を確保しやすい傾向があります。製品によっては複数台構成で設定やデータを同期できるものもあります。

ただし、アプライアンスでも設計不要にはなりません。冗長化の方式、ログの保管、証明書の更新など、運用で必要な前提は残ります。形態選びの段階で、チェックリストの論点がどこまでカバーされるかを見ておくと、導入後のギャップを減らせます。

クラウドサービス型

多拠点展開やゼロトラストを前提とした環境では、クラウド上で提供されるRADIUS認証サービスを利用する選択肢もあります。サーバー構築や保守が不要で、短期間で導入できる点がメリットです。

一方で、オンプレミス環境のActive DirectoryやLDAP、証明書基盤と連携する場合には、VPNや専用接続を含めた全体設計が必要になります。また、クラウド事業者側の障害対応範囲と自社の業務継続計画（BCP）との整合性、通信断時にどう振る舞うか（フェイルセーフ設計）を事前に確認しておくことが重要です。

まとめ

RADIUSは、無線LAN、VPN、有線LAN（802.1X）といった接続ポイントで、認証・認可・利用記録をまとめて扱うためのプロトコルです。接続可否だけでなく、VLANやACLなどの条件も返せるため、企業ネットワークの接続制御を一元化しやすい点が特長です。

ただし、RADIUSは接続時の判定を担う仕組みであって、通信経路の保護や接続後の横展開対策まで単体で完結させるものではありません。認証方式、返却属性、ログ設計、証明書運用、冗長構成まで含めて設計して、初めて期待した効果が得られます。

導入判断では、次の5点を外さないことが重要です。何を認証するか、何を返すか、失敗時にどう切り替えるか、何を記録するか、RADIUS区間をどこまで保護するかです。特に信頼できない経路をまたぐ場合は、RadSec（RADIUS over TLS/DTLS）や閉域・VPNなど、別層の保護もあわせて検討します。

RADIUSを理解するときは、製品名や用語だけで見るより、接続時に何を判断し、何を返し、何を記録し、障害時にどう継続させるかで捉えた方が、設計と運用の判断を誤りにくくなります。

よくある質問