本記事は 2026 年 4 月 20 日 に AWS Migration & Modernization Blog で公開された「 Amazon EVS now offers Windows Server Licensing: A step-by-step guide 」を翻訳したものです。 柔軟性、制御性、そして選択肢の豊富さは、 Amazon Elastic VMware Service (Amazon EVS) の根幹をなす重要な柱です。Amazon EVS では、VMware テクノロジーへの既存の投資を維持しながら、クラウドのメリットを活用できます。Amazon EVS なら、Amazon VPC 内の EC2 ベアメタルインスタンス上で VMware Cloud Foundation (VCF) を直接実行でき、既存のツールや運用プロセスを維持したまま、ワークロードを迅速に移行し、老朽化したインフラストラクチャを廃止できます。 Amazon EVS で Microsoft Windows Server ライセンス の提供を開始したことをお知らせいたします。EVS 環境内で Microsoft Windows Server オペレーティングシステムを実行する仮想マシン (VM) を移行または作成できます。本記事では、移行における意味、仕組み、開始方法を説明します。 より柔軟な対応: Amazon EVS での Windows Server ライセンスオプション Amazon EVS で Windows ベースの VM を実行するには、状況に応じて 2 つのオプションがあります。 Bring Your Own License (BYOL):  ポータビリティ権を持つ対象の Windows Server ライセンス (例: 2019 年 10 月 1 日より前に購入した Windows Server 2016 または 2019 ライセンス) をお持ちの場合、EVS 環境にそのライセンスを持ち込めます。既に投資済みのライセンスを引き続き使用できます。 Amazon EVS の Microsoft Windows ライセンスエンタイトルメント: ポータビリティ権のない VM (Windows Server 2022 や 2025 を実行する VM など) については、Amazon EVS を通じて直接エンタイトルメント（使用権）を付与できるようになりました。vCPU 時間単位の課金で、エンタイトルメントはいつでも追加・削除でき、ニーズの変化に応じてコストを柔軟に管理できます。 開始前に知っておくべきコンセプト ライセンスを設定する前に、EVS コネクタと Windows Server ライセンスエンタイトルメントの 2 つのコンセプトを理解しておく必要があります。 EVS コネクタ: 今回のリリースで EVS コネクタが導入されました。コネクタにより、Amazon EVS サービスが EVS 環境内の VCF 管理アプライアンス (vCenter Server など) と通信できるようになります。各コネクタは 1 つの管理アプライアンスにマッピングされ、完全修飾ドメイン名 (FQDN) と AWS Secrets Manager に保存された認証情報で認証します。Windows Server ライセンスには、Amazon EVS 環境に vCenter コネクタが必要です。コネクタにより、Amazon EVS が Windows Server ライセンスの使用状況を追跡し、VM のライフサイクルイベントを監視できます。 Windows Server ライセンスエンタイトルメント: AWS 提供のライセンスを使用する Windows Server VM ごとにエンタイトルメントを作成する必要があります。作成後、Amazon EVS が VM の電源状態と vCPU 構成を監視するため、課金は実際の使用量に連動し、ワークロードの需要に応じて消費をスケールできます。 課金の仕組み: 監視はエンタイトルメント作成時に開始されますが、課金は VM の実行中の実際のリソース使用量に基づきます。Amazon EVS の Windows ライセンスは、エンタイトルメントを付与した VM の vCPU 時間単位で課金されます。AWS を通じてライセンスを取得した VM のみが課金対象です。Windows Server ライセンスのポータビリティ権の対象となる VM には、AWS からの追加ライセンスコストは発生しません。料金の例については、 Amazon EVS の料金ページ をご覧ください。 ステップバイステップガイド 以下の手順で、EVS 環境内のライセンスを設定します。 手順: VMware vCenter Server 内に ReadOnly ロールを持つユーザーアカウントを作成し、認証情報を AWS Secrets Manager に保存する。 EVS 内に vCenter コネクタを作成する。 VMware VM ID を使用して EVS 内に Windows Server ライセンスエンタイトルメントを追加する。 Activation VPC エンドポイントを作成し、Windows Server VM が AWS Key Management Server (KMS) を使用するよう設定する。 ステップ 1: EVS 環境内の VMware vCenter Server に ReadOnly ロールを持つユーザーアカウントを作成し、認証情報を AWS Secrets Manager に保存する EVS コネクタは、EVS 環境内の vCenter Server アプライアンスとの認証に認証情報が必要です。コネクタを作成する前に、コネクタが使用する ReadOnly ロールを持つ専用ユーザーアカウントを作成します。 新しいユーザーの作成とロールの割り当てに必要な管理者権限を持つアカウントで、Amazon EVS 環境の vCenter Server にログインします。 ローカルの Single-Sign On ユーザー を作成し、 ReadOnly グループに割り当て ます。 図 1: 新しいユーザーのユーザー名、パスワード、説明 (推奨) を設定 図 2: 作成したユーザーを ReadOnlyUsers グループに追加 次に、EVS コネクタが vCenter アプライアンスと連携するために、作成した認証情報が必要です。認証情報を安全に保存し Amazon EVS と共有するには、特定のタグを付けて AWS Secrets Manager に保存します。 AWS マネジメントコンソール から AWS Secrets Manager にアクセスします。 「新しいシークレットを保存する」 を選択します。 「その他のシークレットのタイプ」 を選択します。 「キー/値のペア」 セクションで、完全なユーザー名を 「 キー」 に、パスワードを 「 値」 に入力します。入力後、「 次」  を選択します。 ユーザー名は username@vsphere.local の形式にします この例では、ユーザー名は evs-connector@vsphere.local です 「シークレットの名前と説明」 セクションで、シークレットの名前を入力します。説明はオプションで追加できます。 「タグ – オプション」 セクションで 「 追加する」  を選択します。 キー に EvsAccess 、値 に true を入力してタグを追加します。 注意: キー と 値 は大文字と小文字が区別されます。 図 3: シークレットに EvsAccess=true タグを付与 「ローテーションを設定する」 セクションはデフォルトのままにします。「 次 」 を選択します。 内容を確認し、「 保存」  を選択します。 ステップ 2: EVS 内に vCenter コネクタを作成する 次に、vCenter Server との通信を可能にする Amazon EVS コネクタを作成します。 AWS マネジメントコンソール から Amazon EVS にアクセスします。 コネクタを追加する EVS 環境を選択します。 「コネクタ」 タブを選択し、 「コネクタを作成」 を選択します。 図 4: 新しいコネクタを作成 Amazon EVS vCenter アプライアンス の FQDN を入力します。 先ほど作成した AWS Secrets Manager のシークレットをリストから選択します。 vCenter ユーザーのアクセスと権限を設定済みであることを確認するチェックボックスを選択し、「 コネクタを作成 」 を選択します。 図 5: EVS vCenter へのアクセス権を持つ新しいコネクタの作成フォームを送信 接続の検証には最大 10 分かかる場合があります。Amazon EVS 環境のコネクタタブでコネクタの状態を確認できます。 次のステップに進む前に、 「状態」  が Active 、 「ステータス」 が Passed になるまで待つ必要があります。 ステップ 3: VMware VM ID を使用して EVS 内に Windows Server ライセンスエンタイトルメントを追加する ユーザーアカウントとコネクタの設定が完了したら、VM に Windows Server ライセンスのエンタイトルメントを付与できます。 AWS マネジメントコンソール から Amazon EVS にアクセスします。 コネクタを追加する EVS 環境を選択します。 「使用権限」 タブを選択し、 Add entitlements を選択します。 図 6: エンタイトルメントを追加 .csv ファイルをアップロードするか、VM ID を手動で追加できます。このウォークスルーでは、手動で ID を追加します。 Note: vCenter では PowerCLI やその他のツールで VM Managed Object ID を取得できます。 Note: 各エンタイトルメントに含められる VM は最大 100 台です。100 台ずつバッチでエンタイトルメントをリクエストできます。 テキストボックスに VM ID をカンマ区切りで入力します。 Add entitlements を選択します。 図 7: 新しいエンタイトルメントに VM ID を送信 エンタイトルメントの 「ステータス」 が Active に変わったことを確認します。 ステップ 4: Activation VPC エンドポイントを作成し、Windows Server VM が AWS Key Management Server (KMS) を使用するよう設定する Amazon EVS は、エンタイトルメントを付与した VM のアクティベーションに使用する Key Management Services (KMS) サーバーエンドポイントを提供します。エンタイトルメントの作成後、VPC エンドポイントを作成して Amazon EVS 提供の KMS サーバーへの接続を有効にできます。 このエンドポイントは、AWS 提供の Windows Server ライセンスを使用している Amazon EVS 環境が稼働中の場合にのみ作成できます。 AWS マネジメントコンソール から Amazon VPC にアクセスします。 左側のナビゲーションペインで、「 PrivateLink と Lattice」 セクションから 「 エンドポイント」 を選択します。 「エンドポイントを作成」 を選択します。 エンドポイントの名前を入力します。 「タイプ」 で 「 AWS のサービス」 を選択します。 図 8: Activation VPC エンドポイントを作成 サービス名が「 com.amazonaws.<region>.evs-windows-server-activation 」のサービスを選択します。 ネットワーク設定で、ドロップダウンメニューから Amazon EVS の VPC を選択します。 図 9: 新しいエンドポイントのアクティベーションサービスを設定 次に、 「サブネット」 セクションから サービスアクセスサブネット を選択します。 図 10: 新しいエンドポイントにサービスアクセスサブネットを関連付け エンドポイントにアタッチする セキュリティグループ を選択します。セキュリティグループは、AWS KMS サーバーに接続する Windows Server VM からの インバウンド TCP 1688 を 許可する必要があります 。 エンドポイントのステータスが 「 使用可能」 になったら、エンドポイント名を選択してスクロールダウンし、「 プライベート DNS 名」 を確認します。次のタスクで必要になります。 図 11: エンドポイントのプライベート DNS 名を取得 次に、エンタイトルメントを付与した VM が Amazon EVS 提供の KMS サーバーエンドポイントを Windows アクティベーションに使用するよう設定します。各 VM で手動で設定するか、PowerShell やグループポリシーでプロセスを自動化できます。本記事では、PowerShell による手動オプションを紹介します。 Windows Server VM にログインし、 PowerShell ウィンドウを開きます。 コピーした Private DNS name で、以下のコマンドにより VM が AWS KMS サーバーを使うよう設定します。 slmgr /skms <VPC Endpoint Private DNS Name>:1688 この例では、コマンドは以下のようになります。 slmgr /skms evs-windows-server-activation.us-east-2.amazonaws.com:1688 Key Management Service machine が AWS KMS サーバーに設定されたことを通知するダイアログウィンドウが表示されます。 図 12: Windows Server VM の AWS KMS サーバー設定が完了 次に、以下のコマンドを実行して Windows Server VM をアクティベートします。 slmgr /ato 成功すると、製品が正常にアクティベートされたことを通知するダイアログウィンドウが表示されます。 図 13: Windows Server VM のアクティベーション成功 Windows Server VM が正しく設定されたことを確認するには、以下のコマンドを実行します。 slmgr /dli 成功すると、以下のメッセージが表示されます。 図 14: ライセンスアクティベーションの確認 コマンドラインインターフェイス (CLI) を使う場合は、 ユーザーガイド を参照してください。 開始方法 今すぐ AWS への移行を始めましょう。戦略的なデータセンター撤退の計画、運用コストの削減、クラウドイノベーションの活用のいずれであっても、Amazon EVS で VCF ベースのワークロードをシンプルに移行できます。 さあ始めましょう: 今すぐ Amazon EVS コンソール にアクセス 詳細を確認: 技術ドキュメント で Amazon EVS とライセンスについて学ぶ 移行とモダナイゼーションのオプションを検討する: AWS for VMware ページ ですべての VMware ワークロードの AWS への移行・モダナイゼーションオプションを確認 計画を開始する: まずは お問い合わせ いただき、 無料のアセスメント から始めましょう。 著者について James Selwood AWS の Infrastructure Migration and Modernization チームのシニアスペシャリストソリューションアーキテクトです。19 年の業界経験を持ち、2019 年に AWS に入社。VMware、ネットワーク、コンピューティングインフラストラクチャのバックグラウンドを活かし、お客様のクラウド移行を支援しています。 Allan Scott AWS のシニアスペシャリストソリューションアーキテクトです。2022 年に AWS に入社し、Infrastructure Migration and Modernization チームで 22 年の業界経験を活かして複雑な技術課題に取り組んでいます。VMware 環境、ネットワーク、コンピューティングインフラストラクチャの最適化を専門としています。 Alex Pylnev AWS の Infrastructure Migration and Modernization チームのスペシャリストソリューションアーキテクトです。クラウド移行の計画・実行からレガシーインフラストラクチャのモダナイゼーションまで、お客様の技術課題を支援しています。VMware 環境での豊富な経験を持ちます。 Bianca Velasco AWS のプロダクトマーケティングマネージャーとして、VMware ベースのワークロードの AWS への移行とモダナイゼーションを担当しています。マーケティングとテクノロジー分野で 7 年以上の経験があります。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

はじめに この2月、教育版マインクラフトに長年待望されていた専用サーバープログラム（Dedicated Server）がリリースされました。この記事はこのサーバー専用プログラムをセットアップしてホストするまでを解説します […]

みなさんこんにちは、イノベーションセンターの福田・村田です。 我々は、クラウドとオンプレミスそれぞれの検証環境を所有しており、オンプレミス製品やそれらをクラウドと組み合わせたハイブリッドクラウドの検証をおこなっています。 チームでの活動を続ける中で検証環境が拡大し、セキュリティ強化やコンプライアンス対応、DevOps 環境の整備がますます重要になってきました。 その一環でサーバーやネットワーク機器へのログイン認証を Entra ID に一元化する取り組みを行いました。 本記事では、その背景や技術選定の判断、運用して得られた知見を共有します。 具体的には以下のような内容を扱います。 SSH 公開鍵の手動配布をやめて、Entra ID 認証ベースの一時鍵（opkssh）に移行した話 ネットワーク機器のログインを FreeRADIUS + privacyIDEA で Entra ID に寄せた話 実際に運用してみて分かったハマりどころ（24時間で鍵が切れる、パスワード+OTP 連結入力、など） これまでの構成と課題 全体の構成と採用した方式 サーバーログイン — opkssh 導入前の課題 opkssh を選んだ経緯 ログインの流れ ネットワーク機器ログイン — FreeRADIUS + privacyIDEA RADIUS (FreeRADIUS) 採用の背景 RADIUS の MFA 提供 (privacyIDEA) FreeRADIUS + privacyIDEA 連携による MFA + RADIUS 認証 やってみての所感 よかったこと 「誰がログインしたか」が追えるようになった サーバー・ネットワーク機器追加時の作業が減った 注意が必要だったこと・ハマりどころ opkssh の一時鍵は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 に寄せた取り組みを紹介しました。 鍵配布や個別アカウントの棚卸を削減し、ログインの追跡性を向上させることができました。 今後も拡大が見込まれる検証環境において、セキュリティや運用を考慮した体制整備を進めていきます。