Microsoft Information Protection SDK - 캐시 스토리지

아티클
10/18/2023

MIP SDK는 SDK 캐시 스토리지를 유지 관리하기 위한 SQLite3 데이터베이스를 구현합니다. Microsoft Information Protection SDK 버전 1.3 이전에는 디스크 및 메모리의 두 가지 유형의 캐시 상태 스토리지만 지원되었습니다. 이러한 두 유형 모두 특정 데이터, 특히 보호된 콘텐츠 및 정책 정보에 대한 라이선스를 일반 텍스트로 저장했습니다.

SDK의 보안 상태를 개선하기 위해 플랫폼별 암호화 API를 사용하여 데이터베이스 및 해당 콘텐츠를 보호하는 두 번째 유형의 디스크 캐시에 대한 지원이 추가되었습니다.

애플리케이션은 프로필 또는 개체의 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 이상	Windows 7은 CacheStorageType::OnDisk만 지원합니다.
macOS	High Sierra 이상
Ubuntu Linux	16.04 이상	필수 및 `LinuxEncryptedCache` 기능 플래그입니다`SecretService`.
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 아래에 정의된 경로에 저장됩니다.

보호 데이터베이스

테이블	목적	Encrypted
AuthInfoStore	인증 챌린지 세부 정보를 저장합니다.	아니요
ConsentStore	각 엔진에 대한 동의 결과를 저장합니다.	아니요
DnsInfoStore	보호 작업에 대한 DNS 조회 결과를 저장합니다.	아니요
EngineStore	엔진 세부 정보, 연결된 사용자 및 사용자 지정 클라이언트 데이터를 저장합니다.	아니요
KeyStore	각 엔진에 대한 대칭 암호화 키를 저장합니다.	예
LicenseStore	저장소는 이전에 암호 해독된 데이터에 대한 라이선스 정보를 사용합니다.	예
SdInfoStore	서비스 검색 결과를 저장합니다.	아니요

참고 항목

LicenseStore 캐시를 사용하려면 보호 엔진 또는 파일 엔진 에서 ID를 설정해야 합니다.

정책 데이터베이스

테이블	목적	Encrypted
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에서는 인증된 작업을 수행하는 각 사용자에 대해 엔진이 만들어집니다. 엔진은 인증된 ID를 대신하여 수행되는 모든 작업에 대한 인터페이스를 제공합니다. 프로필 및 엔진 개념에서 설명한 대로 FileEngine, PolicyEngine 또는 ProtectionEngine에는 각각 두 가지 상태 CREATED 와 LOADED. SDK 작업을 수행할 수 있도록 엔진을 만들고 로드해야 합니다. 엔진이 사용되지 않는 경우 SDK는 엔진을 캐시하고 사용 가능한 리소스에 따라 가능한 한 오랫동안 CREATED 상태를 유지합니다. 각 SDK의 프로필 클래스는 이를 명시적으로 달성하는 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를 올바르게 설정하는 방법을 이해하기 위해 프로필 및 엔진 개체 개념에 대해 자세히 알아봅니다.