SDK de Microsoft Information Protection: conceptos de objetos de perfil y motor

Perfiles

La MipContext clase almacena la configuración específica del SDK. El perfil es la clase raíz para 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. El perfil u otros objetos agregados al perfil realizan operaciones futuras. Use solo un objeto de perfil por proceso. La creación de más de una podría dar lugar a un comportamiento inesperado.

El SDK de MIP tiene tres tipos de perfil:

  • 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 que usa la aplicación de consumo determina qué clase de perfil se va a usar.

El perfil proporciona la funcionalidad siguiente:

  • Almacenamiento de estado: define si se va a cargar el estado en la memoria o conservarlo en el disco y si se debe cifrar el estado si se conserva en el disco.
  • Delegado de consentimiento: define el objeto mip::ConsentDelegate que se va a usar para las operaciones de consentimiento.
  • Observador de perfiles de archivo: Define la implementación mip::FileProfile::Observer que se utilizará para las devoluciones de llamada asíncronas en las operaciones de perfil.

Configuración de 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: Un puntero compartido a 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 y cuyos identificador y nombre coinciden con los del registro de la aplicación en Microsoft Entra.

Motores

Los motores del SDK de archivos, directivas y protección proporcionan una interfaz para las operaciones realizadas por una identidad específica. Agregue un motor al objeto de perfil para cada usuario o entidad de servicio que inicie sesión en la aplicación. Puede realizar operaciones delegadas mediante mip::ProtectionSettings y el controlador de archivos o protección. Para obtener más información, consulte la sección configuración de protección en los conceptos de FileHandler.

El SDK tiene tres clases de motor, 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.

Para crear un motor, pase 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, la mip::AuthDelegate configuración regional, la configuración personalizada y otros detalles específicos de la API.

Estados del motor

Un motor puede tener uno de 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, , idque se usa en todas las operaciones de administración del motor. La aplicación puede proporcionar un id. Si la aplicación no proporciona una, el SDK puede generarla. Todas las demás propiedades del motor, como la dirección de correo electrónico de la información de identidad, son cargas opacas para el SDK. El SDK no realiza lógica para mantener ninguna otra propiedad única ni aplicar otras restricciones.

Importante

Use un identificador de motor único para el usuario y use ese identificador de motor cada vez que el usuario realice una operación con el SDK. Si no se proporciona un identificador de motor único y ya existente para un usuario o servicio, el SDK realiza idas y vueltas adicionales al servicio. Estas idas y vueltas al servicio pueden provocar una degradación del rendimiento y una limitación de ancho de banda.

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

El SDK tiene tres métodos de administración del motor: AddEngineAsync, DeleteEngineAsyncy UnloadEngineAsync.

AddEngineAsync

Este método carga un motor existente o crea uno si aún no existe en 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 se mantiene intacto, y puedes volver a cargarlo 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

  • Last updated on