Compartir a través de

SDK de Microsoft Information Protection: conceptos de los objetos Perfil y Motor

  • Artículo

Perfiles

En aquellos casos en los que MipContext es la clase para almacenar la configuración específica del SDK, el perfil es la clase raíz de todas las operaciones específicas de etiquetado y protección de MIP en el SDK de MIP. Antes de usar cualquiera de los tres conjuntos de API, la aplicación cliente debe crear un perfil. Las operaciones futuras las realiza el perfil u otros objetos agregados al perfil. Se recomienda tener un único objeto de perfil por proceso. La creación de más de un objeto puede dar lugar a un comportamiento inesperado.

Hay tres tipos de perfil en el SDK de MIP:

  • PolicyProfile: la clase de perfil para el SDK de directivas de MIP.
  • ProtectionProfile: la clase de perfil para el SDK de protección de MIP.
  • FileProfile: la clase de perfil para el SDK de archivos de MIP.

La API usada en la aplicación de consumo determina qué clase de perfil se debe usar.

El perfil proporciona la funcionalidad siguiente:

  • Define si el estado debe cargarse en la memoria o conservarse en el disco y, si se conserva en el disco, si debe cifrarse.
  • Define el objeto mip::ConsentDelegate que se debe usar para las operaciones de consentimiento.
  • Define la implementación de mip::FileProfile::Observer que se usará para devoluciones de llamada asincrónicas para las operaciones del perfil.

Configuración del perfil

  • MipContext: objeto MipContext que se inicializó para almacenar la información de la aplicación, la ruta de acceso de estado, etc.
  • CacheStorageType: define cómo almacenar el estado: en la memoria, en el disco o en el disco con cifrado.
  • consentDelegate: puntero compartido de la clase mip::ConsentDelegate.
  • observer: puntero compartido en la implementación del perfil Observer (en PolicyProfile, ProtectionProfile y FileProfile).
  • applicationInfo: un objeto mip::ApplicationInfo. Información sobre la aplicación que consume el SDK, que coincide con el id. y el nombre del registro de aplicación de Microsoft Entra.

Motores

Los motores del SDK de archivos, perfil y protección proporcionan una interfaz para las operaciones realizadas por una identidad específica. Se agrega un motor al objeto Profile para cada usuario o entidad de servicio que inicie sesión en la aplicación. Es posible realizar operaciones delegadas a través de mip::ProtectionSettings y el controlador de archivos o protección. Consulte la sección de configuración de la protección en los conceptos de FileHandler para obtener más información.

Hay tres clases de motor en el SDK, una para cada API. En la lista siguiente se muestran las clases de motor y algunas de las funciones asociadas a cada una de ellas:

  • mip::ProtectionEngine
  • mip::PolicyEngine
    • ListSensitivityLabels(): obtiene la lista de etiquetas para el motor cargado.
    • GetSensitivityLabel(): obtiene la etiqueta del contenido existente.
    • ComputeActions(): se proporciona con un identificador de etiqueta y metadatos opcionales, y devuelve la lista de acciones que deben producirse para un elemento específico.
  • mip::FileEngine
    • ListSensitivityLabels(): obtiene la lista de etiquetas para el motor cargado.
    • CreateFileHandler(): crea un mip::FileHandler para un archivo o una secuencia específicos.

La creación de un motor requiere pasar un objeto de configuración de motor específico que contenga la configuración del tipo de motor que se va a crear. El objeto de configuración permite al desarrollador especificar detalles sobre el identificador del motor, la implementación de mip::AuthDelegate, la configuración regional y la configuración personalizada, así como otros detalles específicos de la API.

Estados del motor

Un motor puede tener uno de estos dos estados:

  • CREATED: indica que el SDK tiene suficiente información de estado local después de llamar a los servicios back-end necesarios.
  • LOADED: el SDK ha creado las estructuras de datos necesarias para que el motor esté operativo.

Debe crearse y cargarse un motor para poder realizar cualquier operación. La clase Profile expone algunos métodos de administración de motores: AddEngineAsync, DeleteEngineAsync y UnloadEngineAsync.

En la tabla siguiente se describen los posibles estados del motor y qué métodos pueden cambiar ese estado:

Estado del motor NONE CREATED LOADED
NONE AddEngineAsync
CREATED DeleteEngineAsync AddEngineAsync
LOADED DeleteEngineAsync UnloadEngineAsync

Id. del motor

Cada motor tiene un identificador único, id, que se usa en todas las operaciones de administración del motor. La aplicación puede proporcionar un id. En caso contrario, el SDK puede generar uno. El resto de propiedades del motor (por ejemplo, la dirección de correo electrónico de la información de identidad) son cargas opacas para el SDK. El SDK NO ejecuta ninguna lógica para mantener ninguna de las demás propiedades exclusivas o aplicar cualquier otra restricción.

Importante

** A modo de procedimiento recomendado, use un identificador de motor que sea único para el usuario y úselo cada vez que el usuario realice una operación con el SDK. Si no se proporciona un id. del motor existente y único para un usuario o servicio, se producirán recorridos de ida y vuelta adicionales del servicio. Estos recorridos de ida y vuelta del servicio pueden provocar una degradación del rendimiento y otras limitaciones. **

// 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étodos de administración del motor

Como se mencionó anteriormente, hay tres métodos de administración del motor en el SDK: AddEngineAsync, DeleteEngineAsync y UnloadEngineAsync.

AddEngineAsync

Este método carga un motor existente o crea uno si aún no existe un motor con el estado local.

Si la aplicación no proporciona un id en FileEngineSettings, AddEngineAsync genera un nuevo id. A continuación, comprueba si ya existe algún motor con ese id en la caché de almacenamiento local. Si lo hace, carga ese motor. Si el motor no existe en la memoria caché local, se crea un nuevo motor. Para ello, se llama a las API y los servicios back-end necesarios.

En ambos casos, si el método se completa correctamente, el motor se carga y estará listo para usarse.

DeleteEngineAsync

Elimina el motor con el id especificado. Se elimina todo rastro del motor en la caché local.

UnloadEngineAsync

Descarga las estructuras de datos en la memoria para el motor con el id especificado. El estado local de este motor sigue intacto y se puede volver a cargar con AddEngineAsync.

Este método permite que la aplicación sea prudente con el uso de la memoria, descargando motores que no se prevé que se usen a corto plazo.

Pasos siguientes