A Microsoft tem vários recursos de segurança no SQL Server 2017 que são úteis para diferentes propósitos, dependendo do que você está tentando proteger e de quais ameaças você está tentando proteger. Alguns desses recursos de segurança podem ter implicações de desempenho das quais você deve estar ciente ao decidir quais deseja implementar. Como introdução, abordarei alguns destaques de vários desses recursos de segurança.
Criptografia de banco de dados transparente (TDE)
Transparent Data Encryption (TDE) é a forma de criptografia em repouso do SQL Server, o que significa que seus arquivos de dados, arquivo de log, arquivos tempdb e backups completos, diferenciais e de log do SQL Server serão criptografados quando você habilitar a TDE em um banco de dados de usuário . Isso protege seus dados de alguém que tenha acesso a esses bancos de dados ou arquivos de backup de banco de dados, desde que essa pessoa também não tenha acesso a seus certificados e chaves de criptografia.
A varredura de criptografia TDE inicial para um banco de dados de usuário usará um thread de CPU em segundo plano por arquivo de dados no banco de dados (se os arquivos de dados estiverem localizados em unidades lógicas separadas), para ler lentamente todo o conteúdo do arquivo de dados na memória à taxa de cerca de 52 MB/segundo por arquivo de dados (se os arquivos de dados estiverem localizados em unidades lógicas separadas).
Os dados são então criptografados com o algoritmo de criptografia escolhido e, em seguida, gravados de volta no arquivo de dados a cerca de 55 MB/por segundo (por arquivo de dados, se estiverem em unidades lógicas separadas). Essas taxas de leitura e gravação sequenciais parecem ser propositadamente limitadas e são consistentes em meus testes em vários sistemas com vários tipos de armazenamento.
O processo de criptografia TDE inicial acontece no nível da página, abaixo do SQL Server, portanto, não causa bloqueio ou gera atividade de log de transações como você veria com a reconstrução de um índice. Você pode pausar uma verificação de criptografia TDE ativando o TF 5004 global e despausá-la desativando o TF 5004 e executando o comando ALTER DATABASE dbNAME SET ENCRYTION ON novamente, sem perda de progresso.
O impacto da criptografia/descriptografia na CPU é bastante reduzido no SQL Server 2016 e mais recente se você tiver um processador que dê suporte a instruções de hardware AES-NI. No espaço do servidor, eles foram introduzidos na família de produtos Intel Xeon 5600 (Westmere-EP) para servidores de dois soquetes e na família de produtos Intel Xeon E7-4800/8800 (Westmere-EX) para servidores de quatro e oito soquetes. Qualquer família de produtos Intel mais recente também terá suporte AES-NI. Se você estiver em dúvida se o seu processador suporta AES-NI, você pode procurar por “AES” na saída do campo de instruções da CPU-Z, como você vê na Figura 1.
Figura 1:saída CPU-Z mostrando suporte a instruções AES Depois de criptografar um banco de dados com TDE, o impacto do tempo de execução do TDE é difícil de quantificar de forma previsível porque depende absolutamente de sua carga de trabalho. Se, por exemplo, sua carga de trabalho couber inteiramente no pool de buffers do SQL Server, haverá essencialmente zero sobrecarga do TDE. Se, por outro lado, sua carga de trabalho consistir inteiramente em varreduras de tabela onde a página é lida e depois liberada quase imediatamente, isso imporia a penalidade máxima. A penalidade máxima para uma carga de trabalho volátil de E/S é normalmente inferior a 5% com hardware moderno e com SQL Server 2016 ou posterior.
O trabalho extra de descriptografia TDE acontece quando você lê dados no buffer pool do armazenamento, e o trabalho extra de criptografia TDE acontece quando você grava os dados de volta no armazenamento. Certificar-se de que você não está sob pressão de memória, ter um pool de buffers grande o suficiente e fazer o ajuste de índice e consulta obviamente reduzirá o impacto no desempenho do TDE. TDE não criptografa dados FILESTREAM e um banco de dados criptografado TDE não usará inicialização de arquivo instantânea para seus arquivos de dados.
Antes do SQL Server 2016, a TDE e a compactação de backup nativa não funcionavam bem juntas. Com o SQL Server 2016 e posterior, você pode usar TDE e compactação de backup nativa juntos, desde que especifique um MAXTRANSFERSIZE maior que 64 K no comando de backup. Também é muito importante que você esteja atualizado com suas atualizações cumulativas, pois houve vários hotfixes importantes relacionados ao TDE para SQL Server 2016 e SQL Server 2017. Por fim, o TDE ainda é um recurso apenas do Enterprise Edition, mesmo após o SQL Server 2016 SP1 (que adicionou muitos recursos somente corporativos à Standard Edition).
Segurança em nível de linha (RLS)
A segurança em nível de linha (RLS) limita o acesso de leitura e a maioria dos acessos em nível de gravação com base nos atributos do usuário. O RLS usa o que é chamado de controle de acesso baseado em predicado. O SQL Server aplica as restrições de acesso na camada de banco de dados e elas serão aplicadas sempre que houver uma tentativa de acesso aos dados de qualquer camada.
O RLS funciona criando uma função de predicado que limita as linhas que um usuário pode acessar e, em seguida, usando uma política de segurança e um predicado de segurança para aplicar essa função a uma tabela.
Existem dois tipos de predicados de segurança, que são predicados de filtro e predicados de bloco. Os predicados de filtro filtrarão silenciosamente as linhas disponíveis para operações de leitura (SELECT, UPDATE e DELETE), adicionando essencialmente uma cláusula WHERE que impede que as linhas filtradas apareçam no conjunto de resultados. Predicados de filtro são aplicados durante a leitura dos dados da tabela base e o usuário ou aplicativo não saberá que as linhas estão sendo filtradas dos resultados. É importante, do ponto de vista do desempenho, ter um índice de armazenamento de linhas que cubra seu predicado de filtro RLS.
Predicados de bloco explicitamente (com uma mensagem de erro) operações de gravação de bloco (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE e BEFORE DELETE) que violariam o predicado de bloco.
Predicados de filtro e bloco são criados como funções com valor de tabela em linha. Você também precisará usar a instrução T-SQL CREATE SECURITY POLICY para aplicar e habilitar a função de filtragem para a tabela base relevante
O RLS foi adicionado ao SQL Server 2016 e está disponível em todas as edições do SQL Server 2016 e mais recentes. RLS não funcionará com Filestream, Polybase e exibições indexadas. O RLS pode prejudicar o desempenho da pesquisa de texto completo e pode forçar as consultas de índices columnstore a usar o modo de linha em vez do modo de lote. Esta postagem no blog da Microsoft tem mais informações sobre o impacto do RLS no desempenho. Um bom exemplo de como usar o Repositório de Consultas para ajustar o desempenho do RLS está aqui.
Mascaramento de Dados Dinâmicos (DDM)
O mascaramento dinâmico de dados (DDM) pode ajudar a limitar a exposição de dados confidenciais mascarando-os para usuários não privilegiados. O DDM é aplicado no nível da tabela para que todas as consultas sejam afetadas pelo mascaramento de dados, enquanto as regras de mascaramento reais são aplicadas em colunas individuais na tabela.
Existem quatro tipos de máscaras de dados que você pode usar, que incluem padrão, email, string personalizada e aleatória. Uma máscara padrão fornece mascaramento padrão completo dos dados, dependendo do tipo de dados. Por exemplo, um tipo de dados de string obteria uma máscara de 'XXXX' em vez dos dados reais. Uma máscara de e-mail retornará a primeira letra do endereço de e-mail real, seguida de [email protected], independentemente do sufixo de domínio real. Uma máscara de string personalizada mostrará as primeiras e últimas letras da string, com um preenchimento personalizado no meio. Finalmente, uma máscara aleatória é usada para mascarar dados numéricos e fornecer um valor aleatório em um intervalo definido. As máscaras de dados podem ser criadas em uma instrução CREATE TABLE ou com uma instrução ALTER COLUMN.
O mascaramento de dados dinâmicos não oferece mascaramento para usuários privilegiados que ainda podem consultar diretamente suas tabelas e ver os dados desmascarados. As regras de mascaramento não podem ser usadas com colunas criptografadas (sempre criptografado), colunas computadas ou com dados de fluxo de arquivos. Se houver índices existentes em uma coluna que você deseja mascarar, será necessário descartar o índice, criar a máscara na coluna e recriar o índice. Também é possível inferir os valores para colunas de dados mascarados escrevendo consultas que permitem ao usuário eventualmente adivinhar um valor para uma coluna mascarada.
O mascaramento de dados dinâmico foi introduzido no SQL Server 2016 e está disponível em todas as edições do SQL Server. O DDM não deve ser uma medida de segurança forte como a criptografia real, mas, por outro lado, seu impacto no desempenho parece ser bastante insignificante.
