Zestaw SDK usługi Microsoft Information Protection — magazyn pamięci podręcznej

Artykuł
10/18/2023

Zestaw MIP SDK implementuje bazę danych SQLite3 do obsługi magazynu pamięci podręcznej zestawu SDK. Przed wersją 1.3 zestawu Microsoft Information Protection SDK obsługiwane były tylko dwa typy magazynu stanu pamięci podręcznej: na dysku i w pamięci. Oba te typy przechowywane niektóre dane, w szczególności licencje na chronioną zawartość i informacje o zasadach, w postaci zwykłego tekstu.

Aby poprawić stan zabezpieczeń zestawu SDK, dodaliśmy obsługę drugiego typu pamięci podręcznej dysku, który używa interfejsów API kryptograficznych specyficznych dla platformy do ochrony bazy danych i jej zawartości.

Aplikacja definiuje typ pamięci podręcznej podczas ładowania profilu w ramach FileProfileSettingsobiektów , PolicyProfileSettingslub ProtectionProfileSettings . Typ pamięci podręcznej jest statyczny dla okresu życia profilu. Zmiana na inny typ magazynu pamięci podręcznej wymaga zniszczenia istniejącego profilu i utworzenia nowego.

Typy magazynu pamięci podręcznej

Począwszy od wersji 1.3 zestawu MIP SDK, dostępne są następujące typy pamięci podręcznej magazynu.

Typ	Cel
InMemory	Przechowuje pamięć podręczną magazynu w pamięci w aplikacji.
OnDisk	Przechowuje bazę danych na dysku w katalogu podanym w obiekcie ustawień. Baza danych jest przechowywana w postaci zwykłego tekstu.
OnDiskEncrypted	Przechowuje bazę danych na dysku w katalogu podanym w obiekcie ustawień. Baza danych jest szyfrowana przy użyciu interfejsów API specyficznych dla systemu operacyjnego.

Każdy aparat wygenerowany przez aplikację generuje nowy klucz szyfrowania.

Magazyn pamięci podręcznej jest ustawiany za pośrednictwem jednego z obiektów ustawień profilu za pośrednictwem wyliczenia 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>());

Kiedy należy używać każdego typu

Magazyn pamięci podręcznej jest ważny w przypadku utrzymania dostępu w trybie offline do wcześniej odszyfrowanych informacji i zapewnienia wydajności operacji odszyfrowywania, gdy dane były wcześniej używane.

W magazynie pamięci: tego typu magazynu należy używać w przypadku długotrwałych procesów, w których utrwalanie informacji o zasadach lub pamięci podręcznej licencji między ponownymi uruchomieniami usługi nie jest wymagane.
Na dysku: użyj tego typu magazynu dla aplikacji, w których procesy mogą często zatrzymywać i uruchamiać, ale muszą obsługiwać zasady, licencje i pamięć podręczną odnajdywania usług w ramach ponownych uruchomień. Ten typ pamięci podręcznej magazynu jest zwykły, dlatego lepiej nadaje się do obciążeń serwera, w których użytkownicy nie będą mieli dostępu do magazynu stanu. Przykładem może być usługa systemu Windows lub demon systemu Linux uruchomiony na serwerze lub aplikacja SaaS, w której tylko administratorzy usługi mieliby dostęp do danych stanu.
Na dysku i zaszyfrowaniu: użyj tego typu magazynu dla aplikacji, w których procesy mogą często zatrzymywać i uruchamiać, ale muszą obsługiwać zasady, licencje i pamięć podręczną odnajdywania usług w ramach ponownych uruchomień. Ta pamięć podręczna magazynu jest szyfrowana, dlatego lepiej nadaje się do aplikacji stacji roboczych, w których użytkownik może przeglądać i odnajdywać bazę danych stanu. Szyfrowanie pomaga zagwarantować, że użytkownicy nie będą mieli dostępu do zawartości zasad ani zawartości licencji ochrony w postaci zwykłego tekstu. Należy pamiętać, że we wszystkich przypadkach dane są szyfrowane przy użyciu kluczy, do których użytkownik może mieć dostęp. Wykwalifikowanych przeciwników jest w stanie odszyfrować pamięć podręczną przy minimalnym wysiłku, ale zapobiega to manipulowaniu i przeglądaniu.

Obsługiwane platformy szyfrowania

Platforma	Wersja	Uwagi
Microsoft Windows	Windows 8 i nowsze	System Windows 7 obsługuje tylko funkcję CacheStorageType::OnDisk
macOS	High Sierra i nowsze
Ubuntu Linux	16.04 i nowsze	Wymaga `SecretService` i `LinuxEncryptedCache` flaga funkcji.
Android	Android 7.0 lub nowszy
iOS	Wszystkie obsługiwane wersje

Chociaż zestaw MIP SDK obsługuje inne dystrybucje systemu Linux, nie przetestowaliśmy szyfrowania pamięci podręcznej w systemie RedHat Enterprise Linux, CentOS lub Debian.

Uwaga

Flaga funkcji umożliwiająca włączenie magazynu pamięci podręcznej w systemie Linux jest ustawiona za pomocą polecenia mip::MipConfiguration::SetFeatureSettings()

Buforowanie tabel bazy danych magazynu

Zestaw MIP SDK obsługuje dwie bazy danych na potrzeby pamięci podręcznej. Jednym z nich jest zestaw SDK ochrony i utrzymywanie szczegółów stanu ochrony. Druga dotyczy zestawów SDK zasad i obsługi szczegółów zasad i informacji o usłudze. Oba są przechowywane w ścieżce zdefiniowanej w obiekcie settings w folderze mip\mip.policies.sqlite3 i mip\mip.protection.sqlite3.

Baza danych ochrony

Table	Purpose	Zaszyfrowane
AuthInfoStore	Przechowuje szczegóły wyzwania uwierzytelniania.	Nie.
ConsentStore	Przechowuje wyniki zgody dla każdego aparatu.	Nie.
DnsInfoStore	Przechowuje wyniki wyszukiwania DNS dla operacji ochrony	Nie.
EngineStore	Przechowuje szczegóły aparatu, skojarzonego użytkownika i niestandardowe dane klienta	Nie.
Keystore	Przechowuje symetryczne klucze szyfrowania dla każdego aparatu.	Tak
LicenseStore	Magazyny używają informacji o licencji dla wcześniej odszyfrowanych danych.	Tak
SdInfoStore	Przechowuje wyniki odnajdywania usług.	Nie.

Uwaga

Pamięć podręczna LicenseStore wymaga ustawienia tożsamości dla aparatu ochrony lub aparatu plików.

Baza danych zasad

Table	Purpose	Zaszyfrowane
Keystore	Przechowuje symetryczne klucze szyfrowania dla każdego aparatu.	Tak
Zasady	Przechowuje informacje o zasadach etykiet dla każdego użytkownika.	Tak
ZasadyUrl	Przechowuje adres URL usługi zasad zaplecza dla określonego użytkownika.	Nie.
Czułość	Przechowuje reguły klasyfikacji dla określonych zasad użytkownika.	Tak
WażnośćUrls	Przechowuje adres URL usługi zasad poufności zaplecza dla określonego użytkownika.	Nie.

Zagadnienia dotyczące rozmiaru bazy danych

Rozmiar bazy danych zależy od dwóch czynników: ilość aparatów dodawanych do pamięci podręcznej i ilość licencji ochrony, które zostały buforowane. Od zestawu MIP SDK 1.3 nie ma mechanizmu czyszczenia pamięci podręcznej licencji po wygaśnięciu. Jeśli pamięć podręczna będzie większa niż jest wymagana, konieczne będzie usunięcie zewnętrznej pamięci podręcznej.

Najważniejszym czynnikiem przyczyniającym się do wzrostu bazy danych będzie pamięć podręczna licencji ochrony. Jeśli buforowanie licencjonowania nie jest wymagane, ponieważ runda usługi nie wpłynie na wydajność aplikacji lub pamięć podręczna może być zbyt duża, pamięć podręczna licencji może zostać wyłączona. Można to zrobić, ustawiając CanCacheLicenses dla FileProfile::Settings obiektu wartość false.

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

profileSettings.SetCanCacheLicenses(false);

Aparaty Buforowanie

W zestawie MIP SDK aparat jest tworzony dla każdego użytkownika wykonującego wszelkie uwierzytelnione operacje. Aparaty udostępnia interfejs dla wszystkich operacji wykonywanych w imieniu uwierzytelnionej tożsamości. Zgodnie z opisem w temacie Profile i aparaty pojęcia, FileEngine, PolicyEngine lub ProtectionEngine każdy ma dwa stany CREATED i LOADED. Aparat musi zostać utworzony i załadowany, aby móc wykonywać operacje zestawu SDK. Jeśli aparat nie jest używany, zestaw SDK buforuje aparat i zachowuje go w stanie tak długo, jak to możliwe, w CREATED zależności od dostępnych zasobów. Każda odpowiednia klasa profilu zestawu SDK udostępnia również metodę UnloadEngineAsync jawnego osiągnięcia tego celu.

Każdy aparat ma unikatowy identyfikator id , który jest używany we wszystkich operacjach zarządzania aparatem. Aplikacja kliencka może jawnie podać identyfikator lub zestaw SDK może go wygenerować, jeśli nie jest on dostarczany przez aplikację. Jeśli unikatowy identyfikator jest udostępniany przy użyciu obiektów ustawień aparatu podczas tworzenia aparatu, a buforowanie jest włączone w profilu interfejsu API zgodnie z powyższym opisem, te same aparaty mogą być używane za każdym razem, gdy użytkownik wykonuje operację z zestawem SDK. Postępuj zgodnie z fragmentami kodu, aby utworzyć element [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).

Nie można podać istniejącego identyfikatora engineId spowoduje dodatkowe rundy usług w celu pobrania zasad i pobierze licencje, które mogły już być buforowane dla istniejącego aparatu. Buforowanie identyfikator aparatu umożliwia zestawowi SDK dostęp w trybie offline do wcześniej odszyfrowanych informacji i ogólnych ulepszeń wydajności.

Następne kroki

Następnie dowiedz się więcej na temat pojęć dotyczących obiektów profilów i aparatu, aby dowiedzieć się, jak prawidłowo ustawić identyfikatory aparatu MIP w celu prawidłowego korzystania z buforowania zestawu MIP SDK.