Partager via

Kit SDK Microsoft Information Protection : concepts des objets de profil et moteur

Profils

Quand le MipContext est la classe permettant de stocker des paramètres spécifiques au kit de développement logiciel (SDK), le profil est la classe racine pour toutes les opérations spécifiques à l’étiquetage et à la protection MIP dans le kit de développement logiciel (SDK) MIP. Avant d’utiliser l’un des trois ensembles d’API, l’application cliente doit créer un profil. Les opérations futures sont effectuées par le profil ou par d’autres objets ajoutés au profil. Un seul objet de profil par processus est recommandé. La création de plus d'un élément peut entraîner un comportement inattendu.

Il existe trois types de profil dans le kit de développement logiciel (SDK) MIP :

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

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

  • Définit si l’état doit être chargé en mémoire ou conservé sur le disque et, s’il est conservé sur le disque, s’il doit être chiffré.
  • Définit le mip::ConsentDelegate qui doit être utilisé pour les opérations de consentement.
  • Définit l’implémentation de mip::FileProfile::Observer qui sera utilisée pour les rappels asynchrones pour les opérations de profil.

Paramètres du 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), qui correspond à votre ID et nom d’inscription d’application Microsoft Entra.

Moteurs

Les moteurs du kit de développement logiciel (SDK) Ficher, Profil et Protection fournissent une interface pour les opérations effectuées par une identité spécifique. Un moteur est ajouté à l’objet Profile pour chaque utilisateur ou principal de service qui se connecte à l’application. Il est possible d’effectuer des opérations déléguées via mip::ProtectionSettings et le gestionnaire de fichiers ou de protection. Pour plus d’informations, consultez la section Paramètres de protection dans les concepts de FileHandler.

Il existe trois classes de moteur dans le kit de développement logiciel (SDK), 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.

La création d’un moteur nécessite de passer 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 de mip::AuthDelegate, la locale et les paramètres personnalisés, ainsi que 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, id, qui est utilisé dans toutes les opérations de gestion du moteur. L’application peut fournir un id, ou le kit de développement logiciel (SDK) peut en générer un, s’il n’est pas fourni par l’application. Toutes les autres propriétés du moteur (par ex. 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 AUCUNE logique pour conserver l’une des autres propriétés uniques ou appliquer d’autres contraintes.

Importante

**En guise de bonne pratique, utilisez un ID de moteur unique à l’utilisateur et utilisez-le chaque fois que l’utilisateur effectue une opération avec le kit de développement logiciel (SDK). La non-fourniture d'un engineId unique existant pour un utilisateur ou un service entraînera des allers-retours inutiles. 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

Comme mentionné précédemment, il existe trois méthodes de gestion du moteur dans le kit de développement logiciel (SDK) : AddEngineAsync, DeleteEngineAsync et 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 est toujours intact et peut être rechargé 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