Freigeben über

Microsoft Information Protection SDK - Cache-Speicher

  • Artikel

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 werden bestimmte Daten gespeichert, insbesondere Lizenzen für geschützte Inhalte und Richtlinieninformationen in Nurtext.

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.

Cache Storage Typen

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

type 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 in Nurtext gespeichert.
OnDiskEncrypted Speichert die Datenbank auf dem Datenträger im Verzeichnis, das im Einstellungsobjekt bereitgestellt wird. Die Datenbank wird mit betriebssystemspezifischen APIs verschlüsselt.

Jedes von der Anwendung generierte Modul generiert einen neuen Verschlüsselungsschlüssel.

Der Cache-Speicher wird über eines der Profileinstellungsobjekte durch das mip::CacheStorageType-Enum festgelegt.

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 Platte: Verwenden Sie diesen Speichertyp für Anwendungen, bei denen Prozesse häufig gestoppt und gestartet werden können, aber Richtlinien-, Lizenz- und Diensterkennungs-Caches über Neustarts hinweg beibehalten werden müssen. 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 Festplatte und verschlüsselt: Verwenden Sie diesen Speichertyp für Anwendungen, bei denen Prozesse häufig gestoppt und gestartet werden können, aber Richtlinien-, Lizenz- und Diensterkennungs-Caches über Neustarts hinweg beibehalten werden müssen. Dieser Speichercache ist verschlüsselt und eignet sich daher besser für Arbeitsstationsanwendungen, in denen ein Benutzer die Statusdatenbank durchsuchen und entdecken kann. Die Verschlüsselung hilft, sicherzustellen, dass die Prying-Benutzer keinen Zugriff auf den Inhalt oder den Schutz von Lizenzinhalten in Nur-Text haben. Es ist wichtig zu beachten, dass in allen Fällen die Daten mit Schlüsseln verschlüsselt werden, 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 8 und höher Windows 7 unterstützt nur CacheStorageType::OnDisk
macOS High Sierra und höher
Ubuntu Linux 16.04 (und höher) 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

Das Funktionsflag zur Aktivierung der Cache-Speicherung unter Linux wird über mip::MipConfiguration::SetFeatureSettings() gesetzt

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. Es ist ratsam, alle Dateien im mip\-Verzeichnis zu löschen oder ein alternatives Verzeichnis, das von der Standardeinstellung geändert wurde, vor dem Upgrade der Anwendung auf eine neue Version des MIP SDK zu löschen.

Schutzdatenbank

Tabelle Zweck Verschlüsselt
AuthInfoStore Speichert Die Authentifizierungs-Herausforderungsdetails. No
ConsentStore Speichert Zustimmungsergebnisse für jedes Modul. No
DnsInfoStore Speichert DNS-Nachschlageergebnisse für Schutzvorgänge No
EngineStore Speichert Moduldetails, zugeordnete Benutzer und benutzerdefinierte Clientdaten No
KeyStore Speichert symmetrische Verschlüsselungsschlüssel für jedes Modul. Ja
LicenseStore Speichert 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 jedes Modul. Ja
Richtlinien Speichert Bezeichnungsrichtlinieninformationen für jeden Benutzer. Ja
PoliciesUrl Speichert back-End-Richtliniendienst-URL für bestimmte Benutzer. No
Sensitivität Speichert Klassifizierungsregeln für eine bestimmte Benutzerrichtlinie. Ja
SensitivityUrls Speichert die URL des Back-End-Vertraulichkeitsrichtliniendiensts für bestimmte Benutzer. No

Überlegungen zur Datenbankgröße

Die Datenbankgröße hängt von zwei Faktoren ab: Die Anzahl der Engines, die dem Cache hinzugefügt werden, und die Menge der Schutzlizenzen, die zwischengespeichert wurden. Ab MIP SDK 1.3 gibt es keinen Mechanismus zum Bereinigen des Lizenzcaches, während sie ablaufen. Es muss ein externer Prozess vorhanden sein, um den Cache zu entfernen, wenn er größer als gewünscht ist.

Der wichtigste Beitrag zum Datenbankwachstum ist der Schutzlizenzcache. Wenn die Lizenzierungszwischenspeicherung nicht erforderlich ist, kann der Lizenzcache entweder nicht beeinträchtigt werden, da sich die Dienstrunden nicht auf die Anwendungsleistung auswirken, oder der Cache kann zu groß werden, der Lizenzcache kann deaktiviert werden. Dies wird erreicht, indem CanCacheLicenses auf dem Objekt FileProfile::Settings auf false gesetzt wird.

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 stellt eine Schnittstelle für alle Vorgänge bereit, die im Namen 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 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).

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

Als Nächstes erfahren Sie mehr über Profil- und Engine-Objektkonzepte, um zu verstehen, wie man MIP-Engine-IDs richtig einstellt, um das MIP-SDK-Caching richtig zu nutzen.