Condividi tramite

Microsoft Information Protection SDK - Archiviazione cache

MIP SDK implementa un database SQLite3 per la gestione dell'archiviazione della cache dell'SDK. Prima della versione 1.3 di Microsoft Information Protection SDK, sono stati supportati solo due tipi di archiviazione dello stato della cache: su disco e in memoria. Entrambi questi tipi archiviano determinati dati, in particolare licenze per informazioni sui contenuti e sui criteri protetti, in testo non crittografato.

Per migliorare il comportamento di sicurezza dell'SDK, è stato aggiunto il supporto per un secondo tipo di nella cache su disco che usa API di crittografia specifiche della piattaforma per proteggere il database e il relativo contenuto.

L'applicazione definisce il tipo di cache durante il caricamento del profilo come parte degli oggetti FileProfileSettings, PolicyProfileSettings o ProtectionProfileSettings. Il tipo di cache è statico per la durata del profilo. Per passare a un tipo di archiviazione della cache diverso è necessario eliminare il profilo esistente e crearne uno nuovo.

Tipi di archiviazione cache

A partire da MIP SDK versione 1.3, sono disponibili i tipi di cache di archiviazione seguenti.

Tipo Scopo
InMemory Gestisce la cache di archiviazione in memoria nell'applicazione.
OnDisk Archivia il database su disco nella directory fornita nell'oggetto impostazioni. Il database viene archiviato in testo non crittografato.
OnDiskEncrypted Archivia il database su disco nella directory fornita nell'oggetto impostazioni. Il database viene crittografato usando API specifiche del sistema operativo.

Ogni motore generato dall'applicazione genera una nuova chiave di crittografia.

L'archiviazione cache viene impostata tramite uno degli oggetti impostazioni del profilo, tramite l'enumerazione 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>());

Quando usare ogni tipo

L'archiviazione cache è importante per mantenere l'accesso offline alle informazioni decrittografate in precedenza e garantire prestazioni per le operazioni di decrittografia quando i dati sono stati usati in precedenza.

  • Archivio in memoria: usare questo tipo di archiviazione per i processi duraturi in cui non è necessario rendere permanenti i criteri o le informazioni della cache delle licenze tra i riavvii del servizio.
  • Su disco: usare questo tipo di archiviazione per le applicazioni in cui i processi possono arrestarsi e avviare di frequente, ma devono gestire criteri, licenze e cache di individuazione dei servizi tra i riavvii. Questo tipo di cache di archiviazione è in testo non crittografato, quindi è più adatto per i carichi di lavoro del server in cui gli utenti non avranno accesso all'archiviazione dello stato. Ad esempio, un servizio Windows o un daemon Linux in esecuzione in un server o un'applicazione SaaS in cui solo gli amministratori del servizio avranno accesso ai dati sullo stato.
  • Su disco e crittografato: usare questo tipo di archiviazione per le applicazioni in cui i processi possono arrestare e avviare frequentemente, ma devono gestire criteri, licenze e cache di individuazione dei servizi tra riavvii. Questa cache di archiviazione è crittografata, quindi è più adatta per le applicazioni workstation in cui un utente può esplorare e individuare il database di stato. La crittografia aiuta a garantire che utenti curiosi non abbiano accesso ai contenuti dei criteri o della licenza di protezione in testo normale. È importante notare che in tutti i casi i dati vengono crittografati con chiavi a cui l'utente può accedere. Un avversario esperto è in grado di decrittografare la cache con uno sforzo minimo, ma ciò impedisce manomissioni e esplorazione.

Piattaforme supportate per la crittografia

Piattaforma Versione Note
Microsoft Windows Windows 8 e versioni successive Windows 7 supporta solo CacheStorageType::OnDisk
macOS High Sierra e versioni successive
Ubuntu Linux 16.04 e versioni successive Richiede le feature flag di funzionalità SecretService e LinuxEncryptedCache.
Android Android 7.0 o versione successiva
iOS Tutte le versioni supportate

Anche se MIP SDK supporta altre distribuzioni Linux, non è stata testata la crittografia della cache in RedHat Enterprise Linux, CentOS o Debian.

Nota

Il flag di funzionalità per abilitare l'archiviazione cache in Linux viene impostato tramite mip::MipConfiguration::SetFeatureSettings()

Tabelle del database di archiviazione nella cache

MIP SDK gestisce due database per la cache. Uno è per gli SDK di protezione e mantenere i dettagli dello stato di protezione. L'altro riguarda gli SDK per i criteri e la gestione dei dettagli dei criteri e delle informazioni sul servizio. Entrambi vengono archiviati nel percorso definito nell'oggetto settings, in mip\mip.policies.sqlite3 e mip\mip.protection.sqlite3.

Nota

MIP SDK non garantisce la compatibilità tra versioni diverse della cache. È consigliabile cancellare tutti i file all'interno della directory mip\ o qualsiasi directory alternativa modificata dall'impostazione predefinita, prima di aggiornare l'applicazione a una nuova versione di MIP SDK.

Database di protezione

Tabella Scopo Crittografato
AuthInfoStore Archivia i dettagli della richiesta di autenticazione. No
ConsentStore Archivia i risultati del consenso per ogni motore. No
DnsInfoStore Archivia i risultati della ricerca DNS per le operazioni di protezione No
EngineStore Archivia i dettagli del motore, l'utente associato e i dati client personalizzati No
KeyStore Archivia le chiavi di crittografia simmetrica per ogni motore. Sì
LicenseStore Archivia le informazioni sulla licenza per i dati decrittografati in precedenza. Sì
SdInfoStore Archivia i risultati dell'individuazione dei servizi. No

Nota

La cache LicenseStore richiede che venga impostata un'identità sul motore di protezione o sul motore di file.

Database delle politiche

Tabella Scopo Cifrato
KeyStore Archivia le chiavi di crittografia simmetrica per ogni motore. Sì
Politiche Archivia le informazioni sui criteri di etichetta per ogni utente. Sì
PoliticheURL Archivia l'URL del servizio di politica backend per utente specifico. No
Sensibilità Archivia le regole di classificazione per un criterio utente specifico. Sì
URL di sensibilità Archivia l'URL del servizio di politiche di sensibilità back-end per un utente specifico. No

Considerazioni sulle dimensioni del database

Le dimensioni del database dipendono da due fattori: la quantità di motori aggiunti alla cache e la quantità di licenze di protezione memorizzate nella cache. A partire da MIP SDK 1.3, non esiste alcun meccanismo per pulire la cache delle licenze alla scadenza. Sarà necessario un processo esterno per rimuovere la cache se aumenta di dimensioni superiori a quelle desiderate.

Il collaboratore più significativo alla crescita del database sarà la cache delle licenze di protezione. Se la memorizzazione nella cache delle licenze non è necessaria, perché i round trip del servizio non influiscono sulle prestazioni dell'applicazione, oppure la cache potrebbe crescere troppo, si può disabilitare la cache delle licenze. Questa operazione viene eseguita impostando CanCacheLicenses sull'oggetto FileProfile::Settings su false.

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

profileSettings.SetCanCacheLicenses(false);

Motori di cache

In MIP SDK viene creato un motore per ogni utente che esegue qualsiasi operazione autenticata. I motori forniscono un'interfaccia per tutte le operazioni eseguite per conto di un'identità autenticata. Come descritto in Concetti relativi a profili e motori, FileEngine, PolicyEngine o ProtectionEngine ognuno ha due stati CREATED e LOADED. Per poter eseguire operazioni SDK, è necessario creare e caricare un motore. Se un motore non è in uso, l'SDK memorizza nella cache il motore e lo mantiene nello CREATED stato il più a lungo possibile a seconda delle risorse disponibili. Ogni classe di profilo dell'SDK corrispondente fornisce anche un metodo per ottenere questo risultato UnloadEngineAsync in modo esplicito.

Ogni motore ha un identificatore univoco id usato in tutte le operazioni di gestione del motore. L'applicazione client può fornire un ID in modo esplicito oppure l'SDK può generarne uno, se non viene fornito dall'applicazione. Se viene fornito un identificatore univoco usando oggetti impostazioni motore al momento della creazione del motore e la memorizzazione nella cache è abilitata nel profilo API come descritto in precedenza, gli stessi motori possono essere usati ogni volta che l'utente esegue un'operazione con l'SDK. Seguire i frammenti di codice per la creazione di un oggetto [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).

Se non si specifica un engineId esistente, si verificheranno richieste di servizio extra per recuperare le politiche e si recupereranno le licenze che potrebbero essere già state memorizzate nella cache per il motore esistente. La memorizzazione nella cache dell'ID motore consente all'SDK di accedere offline alle informazioni decrittografate in precedenza e ai miglioramenti generali delle prestazioni.

Passaggi successivi

Per sapere di più sui concetti di oggetto Profilo e Motore, per comprendere come impostare correttamente gli ID motore MIP e utilizzare in modo efficace la memorizzazione nella cache di MIP SDK.