Microsoft Information Protection SDK - Cache-Speicher

Das MIP SDK implementiert eine SQLite3-Datenbank zum Verwalten des SDK-Cachespeichers. Vor Version 1.3 des Microsoft Information Protection SDK wurden nur zwei Typen des Cachestatusspeichers unterstützt: Auf dem Datenträger und im Arbeitsspeicher. Beide Typen speicherten bestimmte Daten, insbesondere Lizenzen für geschützte Inhalte und Richtlinien in Klartext.

Um die Sicherheitsposition des SDK zu verbessern, haben wir eine zweite Art von Datenträgercache hinzugefügt, die plattformspezifische kryptografische APIs verwendet, um die Datenbank und deren Inhalt zu schützen.

Die Anwendung definiert den Cachetyp beim Laden des Profils als Teil der FileProfileSettings, PolicyProfileSettings oder ProtectionProfileSettings Objekte. Der Cachetyp ist statisch für die Lebensdauer des Profils. Das Ändern in einen anderen Cachespeichertyp erfordert die Zerstörung des vorhandenen Profils und das Erstellen eines neuen.

Cachespeichertypen

Ab MIP SDK Release 1.3 sind die folgenden Speichercachetypen verfügbar.

Typ Zweck
InMemory Verwaltet den Speichercache im Arbeitsspeicher in der Anwendung.
OnDisk Speichert die Datenbank auf dem Datenträger im Verzeichnis, das im Einstellungsobjekt bereitgestellt wird. Die Datenbank wird im Klartext gespeichert.
OnDiskEncrypted Speichert die Datenbank auf dem Datenträger im Verzeichnis, das im Einstellungsobjekt bereitgestellt wird. Die Datenbank wird mit betriebssystemspezifischen APIs verschlüsselt.

Jede von der Anwendung generierte Engine erzeugt einen neuen Verschlüsselungsschlüssel.

Sie legen den Cache-Speicher in einem der Profileinstellungsobjekte mithilfe des mip::CacheStorageType-Enums fest.

FileProfile::Settings profileSettings(mMipContext,
    mip::CacheStorageType::OnDiskEncrypted, // Define the storage type to use.
    mAuthDelegate,
    std::make_shared<sample::consent::ConsentDelegateImpl>(),
    std::make_shared<FileProfileObserver>());

Wann ist welcher Typ zu verwenden?

Der Cachespeicher ist wichtig für die Aufrechterhaltung des Offlinezugriffs auf zuvor entschlüsselte Informationen und die Sicherstellung der Leistung für Entschlüsselungsvorgänge, wenn Daten zuvor genutzt wurden.

  • Im Speicher: Verwenden Sie diesen Speichertyp für langlebige Prozesse, bei denen die Aufrechterhaltung der Richtlinien- oder Lizenz-Cache-Informationen über Dienstneustarts hinweg nicht erforderlich ist.
  • Auf dem Datenträger: Verwenden Sie diesen Speichertyp für Anwendungen, bei denen Prozesse häufig beendet und gestartet werden können, müssen jedoch Richtlinien-, Lizenz- und Dienstermittlungscache über Neustarts hinweg verwalten. Dieser Speichercachetyp ist nurtext, daher ist es besser geeignet für Serverlasten, in denen Benutzer keinen Zugriff auf den Statusspeicher haben. Beispiele dafür wären ein Windows Dienst oder Linux-Daemon, der auf einem Server ausgeführt wird, oder eine SaaS-Anwendung, in der nur Dienstadministratoren Zugriff auf die Statusdaten haben würden.
  • Auf Datenträger und verschlüsselt: Verwenden Sie diesen Speichertyp für Anwendungen, bei denen Prozesse häufig beendet und gestartet werden können, müssen jedoch Richtlinien-, Lizenz- und Dienstermittlungscache über Neustarts hinweg verwalten. Dieser Speichercache ist verschlüsselt und eignet sich daher besser für Arbeitsstationsanwendungen, bei denen ein Benutzer die Statusdatenbank durchsuchen und ermitteln kann. Die Verschlüsselung hilft sicherzustellen, dass neugierige Benutzer keinen Zugriff auf die Richtlinieninhalte oder den Inhalt der Schutzlizenz im Klartext haben. In allen Fällen werden die Daten mit Schlüsseln verschlüsselt, auf die der Benutzer zugreifen kann. Ein erfahrener Angreifer kann den Cache mit minimalem Aufwand entschlüsseln, dies verhindert jedoch Manipulationen und Browsen.

Unterstützte Plattformen für verschlüsselung

Plattform Version Hinweise
Microsoft Windows Windows 11, Supportversion von Windows Server
macOS High Sierra und höher
Ubuntu Linux 22.04 und spätere Versionen Erfordert SecretService- und LinuxEncryptedCache-Featurekennzeichnung.
Android Android 7.0 oder höher
iOS Alle unterstützten Versionen

Während das MIP SDK andere Linux-Distributionen unterstützt, haben wir die Cacheverschlüsselung auf RedHat Enterprise Linux, CentOS oder Debian nicht getestet.

Hinweis

Sie setzen das Feature-Flag, um die Cache-Speicherung unter Linux mit mip::MipConfiguration::SetFeatureSettings() zu aktivieren.

Cachedatenbanktabellen

Das MIP SDK verwaltet zwei Datenbanken für den Cache. Eine ist für die Schutz-SDKs und die Erhaltung von Schutzstatusdetails. Das andere ist für die Richtlinien-SDKs und die Verwaltung von Richtliniendetails und Dienstinformationen. Beide werden in dem im Einstellungsobjekt definierten Pfad gespeichert, und zwar unter mip\mip.policies.sqlite3 und mip\mip.protection.sqlite3.

Hinweis

Das MIP SDK garantiert keine Kompatibilität in verschiedenen Versionen des Caches. Löschen Sie alle Dateien im mip\-Verzeichnis oder ein alternatives Verzeichnis, das von der Standardeinstellung geändert wurde, bevor Sie die Anwendung auf eine neue Version des MIP SDK aktualisieren.

Schutzdatenbank

Tabelle Zweck Verschlüsselt
AuthInfoStore Speichert Authentifizierungsherausforderungsdetails. Nein
ConsentStore Speichert Zustimmungsergebnisse für jede Engine. Nein
DnsInfoStore Speichert DNS-Nachschlageergebnisse für Schutzvorgänge Nein
EngineStore Speichert Moduldetails, zugeordnete Benutzer und benutzerdefinierte Clientdaten Nein
KeyStore Speichert symmetrische Verschlüsselungsschlüssel für jede Engine. Ja
LicenseStore Die Speicher verwenden Lizenzinformationen für zuvor entschlüsselte Daten. Ja
SdInfoStore Speichert Dienstermittlungsergebnisse. Nein

Hinweis

Für den LicenseStore-Cache muss eine Identität für das Schutzmodul oder das Dateimodul festgelegt werden.

Richtliniendatenbank

Tabelle Zweck Verschlüsselt
KeyStore Speichert symmetrische Verschlüsselungsschlüssel für jede Engine. Ja
Richtlinien Speichert Bezeichnungsrichtlinieninformationen für jeden Benutzer. Ja
Richtlinien-URL Speichert back-End-Richtliniendienst-URL für bestimmte Benutzer. Nein
Sensitivität Speichert Klassifizierungsregeln für eine bestimmte Benutzerrichtlinie. Ja
SensitivityUrls Speichert die URL des Back-End-Vertraulichkeitsrichtliniendiensts für bestimmte Benutzer. Nein

Überlegungen zur Datenbankgröße

Die Datenbankgröße hängt von zwei Faktoren ab: der Anzahl der Engines, die im Cache gespeichert werden, und der Anzahl der Schutzlizenzen, die im Cache gespeichert wurden. Ab MIP SDK 1.18 können Sie DeleteStoredData() auf ProtectionEngine verwenden, um zwischengespeicherte Enginedaten programmgesteuert zu entfernen. Bei früheren Versionen kann ein externer Prozess erforderlich sein, um den Cache zu entfernen, wenn er größer als gewünscht wird.

Der wichtigste Beitrag zum Datenbankwachstum ist der Schutzlizenzcache. Wenn die Zwischenspeicherung von Lizenzdaten nicht erforderlich ist, entweder weil sich die Hin- und Rückübertragungen an den Dienst nicht auf die Leistung Ihrer Anwendung auswirken oder weil der Cache möglicherweise zu groß wird, können Sie den Lizenzcache deaktivieren. Legen Sie dazu für das FileProfile::Settings Objekt den Wert "false" festCanCacheLicenses.

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

profileSettings.SetCanCacheLicenses(false);

Zwischenspeichern von Engines

In MIP SDK wird ein Modul für jeden Benutzer erstellt, der einen authentifizierten Vorgang ausführt. Engines stellen eine Schnittstelle für alle Vorgänge bereit, die im Auftrag einer authentifizierten Identität ausgeführt werden. Wie in Profilen und Engines-Konzepten erläutert, hat FileEngine, PolicyEngine oder ProtectionEngine jeweils zwei Zustände CREATED und LOADED. Ein Modul muss erstellt und geladen werden, damit es SDK-Vorgänge ausführen kann. Wenn eine Engine nicht in Gebrauch ist, speichert das SDK die Engine im Cache und hält sie so lange wie möglich im Zustand CREATED, je nach verfügbaren Ressourcen. Die Klasse profile des jeweiligen SDK bietet auch eine Methode UnloadEngineAsync, um dies explizit zu erreichen.

Jede Engine hat eine eindeutige Kennung id, die bei allen Enginemanagementvorgängen verwendet wird. Die Clientanwendung kann eine ID explizit bereitstellen, oder das SDK kann eine id generieren, wenn sie nicht von der Anwendung bereitgestellt wird. Wenn ein eindeutiger Bezeichner zum Zeitpunkt der Modulerstellung mithilfe von Moduleinstellungen bereitgestellt wird und das Zwischenspeichern im API-Profil wie oben beschrieben aktiviert ist, können dieselben Engines jedes Mal verwendet werden, wenn der Benutzer einen Vorgang mit dem SDK ausführt. Folgen Sie den Codeschnipseln für die Erstellung von [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).

Ein Fehler beim Bereitstellen einer vorhandenen engineId führt zu zusätzlichen Dienst-Roundtrips zum Abrufen von Richtlinien und ruft Lizenzen ab, die möglicherweise bereits für das vorhandene Modul zwischengespeichert wurden. Das Zwischenspeichern der Modul-ID ermöglicht dem SDK-Offlinezugriff auf zuvor entschlüsselte Informationen und allgemeine Leistungsverbesserungen.

Nächste Schritte

Erfahren Sie als Nächstes mehr über die Konzepte von Profil- und Engine-Objekten, um zu verstehen, wie Engine-IDs korrekt festgelegt werden, damit das Caching im MIP SDK ordnungsgemäß verwendet wird.

  • Last updated on