Microsoft Information Protection SDK – Profil- und Engine-Objektkonzepte

  • Artikel

Profiles

Während MipContext die Klasse für die Speicherung SDK-spezifischer Einstellungen ist, ist das Profil die Stammklasse für alle MIP- und schutzspezifischen Vorgänge im MIP-SDK. Bevor Sie eine der drei API-Sätze verwenden, muss die Clientanwendung ein Profil erstellen. Künftige Vorgänge werden vom Profil oder von anderen Objekten durchgeführt, die dem Profil hinzugefügt wurden. Es wird nur ein einzelnes Profilobjekt pro Prozess empfohlen. Das Erstellen von mehr als einem kann zu unerwartetem Verhalten führen.

Im MIP SDK gibt es drei Profiltypen:

Die in der konsumierenden Anwendung verwendete API bestimmt, welche Profilklasse verwendet werden soll.

Das Profil selbst bietet die folgende Funktion:

  • Definiert, ob der Zustand im Arbeitsspeicher geladen oder auf dem Datenträger gespeichert werden soll, und wenn er auf dem Datenträger beibehalten wird, sollte er verschlüsselt werden.
  • Legt die mip::ConsentDelegate fest, die für Zustimmungsvorgänge verwendet werden sollen.
  • Definiert die mip::FileProfile::Observer-Implementierung, die für asynchrone Rückrufe für Profiloperationen verwendet wird.

Profileinstellungen

  • MipContext: Das MipContext Objekt, das initialisiert wurde, um Anwendungsinformationen, Statuspfad usw. zu speichern.
  • CacheStorageType: Legt fest, wie der Status zu speichern ist: Im Speicher, auf der Festplatte, oder auf der Festplatte und verschlüsselt.
  • consentDelegate: Ein gemeinsam genutzter Zeiger der Klasse mip::ConsentDelegate.
  • observer: Ein gemeinsam genutzter Zeiger auf die Profilimplementierung Observer (in PolicyProfile, ProtectionProfile und FileProfile).
  • applicationInfo: Ein mip::ApplicationInfo-Objekt. Informationen zu der Anwendung, die das SDK verwendet, das Ihrer Microsoft Entra-Anwendungsregistrierungs-ID und ihrem Namen entspricht.

Engines

Die Datei-, Profil- und Protection SDK-Engines bieten eine Schnittstelle für Vorgänge, die mit einer bestimmten Identität durchgeführt werden. Für jeden Benutzer oder Dienstprinzipal, der sich bei der Anwendung anmeldet, wird dem Profilobjekt eine Engine hinzugefügt. Es ist möglich, delegierte Vorgänge über mip::ProtectionSettings und den Datei- oder Schutzhandler durchzuführen. Siehe den Abschnitt Schutzeinstellungen in den FileHandler-Konzepten für weitere Einzelheiten.

Im SDK gibt es drei Engineklassen, eine für jede API. In der folgenden Liste sind die Engineklassen und einige der jeweils zugeordneten Funktionen aufgeführt:

  • mip::ProtectionEngine
  • mip::PolicyEngine
    • ListSensitivityLabels(): Ruft die Liste der Bezeichnungen für die geladene Engine ab.
    • GetSensitivityLabel(): Ruft die Bezeichnung aus vorhandenen Inhalten ab.
    • ComputeActions(): Gibt mit einer Bezeichnungs-ID und optionalen Metadaten die Liste der Aktionen zurück, die für ein bestimmtes Element auftreten sollen.
  • mip::FileEngine
    • ListSensitivityLabels(): Ruft die Liste der Bezeichnungen für die geladene Engine ab.
    • CreateFileHandler(): Erstellt eine mip::FileHandler für eine bestimmte Datei oder einen bestimmten Datenstrom.

Beim Erstellen eines Moduls muss ein bestimmtes Moduleinstellungenobjekt übergeben werden, das die Einstellungen für den Zu erstellenden Modultyp enthält. Das Einstellungen-Objekt ermöglicht es dem Entwickler, Details zum Engine-Identifikator, zur mip::AuthDelegate-Implementierung, zum Gebietsschema und zu benutzerdefinierten Einstellungen sowie andere API-spezifische Details anzugeben.

Engine-Zustände

Eine Engine kann einen von zwei Zuständen aufweisen:

  • CREATED: Erstellt gibt an, dass das SDK über genügend lokale Zustandsinformationen verfügt, nachdem die erforderlichen Back-End-Dienste aufgerufen wurden.
  • LOADED: Das SDK hat die erforderlichen Datenstrukturen erstellt, damit die Engine funktionsfähig ist.

Eine Engine muss sowohl erstellt als auch geladen werden, um Vorgänge auszuführen. Die Profile-Klasse macht einige Engine-Verwaltungsmethoden verfügbar: AddEngineAsync, DeleteEngineAsync und UnloadEngineAsync.

Die folgende Tabelle beschreibt die möglichen Enginezustände und die Methoden, die diesen Zustand ändern können:

engine-state NONE CREATED GELADEN
NONE AddEngineAsync
CREATED DeleteEngineAsync AddEngineAsync
GELADEN DeleteEngineAsync UnloadEngineAsync

Engine-ID

Jede Engine hat eine eindeutige Kennung, id, die bei allen Enginemanagementvorgängen verwendet wird. Die Anwendung kann ein id bereitstellen, oder das SDK kann eines generieren, wenn es nicht von der Anwendung bereitgestellt wird. Alle anderen Engine-Eigenschaften (z. B. E-Mail-Adresse in den Identitätsinformationen) sind undurchsichtige Nutzlasten für das SDK. Das SDK führt KEINE Logik aus, um jegliche anderen Eigenschaften eindeutig zu halten oder andere Einschränkungen zu erzwingen.

Wichtig

**Als bewährte Methode verwenden Sie eine Modul-ID, die für den Benutzer eindeutig ist, und verwenden Sie diese jedes Mal, wenn der Benutzer einen Vorgang mit dem SDK ausführt. Fehler beim Bereitstellen einer vorhandenen, eindeutigen Engine-ID für einen Benutzer oder Dienst führt zu zusätzlichen Service-Roundtrips. Diese Dienst-Roundtrips können zu Leistungsbeeinträchtigungen und Drosselung führen. **

// Create the FileEngineSettings object
FileEngine::Settings engineSettings(mip::Identity(mUsername), // This will be the engine ID. UPN, email address, or other unique user identifiers are recommended. 
													          mAuthDelegate,            // authDelegate implementation 
													          "",                       // ClientData
													          "en-US",                  // Client Locale
                                    false);                   // Load Sensitive Information Types

Engineverwaltungsmethoden

Wie bereits erwähnt, gibt es im SDK drei Methoden für das Enginemanagement: AddEngineAsync, DeleteEngineAsync, und UnloadEngineAsync.

AddEngineAsync

Mit dieser Methode wird eine vorhandene Engine geladen bzw. eine solche erstellt, wenn sie nicht bereits im lokalen Zustand vorhanden ist.

Wenn die Anwendung kein id in FileEngineSettings bereitstellt, erzeugt AddEngineAsync ein neues id. Dann wird geprüft, ob eine Engine mit diesem id bereits im lokalen Speichercache vorhanden ist. Wenn dies der Fall ist, wird diese Engine geladen. Wenn die Engine nicht im lokalen Cache vorhanden ist, wird eine neue Engine durch Aufruf der erforderlichen APIs und Backend-Dienste erstellt.

In beiden Fällen wird die Engine geladen und kann verwendet werden, wenn die Methode erfolgreich ist.

DeleteEngineAsync

Löscht die Engine mit angegebenen id. Alle Spuren der Engine werden aus dem lokalen Cache entfernt.

UnloadEngineAsync

Entlädt die In-Memory-Datenstrukturen für die Engine mit dem angegebenen id. Der lokale Zustand dieser Engine ist noch intakt und kann mit AddEngineAsync neu geladen werden.

Mit dieser Methode kann die Anwendung den Speicher sinnvoll nutzen, indem sie Engines entlädt, die voraussichtlich nicht bald verwendet werden.

Nächste Schritte