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

Perfiles

Donde la es la clase para almacenar la configuración específica del SDK, el perfil es la clase raíz para todas las operaciones de etiquetado y protección específicas de MIP en MipContext el SDK de MIP. Antes de usar cualquiera de los tres conjuntos de API, la aplicación cliente debe crear un perfil. El perfil o otros objetos agregados al perfil realizan operaciones futuras. Solo se recomienda un único objeto de perfil por proceso. Crear más de uno puede provocar un comportamiento inesperado.

Hay tres tipos de perfil en el SDK de MIP:

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

El perfil en sí proporciona la siguiente funcionalidad:

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

Perfil Configuración

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

Motores

Los motores del SDK de archivo, perfil y protección proporcionan una interfaz para las operaciones realizadas por una identidad específica. Se agrega un motor al objeto Perfil para cada usuario o entidad de servicio que inicia sesión en la aplicación. Es posible realizar operaciones delegadas a través mip::ProtectionSettings del controlador de protección o archivo. Vea la sección configuración de 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 del motor cargado.
    • GetSensitivityLabel(): Obtiene la etiqueta del contenido existente.
    • ComputeActions(): Se proporciona un identificador de etiqueta y metadatos opcionales, devuelve la lista de acciones que deben producirse para un elemento específico.
  • mip::FileEngine
    • ListSensitivityLabels(): Obtiene la lista de etiquetas del motor cargado.
    • CreateFileHandler(): Crea una para un archivo o una transmisión mip::FileHandler específicos.

Crear 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, la configuración regional y la configuración personalizada, así como otros detalles específicos mip::AuthDelegate de la API.

Estados del motor

Un motor puede tener uno de dos estados:

  • CREATED: Creado 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.

Un motor debe crearse y cargarse para realizar cualquier operación. La Profile clase expone algunos métodos de administración de motores: , y AddEngineAsyncDeleteEngineAsyncUnloadEngineAsync .

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

Estado del motor NONE CREADO CARGADO
NONE AddEngineAsync
CREADO DeleteEngineAsync AddEngineAsync
CARGADO DeleteEngineAsync UnloadEngineAsync

Id. del motor

Cada motor tiene un identificador único, id que se usa en todas las operaciones de administración de motores. La aplicación puede proporcionar una o el SDK puede generar una, si no la proporciona id la aplicación. Todas las demás propiedades del motor (por ejemplo, la dirección de correo electrónico en la información de identidad) son cargas opacas para el SDK. El SDK NO realiza ninguna lógica para mantener ninguna de las otras propiedades únicas o exigir cualquier otra restricción.

Importante

**Como procedimiento recomendado, use un id. de motor único para el usuario y úselo cada vez que el usuario realice una operación con el SDK. Si no se proporciona un engineId único existente para un usuario o servicio, se realizarán viajes de ida y vuelta de servicio adicionales. Estos viajes de ida y vuelta del servicio pueden provocar degradación del rendimiento y limitació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

Métodos de administración de motores

Como se mencionó anteriormente, hay tres métodos de administración de motores en el SDK: AddEngineAsyncDeleteEngineAsync , y 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 una id entrada , genera un nuevo archivo FileEngineSettingsAddEngineAsyncid . A continuación, comprueba si un motor con el que ya id existe 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 llamando a las API y servicios back-end necesarios.

En ambos casos, si el método se realiza correctamente, el motor está cargado y listo para usarse.

DeleteEngineAsync

Elimina el motor con el determinado id . Todos los seguimientos del motor se quitan de la caché local.

UnloadEngineAsync

Descarga las estructuras de datos en memoria del motor con el determinado id . 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 juiciosa sobre el uso de memoria descargando motores que no se espera que se usen pronto.

Pasos siguientes