みなさんこんにちは、イノベーションセンターの福田・村田です。
我々は、クラウドとオンプレミスそれぞれの検証環境を所有しており、オンプレミス製品やそれらをクラウドと組み合わせたハイブリッドクラウドの検証をおこなっています。 チームでの活動を続ける中で検証環境が拡大し、セキュリティ強化やコンプライアンス対応、DevOps 環境の整備がますます重要になってきました。
その一環でサーバーやネットワーク機器へのログイン認証を Entra ID に一元化する取り組みを行いました。 本記事では、その背景や技術選定の判断、運用して得られた知見を共有します。 具体的には以下のような内容を扱います。
- SSH 公開鍵の手動配布をやめて、Entra ID 認証ベースの一時鍵（opkssh）に移行した話
- ネットワーク機器のログインを FreeRADIUS + privacyIDEA で Entra ID に寄せた話
- 実際に運用してみて分かったハマりどころ（24時間で鍵が切れる、パスワード+OTP 連結入力、など）
これまでの構成と課題
これまで我々の環境では、サーバーやネットワーク機器ごとに異なるログイン方式が採用されていました。 例えば、サーバーには SSH 公開鍵認証をしている一方、ネットワーク機器では SSH パスワード認証やコンソール接続をしている、という状態です。
その結果、以下のような課題が顕在化していました。
- SSH 鍵ペア・パスワード・アカウントなどの認証情報の管理が煩雑になり、属人化する
- 機器ごとに運用手順が異なり、運用コストが増加する
- 誰が・いつ・どの機器にログインしたかを把握しづらく、トラブルシューティングにかかる時間が長期化する
こうした課題を解決すべく、原因であったログイン方式の改修に取り組みました。 具体的には、次の2点です。
- サーバーおよびネットワーク機器のログイン認証を一元化する
- 誰が・いつ・どの機器にログインしたかを追跡可能にする
また、多要素認証（Multi-Factor Authentication, MFA）の導入による認証の強化も合わせて目指しました。
我々の環境ではすでに、Web サービスのログインを Microsoft Entra ID （Entra ID, 旧 Azure Active Directory）に一元化し、サインインログも Entra ID で追跡可能にした実績がありました。 また、Entra ID には MFA の機能が備わっています。 そこで、機器へのログインも Entra ID に寄せることで、Web サービスと同様に認証の一元化、ログイン履歴の追跡、そして MFA の導入をまとめて実現できると判断しました。
全体の構成と採用した方式
今回、すべての機器で認証の起点を Entra ID にしました。 最終的に SSH でログインする点は共通していますが、サーバーとネットワーク機器で採用した方式が異なるため、それぞれ解説します。
サーバーログイン — opkssh
導入前の課題
もともとサーバーへのログインには SSH の公開鍵認証を利用していました。利用者ごとに SSH 鍵ペアを発行し、各サーバーに SSH 公開鍵を配置する運用です。
検証環境の拡大に伴いサーバー台数が増えるにつれて鍵管理において以下の運用負荷が課題になっていきました。
- SSH 公開鍵を配布する手間が増える
- どのサーバーにどの鍵が残っているか把握しづらくなる
opkssh を選んだ経緯
この課題に対して導入したのが OpenPubkey SSH（opkssh） です。 2025年3月に Cloudflare がオープンソース化を発表し、Linux Foundation の OpenPubkey プロジェクト傘下で開発されている OSS です。 OpenID Connect（OIDC）対応の IdP と連携して SSH ログインを提供する仕組みです。
opkssh の導入にあたって、SSH のプロトコル自体に手を入れる必要はありません。 サーバー側の sshd 設定ファイルと opkssh 用の設定ファイルを追加・変更することで導入できます（下記）。 この設定内容はサーバー固有のものではないため、サーバーが増えた場合でも容易に展開が可能です。 また、opkssh は認証結果を IdP と連携して利用するため、MFA についても SSH 側で個別に実装する必要はありません。 このような理由から、opkssh を採用しました。
# /etc/ssh/sshd_config ## 受信した SSH 公開鍵を opkssh が検証する AuthorizedKeysCommand /usr/local/bin/opkssh verify %u %k %t AuthorizedKeysCommandUser root
# /etc/opk/providers ## IdP として Entra ID を指定 ### tenant-id は Entra ID のテナントID ### clinet-id は Azure のクライアントID https://login.microsoftonline.com/{{ tenant-id }}/v2.0 {{ client-id }}
# /etc/opk/auth_id ## IdP が引き継げるサーバ内のユーザを指定 ### user-name は、サーバ内のユーザ名 ### email-address は、Entra ID アカウントのメールアドレス ### tenant-id は Entra ID のテナントID {{ user-name }} {{ email-address }} https://login.microsoftonline.com/{{ tenant-id }}/v2.0
ログインの流れ
opkssh 導入後のサーバーログインは、以下の流れになります。
- 利用者が
opkssh loginを実行すると、ブラウザで Entra ID のログイン画面が開きます - Entra ID での認証（MFA 含む）が成功すると、一時的な SSH 鍵ペアが配布されます。SSH 公開鍵には、鍵の有効期限や Entra ID のユーザ情報を含む PK Token が埋め込まれています
- 通常の SSH ログインと同様にサーバーにログインします
- サーバー側では sshd_config に設定した検証ツールが PK Token を検証し、問題なければログインが許可されます
この構成により、SSH ログインの認証が Entra ID に集約され、MFA を含む認証ポリシーを IdP 側で統一的に管理できるようになりました。 一次的な SSH 鍵ペアは短期間で失効するため、従来の、各サーバーに SSH 公開鍵を配置する運用も解消されました。
ネットワーク機器ログイン — FreeRADIUS + privacyIDEA
続いて、ネットワーク機器における Entra ID ログインおよび MFA の提供について解説します。
RADIUS (FreeRADIUS) 採用の背景
ネットワーク機器の認証一元化には代表的な選択肢として Terminal Access Controller Access-Control System Plus（TACACS+） や Remote Authentication Dial-In User Service（RADIUS） といった認証方法があります。
TACACS+ はコマンド単位の認可制御まで柔軟に設計できますが、その分、構築・運用の設計項目が多くなります。 さらに TACACS+ は構成・実装の自由度が高いのですが、設定や運用に関する事例が相対的に少なく、判断材料の収集に時間を要する印象でした。
一方 RADIUS は利用実績も豊富であり、運用ノウハウや設定例等も豊富に公開されていました。 さらに導入もシンプルにおこなえて幅広い機器がサポートしています。
そこで RADIUS を採用してログインを提供することにしました。
Entra ID による RADIUS の提供自体は Microsoft 公式が Windows Server の Network Policy Server を提供しています(参考文献)。 さらの Network Policy Server には Microsoft 公式として Azure MFA という MFA を導入する方式も提供していました(参考文献) 。 最初はこの方法で RADIUS を提供できないか検証していたました。 しかし検証途中で以下の点が判明し、今回は採用を見送りました。
- Windows Server の保守運用をしなければならないこと
- Network Policy Server とネットワーク機器による RADIUS ログインとの相性が悪いこと
そこで他に RADIUS を提供する方法を検討しました。 その中でも特に柔軟な設定ができ、まとまった情報を得やすい FreeRADIUS に着目しました。 FreeRADIUS はプラグイン形式で RADIUS 認証を拡張する仕組みが存在し、 RADIUS 認証を実質的にプラグインにバイパスできます。 我々はこの点に着目し、 FreeRADIUS にさらに MFA を提供するシステムをプラグインを通して提供することで MFA + RADIUS の環境を実現できないかを検討しました。
RADIUS の MFA 提供 (privacyIDEA)
RADIUS 認証は ID/パスワード認証を前提としたプロトコルです。 そのため MFA を導入するには追加の属性をいれたり、外部連携が必要になるという課題があります。 ですが FreeRADIUS であれば RADIUS 認証を拡張できるため、 MFA 認証も入れることができるだろうと予想しさまざまな MFA 認証システムを検討しました。
その中でも privacyIDEA は開発が活発であり、しかも FreeRADIUS と連携するためのプラグインを公式で提供していました。 コミュニティ規模が小さいためまとまった情報は少ないのですが、導入自体は公式自身で FreeRADIUS と連携するためのドキュメントを整備してくれているため、導入を簡単におこなえました。
privacyIDEA 自体は TOTP、 SMS、 E メール等豊富な MFA に対応しており、 REST API 経由でアカウントに MFA を提供できます。 その上 LDAP / Entra ID / RADIUS 等のさまざまなアカウントサービスとも連携する方法が用意されており、それらと連携して MFA を提供できます。
そこで今回はこの Entra ID、 FreeRADIUS との連携の容易さから privacyIDEA による RADIUS 認証 + MFA システムの提供をすすめました。
FreeRADIUS + privacyIDEA 連携による MFA + RADIUS 認証
具体的には以下のような流れで RADIUS 認証に MFA を提供しています。
- 機器官理者が FreeRADIUS に RADIUS クライアントとしてネットワーク機器を登録
- ユーザーは事前に privacyIDEA の Web UI で TOTP トークンを登録（Authenticator アプリケーション等で QR コードを読み取り）
- ネットワーク機器に SSH ログインすると RADIUS 認証リクエストがFreeRADIUS に送られる
- FreeRADIUS は privacyIDEA に認証を委譲。privacyIDEA は Entra Domain Services（LDAPS）経由でパスワードを検証し、TOTP は自身に登録されたトークンと照合する
- パスワード・TOTP ともに正しければ認証成功
なお、ログイン時にユーザーが入力するのはパスワードと TOTP を連結した文字列です。
たとえばパスワードが mypassword で TOTP が 123456 なら、mypassword123456 と入力します。
RADIUS プロトコルのパスワードフィールドが1つしかないため、privacyIDEA 側で末尾6桁を OTP として分離し、それぞれを検証する仕組みです。
これによって RADIUS 認証をするネットワーク機器からみるとパスワード認証にみえつつ実際には privacyIDEA 側でパスワード + MFA の検証をおこなうというシステムを構築できました。 FreeRADIUS のプラグイン拡張による柔軟性と privacyIDEA の MFA 提供によって、本来であれば ID/パスワード認証が基本となる RADIUS に対して Entra ID アカウントを提供しつつ MFA も提供でき、実現したかったネットワーク機器への MFA + Entra ID ログインを達成できました。
やってみての所感
構成や方式の話が続いたので、ここからは実際に運用して感じたことを共有します。
よかったこと
「誰がログインしたか」が追えるようになった
以前は、誰が・いつ・どの機器にログインしたかを特定できない状況でした。 Entra ID に認証を一元化したことですべてのログインが個人のアイデンティティへと紐づくようになり、トラブル時の調査や監査対応も楽になりました。
サーバー・ネットワーク機器追加時の作業が減った
以前はサーバー・ネットワーク機器を1台追加するたびに、その機器に対してメンバー個々がログインできるよう、ユーザや認証情報の設定する必要がありました。 しかし、opkssh や FreeRADIUS + privacyIDEA の導入後は、メンバー個々の設定は不要になり、サーバー・ネットワーク機器側に初期設定を一度だけすれば十分になりました。 これにより、機器追加時の作業量は人数に依存せず、機器台数にのみ依存する形となりました。 検証環境が頻繁に拡大する状況であっても、運用負荷の増加を抑えられるようになりました。
注意が必要だったこと・ハマりどころ
opkssh の一時鍵は24時間で失効する
opkssh が生成する SSH 鍵ペアはデフォルト24時間の有効期限があります。長時間の作業や翌日にまたがるメンテナンスでは途中で鍵が失効し、opkssh login の再実行が必要です。 「急にログインできなくなった」という問い合わせを防ぐため、利用者への事前周知は必須でした。
パスワード + OTP の連結入力は初見で戸惑う
RADIUS + privacyIDEA の構成では、ログイン時にパスワードと TOTP を連結して入力します（例：mypassword123456）。
慣れれば問題ありませんが、初めて使うメンバーからは「パスワード欄に何を入れればいいのか分からない」という声が上がりました。導入前にログイン手順書を用意してチームに共有してから展開したのは正解でした。
まとめ
本記事では、サーバーに opkssh、ネットワーク機器に FreeRADIUS + privacyIDEA を採用し、ログイン認証の起点を Entra ID に寄せた取り組みを紹介しました。
鍵配布や個別アカウントの棚卸を削減し、ログインの追跡性を向上させることができました。
今後も拡大が見込まれる検証環境において、セキュリティや運用を考慮した体制整備を進めていきます。
