Microsoft PurviewのInformation Protectionで使われるRights Management connector（RMSコネクタ）は、共有シークレット認証から証明書ベース認証へ移行します。結論として、オンプレミスのExchange Server、SharePoint Server、Windows Server FCIでRMSコネクタを使っている組織は、Microsoft Entraアプリ登録、証明書、PowerShellによる構成手順を事前に見直す必要があります。
今回の変更は、単なる認証方式の置き換えではありません。従来はセットアップ側がサービスプリンシパルや共有シークレットを用意する流れでしたが、今後は管理者が自分たちでEntra IDアプリと証明書を準備し、各ワークロードに対して証明書構成を行う形になります。Microsoft 365 Roadmapでは、この更新はPreviewが2026年6月、General Availabilityが2026年8月予定、ステータスはIn developmentとして掲載されています。(Microsoft)
Microsoft PurviewのRMSコネクタで何が変わるのか
今回の更新の中心は、Microsoft Rights Management（RMS）connectorの認証方式が、shared-secret authentication（共有シークレット認証）からcertificate-based authentication（証明書ベース認証）へ移行する点です。
Microsoft 365 Roadmap ID 564617では、管理者がMicrosoft Entraアプリ登録と証明書を構成し、新しいPowerShellモジュールを使ってConnector、Exchange、SharePoint、FCIの各ワークロードに証明書を設定すると説明されています。また、新しいPowerShell cmdletが証明書のインポート、レジストリ構成、秘密キー権限、検証を扱うとされています。(Microsoft)
変更点を整理すると、次のようになります。
| 項目 | これまで | 今後 |
|---|---|---|
| 認証方式 | 共有シークレットを利用 | 証明書ベース認証を利用 |
| Entra ID側の準備 | セットアップがサービスプリンシパルやシークレットを用意する流れ | 管理者がEntraアプリ登録と証明書を準備 |
| 構成作業 | 既存のRMSコネクタ手順中心 | 新PowerShellモジュールでワークロードごとに証明書を構成 |
| 対象ワークロード | RMS Connector、Exchange、SharePoint、FCI | 同じくConnector、Exchange、SharePoint、FCI |
| 管理上の注意点 | シークレットの保管・期限管理が中心 | 証明書の有効期限、秘密キー権限、展開先の整合性が重要 |
ポイントは、「証明書ベースになって安全になる」という表面的な話ではなく、認証情報のライフサイクル管理が管理者側に移ることです。証明書の期限切れ、秘密キー権限の不足、ワークロードごとの設定漏れがあると、オンプレミス側のIRM機能に影響する可能性があります。
影響を受ける環境
影響を受けるのは、Microsoft Purview Information ProtectionやAzure Rights Managementを利用し、オンプレミスサーバーからクラウド側のRights Managementサービスへ接続するためにRMSコネクタを展開している環境です。
Microsoft Learnでは、RMSコネクタはオンプレミスのExchange Server、SharePoint Server、Windows ServerのFile Classification Infrastructure（FCI）でIRM機能を使えるようにするための小規模なオンプレミスサービスと説明されています。具体的には、オンプレミスサーバーとクラウドサービスの通信インターフェース、つまりリレーとして動作します。(Microsoft Learn)
対象になりやすい環境は、次のとおりです。
| 環境 | 確認すべきポイント |
|---|---|
| Exchange ServerでIRMを利用 | Exchange Server 2013、2016、2019でRMSコネクタを経由しているか |
| SharePoint ServerでIRM保護ライブラリを利用 | SharePoint Server 2013、2016、2019がRMSコネクタを参照しているか |
| Windows Server FCIでファイルを分類・保護 | File Classification InfrastructureがRMSコネクタ経由でRMSテンプレートを使っているか |
| ハイブリッド構成 | 一部ユーザーがExchange Online、一部がExchange Serverなど混在していないか |
| 既存コネクタを更新予定 | アップグレード前にEntraアプリ登録と証明書準備が必要になる可能性 |
RMSコネクタがサポートするオンプレミスサーバーとして、Microsoft LearnではExchange Server 2013/2016/2019、SharePoint Server 2013/2016/2019、Windows Server 2012/2012 R2/2016のFCIが挙げられています。(Microsoft Learn)
影響が小さい環境と大きい環境の見分け方
まず確認したいのは、「Microsoft Purviewを使っているか」ではなく、オンプレミス側でRMSコネクタを使っているかです。Microsoft 365やPurviewのクラウド機能だけを利用している組織では、今回の変更が直接の作業につながらない場合があります。
一方で、次の条件に当てはまる場合は影響が大きくなります。
- オンプレミスExchangeでIRM保護メールを扱っている
- SharePoint ServerのIRM保護ライブラリを利用している
- Windows Server FCIでOffice文書の分類・保護を自動化している
- RMSコネクタを高可用性構成で複数台展開している
- 証明書管理やEntraアプリ登録の運用ルールが未整備
- サーバー構成を手動レジストリ編集で管理している
- 本番と検証環境でRMSコネクタの構成差分がある
特に注意したいのは、過去に一度だけRMSコネクタを構成し、その後ほとんど触っていない環境です。こうした環境では、誰が証明書を管理するのか、期限切れをどう検知するのか、障害時にどのログを見るのかが曖昧になりがちです。
管理者が最初に確認すべきこと
今回の変更に備えるなら、いきなり証明書を作るのではなく、現在のRMSコネクタ利用状況を棚卸しすることが先です。設定作業よりも、対象範囲の見落としのほうが障害につながりやすいためです。
RMSコネクタの利用有無を確認する
まず、オンプレミス環境で次の構成が残っていないか確認します。
| 確認対象 | 見るべき場所・観点 |
|---|---|
| RMSコネクタサーバー | RMS ConnectorがインストールされているWindows Server |
| Exchange Server | IRM設定、RMSコネクタ向けのリダイレクト設定 |
| SharePoint Server | IRM設定、RMSサーバー指定、レジストリ設定 |
| FCIサーバー | File Server Resource Manager、分類ルール、RMSテンプレート利用 |
| ネットワーク | RMSコネクタからAzure Rights Managementサービスへの通信 |
| 運用資料 | インストール時の管理者、証明書、プロキシ、DNS、負荷分散の記録 |
RMSコネクタは、1つのテナントにつき単一のコネクタ構成を展開し、高可用性のために複数サーバーで構成する形が案内されています。Microsoft Learnでは、最小2台のコンピューターをRMSコネクタ用に識別する手順も示されています。(Microsoft Learn)
Entraアプリ登録の管理方針を決める
今回の更新では、管理者がMicrosoft Entraアプリ登録と証明書を用意することが前提になります。ここで重要なのは、「誰でも作れるアプリ登録」にしないことです。
実務では、次のようなルールを決めておくと安全です。
| 項目 | 推奨される考え方 |
|---|---|
| アプリ登録の命名 | rms-connector-prod、rms-connector-testなど用途と環境が分かる名前にする |
| 所有者 | 個人ではなく、情報保護・ID管理チームの管理者を複数登録する |
| 証明書 | 有効期限、発行元、秘密キー保管場所を台帳化する |
| 権限管理 | 必要最小限の管理者だけが証明書やアプリ登録を変更できるようにする |
| 更新手順 | 証明書更新、ロールバック、検証コマンドを手順書に含める |
個人アカウントをアプリ所有者にしたままにすると、退職・異動・権限整理のタイミングで管理不能になることがあります。Entraアプリ登録は、作って終わりではなく、運用資産として扱うべきです。
証明書のライフサイクルを設計する
証明書ベース認証では、証明書そのものの安全性と継続運用が重要になります。共有シークレットより安全性を高めやすい一方で、証明書の期限切れや秘密キー権限の不備があると、認証失敗につながります。
最低限、次の項目を決めてください。
| 設計項目 | 判断基準 |
|---|---|
| 証明書の発行元 | 社内CA、信頼済みCA、運用ポリシーに合う方式を選ぶ |
| 有効期限 | 長すぎる期限は避けつつ、更新忘れを防げる期間にする |
| 秘密キーの保護 | エクスポート可否、保管場所、アクセス権を明確にする |
| 更新通知 | 期限の90日前、60日前、30日前など複数段階で通知する |
| ローテーション | 新旧証明書の並行期間を設け、切り戻し可能にする |
| 監査 | 誰が証明書を更新・差し替えたか追跡できるようにする |
失敗しやすいのは、「証明書をアップロードしたので完了」と考えてしまうケースです。実際には、ローカルサーバー側で証明書が参照できること、秘密キーに必要な読み取り権限があること、各ワークロードで正しく構成されていることまで確認する必要があります。
移行前に整理すべき設定項目
RMSコネクタの移行準備では、次の順番で確認すると抜け漏れを減らせます。
| 順番 | 作業 | 目的 |
|---|---|---|
| 1 | RMSコネクタ利用サーバーを一覧化 | 対象外と思っていた古いサーバーを見落とさない |
| 2 | Exchange、SharePoint、FCIの利用有無を確認 | ワークロードごとの設定範囲を把握する |
| 3 | 既存のレジストリ・構成スクリプトを確認 | 手動設定と自動設定の差分を把握する |
| 4 | Entraアプリ登録の設計 | 本番・検証・所有者・権限を決める |
| 5 | 証明書の発行・保管方針を決定 | 期限切れや秘密キー紛失を防ぐ |
| 6 | 新PowerShellモジュールの検証 | 本番適用前にcmdletの動作を確認する |
| 7 | 監視項目を更新 | 認証失敗、証明書期限、イベントログを監視する |
| 8 | ロールバック手順を作成 | 切替失敗時の復旧経路を確保する |
Microsoftの説明では、顧客はコネクタのインストールまたはアップグレード前に、Entra IDアプリケーションの登録と証明書アップロードを計画すべきとされています。(Microsoft)
Exchange Serverで確認すべきポイント
Exchange ServerでIRMを使っている場合、RMSコネクタはメールや添付ファイルの保護・利用に関わる重要な経路になります。特にオンプレミスExchangeが残っているハイブリッド環境では、クラウド側だけを見ていると影響を見落とします。
確認すべきポイントは次のとおりです。
- Exchange Server 2013、2016、2019のどれが稼働しているか
- すべての対象サーバーがRMSコネクタ向けに構成されているか
- 旧AD RMSから移行した環境で古い設定が残っていないか
- RMSコネクタとの通信がHTTPではなくHTTPSになっているか
- 証明書変更後にIRM保護メールの作成・閲覧・転送制限が期待どおり動くか
Microsoft Learnでは、Exchange 2013はClient Access ServersとMailbox Servers、Exchange 2016/2019はMailbox Serversが構成対象として示されています。(Microsoft Learn)
実務上は、切替後に次のようなテストを行うと安心です。
| テスト | 確認内容 |
|---|---|
| IRM保護メールの送信 | テンプレートが選択でき、送信できるか |
| 受信者側の閲覧 | 許可されたユーザーが開けるか |
| 権限制御 | 転送禁止、印刷禁止などが反映されるか |
| 外部・ハイブリッド | Exchange Online側ユーザーとのやり取りに問題がないか |
| イベントログ | 認証失敗や未承認アクセスが出ていないか |
SharePoint Serverで確認すべきポイント
SharePoint ServerでIRM保護ライブラリを使っている場合、RMSコネクタの変更はドキュメントの保護と閲覧に影響します。特に、部門サイトや長期間使われているドキュメントライブラリでは、利用者がIRMの存在を意識していないことがあります。
確認すべき項目は次のとおりです。
- SharePoint Server 2013、2016、2019の対象ファーム
- IRMを有効化しているWebアプリケーションやライブラリ
- RMSコネクタを指定している設定
- フロントエンドWebサーバーとCentral Administrationサーバーの構成
- 証明書変更後のダウンロード、閲覧、編集、権限制御の動作
Microsoft Learnでは、SharePointではフロントエンドWebサーバーとCentral Administrationをホストするサーバーが構成対象として案内されています。(Microsoft Learn)
SharePointでは、設定そのものよりも「どのライブラリでIRMを使っているか」の棚卸しに時間がかかります。移行計画では、情報システム部門だけでなく、文書管理やコンプライアンス担当にも確認を取ると見落としを減らせます。
Windows Server FCIで確認すべきポイント
File Classification Infrastructure（FCI）を使ってファイルサーバー上のOffice文書を分類・保護している場合も、RMSコネクタの影響を受けます。
Microsoft Learnでは、RMSコネクタを使うWindows Server FCIでは、File Resource ManagerをインストールしたWindows Serverコンピューターが構成対象とされています。(Microsoft Learn)
確認すべきポイントは次のとおりです。
| 確認項目 | 理由 |
|---|---|
| FCI対象サーバー | 分類ルールが動いているサーバーを漏れなく把握する |
| 分類ルール | RMSテンプレートを使うルールがあるか確認する |
| ファイル形式 | RMSコネクタはOffice文書中心の利用である点を確認する |
| 実行タイミング | 夜間バッチや定期タスクで障害が出ないか確認する |
| 所有者設定 | 保護後の所有者・利用権限が期待どおりか確認する |
Microsoft Learnでは、RMSコネクタによってWindows Serverフォルダー上のOffice文書が暗号化される場合、RMSコネクタ用に作成されたMicrosoft Entra IDのサービスプリンシパルアカウントがユーザーの代わりに文書を暗号化すると説明されています。(Microsoft Learn)
今回の証明書ベース認証への移行後も、利用者から見ると「ファイルが開けるかどうか」が最も重要です。FCIでは、管理画面上の成功だけでなく、実ファイルを使った読み取り・編集・権限制御の確認を必ず行ってください。
展開時に注意したい失敗パターン
証明書ベース認証への移行では、次のような失敗が起こりやすくなります。
| 失敗パターン | 起こり得る影響 | 対策 |
|---|---|---|
| 証明書の秘密キー権限が不足 | コネクタやワークロードが証明書を使えない | PowerShellによる検証とイベントログ確認を行う |
| 本番と検証で別の手順を使う | 本番切替時に想定外の差分が出る | 同じ手順書・同じ構成方針で検証する |
| Entraアプリ登録の所有者が個人のみ | 担当者不在時に更新できない | 複数管理者または管理グループで所有する |
| 証明書期限を監視していない | 期限切れでIRM機能が停止する | 期限通知と定期レビューを設定する |
| 一部ワークロードだけ設定漏れ | Exchangeは動くがSharePointが失敗するなど | Connector、Exchange、SharePoint、FCIを個別にチェックする |
| 古いレジストリ設定が残る | 接続先やプロトコルが意図とずれる | 自動構成ツールや新cmdletの結果を確認する |
| ロードバランサー配下の一部ノードだけ未更新 | 断続的な認証失敗 | 全ノードの証明書・設定・イベントログを比較する |
特に高可用性構成では、1台だけ設定が古いままでも、利用者から見ると「たまに開けない」「特定の時間だけ失敗する」といった切り分けにくい障害になります。ロードバランサー配下のRMSコネクタサーバーは、ノード単位で検証してください。
レジストリ設定とPowerShell構成の考え方
既存のRMSコネクタでは、オンプレミスサーバー側にレジストリ設定が必要です。Microsoft Learnでは、Exchange、SharePoint、Windows ServerでRMSコネクタを使うためのレジストリ設定について、手動で追加・確認する場合の情報が提供されています。一方で、推奨される方法はMicrosoft RMS connectorのサーバー構成ツールを使うこととされています。(Microsoft Learn)
今回の更新では、新しいPowerShell cmdletがレジストリ構成や証明書関連の処理を扱うと説明されています。したがって、今後の運用では「手動でレジストリを編集する」よりも、PowerShellで再現可能な手順として管理することが重要になります。
実務では、次のように考えるとよいでしょう。
| 管理方法 | 向いている場面 | 注意点 |
|---|---|---|
| PowerShellによる構成 | 本番・検証・複数サーバーへ同じ設定を展開したい | 実行ログとパラメーターを保管する |
| 自動構成ツール | 既存手順を踏襲しつつ効率化したい | 新しい証明書ベース認証手順との整合を確認する |
| 手動レジストリ確認 | 障害調査や差分確認 | 手作業での変更は最小限にする |
手順書には、実行コマンドだけでなく、実行前後に確認する値、想定される成功メッセージ、失敗時に見るイベントIDを入れておくと運用しやすくなります。
監視とトラブルシューティングで見るべきログ
移行後は、動作確認だけでなく継続監視も必要です。RMSコネクタはApplicationイベントログにMicrosoft RMS connectorのイベントを記録します。Microsoft Learnでは、サービス開始を示すInformation 1000、承認済みサーバーの接続を示す1002、承認アカウント一覧の更新を示す1004などが案内されています。(Microsoft Learn)
特に確認したいイベントは次のとおりです。
| イベント | 意味 | 確認ポイント |
|---|---|---|
| Information 1000 | RMS connector Web service開始 | サービスが正常に起動しているか |
| Information 1002 | 承認済みサーバーの接続成功 | Exchange、SharePoint、FCIから接続できているか |
| Information 1004 | 承認アカウント一覧の更新 | 承認リストが取得できているか |
| Warning 2001 | 未承認アクセス | 対象サーバーのアカウントが承認されているか |
| Warning 2002 | HTTP接続の警告 | HTTPS構成に移行できているか |
| Warning 2003 | 承認一覧が空 | 承認サーバーの設定が抜けていないか |
| Error 3001 | 承認情報のダウンロード失敗 | DNS、インターネット接続、プロキシを確認する |
Microsoft Learnでは、RMSコネクタサーバーがAzure Rights Managementサービスへ接続できない場合、Webプロキシ構成が原因になることが多いとも説明されています。(Microsoft Learn)
証明書ベース認証への移行後は、イベントログに加えて、次の監視も追加すると安全です。
- 証明書の有効期限
- 証明書の秘密キーアクセス権
- Entraアプリ登録の所有者・証明書情報
- RMSコネクタサーバーのサービス稼働状況
- Exchange、SharePoint、FCIからの実利用テスト
- プロキシやファイアウォール変更の影響
開発者・自動化担当が確認すべきこと
この変更は主に管理者向けですが、PowerShellや構成管理を担当する開発者・自動化担当にも関係します。特に、RMSコネクタの構築や更新をスクリプト化している場合は、共有シークレット前提の処理を見直す必要があります。
確認すべき点は次のとおりです。
| 確認項目 | 理由 |
|---|---|
| 既存スクリプトに共有シークレット前提の処理がないか | 新しい方式では不要または動作しない可能性がある |
| Entraアプリ登録を手動で作るのか、自動化するのか | 権限と監査の設計が変わる |
| 証明書の生成・取得・保管をどう扱うか | 秘密キーを不用意に露出させないため |
| PowerShellモジュールのバージョン管理 | 検証環境と本番環境の差分を防ぐ |
| 実行アカウントの権限 | 必要な設定を行えるが、過剰権限にならないようにする |
| CI/CDや構成管理ツールとの連携 | 証明書や秘密キーをログに出さないようにする |
証明書や秘密キーを扱う処理では、ログ出力に注意してください。デバッグ目的で証明書情報、パス、権限、サムプリントなどを出力する場合でも、公開ログや共有チャンネルに流れないように制御する必要があります。
移行・展開の実践ステップ
本番環境での展開は、次の流れで進めると現実的です。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 現状把握 | RMSコネクタ、Exchange、SharePoint、FCIの利用状況を棚卸し | 対象サーバーとワークロード一覧がある |
| 設計 | Entraアプリ登録、証明書、所有者、更新手順を決める | 運用方針が承認されている |
| 検証 | 検証環境で新PowerShellモジュールと証明書構成を試す | IRM保護と閲覧が成功する |
| 手順化 | コマンド、確認項目、ロールバックを文書化 | 第三者が同じ手順で実行できる |
| 本番準備 | 証明書、権限、メンテナンス時間、通知を準備 | 実施判定会議でGo判断できる |
| 本番適用 | ワークロードごとに構成し、イベントログと利用テストを確認 | Exchange、SharePoint、FCIの主要シナリオが成功する |
| 運用移行 | 証明書期限監視、イベント監視、更新手順を定常運用へ組み込む | 次回更新時の担当と手順が明確 |
ここで重要なのは、RMSコネクタ単体のインストール成功をゴールにしないことです。利用者が使うのは、Exchangeの保護メール、SharePointの保護ライブラリ、FCIで保護されたファイルです。必ずワークロードごとの利用シナリオで確認してください。
今回の更新で管理者が取るべき次の行動
今回のMicrosoft Purview Information ProtectionにおけるRMSコネクタの証明書ベース認証対応は、セキュリティ強化としては前向きな変更です。一方で、共有シークレット前提の古い運用を続けている組織では、Entraアプリ登録、証明書、PowerShell、ワークロード別設定という新しい管理ポイントが増えます。
まず行うべきことは、次の3つです。
- 自社でRMSコネクタを使っているか確認する
- Exchange、SharePoint、FCIのどこで使われているか一覧化する
- Entraアプリ登録と証明書管理の運用ルールを決める
そのうえで、検証環境で新しいPowerShellモジュールによる構成、証明書の権限、イベントログ、実際のIRM利用シナリオを確認します。Microsoft 365 Roadmapの情報は変更される可能性があるため、PreviewやGeneral Availabilityの時期だけで判断せず、公式情報とMicrosoft Learnの更新を継続的に確認しながら展開計画を固めてください。Microsoft 365 Roadmap自体も、商用機能の予定日や説明は変更される可能性があると案内しています。(Microsoft)
コメント