テレワークが日常となった今、企業のネットワーク境界線は曖昧になりました。かつては社内LANという「城壁」の中にいれば安全でしたが、現在は外部からVPN(Virtual Private Network)を経由してシステムへアクセスすることが当たり前です。
ここで問われるのが、「その接続は本当に正規の利用者か?」という認証の強度です。単なるIDとパスワードだけでは、現代のサイバー攻撃を防ぐことは困難です。
今回は、高度なセキュリティ試験でも頻出であり、実務においても最強クラスの強度を誇る認証プロトコル「EAP-TLS」を中心に、VPN接続における認証の仕組みを徹底的に解剖します。証明書を用いた相互認証の仕組みを理解することは、セキュリティエンジニアとしての基礎体力を飛躍的に向上させます。
1. VPNセキュリティの要衝:なぜ「認証」が重要なのか
VPNは、インターネットという公衆網の中に、暗号技術を用いて仮想的な専用線を構築する技術です。通信内容はIPsecやSSL/TLSによって暗号化され、盗聴から守られています。
しかし、どれほど通信経路が強固でも、「誰を通すか」を決める認証(Authentication)の入り口が脆弱であれば、攻撃者は正面玄関から堂々と侵入してきます。
従来型認証(ID+パスワード)の限界
かつて主流だったPAPやCHAPといった単純なID・パスワード認証は、現在では推奨されません。
- パスワードの使い回し:ユーザーのリテラシーに依存し、リスト型攻撃の餌食になりやすい
- 総当たり攻撃:単純なパスワードはブルートフォース攻撃で容易に突破される
- 端末の特定が困難:IDとパスワードさえ合っていれば、個人の私物PCやマルウェアに感染した端末からの接続も許可してしまう

パスワード認証の脆弱性は、統計データからも明らかです。2023年のサイバーセキュリティレポートによれば、企業への不正アクセスの約70%が認証情報の漏洩や推測によるものとされています。パスワードスプレー攻撃では、よく使われる簡単なパスワード(「Password123」「Company2024」など)を大量のアカウントに試すことで、どこかで必ず突破口を見つけることができてしまいます。
さらに深刻なのは、パスワード認証では「誰の端末からアクセスしているか」を識別できない点です。正規の社員のIDとパスワードが漏洩すれば、攻撃者は自宅のPCから、あるいはマルウェアに感染した危険な端末から、堂々と企業ネットワークに侵入できてしまいます。
認証強化の切り札:IEEE 802.1XとEAP
現代のネットワーク認証において標準的に利用されるのが、IEEE 802.1Xという規格です。この規格は、有線・無線を問わずネットワークへのアクセス制御を統一的に実現するために策定されました。
このIEEE 802.1Xで利用される認証プロトコルの枠組み(フレームワーク)がEAP(Extensible Authentication Protocol)です。EAP自体は認証の手順を定めた「コンテナ」のようなもので、その中に実際の認証方式(TLS、PEAPなど)を格納して運びます。
IEEE 802.1Xの強力な点は、認証に成功するまでネットワークへのアクセスを物理的にブロックできることです。認証が完了するまで、クライアントは認証サーバーとの通信以外は一切許可されません。これにより、未認証の端末が社内ネットワークに侵入する余地を完全に排除できます。
2. 最強の認証方式「EAP-TLS」の仕組みを解剖する
試験対策において、最も重要度が高いのがこのEAP-TLS(EAP-Transport Layer Security)です。電子証明書を用いることで、現在普及している認証方式の中で最も高いセキュリティ強度を誇ります。
EAP-TLSの最大の特徴:相互認証
EAP-TLSの核心は、クライアント(利用者)とサーバー(認証サーバー)が、互いにデジタル証明書を提示し合って相手を検証する「相互認証」を行う点にあります。
- サーバー認証:クライアントは、接続先のサーバーが「偽のサーバー(偽基地局や偽VPN装置)」でないことを確認します
- クライアント認証:サーバーは、接続してきたクライアントが「許可された端末(証明書を持つ端末)」であることを確認します
これにより、なりすましサーバーへの誤接続(中間者攻撃の防止)と、不正な端末からのアクセス(未許可端末の排除)を同時に防ぐことができます。

相互認証の重要性は、実際のインシデント事例から学ぶことができます。2019年に発覚したある企業への攻撃では、攻撃者が偽のVPNサーバーを構築し、社員を誘導してログイン情報を窃取していました。もしEAP-TLSによるサーバー認証が実装されていれば、クライアント側で「このサーバーは信頼できるCAの証明書を持っていない」と判断され、接続を拒否できたはずです。
試験で問われる!EAP-TLSの認証フロー詳細
記述式問題(午後試験)では、このフローの理解を問われることがあります。

- EAP開始:VPNクライアント(サプリカント)が接続要求を出します
- Identity要求:認証サーバー(RADIUSサーバー)がIDの提示を求めます
- TLSハンドシェイク開始:ここからEAPのパケットの中でTLSのやり取りが始まります
- サーバー証明書の送付:サーバーは自身の「サーバー証明書」をクライアントに送ります
- サーバーの検証:クライアントは、あらかじめ信頼するルート認証局(CA)の証明書を使って、送られてきたサーバー証明書を検証します
- クライアント証明書の送付(重要!):クライアントは自身の「クライアント証明書」をサーバーに送ります
- クライアントの検証:サーバーは、信頼するCAの証明書を使って、クライアント証明書を検証します。また、証明書失効リスト(CRL)やOCSPを参照し、証明書が無効化されていないかも確認します
- 暗号化通信路の確立:双方が正規の相手であると確認できたら、セッション鍵を生成し、以降の通信を暗号化します
- 認証成功:RADIUSサーバーがVPN装置(オーセンティケータ)に対して「Access-Accept(許可)」を通知し、VPN接続が確立されます
このフロー全体を通して、パスワードは一度も送信されません。認証の鍵となるのは、クライアントが持つ秘密鍵と証明書のペアです。証明書は公開情報ですが、対応する秘密鍵は端末内に厳重に保管され、外部に送信されることはありません。認証時には、クライアントがこの秘密鍵を使って電子署名を生成し、「私は確かにこの証明書の正当な所有者です」と証明します。
EAP-TLSのメリットとデメリット
| 項目 | 特徴 |
|---|---|
| セキュリティ強度 | 極めて高い。証明書がないと接続できないため、パスワード漏洩の影響を受けない |
| 端末制御 | 可能。会社が支給し証明書をインストールした端末のみ接続を許可できる(私物端末排除) |
| 運用コスト | 高い。全クライアント端末に証明書を配布・インストールし、更新管理をする必要がある |
| ユーザー利便性 | 高い。証明書があれば接続時に複雑なパスワード入力を求めずに済む |
運用コストの具体例を挙げると、1000台の端末を管理する企業の場合、証明書の有効期限は通常1〜3年です。期限切れの前に全端末の証明書を更新する作業が発生します。手動で行えば膨大な工数がかかるため、MDMツールやActive Directoryの自動更新機能を活用した仕組み作りが不可欠です。
3. 現場で選ばれるその他のEAP方式:PEAPとEAP-TTLS
すべての環境で全員に証明書を配ることは、運用管理上(特に数千人規模の企業では)困難な場合があります。そこで、セキュリティと運用負荷のバランスをとった方式もよく利用されます。これらも試験で比較対象として頻出です。
PEAP(Protected EAP)
PEAPは、サーバー側のみ証明書を持ち、クライアント側はIDとパスワードで認証する方式です。
- まずサーバー証明書を使ってTLSトンネル(暗号化された土管)を作ります
- その安全なトンネルの中で、従来型のID・パスワード認証(MS-CHAPv2など)を行います
- メリット:クライアント証明書の配布が不要なため、導入が容易
- デメリット:クライアント認証はパスワードベースになるため、EAP-TLSに比べると強度は落ちる(端末の特定が厳密にはできない)
PEAPの大きな利点は、既存のActive Directoryなどのユーザーデータベースをそのまま活用できる点です。多くの企業では、すでにADでユーザー管理をしているため、新たにPKI(公開鍵基盤)を構築する必要がなく、導入のハードルが大幅に下がります。
ただし、PEAPにも弱点があります。TLSトンネル内とはいえ、パスワードベースの認証が行われるため、フィッシング攻撃には弱いという特性があります。攻撃者が偽のログインページを作成し、ユーザーを騙してIDとパスワードを入力させることができれば、そのまま不正アクセスが可能になってしまいます。
EAP-TTLS(EAP-Tunneled TLS)
PEAPと構造は似ています。サーバー認証を行ってトンネルを作り、その中で別の認証プロトコルを流します。PEAPがMicrosoft主導で普及したのに対し、EAP-TTLSはより汎用的な設計になっています。
EAP-TTLSの特徴は、トンネル内で使用できる認証方式の柔軟性です。PAP、CHAP、MS-CHAPv2だけでなく、様々なレガシー認証方式に対応できます。これにより、古いシステムとの互換性を保ちながら、通信路自体は暗号化によって保護することが可能です。

実務においては、セキュリティ要件と運用コストのバランスを考慮して認証方式を選択します。機密性の高い情報を扱う部署(経営企画、法務、研究開発など)にはEAP-TLS、一般的な業務部門にはPEAPといった形で、部門ごとに異なる認証方式を適用する「ハイブリッド運用」を採用する企業も増えています。
4. ネットワーク構成要素:RADIUSとAAAモデル
VPN認証を語る上で外せないのが、RADIUS(Remote Authentication Dial In User Service)プロトコルと、それを処理する認証サーバーです。
AAAモデル
セキュリティ管理の基本概念であるAAAを実現します。
- Authentication(認証):正規のユーザーか?(EAP-TLSなどで確認)
- Authorization(認可):どのリソースへのアクセスを許すか?(VLANの割り当て、フィルタリングルールの適用)
- Accounting(アカウンティング):誰がいつ、どれくらい利用したか?(ログの記録)
このAAAモデルは、セキュリティの基本原則を体系化したものです。認証だけでは不十分で、認証後に「何を許可するか」を制御し、さらに「誰が何をしたか」を記録することで、セキュリティインシデント発生時の追跡調査が可能になります。
認可(Authorization)の実例として、営業部門のユーザーがVPN接続に成功した場合、営業システムへのアクセスのみを許可し、人事システムや財務システムへのアクセスは自動的にブロックするといった制御が可能です。RADIUSサーバーは認証成功時に「このユーザーは営業VLANに割り当てる」という指示をVPN装置に送り、ネットワークレベルでアクセス制御を実現します。
アカウンティング(Accounting)では、接続開始時刻、切断時刻、送受信データ量、接続元IPアドレスなどが記録されます。これらのログは、不正アクセスの痕跡を追跡するだけでなく、コンプライアンス監査や内部統制の証跡としても重要な役割を果たします。
構成図の読み解き方(試験対策)
試験問題のネットワーク構成図では、以下のような役割分担が登場します。この用語のマッピングを瞬時に行えるようにしましょう。
- サプリカント(Supplicant):VPNクライアントソフトがインストールされたPCやスマホ。「認証をお願いする」立場
- オーセンティケータ(Authenticator):VPNゲートウェイや無線LANコントローラ。サプリカントと認証サーバーの仲介役。EAPパケットをRADIUSパケットに詰め替えて転送します
- 認証サーバー(Authentication Server):RADIUSサーバー。実際に判定を下す「裁判官」。バックエンドにActive Directory(AD)やPKI(認証局)と連携していることが多いです

試験問題では、これら3つの要素間でやり取りされるパケットの種類とタイミングを問われることがあります。サプリカントとオーセンティケータ間ではEAPパケットが、オーセンティケータと認証サーバー間ではRADIUSパケットが使用されます。オーセンティケータは、EAPパケットをRADIUSのAttributeとして包んで転送する「通訳」の役割を果たします。
RADIUSプロトコルでは、UDPポート1812(認証)と1813(アカウンティング)が使用されます。これらのポート番号は試験頻出事項です。また、RADIUSパケットは共有秘密鍵(Shared Secret)によってメッセージ認証が行われ、改ざんを検知できる仕組みになっています。
5. 実務視点の運用課題:証明書のライフサイクル管理
EAP-TLSを採用する場合、技術的な設定以上に「運用設計」が重要になります。試験でも、この運用面の穴を突く問題が出題されます。
証明書の配布(プロビジョニング)
数千台のPCにどうやってクライアント証明書を配るかが課題です。
- キッティング時にIT部門が手動でインストールする
- MDM(モバイルデバイス管理)ツールを使って、無線経由で強制的にプッシュ配信する
- Active Directoryのグループポリシー(GPO)を使って自動配布する
大規模組織では、証明書配布の自動化が必須です。マイクロソフト環境であれば、Active Directory Certificate Services(AD CS)と連携し、ドメイン参加時に自動的にクライアント証明書を発行・インストールする仕組みを構築できます。ユーザーは何も意識することなく、PCの電源を入れてドメインにログインするだけで、バックグラウンドで証明書が配布されます。
BYOD(私物端末の業務利用)環境では、MDMツールが重要な役割を果たします。従業員が自分のスマートフォンやタブレットを業務利用する際、MDMに登録することで自動的に証明書がプッシュされ、VPN接続が可能になります。同時に、端末が盗難にあった場合や退職時には、MDMから遠隔で証明書を削除することも可能です。
証明書の失効(Revocation)
社員が退職したり、PCを紛失したりした場合、直ちにその端末の証明書を無効化しなければなりません。
- CRL(証明書失効リスト):無効化された証明書のシリアル番号リスト。認証サーバーは定期的にCAからこれをダウンロードして参照します。タイムラグが発生する可能性があります
- OCSP(Online Certificate Status Protocol):リアルタイムでCAに問い合わせるプロトコル。即時性が高いですが、CAへのアクセス負荷が高まります
CRLには更新間隔という概念があります。通常、CRLは24時間ごとに更新されるため、最悪の場合、証明書を失効させてから実際にアクセスがブロックされるまで24時間のタイムラグが生じます。この間に不正アクセスされるリスクがあるため、即時性が求められる場合はOCSPの利用が推奨されます。
OCSPでは、認証のたびにリアルタイムでCAに問い合わせるため、失効直後から即座にアクセスをブロックできます。ただし、数千の端末が同時にVPN接続する朝の時間帯などは、OCSPサーバーへの負荷が集中し、レスポンスが遅延する可能性があります。この問題を解決するため、OCSP Staplingという技術も登場しています。
試験のポイント
「PCを紛失したが、VPNパスワードを変更したから大丈夫」というのは間違いです。EAP-TLSで「パスワード認証を併用していない」場合、証明書が入ったPCを拾った第三者がそのままVPN接続できてしまうリスクがあります(PINコード設定がない場合)。したがって、「紛失時は速やかに証明書を失効させる」という運用フローが正解になります。
証明書の秘密鍵にPINコードや生体認証を組み合わせる多要素認証も有効な対策です。Windows環境では、TPM(Trusted Platform Module)チップに秘密鍵を格納し、PINコード入力なしには使用できないように設定できます。これにより、PC本体を紛失しても、攻撃者が秘密鍵を使用することは極めて困難になります。
6. 上級編:TLSハンドシェイクの深層とトラブルシューティング
ここからは、午後試験IIレベルの知識です。パケットキャプチャ問題が出た際に役立ちます。
EAP-TLSにおけるハンドシェイクのキモ
通常のHTTPS通信と異なり、EAP-TLSでは「CertificateRequest」というフェーズが重要です。
- ClientHello:暗号スイートの提案
- ServerHello:暗号スイートの決定
- CertificateRequest:サーバーがクライアントに対し「君の証明書も見せてくれ」と要求します。この時、サーバーは「私が信頼している認証局(CA)のリスト」を提示します
- Certificate (Client):クライアントは、提示されたリストに合致する自分の証明書を送ります
- CertificateVerify:クライアントは自身の秘密鍵で署名データを送り、証明書の正当な持ち主であることを証明します
CertificateVerifyメッセージは、EAP-TLSの心臓部です。ここでクライアントは、これまでのハンドシェイクメッセージ全体のハッシュ値を計算し、自分の秘密鍵で署名します。サーバーは、クライアント証明書に含まれる公開鍵を使ってこの署名を検証することで、「このクライアントは確かに証明書に対応する秘密鍵を持っている」ことを確認します。
暗号スイートの選択も重要なポイントです。現代の推奨設定では、TLS 1.2以降を使用し、AES-GCMなどのAEAD(認証付き暗号)をサポートする暗号スイートを優先します。古いRC4やDESは脆弱性が発見されているため、明示的に無効化すべきです。
なぜ繋がらない?代表的なトラブル
- 時刻同期のズレ:証明書には有効期間があります。PCやサーバーの時刻がずれていると「期限切れ」と判定され、認証に失敗します。NTPの設定は必須です
- 中間CA証明書の欠如:サーバー証明書を更新した際、新しい中間CA証明書を入れ忘れると、クライアント側で検証エラーになります
- フラグメンテーション:証明書を含んだパケットはサイズが大きいため、ネットワーク経路上で分割(フラグメント)されることがあります。一部の機器がこれを正しく処理できず、タイムアウトすることがあります(Framed-MTUの調整で解決)
時刻同期の問題は意外と頻発します。仮想マシン環境では、ホストとゲストの時刻がずれることがあり、証明書の有効期限チェックでエラーになります。また、海外拠点のPCが日本のVPNサーバーに接続する際、タイムゾーンの設定ミスで時刻が大きくずれていると、証明書が「まだ有効期間開始前」あるいは「すでに期限切れ」と判断されてしまいます。
中間CA証明書の問題は、証明書更新時に頻発します。多くのCAは階層構造を持っており、ルートCA→中間CA→エンドエンティティ証明書という3階層になっています。サーバーは、自身のエンドエンティティ証明書だけでなく、中間CA証明書も一緒にクライアントに送信する必要があります。これを忘れると、クライアントは証明書チェーンを完成できず、「信頼できないサーバー」と判断してしまいます。
フラグメンテーション問題は、特に無線LAN環境で顕著です。証明書を含んだパケットは2KB以上になることもあり、MTU(Maximum Transmission Unit)の制約で分割されます。しかし、一部の古いファイアウォールやNAT装置は、フラグメントされたEAPパケットを正しく再構成できず、パケットを破棄してしまいます。この場合、RADIUS属性のFramed-MTU値を小さく設定し、最初からパケットサイズを制限することで問題を回避できます。
証明書チェーンの検証エラーも頻出トラブルです。クライアント側に正しいルートCA証明書がインストールされていない場合、サーバー証明書の検証が失敗します。WindowsやmacOSには信頼されたルートCA証明書があらかじめインストールされていますが、企業独自のプライベートCAを使用している場合は、手動でルートCA証明書をクライアントに配布する必要があります。
もう一つの典型的な問題は、ホスト名の不一致です。サーバー証明書に記載されているCN(Common Name)やSAN(Subject Alternative Name)と、クライアントが実際に接続しようとしているホスト名が一致しない場合、証明書検証エラーになります。例えば、証明書のCNが「vpn.example.com」なのに、クライアントが「192.168.1.1」というIPアドレスで接続しようとすると、検証が失敗します。
【演習問題】RADIUSとTACACS+の違いを攻略!ネットワーク認証プロトコル理解度チェック
記事で解説したネットワーク認証の基盤「AAAモデル」や、RADIUSとTACACS+の技術的な違い(ポート番号、暗号化範囲、認証・認可の仕組みなど)について、理解度を確認できる全10問のクイズを作成しました。
情報処理安全確保支援士やネットワークスペシャリスト試験の対策としてはもちろん、現場での設計判断に役立つ基礎知識の定着にお役立てください。選択肢をクリックすると、その場で正誤と詳しい解説が表示されます。
まとめ:ネットワークの信頼は認証から始まる
VPNにおける認証、特にEAP-TLSは、暗号技術、PKI、ネットワークプロトコル知識が複合的に求められる分野です。だからこそ、試験では受験者の総合力を測るのにうってつけのテーマとして頻出します。
重要ポイントの振り返り
- EAP-TLSは、相互認証により最強の強度を誇るが、証明書管理の手間がかかる
- PEAPは、導入が楽だが、クライアント認証はパスワードベースになる
- セキュリティの肝は、証明書の配布と失効の管理、そしてクライアント側でのサーバー検証設定にある
単に用語を暗記するのではなく、「PCから認証サーバーまで、パケットがどう流れ、どこで暗号化され、どの鍵で誰を検証しているのか」を脳内でシミュレーションできるようにしてください。
実務では、これらの技術を組み合わせた多層防御が基本です。EAP-TLSによる強固な認証に加えて、端末のマルウェア対策ソフトの導入状態をチェックする「ポスチャアセスメント」、接続後もユーザーの行動を監視する「振る舞い検知」など、複数のセキュリティ対策を組み合わせることで、真に堅牢な認証基盤が実現します。
さらに、ゼロトラストアーキテクチャの考え方では、VPN接続後も「信頼しない」という前提に立ちます。認証は入り口の通過に過ぎず、その後のすべてのアクセスに対して継続的な検証を行います。この考え方により、万が一認証を突破されたとしても、被害を最小限に抑えることが可能になります。
最後に、認証技術は日々進化しています。FIDO2やWebAuthnといった新しい認証規格、ハードウェアセキュリティキーの普及、AIを活用した異常検知など、次世代の認証技術も続々と登場しています。基本となるEAP-TLSの仕組みをしっかり理解した上で、これらの新技術にもアンテナを張り続けることが、セキュリティエンジニアとしての成長につながります。