Microsoft 信息保护 SDK - 缓存存储

项目
07/24/2024

MIP SDK 执行 SQLite3 数据库来维护 SDK 缓存存储。在 Microsoft 信息保护 SDK 版本 1.3 之前，仅支持两种类型的缓存状态存储：磁盘上和内存中存储。这两种类型都以纯文本形式存储了某些数据，特别是受保护内容和策略信息的许可证。

为了改善 SDK 的安全态势，我们添加了对第二种类型的磁盘上缓存的支持，该缓存使用特定于平台的加密 API 来保护数据库及其内容。

应用程序在将配置文件作为 FileProfileSettings、PolicyProfileSettings 或 ProtectionProfileSettings 对象的一部分加载时定义缓存类型。缓存类型在配置文件的生命周期内是静态的。更改为不同类型的缓存存储类型需要销毁现有配置文件并创建一个新的配置文件。

缓存存储类型

从 MIP SDK 版本 1.3 开始，以下存储缓存类型可用。

类型	用途
InMemory	在应用程序的内存中维护存储缓存。
OnDisk	将磁盘上的数据库存储在设置对象中提供的目录中。数据库以纯文本形式存储。
OnDiskEncrypted	将磁盘上的数据库存储在设置对象中提供的目录中。数据库使用特定于操作系统的 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 及更高版本	Windows 7 仅支持 CacheStorageType::OnDisk
macOS	High Sierra 及更高版本
Ubuntu Linux	16.04 及更高版本	需要 `SecretService` 和 `LinuxEncryptedCache` 功能标志。
Android	Android 7.0 或更高版本
iOS	所有支持的版本

虽然 MIP SDK 确实支持其他 Linux 发行版，但我们没有在 RedHat Enterprise Linux、CentOS 或 Debian 上测试缓存加密。

注意

在 Linux 上启用缓存存储的功能标志是通过 mip::MipConfiguration::SetFeatureSettings() 设置的

缓存存储数据库表

MIP SDK 维护两个缓存数据库。一种用于保护 SDK，并维护保护状态详细信息。另一种用于策略 SDK，并维护策略详细信息和服务信息。两者都存储在设置对象（位于 mip\mip.policies.sqlite3 和 mip\mip.protection.sqlite3 下方）中定义的路径中。

注意

MIP SDK 不能保证其缓存的不同版本之间的兼容性。建议先清除 mip\ 目录中的所有文件，或者从默认设置更改的任何替代目录，然后再将应用程序升级到新版本的 MIP SDK。

保护数据库

表	用途	已加密
AuthInfoStore	存储身份验证挑战信息信息。	否
ConsentStore	存储每个引擎的同意结果。	否
DnsInfoStore	存储保护操作的 DNS 查找结果	否
EngineStore	存储引擎详细信息、关联用户和自定义客户端数据	否
KeyStore	存储每个引擎的对称加密密钥。	是
LicenseStore	商店将许可证信息用于先前解密的数据。	是
SdInfoStore	存储服务发现结果。	否

注意

LicenseStore 缓存要求在保护引擎或文件引擎上设置标识。

策略数据库

表	用途	已加密
KeyStore	存储每个引擎的对称加密密钥。	是
策略	存储每个用户的标签策略信息。	是
PoliciesUrl	存储特定用户的后端策略服务 URL。	否
敏感性	存储特定用户策略的分类规则。	是
SensitivityUrls	存储特定用户的后端敏感度策略服务 URL。	否

数据库大小注意事项

数据库大小取决于两个因素：添加到缓存的引擎数量和已缓存的保护许可证数量。从 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 中，为执行任何经过身份验证的操作的每个用户创建一个引擎。引擎为代表经身份验证的标识执行的所有操作提供接口。如配置文件和引擎概念中所述，FileEngine、PolicyEngine 或 ProtectionEngine 各自有两个状态CREATED和 LOADED。需要创建和加载引擎才能执行 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 引擎 ID 来正确利用 MIP SDK 缓存。

通过