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 と名前と一致するアプリケーションに関する情報。

エンジン

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

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

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

エンジンを作成するには、作成するエンジンの種類の設定を含む特定のエンジン設定オブジェクトを渡します。 settings オブジェクトを使用すると、開発者はエンジン識別子、 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 情報のメール アドレスなど、他のすべてのエンジン プロパティは、SDK の不透明なペイロードです。 SDK では、他のプロパティを一意に保つロジックや、他の制約を適用するロジックは実行されません。

重要

ユーザーに固有のエンジン ID を使用し、ユーザーが SDK で操作を実行するたびにそのエンジン ID を使用します。 ユーザーまたはサービスに対して既存の一意のエンジン ID を指定しない場合、SDK は追加のサービス ラウンド トリップを行います。 これらのサービス間の往復通信により、パフォーマンスの低下やスロットリングが発生する可能性があります。

// 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

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

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

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

DeleteEngineAsync

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

UnloadEngineAsync

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

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

次のステップ

  • 最終更新: