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. | Sí |
LicenseStore | Almacena la información de licencia de uso para los datos descifrados previamente. | Sí |
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. | Sí |
Directivas | Almacena información de directiva de etiquetas para cada usuario. | Sí |
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. | Sí |
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.