Como melhorar a segurança do SQL Server?

Descubra como melhorar a segurança do SQL Server 2022 em Microsoft Windows Server, com recurso às melhores práticas para proteção de dados e de uma arquitetura resiliente e segura.

NOTA: É importante referir que tudo o que será aqui descrito está pensado para ambientes SQL Server em Windows Server, embora algumas das recomendações também sejam válidas para sistemas GNU/Linux.

Além da informação mencionada aqui, é recomendável dar uma vista de olhos ao artigo Requisitos e planificação da instalação do SQL Server 2022 no nosso blog.

Dicas e práticas recomendadas para a segurança do SQL Server:

A primeira coisa que devemos ter em mente é que, quando falamos de segurança, nunca existe suficiente. Temos de falar sempre sobre um modelo de camadas de cebola, no qual implementamos diferentes níveis de proteção.

Estes níveis de proteção devem ter uma aplicação holística, ou seja, devem ser aplicados a todos os níveis e aspetos da instalação do servidor da base de dados: desde a instalação física do servidor até aos patches de segurança das aplicações e sistema operativo, ou a maneira em que as consultas são desenhadas.

A seguir, vamos rever alguns dos pontos a considerar para melhorar a segurança da nossa base de dados Microsoft SQL Server em sistemas Microsoft Windows Server.

Segurança física:

O ponto número 1 da segurança de um sistema, antes de entrar na parte lógica, deve ser proteger a máquina física que contém o servidor. Por mais que protejamos um servidor a nível lógico, por mais que coloquemos firewalls, antivírus, façamos correções, configuremos acessos, etc., se não houver segurança física, uma porta que impeça o acesso ao servidor, que controle os acessos, a verificação de temperatura, etc., todos os itens anteriores serão inúteis, porque alguém poderá aceder ao servidor e desligá-lo, destruí-lo, roubá-lo, etc.

A segurança física do servidor pode compreender um grande número de elementos, que incluem o facto de os servidores estarem numa sala separada com acesso controlado (através de porta fechada, fecho eletrónico, sistemas biométricos, etc.) com sistemas de extinção de incêndios, sistemas de ar condicionado para manter a temperatura estável e evitar problemas de sobreaquecimento dos servidores, etc.

Embora não faça parte da segurança física, há outras “facilites” que devem ser tidas em consideração, como fontes de alimentação redundantes, unidades de alimentação ininterrupta (UPS), conexão de diferentes provedores, ligação à Internet (de preferência redundante), etc.

Segurança do sistema operativo:

Não nos cansamos de falar sobre isto. Se não tivermos um sistema operativo forte, é impossível executar uma aplicação segura.

Em primeiro lugar, temos de dizer que é essencial implementar apenas os serviços fundamentais no servidor e que é desejável não implementar mais de um por servidor, sendo preferível usar máquinas virtuais, contentores, etc. Desta forma, evitaremos a possibilidade de criar pontos críticos de erro na nossa infraestrutura. Obviamente, no caso das bases de dados, estas devem ser implementadas num servidor isolado que não forneça nenhum outro serviço além desse.

Devemos aplicar todos os patches e atualizações possíveis, mas só aqueles que se destinam à nossa plataforma.

Com isto, queremos dizer que, pode ser contraproducente aplicar um patch criado para um hardware específico se não tivermos esse hardware, e que se houver um patch para o Office e não tivermos o Office instalado, é melhor ignorá-lo, porque pode ter algum bug, problema, etc.

Relembramos que é preferível fazer o deploy de um ambiente de teste para implementar as nossas atualizações e testá-las antes de as colocar em produção.

Claro que, além das atualizações, devemos instalar algum software antivírus e antimalware que nos proteja das mil e uma ameaças que existem hoje em dia, e que não param de melhorar e surgir continuamente.

Para terminar este ponto, não devemos esquecer a firewall do sistema operativo, que deve ter apenas as portas necessárias abertas para poder operar. Para reforçar este ponto, recomendamos consultar este tutorial (em inglês) onde pode aprender como configurar as portas exigidas pelo SGBD. Da mesma forma, recomendamos dar uma vista de olhos ao seguinte conteúdo do site da Microsoft, para saber como configurar o serviço SSIS com a firewall do Windows.

A seguir, vamos rever algumas das recomendações para melhorar a segurança do SQL Server.

Segurança dos ficheiros do SQL Server:

O SQL Server usa o sistema de ficheiros do sistema operativo para armazenar alguns ficheiros. Para evitar problemas, o acesso a estes ficheiros deve ser limitado. Para isso, devemos determinar os caminhos a proteger, e a primeira coisa que devemos fazer é lançar a seguinte frase no SSMS:

SELECT CONVERT(char(20), SERVERPROPERTY(‘productlevel’));

NOTA: No nosso caso estamos a trabalhar com o SQL Server 2022, que é 16.x, mas fica a explicação para quem tiver outras versões.

Como resultado:

Quando soubermos a versão do nosso SQL Server, podemos substituir a versão na string “<unidade>:\Ficheiros de Programas\Microsoft SQL Server\nnn\”.

Onde:

• <unidade>: será a letra da unidade onde o SQL Server está instalado, por exemplo “E:”.
• nnn: Identifica a versão do SQL Server.

Além disso, deve-se ter em consideração que, dependendo da instalação, haverá diferentes elementos e nomenclaturas.

• MSSQL: Mecanismo do SQL Server. Seguido por um número de versão, um underscore e a versão secundária, um ponto e o nome da instância. Por exemplo: MSSQL{nn}.MSSQLSERVER.
• MSAS: Analysis Services. Seguido por um número de versão, um underscore e a versão secundária, um ponto e o nome da instância. Por ejemplo: MSAS{nn}.MSSQLSERVER.
• MSRS: Reporting Services. Seguido por um número de versão, um underscore e a versão secundária, um ponto e o nome da instância. Por exemplo: MSSQL{nn}.<instancia>.

Dito isto, pode-se especificar que, para uma instância chamada “TesteManuel”, os caminhos seriam os seguintes:

• C:\Ficheiros de programa\Microsoft SQL Server\MSSQL16\
• C:\Ficheiros de programa\Microsoft SQL Server\MSAS16.TesteManuel\
• C:\Ficheiros de programa\Microsoft SQL Server\MSRS16.TesteManuel\

Segurança do SQL Server no registo do sistema:

Da mesma forma que os caminhos dos ficheiros do sistema operativo são protegidos no que se refere ao SQL Server, as entradas do SGBD devem ser protegidas no registo do Windows (acessível com o RegEdit).

Conhecendo a versão, devem proteger-se as entradas do hive do registo criadas em “HKLM\Software\Microsoft\Microsoft SQL Server<instância>”.

Um exemplo disto para a nossa instância “TesteManuel” seria:

• HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL16.TesteManuel
• HKLM\Software\Microsoft\Microsoft SQL Server\MSAS16.TesteManuel
• HKLM\Software\Microsoft\Microsoft SQL Server\MSRS16.TesteManuel

Configuração do mecanismo de bases de dados SQL Server para criptografia de conexões:

Para proteger a plataforma, é necessário criptografar todas as conexões de entrada ao Microsoft SQL Server, e também é possível habilitar a criptografia apenas para um conjunto específico de clientes, o que, a nosso ver, é menos seguro do que forçar a criptografia para todos.

Para configurar esta encriptação, a primeira coisa que a fazer é configurar o SQL Server para usar um certificado que cumpra os requisitos do certificado para SQL Server. Isto permitirá avançar com os seguintes pontos necessários para dotar a infraestrutura do SGBD com segurança adicional.

Não queremos alongar-nos demasiado neste artigo, por isso preferimos recomendar a leitura deste artigo da Microsoft, onde se pode aprender a configurar o SQL Server para usar certificados e como alterar as configurações de criptografia da instância do SQL Server. Com estas duas etapas podemos encriptar todas as conexões de entrada ao SQL Server para o uso de um certificado de uma entidade comercial pública.

Alteração das contas utilizadas pelos serviços:

Outro ponto bastante simples e fácil de implementar é a alteração das contas utilizadas para autenticação do SQL Server pelos serviços. Isto é realmente necessário, tanto para alteração de passwords (que não deveria ser um problema pois devem ser únicas), como para alterar os nomes de utilizador para que não sejam genéricos, o que aumentará significativamente a segurança.

Para fazer estas alterações, devemos aceder ao SQL Server Configuration Manager, no próprio Windows ou na consola, com “C:\Windows\SysWOW64\SQLServerManager<nn>.msc”, substituindo <nn> pela versão do SQL Server instalada.

Recordamos que, neste mesmo artigo, na secção “Segurança dos ficheiros do SQL Server”, é explicado como se pode conhecer a versão do SQL Server que estamos a implementar, sendo por exemplo 16 para o SQL Server 2022. Neste caso, o caminho seria: “C:\Windows\SysWOW64\SQLServerManager16.msc”.

NOTA: Quando se faz uma alteração de password no SQL Server Configuration Manager, essa alteração entra em vigor sem exigir a reinicialização do serviço.

Mascaramento de dados dinâmicos:

O uso de mascaramento dinâmico de dados, também conhecido como DDM pela sigla em inglês (Dynamic Data Masking), fornece uma camada adicional de proteção ao limitar o acesso às informações por utilizadores não privilegiados.

NOTA: O DDM está disponível desde a versão SQL Server 2016.

Este é um modelo que agrega boa segurança com mínimo esforço.

O mascaramento dinâmico de dados permite que os clientes especifiquem a quantidade de informações que devem estar disponíveis para visualização e quem tem permissão de acesso.

Uma das vantagens do DDM é que pode ser aplicado aos campos mais sensíveis, sem ocultar outros dados da mesma tabela e impedindo o acesso a colunas específicas.

Para a implementação do DDM, é preciso definir uma política central de mascaramento de dados, que deve atuar em campos confidenciais da base de dados. Em seguida, devem ser designados os utilizadores ou funções (roles) com acesso à informação, o que negará o acesso aos restantes utilizadores e funções.

Para configurar o mascaramento dinâmico de dados vamos usar comandos de T-SQL, mas devemos ter em consideração uma sintaxe específica e uma série de limitações ao seu uso.

Para começar, importa saber que não se pode usar o DDM nos seguintes tipos de colunas:

• Colunas criptografadas.
• Filestream.
• Column_Set.
• Coluna de Tabela Externa PolyBase.
• Colunas de Índice FULLTEXT.

Também devemos ter em conta que nao é possível criar máscaras em colunas calculadas, mas se usarmos uma coluna mascarada para o cálculo de uma coluna, o resultado será mascarado.

As permissões necessárias para criar um DDM são as de CREATE TABLE e ALTER, enquanto as permissões ALTER ANY MASK e ALTER TABLE são necessárias para modificar, adicionar, substituir ou eliminar. Por fim, a visualização será feita com SELECT, como qualquer outra consulta, mas dependerá das possibilidades de acesso.

Para saber mais sobre esta opção, recomendamos visitar o site da Microsoft.

Proteção estendida para o mecanismo de bases de dados:

O SQL Server possui um recurso de segurança que curiosamente não é ativado por padrão, mas deve ser ativado pelo administrador. Esta é a Proteção Expandida para Autenticação.

Trata-se de um recurso dos componentes de rede implementados pelo sistema operativo que permite realizar conexões mais seguras quando são feitas com Proteção Expandida.

Esta função usa a ligação do serviço e ligação do canal para impedir ataques de retransmissão de autenticação, nos quais um cliente que pode executar a autenticação NTLM se conecta a um invasor quando este usa as credenciais do cliente para autenticar-se num serviço.

Para habilitar esta função, vamos ao “SQL Server Configuration Manager”, expandimos a configuração de rede do SQL Server e acedemos às propriedades de “Protocols of _<instance>” onde <instance> será o nome da instância a configurar.

Aí, devemos procurar o valor “Proteção Expandida” nas opções avançadas e marcamos a opção de forçar a criptografia.

Para que as alterações entrem em vigor é preciso reiniciar a base de dados.

Revisão da conta SA:

A conta SA é um velho conhecido dos administradores do SQL Server e de certeza que gerou várias discussões entre eles e os administradores de sistemas operativos. Esta conta é usada para fazer login no próprio mecanismo da base de dados do SQL Server e tem acesso com privilégios de administrador do sistema.

Esta é uma conta criada por padrão no servidor enquanto a instância padrão do master é implementada. É importante saber que os seus privilégios não podem ser limitados, mas podem ser desativados.

A melhor opção seria exigir a utilização da autenticação do Windows, o que desativaria a autenticação do SQL Server. Isto significa que a conta SA continuaria presente, mas desativada, com uma password aleatória e altamente complexa.

Limitação de utilizador convidado (guest) do SQL Server:

Todas as bases de dados do SQL Server, assim como outras aplicações, incluem a figura do utilizador convidado, também conhecido como guest. As permissões que este utilizador possui aplicam-se a todos os utilizadores que têm acesso à base de dados sem ter uma conta própria.

Esta conta não pode ser excluída, mas pode ser desativada com revogação da permissão de conexão.

NOTA: Pode usar o comando T-SQL “REVOKE CONNECT FROM GUEST;” em bases de dados que não sejam master ou tempdb.

Exploração de canal lateral:

Os sistemas informáticos precisam de suportes físicos para se manterem operacionais, o que leva à geração de todo o tipo de vestígios, como tempo, imagem, som, etc.

A vulnerabilidade do canal lateral explora algumas dessas impressões digitais para obter informações confidenciais através de um algoritmo. Para obter esta informação analisam padrões de outputs que os computadores emitem constantemente.

Para minimizar o risco de um ataque de canal lateral num sistema SQL Server, podemos usar os seguintes pontos:

• Manter o sistema o mais atualizado possível (não nos cansamos de insistir).
• Usar as atualizações de firmware mais recentes para todo o hardware local.
• Se estivermos a trabalhar com cloud pública, devemos adicionar proteção adicional contra ataques de canal lateral com máquinas virtuais isoladas, hosts dedicados ou aproveitando máquinas virtuais de processos sensíveis.
• Para cloud privada, existem opções como máquinas virtuais blindadas Microsoft Hyper-V.

Proteção contra injeção de SQL:

A injeção de SQL, “SQL injection” ou “SQLi” é uma vulnerabilidade de segurança de serviços web, que permite que um invasor modifique as consultas que chegam à base de dados a partir de uma aplicação.

Os invasores costumam usar esta vulnerabilidade para exfiltrar dados normalmente inacessíveis, incluindo dados pertencentes a outros utilizadores ou outros dados normalmente usados pela aplicação.

Nos casos mais críticos, o invasor poderá modificar ou até eliminar dados contidos na base de dados, causando alterações persistentes no conteúdo e no comportamento da aplicação.

Para minimizar o risco de uma injeção de SQL, devemos considerar os pontos seguintes:

• Construir instruções SQL geradas dinamicamente de forma parametrizada.
• Todos os códigos relacionados com EXECUTE, EXEC ou “sp_executesql” devem ser revistos por administradores de segurança e developers.
• Revisão dos processos que constroem instruções SQL.
• Validação consistente das entradas dos utilizadores.
• Limpar as saídas de erro de transposição.

Para além dos pontos anteriores, não devem permitir-se os seguintes caracteres de entrada:

• “;” Delimitador de consultas.
• “’” Delimitador de string de dados de caracteres.
• “—“ Delimitador de comentário de linha única.
• “/ * … * /” Delimitador de comentário.
• “xp_” Procedimentos armazenados estendidos de catálogo, como “xp_cmdshell”.

Devemos substituir “xp_cmdshell” por “SQLCLR”, porque o seu uso é não é recomendado em ambientes SQL Server.

Autenticação do Windows para Reporting Services:

O sistema operativo é responsável por gerir a autenticação dos utilizadores para uso do Reporting Services através de segurança integrada, o que permite validar as credenciais do utilizador.

Mas não tem de ser assim necessariamente. Podemos desenvolver a autenticação personalizada no Reporting Services para oferecer suporte a esquemas de autenticação adicionais através da interface de extensão de segurança conhecida como “IAuthenticationExtension2”.

Para saber como aproveitar esta funcionalidade, recomendamos a leitura do seguinte recurso da Microsoft.

Auditoria de sistema e bases de dados:

Para ter um sistema seguro, será útil fazer auditorias e criar relatórios frequentes sobre as aplicações e o próprio sistema operativo. Para isso, devem ser criadas políticas de auditoria ao nível do servidor, bem como ao nível da base de dados.

Ao criar as auditorias, não devemos esquecer as tabelas nem as colunas com dados confidenciais que tenham qualquer tipo de medidas de segurança.

Além de criar regras e relatórios, estes devem rever-se de vez em quando para verificar se está tudo bem e ativar as operações pertinentes caso se encontre algum problema.

Pode obter mais informação sobre as auditorias de SQL Server no site da Microsoft.

Passwords seguras:

Ao longo deste artigo, assim como em muitos outros escritos anteriormente e noutros que escreveremos mais adiante, falamos sobre a necessidade do uso de passwords seguras, e não podemos terminar este artigo sem responder à seguinte pergunta: O que é uma password forte para a Microsoft?

Bem, em primeiro lugar, isso depende um pouco dos requisitos que são definidos pelo domínio ou pela aplicação usada para validação e, além disso, devido ao poder dos equipamentos e ferramentas voltadas para descobrir passwords, é necessário aumentar constantemente o número de caracteres utilizados. Em linhas gerais, podemos dizer que uma boa password deve seguir estas regras:

• Ter um comprimento mínimo de oito caracteres.
• Não conter o nome da organização, de um utilizador ou de uma pessoa.
• Não conter palavras que existam num dicionário.
• Não ser parecida com qualquer password anterior.
• Deve conter maiúsculas.
• Deve conter minúsculas.
• Deve conter números.
• Deve contar caracteres especiais.

Conclusão

Ao longo deste artigo, revimos algumas das práticas recomendadas para melhorar a segurança do SQL Server 2022 (ou outras versões). Os conselhos dados neste artigo são realmente úteis para todas as versões suportadas atualmente, incluindo on-premise e on-cloud.

Revisamos alguns pontos sobre segurança física, alguns sobre codificação, consulta e até programação, e outros relacionados com a administração, principalmente na parte de processos e utilizadores.

Todos estes pontos visam melhorar a segurança, mas devemos dizer que o mais importante, como já dissemos noutras ocasiões, é ter uma planificação correta, que nos ajudará a eliminar a maioria das vulnerabilidades ou erros de implementação.

Este artigo, como é lógico, não podia ser infinito, (seria aborrecido!) por isso ficaram de fora alguns pontos, como o uso de funções criptográficas Transact-SQL, que abordaremos posteriormente.

Acreditamos que, com estas dicas, conseguirá melhorar a segurança das suas bases de dados, mas lembre-se de que estes são apenas alguns dos pontos a ter em conta. É importante continuar a investigar e adicionar novos pontos.

Obrigado por acompanhar-nos!