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 FileProfileSettingsoggetti , PolicyProfileSettingso 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.

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.

• In Archiviazione memoria: usare questo tipo di archiviazione per i processi di lunga durata in cui non è necessario rendere persistenti 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 consente di garantire che gli utenti non abbiano accesso tramite il contenuto dei criteri o il contenuto 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

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

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.

Database di protezione

Database dei criteri

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 influisce sulle prestazioni dell'applicazione o la cache potrebbe aumentare troppo, la cache delle licenze può essere disabilitata. 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 memorizzazione nella 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 verifica un round trip aggiuntivo del servizio per recuperare i criteri e recupera 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

Altre informazioni sui concetti relativi agli oggetti profilo e motore per comprendere come impostare correttamente gli ID del motore MIP per usare correttamente la memorizzazione nella cache di MIP SDK.