Compartilhar via

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

  • Artigo

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 em 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.

O armazenamento em cache é definido por um dos objetos de configurações de perfil, por meio da enumeração 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 usar cada tipo

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

  • Em Armazenamento na memória: use este tipo de armazenamento para processos de longa duração em que a manutenção das informações de cache de política ou de licença nas reinicializações de serviço não é necessária.
  • Em disco: use este tipo de armazenamento para aplicativos em que os processos podem ser interrompidos e iniciados 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 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 este tipo de armazenamento para aplicativos em que os processos podem ser interrompidos e iniciados 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 em que um usuário pode navegar e descobrir o banco de dados de estado. A criptografia ajuda a garantir que 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. É importante notar que, 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 a adulteração e a navegação.

Plataformas compatíveis com criptografia

Plataforma Versão Observações
Microsoft Windows Windows 8 e mais recentes O Windows 7 só é compatível com CacheStorageType::OnDisk
macOS High Sierra e posterior
Ubuntu Linux 16.04 e posterior Requer sinalizador de recursos 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

O sinalizador de recursos para habilitar o armazenamento em cache no Linux é definido por meio de 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 MIP não garante a compatibilidade entre diferentes versões de seu cache. É aconselhável limpar todos os arquivos dentro do 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 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 no mecanismo de arquivos.

Banco de dados de políticas

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
Confidencialidade 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. Desde o SDK da PIM 1.3, não há um mecanismo para limpar o cache de licenças à medida que elas expiram. Deverá existir um processo externo para remover o cache se ele aumentar mais 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. Isso é feito definindo CanCacheLicenses no objeto FileProfile::Settings 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 um id explicitamente ou o SDK poderá gerar um id se ele não for fornecido 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 snippets 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).

O não fornecimento de um engineId existente resultará em viagens de ida e volta de serviço adicionais para buscar políticas, e buscarão licenças que podem já ter sido armazenadas em cache para o mecanismo 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 Conceitos de objeto de perfil e mecanismo para entender como definir corretamente os IDs do mecanismo da PIM para utilizar corretamente o cache do SDK da PIM.