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

はじめに

本記事では、RADIUSを「ネットワーク接続時に何を判定し、何を返し、何を記録するのか」という視点で整理します。用語を暗記するよりも、設計・運用で判断に迷いにくくするための前提として読み進めてください。

持ち運びが容易なモバイルPCやスマートデバイスが普及し、テレワークも一般化しました。企業では、社内外のどこからでも業務ができる一方で、「誰が・どの端末で・どのネットワークに接続しているか」を適切に判定できなければ、不正接続や情報漏えいにつながるおそれがあります。

こうした環境で、無線LANやVPN、有線LAN（802.1X）などの接続制御ポイントでユーザーや端末を判定し、接続条件まで含めて制御する技術の1つがRADIUS認証です。RADIUSは古くから使われてきた標準的な仕組みで、現在も多くのネットワーク機器がRADIUSクライアントとして外部のRADIUSサーバーに認証・認可を問い合わせる方式に対応しています。

なお、本記事で扱うRADIUSは「ネットワーク認証プロトコルとしてのRADIUS（Remote Authentication Dial-In User Service）」を指します。英単語の「半径」や、同名の一般用語・製品名とは意味が異なるため、ここではネットワークアクセス制御（AAA）の話として整理します。

RADIUSを理解するうえでは、用語の定義よりも「接続時に何を判断し、何を返し、何を記録するのか」を知っておくことが重要です。この記事では、RADIUS認証の概要から仕組み、メリット、設計・運用上の注意点までを順に解説します。後半では、現場でつまずきやすい設定・連携・ログの論点もまとめます。

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

RADIUSとは

この章では、RADIUSがカバーする範囲（できること／できないこと）と、設計の初期に確認しておきたい通信・共有鍵の扱いをまとめます。まずは「接続時の判定」を支えるプロトコルとしての位置づけをつかみましょう。

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

最初に、RADIUSで「できること／できないこと／よくある使い方」を要点で整理します。

• できること：接続時に認証を行い、VLANやACLなどの接続条件を属性として返し、機器側がそれを解釈して制御できる。利用状況の記録（Accounting）もあわせて扱える（実際に使える条件や属性は機器の実装に依存します）
• できないこと：RADIUSを使っただけで通信経路が自動的に暗号化されるわけではない。また、接続後の内部横展開対策は別途の設計が必要（無線LANの暗号化は別レイヤーの仕組みによります）
• よくある使い方：企業無線LAN（WPA2-Enterprise／WPA3-Enterprise）、VPN、802.1X（有線LAN）

RADIUSは多くの実装でUDPを用い、一般に認証はUDP/1812、アカウンティングはUDP/1813が使われます（歴史的経緯で1645/1646が残っている環境もあります）。加えて、環境によってはCoA/Disconnect（Change of Authorization）を利用し、別ポート（例：UDP/3799）を使う場合もあります。ファイアウォールやACLの設計では、こうしたポート設計とあわせて「どのネットワーク機器がRADIUSサーバーへ到達できるのか」を明確にしておくことが重要です。到達性が曖昧なままだと、障害時に「認証が不安定」という症状として現れ、原因の切り分けが難しくなります。

またRADIUSでは、RADIUSクライアントとRADIUSサーバーの間でShared Secret（共有鍵）を設定し、メッセージの検証や一部情報の秘匿化に用います。ただし、ここで保護できるのはパケット全体ではなく、仕様上の一部（限定された範囲）です。つまり「RADIUSを使っている＝経路上の盗聴に強い」とは言い切れません。経路が信頼できない場合は、後述するRadSec（RADIUS over TLS/DTLS）や、閉域・VPNなど別の層での保護も含めて検討します。実務では「RADIUSでどこまで保護できるか」を説明できる状態にしておくと、要件定義や監査対応で齟齬が起きにくくなります。

RADIUSは比較的シンプルな実装で、多くのネットワーク機器が「外部認証連携（RADIUSクライアント機能）」として対応しています。複数のスイッチ、無線LANアクセスポイント、VPN装置などに分散しがちなアクセス管理を認証基盤に集約できるため、設定の一貫性を保ちやすく、運用の効率化につながります。加えて、環境によっては同一の認証情報で複数のネットワーク利用に対応でき、利用者側の入力負担や問い合わせ負担が軽減されることもあります。

一方で、RADIUSは「接続時に判定する」ことに強みがある反面、設計を誤ると「許可しすぎるネットワーク」になり得ます。たとえば、認証に通ったユーザーに対して、どのVLANへ入れるのか、どのACLを適用するのか、どの時間帯・どの拠点からを許可するのかといった認可設計が曖昧だと、利便性は高いがリスクも残る構成になりがちです。RADIUSを理解する際は、認証だけでなく「認可（接続条件を返す）」まで含めて捉えることが重要です。ここが曖昧なままだと、運用フェーズで例外が増え、結果として「なぜ通ったのか」を説明しづらい状態になりやすい点は意識しておきたいところです。

なお、後継プロトコルとして「直径」を意味するDiameter（ダイアメーター）があることから、両者の名称はしばしば対比して語られます。DiameterはAAAフレームワークとして標準化されていますが、RADIUSの置き換えが常に前提というわけではなく、用途・要件・既存機器対応に応じて選択されます。実際の設計では「接続を制御する機器がどこまで対応しているか」が選定に大きく影響します。

AAAモデル

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

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

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

AAAと属性の関係

この章では、RADIUSがやり取りする情報を「属性」という単位で捉え、認証・認可・利用記録がどのように組み立てられるかをまとめます。設計やトラブル対応で「どこを見るか」の目安になります。

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

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

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

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

認証を担う属性

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

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

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

認可に使われる属性

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

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

認可設計で重要なのは、許可の粒度を曖昧にしないことです。たとえば「社員はOK」のような大雑把な設計だと、退職・休職・権限変更の反映遅れがそのままリスクになります。属性は便利な一方で、条件分岐が増えすぎると運用が回りにくくなるため、まずは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（ベンダー固有属性）」があります。これは、ネットワーク機器ベンダーなどが独自に定義する属性で、標準仕様だけでは表現しきれない制御を実現するために用いられます。たとえば、ベンダー独自のQoS設定や詳細なアクセス制御条件などを指定するケースがあります。

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

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

RADIUSの利用シーン

この章では、RADIUSが実務でどこに入り込むのかを、接続ポイントの種類ごとにまとめます。「どの接続ポイントで、何を見て、何を返すか」が見えてくると、設計の要点をつかみやすくなります。

RADIUSは、当初はダイヤルアップ接続をはじめとするネットワークアクセス管理の用途で普及しました。ユーザーの接続要求に対する認証・認可に加え、利用状況の記録（Accounting）を一連で扱える点が、当時の運用ニーズに合致したためです。

その後、ネットワークが無線化・分散化し、テレワークや多拠点運用が一般化するにつれて、RADIUSは「接続時の制御」を担う仕組みとして利用範囲を広げてきました。現在では、無線LAN、VPN、有線LAN（802.1X）、ネットワークセグメント制御など、企業ネットワークのさまざまな場面で使われています。

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

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

1990年代は、電話回線を使ってISPに接続し、利用時間に応じて課金や利用管理が行われる環境が一般的でした。この流れの中で、ユーザー認証・アクセス制御・利用記録（Accounting）を一括して扱う仕組みとして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（Extensible Authentication Protocol）を利用した拡張方式が広く利用されています。企業ネットワークでは、盗聴・なりすまし対策の観点から、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認証が「誰と誰が通信し、どの順序で判定が進むのか」をまとめます。ここを押さえると、Reject時の切り分けやログの読み方が楽になります。

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

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

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

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

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

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

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

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

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

RADIUSのメリット

この章では、RADIUS導入で得られる代表的なメリットを「安全性」と「運用性」の両面からまとめます。ポイントは「認証を集約できる」だけでなく、設計次第で接続制御を説明しやすい形にできることです。

RADIUS認証を導入することで、企業ネットワークの安全性向上と運用効率の改善を同時に図れます。ここでは、代表的な4つのメリットをまとめます。

セキュリティ強化

多くのRADIUSサーバー製品は、ワンタイムパスワード（OTP）や証明書認証といった認証方式に対応しています。これにより、従来の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クライアント側（無線LANアクセスポイントやVPN装置など）でも複数のRADIUSサーバーを登録しておく運用が一般的です。これにより、プライマリサーバーが応答しない場合には自動的にセカンダリサーバーへ認証要求を切り替えられ、ネットワーク利用への影響を最小限に抑えられます。

設計時は「二重化すれば安心」で終わらせず、次の点まで確認しておくとトラブルを減らせます。

• フェイルオーバー時に、認証ポリシーやユーザー情報が同じ状態に保たれるか（同期の仕組みとタイミング）
• 切替に要する時間と、クライアント側のリトライ設定（タイムアウト、再送回数）
• 監査・運用上必要なログが冗長構成でも欠損しないか（保管先、集約方法）

加えて、RADIUSはUDPで運ばれることが多く、通信遅延やパケットロスがあると「認証がたまに落ちる」「特定拠点だけ不安定」といった症状になります。冗長化だけでなく、ネットワーク経路とタイムアウト設計も含めて止まりにくい接続制御に整えることが重要です（UDPだから不安定、と決めつけるのではなく、設定と監視で扱える範囲に収めます）。

実務では、障害の切り分けを容易にするために、監視とログの設計も冗長化の一部として扱います。たとえば、サーバーの死活だけでなく、認証成功率やReject率、応答遅延の増加を見られるようにしておくと、止まる前の兆候をつかみやすくなります。冗長構成は「復旧できる」だけでなく、「崩れる前に気づける」設計にすると運用が安定します。

このように、サーバー側とクライアント側の双方で冗長構成を考慮することで、認証基盤全体の可用性を高め、安定したネットワーク運用を実現できます。

RADIUS運用で想定したい脅威

この章では、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によるセキュリティ拡張

この章では、RADIUS通信の経路保護を強める選択肢としてRadSecをまとめます。導入可否は「対応製品の有無」だけでなく、証明書運用と性能設計まで含めて判断します。

RadSecは、一般にRADIUS over TLS（RFC 6614）を指す呼称として使われることが多く、RADIUS通信をTLSで保護することで、従来のRADIUSで課題とされてきた通信経路上の盗聴や改ざんリスクを下げることが期待できます。一方で、DTLSで保護する方式はRADIUS over DTLS（RFC 7360）として規定されており、状況によっては両者をまとめて指す場合もあります（呼び方が揺れる点に注意します）。

RADIUS over TLSはRFC 6614、RADIUS over DTLSはRFC 7360で規定されています（状況によって、RADIUS over TLSをRadSecと呼ぶことがあります）。

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

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運用で問題になりやすいポイントを、切り分け順に並べてまとめます。前章で挙げた脅威やリスクを、実務の確認手順へ落とし込む位置づけです。

RADIUSは標準的な仕組みですが、現場では「通らない」「たまに落ちる」「想定と違うVLANに入る」といった形でつまずくことがあります。ここでは、製品やベンダーを問わず共通しやすい見落としポイントを、設計と運用の観点でまとめます。導入検討の段階でも、この章をチェックしておくと手戻りが減ります。

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

• 送信元の識別：どの機器がRADIUSリクエストを投げるのかを整理し、RADIUSサーバー側で許可する送信元（IP、NAS-Identifier等）を明確にします。拠点追加や機器更改で送信元が変わると、突然Rejectになることがあります。
• Shared Secretの整合：Shared Secretの不一致は、もっとも基本的で頻度が高いトラブル要因です。機器側とサーバー側で同じ文字列になっているか、余計な空白が混ざっていないかまで確認します。
• 到達性の確認：UDP/1812（認証）とUDP/1813（Accounting）が、接続制御を担う機器からサーバーへ到達できるかを事前に確認します。経路が複雑な環境では、FW/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を導入する際には、認証機能そのものだけでなく、想定される同時接続数や認証頻度、可用性要件、他システムとの連携範囲などを踏まえて、適切なRADIUSサーバーの形態を選択する必要があります。ここでは、代表的な4つの形態と、それぞれの特徴および注意点をまとめます。

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

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

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

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

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

専用アプライアンス型

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

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

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

クラウドサービス型

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

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

まとめ

この章では、RADIUSの位置づけを「接続時の制御」という観点で振り返り、導入時に外せない設計論点を再確認します。読み終えたあとに次に検討すべき点が残る形で締めます。

RADIUSは、企業ネットワークにおけるユーザー認証を安全かつ効率的に実現するための中核技術として、長年にわたり幅広く利用されてきました。無線LANやVPN、有線LAN（802.1X）、ダイナミックVLANなど、多様なネットワーク環境に対応できる点はRADIUSの大きな特長です。

また、AAAモデルに基づく認証・認可・利用記録の考え方を前提に、属性（Attribute）を通じて接続条件まで制御できるため、設計次第で「接続時の制御と運用の見通しを両立する」構成を目指せます。加えて、Active Directoryなど既存の認証基盤と連携しやすい点も、企業利用において重要なメリットといえるでしょう。

一方で、RADIUSは「導入すれば安全になる」という仕組みではありません。認可設計（VLAN・ACL・条件分岐）、冗長化、ログの取り方、証明書運用といった実務要件を詰めて初めて、期待した効果が出ます。特に通信経路の保護が必要な場面では、RadSec（RADIUS over TLS/DTLS）も選択肢になります。

本記事では、定義や仕組みだけでなく、運用でつまずきやすいポイントをチェックリストとしてまとめました。RADIUSは接続制御の基盤になりやすい分、問題が起きると影響が大きくなります。だからこそ、導入前に「何を見るべきか」を押さえておくことが、安定運用につながります。

ネットワークの分散化やリモートアクセスの常態化が進む中で、RADIUSとその周辺技術は、今後も企業ネットワークを支える要素であり続けると考えられます。

よくある質問

この記事の内容を踏まえ、読者が検索しやすい形で要点を確認できるように、よくある質問をまとめます。FAQは本文の言い換えではなく、理解を補う目的で整理しています。