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

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

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

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.

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.

Banco de dados de proteção

Banco de dados de políticas

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.