Microsoft Information Protection SDK - Concepts de profil et d’objet du moteur

Profils

La MipContext classe stocke les paramètres spécifiques au Kit de développement logiciel (SDK). Le profil est la classe racine de toutes les opérations d’étiquetage et de protection MIP spécifiques au SDK MIP. Avant d’utiliser l’un des trois ensembles d’API, l’application cliente doit créer un profil. Le profil ou d’autres objets ajoutés au profil effectuent des opérations ultérieures. Utilisez un seul objet de profil par processus. La création de plusieurs peut entraîner un comportement inattendu.

Le Kit de développement logiciel (SDK) MIP a trois types de profil :

L’API utilisée par l’application consommatrice détermine la classe de profil à utiliser.

Le profil lui-même offre la fonctionnalité suivante :

  • Stockage d’état : définit s’il faut charger l’état en mémoire ou le conserver sur le disque, et s’il faut chiffrer l’état s’il est conservé sur le disque.
  • Délégué de consentement : définit l’utilisation mip::ConsentDelegate pour les opérations de consentement.
  • Observateur de profil de fichier : définit l’implémentation mip::FileProfile::Observer à utiliser pour les rappels asynchrones pour les opérations de profil.

Paramètres de profil

  • MipContext : L’objet MipContext initialisé pour stocker les informations de l’application, le chemin d’état, etc.
  • CacheStorageType : Définit comment stocker l’état : en mémoire, sur le disque ou sur le disque et chiffré.
  • consentDelegate : pointeur partagé de classe mip::ConsentDelegate.
  • observer : pointeur partagé vers l’implémentation du profil Observer (dans PolicyProfile, ProtectionProfile et FileProfile).
  • applicationInfo : un objet mip::ApplicationInfo. Informations sur l’application qui consomme le Kit de développement logiciel (SDK) et correspond à votre ID et nom d’inscription d’application Microsoft Entra.

Moteurs

Les moteurs du Kit de développement logiciel (SDK) File, Policy et Protection fournissent une interface pour les opérations effectuées par une identité spécifique. Ajoutez un moteur à l’objet de profil pour chaque utilisateur ou principal de service qui se connecte à l’application. Vous pouvez effectuer des opérations déléguées à l’aide de mip::ProtectionSettings et du gestionnaire de fichiers ou du gestionnaire de protection. Pour plus d’informations, consultez la section des paramètres de protection dans les concepts de FileHandler.

Le Kit de développement logiciel (SDK) comporte trois classes de moteur, une pour chaque API. La liste suivante présente les classes de moteur et quelques-unes des fonctions associées à chacune d’elles :

  • mip::ProtectionEngine
  • mip::PolicyEngine
    • ListSensitivityLabels() : obtient la liste des étiquettes pour le moteur chargé.
    • GetSensitivityLabel() : obtient le label à partir du contenu existant.
    • ComputeActions() : fourni avec un ID d’étiquette et des métadonnées facultatives, retourne la liste des actions qui doivent se produire pour un élément spécifique.
  • mip::FileEngine
    • ListSensitivityLabels() : obtient la liste des étiquettes pour le moteur chargé.
    • CreateFileHandler() : crée un mip::FileHandler pour un fichier ou un flux spécifique.

Pour créer un moteur, transmettez un objet de paramètres de moteur spécifique qui contient les paramètres du type de moteur à créer. L’objet paramètres permet au développeur de spécifier des détails sur l’identificateur du moteur, l’implémentation mip::AuthDelegate , les paramètres régionaux, les paramètres personnalisés et d’autres détails spécifiques à l’API.

États du moteur

Un moteur peut avoir l’un des deux états suivants :

  • CREATED : cet état indique que le SDK dispose de suffisamment de données d’état local après avoir appelé les services backend requis.
  • LOADED : le kit de développement logiciel (SDK) a créé les structures de données requises pour que le moteur soit opérationnel.

Un moteur doit être créé et chargé pour effectuer toutes les opérations. La classe Profile expose quelques méthodes de gestion du moteur : AddEngineAsync, DeleteEngineAsync et UnloadEngineAsync.

Le tableau suivant décrit les états du moteur possibles et les méthodes qui peuvent changer cet état :

État moteur Aucune CREATED CHARGÉ
Aucune AddEngineAsync
CREATED DeleteEngineAsync AddEngineAsync
CHARGÉ DeleteEngineAsync UnloadEngineAsync

ID du moteur

Chaque moteur a un identificateur unique, idutilisé dans toutes les opérations de gestion du moteur. L’application peut fournir un id. Si l’application n’en fournit pas, le Kit de développement logiciel (SDK) peut le générer. Toutes les autres propriétés du moteur, telles que l’adresse e-mail dans les informations d’identité, sont des charges utiles opaques pour le Kit de développement logiciel (SDK). Le Kit de développement logiciel (SDK) n’effectue pas de logique pour conserver d’autres propriétés uniques ou appliquer d’autres contraintes.

Importante

Utilisez un ID de moteur unique à l’utilisateur et utilisez cet ID de moteur chaque fois que l’utilisateur effectue une opération avec le Kit de développement logiciel (SDK). Si vous ne fournissez pas d’ID de moteur unique existant pour un utilisateur ou un service, le SDK effectue des allers-retours de service supplémentaires. Ces allers-retours de service peuvent entraîner une dégradation et une limitation des performances.

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

Méthodes de gestion du moteur

Le Kit de développement logiciel (SDK) a trois méthodes de gestion du moteur : AddEngineAsync, DeleteEngineAsyncet UnloadEngineAsync.

AddEngineAsync

Cette méthode charge un moteur existant ou en crée un s’il n’existe pas déjà dans l’état local.

Si l’application ne fournit pas un id dans FileEngineSettings, AddEngineAsync génère un nouvel id. Il vérifie ensuite si un moteur avec ce id existe déjà dans le cache de stockage local. Si tel est le cas, il charge alors le moteur. Si le moteur n’existe pas dans le cache local, un nouveau moteur est créé en appelant les API et les services principaux nécessaires.

Dans les deux cas, si la méthode réussit, le moteur est chargé et prêt à être utilisé.

DeleteEngineAsync

Supprime le moteur avec le id donné. Toutes les traces du moteur sont supprimées du cache local.

UnloadEngineAsync

Décharge les structures de données en mémoire du moteur avec le id spécifié. L’état local de ce moteur reste intact et vous pouvez le recharger avec AddEngineAsync.

Cette méthode permet à l’application d’être judicieuse au sujet de l’utilisation de la mémoire, en déchargeant les moteurs qui ne sont pas censés être utilisés prochainement.

Étapes suivantes

  • Last updated on