次の方法で共有

Microsoft Information Protection SDK - プロファイルとエンジン オブジェクトの概念

  • [アーティクル]

プロファイル

MipContext は SDK 固有の設定を格納するためのクラスであり、プロファイルは MIP SDK における MIP のすべてのラベル付けおよび保護固有の操作のルート クラスです。 3 つの API セットを使用する前に、クライアント アプリケーションでプロファイルを作成する必要があります。 それ以降のすべての操作は、プロファイルまたはプロファイルに "追加された" 他のオブジェクトによって実行されます。 プロファイル オブジェクトはプロセスごとに 1 つだけ使用することをお勧めします。 複数作成すると、予期しない動作が発生する可能性があります。

MIP SDK のプロファイルには、3 つの種類があります。

利用する側のアプリケーションで使用されている API により、使用する必要があるプロファイル クラスが決定されます。

プロファイル自体は、次の機能を提供します。

  • 状態をメモリに読み込むか、ディスクに保存するか、およびディスクに保存する場合は暗号化する必要があるかどうかを定義します。
  • 同意操作に使用する必要がある mip::ConsentDelegate を定義します。
  • プロファイル操作の非同期コールバックに使用される mip::FileProfile::Observer の実装を定義します。

プロファイルの設定

  • MipContext: アプリケーション情報、状態パスなどを格納するために初期化された MipContext オブジェクト。
  • CacheStorageType: 状態を格納する方法 (メモリ内、ディスク上、またはディスク上かつ暗号化) を定義します。
  • consentDelegate: クラス mip::ConsentDelegate の共有ポインター。
  • observer: プロファイル Observer 実装への共有ポインター (PolicyProfile、ProtectionProfile および FileProfile 内)。
  • applicationInfo: mip::ApplicationInfo オブジェクト。 SDK を使用しているアプリケーションに関する情報。これは、Microsoft Entra のアプリケーション登録の ID および名前と一致します。

エンジン

File、Profile、Protection の各 SDK では、エンジンによって、特定の ID に代わって実行される操作へのインターフェイスが提供されます。 アプリケーションにサインインするユーザーまたはサービス プリンシパルごとに、1 つのエンジンが Profile オブジェクトに追加されます。 mip::ProtectionSettings と、ファイルまたは保護ハンドラーを使用して、委任された操作を実行できます。 詳細については、FileHandler の概念の保護設定に関するセクションを参照してください。

SDK には、API ごとに 1 つずつ、3 つのエンジン クラスがあります。 次の一覧は、エンジン クラスと、それぞれに関連付けられているいくつかの関数を示しています。

  • mip::ProtectionEngine
  • mip::PolicyEngine
    • ListSensitivityLabels(): 読み込まれたエンジンのラベルの一覧を取得します。
    • GetSensitivityLabel(): 既存のコンテンツからラベルを取得します。
    • ComputeActions(): ラベル ID と省略可能なメタデータを指定して、特定の項目に対して発生しなければならないアクションの一覧を返します。
  • mip::FileEngine
    • ListSensitivityLabels(): 読み込まれたエンジンのラベルの一覧を取得します。
    • CreateFileHandler(): 固有のファイルまたはストリームに対して mip::FileHandler を作成します。

エンジンを作成するには、作成するエンジンの種類の設定を含む特定のエンジン設定オブジェクトを渡す必要があります。 開発者は、設定オブジェクトを使用して、エンジン識別子、mip::AuthDelegate の実装、ロケール、カスタム設定の詳細、および他の API 固有の詳細を指定できます。

エンジン状態

エンジンは、次の 2 つの状態のいずれかになる場合があります。

  • CREATED: [作成済み] は、必要なバックエンド サービスを呼び出した後、SDK に十分なローカル状態情報があることを示します。
  • LOADED: SDK は、エンジンが動作するために必要なデータ構造を構築しました。

操作を実行するには、エンジンを作成して読み込む必要があります。 Profile クラスは、エンジン管理方法である AddEngineAsync、DeleteEngineAsync およひ UnloadEngineAsync を公開します。

次の表では、考えられるエンジンの状態とその状態を変更できるメソッドについて説明します。

エンジンの状態 NONE CREATED ロード完了
NONE AddEngineAsync
CREATED DeleteEngineAsync AddEngineAsync
ロード完了 DeleteEngineAsync UnloadEngineAsync

エンジン ID

各エンジンには、すべてのエンジン管理操作で使用される固有の識別子である id があります。 アプリケーションで id を指定できます。アプリケーションで指定しない場合は、SDK で生成できます。 その他のすべてのエンジン プロパティ (ID 情報の Email アドレスなど) は、SDK の不透明ペイロードです。 SDK は、他のプロパティを一意に保つロジックや、他の制約を適用するロジックを実行しません。

重要

**ベスト プラクティスとして、ユーザーに固有のエンジン ID を使用し、ユーザーが SDK で操作を実行するたびにそれを使用します。 ユーザーまたはサービスに対して既存の一意の engineId を指定しないと、サービスへの余分なラウンド トリップが発生します。 これらのサービス ラウンド トリップにより、パフォーマンスが低下し、調整が発生する可能性があります。 **

// Create the FileEngineSettings object
FileEngine::Settings engineSettings(mip::Identity(mUsername), // This will be the engine ID. UPN, email address, or other unique user identifiers are recommended. 
													          mAuthDelegate,            // authDelegate implementation 
													          "",                       // ClientData
													          "en-US",                  // Client Locale
                                    false);                   // Load Sensitive Information Types

エンジン管理方法

前述のとおり、SDK には、AddEngineAsync、DeleteEngineAsync、UnloadEngineAsync という 3 つのエンジン管理メソッドがあります。

AddEngineAsync

このメソッドは、既存のエンジンを読み込みます。ローカル状態にまだ存在しない場合は作成します。

アプリケーションが FileEngineSettings で id を指定しない場合は、AddEngineAsync によって新しい id が生成されます。 その後、その id を持つエンジンがローカル ストレージ キャッシュに既に存在するかどうかが確認されます。 その場合は、そのエンジンが読み込まれます。 エンジンがローカル キャッシュに存在 "しない" 場合、必要な API とバックエンド サービスを呼び出すことで、新しいエンジンが作成されます。

どちらの場合も、メソッドが成功すると、エンジンが読み込まれ、使用できる状態になります。

DeleteEngineAsync

指定した id でエンジンを削除します。 エンジンのすべてのトレースは、ローカル キャッシュから削除されます。

UnloadEngineAsync

指定した id でエンジンのメモリ内データ構造をアンロードします。 このエンジンのローカル状態はそのままで、AddEngineAsync で再ロードできます。

このメソッドでは、すぐに使用する見込みのないエンジンをアンロードすることで、アプリケーションでメモリ使用率について適切に判断できます。

次のステップ