Partager via

Kit de développement logiciel (SDK) Microsoft Information Protection - Stockage du cache

  • Article

Le SDK MIP implémente une base de données SQLite3 pour maintenir le stockage du cache du SDK. Avant la version 1.3 du kit de développement logiciel (SDK) Microsoft Information Protection, seuls deux types de stockage d’état du cache ont été pris en charge : sur disque et en mémoire. Ces deux types ont stocké certaines données, notamment des licences pour le contenu protégé et les informations de stratégie, en texte clair.

Pour améliorer l’état de la sécurité du kit de développement logiciel (SDK), nous avons ajouté la prise en charge d’un deuxième type de cache de disque qui utilise des API de chiffrement spécifiques à la plateforme pour protéger la base de données et son contenu.

L’application définit le type de cache lors du chargement du profil dans les objets FileProfileSettings, PolicyProfileSettings ou ProtectionProfileSettings. Le type de cache est statique pour la durée du profil. Le passage à un autre type de stockage de cache nécessite de détruire le profil existant et d’en créer un nouveau.

Types de stockage de cache

À compter de la version 1.3 du kit de développement logiciel (SDK) MIP, les types de cache de stockage suivants sont disponibles.

Type Objectif
InMemory Conserve le cache de stockage en mémoire dans l’application.
OnDisk Stocke la base de données sur le disque dans l’annuaire fourni dans l’objet paramètres. La base de données est stockée en texte clair.
OnDiskEncrypted Stocke la base de données sur le disque dans l’annuaire fourni dans l’objet paramètres. La base de données est chiffrée à l’aide d’API spécifiques au système d’exploitation.

Chaque moteur généré par l’application génère une nouvelle clé de chiffrement.

Le stockage du cache est défini via l’un des objets de paramètres de profil, via l’énumération 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>());

Quand utiliser chaque type

Le stockage du cache est important pour maintenir l’accès hors connexion aux informations précédemment déchiffrées et garantir les performances des opérations de déchiffrement lorsque les données ont été consommées précédemment.

  • Stockage en mémoire : utilisez ce type de stockage pour les processus de longue durée où la persistance des informations de cache de stratégie ou de cache de licence sur les redémarrages de service n’est pas nécessaire.
  • Sur disque : utilisez ce type de stockage pour les applications où les processus peuvent souvent s’arrêter et redémarrer, mais doivent conserver le cache de stratégie, de licence et de découverte de service entre les redémarrages. Ce type de cache de stockage est en texte clair. Il convient donc mieux aux charges de travail de serveur où les utilisateurs n’auront pas accès au stockage d’état. Des exemples de ce charge incluent un service Windows ou un démon Linux s’exécutant sur un serveur ou une application SaaS où seuls les administrateurs de service auraient accès aux données d’état.
  • Sur disque et chiffré : utilisez ce type de stockage pour les applications où les processus peuvent souvent s’arrêter et démarrer, mais doivent conserver le cache de stratégie, de licence et de découverte de service entre les redémarrages. Ce cache de stockage est chiffré. Il convient donc mieux aux applications de station de travail où un utilisateur peut parcourir et découvrir la base de données d’état. Le chiffrement permet de s’assurer que les utilisateurs indiscrets n’auront pas accès via le contenu de la stratégie ou le contenu de la licence de protection en texte brut. Il est important de noter que dans tous les cas, les données sont chiffrées avec des clés auxquelles l’utilisateur peut accéder. Un adversaire qualifié est en mesure de déchiffrer le cache avec un effort minimal, mais cela empêche la falsification et la navigation.

Plateformes prises en charge pour le chiffrement

Plateforme Version Notes
Microsoft Windows Windows 8 et ultérieur Windows 7 prend uniquement en charge CacheStorageType::OnDisk
macOS High Sierra et versions ultérieures
Ubuntu Linux 16.04 et versions ultérieures Nécessite SecretService et l’indicateur de fonctionnalité LinuxEncryptedCache.
Android Android 7.0 ou version ultérieure
iOS Toutes les versions prises en charge

Bien que le SDK MIP prenne en charge d’autres distributions Linux, nous n’avons pas testé le chiffrement du cache sur RedHat Enterprise Linux, CentOS ou Debian.

Remarque

L’indicateur de fonctionnalité permettant d’activer le stockage de cache sur Linux est défini via mip::MipConfiguration::SetFeatureSettings()

Mettre en cache les tables de base de données de stockage

Le SDK MIP gère deux bases de données pour le cache. Il s’agit des kits de développement logiciel (SDK) Protection et de la maintenance des détails de l’état de protection. L’autre est destinée aux SDK Policy et à la gestion des détails de la stratégie et des informations de service. Les deux sont stockées dans le chemin défini dans l’objet settings, sous mip\mip.policies.sqlite3 et mip\mip.protection.sqlite3.

Remarque

Le SDK MIP ne garantit pas la compatibilité entre différentes versions de son cache. Il est recommandé d’effacer tous les fichiers dans le répertoire mip\ ou tout autre répertoire modifié par défaut avant de mettre à niveau l’application vers une nouvelle version du SDK MIP.

Base de données de protection

Table Objectif Chiffré
AuthInfoStore Stocke les détails de la demande d’authentification. Non
ConsentStore Stocke les résultats de consentement pour chaque moteur. Non
DnsInfoStore Stocke les résultats de recherche DNS pour les opérations de protection Non
EngineStore Stocke les détails du moteur, l’utilisateur associé et les données client personnalisées Non
KeyStore Stocke les clés de chiffrement symétriques pour chaque moteur. Oui
LicenseStore Stocke les informations de licence pour les données précédemment déchiffrées. Oui
SdInfoStore Stocke les résultats de la découverte de service. Non

Remarque

Le cache LicenseStore nécessite une identité à définir sur le moteur de protection ou le moteur de fichiers.

Base de données de stratégie

Table Objectif Chiffré
KeyStore Stocke les clés de chiffrement symétriques pour chaque moteur. Oui
Stratégies Stocke les informations de stratégie des étiquettes pour chaque utilisateur. Oui
PoliciesUrl Stocke l’URL du service de stratégie back-end pour un utilisateur spécifique. Non
Confidentialité Stocke les règles de classification pour une stratégie d’utilisateur spécifique. Oui
SensitivityUrls Stocke l’URL du service de stratégie de confidentialité back-end pour un utilisateur spécifique. Non

Considérations liées à la taille de la base de données

La taille de la base de données dépend de deux facteurs : la quantité de moteurs ajoutés au cache et la quantité de licences de protection mises en cache. À compter du SDK MIP 1.3, il n’existe aucun mécanisme permettant de nettoyer le cache de licences quand il expire. Un processus externe est nécessaire pour supprimer le cache s’il grandit au-delà de ce que vous souhaitez.

Le contributeur le plus important à la croissance de la base de données sera le cache de licences de protection. Si la mise en cache des licences n’est pas nécessaire, soit parce que les allers-retours de service n’affectent pas les performances de votre application, soit parce que le cache peut augmenter pour atteindre une trop grande taille, le cache de licences peut être désactivé. Pour ce faire, définissez CanCacheLicenses sur l’objet FileProfile::Settings à faux.

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

profileSettings.SetCanCacheLicenses(false);

Moteurs de mise en cache

Dans le kit de développement logiciel (SDK) MIP, un moteur est créé pour chaque utilisateur effectuant une opération authentifiée. Les moteurs fournissent une interface pour toutes les opérations effectuées au nom d’une identité authentifiée. Comme indiqué dans les concepts profils et moteurs, FileEngine, PolicyEngine ou ProtectionEngine ont chacun deux états CREATED et LOADED. Un moteur doit être créé et chargé pour pouvoir effectuer des opérations du kit de développement logiciel (SDK). Si un moteur n’est pas utilisé, le SDK met en cache le moteur et le conserve dans l’état CREATED aussi longtemps que possible en fonction des ressources disponibles. Chaque classe de profil du SDK respectif fournit également une méthode UnloadEngineAsync pour y parvenir explicitement.

Chaque moteur possède un identificateur unique id utilisé dans toutes les opérations de gestion du moteur. L’application cliente peut fournir explicitement un ID, ou le SDK peut en générer un, s’il n’est pas fourni par l’application. Si un identificateur unique est fourni à l’aide d’objets de paramètres de moteur au moment de la création du moteur et que la mise en cache est activée dans le profil d’API, comme décrit ci-dessus, les mêmes moteurs peuvent être utilisés chaque fois que l’utilisateur effectue une opération avec le kit de développement logiciel (SDK). Suivez les extraits de code pour créer 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).

L’échec de la fourniture d’un engineId existant entraîne des allers-retours de service supplémentaires pour récupérer la stratégie et récupère des licences qui ont peut-être déjà été mises en cache pour le moteur existant. La mise en cache de l’ID du moteur permet au SDK hors connexion d’accéder aux informations précédemment déchiffrées et aux améliorations générales des performances.

Étapes suivantes

Ensuite, apprenez-en davantage sur les concepts d’objet Profile et Engine pour comprendre comment définir correctement les ID de moteur MIP pour utiliser correctement la mise en cache du SDK MIP.