Microsoft Information Protection SDK - キャッシュストレージ

MIP SDK は、SDK キャッシュストレージを保持するための SQLite3 データベースを実装しています。 Microsoft Information Protection SDK のバージョン 1.3 より前では、2 種類のキャッシュ状態ストレージ (ディスク上とメモリ内) しかサポートされていませんでした。これらの種類はどちらも、特定のデータ (特に保護されたコンテンツとポリシー情報のライセンス) をプレーンテキストで格納していました。

SDK のセキュリティ体制を改善するために、プラットフォーム固有の暗号化 API を使用してデータベースとそのコンテンツを保護する 2 つ目の種類のオンディスクキャッシュのサポートを追加しました。

アプリケーションでは、FileProfileSettings、PolicyProfileSettings、または ProtectionProfileSettings オブジェクトの一部としてプロファイルを読み込むときにキャッシュの種類を定義します。キャッシュの種類は、プロファイルが有効な間は静的です。別のキャッシュストレージの種類に変更するには、既存のプロファイルを破棄して、新しいプロファイルを作成する必要があります。

キャッシュストレージの種類

MIP SDK リリース 1.3 から、以下のストレージキャッシュの種類を使用できます。

タイプ	目的
InMemory	アプリケーションのメモリ内にストレージキャッシュを保持します。
OnDisk	設定オブジェクトで指定されたディレクトリに、ディスク上のデータベースを格納します。データベースはプレーンテキストで格納されます。
OnDiskEncrypted	設定オブジェクトで指定されたディレクトリに、ディスク上のデータベースを格納します。データベースは、OS 固有の API を使用して暗号化されます。

アプリケーションによって生成される各エンジンによって、新しい暗号化キーが生成されます。

mip::CacheStorageType列挙型を使用して、プロファイル設定オブジェクトの 1 つにキャッシュストレージを設定します。

FileProfile::Settings profileSettings(mMipContext,
    mip::CacheStorageType::OnDiskEncrypted, // Define the storage type to use.
    mAuthDelegate,
    std::make_shared<sample::consent::ConsentDelegateImpl>(),
    std::make_shared<FileProfileObserver>());

それぞれの種類を使用するタイミング

キャッシュストレージは、以前に復号化された情報へのオフラインアクセスを維持し、データが以前に使用されたときの復号化操作のパフォーマンスを確保するために重要です。

インメモリストレージ: このストレージの種類は、サービスの再起動後はポリシーまたはライセンスキャッシュ情報を保持する必要がない長期間にわたるプロセスに使用します。
ディスク上: このストレージの種類は、プロセスが頻繁に停止して開始される可能性があるが、再起動の間にポリシー、ライセンス、およびサービス検出キャッシュを維持する必要があるアプリケーションに使用します。このストレージキャッシュの種類はプレーンテキストなので、ユーザーが状態ストレージにアクセスできないサーバーワークロードに適しています。たとえば、サーバーで実行されている Windows サービスまたは Linux デーモン、またはサービス管理者だけが状態データにアクセスできる SaaS アプリケーションなどです。
ディスクと暗号化時: プロセスが頻繁に停止して開始する可能性があるが、再起動の間にポリシー、ライセンス、およびサービス検出キャッシュを維持する必要があるアプリケーションには、このストレージの種類を使用します。このストレージキャッシュは暗号化されているため、ユーザーが状態データベースを参照して検出する可能性があるワークステーションアプリケーションに適しています。暗号化は、ユーザーがポリシーコンテンツや保護ライセンスコンテンツにプレーンテキストでアクセスできないようにするのに役立ちます。いずれの場合も、データはユーザーがアクセスできるキーで暗号化されます。高い技術を持つ敵対者は、最小限の労力でキャッシュの暗号化を解除できますが、これによって改ざんや閲覧が防止されます。

暗号化でサポートされているプラットフォーム

プラットフォーム	バージョン	メモ
Microsoft Windows	Windows 11、Windows Server のサポートバージョン
macOS	ハイシエラ以降
Ubuntu Linux	22.04 以降	`SecretService` および `LinuxEncryptedCache` 機能フラグが必要です。
Android	Android 7.0 以降
iOS	サポートされているすべてのバージョン

MIP SDK は他の Linux ディストリビューションをサポートしますが、RedHat Enterprise Linux、CentOS、または Debian ではキャッシュ暗号化をテストしていません。

メモ

機能フラグを設定して、Linux でキャッシュストレージを有効にします。 mip::MipConfiguration::SetFeatureSettings()

キャッシュストレージデータベーステーブル

MIP SDK では、キャッシュ用に 2 つのデータベースが保持されます。 1 つは保護 SDK 用で、保護状態の詳細を保持します。もう 1 つはポリシー SDK 用で、ポリシーの詳細とサービス情報を保持するためのものです。どちらも、mip\mip.policies.sqlite3 と mip\mip.protection.sqlite3 の配下の設定オブジェクトで定義されているパスに格納されます。

メモ

MIP SDK では、キャッシュの異なるバージョン間の互換性は保証されません。アプリケーションを新しいバージョンの MIP SDK にアップグレードする前に、mip\ ディレクトリ内のすべてのファイル、または既定の設定から変更された代替ディレクトリをすべてクリアします。

保護データベース

テーブル	目的	暗号化された
AuthInfoStore	認証チャレンジの詳細を格納します。	いいえ
ConsentStore	各エンジンの同意結果を格納します。	いいえ
DnsInfoStore	保護操作の DNS 参照結果を格納します	いいえ
EngineStore (エンジンストア)	エンジンの詳細、関連付けられているユーザー、およびカスタムクライアントデータを格納します	いいえ
KeyStore	各エンジンの対称暗号化キーを格納します。	はい
ライセンスストア	ストアは以前に暗号化解除されたデータのライセンス情報を使用します。	はい
SdInfoStore	サービス検出の結果を格納します。	いいえ

メモ

LicenseStore キャッシュでは、保護エンジンまたはファイルエンジンに ID を設定する必要があります。

ポリシーデータベース

テーブル	目的	暗号化された
KeyStore	各エンジンの対称暗号化キーを格納します。	はい
ポリシー	各ユーザーのラベルポリシー情報を格納します。	はい
ポリシーURL	特定ユーザーのバックエンドポリシーサービス URL を格納します。	いいえ
感度	特定のユーザーポリシーの分類ルールを格納します。	はい
SensitivityUrls	特定ユーザーのバックエンド感度ポリシーサービス URL を格納します。	いいえ

データベースのサイズに関する注意事項

データベースのサイズは、キャッシュに追加されるエンジンの数と、キャッシュされた保護ライセンスの数という 2 つの要因によって異なります。 MIP SDK 1.18 以降では、ProtectionEngineでDeleteStoredData()を使用して、キャッシュされたエンジンデータをプログラムで削除できます。以前のバージョンでは、キャッシュが必要以上に大きくなる場合は、キャッシュを削除するために外部プロセスが必要になる場合があります。

データベースのが拡大する最も大きな要因となるのは、保護ライセンスキャッシュです。サービスラウンドトリップがアプリケーションのパフォーマンスに影響を与えないか、キャッシュが大きくなりすぎる可能性があるため、ライセンスキャッシュが必要ない場合は、ライセンスキャッシュを無効にすることができます。これを行うには、FileProfile::Settings オブジェクトのCanCacheLicensesを false に設定します。

FileProfile::Settings profileSettings(mMipContext,
    mip::CacheStorageType::OnDiskEncrypted,
    mAuthDelegate,
    std::make_shared<sample::consent::ConsentDelegateImpl>(),
    std::make_shared<FileProfileObserver>());

profileSettings.SetCanCacheLicenses(false);

キャッシュエンジン

MIP SDK では、認証された操作を実行するユーザーごとにエンジンが作成されます。エンジンは、認証された ID に代わって実行されるすべての操作のインターフェイスを提供します。「プロファイルとエンジンの概念」で説明したように、FileEngine、PolicyEngine、または ProtectionEngine にはそれぞれ、CREATED と LOADED という 2 つの状態があります。 SDK 操作を実行できるようにするには、エンジンを作成して読み込む必要があります。エンジンが使用されていない場合は、使用可能なリソースに応じて、SDK によってエンジンがキャッシュされ、可能な限り CREATED の状態が維持されます。それぞれの SDK の profile クラスには、これを明示的に実現するメソッド UnloadEngineAsync も用意されています。

各エンジンには、すべてのエンジン管理操作で使用される一意識別子 id があります。クライアントアプリケーションは、ID を明示的に指定することも、アプリケーションによって提供されていない場合は SDK で ID を生成することもできます。エンジンの作成時にエンジン設定オブジェクトを使用して一意識別子が指定され、上記の説明のように API プロファイルでキャッシュが有効になっている場合、ユーザーが SDK で操作を実行するたびに同じエンジンを使用できます。 [mip::FileEngine](./concept-profile-engine-file-engine-cpp.md#create-file-engine-settings)、[mip::PolicyEngine](./concept-profile-engine-policy-engine-cpp.md#implementation-create-policy-engine-settings) を作成するためのコードスニペットに従ってください。

既存の engineId を指定しないと、ポリシーをフェッチするための追加のサービスラウンドトリップが発生し、既存のエンジン用に既にキャッシュされている可能性のあるライセンスがフェッチされます。エンジン ID をキャッシュすることで、SDK は、以前に暗号化が解除された情報にオフラインでアクセスできるようになり、一般的なパフォーマンスが向上します。

次のステップ

次に、MIP SDK キャッシュを適切に使用するように MIP エンジン ID を適切に設定する方法を理解するために、プロファイルオブジェクトとエンジンオブジェクトの概念について学習します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-09-18