Visão geral do gerenciamento de chaves do Always Encrypted

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do Azure

O Always Encrypted usa dois tipos de chaves criptográficas para proteger seus dados: uma chave para criptografar seus dados e outra chave para criptografar a chave que criptografa seus dados. A chave de criptografia de coluna criptografa seus 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 chave usadas para criptografar 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 contém apenas metadados sobre as chaves mestras de coluna (o tipo de repositório de chaves e a localização). Os metadados da chave mestra de coluna são armazenados na exibição de catálogo sys.column_master_keys (Transact-SQL).

Os principais metadados no sistema de banco de dados não contêm chaves mestras de coluna de texto não criptografado nem 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 sem formatação, execute suas ferramentas de gerenciamento de chaves em um computador diferente do que hospeda seu banco de dados. Examine a seção Considerações de Segurança para Gerenciamento de Chaves abaixo para obter 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 chaves: criando as chaves físicas em um repositório de chaves confiável (por exemplo, no Repositório de Certificados Windows, Azure Key Vault ou em um módulo de segurança de hardware), criptografando chaves de criptografia de coluna com chaves mestras de coluna e criando metadados para ambos os tipos de chaves no banco de dados.

  • Rotação de chaves: substituindo periodicamente uma chave existente por uma nova chave. Talvez seja necessário girar uma chave se a chave tiver sido comprometida ou para cumprir as políticas da sua organização ou os regulamentos de conformidade que exigem chaves criptográficas devem ser giradas.

Funções de gerenciamento de chaves

Há duas funções distintas de usuários que gerenciam chaves Always Encrypted; administradores de segurança e administradores de banco de dados (DBAs):

  • 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 precisa ser capaz de acessar as chaves e o repositório de chaves, mas não precisa de acesso ao banco de dados.
  • DBA: gerencia metadados sobre as 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.

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

Quando as chaves Always Encrypted são gerenciadas com separação de função, pessoas diferentes em uma organização assumem as funções de administrador de segurança e DBA. Um processo de gerenciamento de chave com separação de função garante que os DBAs não tenham acesso às chaves ou repositórios de chaves que contêm as chaves reais e os administradores de segurança não têm 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.

Note

Os administradores de segurança geram e trabalham com as chaves de texto sem formatação, portanto, eles não devem executar suas tarefas nos mesmos computadores que hospedam um sistema de banco de dados ou computadores que podem ser acessados por DBAs ou qualquer outra pessoa que possa ser potencialmente adversária.

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

Quando as chaves Always Encrypted são gerenciadas sem separação de função, uma única pessoa pode assumir as funções de administrador de segurança e DBA, o que significa que essa pessoa precisa ser capaz de acessar e gerenciar as chaves/repositórios de chaves e os metadados de chave. O gerenciamento de chaves sem separação de função é recomendado para organizações que usam o modelo DevOps ou se o banco de dados está hospedado na nuvem e o objetivo principal é restringir os administradores de nuvem (mas não os DBAs locais), de acessar 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 desonesto 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 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 colunas ou chaves de criptografia de colunas no computador que hospeda seu 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.

Conteúdo relacionado

  • Last updated on