Microsoft Information Protection SDK - Armazenamento em cache

O SDK MIP implementa uma base de dados SQLite3 para manter o armazenamento cache do SDK. Antes da versão 1.3 do Microsoft Information Protection SDK, apenas dois tipos de armazenamento de estado de cache eram suportados: no disco e na memória. Ambos os tipos armazenavam certos dados, especificamente licenças para conteúdos protegidos e informações de políticas, em texto simples.

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

A aplicação define o tipo de cache ao carregar o perfil como parte dos FileProfileSettings, PolicyProfileSettings, ou ProtectionProfileSettings objetos. O tipo de cache é estático durante toda a vida útil do perfil. Mudar para um tipo diferente de armazenamento de cache requer destruir o perfil existente e criar um novo.

Tipos de Armazenamento de Cache

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

Cada motor gerado pela aplicação gera uma nova chave de encriptação.

O armazenamento de cache é definido através de um dos objetos de definição 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 offline a informações previamente desencriptadas e garantir o desempenho das operações de desencriptação quando os dados já foram consumidos.

• Em armazenamento de memória: Use este tipo de armazenamento para processos de longa duração onde não é necessário persistir a informação da cache de política ou licença através dos reinicios do serviço.
• No Disco: Use este tipo de armazenamento para aplicações onde os processos podem frequentemente parar e arrancar, mas devem manter a cache de descoberta de políticas, licenças e serviços durante os reinícios. Este tipo de cache de armazenamento é texto simples, por isso é mais adequado para cargas de trabalho de servidor onde os utilizadores não têm acesso ao armazenamento de estado. Exemplos disto seriam um serviço Windows ou daemon Linux a correr num servidor, ou uma aplicação SaaS onde apenas administradores de serviço teriam acesso aos dados de estado.
• Em Disco e Encriptado: Use este tipo de armazenamento para aplicações onde os processos podem frequentemente parar e arrancar, mas devem manter a cache de políticas, licenças e descoberta de serviço ao longo dos reinícios. Esta cache de armazenamento é encriptada, pelo que é mais adequada para aplicações de estação de trabalho onde o utilizador pode navegar e descobrir a base de dados de estado. A cifragem ajuda a garantir que os utilizadores curiosos não terão acesso aos conteúdos da política ou da licença de proteção em texto simples. É importante notar que, em todos os casos, os dados são encriptados com chaves às quais o utilizador pode conseguir aceder. Um adversário habilidoso consegue desencriptar a cache com esforço mínimo, mas isso impede manipulações e navegações.

Plataformas Suportadas para Encriptação

Embora o MIP SDK suporte outras distribuições Linux, não testámos a encriptação da cache no RedHat Enterprise Linux, CentOS ou Debian.

Tabelas de bases de dados de armazenamento em cache

O SDK MIP mantém duas bases de dados para cache. Um é para os SDKs de Proteção e para manter os detalhes do estado de proteção. A outra é para os SDKs de Políticas e para a manutenção dos detalhes das políticas e informações de serviço. Ambos são armazenados no caminho definido no objeto de definições, em mip\mip.policies.sqlite3 e mip\mip.protection.sqlite3.

Base de Dados de Proteção

Base de Dados de Políticas

Considerações sobre o tamanho da base de dados

O tamanho da base de dados depende de dois fatores: a quantidade de motores adicionados à cache e a quantidade de licenças de proteção que foram armazenadas em cache. A partir da MIP SDK 1.18, DeleteStoredData() no ProtectionEngine pode ser usado para remover programaticamente os dados do motor em cache. Para versões anteriores, pode ser necessário um processo externo para remover a cache se esta crescer em tamanho superior ao desejado.

O maior contributo para o crescimento da base de dados será a cache de licenças de proteção. Se a cache de licenciamento não for necessária, seja porque as idas e voltas do serviço não impactam o desempenho da sua aplicação, ou porque a cache pode crescer demasiado, a cache de licenciamento pode ser desativada. Isto é conseguido ao definir o objeto FileProfile::Settings como falso CanCacheLicenses.

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

profileSettings.SetCanCacheLicenses(false);

Motores de Cache

No MIP SDK, é criado um motor para cada utilizador que realiza qualquer operação autenticada. Engines fornece uma interface para todas as operações realizadas em nome de uma identidade autenticada. Como discutido nos conceitos de Perfis e Motores, FileEngine, PolicyEngine ou ProtectionEngine têm cada um dois estados CREATED e LOADED. É necessário criar e carregar um motor para que este possa realizar operações SDK. Se um motor não estiver em uso, o SDK armazena o motor em cache e mantém-no no CREATED estado o máximo de tempo possível, dependendo dos recursos disponíveis. A classe de perfil de cada respetivo SDK também fornece um método UnloadEngineAsync para alcançar isto de forma explícita.

Cada motor tem um identificador id único que é utilizado em todas as operações de gestão do motor. A aplicação cliente pode fornecer um id explicitamente, ou o SDK pode gerar um, caso não seja fornecido pela aplicação. Se for fornecido um identificador único usando objetos de definições do motor no momento da criação do motor, e a cache estiver ativada no perfil API como descrito acima, os mesmos motores podem ser usados sempre que o utilizador realiza uma operação com o SDK. Siga os excertos 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).

Não fornecer um engineID existente resultará em viagens adicionais de ida e volta para buscar a apólice e irá buscar licenças que possam já ter sido armazenadas em cache para a locomotiva existente. Armazenar em cache o ID do motor permite ao SDK acesso offline a informações previamente desencriptadas e melhorias gerais de desempenho.

Próximas Etapas

De seguida, aprenda mais sobre os conceitos de Profile e Engine Object para compreender como definir corretamente IDs do motor MIP para utilizar corretamente a cache do MIP SDK.