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 から、以下のストレージ キャッシュの種類を使用できます。
| Type | 目的 |
|---|---|
| InMemory | アプリケーションのメモリ内にストレージ キャッシュを保持します。 |
| OnDisk | 設定オブジェクトで指定されたディレクトリに、ディスク上のデータベースを格納します。 データベースはプレーンテキストで格納されます。 |
| OnDiskEncrypted | 設定オブジェクトで指定されたディレクトリに、ディスク上のデータベースを格納します。 データベースは、OS 固有の API を使用して暗号化されます。 |
アプリケーションによって生成される各エンジンによって、新しい暗号化キーが生成されます。
キャッシュ ストレージは、mip::CacheStorageType 列挙型を介して、プロファイル設定オブジェクトのいずれかを使用して設定されます。
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 8.1 以降 | Windows 7 では CacheStorageType::OnDisk だけがサポートされます |
| macOS | ハイシエラ以降 | |
| Ubuntu Linux | 16.04 以降 | SecretService および LinuxEncryptedCache 機能フラグが必要です。 |
| Android | Android 7.0 以降 | |
| iOS | サポートされているすべてのバージョン |
MIP SDK は他の Linux ディストリビューションをサポートしますが、RedHat Enterprise Linux、CentOS、または Debian ではキャッシュ暗号化をテストしていません。
Note
Linux でキャッシュ ストレージを有効にする機能フラグは、mip::MipConfiguration::SetFeatureSettings() を使用して設定します
キャッシュ ストレージ データベース テーブル
MIP SDK では、キャッシュ用に 2 つのデータベースが保持されます。 1 つは保護 SDK 用で、保護状態の詳細を保持します。 もう 1 つはポリシー SDK 用で、ポリシーの詳細とサービス情報を保持するためのものです。 どちらも、mip\mip.policies.sqlite3 と mip\mip.protection.sqlite3 の配下の設定オブジェクトで定義されているパスに格納されます。
保護データベース
| テーブル | 目的 | Encrypted |
|---|---|---|
| AuthInfoStore | 認証チャレンジの詳細を格納します。 | いいえ |
| ConsentStore | 各エンジンの同意結果を格納します。 | いいえ |
| DnsInfoStore | 保護操作の DNS 参照結果を格納します | いいえ |
| EngineStore | エンジンの詳細、関連付けられているユーザー、およびカスタム クライアント データを格納します | いいえ |
| KeyStore | 各エンジンの対称暗号化キーを格納します。 | はい |
| LicenseStore | 以前に暗号化解除されたデータのライセンス情報を格納します。 | はい |
| SdInfoStore | サービス検出の結果を格納します。 | いいえ |
ポリシー データベース
| テーブル | 目的 | Encrypted |
|---|---|---|
| KeyStore | 各エンジンの対称暗号化キーを格納します。 | はい |
| ポリシー | 各ユーザーのラベル ポリシー情報を格納します。 | はい |
| PoliciesUrl | 特定ユーザーのバックエンド ポリシー サービス URL を格納します。 | いいえ |
| 感度 | 特定のユーザー ポリシーの分類ルールを格納します。 | はい |
| SensitivityUrls | 特定ユーザーのバックエンド感度ポリシー サービス URL を格納します。 | いいえ |
データベースのサイズに関する注意事項
データベースのサイズは、キャッシュに追加されているエンジンの数とキャッシュされている保護ライセンスの数という 2 つの要因によって異なります。 MIP SDK 1.3 では、有効期限が切れたときにライセンス キャッシュをクリーンアップするメカニズムはありません。 必要以上に大きくなったときにキャッシュを削除するには、外部プロセスが必要になります。
データベースのが拡大する最も大きな要因となるのは、保護ライセンス キャッシュです。 サービスのラウンド トリップによってアプリケーションのパフォーマンスが影響を受けない、またはキャッシュが大きくなりすぎる可能性があるといった理由でライセンス キャッシュが不要な場合は、ライセンス キャッシュを無効にすることができます。 これを実行するには、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 で生成することもできます。 エンジンの作成時にエンジン設定オブジェクトを使用して一意識別子が指定され、上記の説明のように 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 エンジン ID を適切に設定して MIP SDK キャッシュを適切に使用する方法を理解するために、プロファイルとエンジンのオブジェクトの概念について学習します。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示