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 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.

Pamięć podręczną ustawiasz w jednym z obiektów ustawień profilu poprzez wyliczenie 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 istotna dla utrzymania dostępu offline do wcześniej odszyfrowanych informacji oraz zapewnienia wydajności operacji odszyfrowywania, gdy dane były już wcześniej wykorzystywane.

• 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 pamięci dla aplikacji, w których procesy mogą być często zatrzymywane i ponownie uruchamiane, ale muszą zachować polityki, licencje i pamięć podręczną wykrywania usług między ponownymi uruchomieniami. 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 szyfrowane: Użyj tego typu pamięci masowej w przypadku aplikacji, w których procesy mogą często się zatrzymywać i uruchamiać ponownie, ale muszą zachować zasady, licencje i pamięć podręczną mechanizmu odnajdywania usług między ponownymi uruchomieniami. Ta pamięć podręczna jest szyfrowana, więc lepiej nadaje się do aplikacji uruchamianych na stacjach roboczych, w których użytkownik może przeglądać bazę danych stanu i poznawać jej zawartość. Szyfrowanie pomaga zapewnić, że nieuprawnieni użytkownicy nie będą mieć dostępu do treści zasad ani treści licencji ochrony w postaci jawnego tekstu. We wszystkich przypadkach dane są szyfrowane przy użyciu kluczy, do których użytkownik może uzyskać 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

Należy ustawić flagę funkcji, aby włączyć magazyn pamięci podręcznej w systemie Linux 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

SDK MIP nie gwarantuje zgodności między różnymi wersjami swojej pamięci podręcznej. Przed zaktualizowaniem aplikacji do nowej wersji zestawu SDK MIP usuń wszystkie pliki z katalogu mip\ lub z katalogu alternatywnego, jeśli zmieniono ustawienie domyślne.

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	Zaszyfrowany
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 oraz liczby licencji ochronnych zapisanych w pamięci podręcznej. Od wersji 1.18 zestawu MIP SDK można użyć DeleteStoredData() na ProtectionEngine, aby programowo usuwać buforowane dane 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 dodatkowa komunikacja z usługą nie wpłynie na wydajność aplikacji, czy dlatego, że rozmiar pamięci podręcznej mógłby być zbyt duży — możesz wyłączyć pamięć podręczną licencji. W tym celu ustaw w obiekcie FileProfile::Settings wartość CanCacheLicenses na false.

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

profileSettings.SetCanCacheLicenses(false);

Silniki buforowania

W zestawie MIP SDK silnik jest tworzony dla każdego użytkownika wykonującego dowolne uwierzytelnione operacje. Silniki zapewniają interfejs do wszystkich operacji wykonywanych w imieniu 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 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).

Niepodanie istniejącego identyfikatora engineId spowoduje dodatkowe wywołania usługi w celu pobrania zasad oraz pobranie licencji, które mogły już być 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.

Następne kroki

Następnie dowiedz się więcej o pojęciach związanych z obiektami Profile i Engine, aby zrozumieć, jak prawidłowo ustawić identyfikatory mechanizmu MIP i poprawnie korzystać z mechanizmu buforowania w zestawie MIP SDK.