SDK da Proteção de Informações da Microsoft: armazenamento em cache

O SDK da PIM 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 em cache eram compatíveis: 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 não criptografado.

Para melhorar a postura de segurança do SDK, adicionamos suporte para um segundo tipo de cache de 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 dos objetos FileProfileSettings, PolicyProfileSettings ou ProtectionProfileSettings. 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 de cache

Desde o SDK da PIM versão 1.3, os tipos de cache de armazenamento a seguir estão disponíveis.

Tipo	Finalidade
InMemory	Mantém o cache de armazenamento na memória do aplicativo.
OnDisk	Armazena o banco de dados no disco, no diretório fornecido no objeto de configurações. O banco de dados é armazenado em texto não criptografado.
OnDiskEncrypted	Armazena o banco de dados no disco, no diretório fornecido no objeto de configurações. O banco de dados é criptografado usando APIs específicas do SO.

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

Você define o armazenamento em cache em um dos objetos de configurações de perfil, por meio da mip::CacheStorageType enumeração.

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 offline a informações descriptografadas anteriormente e garantir o desempenho de operações de descriptografia quando os dados foram consumidos anteriormente.

• Armazenamento em Memória: Use este tipo de armazenamento para processos de longa duração, nos quais não é necessário manter as informações de cache de política ou de licença durante as reinicializações do serviço.
• Em Disco: use esse tipo de armazenamento para aplicativos em que os processos podem parar e iniciar com frequência, mas devem manter a política, a licença e o cache de descoberta de serviços entre reinicializações. Esse tipo de cache de armazenamento é texto não criptografado, portanto, ele é 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 do Windows ou um daemon Linux em execução em um servidor ou um aplicativo SaaS em que 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 a política, a licença e o cache de descoberta de serviço entre reinicializações. Esse cache de armazenamento é criptografado, portanto, é mais adequado para aplicativos de estação de trabalho em que um usuário pode procurar e descobrir o banco de dados de estado. A criptografia ajuda a garantir que os usuários curiosos não tenham acesso ao conteúdo da política ou ao conteúdo da licença de proteção em texto sem formatação. Em todos os casos, os dados são criptografados com chaves que o usuário pode acessar. Um adversário habilidoso é capaz de descriptografar o cache com o mínimo de esforço, mas isso impede alterações e navegação indesejadas.

Plataformas com suporte para criptografia

Plataforma	Versão	Observações
Microsoft Windows	Windows 11, versão de suporte do Windows Server
macOS	High Sierra e posterior
Ubuntu Linux	22.04 e posterior	Requer sinalizadores de funcionalidades SecretService e LinuxEncryptedCache.
Android	Android 7.0 ou posterior
iOS	Todas as versões com suporte

Embora o SDK da PIM seja compatível com outras distribuições do Linux, não testamos a criptografia de cache no RedHat Enterprise Linux, CentOS ou Debian.

Observação

Você define o sinalizador de recursos para habilitar o armazenamento em cache no Linux com mip::MipConfiguration::SetFeatureSettings()

Tabelas de banco de dados de armazenamento em cache

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

Observação

O SDK do MIP não garante compatibilidade entre diferentes versões do cache. Limpe todos os arquivos no diretório mip\ ou qualquer diretório alternativo alterado da configuração padrão antes de atualizar o aplicativo para uma nova versão do SDK do MIP.

Banco de dados de proteção

Tabela	Finalidade	Criptografado
AuthInfoStore	Armazena detalhes do desafio de autenticação.	Não
ConsentStore	Armazena resultados de 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, o usuário associado e dados personalizados do cliente	Não
KeyStore	Armazena chaves de criptografia simétrica para cada mecanismo.	Sim
LicenseStore	Armazena informações de licença de uso para dados descriptografados anteriormente.	Sim
SdInfoStore	Armazena resultados de descoberta de serviço.	Não

Observação

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

Banco de dados de política

Tabela	Finalidade	Criptografado
KeyStore	Armazena chaves de criptografia simétrica para cada mecanismo.	Sim
Políticas	Armazena informações de políticas de rótulo para cada usuário.	Sim
PoliciesUrl	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
SensitivityUrls	Armazena a URL do serviço de políticas de confidencialidade 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.18, você pode usar DeleteStoredData() em ProtectionEngine para remover dados de mecanismo em cache programaticamente. Para versões anteriores, um processo externo pode ser necessário para remover o cache se ele crescer maior do que o desejado.

O contribuidor mais significativo para o aumento do banco de dados será o cache da licença de proteção. Se o cache do licenciamento não for necessário, pode ser porque as viagens de ida e volta do serviço não afetam o desempenho do aplicativo, ou o cache pode aumentar demais e o cache de licença pode ser desabilitado. Para fazer isso, defina 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 SDK da PIM, um mecanismo é criado para cada usuário que executa uma operação autenticada. Os mecanismos fornecem uma interface para todas as operações executadas em nome de uma identidade autenticada. Conforme discutido em Conceitos de Perfis e Mecanismos, FileEngine, PolicyEngine ou ProtectionEngine têm dois estados CREATED e LOADED. Um mecanismo precisa ser criado e carregado para poder executar operações de SDK. Se um mecanismo não estiver em uso, o SDK armazenará o mecanismo em cache e o manterá no estado CREATED pelo maior tempo possível, dependendo dos recursos disponíveis. Cada classe de perfil do respectivo SDK também fornece um método UnloadEngineAsync para conseguir isso explicitamente.

Cada mecanismo tem um identificador exclusivo id que é usado em todas as operações de gerenciamento de mecanismos. O aplicativo cliente pode fornecer uma ID explicitamente ou o SDK poderá gerar uma, se 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) e um [mip::PolicyEngine](./concept-profile-engine-policy-engine-cpp.md#implementation-create-policy-engine-settings).

Não fornecer um engineId existente resultará em idas e voltas adicionais ao serviço para obter a política e fará a busca de licenças que talvez já tenham sido armazenadas em cache para o engine existente. O armazenamento em cache da ID do mecanismo permite que o SDK tenha acesso offline a informações descriptografadas anteriormente e a melhorias gerais de desempenho.

Próximas Etapas 

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