LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

社内Wi-Fiのパスワードを全員で使い回していて、退職者が出るたびに変えるべきか迷う。VPNのアカウントと社内のアカウントが別々で、管理が二重になっている——。拠点や在宅勤務が増えた会社では、こうした悩みが起こりがちです。FreeRADIUS（フリーラディウス）は、Wi-FiやVPNにつなぐ人や端末を1か所で確かめるための、無料で使えるオープンソースの認証サーバーです。

アクセスポイントやVPN装置ごとにばらばらだった認証をまとめられ、電子証明書を使った認証にも対応しています。ただし万能ではなく、証明書の更新まで含めた運用を決めておかないと止まりやすい仕組みでもあります。本記事では、社内ネットワークを任された情報システムの担当者に向けて、FreeRADIUSの役割、共有パスワード方式との違い、証明書認証の仕組みと運用、そして外部に頼むときに確認したい点を整理します。

FreeRADIUSとは

RADIUS（ラディウス）は、ネットワークにつなごうとする人を確かめる「認証」、何を許すかを決める「認可」、利用の記録を残す「アカウンティング」のための通信の決まりです。規格はRFC 2865で、アクセスポイントやVPN装置がRADIUSの「クライアント」として利用者の情報を認証サーバーに渡し、返ってきた答えに従って接続を許すか断るかを決めます。^*5 FreeRADIUSは、この認証サーバーを受け持つソフトウェアです。

• 1999年6月に始まったプロジェクトで、ソースコードはGNU GPLv2（利用や再配布の条件を定めたライセンス）で公開されています^*3
• Wi-Fiの802.1X（つなぐ前に利用者を確かめる仕組み）やVPNなどの認証に使えます^*4
• 利用者の情報は、Active DirectoryやOpenLDAP、MySQLなどに置いたものを参照できます
• 保守を担うInkBridge Networksが、有償のサポートを提供しています

公式のREADMEは、認証を1か所にまとめると、利用者の追加や削除のたびに変える箇所を減らせると説明しています。装置ごとにアカウントを持たせている会社ほど効き目があります。

共有パスワード方式との違い

総務省の説明では、WPA2パーソナルなどの一般向けの方式は全員で共通のパスワードを使い、WPA2エンタープライズなどの企業向けの方式は利用者ごとにIDを設定して、利用者側とアクセスポイント側で相互に認証します。企業向けの方式では暗号鍵も1人ずつ別になり、偽のアクセスポイントへ接続してしまう心配もありません。^*1 この方式で、裏側の認証を受け持つのがRADIUSサーバーです。

共有パスワードは手軽ですが、知っている人なら誰でもつなげます。総務省の手引きは、暗号化キーが知られると、同じ名前とキーの偽のWi-Fiを置いて通信を盗むことも可能になると注意しています。^*2 退職者やなくした端末を1人・1台ずつ止められることが、RADIUSを使う方式のいちばんの違いです。

証明書認証（EAP-TLS）の仕組み

EAP-TLSは、EAP（いろいろな認証方式を載せられる共通の枠組み）の上で、Webの暗号化通信にも使われるTLSを使って認証する方式で、RFC 5216に定められています。^*6 端末とサーバーがそれぞれの電子証明書を見せ合い、互いに相手を確かめる「相互認証」が特徴です。社員がWi-Fiにつなぐときの流れは、次の4つの段階に分けると分かりやすくなります。

• ステップ1：社員の端末が、アクセスポイントやVPN装置に接続を求める
• ステップ2：アクセスポイントが、端末の情報をFreeRADIUSに渡す。両者の間は、事前に決めた共有の秘密の値で確かめ合う^*5
• ステップ3：FreeRADIUSと端末が証明書を見せ合い、失効していないかも確かめる
• ステップ4：FreeRADIUSが許可か拒否を返し、アクセスポイントがそれに従って接続を通すか断る

社員がパスワードを打ち込む場面はなくなる代わりに、証明書をどの端末に入れ、いつ入れ替えるかの準備が要ります。2022年には、TLS 1.3でEAP-TLSを使う方法もRFC 9190として定められました。^*6

証明書の運用で決めておくこと

EAP-TLSは入れたら終わりではありません。RFC 5216は、証明書は長く使われる身元の証明なので、失効したかどうかを確かめられることが大切だとしています。^*6 証明書を発行する認証局（証明書の発行元）を社内に置くか、外部のサービスを使うかも含めて、次の点を導入の前に決めておきます。

• 発行と配布：どの端末に、誰が、どの手順で証明書を入れるか
• 有効期限と更新：期限が切れる前に、誰がいつ入れ替えるか
• 失効：退職や紛失のときに証明書を無効にし、失効の一覧（CRL）を認証サーバーが確かめられるようにする
• サーバーの確認：端末の側でも、正しい認証サーバーかどうかを確かめる設定にする
• 設定の変更：標準の設定から始め、少しずつ変えては試し、動いた設定を変更の理由と一緒に残す（公式のREADMEが勧める進め方）

アカウントの棚卸しも欠かせません。総務省は、長く使われていないアカウントや削除すべきアカウントを定期的に確かめ、不要なものを無効化・削除するよう勧めています。^*7 証明書も同じで、配った端末の一覧と有効な証明書の一覧を突き合わせる場を決めておくと、止め忘れを防げます。

外部に頼むときに確認しておきたい点

FreeRADIUSはライセンス費用がかからない一方、公式のREADMEも設定や管理が難しい場合があると認めています。サーバーと証明書を扱える担当者がいて拠点や機器が少なければ、自社で入れる選択も取れます。拠点が多い、Active Directoryと連携させたい、証明書の配布まで一度に整えたい場合は、外部に頼む前提で次の点を確かめておきます。

• どこまで頼むか：FreeRADIUSの構築、Active Directoryとの連携、認証局と証明書の配布、アクセスポイントやVPN装置の設定のうち、どれを任せるか
• 止まったときの備え：認証サーバーが止まるとWi-FiやVPNにつなげなくなるため、2台で組むか、障害時に誰が対応するか
• 切り替えの手順：共有パスワードから移るとき、部署ごとに移すか一度に移すか、元に戻す手順を用意するか
• 検証の方法：本番の前に、退職者のアカウントや失効させた証明書の端末がつながらないことまで試すか
• 運用後の見直し：証明書の更新や棚卸しを誰が受け持ち、その結果をどう見直すか

社内のWebアプリへのログインをまとめたい場合はKeycloakでSSO認証基盤を外注構築を、社内アカウントの台帳から整えたい場合はSamba ADとはの記事を参考にしてください。

まとめ：FreeRADIUSで確かめておきたい3つの点

FreeRADIUSで社内ネットワークの認証をまとめるうえで、確かめておきたい点は3つに整理できます。第一に、どの認証方式で、誰と何をつなぐかを決めること。第二に、証明書を使うなら、発行・更新・失効を誰が受け持つかを導入の前に決めること。第三に、認証サーバーが止まったときの備えと、退職者の端末を止められるかの確認を本番前に済ませることです。この3点を踏まえておけば、「入れてはみたが、証明書の期限切れで朝から誰もつなげない」という事態を避けやすくなります。構築や移行の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：総務省「国民のためのサイバーセキュリティサイト」職場での対策（無線LANの利用）（https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/staff/03/）。出典：コラム「企業向けのWi-Fiセキュリティ方式」（パーソナル方式とエンタープライズ方式の違い、相互認証、個別の暗号鍵、偽のアクセスポイント）の記述を参照（2026年11月確認）
2. *2　参考：総務省「公衆Wi-Fi提供者向け セキュリティ対策の手引き（令和7年2月版）」（https://www.soumu.go.jp/main_content/000990289.pdf）。出典：コラム「暗号化キー公開のリスク」（WPA2パーソナル方式で暗号化キーが知られた場合の偽Wi-Fiの危険）の記述を参照（2026年11月確認）
3. *3　参考：FreeRADIUS Project 公式サイト（トップページ・About Us・Releases）（https://www.freeradius.org/about/）。出典：RADIUSとAAAの説明、802.1XでRADIUSが認証の裏側を担うこと、1999年6月のプロジェクト開始、GPLv2、InkBridge Networksによる保守とサポートの記述を参照（2026年11月確認）
4. *4　参考：FreeRADIUS/freeradius-server（GitHub）README・COPYRIGHT（https://github.com/FreeRADIUS/freeradius-server）。出典：認証の一元化の利点、802.1X・VPNなどへの対応、Active Directory・OpenLDAP・MySQLなどの連携先、設定の難しさと推奨する設定の進め方、ライセンス（GNU GPLv2）を参照（2026年11月確認）
5. *5　参考：IETF RFC 2865「Remote Authentication Dial In User Service (RADIUS)」（https://www.rfc-editor.org/rfc/rfc2865.html）。出典：クライアントとサーバーの役割（NASがRADIUSのクライアント）、共有の秘密の値による確認、Access-Accept・Access-Rejectの応答を参照（2026年11月確認）
6. *6　参考：IETF RFC 5216「The EAP-TLS Authentication Protocol」／RFC 9190「EAP-TLS 1.3」（https://www.rfc-editor.org/rfc/rfc5216.html）。出典：EAP-TLSの証明書による相互認証、5.4節の証明書の失効確認（CRL・OCSP）、TLS 1.3でEAP-TLSを使う方法（RFC 9190、2022年2月）を参照（2026年11月確認）
7. *7　参考：総務省「国民のためのサイバーセキュリティサイト」アカウント管理（https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/admin/10/）。出典：アカウントの棚卸（不要なアカウントの無効化・削除）の記述を参照（2026年11月確認）

Tweet