Microsoft Information Protection SDK — pamięć podręczna

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

Aby poprawić bezpieczeństwo zestawu SDK, dodaliśmy obsługę drugiego typu pamięci podręcznej dyskowej, które chronią bazę danych i jej zawartość, wykorzystujące interfejsy API kryptograficzne specyficzne dla platformy.

Aplikacja definiuje typ pamięci podręcznej podczas ładowania profilu jako części FileProfileSettings , PolicyProfileSettings lub ProtectionProfileSettings obiektów. Typ pamięci podręcznej jest statyczny dla cyklu życia profilu. Zmiana typu pamięci podręcznej na inny typ wymaga liklikowania istniejącego profilu i utworzenia nowego.

Typy Storage pamięci podręcznej

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

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

Pamięć podręczna jest ustawiana za pośrednictwem jednego z obiektów ustawień profilu, za pośrednictwem mip::CacheStorageType wyli roku.

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 używać każdego typu

Pamięć podręczna ma znaczenie dla utrzymywania dostępu w trybie offline do wcześniej odszyfrowanych informacji, a także zapewniania wydajności operacji odszyfrowywania, gdy dane były już wcześniej używane.

• W pamięci Storage:Użyj tego typu magazynu na potrzeby długotrwałych procesów, w których nie jest wymagane utrzymywanie zasad lub licencji w pamięci podręcznej po ponownym uruchomieniu usługi.
• Na dysku:tego typu magazynu należy używać w przypadku aplikacji, w których procesy mogą często się zatrzymywać i rozpoczynać, ale muszą zachowywać pamięć podręczną odnajdowania zasad, licencji i usług po ponownym uruchomieniu. Ten typ pamięci podręcznej jest zwykłego tekstu, dlatego lepiej nadaje się do obciążeń serwera, gdy użytkownicy nie będą mieli dostępu do magazynu stanowego. Przykładem może być usługa Windows lub daemon systemu Linux uruchomiona na serwerze lub aplikacja SaaS, w której tylko administratorzy usług będą mieli dostęp do danych o stanie.
• Na dysku iw funkcji zaszyfrowanej: tego typu magazynu należy używać w przypadku aplikacji, w których procesy mogą często się zatrzymywać i uruchamiać, ale po ponownym uruchomieniu musi zachowywać pamięć podręczną odnajdowania zasad, licencji i usług. Ta pamięć podręczna magazynu jest zaszyfrowana, więc lepiej nadaje się do aplikacji na stacji roboczej, w których użytkownik może przeglądać i wykrywać stanową bazę danych. Szyfrowanie gwarantuje, że wyzyscy użytkownicy nie będą mieli do nich dostępu za pośrednictwem zawartości zasad lub licencji ochrony w formacie 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. Uzdolniony adversary będzie mógł odszyfrować pamięć podręczną przy minimalnym nakładzie pracy, ale zapobiega to manipulowaniu i przeglądaniu.

Obsługiwane platformy szyfrowania

Zestaw SDK miP obsługuje inne dystrybucje Linuksa, ale nie testujemy szyfrowania pamięci podręcznej w systemie RedHat Enterprise Linux, CentOS lub Debian.

Tabele baz danych magazynu w pamięci podręcznej

Zestaw SDK programu MIP przechowuje dwie bazy danych dla pamięci podręcznej. Pierwszy z nich to zestaw SDK ochrony i zachowanie szczegółów stanu ochrony. Drugie jest w przypadku zestawów SDK zasad oraz z zachowaniem szczegółów zasad i informacji o usługach. Oba pliki są przechowywane w ścieżce zdefiniowanej w obiekcie settings, w folderze mip\mip.policies.sqlite3 i mip\mip.protection.sqlite3.

Baza danych ochrony

Baza danych zasad

Zagadnienia dotyczące rozmiaru bazy danych

Rozmiar bazy danych zależy od dwóch czynników: liczby aparatów dodawanych do pamięci podręcznej i liczby licencji ochrony, które zostały zapisane w pamięci podręcznej. W zestawie MIP SDK 1.3 nie ma mechanizmu oczyszczania pamięci podręcznej licencji po ich wygaśnięciu. Usunięcie pamięci podręcznej musi być procesem zewnętrznym, jeśli zostanie powiększony, niż jest to oczekiwane.

Najważniejszym współautorem wzrostu bazy danych będzie pamięć podręczna licencji ochrony. Jeśli licencjonowanie pamięci podręcznej nie jest wymagane, ponieważ odwyżki usługi nie będą miały wpływu na wydajność aplikacji lub może wystąpić zbyt duży wzrost pamięci podręcznej, można wyłączyć pamięć podręczną licencji. Jest to możliwe dzięki ustawieniu dla CanCacheLicenses obiektu FileProfile::Settings wartości false.

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

profileSettings.SetCanCacheLicenses(false);

Buforowanie wyszukiwarki

W zestawie SDK pakietu MIP dla każdego użytkownika jest tworzony aparat wykonujący dowolną uwierzytelnioną operację. Aparaty zapewniają interfejs dla wszystkich operacji wykonywanych w imieniu uwierzytelnionych tożsamości. Zgodnie z omówieniem w pojęciach Profile i aparaty, FileEngine, PolicyEngine lub ProtectionEngine każdy ma dwa stany i LOADED . Aby można było wykonywać operacje zestawu SDK, należy utworzyć i załadować do niego aparat. Jeśli aparat nie jest w użyciu, zestaw SDK buforuje aparat w pamięci podręcznej i zachowuje go w stanie tak długo, jak to możliwe, w zależności CREATED od dostępnych zasobów. Każda klasa profilu odpowiedniego zestawu SDK również zapewnia metodę, aby osiągnąć ten cel jawnie.

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

W przeciwnym razie podanie istniejącego engineId spowoduje dodatkowe odsyłki usługi w celu pobrania zasad i pobranie licencji, które mogą już być buforowane dla istniejącego aparatu. Buforowanie identyfikator aparatu umożliwia dostęp zestawu SDK w trybie offline do wcześniej odszyfrowanych informacji i ulepszeń ogólnej wydajności.

Następne kroki

Następnie dowiedz się więcej o pojęciach obiektów Profile i Engine, aby dowiedzieć się, jak poprawnie skonfigurować identyfikatory aparatów MIP w celu poprawnego korzystania z buforowania zestawu SDK MIP.