SHIELD DRM 使用に関する FAQ
この文書はSHIELD DRMに関する受け付けられたQ&Aわ技術的背景/対応ガイドを一緒に記載された文書です。
文書変換 / 所有権
Q1. クラウドアップロード時にMIP文書の所有者をユーザー本人に設定できますか？
現象: ローカルPCのDS文書をクラウドにアップロードすると、MIP文書の所有者がユーザー本人ではなくSecurity365アプリとして表示されます。
不可能です。
クラウドで変換する時Azure アプリケーション 権限に変換が行われ、ユーザーの委任権限による変換はサポートされていません。
技術的背景
SHIELD DRMはMicrosoft Entra ID(旧Azure AD)に基づいています。MSAL 認証フローをサポートし、**デーモン(Daemon)**タイプを採用します。
- デーモン(Daemon)方式それは何ですか？
- バックグラウンドで動作するサービス/アプリケーションがユーザーの介入なしに認証/認可を行う方式です。
- サーバー間通信または自動化作業で主に使用します。
- クライアント資格情報(Client Credential)フロー
- アプリ自体のClient ID / Client Secretを利用してトークンを取得します。
- ユーザーのログイン情報は必要ありません。
- 結果的にユーザー自身が所有者として文書を変換したり、所有権を委譲することはできません。
対応策
- ラベルポリシーで所有者に関係なくラベルを変更できるように設定できます。
- このポリシーを有効にすると、アプリ所有文書も正常にラベル変更が可能です。
参考文書
- MSAL 認証フローの整理
- [SHIELD DRM仕様書](https://devdocsy.softcamp.co.kr/SHIELDDRM/summary/specification/#注意事項)
イベントリシーバー
Q2. 新しい SharePoint サイトを作成する際に、イベント レシーバーの自動インストールを防ぐことはできますか？
はい、可能です。
その動作は SHIELD DRM の**"リアルタイム検知"**機能で制御します。
- リアルタイム検出 ON: 新しい OneDrive/SharePoint サイトが作成されると、イベント レシーバーを自動インストールします。
- リアルタイム検出 OFF: 新しいサイトが作成されてもイベントリシーバーが自動的にインストールされず, 管理者が直接インストールする必要があります。
したがって、新しいサイトの自動インストールを希望しない場合は**"リアルタイム検出"をOFF**に設定すれば大丈夫です。
設定位置
- SHIELD DRM 管理者ページ →[連動管理] → イベントリシーバーメニュー内のポリシー（オプション）領域で設定します。
- ※ 正確なメニュー名/パスは運用中の管理者画面のバージョンによって異なる場合があるため、実際の画面に基づいて最終確認が必要です。
Q3. 特定のサイトだけイベントリシーバーを削除し、自動再インストールされないようにすることはできますか？
お問い合わせの形 — つまり**"特定のサイトのみイベントリシーバーを削除した後、そのサイトを自動再インストール対象から（永久に）除外"する機能は現在提供されていません。**
- イベントリシーバーの削除自体は管理者ページで実行できますが、
- "特定のサイトを再インストール対象から除外"状態で固定するサイト別例外設定はありません。
- Q2の**"リアルタイム検知"は新規作成サイト全体**ON/OFF設定であり、特定のサイトのみ選択的に除外する用途ではありません。
したがって、「特定の一部サイト対象削除 + 自動再インストール除外」という要件は、現在の機能では満たされていません。
Azure アプリ構成
Q4. SHIELD DRM Azure アプリが6つある理由と各アプリの役割は何ですか？
6つのアプリはアプリごとに異なる役割を果たしません。
SHIELDRM_MainとSub1~5は機能的に同じアプリであり、アプリを6つに分けた理由はMicrosoft Graph APIのスロットリング（呼び出し制限）を分散するためです。
アプリ構成
- Security365 (別途 1個アプリ): Softcampサービスを使用する権限を持つ共通アプリです。
- SHIELDRM アプリ (6個 = Main + Sub1~Sub5): SHIELD DRMサービスを使用するための権限を持つアプリです。(管理者画面に表示される6つのアプリがこれに該当)
6つで運営する理由 (スロットリング分散)
- Microsoft Graph(M365 API)にはスロットリング(スロットリング)があります。サービスの可用性・安定性のために、一定時間内の呼び出し量を制限し、上限を超えた場合は該当アプリの追加リクエストを一定時間制限してHTTP 429(Too Many Requests)を返し、応答ヘッダーに推奨待機時間を含めて送信します。
- この限度のかなりの部分がアプリ（アプリケーション）単位に適用されます。
- したがって、呼び出しを単一のアプリに集中させず、複数のアプリに分散させることで、各アプリが別々の制限を持つことになり、単一のアプリが制限に引っかかる可能性を低くすることができます。
- 現在、SHIELDRMアプリを6つ（Main + Sub1〜5）運営しているのは、このスロットリングを緩和するための構成です。