Sdílet prostřednictvím

Microsoft Information Protection SDK – Koncepty objektů profilu a stroje

  • Článek

Profily

MipContext Kde je třída pro ukládání nastavení specifických pro sadu SDK, je profil kořenovou třídou pro všechny operace popisování a ochrany MIP v sadě MIP SDK. Před použitím některé ze tří sad rozhraní API musí klientská aplikace vytvořit profil. Budoucí operace provádí profil nebo jiné objekty přidané do profilu. Doporučuje se pouze jeden objekt profilu pro každý proces. Vytvoření více než jednoho může vést k neočekávanému chování.

V sadě MIP SDK existují tři typy profilů:

Rozhraní API použité v aplikaci využívající určuje, která třída profilu se má použít.

Samotný profil poskytuje následující funkce:

  • Definuje, jestli se má stav načíst do paměti nebo trvale na disk, a pokud je trvale zachovaný na disk, měl by být zašifrovaný.
  • mip::ConsentDelegate Definuje, které se mají použít pro operace souhlasu.
  • Definuje implementaci mip::FileProfile::Observer , která se použije pro asynchronní zpětné volání pro operace profilu.

Nastavení profilu

  • MipContext: Objekt MipContext inicializovaný k uložení informací o aplikaci, cesty stavu atd.
  • CacheStorageType: Definuje, jak uložit stav: V paměti, na disku nebo na disku a zašifrováno.
  • consentDelegate: Sdílený ukazatel třídy mip::ConsentDelegate.
  • observer: Sdílený ukazatel na implementaci profilu Observer (v PolicyProfileProtectionProfile, a FileProfile).
  • applicationInfo: Objekt mip::ApplicationInfo . Informace o aplikaci, která využívá sadu SDK, která odpovídá VAŠEMu ID a názvu registrace aplikace Microsoft Entra.

Motory

Moduly File, Profile a Protection SDK poskytují rozhraní pro operace prováděné konkrétní identitou. Jeden modul se přidá do objektu Profile pro každého uživatele nebo instanční objekt, který se přihlásí k aplikaci. Delegovaná operace je možné provádět prostřednictvím mip::ProtectionSettings souboru nebo obslužné rutiny ochrany. Další podrobnosti najdete v části Nastavení ochrany v konceptech Obslužná rutina souborů.

V sadě SDK existují tři třídy modulu, jedna pro každé rozhraní API. Následující seznam obsahuje třídy motoru a několik funkcí přidružených k jednotlivým funkcím:

  • mip::ProtectionEngine
  • mip::PolicyEngine
    • ListSensitivityLabels(): Získá seznam popisků pro načtený motor.
    • GetSensitivityLabel(): Získá popisek z existujícího obsahu.
    • ComputeActions(): Poskytuje se s ID popisku a volitelnými metadaty, vrátí seznam akcí, ke kterým by mělo dojít pro konkrétní položku.
  • mip::FileEngine
    • ListSensitivityLabels(): Získá seznam popisků pro načtený motor.
    • CreateFileHandler(): Vytvoří pro mip::FileHandler určitý soubor nebo datový proud.

Vytvoření modulu vyžaduje předání konkrétního objektu nastavení modulu, který obsahuje nastavení pro typ modulu, který se má vytvořit. Objekt nastavení umožňuje vývojáři zadat podrobnosti o identifikátoru modulu, mip::AuthDelegate implementaci, národním prostředí a vlastním nastavení a také další podrobnosti specifické pro rozhraní API.

Stavy motoru

Modul může mít jeden ze dvou stavů:

  • CREATED: Vytvořeno znamená, že sada SDK má po volání požadovaných back-endových služeb dostatek informací o místním stavu.
  • LOADED: Sada SDK vytvořila požadované datové struktury, aby byl modul funkční.

Aby bylo možné provádět jakékoli operace, musí se vytvořit i načíst modul. Třída Profile zveřejňuje několik metod správy modulu: AddEngineAsync, DeleteEngineAsynca UnloadEngineAsync.

Následující tabulka popisuje možné stavy modulu a metody, které mohou tento stav změnit:

Stav motoru ŽÁDNÝ VYTVOŘENO NALOŽENÝ
ŽÁDNÝ AddEngineAsync
VYTVOŘENO DeleteEngineAsync AddEngineAsync
NALOŽENÝ DeleteEngineAsync UnloadEngineAsync

ID modulu

Každý modul má jedinečný identifikátor, idkterý se používá ve všech operacích správy modulu. Aplikace může poskytnout sadu idSDK nebo ji může vygenerovat, pokud ji aplikace neposkytuje. Všechny ostatní vlastnosti modulu (například e-mailová adresa v informacích o identitě) jsou neprůžné datové části sady SDK. Sada SDK neprovádí žádnou logiku, která by zachovala jakoukoli jinou jedinečnou vlastnost nebo vynucuje jakákoli jiná omezení.

Důležité

**Osvědčeným postupem je použít ID modulu, které je pro uživatele jedinečné a používá se při každém provedení operace se sadou SDK. Když uživateli nebo službě neposkytnete existující, jedinečný identifikátor engineId, dojde k dalšímu zaokrouhlení služby. Tyto doby odezvy služby můžou vést ke snížení výkonu a omezování. **

// 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

Metody správy stroje

Jak už bylo zmíněno dříve, v sadě SDK existují tři metody správy modulu: AddEngineAsync, DeleteEngineAsynca UnloadEngineAsync.

AddEngineAsync

Tato metoda načte existující modul nebo vytvoří modul, pokud ještě neexistuje v místním stavu.

Pokud aplikace nezadá id , FileEngineSettingsAddEngineAsync vygeneruje novou id. Pak zkontroluje, jestli modul s již id existuje v mezipaměti místního úložiště. Pokud ano, načte tento modul. Pokud modul v místní mezipaměti neexistuje , vytvoří se nový modul voláním potřebných rozhraní API a back-endových služeb.

V obou případech, pokud je metoda úspěšná, je modul načten a připraven k použití.

DeleteEngineAsync

Odstraní modul s daným idmodulem . Všechna trasování modulu se odeberou z místní mezipaměti.

UnloadEngineAsync

Uvolní datové struktury v paměti pro modul s daným idmodulem . Místní stav tohoto modulu je stále nedotčený a lze jej znovu načíst .AddEngineAsync

Tato metoda umožňuje, aby aplikace byla upředná ohledně využití paměti uvolněním modulů, které se neočekává, že se brzy použijí.

Další kroky