SDK de Proteção de Informações da Microsoft - Armazenamento em cache

Artigo
10/18/2023

O MIP SDK implementa um banco de dados SQLite3 para manter o armazenamento em cache do SDK. Antes da versão 1.3 do SDK da Proteção de Informações da Microsoft, apenas dois tipos de armazenamento de estado de cache eram suportados: no disco e na memória. Ambos os tipos armazenavam determinados dados, especificamente licenças para conteúdo protegido e informações de políticas, em texto sem formatação.

Para melhorar a postura de segurança do SDK, adicionamos suporte para um segundo tipo de cache em disco que usa APIs criptográficas específicas da plataforma para proteger o banco de dados e seu conteúdo.

O aplicativo define o tipo de cache ao carregar o perfil como parte do FileProfileSettings, PolicyProfileSettingsou ProtectionProfileSettings objetos. O tipo de cache é estático durante a vida útil do perfil. Mudar para um tipo diferente de armazenamento em cache requer a destruição do perfil existente e a criação de um novo.

Tipos de armazenamento em cache

A partir do MIP SDK versão 1.3, os seguintes tipos de cache de armazenamento estão disponíveis.

Tipo	Finalidade
InMemory	Mantém o cache de armazenamento na memória do aplicativo.
OnDisk	Armazena o banco de dados em disco no diretório fornecido no objeto settings. O banco de dados é armazenado em texto sem formatação.
OnDiskEncrypted	Armazena o banco de dados em disco no diretório fornecido no objeto settings. O banco de dados é criptografado usando APIs específicas do sistema operacional.

Cada mecanismo gerado pelo aplicativo gera uma nova chave de criptografia.

O armazenamento em cache é definido através de um dos objetos de configurações de perfil, através do mip::CacheStorageType enum.

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 usar cada tipo

O armazenamento em cache é importante para manter o acesso off-line a informações descriptografadas anteriormente e garantir o desempenho das operações de descriptografia quando os dados foram consumidos anteriormente.

No armazenamento de memória: use este tipo de armazenamento para processos de longa duração nos quais não é necessário persistir as informações de cache de política ou licença nas reinicializações do serviço.
No disco: use esse tipo de armazenamento para aplicativos em que os processos podem parar e iniciar com frequência, mas devem manter o cache de descoberta de políticas, licenças e serviços nas reinicializações. Esse tipo de cache de armazenamento é texto sem formatação, portanto, é mais adequado para cargas de trabalho de servidor em que os usuários não terão acesso ao armazenamento de estado. Exemplos disso seriam um serviço Windows ou daemon Linux em execução em um servidor, ou um aplicativo SaaS onde apenas administradores de serviço teriam acesso aos dados de estado.
Em disco e criptografado: use esse tipo de armazenamento para aplicativos em que os processos podem parar e iniciar com frequência, mas devem manter o cache de descoberta de políticas, licenças e serviços nas reinicializações. Esse cache de armazenamento é criptografado, portanto, é mais adequado para aplicativos de estação de trabalho onde um usuário pode navegar e descobrir o banco de dados de estado. A encriptação ajuda a garantir que os utilizadores curiosos não terão acesso através do conteúdo da política ou do conteúdo da licença de proteção em texto simples. É importante notar que, em todos os casos, os dados são criptografados com chaves que o usuário pode ser capaz de acessar. Um adversário habilidoso é capaz de descriptografar o cache com o mínimo de esforço, mas isso evita adulterações e navegação.

Plataformas suportadas para encriptação

Plataforma	Versão	Notas
Microsoft Windows	Windows 8 e versões mais recentes	O Windows 7 suporta apenas CacheStorageType::OnDisk
macOS	Alta Serra e mais tarde
Ubuntu Linux	16.04 e seguintes	Requer `SecretService` e `LinuxEncryptedCache` sinalizador de recurso.
Android	Android 7.0 ou posterior
iOS	Todas as versões suportadas

Embora o MIP SDK suporte outras distribuições Linux, não testamos a criptografia de cache no RedHat Enterprise Linux, CentOS ou Debian.

Nota

O sinalizador de recurso para habilitar o armazenamento em cache no Linux é definido via mip::MipConfiguration::SetFeatureSettings()

Tabelas de banco de dados de armazenamento em cache

O SDK MIP mantém dois bancos de dados para cache. Um deles é para os SDKs de proteção e a manutenção dos detalhes do estado de proteção. O outro é para os SDKs de política e manutenção de detalhes de política e informações de serviço. Ambos são armazenados no caminho definido no objeto settings, em mip\mip.policies.sqlite3 e mip\mip.protection.sqlite3.

Base de Dados de Proteção

Tabela	Propósito	Encriptados
AuthInfoStore	Armazena detalhes do desafio de autenticação.	Não
Loja de Consentimento	Armazena os resultados do consentimento para cada mecanismo.	Não
DnsInfoStore	Armazena resultados de pesquisa de DNS para operações de Proteção	Não
EngineStore	Armazena detalhes do mecanismo, usuário associado e dados personalizados do cliente	Não
Loja de chaves	Armazena chaves de criptografia simétricas para cada mecanismo.	Sim
Loja de Licenças	Armazena informações de licença de uso para dados descriptografados anteriormente.	Sim
SdInfoStore	Armazena resultados de descoberta de serviço.	Não

Nota

O cache do LicenseStore requer que uma identidade seja definida no mecanismo de proteção ou no mecanismo de arquivos.

Base de dados de políticas

Tabela	Propósito	Encriptados
Loja de chaves	Armazena chaves de criptografia simétricas para cada mecanismo.	Sim
Políticas	Armazena informações de política de rótulo para cada usuário.	Sim
PolíticasUrl	Armazena a URL do serviço de política de back-end para um usuário específico.	Não
Sensibilidade	Armazena regras de classificação para uma política de usuário específica.	Sim
SensibilidadeUrls	Armazena a URL do serviço de política de sensibilidade de back-end para um usuário específico.	Não

Considerações sobre o tamanho do banco de dados

O tamanho do banco de dados depende de dois fatores: a quantidade de mecanismos que estão sendo adicionados ao cache e a quantidade de licenças de proteção que foram armazenadas em cache. A partir do MIP SDK 1.3, não há nenhum mecanismo para limpar o cache de licenças à medida que expiram. Terá que haver um processo externo para remover o cache se ele crescer maior do que o desejado.

O contribuinte mais significativo para o crescimento do banco de dados será o cache de licença de proteção. Se o cache de licenciamento não for necessário, seja porque as viagens de ida e volta do serviço não afetarão o desempenho do aplicativo ou porque o cache pode crescer muito, o cache de licenças poderá ser desativado. Isso é feito definindo CanCacheLicenses no FileProfile::Settings objeto como false.

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

profileSettings.SetCanCacheLicenses(false);

Mecanismos de cache

No MIP SDK, um mecanismo é criado para cada usuário que executa qualquer operação autenticada. Os mecanismos fornecem uma interface para todas as operações executadas em nome de uma identidade autenticada. Conforme discutido nos conceitos de Perfis e Mecanismos, FileEngine, PolicyEngine ou ProtectionEngine têm dois estados CREATED e LOADED. Um mecanismo precisa ser criado e carregado para que ele seja capaz de executar operações SDK. Se um mecanismo não estiver em uso, o SDK armazenará em cache o mecanismo e o manterá no CREATED estado o maior tempo possível, dependendo dos recursos disponíveis. Cada classe de perfil do respetivo SDK também fornece um método UnloadEngineAsync para conseguir isso explicitamente.

Cada mecanismo tem um identificador id exclusivo que é usado em todas as operações de gerenciamento do motor. O aplicativo cliente pode fornecer uma id explicitamente, ou o SDK pode gerar uma, se ela não for fornecida pelo aplicativo. Se um identificador exclusivo for fornecido usando objetos de configurações do mecanismo no momento da criação do mecanismo e o cache estiver habilitado no perfil da API, conforme descrito acima, os mesmos mecanismos poderão ser usados sempre que o usuário executar uma operação com o SDK. Siga os trechos de código para criar um [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).

A falha ao fornecer um engineId existente resultará em viagens de ida e volta de serviço extra para buscar a política e buscará licenças que podem já ter sido armazenadas em cache para o mecanismo existente. O armazenamento em cache do ID do mecanismo permite que o SDK tenha acesso off-line a informações descriptografadas anteriormente e melhorias gerais de desempenho.

Passos Seguintes

Em seguida, saiba mais sobre os conceitos de objeto Profile e Engine para entender como definir corretamente IDs de mecanismo MIP para utilizar corretamente o cache do MIP SDK.

Partilhar via