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

MIP SDK implementuje bazę danych SQLite3 w celu utrzymania pamięci podręcznej 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 obiektów FileProfileSettings, PolicyProfileSettings lub 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 przechowywania w pamięci podręcznej

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

Typ	Cel
InMemory	Utrzymuje pamięć podręczną magazynowania w pamięci 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 silnik 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

Pamięć podręczna jest ważna do utrzymania dostępu offline do wcześniej odszyfrowanych informacji oraz zachowania 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 wznawiać, ale muszą zachować zasady, licencje i pamięć podręczną odnajdywania usług przy ponownych uruchomieniach. Ten typ pamięci podręcznej jest niezaszyfrowany, dlatego jest bardziej odpowiedni do obciążeń serwerowych, w których użytkownicy nie będą mieli dostępu do przechowywania 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 zaszyfrowane: użyj tego typu pamięci dla aplikacji, w których procesy mogą często się zatrzymywać i uruchamiać, ale muszą zachować zasady, licencje oraz pamięć podręczną odnajdywania usług podczas ponownych uruchomień. Ta pamięć podręczna jest szyfrowana, dlatego lepiej nadaje się do aplikacji stacji roboczych, w których użytkownik może przeglądać i uzyskiwać dostęp do bazy danych stanów. Szyfrowanie pomaga zagwarantować, że wścibscy użytkownicy nie będą mieli dostępu do zawartości zasad ani zawartości licencji ochrony w tekście jawnym. 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. Wykwalifikowany przeciwnik jest w stanie odszyfrować pamięć podręczną przy minimalnym wysiłku, ale nie zapobiega to manipulowaniu i przeglądaniu.

Obsługiwane platformy szyfrowania

Platforma	Version	Notatki
Microsoft Windows	Windows 11, wersja pomocy technicznej systemu Windows Server
macOS	High Sierra i nowsze
Ubuntu Linux	22.04 i wyżej	Wymaga SecretService i LinuxEncryptedCache flagi 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()

Tabele bazy danych pamięci podręcznej

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 do zarządzania politykami oraz utrzymania szczegółów polityk i informacji o usługach. Oba są przechowywane w ścieżce zdefiniowanej w obiekcie settings, pod mip\mip.policies.sqlite3 i mip\mip.protection.sqlite3.

Uwaga

MIP SDK nie gwarantuje zgodności między różnymi wersjami cache. Przed zaktualizowaniem aplikacji do nowej wersji MIP SDK zaleca się usunięcie wszystkich plików z katalogu mip\ lub z dowolnego innego katalogu, jeśli ustawienia domyślne zostały zmienione.

Baza danych ochrony

Tabela	Cel	Zaszyfrowany
AuthInfoStore	Przechowuje szczegóły wyzwania uwierzytelniania.	Nie
Sklep Zgód	Przechowuje wyniki zgody dla każdego silnika.	Nie
DnsInfoStore	Przechowuje wyniki wyszukiwania DNS dla operacji ochrony	Nie
EngineStore	Przechowuje szczegóły silnika, powiązanego użytkownika i niestandardowe dane klienta	Nie
KeyStore	Przechowuje symetryczne klucze szyfrowania dla każdego silnika.	Yes
LicenseStore	Magazyny używają informacji o licencji dla wcześniej odszyfrowanych danych.	Yes
SdInfoStore	Przechowuje wyniki odnajdywania usług.	Nie

Uwaga

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

Baza danych zasad

Tabela	Cel	Szyfrowane
KeyStore	Przechowuje symetryczne klucze szyfrowania dla każdego silnika.	Yes
Zasady	Przechowuje informacje o zasadach etykiet dla każdego użytkownika.	Yes
PoliciesUrl	Przechowuje adres URL dla usługi polityki backendu dla określonego użytkownika.	Nie
Czułość	Przechowuje reguły klasyfikacji dla określonej polityki użytkownika.	Yes
SensitivityUrls	Przechowuje adres URL usługi zasad poufności backendu dla określonego użytkownika.	Nie

Zagadnienia dotyczące rozmiaru bazy danych

Rozmiar bazy danych zależy od dwóch czynników: liczby silników dodawanych do pamięci podręcznej i liczby licencji zabezpieczeń, które zostały zbuforowane. Począwszy od zestawu MIP SDK 1.18, DeleteStoredData() na ProtectionEngine można użyć do programowego usuwania buforowanych danych silnika. W przypadku wcześniejszych wersji może być wymagany proces zewnętrzny, aby usunąć pamięć podręczną, jeśli będzie ona większa niż jest wymagana.

Najważniejszym czynnikiem przyczyniającym się do wzrostu bazy danych będzie pamięć podręczna licencji ochrony. Jeśli buforowanie licencji nie jest wymagane, czy to dlatego, że wywołania zwrotne usługi nie wpłyną na wydajność aplikacji, czy też ze względu na możliwość, że pamięć podręczna może stać się zbyt duża, można ją wyłączyć. 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 buforowania

W zestawie MIP SDK silnik jest tworzony dla każdego użytkownika wykonującego dowolne uwierzytelnione operacje. Silniki udostępniają interfejs dla wszystkich operacji wykonywanych na rzecz uwierzytelnionej tożsamości. Zgodnie z Profile i koncepcje silników, FileEngine, PolicyEngine lub ProtectionEngine, każde z nich ma dwa stany CREATED i LOADED. Silnik musi zostać utworzony i załadowany, aby móc wykonywać operacje SDK. Jeśli silnik nie jest używany, zestaw SDK buforuje silnik i utrzymuje go w stanie CREATED tak długo, jak to możliwe, w 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 silnik ma unikatowy identyfikator id, który jest używany we wszystkich operacjach zarządzania silnikiem. Aplikacja kliencka może jawnie podać identyfikator lub zestaw SDK może go wygenerować, jeśli nie jest on dostarczany przez aplikację. Jeśli unikalny identyfikator jest udostępniany przy użyciu obiektów ustawień silnika podczas tworzenia silnika, a pamięć podręczna jest włączona w profilu interfejsu API, zgodnie z powyższym opisem, te same silniki mogą być używane za każdym razem, gdy użytkownik wykonuje operację za pomocą 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).

Brak podania istniejącego identyfikatora engineId spowoduje dodatkowe operacje serwisowe w celu pobrania zasad oraz pobierze licencje, które mogły już zostać zapisane w pamięci podręcznej dla istniejącego silnika. Buforowanie identyfikatora silnika umożliwia zestawowi SDK dostęp w trybie offline do wcześniej odszyfrowanych informacji oraz ogólną poprawę wydajności.

Dalsze kroki

Następnie dowiedz się więcej na temat pojęć dotyczących obiektów profilów i silnika, aby prawidłowo ustawić identyfikatory silnika MIP i właściwie korzystać z buforowania w MIP SDK.