Partilhar via

Visão geral do gerenciamento de chaves para Always Encrypted

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

O Always Encrypted utiliza dois tipos de chaves criptográficas para proteger os seus dados – uma chave para encriptar os seus dados e outra chave para encriptar a chave que encripta os seus dados. A chave de cifragem da coluna cifra os seus dados, a chave principal da coluna cifra a chave de cifragem da coluna. Este artigo fornece uma visão detalhada para gerir estas chaves de encriptação.

Ao discutir chaves Always Encrypted e gestão de chaves, é importante compreender a distinção entre as chaves criptográficas reais e os objetos de metadados que descrevem as chaves. Usamos os termos chave de encriptação de coluna e chave mestra de coluna para referir-nos às chaves criptográficas reais, e usamos metadados de chave de encriptação de colunas e metadados de chave mestra de coluna para referir-nos às descrições de chave Sempre Encriptadas na base de dados.

  • As chaves de encriptação de colunas são chaves de encriptação de conteúdo usadas para encriptar dados. Como o nome indica, usas chaves de encriptação de colunas para encriptar dados nas colunas da base de dados. Pode encriptar uma ou mais colunas com a mesma chave de encriptação de coluna, ou pode usar várias chaves de encriptação de colunas dependendo das necessidades da sua aplicação. As chaves de encriptação das colunas são elas próprias encriptadas, e apenas os valores encriptados das chaves de encriptação das colunas são armazenados na base de dados (como parte dos metadados da chave de encriptação das colunas). Os metadados da chave de encriptação das colunas são armazenados nas vistas do catálogo sys.column_encryption_keys (Transact-SQL) e sys.column_encryption_key_values (Transact-SQL). As chaves de encriptação de coluna usadas com o algoritmo AES-256 têm 256 bits de comprimento.

  • As chaves mestras de coluna são chaves usadas para proteger e encriptar chaves de encriptação de colunas. As chaves mestras de coluna devem ser armazenadas num armazenamento de chaves de confiança, como o Windows Certificate Store, Azure Key Vault ou um módulo de segurança de hardware. A base de dados contém apenas metadados sobre as chaves-mestras de coluna (o tipo de armazenamento de chave e a sua localização). Os metadados da chave mestra da coluna são armazenados na vista de catálogo sys.column_master_keys (Transact-SQL).

É importante notar que os metadados de chave no sistema de base de dados não contêm chaves mestras de coluna em texto simples nem chaves de encriptação de colunas em texto simples. A base de dados contém apenas informações sobre o tipo e localização das chaves mestras das colunas, e valores encriptados das chaves de encriptação das colunas. Isto significa que as chaves de texto simples nunca são expostas ao sistema de base de dados, garantindo que os dados protegidos com o Always Encrypted são seguros, mesmo que o sistema de base de dados seja comprometido. Para garantir que o sistema de base de dados não consegue aceder às chaves em texto simples, certifique-se de executar as suas ferramentas de gestão de chaves numa máquina diferente daquela que aloja a sua base de dados – consulte a secção de Considerações de Segurança para Gestão de Chaves abaixo para mais detalhes.

Como a base de dados contém apenas dados encriptados (em colunas protegidas de Sempre Encriptado) e não pode aceder às chaves de texto simples, não consegue desencriptar os dados. Isto significa que consultar colunas Always Encrypted simplesmente devolverá valores encriptados, pelo que as aplicações cliente que precisam de encriptar ou desencriptar dados protegidos devem poder aceder à chave mestra da coluna e às chaves de encriptação das colunas relacionadas. Para mais detalhes, consulte Desenvolver Aplicações usando Always Encrypted.

Tarefas de Gestão-chave

O processo de gestão das chaves pode ser dividido nas seguintes tarefas de alto nível:

  • Provisionamento de chaves - Criar as chaves físicas num armazenamento de chaves de confiança (por exemplo, na Windows Certificate Store, Azure Key Vault ou num módulo de segurança de hardware), encriptar chaves de encriptação de colunas com chaves mestras de coluna e criar metadados para ambos os tipos de chaves na base de dados.

  • Rotação de teclas - Substituir periodicamente uma tecla existente por uma nova. Pode ser necessário rodar uma chave se a chave tiver sido comprometida, ou para cumprir as políticas ou regulamentos de conformidade da sua organização que exigem que as chaves criptográficas sejam rotadas.

Papéis-chave de gestão

Existem dois papéis distintos dos utilizadores que gerem chaves Always Crypted; Administradores de Segurança e Administradores de Bases de Dados (DBAs):

  • Administrador de Segurança - gera chaves de encriptação de colunas e chaves mestras de coluna e gere armazenamentos de chaves que contêm as chaves mestras da coluna. Para realizar estas tarefas, um Administrador de Segurança precisa de conseguir aceder às chaves e ao armazenamento de chaves, mas não precisa de acesso à base de dados.
  • DBA - gere os metadados sobre as chaves na base de dados. Para realizar tarefas de gestão de chaves, um DBA precisa de ser capaz de gerir metadados de chave na base de dados, mas não precisa de acesso às chaves ou ao armazenamento de chaves que detém as chaves mestras da coluna.

Considerando os papéis acima, existem duas formas diferentes de realizar tarefas de gestão de chaves para o Always Encrypted; com separação de papéis, e sem separação de papéis. Dependendo das necessidades da sua organização, pode selecionar o processo de gestão de chaves que melhor se adequa às suas necessidades.

"Gestão de Chaves com Separação de Funções"

Quando as chaves Always Encrypted são geridas com separação de funções, diferentes pessoas numa organização assumem os papéis de Administrador de Segurança e DBA. Um processo de gestão de chaves com separação de funções garante que os DBAs não têm acesso às chaves ou armazenamentos de chaves que contêm as chaves reais, e os Administradores de Segurança não têm acesso à base de dados que contém dados sensíveis. Gerir chaves com separação de funções é recomendado se o seu objetivo é garantir que os DBAs da sua organização não possam aceder a dados sensíveis.

Nota: Os Administradores de Segurança geram e trabalham com as chaves de texto simples, pelo que nunca devem realizar as suas tarefas nos mesmos computadores que alojam um sistema de base de dados, ou computadores que possam ser acedidos por DBAs ou qualquer outra pessoa que possa ser adversária potencial.

Gerir Chaves sem Separação de Funções

Quando as chaves Always Encrypted são geridas sem separação de funções, uma única pessoa pode assumir tanto o papel de Administrador de Segurança como de DBA, o que implica que essa pessoa precisa de ser capaz de aceder e gerir tanto as chaves/armazenamentos de chaves como os metadados das chaves. A gestão de chaves sem separação de funções pode ser recomendada para organizações que utilizam o modelo DevOps, ou se a base de dados estiver alojada na cloud e o objetivo principal for restringir administradores de cloud (mas não DBAs locais) o acesso a dados sensíveis.

Ferramentas para Gerir Chaves Sempre Encriptadas

Chaves sempre encriptadas podem ser geridas usando SQL Server Management Studio (SSMS) e PowerShell:

Considerações de Segurança para a Gestão de Chaves

O objetivo principal do Always Encrypted é garantir que os dados sensíveis armazenados numa base de dados estão seguros, mesmo que o sistema de base de dados ou o seu ambiente de alojamento sejam comprometidos. Exemplos de ataques de segurança onde o Always Encrypted pode ajudar a prevenir fugas de dados sensíveis incluem:

  • Um administrador de base de dados malicioso, com altos privilégios, como um DBA, a consultar colunas de dados sensíveis.
  • Um administrador desonesto de um computador que hospeda uma instância do SQL Server, digitalizando a memória de um processo do SQL Server ou ficheiros de despejo de memória do processo do SQL Server.
  • Um operador malicioso de centro de dados a consultar uma base de dados de clientes, a examinar ficheiros de dump do SQL Server ou a examinar a memória de um computador que aloja dados de clientes na cloud.
  • Malware a correr num computador que hospeda a base de dados.

Para garantir que o Always Encrypted é eficaz na prevenção deste tipo de ataques, o seu processo de gestão de chaves deve garantir que as chaves mestras da coluna e as chaves de encriptação das colunas, bem como as credenciais para um armazenamento de chaves que contenha as chaves mestras da coluna, nunca sejam reveladas a um potencial atacante. Aqui estão algumas orientações que deve seguir:

  • Nunca gere chaves mestras de colunas ou chaves de encriptação de colunas num computador que aloja a sua base de dados. Em vez disso, gera as chaves num computador separado, que seja dedicado à gestão de chaves, ou seja uma máquina que aloja aplicações que precisarão de acesso às chaves de qualquer forma. Isto significa que nunca deve executar ferramentas usadas para gerar as chaves no computador que aloja a sua base de dados , porque se um atacante aceder a um computador usado para provisionar ou manter as suas chaves Always Crypted, o atacante pode potencialmente obter as suas chaves, mesmo que as chaves apareçam na memória da ferramenta apenas por um curto período.
  • Para garantir que o seu processo de gestão de chaves não revele inadvertidamente chaves mestras de coluna ou chaves de encriptação de colunas, é fundamental identificar potenciais adversários e ameaças de segurança antes de definir e implementar um processo de gestão de chaves. Por exemplo, se o seu objetivo é garantir que os DBAs não tenham acesso a dados sensíveis, então um DBA não pode ser responsável por gerar as chaves. Um DBA, no entanto, pode gerir os principais metadados na base de dados, uma vez que os metadados não contêm as chaves em texto claro.

Próximas Etapas

  • Last updated on