Microsoft Information Protection SDK – Konzepte für Profil- und Engine-Objekte

Profile

Die MipContext Klasse speichert SDK-spezifische Einstellungen. Das Profil ist die Stammklasse für alle MIP-Bezeichnungen und schutzspezifischen Vorgänge im MIP SDK. Bevor Sie eine der drei API-Sätze verwenden, muss die Clientanwendung ein Profil erstellen. Das Profil oder andere Dem Profil hinzugefügte Objekte führen zukünftige Vorgänge aus. Verwenden Sie pro Prozess nur ein Profilobjekt. Das Erstellen von mehr als einem kann zu unerwartetem Verhalten führen.

Das MIP SDK verfügt über drei Profiltypen:

Die API, die von der verwendeten Anwendung verwendet wird, bestimmt, welche Profilklasse verwendet werden soll.

Das Profil selbst bietet die folgende Funktion:

  • Statusspeicher: Definiert, ob der Zustand im Arbeitsspeicher geladen oder auf dem Datenträger gespeichert werden soll, und ob der Zustand verschlüsselt werden soll, wenn er auf dem Datenträger gespeichert ist.
  • Einwilligungsdelegat: Legt das mip::ConsentDelegate fest, das für Einwilligungsvorgänge verwendet wird.
  • Beobachter für Dateiprofile: Definiert die mip::FileProfile::Observer-Implementierung, die für asynchrone Rückrufe bei Profilvorgängen 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 über die Anwendung, die das SDK nutzt und mit der ID und dem Namen Ihrer Microsoft Entra-Anwendungsregistrierung übereinstimmt.

Motoren

Die Module "File", "Policy" und "Protection SDK" stellen eine Schnittstelle für Vorgänge bereit, die von einer bestimmten Identität ausgeführt werden. Fügen Sie dem Profilobjekt für jeden Benutzer oder Dienstprinzipal, der sich bei der Anwendung anmeldet, eine Engine hinzu. Sie können delegierte Vorgänge mithilfe mip::ProtectionSettings und des Datei- oder Schutzhandlers ausführen. Weitere Informationen finden Sie im Abschnitt "Schutzeinstellungen" in den FileHandler-Konzepten.

Das SDK verfügt über drei Modulklassen, 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.

Übergeben Sie zum Erstellen eines Moduls ein bestimmtes Moduleinstellungsobjekt, das die Einstellungen für den zu erstellenden Modultyp enthält. Mit dem Einstellungsobjekt kann der Entwickler Details zum Modulbezeichner, zur mip::AuthDelegate Implementierung, zum Gebietsschema, zu benutzerdefinierten Einstellungen und anderen API-spezifischen Details angeben.

Motorzustände

Eine Engine kann sich in einem von zwei Zuständen befinden:

  • 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:

Motorzustand NONE CREATED GELADEN
NONE AddEngineAsync
CREATED DeleteEngineAsync AddEngineAsync
GELADEN DeleteEngineAsync UnloadEngineAsync

Engine-ID

Jedes Modul verfügt über einen eindeutigen Bezeichner, idder in allen Modulverwaltungsvorgängen verwendet wird. Die Anwendung kann eine id bereitstellen. Wenn die Anwendung keins bereitstellt, kann es vom SDK generiert werden. Alle anderen Moduleigenschaften, z. B. die E-Mail-Adresse in den Identitätsinformationen, sind undurchsichtige Nutzlasten für das SDK. Das SDK führt keine Logik aus, um andere Eigenschaften eindeutig zu halten oder andere Einschränkungen zu erzwingen.

Wichtig

Verwenden Sie eine für den Benutzer eindeutige Modul-ID, und verwenden Sie diese Modul-ID jedes Mal, wenn der Benutzer einen Vorgang mit dem SDK ausführt. Wenn Sie keine vorhandene, eindeutige Modul-ID für einen Benutzer oder Dienst bereitstellen, macht das SDK zusätzliche Dienst-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

Engine-Verwaltungsmethoden

Das SDK verfügt über drei Modulverwaltungsmethoden: AddEngineAsync, , DeleteEngineAsyncund 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 bleibt erhalten, und Sie können sie mit AddEngineAsync neu laden.

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

Nächste Schritte

  • Last updated on