Compartilhar via

Visão geral do gerenciamento de chaves do Always Encrypted

  • Artigo

Aplica-se a: SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

Always Encrypted usa dois tipos de chaves de criptografia para proteger seus dados, uma chave para criptografar os dados e outra para criptografar a chave que criptografa os dados. A chave de criptografia de coluna criptografa os dados, a chave mestra de coluna criptografa a chave de criptografia de coluna. Este artigo fornece uma visão geral detalhada para gerenciar essas chaves de criptografia.

Ao discutir chaves Always Encrypted e o gerenciamento de chaves, é importante compreender a diferença entre as chaves de criptografia reais e os objetos de metadados que descrevem as chaves. Usamos os termos chave de criptografia de coluna e chave mestra de coluna para referir-se às chaves de criptografia reais e usamos os metadados de chave de criptografia de coluna e metadados de chave mestra de coluna para referir-se às descrições da chave Always Encrypted no banco de dados.

  • Chaves de criptografia de coluna são chaves de criptografia de conteúdo usadas para criptografar dados. Como o nome implica, usamos chaves de criptografia de coluna para criptografar dados em colunas de banco de dados. Você pode criptografar uma ou mais colunas com a mesma chave de criptografia de coluna ou pode usar várias chaves de criptografia de coluna dependendo dos requisitos do aplicativo. As chaves de criptografia de coluna são criptografadas elas mesmas e apenas os valores criptografados das chaves de criptografia de coluna são armazenados no banco de dados (como parte dos metadados de chave de criptografia de coluna). Os metadados de chave de criptografia de coluna são armazenados nas exibições de catálogo sys.column_encryption_keys (Transact-SQL) e sys.column_encryption_key_values (Transact-SQL) . As chaves de criptografia de coluna usadas com o algoritmo AES-256 têm 256 bits.

  • Chaves mestras de coluna são chaves de proteção de chaves usadas para criptografar as chaves de criptografia de coluna. Chaves mestras de coluna devem ser armazenadas em um repositório de chave confiável, como o Repositório de Certificados do Windows, o Cofre de Chaves do Azure ou um módulo de segurança de hardware. O banco de dados só contém metadados sobre chaves mestras de coluna (o tipo e local do repositório de chaves). Os metadados de chave mestra de coluna são armazenados na exibição de catálogo sys.column_master_keys (Transact-SQL) .

É importante observar que os principais metadados no sistema de banco de dados não contêm chaves mestras de coluna de texto não criptografado ou chaves de criptografia de coluna de texto não criptografado. O banco de dados contém apenas informações sobre o tipo e o local das chaves mestras de coluna e valores criptografados das chaves de criptografia de coluna. Isso significa que chaves com texto não criptografado nunca são expostas no sistema de banco de dados, garantindo que os dados protegidos que usam o Always Encrypted estejam seguros, mesmo se o sistema de banco de dados for comprometido. Para garantir que o sistema de banco de dados não possa obter acesso às chaves de texto não criptografado, execute as ferramentas de gerenciamento de chaves em um computador diferente daquele que hospeda seu banco de dados. Leia a seção Considerações de segurança para gerenciamento de chaves abaixo para ver os detalhes.

Como o banco de dados só contém dados criptografados (em colunas Always Encrypted protegidas) e não pode acessar as chaves de texto não criptografado, ele não pode descriptografar os dados. Isso significa que consultar colunas Always Encrypted simplesmente retornará valores criptografados, por isso aplicativos cliente que precisam criptografar ou descriptografar dados protegidos devem ser capazes de acessar a chave mestra de coluna e as chaves de criptografia de coluna relacionadas. Para obter detalhes, confira Desenvolver aplicativos usando o Always Encrypted.

Tarefas de Gerenciamento de Chaves

O processo de gerenciamento de chaves pode ser dividido nas seguintes tarefas de alto nível:

  • Provisionamento de chave - Criar as chaves físicas em um repositório de chaves confiável (por exemplo, no Repositório de Certificados do Windows, o Cofre de Chaves do Azure ou um módulo de segurança de hardware), chaves de criptografia de coluna de criptografia com chaves mestras de coluna e criar metadados para os dois tipos de chaves no banco de dados.

  • Rotação de chaves - Substituir periodicamente uma chave existente por uma nova chave. Poderá ser necessário trocar uma chave caso ela tenha sido comprometida ou para manter a conformidade com as políticas ou os regulamentos da organização que exigem que as chaves de criptografia sejam trocadas.

Funções de Gerenciamento de Chaves

Existem duas funções distintas de usuários que gerencia chaves Always Encrypted: Administradores de Segurança e DBAs (Administradores de Banco de Dados):

  • Administrador de Segurança - Gera chaves de criptografia de coluna e chaves mestras de coluna e gerencia repositórios de chaves que contém as chaves mestras de coluna. Para executar essas tarefas, um Administrador de Segurança deve ser capaz de acessar as chaves e o repositório de chaves, mas não precisam de acesso ao banco de dados.
  • DBA – gerencia os metadados das chaves no banco de dados. Para executar tarefas de gerenciamento de chaves, um DBA precisa ser capaz de gerenciar metadados de chave no banco de dados, mas não precisam acessar as chaves ou repositório de chaves que contém as chaves mestras de coluna.

Considerando as funções acima, há duas maneiras de executar tarefas de gerenciamento de chaves para Always Encrypted: com separação de funçãoe sem separação de funções. Dependendo das necessidades da sua organização, você pode selecionar o processo de gerenciamento de chaves que melhor atenda às suas necessidades.

Gerenciamento de chaves com separação de funções

Quando chaves Always Encrypted forem gerenciadas com separação de funções, pessoas diferentes em uma organização assumem as funções de Administrador de Segurança e de DBA. Um processo de gerenciamento de chaves com separação de funções garante que DBAs não tenham acesso a chaves ou repositórios de chaves que contém chaves reais e os Administradores de Segurança não tenham acesso ao banco de dados que contêm dados confidenciais. É recomendável gerenciar as chaves com separação de funções se sua meta for garantir que os DBAs na sua organização não possam acessar dados confidenciais.

Observação: Administradores de Segurança geram e trabalham com as chaves de texto não criptografado, por isso nunca devem executar suas tarefas nos mesmos computadores que hospedam um sistema de banco de dados ou computadores que podem ser acessados por DBAs ou outras pessoas que podem ser possíveis adversários.

Gerenciamento de chaves sem separação de funções

Quando chaves Always Encrypted são gerenciadas sem a separação de funções, uma única pessoa pode assumir ambas as funções de Administrador de Segurança e de DBA, o que significa que a pessoa precisa ser capaz de acessar e gerenciar tanto as chaves/repositório de chaves quanto os metadados de chaves. Gerenciar chaves sem separação de funções pode ser recomendado para organizações que usam o modelo de DevOps ou se o banco de dados estiver hospedado na nuvem e o principal objetivo for impedir que os administradores de nuvem (mas não os DBAs locais) acessem dados confidenciais.

Ferramentas para gerenciar chaves Always Encrypted

Chaves Always Encrypted podem ser gerenciadas usando o SSMS (SQL Server Management Studio) e PowerShell:

Considerações de segurança para gerenciamento de chaves

O principal objetivo do Always Encrypted é garantir que os dados confidenciais armazenados em um banco de dados estejam seguros, mesmo se o sistema de banco de dados ou seu ambiente de hospedagem for comprometido. Exemplos de ataques de segurança em que o Always Encrypted pode ajudar a impedir vazamentos de dados confidenciais:

  • Um usuário de banco de dados de alto privilégio mal-intencionado, como um DBA, consultando colunas de dados confidenciais.
  • Um administrador invasor de um computador que hospeda uma instância do SQL Server examinando a memória de um processo do SQL Server ou arquivos de despejo de memória do processo do SQL Server.
  • Um operador do data center mal-intencionado consulta um banco de dados do cliente, examinando os arquivos de despejo do SQL Server ou examinando a memória de um computador que hospeda os dados do cliente na nuvem.
  • Malware em execução em um computador que hospeda o banco de dados.

Para garantir que Always Encrypted seja eficaz na prevenção desses tipos de ataques, o processo de gerenciamento de chaves deve garantir que as chaves mestras de coluna e as chaves de criptografia de coluna, e as credenciais para um repositório de chaves que contém as chaves mestras de coluna, nunca sejam reveladas para um invasor em potencial. Aqui estão algumas diretrizes que você deve seguir:

  • Nunca gere chaves mestras de coluna ou as chaves de criptografia de coluna em um computador que hospeda o banco de dados. Em vez disso, gere as chaves em um computador separado, dedicado para o gerenciamento de chaves ou que hospeda aplicativos que também precisarão de acesso às chaves. Isso significa que você nunca deve executar ferramentas usadas para gerar as chaves no computador que hospeda o banco de dados, pois se um invasor acessar um computador usado para provisionar ou manter as chaves Always Encrypted, ele terá a chance de poderá obter suas chaves, mesmo se elas aparecerem somente na memória da ferramenta por um curto período.
  • Para garantir que o processo de gerenciamento de chaves não revele inadvertidamente as chaves mestras de coluna ou as chaves de criptografia de coluna, é essencial identificar os possíveis adversários e ameaças de segurança antes de definir e implementar um processo de gerenciamento de chaves. Por exemplo, se sua meta é garantir que os DBAs não tenham acesso a dados confidenciais, um DBA não pode ser o responsável por gerar as chaves. Um DBA, no entanto, pode gerenciar metadados de chave no banco de dados, pois os metadados não contêm as chaves de texto não criptografado.

Próximas etapas