Compartir a través de


SDK de Microsoft Information Protection: Almacenamiento en caché

El SDK de MIP implementa una base de datos SQLite3 para mantener el almacenamiento en caché del SDK. Antes de la versión 1.3 del SDK de Microsoft Information Protection, solo se admitían dos tipos de almacenamiento de estado de caché: en disco y en memoria. Ambos tipos almacenaban determinados datos, específicamente licencias para información de directiva y contenido protegido, en texto no cifrado.

Para mejorar la posición de seguridad del SDK, se ha agregado compatibilidad con un segundo tipo en la caché de disco que usa API criptográficas específicas de la plataforma para proteger la base de datos y su contenido.

La aplicación define el tipo de caché al cargar el perfil como parte de los objetos FileProfileSettings, PolicyProfileSettings o ProtectionProfileSettings. El tipo de caché es estático durante la vida útil del perfil. Cambiar a otro tipo de almacenamiento de caché requiere destruir el perfil existente y crear uno nuevo.

Tipos de almacenamiento en caché

A partir de la versión 1.3 del SDK de MIP, están disponibles los siguientes tipos de caché de almacenamiento.

Tipo Fin
InMemory Mantiene la memoria caché de almacenamiento en la memoria en la aplicación.
OnDisk Almacena la base de datos en el disco del directorio proporcionado en el objeto de configuración. La base de datos se almacena en texto no cifrado.
OnDiskEncrypted Almacena la base de datos en el disco del directorio proporcionado en el objeto de configuración. La base de datos se cifra mediante API específicas del sistema operativo.

Cada motor generado por la aplicación genera una nueva clave de cifrado.

El almacenamiento en caché se establece a través de uno de los objetos de configuración de perfil, a través de la enumeración mip::CacheStorageType.

FileProfile::Settings profileSettings(mMipContext,
    mip::CacheStorageType::OnDiskEncrypted, // Define the storage type to use.
    mAuthDelegate,
    std::make_shared<sample::consent::ConsentDelegateImpl>(),
    std::make_shared<FileProfileObserver>());

Cuándo usar cada tipo

El almacenamiento en caché es importante para mantener el acceso sin conexión a información previamente descifrada y garantizar el rendimiento de las operaciones de descifrado cuando los datos se han consumido anteriormente.

  • En Almacenamiento en memoria: use este tipo de almacenamiento para los procesos de larga duración en los que no es necesario conservar la información de caché de la directiva o licencia entre reinicios del servicio.
  • En disco: use este tipo de almacenamiento para las aplicaciones en las que los procesos pueden detenerse e iniciarse con frecuencia, pero deben mantener la caché de directivas, licencias y detección de servicios entre reinicios. Este tipo de caché de almacenamiento es texto no cifrado, por lo que es más adecuado para cargas de trabajo de servidor en las que los usuarios no tendrán acceso al almacenamiento de estado. Algunos ejemplos de esto serían un servicio de Windows o un demonio de Linux que se ejecuta en un servidor o una aplicación SaaS en la que solo los administradores de servicios tuvieran acceso a los datos de estado.
  • En disco y cifrado: use este tipo de almacenamiento para las aplicaciones en las que los procesos pueden detenerse e iniciarse con frecuencia, pero deben mantener la caché de directivas, licencias y detección de servicios entre reinicios. Esta caché de almacenamiento está cifrada, por lo que es más adecuada para las aplicaciones de estación de trabajo en las que un usuario puede examinar y detectar la base de datos de estado. El cifrado ayuda a garantizar que los usuarios indebidos no tengan acceso a través del contenido de la directiva o el contenido de la licencia de protección en texto sin formato. Es importante tener en cuenta que, en todos los casos, los datos se cifran con claves a las que el usuario puede acceder. Un adversario cualificado puede descifrar la memoria caché con un esfuerzo mínimo, pero esto evita alteraciones y exploración.

Plataformas admitidas para el cifrado

Plataforma Versión Notas
Microsoft Windows Windows 8 y más recientes Windows 7 solo admite CacheStorageType::OnDisk
macOS High Sierra y versiones posteriores
Ubuntu Linux 16.04 y versiones posteriores Requiere la marca de características SecretService y LinuxEncryptedCache.
Android Android 7.0 o posterior
iOS Todas las versiones compatibles

Aunque el SDK de MIP admite otras distribuciones de Linux, no probamos el cifrado de caché en RedHat Enterprise Linux, CentOS o Debian.

Nota

La marca de características para habilitar el almacenamiento en caché en Linux se establece mediante mip::MipConfiguration::SetFeatureSettings()

Tablas de base de datos de almacenamiento en caché

El SDK de MIP mantiene dos bases de datos para la memoria caché. Uno es para los SDK de protección y el mantenimiento de los detalles del estado de protección. El otro es para los SDK de directiva y el mantenimiento de los detalles de la directiva y la información del servicio. Ambos se almacenan en la ruta de acceso definida en el objeto de configuración, en mip\mip.policies.sqlite3 y mip\mip.protection.sqlite3.

Nota:

El SDK de MIP no garantiza la compatibilidad entre distintas versiones de su caché. Es aconsejable borrar todos los archivos del directorio mip\ o cualquier directorio alternativo cambiado de configuración predeterminada, antes de actualizar la aplicación a una nueva versión del SDK de MIP.

Bases de datos de protección

Tabla Fin Cifrados
AuthInfoStore Almacena los detalles del desafío de autenticación. No
ConsentStore Almacena los resultados de consentimiento de cada motor. No
DnsInfoStore Almacena los resultados de búsqueda de DNS para las operaciones de protección No
EngineStore Almacena los detalles del motor, el usuario asociado y los datos de cliente personalizados No
KeyStore Almacena claves de cifrado simétricas para cada motor.
LicenseStore Almacena la información de licencia de uso para los datos descifrados previamente.
SdInfoStore Almacena los resultados de la detección de servicios. No

Nota:

La caché de LicenseStore requiere que se establezca una identidad en el motor de protección o en el motor de archivos.

Base de datos de directiva

Tabla Fin Cifrados
KeyStore Almacena claves de cifrado simétricas para cada motor.
Directivas Almacena información de directiva de etiquetas para cada usuario.
PoliciesUrl Almacena la dirección URL del servicio de directiva de back-end para un usuario específico. No
Sensibilidad Almacena reglas de clasificación para una directiva de usuario específica.
SensitivityUrls Almacena la dirección URL del servicio de directiva de confidencialidad de back-end para un usuario específico. No

Consideraciones sobre el tamaño de la base de datos

El tamaño de la base de datos depende de dos factores: la cantidad de motores que se agregan a la memoria caché y la cantidad de licencias de protección que se han almacenado en caché. A partir del SDK de MIP 1.3, no hay ningún mecanismo para limpiar la caché de licencias a medida que expiran. Tendrá que haber un proceso externo para eliminar la memoria caché si crece más de lo que se desea.

El colaborador más significativo para el crecimiento de la base de datos será la caché de licencias de protección. Si no se requiere el almacenamiento en caché de licencias, ya sea porque los recorridos de ida y vuelta del servicio no afectarán al rendimiento de la aplicación o porque la memoria caché puede aumentar demasiado, la caché de licencias puede deshabilitarse. Para ello, establezca CanCacheLicenses en el objeto FileProfile::Settings en falso.

FileProfile::Settings profileSettings(mMipContext,
    mip::CacheStorageType::OnDiskEncrypted,
    mAuthDelegate,
    std::make_shared<sample::consent::ConsentDelegateImpl>(),
    std::make_shared<FileProfileObserver>());

profileSettings.SetCanCacheLicenses(false);

Motores de almacenamiento en caché

En el SDK de MIP, se crea un motor para cada usuario que realiza cualquier operación autenticada. Los motores proporcionan una interfaz para todas las operaciones que se realizan en nombre de una identidad autenticada. Como se describe en Los conceptos de perfiles y motores, FileEngine, PolicyEngine o ProtectionEngine cada uno tiene dos estados CREATED y LOADED. Es necesario crear y cargar un motor para que pueda realizar operaciones del SDK. Si un motor no está en uso, el SDK almacena en caché el motor y lo conserva en el estado CREATED siempre que sea posible, en función de los recursos disponibles. Cada clase de perfil del SDK respectiva también proporciona un método UnloadEngineAsync para lograr esto explícitamente.

Cada motor tiene un identificador único id que se usa en todas las operaciones de administración del motor. La aplicación cliente puede proporcionar un id. explícitamente, o el SDK puede generar uno, si la aplicación no lo proporciona. Si se proporciona un identificador único mediante objetos de configuración del motor en el momento de la creación del motor y el almacenamiento en caché está habilitado en el perfil de API, como se ha descrito anteriormente, se pueden usar los mismos motores cada vez que el usuario realiza una operación con el SDK. Siga los fragmentos de código para crear un [mip::FileEngine](./concept-profile-engine-file-engine-cpp.md#create-file-engine-settings), [mip::PolicyEngine](./concept-profile-engine-policy-engine-cpp.md#implementation-create-policy-engine-settings).

Si no se proporciona un engineId existente, se producirán recorridos de ida y vuelta de servicio adicionales para capturar la directiva y se capturarán licencias que puede que ya se hayan almacenado en caché para el motor existente. El almacenamiento en caché del id. del motor permite que el SDK acceda sin conexión a información previamente descifrada y mejoras generales de rendimiento.

Pasos siguientes

A continuación, obtenga más información sobre los conceptos de objetos de perfil y motor para comprender cómo establecer correctamente los identificadores de motor de MIP para usar correctamente el almacenamiento en caché del SDK de MIP.