現場で見かけるのは、たとえばこんな状態です。社内 Wi-Fi のパスワードは数年前から変わっていない。VPN のアカウントは Excel 台帳と Wiki の両方に載っていて、どちらが最新かは担当者しか分からない。スイッチやルーターの管理者 ID は機器ごとに設定されていて、一覧はどこにもない。
一つひとつは「回っている」ように見えるため、優先度が上がりにくいのが厄介です。退職者が出たとき、外部協力会社の担当が入れ替わったとき、そのたびに「あのアカウントは消したか」「あの機器のパスワードは変えたか」を思い出しながら追いかけることになります。
RADIUS サーバーは、この「認証の入口が分散している状態」を、一つの判断ポイントに集約するための選択肢です。ただし、立てれば解決するわけではありません。まずは、何をどう整理できる仕組みなのかを押さえておきます。
RADIUS サーバーが扱うのは、大きく分けて「本人確認」「利用範囲の判断」「利用記録」の 3 つです。技術的には AAA ( Authentication / Authorization / Accounting ) と呼ばれ、RADIUS はこの AAA プロトコルの一つに位置づけられます。
本人確認：接続しようとしている人や端末が、登録された利用者と一致するかを確かめる
利用範囲の判断：認証を通した相手に、どのネットワーク・どの機器の利用を許可するかを決める
利用記録：誰が、いつ、どこから接続したかをログとして残す
社員は社内ネットワーク、来訪者はゲスト Wi-Fi、管理者はネットワーク機器の管理画面へ、というように分けられます。「接続先と権限を用途ごとに整理する」ための土台と考えると理解しやすい仕組みです。
一方で、RADIUS 単体で端末そのものの保護や、外部からの攻撃遮断まで面倒を見てくれるわけではありません。この点は後半で改めて触れます。
RADIUS サーバーだけを立てても、認証は動きません。実際に利用者の接続を受け付ける機器が、RADIUS サーバーに問い合わせを行う必要があります。この問い合わせを行う機器を、RADIUS クライアントと呼びます。
RADIUS クライアントに該当するのは、無線 LAN アクセスポイント、VPN 装置、スイッチ、ルーター、ファイアウォールなど、利用者が最初に触れる機器です。RADIUS サーバーは「判断する場所」、RADIUS クライアントは「入口で確認する機器」という関係です。
ここで注意したいのが、すべての VPN 装置が RADIUS 前提で使われるわけではないという点です。たとえば Buffalo の 10Gbps 有線対応 VPN ルーター VR-U500X は、IPsec で最大 30 対地、L2TP over IPsec も 30 対地までを本体単体で扱えます。拠点間 VPN の対地数が限られ、利用者も固定的な構成であれば、RADIUS を挟まず VPN 装置側で認証まで完結させる構成も現実的な選択肢になります。
「RADIUS クライアントとして組み込むか、VPN 装置内で完結させるか」は、規模と体制で分かれる論点です。
RADIUS の方向に進める場合、まず確認したいのが、いま社内にあるアクセスポイントや VPN 装置が RADIUS クライアントとして使えるかどうかです。
|
確認項目 |
確認する理由 |
見落とした場合の影響 |
|
RADIUS 認証への対応 |
外部認証サーバーへ問い合わせできるか |
その機器を認証連携に組み込めない |
|
UDP 1812 / 1813 の通信 |
認証・記録用ポートとして一般的に使われる |
通信が通らず認証が成立しない |
|
共有シークレットの設定 |
サーバーと機器の間の合言葉として使う |
値が違うと認証要求が拒否される |
|
802.1X / EAP 対応 |
企業向け Wi-Fi の証明書認証などで必要 |
選べる認証方式が狭まる |
|
セカンダリ RADIUS の指定 |
サーバー障害時も認証を継続するため |
停止時に全社が接続不能になり得る |
|
ログ出力機能 ( Syslog など ) |
認証失敗や不審な接続の追跡に使う |
障害調査に時間がかかる |
機器仕様書を一度は開いておきたいポイントです。「対応している」ことよりも、「何を確認したか」を残しておくと、あとで設計判断を振り返りやすくなります。
RADIUS サーバー構築で成果が分かれるのは、コマンドを叩く前の設計段階です。
社内 Wi-Fi、VPN、ネットワーク機器へのログイン。このうち、どこから RADIUS に寄せるかを決めます。最初からすべてを対象にすると影響範囲が広くなり、切り戻しも難しくなります。まずは社内 Wi-Fi、次に VPN、最後に機器ログインというように段階的に広げるやり方が現実的なケースが多くあります。
検証段階では FreeRADIUS 内に持たせる方法があります。ただし、業務で使う段階では、Active Directory や LDAP と連携し、既存の社員アカウント管理に寄せる構成が候補になります。少人数の情シス部門で台帳が複数に分かれると、退職・異動時の更新漏れが起きやすくなります。
ID・パスワード認証で始めるのか、証明書認証や 802.1X / EAP まで踏み込むのか。厳しくしすぎると、証明書の期限切れや端末交換のたびに問い合わせが増えます。一方で緩くしすぎると、共有 ID や弱いパスワードの運用に戻ってしまい、RADIUS を入れた意味が薄れます。安全性と運用負荷のバランスをどう取るかの話になります。
RADIUS サーバーが止まると、Wi-Fi や VPN に誰も接続できなくなる、という事態はあり得ます。本番運用ではセカンダリ RADIUS の設定や、拠点をまたぐ場合の配置設計まで検討しておきます。
このとき、認証サーバーだけでなく、通信経路の VPN 装置そのものが止まらない前提も併せて考えたい部分です。VPN ルーターの標準保証・有償保守の期間 ( 例：VR-U500X は標準 5 年、有償で最大 7 年 ) や、遠隔管理サービスの有無まで含めて棚卸ししておくと、後追いの改修が減ります。
Linux 環境で構築する場合、FreeRADIUS が代表的な選択肢です。Ubuntu 系での導入時に実行するコマンドは、次のような流れになります。
sudo apt update
sudo apt install freeradius freeradius-utils
sudo systemctl enable freeradius
sudo systemctl start freeradius
ただし、これは入口に過ぎません。業務で使う段階では、RADIUS クライアントの登録、共有シークレットの管理、認証方式の選択、ログの保存、冗長化の設計といった要素の方が、実際の工数を占めます。まずは検証環境で最小構成の疎通確認を行い、想定した端末で接続が成立することを確認してから、本番相当の設定に進める順序が安全です。
ここまでの内容を前提に、あえて逆側の話をします。拠点数と利用者が限られる規模では、RADIUS を立てない方が運用が回りやすいケースがあります。
たとえば、SOHO や小さな支所を本社と VPN でつなぐ用途であれば、10Gbps 有線対応の Buffalo VR-U500X のような VPN ルーターで IPsec / L2TP over IPsec を組み、必要に応じて別売の UTM 拡張ライセンスパック ( VR-UTM シリーズ ) を組み合わせる構成があります。UTM 側では、Web フィルタリング、マルウェア防止、不正アクセスのブロックといった入口対策を扱えます。
この構成のポイントは、認証・VPN・簡易 UTM を 1 台に寄せられることです。RADIUS サーバーを別に立てて連携させる場合と比較して、構築・運用の負担は軽くなります。
一方で、次のような場合には、この構成では対応しきれなくなります。
対地数が VR-U500X の IPsec 30 対地を超えてくる
利用者数や端末数が増え、権限を細かく分ける必要が出てくる
認証ログを長期に保存し、監査対応の要求が高まる
「立てない」から始めて、規模が拡大したら RADIUS の検討に進むという段階的な進め方も、一つの現実解です。
RADIUS サーバーは、立てたあとの運用設計を誤ると管理負荷がむしろ増える、という側面があります。少人数の情シス部門では、次のあたりを事前に決めておきたいところです。
利用者の追加・削除、権限変更を、誰がどのタイミングで行うか
ゲスト利用の期限管理を、申請ベースにするか、期限つきアカウントで自動失効にするか
認証失敗が起きたとき、パスワード誤り / 証明書期限切れ / RADIUS クライアント設定のどれから疑うか
こうした運用ルールは、遠隔管理サービスを使ってもツール側では決まりません。たとえば、Buffalo が提供する「キキNavi」のようなリモート管理サービスを併用すれば、機器の死活監視や設定情報の保存、遠隔操作は扱いやすくなります。ただし、誰がゲスト申請を承認するか、退職時に何日以内にアカウントを止めるかといった運用ルールそのものは、ツールでは代替されません。この見極めが甘いと、便利な仕組みを入れたはずが問い合わせ対応で担当者が張り付く、ということが起こります。
RADIUS サーバーは認証の入口を集約する仕組みですが、これ単体で情報セキュリティー全体をカバーできるわけではありません。役割で分けると次のようになります。
認証基盤 ( RADIUS など )：誰が入るかの統制
入口対策 ( ファイアウォール、UTM )：何が入るかの統制
内部対策 ( ネットワーク分離、セグメンテーション )：入ってしまった後、どこまで広がるかの統制
中小企業向けにこの 3 層をパッケージ化した例として、横河レンタ・リース株式会社では、ネットワーク診断 + Buffalo ファイアウォール + SubGate による「SMBセキュリティー安心パック」を提供しています。SubGate は社内ネットワークの見える化と、感染端末のネットワークからの遮断を担う位置づけです。
ここで伝えたいのは商品そのものというより、「認証だけ整えても、外部攻撃と内部感染は別レイヤーで手当てが要る」という構造です。
RADIUS を立てるかどうかに関わらず、この 3 層のどこが手薄になっているかを一度棚卸ししておくと、認証基盤への投資の優先度も判断しやすくなります。過度な期待も禁物で、単一の仕組みで完結する話ではない、という前提を持っておくことが大切です。
RADIUS サーバー構築は、社内 Wi-Fi、VPN、ネットワーク機器の認証を一元的に扱うための有効な選択肢の一つです。ただし、価値が出るかどうかは、サーバーを立てる作業ではなく、その前後の整理で決まります。
判断は大きく次の 3 択に集約できます。
本格的に RADIUS サーバーを構築する：拠点・利用者が多く、権限を細かく分ける必要がある場合
VPN ルーター側で認証を完結させる：SOHO や小規模拠点で、対地数と利用者が限られる場合
認証にとどまらず、入口・内部対策も含めてパッケージ的に整理する：情シス人員が限られ、まず全体の底上げを優先したい場合
どの選択でも、次の観点を一度紙に書き出すだけで、次の一歩は見えやすくなります。
どの入口を段階的に対象化するか
既存機器を活かせるか
停止時の影響をどう想定するか
立てたあとの運用を誰が回すか
認証以外の層 ( 入口・内部 ) は誰が見るか
A. 端末数が少なく、利用者もほぼ固定であれば、無理に構築する必要はありません。VR-U500X のような IPsec VPN 対応ルーター側で拠点間接続を組み、必要に応じて UTM ライセンスを加える構成で、認証まで完結できるケースがあります。判断の分かれ目は、規模よりも「入れ替わりの頻度」と「拠点数の拡大見込み」に近いと考えられます。
A. Active Directory は主に社員アカウントの管理、RADIUS はネットワーク機器側での認証の入口という役割の違いがあります。両者を連携させ、AD の情報を RADIUS 経由で Wi-Fi や VPN の認証に使う、という構成が一般的な検討候補になります。「片方があれば片方が要らない」というより、役割分担の設計として捉える方が実態に近いです。
A. RADIUS が担うのは「誰が入るかの統制」で、外部攻撃の遮断や、感染端末の内部拡散抑止までは範囲外です。ファイアウォール / UTM による入口対策、セグメンテーションによる内部対策と組み合わせて、はじめて全体像として機能します。認証だけを厚くしても、他の層が薄いままだと守れない領域が残ります。
A. 認証失敗時の切り分けです。パスワード誤り、証明書の期限切れ、RADIUS クライアント側の設定、サーバー側の設定、経路上の通信遮断など、原因の候補が複数にまたがるため、切り分け手順を先に整理しておかないと、問い合わせのたびに調査時間が伸びます。手順書化と、切り分けに使うログの保存設計を、構築とあわせて進めることをおすすめします。
RADIUS サーバー構築は、認証の入口を一つに寄せることで、退職・異動時の棚卸しや、接続ログの追跡を扱いやすくするための選択肢です。ただし、規模によっては VPN ルーター側で完結させる方が現実的な場合もあり、また認証だけでは外部攻撃や内部感染までは守れません。「立てる／立てない」「どの層とどう組み合わせるか」の整理が、構築作業そのものより先に来るとお考えください。
横河レンタ・リース株式会社では、ネットワーク認証基盤の設計・構築、VPN ルーターを含む機器選定、入口・内部対策のパッケージ提供まで、お客さまの環境に合わせた形でご相談を承っています。RADIUS サーバー構築や、既存認証環境の見直しを検討されている場合は、お気軽にお問い合わせください。