はじめに

YAMAHA RTX シリーズでリモートアクセスVPNを組んでいる情シスの方なら、一度はこう思ったことがあるのではないでしょうか。

「RTX 自体には大満足なんだけど、このご時世に“IDとパスワードだけのVPN”はさすがに怖い…。」

ここ数年、ランサムウェア被害のニュースが途切れることはありません。VPN 装置が最初の突破口になったケースも多く報告され、

「VPN が一番弱いところになっていないか？」

を問い直すのは、RTXファンにとっても避けて通れないテーマになりました。

本記事は、

• すでに RTX でリモートアクセスVPNを運用している企業が、
• 「RTXはそのまま使い続けたい」という前提を守りながら、
• ランサムウェア対策や本社・親会社の通達、セキュリティ格付けへの備えにも対応できるように、
• 認証だけを“二要素認証”へアップデートする

ための入門ガイドです。

ヤマハ公式の仕組み（Lua／RADIUS）のおさらいから、クラウド認証サービス SingleID と組み合わせた構成まで、RTXファン目線で、読み物として分かりやすく整理していきます。

---

1. RTXユーザの現場で何が起きているのか

まずは、実際に RTX を使う企業で、どんなきっかけから話が始まっているのかを見てみます。

大きく分けると、相談は 2 つのパターンです。

1-1. パターン①：ランサムウェア報道で「VPNが一番怖いもの」になった

1つ目は、連日のランサムウェア報道がきっかけのパターンです。

情シスの方からよく聞くのは、こんな言葉です。

「RTX 自体には満足しているけれど、パスワードだけで社内ネットワークに入れる状態をこのまま続けるのは怖い。」

機器としての RTX には不満はない。ただ、インターネットと社内ネットワークの境目にあるのが「IDとパスワードだけの VPN」という状況は、もはや経営リスクと言ってよいレベルになってきています。

そこで最初に検討されるのが、

• 「RTX をやめて、UTM や SASE にリプレースする」

という案です。

一見すると、これが一番“きれいな”解に見えます。しかし、全国に拠点を持つ企業ほど、ここで現実に突き当たります。

• RTX はすでに標準機として全拠点に入っている
• 設計変更・機器更改・検証・ユーザへの案内…を全部やり直すのは、「今すぐ」やるにはあまりにも重い

結果として、こんな整理になります。

「RTX そのものは生かしたい。ただ、認証だけは早急に二要素にしたい。」

ここから、RTX は残したまま、認証だけを外付けで強化する方法探しが始まります。

1-2. パターン②：本社・親会社から「二要素認証必須」の通達

もう 1 つのパターンは、トップダウンで始まるケースです。

• 親会社やグループ本社から、
  • 「リモートアクセス VPN は二要素認証を必須とする」
  • 「サプライチェーン全体のセキュリティ水準をそろえる」
  といった通達が出る
• 経産省の「サプライチェーン強化に向けたセキュリティ対策評価制度」も意識し始めている（※6）

こうなると、各社の情シスは、

• どの構成なら「格付け」「監査」でちゃんと説明できるか
• 来年度の予算でどこまで踏み込むべきか

という目線で検討を進めます。

当然、ここでも RTX から UTM／SASE への全面リプレース案は議題に上がります。ただ、やはり同じ壁にぶつかります。

「今年度中に、全部リプレースまでやり切るのは現実的ではない。」

そこで、方針は次のように落ち着きます。

「RTX は当面そのまま使う。ただし、二要素認証と ID 管理はクラウド側に寄せる。」

この前提の上で、RTX＋SingleID の PoC を行い、

• 来年度の予算要求の材料
• セキュリティ格付けや監査の場での説明材料

として整理していく、という流れが増えています。

---

2. RTXが標準で持っている「二要素認証らしき」しくみ

RTXファンとしては、まず「RTX単体でできること」を押さえておきたいところです。

ヤマハの技術情報を見ていくと、二要素認証に“近い”構成として、主に 2 つが紹介されています。

2-1. Luaスクリプトで PPP パスワードを定期的に変える構成

1つ目は、Lua スクリプトと L2TP/IPsec を組み合わせた「ワンタイムパスワード」構成です。ヤマハ公式の設定例では、Lua スクリプトを用いて L2TP クライアント用 PPP 認証のパスワードを定期的に書き換える例が紹介されています（※1）。

ざっくり言うと、

• PPP ユーザのパスワードを Lua スクリプトで定期的に自動変更する
• 新しいパスワードをメールなどでユーザへ通知する
• ユーザは VPN クライアントの設定を、そのパスワードに入れ替えて使う

という仕組みです。

人手でパスワードをローテーションするよりもずっと安全で、RTX 単体で完結するという点は、大きな魅力です。

ただし、ここで 1 つ整理しておきたいポイントがあります。

• ログインのたびにパスワードが変わる「都度 OTP」ではない
• 一定期間有効な「共通パスワード」を、定期的に更新するイメージになる

そのため、認証要素としてはあくまで

「ID ＋ パスワード（＝知識要素だけ）」

です。

現場の情シスの方と話していると、よくこんな感想が返ってきます。

「パスワード運用としては確かにマシになる。でも、“二要素認証を入れました”とは言いづらいんですよね。」

パスワード運用改善としては優れた機能ですが、「MFA（多要素認証）」という言葉から多くの人がイメージする姿とは、少し差があります。

2-2. RADIUS＋OTPサーバで、正攻法のMFAを自前構築

2つ目は、RTX の PPP 認証を RADIUS に投げ、さらに OTP サーバと組み合わせる構成です。

ヤマハの技術情報（RTpro）では、L2TP/IPsec 接続の PPP 認証で PAP または CHAP を用いた RADIUS 認証が利用できることが明記されています（※2）。

この先に OTP サーバを組み合わせれば、

• ID
• パスワード
• ワンタイムパスワード（OTP）

の 3 要素を組み合わせた、教科書通りの二要素認証／多要素認証を実現できます。

技術的には、とてもまっとうなアプローチです。

一方で、運用の視点から見ると、次のような課題が見えてきます。

• RADIUS サーバと OTP サーバの構築・冗長化
• ユーザ・グループ管理の設計と運用
• OTP シークレットの配布・失効
• 認証ログと監査ログの保管・検索

PoC の範囲ではうまく動いても、

「5 年、10 年と担当者が変わっても安定運用する」

ところまで考えると、運用負荷と属人化リスクがかなり重くのしかかります。

RTXファンとしても、

「RTX は好きだけど、認証周りの全部を自前サーバで面倒見るのはしんどい」

という本音が出てくるポイントです。

---

3. 「ルータはそのまま、認証だけクラウドへ」──RTX＋SingleIDという落としどころ

ここからが、本記事のメインテーマです。

Lua や RADIUS/OTP だけではカバーしきれない部分をどうするか。そこで、実際の案件で選ばれているのが、

「RTX はルータ／VPN 装置としてそのまま活かし、認証だけをクラウドサービスの SingleID に任せる」

という構成です。

SingleID は、クラウド型の

• RADIUS（クラウドRADIUS）（※3）
• プライベート PKI（クライアント証明書）（※4）
• ID 管理／SSO（Entra ID 連携も含む統合認証基盤）（※3）（※7）

をまとめて提供するサービスで、RTX との接続検証も行っています。

「RTXファンが RTX を手放さずに、認証だけ令和仕様にする」ための強い味方、というイメージです。

3-1. 入門としての第一歩：「ID＋パスワード＋6桁コード」

最初の一歩として最も多いのが、

ユーザ ID ＋ パスワード ＋ 6 桁の TOTP コード

で RTX の VPN を守る構成です。

やっていることはシンプルです。

• RTX は、PPP 認証を SingleID のクラウド RADIUS に転送する
• SingleID 側で、
  • ID／パスワード
  • スマホアプリで生成される 6 桁コード（TOTP）
  の両方を検証する

この 6 桁コードは、ユーザのスマートフォンに保存されたシークレットをもとに、30 秒ごとに自動更新される数字です（TOTP の一般的仕様）。

• パスワード → 「知っているもの（知識要素）」
• スマホ＋TOTP → 「持っているもの（所持要素）」

という分かりやすい二要素認証になります。

ユーザ体験としても、

「ID とパスワードを入れて、スマホの認証アプリを見て 6 桁コードを打ち込む」

という、クラウドサービスの MFA と同じ感覚で使えます。

RTX側は「認証をクラウドに投げる」だけなので、ルータとしての設定や構成は最小限の変更で済むのもポイントです。

3-2. クライアント証明書は「ネットワーク認証」と「Entra ID CBA」に回す

SingleID は、クラウド型のプライベート PKI として、クライアント証明書も発行できます（※4）。

• Windows / macOS / モバイル端末向けクライアント証明書
• 有効期限管理・失効処理

などをクラウド側で一元管理できます。

一方で、YAMAHA RTX の L2TP/IPsec リモートアクセス VPN における PPP 認証は、ユーザ ID／パスワード（PAP/CHAP）を前提にした構成が公式ドキュメントで説明されています（※2）。

そのため、SingleID が発行するクライアント証明書は、主に次の用途で活かしていきます。

• 無線 LAN／有線 LAN のネットワーク認証（802.1X／EAP-TLS）
• Entra ID と連携した CBA（証明書ベース認証）による SaaS／社内アプリ認証（※5）

Microsoft Entra ID の CBA（Certificate-Based Authentication）は、X.509 証明書を用いてフィッシング耐性の高い認証を実現する公式機能で、アプリケーションやブラウザのサインインに利用できます（※5）。

イメージとしては、

• VPN の入口：RTX ＋ SingleID で ID＋パスワード＋TOTP
• 社内 LAN／SaaS の入口：SingleID のクライアント証明書 ＋ Entra ID CBA

という、二段構えの「入口ガード」を作っていくイメージです。

すでに Entra ID と Intune を使っている企業であれば、Intune の SCEP 証明書プロファイルを通じて、クライアント証明書をデバイスへ自動配布する構成も広く採用されています（※8）。

これにより、

• 証明書の発行
• 配布
• 失効

といったライフサイクルを、ほぼ自動化できます。

RTX 自体はこれまで通り「堅牢なルータ・VPN装置」として働き続け、認証・証明書周りだけをクラウドにオフロードするイメージです。

3-3. IDとログを「どこで」管理するか

SingleID は、独自のユーザ DB を持ちつつ、Entra ID とのユーザ／グループ同期にも対応しています（※3）（※7）。

どちらの方式を採るにしても、

• 「VPN 接続を許可するユーザ／グループ」を一元管理できる
• RTX 経由の認証ログを、SingleID 上でまとめて確認できる

という状態を作れます。

たとえば、

• 退職者は SingleID あるいは Entra ID 側でアカウントを無効化すれば、RTX 経由の VPN もすぐに止まる
• 「VPN 利用可能グループ」に所属しているユーザだけが、RTX に接続できる
• 不審なログインがあれば、SingleID の管理画面からログを追える

といった運用です。

オンプレミスに新しくサーバを立てることなく、ID ライフサイクル管理と認証ログの可視化までをクラウド側で完結できるのが、RTX＋SingleID 構成の大きな違いです（※3）（※9）。

3-4. 「小規模RTXユーザでも入りやすい」ユーザライセンス

もう 1 つ、RTXファンとして見逃せないポイントがライセンスの考え方です。

RTX は、中堅・大企業だけでなく、社員数 10〜数十名といった中小企業や、小規模拠点でも広く使われています。

こうした環境でありがちな悩みが、

「クラウドの認証サービスは、最小契約数が大きすぎて手が出しにくい」

というものです。

SingleID はユーザライセンスを前提としており、最小 10 ユーザから利用できる料金体系になっています（※3）（※9）。

つまり、

• 本社 30 名＋拠点 10 名といった規模でも導入しやすい
• まずは「VPN 利用者だけ 10 ユーザ」でスタートし、利用状況を見ながら段階的に拡張していく

といった “小さく始めて大きく育てる” 導入がしやすい設計です。

RTX が「中小企業〜大企業まで幅広いユーザ層」に使われているのと同じように、SingleID も少人数からスケールアップ可能なライセンスモデルを取っているため、

「RTX はこのまま使いたい。でも、利用者はまず 10〜20 人だけでいい」

というケースでも、現実的なコスト感で二要素認証を導入できます。

---

4. RTXファンが意識しておきたい「セキュリティ格付け」の目線

最後に、もう少し俯瞰した視点として、経産省の「サプライチェーン強化に向けたセキュリティ対策評価制度」や各種ガイドラインとの関係を見てみます（※6）。

今後、多くの企業で

• 特権アカウント
• リモートアクセス（VPN 等）

に対して、多要素認証が事実上の標準要件になっていくことは、国内外の議論の流れから見ても自然な方向性だと考えられます（※10）。

この観点で、ここまでの 3 つの構成をざっくり並べると、次のようになります。

• RTX ＋ Lua 方式
  パスワード運用の改善策としては有効。ただし、「MFA を導入した」と説明するには弱い。
• RTX ＋ 自前 RADIUS／OTP 方式
  技術的には正攻法の MFA。そのぶん、サーバ構築・運用・属人化リスクまで自社で負う。
• RTX ＋ SingleID 方式
  ID＋パスワード＋TOTP の分かりやすい二要素認証。Entra ID 連携やクライアント証明書による CBA まで見据えられる。認証ログと ID ライフサイクルがクラウド側で一元管理されるため、評価制度や監査の場で説明資料に落とし込みやすい。さらに、ユーザライセンス（最小10ユーザ）で小規模環境から段階的に導入できる。

特に、パターン②のように

「本社通達」と「セキュリティ格付けへの備え」

の両方を背負っている情シスにとっては、

• RTX を残した構成のまま、
• それでも「MFA」と「運用体制」をどう説明するか

が重要なテーマです。

RTX＋SingleID 構成で PoC を行い、その結果を構成図やログ画面のキャプチャとともに資料化することで、

• グループ本社への報告
• 取引先への説明
• 将来の格付けや監査への備え

を一歩前に進めている企業が増えています。

---

おわりに ── RTXファンだからこその「認証アップデート」

この記事でお伝えしたかったのは、

「RTX をやめるか／続けるか」という二択ではなく、「RTX を活かしたまま、どう強化するか」という選択肢がある

ということです。

実際の現場では、次のような前提を同時に満たさなければならないケースがほとんどです。

• RTX はすでに全拠点で標準機として定着している
• しかし、パスワードだけの VPN を続けるのは明らかにリスクが高い
• 短期での全面リプレースは、費用も工期も現実的ではない

この中で、

「RTX は残したまま、二要素認証と ID 管理だけを SingleID でクラウドに寄せる」

という構成は、

• ランサムウェア対策として “今すぐ下げられるリスク” を下げつつ、
• 来年度以降のネットワーク認証・SaaS 認証・ゼロトラスト化まで見据えられる

RTXファンらしい現実的な一手になりつつあります。

すでに RTX でリモートアクセス VPN を運用していて、

• 「とにかく早く、パスワードだけの状態を卒業したい」
• 「本社や取引先からの『二要素認証必須』に応えたい」
• 「できれば RTX は活かしたまま、最小限の変更で済ませたい」
• 「小規模ユーザ数から、ムリのないライセンスで始めたい」

という状況であれば、RTX ＋ SingleID は、検討する価値のある選択肢だと思います。

ご興味があれば、実際の PoC 構成例や、YAMAHA RTX 向けの設定ガイドもあわせてご紹介できますので、お気軽にお問い合わせください。

---

参考文献・出典

• ※1 ヤマハ株式会社「L2TP/IPsecのワンタイムパスワードを設定する」
  URL: https://network.yamaha.com/setting/router_firewall/monitor/lua_script/one_time_password-rtx1200
• ※2 ヤマハ株式会社 RTpro「L2TP/IPsec」
  URL: https://www.rtpro.yamaha.co.jp/RT/docs/l2tp_ipsec/
• ※3 SingleID 公式サイト「クラウドRADIUS」
  URL: https://www.singleid.jp/cloudradius/
• ※4 SingleID 公式サイト「プライベートPKI」
  URL: https://www.singleid.jp/privatepki/
• ※5 Microsoft Learn「Microsoft Entra certificate-based authentication (CBA) - Overview」
  URL: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication
• ※6 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度構築に向けた中間取りまとめ」
  URL: https://www.meti.go.jp/press/2025/04/20250414002/20250414002.html
• ※7 SingleID 公式サイト各サービスページ・技術情報（Entra ID 連携の記載を含む）
  URL: https://www.singleid.jp/
• ※8 Microsoft Learn「Use SCEP certificate profiles with Microsoft Intune」および関連ドキュメント
  URL: https://learn.microsoft.com/en-us/intune/intune-service/protect/certificates-profile-scep
• ※9 SingleID 公式サイト「料金・契約形態」ほか（クラウドRADIUS/PKI/SSO を含む統合サービス構成の説明）
  URL: https://www.singleid.jp/price/
• ※10 Microsoft Entra 認証ドキュメント（多要素認証・パスワードレス認証に関するコンセプト）
  URL: https://learn.microsoft.com/en-us/entra/identity/authentication/