Passo a passo dos recursos de segurança do SQL Server em Linux

Aplica-se a: SQL Server - Linux

Se você for um usuário do Linux não familiarizado com o SQL Server, as tarefas a seguir o orientarão em algumas das tarefas de segurança. Elas não são exclusivas nem específicas do Linux, mas ajudam a dar uma ideia de áreas para posterior investigação. Em cada exemplo, um link é fornecido para a documentação detalhada dessa área.

Os exemplos de código do Transact-SQL deste artigo usa o banco de dados de exemplo AdventureWorks2022 ou AdventureWorksDW2022, que pode ser baixado da home page Microsoft SQL Server Samples and Community Projects.

Criar um logon e um usuário de banco de dados

Permite a outros usuários o acesso ao SQL Server criando um logon no banco de dados master usando a instrução CREATE LOGIN. Por exemplo:

CREATE LOGIN Larry WITH PASSWORD = '************';

Observação

Sempre use uma senha forte no lugar dos asteriscos no comando anterior.

Os logons podem se conectar ao SQL Server e ter acesso (com permissões limitadas) ao banco de dados master. Para se conectar a um banco de dados de usuário, um logon precisa ter uma identidade correspondente no nível de banco de dados, chamada usuário de banco de dados. Os usuários são específicos de cada banco de dados e precisam ser criados separadamente em cada banco de dados para permitir acesso a eles. O exemplo a seguir insere você no banco de dados AdventureWorks2022 e, em seguida, usa a instrução CREATE USER para criar um usuário chamado Larry que está associado ao logon chamado Larry. Embora o logon e o usuário estejam relacionados (mapeados entre si), eles são objetos diferentes. O logon é uma entidade de segurança no nível do servidor. O usuário é uma entidade de segurança no nível do banco de dados.

USE AdventureWorks2022;
GO
CREATE USER Larry;
GO

• Uma conta de administrador do SQL Server pode se conectar a qualquer banco de dados e pode criar mais logons e usuários em qualquer banco de dados.
• Quando alguém cria um banco de dados, ele se torna o proprietário do banco de dados, que pode se conectar a esse banco de dados. Os proprietários do banco de dados podem criar mais usuários.

Posteriormente, você pode autorizar outros logons a criar mais logons concedendo a eles a permissão ALTER ANY LOGIN. Em um banco de dados, você pode autorizar outros usuários a criarem mais usuários concedendo a eles a permissão ALTER ANY USER. Por exemplo:

GRANT ALTER ANY LOGIN TO Larry;
GO

USE AdventureWorks2022;
GO
GRANT ALTER ANY USER TO Jerry;
GO

Agora o logon Larry pode criar mais logons e o usuário Jerry pode criar mais usuários.

Como permitir acesso com privilégios mínimos

As primeiras pessoas a se conectarem a um banco de dados de usuário são as contas de administrador e proprietário do banco de dados. No entanto, esses usuários têm todas as permissões disponíveis no banco de dados. Isso representa um número de permissões além do que a maioria dos usuários deve ter.

Quando você estiver apenas começando, poderá atribuir algumas categorias gerais de permissões usando as funções de banco de dados fixas internas. Por exemplo, a função de banco de dados fixa db_datareader pode ler todas as tabelas no banco de dados, mas não pode fazer nenhuma alteração. Permita a associação em uma função de banco de dados fixa usando a instrução ALTER ROLE. O exemplo a seguir adiciona o usuário Jerry à função de banco de dados fixa db_datareader.

USE AdventureWorks2022;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

Para obter uma lista das funções de banco de dados fixas, confira Funções no nível do banco de dados.

Posteriormente, quando estiver pronto para configurar o acesso mais preciso aos seus dados (altamente recomendado), crie suas próprias funções de banco de dados definidas pelo usuário usando a instrução CREATE ROLE. Em seguida, atribua permissões granulares específicas às funções personalizadas.

Por exemplo, as instruções a seguir criam uma função de banco de dados chamada Sales, concede ao grupo Sales a capacidade de ver, atualizar e excluir linhas da tabela Orders e, em seguida, adiciona o usuário Jerry à função Sales.

CREATE ROLE Sales;
GRANT SELECT ON Object::Sales TO Orders;
GRANT UPDATE ON Object::Sales TO Orders;
GRANT DELETE ON Object::Sales TO Orders;
ALTER ROLE Sales ADD MEMBER Jerry;

Para obter mais informações sobre o sistema de permissões, confira Introdução às Permissões do Mecanismo de Banco de Dados.

Configurar segurança em nível de linha

A Segurança em Nível de Linha permite restringir o acesso a linhas em um banco de dados com base no usuário que está executando uma consulta. Esse recurso é útil para cenários como a garantia de que os clientes possam acessar somente os próprios dados ou que os trabalhadores possam acessar apenas os dados pertinentes ao departamento deles.

As etapas a seguir explicam como configurar dois usuários com acesso de nível de linha diferente à tabela Sales.SalesOrderHeader.

Crie duas contas de usuário para testar a segurança em nível de linha:

USE AdventureWorks2022;
GO

CREATE USER Manager WITHOUT LOGIN;
CREATE USER SalesPerson280 WITHOUT LOGIN;

Conceda acesso de leitura à tabela Sales.SalesOrderHeader para ambos os usuários:

GRANT SELECT ON Sales.SalesOrderHeader TO Manager;
GRANT SELECT ON Sales.SalesOrderHeader TO SalesPerson280;

Crie um esquema e uma função com valor de tabela embutida. A função retorna 1 quando uma linha na coluna SalesPersonID corresponde à ID de um logon SalesPerson ou se o usuário que executa a consulta é o usuário Gerente.

CREATE SCHEMA Security;
GO

CREATE FUNCTION Security.fn_securitypredicate(@SalesPersonID AS int)
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS fn_securitypredicate_result
    WHERE ('SalesPerson' + CAST(@SalesPersonId as VARCHAR(16)) = USER_NAME())
    OR (USER_NAME() = 'Manager');

Crie uma política de segurança que adicione a função como um predicado de bloqueio e de filtro na tabela:

CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.fn_securitypredicate(SalesPersonID)
  ON Sales.SalesOrderHeader,
ADD BLOCK PREDICATE Security.fn_securitypredicate(SalesPersonID)
  ON Sales.SalesOrderHeader
WITH (STATE = ON);

Execute o disposto a seguir para consultar a tabela SalesOrderHeader como cada usuário. Verifique se SalesPerson280 vê apenas as 95 linhas das próprias vendas e se o Manager pode ver todas as linhas na tabela.

EXECUTE AS USER = 'SalesPerson280';
SELECT * FROM Sales.SalesOrderHeader;
REVERT;

EXECUTE AS USER = 'Manager';
SELECT * FROM Sales.SalesOrderHeader;
REVERT;

Altere a política de segurança para desabilitar a política específica. Agora ambos os usuários podem acessar todas as linhas.

ALTER SECURITY POLICY SalesFilter
WITH (STATE = OFF);

Habilitar Máscara Dinâmica de Dados

A Máscara Dinâmica de Dados permite limitar a exposição de dados confidenciais a usuários de um aplicativo por meio do mascaramento completo ou parcial de determinadas colunas.

Use uma instrução ALTER TABLE para adicionar uma função de mascaramento à coluna EmailAddress na tabela Person.EmailAddress:

USE AdventureWorks2022;
GO

ALTER TABLE Person.EmailAddress
ALTER COLUMN EmailAddress ADD MASKED
    WITH (FUNCTION = 'email()');

Crie um usuário TestUser com a permissão SELECT na tabela e execute uma consulta como TestUser para ver os dados mascarados:

CREATE USER TestUser WITHOUT LOGIN;

GRANT SELECT ON Person.EmailAddress TO TestUser;

EXECUTE AS USER = 'TestUser';

SELECT EmailAddressID, EmailAddress
FROM Person.EmailAddress;

REVERT;

Verifique se a função de mascaramento altera o endereço de email no primeiro registro de:

EmailAddressID	EmailAddress
1	ken0@adventure-works.com

into

EmailAddressID	EmailAddress
1	kXXX@XXXX.com

Habilite a Transparent Data Encryption

Uma ameaça ao seu banco de dados é o risco de que alguém roube os arquivos de banco de dados de sua unidade de disco rígido. Isso pode acontecer com uma intrusão que obtém acesso elevado ao seu sistema, por meio de ações de um funcionário problemático ou por roubo do computador que contém os arquivos (como um laptop).

A TDE (transparent data encryption) criptografa os arquivos de dados conforme eles são armazenados no disco rígido. O banco de dados master do mecanismo de banco de dados do SQL Server tem a chave de criptografia para que o mecanismo de banco de dados possa manipular os dados. Os arquivos de banco de dados não podem ser lidos sem acesso à chave. Os administradores de alto nível podem gerenciar, fazer backup e recriar a chave, para que o banco de dados possa ser movido, mas apenas por pessoas selecionadas. Quando a TDE é configurada, o banco de dados tempdb também é criptografado automaticamente.

Como o Mecanismo de Banco de Dados pode ler os dados, a TDE não protege contra acesso não autorizado por administradores do computador que pode ler diretamente a memória ou acessar o SQL Server por meio de uma conta de administrador.

Configurar a TDE

• Crie uma chave mestra
• Crie ou obtenha um certificado protegido pela chave mestra
• Crie uma chave de criptografia de banco de dados e proteja-a com o certificado
• Defina o banco de dados para usar criptografia

Configurar a TDE requer a permissão CONTROL no banco de dados master e a permissão CONTROL no banco de dados do usuário. Normalmente, um administrador configura a TDE.

O exemplo a seguir ilustra criptografia e descriptografia do banco de dados AdventureWorks2022 usando um certificado instalado no servidor nomeado MyServerCert.

USE master;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**********';
GO

CREATE CERTIFICATE MyServerCert
    WITH SUBJECT = 'My Database Encryption Key Certificate';
GO

USE AdventureWorks2022;
GO

CREATE DATABASE ENCRYPTION KEY
    WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO

ALTER DATABASE AdventureWorks2022
SET ENCRYPTION ON;

Para remover a TDE, execute o comando a seguir:

ALTER DATABASE AdventureWorks2022 SET ENCRYPTION OFF;

As operações de criptografia e descriptografia são agendadas em threads em segundo plano pelo SQL Server. É possível exibir o status dessas operações usando exibições do catálogo e de gerenciamento dinâmico na lista mostrada adiante neste artigo.

Aviso

Os arquivos de backup de bancos de dados com TDE habilitada também são criptografados usando a chave de criptografia do banco de dados. Como resultado, quando você restaura esses backups, o certificado que protege a chave de criptografia do banco de dados deve estar disponível. Isso significa que, além de fazer backup do banco de dados, assegure-se de que os backups dos certificados de servidor sejam mantidos para evitar perda de dados. Se o certificado não estiver mais disponível, haverá perda de dados. Para obter mais informações, consulte SQL Server Certificates and Asymmetric Keys.

Para obter mais informações sobre a TDE, confira TDE (Transparent Data Encryption).

Configurar a criptografia de backup

O SQL Server tem a capacidade de criptografar os dados durante a criação de um backup. Especificando o algoritmo de criptografia e o criptografador (um certificado ou uma chave assimétrica) ao criar um backup, você pode criar um arquivo de backup criptografado.

Aviso

Sempre faça backup do certificado ou da chave assimétrica e, preferencialmente, em um local diferente do arquivo de backup usado para criptografar. Sem o certificado ou a chave assimétrica, você não pode restaurar o backup, tornando o arquivo de backup inutilizável.

O exemplo a seguir cria um certificado e cria um backup protegido pelo certificado.

USE master;
GO

CREATE CERTIFICATE BackupEncryptCert
    WITH SUBJECT = 'Database backups';
GO

BACKUP DATABASE [AdventureWorks2022]
    TO DISK = N'/var/opt/mssql/backups/AdventureWorks2022.bak'
WITH COMPRESSION,
    ENCRYPTION (
        ALGORITHM = AES_256,
        SERVER CERTIFICATE = BackupEncryptCert
    ),
    STATS = 10
GO

Para obter mais informações, veja Criptografia de backup.

Conteúdo relacionado

• Central de segurança do Mecanismo de Banco de Dados do SQL Server e Banco de Dados SQL do Azure