Os Grupos de Disponibilidade são fantásticos para soluções de Alta Disponibilidade/Recuperação de Desastres, e tenho certeza de que outros DBAs concordarão comigo. No entanto, haverá momentos em que devemos considerar certas precauções e etapas extras com cuidado para evitar surpresas indesejadas. Por exemplo, qualquer Réplica Secundária se torna a Réplica Primária atual por qualquer motivo, e nosso objetivo é não deixar isso acontecer.
Existem duas opções de criptografia fornecidas pelo SQL:sql tde vs sempre criptografado. Neste artigo, vou mostrar um cenário que exige que o DBA preste atenção extra aos detalhes. Assim como o título diz, ele o guiará pela maneira correta de lidar com a criptografia de dados nos bancos de dados que fazem parte da configuração do Grupo de Disponibilidade AlwaysOn.
Considerações iniciais
Usarei Transparent Data Encryption (TDE) como a tecnologia para construir meu caso. Aplica-se a todas as versões com suporte do SQL Server. É importante mencionar que esse recurso está disponível apenas nas seguintes edições do SQL Server:
- Avaliação do SQL Server 2019, Standard, Developer, Enterprise
- Avaliação do SQL Server 2017, Desenvolvedor, Empresa
- Avaliação do SQL Server 2016, Desenvolvedor, Empresa
- Avaliação do SQL Server 2014, Desenvolvedor, Empresa
- Avaliação do SQL Server 2012, Desenvolvedor, Empresa
- SQL Server 2008R2 Datacenter, Avaliação, Desenvolvedor, Empresa
- Avaliação do SQL Server 2008, Desenvolvedor, Empresa
Vamos ver como podemos usar TDE (Transparent Data Encryption) no SQL Server Standard Edition. Antes de tudo, precisamos criar uma DMK (Database Master Key) para criptografar os dados. Em seguida, criamos um certificado e uma chave para poder descriptografar os dados ao acessá-los. Não se esqueça de fazer backup do certificado e, por fim, habilitar a criptografia.
Observação: O recurso TDE não é suportado no SQL Server Express Edition.
Esta postagem não abordará as etapas para criar um grupo de disponibilidade e estou contando com o que já foi criado para fins de teste. Você pode ler mais sobre como implantar grupos de disponibilidade AlwaysOn do SQL Server no Linux.
O ambiente é baseado em Windows, mas os princípios serão muito semelhantes se você usar plataformas diferentes (por exemplo, SQL Server em Linux ou instâncias gerenciadas de SQL do Azure).
O que é criptografia de dados temporária
A principal razão pela qual usamos TDE é a segurança de dados e arquivos de log para seu banco de dados SQL. Para evitar que seus dados pessoais sejam roubados, é uma boa ideia defendê-los, além disso, esse processo de criptografia é muito fácil. Antes que a página seja gravada no disco, os arquivos são criptografados no nível da página. Toda vez que você deseja acessar seus dados, eles são descriptografados. Após a implementação da TDE, você precisará de um certificado específico e uma chave para restaurar ou anexar o banco de dados. Isso é o que é um algoritmo de criptografia.
Microsoft Exemplo de grupo de disponibilidade do SQL Server
Meu grupo de disponibilidade de teste consiste em 2 réplicas, cada uma em sua própria VM. Aqui estão as propriedades básicas:
Como você pode ver, não há nada extravagante, apenas algumas réplicas usando o modo de confirmação síncrona e no modo de failover manual.
A captura de tela a seguir demonstra um banco de dados chamado "teste". Ele é adicionado ao Grupo de Disponibilidade AlwaysOn do SQL Server e está no estado sincronizado.
Como habilitar TDE no SQL Server
Aqui estão as etapas para habilitar o SQL Server TDE para o banco de dados “teste”. Observação :executaremos as etapas a seguir na réplica primária atual.
Etapa 1
Crie uma chave mestra no banco de dados mestre.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Etapa 2
Crie um certificado protegido pela chave mestra.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Etapa 3
Crie a chave de criptografia de banco de dados (DEK) e proteja-a com o certificado criado na etapa 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Etapa 4
Defina o banco de dados “teste” para usar criptografia.
ALTER DATABASE test
SET ENCRYPTION ON;
Como verificar se o TDE está ativado?
Depois de terminar, você precisa confirmar se a Criptografia de Dados Transparente no SQL Server está habilitada para o banco de dados "teste".
Nas Propriedades do banco de dados seção, vá para as Opções página. Lá, preste atenção ao Estado área na parte inferior da janela. A Criptografia ativada o valor deve ser Verdadeiro .
Você também pode executar o seguinte código TSQL para confirmá-lo:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Problema de gerenciamento e certificação de chaves
Observação: Não se surpreenda se descobrir que o tempdb também é criptografado. É porque tempdb é onde todos os tipos de operações ocorrem (por exemplo, classificação, junções de hash etc.), usando os dados de todos os bancos de dados. Portanto, se pelo menos um banco de dados do usuário for criptografado, as operações desse banco de dados específico poderão entrar em tempdb, que precisará retornar esses dados ao banco de dados do usuário. Portanto, o envio de dados não criptografados de volta representaria o problema.
Você pode ler mais sobre criptografia de backup no SQL Server para aumentar a segurança do seu banco de dados.
Você pode usar o seguinte código TSQL para confirmar que há uma chave mestra do banco de dados presente para o banco de dados “teste” criptografado pelo certificado (conforme executado na etapa 3):
SELECT
DB_NAME(database_id) AS DB,
create_date,
key_algorithm,
key_length,
encryptor_thumbprint,
encryptor_type
FROM sys.dm_database_encryption_keys
WHERE DB_NAME(database_id) = 'test'
Até aí tudo bem, pelo menos para a réplica primária. Mas o que acontece se consultarmos os sys.databases visualização do sistema para confirmar o status de criptografia do banco de dados “teste” na réplica secundária?
O Grupo de Disponibilidade replica tudo relacionado ao banco de dados de uma réplica para outra. No entanto, a réplica secundária afirma claramente que não é criptografada.
Vamos verificar nossa Réplica Secundária para quaisquer pistas sobre isso:
O estado do banco de dados é “Não sincronizando/suspeito” – não parecendo nada bem. No entanto, depois de inspecionar o log de erros da réplica secundária, vejo o seguinte:
2021-04-10 00:40:55.940 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.940 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.950 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Always On Availability Groups data movement for database 'test' has been suspended for the following reason: "system" (Source ID 2; Source string: 'SUSPEND_FROM_REDO'). To resume data movement on the database, you will need to resume the database manually. For information about how to resume an availability database, see SQL Server Books Online.
2021-04-10 00:40:55.950 spid39s Error: 3313, Severity: 21, State: 2.
2021-04-10 00:40:55.950 spid39s During redoing of a logged operation in database 'test', an error occurred at log record ID (34:743:1). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
O principal problema é que o certificado usado para criptografar a Chave de Criptografia do Banco de Dados do banco de dados “teste” (Etapa 3) não está presente na Réplica Secundária.
Por quê?
Porque os Grupos de Disponibilidade não replicam dados de bancos de dados do sistema. O certificado do servidor ausente reside no banco de dados mestre da réplica primária.
Como verificar e configurar o certificado TDE no SQL Server
Vamos gerar um backup do certificado do servidor no banco de dados mestre da réplica primária. Em seguida, vamos restaurá-lo no banco de dados mestre da réplica secundária.
Use o seguinte código TSQL para gerar o backup da réplica primária atual que tem o banco de dados “teste” com TDE habilitado:
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Antes de tentar restaurar o certificado na réplica secundária, verifique primeiro se a chave mestra do banco de dados existe no banco de dados mestre. Se não, crie-o exatamente como na Etapa 1.
Use o seguinte código TSQL para restaurar o certificado na réplica secundária. Observação :Certifique-se de copiar primeiro os arquivos .cer e .pvk para o diretório de destino.
USE master;
GO
CREATE CERTIFICATE TestCertificate
FROM FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (
FILE = N'C:\temp\TestCertificate.pvk',
DECRYPTION BY PASSWORD = '<YourStrongPasswordHere>'
);
Assim, mesmo após a restauração do certificado na Réplica Secundária, o estado do banco de dados “teste” permanece o mesmo:
Como a movimentação de dados para o banco de dados “teste” está pausada, vamos retomá-la manualmente para ver se temos sorte desta vez:
Sim! A operação foi bem sucedida. O banco de dados “teste” não é apenas totalmente sincronizado e íntegro, mas também criptografado com TDE.
Além disso, após a realização do failover manual para trocar os papéis das réplicas, tudo continua funcionando perfeitamente bem.
Conclusão
A solução apresentada funcionou perfeitamente bem. No entanto, pode não ser ideal em todos os casos, especialmente se você for um DBA que gosta de planejar e fazer as coisas da maneira “correta”. Eu vejo “correto” da seguinte forma:
- Remova o banco de dados do Grupo de Disponibilidade
- Execute todas as etapas para ativar a Criptografia de dados transparente na réplica em que o banco de dados é lido/gravado.
- Faça backup do certificado do servidor da réplica primária.
- Copie o arquivo de backup para os locais das réplicas secundárias.
- Restaure o certificado no banco de dados mestre.
- Adicione o banco de dados de volta ao Grupo de Disponibilidade.
- Certifique-se de que o estado operacional do banco de dados seja o correto e pretendido (dependendo de sua configuração específica).
Estou colocando aspas duplas para “correto” porque da forma como apresentei a solução consegui o banco de dados na réplica secundária marcado como suspeito. Isso por si só provavelmente levantaria muitas bandeiras/alertas/apontar o dedo indesejados. É um ruído desnecessário que você pode evitar facilmente levando em consideração todas as considerações para planejar e implementar adequadamente o TDE em uma configuração do Always On Availability Group.
Para encerrar este post, estou deixando você com a hierarquia de criptografia oficial usada para TDE, que a Microsoft postou em seu site. O que eu gostaria que você tivesse em mente é onde cada elemento é criado (no banco de dados mestre ou do usuário), para que você possa superar possíveis problemas/surpresas com os Grupos de Disponibilidade.
Caso você não saiba, o SQL Complete pode ajudá-lo muito a configurar o Always Encrypted, que é outra tecnologia útil para proteger dados confidenciais.
Lembre-se de que você precisaria considerar o mesmo que é discutido neste artigo se estiver planejando lidar com Always Encrypted em um cenário Always On Availability Group. No entanto, os recursos que o SQL Complete v6.7 apresenta são projetados para garantir que você tenha sucesso logo de cara.
