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

Aplica-se a: SQL Server no 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. Essas tarefas não são exclusivas ou específicas do Linux, mas dão uma ideia das áreas a serem exploradas mais a fundo. Cada exemplo faz link para a documentação detalhada daquela área.

Os exemplos de código neste artigo usam o banco de dados de exemplo AdventureWorks2025 ou AdventureWorksDW2025, que você pode baixar na página inicial Microsoft SQL Server Samples and Community Projects.

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

Conceda a outros acesso ao SQL Server criando um login no master banco de dados com a CREATE LOGIN instrução. Por exemplo:

CREATE LOGIN Larry
    WITH PASSWORD = '<password>';

Caution

Sua senha deve seguir a política de senha padrão do SQL Server. Por padrão, a senha precisa ter pelo menos oito caracteres e conter caracteres de três dos seguintes quatro conjuntos: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos. As senhas podem ter até 128 caracteres. Use senhas que sejam tão longas e complexas quanto possível.

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 para cada banco de dados, então você deve criá-los separadamente em cada banco para conceder acesso.

O exemplo a seguir muda para o AdventureWorks2025 banco de dados e então usa a CREATE USER instrução para criar um usuário chamado Larry que mapeia para o login chamado Larry. Embora o login e o usuário estejam relacionados (mapeados um ao outro), 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 AdventureWorks2025;
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 você cria um banco de dados, você se torna o dono do banco e pode se conectar a esse banco. 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 AdventureWorks2025;
GO

GRANT ALTER ANY USER TO Jerry;
GO

Agora o login Larry pode criar mais logins, e o usuário Jerry pode criar mais usuários.

Como permitir acesso com privilégios mínimos

Administradores e donos de banco de dados geralmente são os primeiros usuários a se conectar a um banco de usuários. Essas contas têm todas as permissões no banco de dados. Não use essas contas para tarefas que exigem menos permissões.

Quando você está começando, pode atribuir algumas categorias gerais de permissões com os papéis fixos de banco de dados embutidos. Por exemplo, o db_datareader papel fixo de banco de dados pode ler todas as tabelas do banco de dados, mas não pode fazer alterações. Conceda a participação em um papel fixo de banco de dados com a declaração ALTER ROLE . O exemplo a seguir adiciona o usuário Jerry ao papel de banco de dados fixo db_datareader .

USE AdventureWorks2025;
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.

Mais tarde, quando estiver pronto para configurar um acesso mais preciso aos seus dados (altamente recomendado), crie seus próprios papéis de banco de dados definidos pelo usuário com a CREATE ROLE instrução. Em seguida, atribua permissões granulares específicas às funções personalizadas.

Por exemplo, as seguintes instruções criam um papel de banco de dados chamado Sales, concedam ao Sales grupo a capacidade de ler, atualizar e excluir linhas da Orders tabela, e então adicionar o usuário Jerry à Sales função.

CREATE ROLE Sales;

GRANT SELECT ON OBJECT::Orders TO Sales;
GRANT UPDATE ON OBJECT::Orders TO Sales;
GRANT DELETE ON OBJECT::Orders TO Sales;

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 a 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 executa uma consulta. Esse recurso é útil para cenários como garantir que os clientes possam acessar apenas seus próprios dados ou que os trabalhadores possam acessar apenas os dados do seu departamento.

Os passos a seguir acompanham a configuração de dois usuários com acesso diferente em nível de linha à Sales.SalesOrderHeader tabela.

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

USE AdventureWorks2025;
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 novo esquema e uma função embutida com valor de tabela. A função retorna 1 quando uma linha na SalesPersonID coluna corresponde ao ID de um SalesPerson login, ou quando o usuário que executa a consulta é o usuário.Manager

CREATE SCHEMA Security;
GO

CREATE FUNCTION Security.fn_securitypredicate
(@SalesPersonID 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 as seguintes instruções para consultar a SalesOrderHeader tabela como cada usuário. Verifique se SalesPerson280 vê apenas as 95 linhas relativas às 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 desativá-la. Agora ambos os usuários podem acessar todas as linhas.

ALTER SECURITY POLICY SalesFilter
    WITH (STATE = OFF);

Habilitar o mascaramento de dados dinâmicos

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 AdventureWorks2025;
GO

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

Crie um novo usuário TestUser com SELECT permissão na tabela e então execute uma consulta para TestUser visualizar 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	Endereço de Email
1	ken0@adventure-works.com

em

EmailAddressID	Endereço de Email
1	kXXX@XXXX.com

Ative a criptografia transparente de dados

Um atacante pode roubar arquivos de banco de dados do seu disco rígido. Isso pode ocorrer se um atacante obtiver acesso elevado ao sistema, se um funcionário pegar os arquivos ou se alguém roubar o computador que os guarda.

A TDE (transparent data encryption) criptografa os arquivos de dados conforme eles são armazenados no disco rígido. O master banco de dados do Mecanismo de Banco de Dados do SQL Server possui 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. Administradores de alto nível podem gerenciar, fazer backup e recriar a chave, para que apenas pessoas selecionadas possam mover o banco de dados. Quando você ativa o TDE, o SQL Server também criptografa automaticamente o tempdb banco de dados.

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

Configurar 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 a criptografia e descriptografia do AdventureWorks2025 banco de dados com um certificado nomeado MyServerCert instalado no servidor.

USE master;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

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

USE AdventureWorks2025;
GO

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

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION ON;

Para remover a TDE, execute o comando a seguir:

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION OFF;

O SQL Server agenda as operações de criptografia e descriptografia em threads em segundo plano. Você pode ver o status dessas operações com as visualizações de catálogo e as vistas de gerenciamento dinâmico na lista que aparece mais adiante neste artigo.

Warning

A chave de criptografia do banco de dados também criptografa arquivos de backup de bancos de dados que possuem TDE ativado. Como resultado, quando você restaura esses backups, o certificado que protege a chave de criptografia do banco de dados deve estar disponível. Além de fazer backup do banco de dados, você deve fazer backup dos certificados do servidor para evitar perda de dados. Resultados de perda de dados se o certificado não estiver mais disponível. 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 pode criptografar dados enquanto cria 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.

Warning

Sempre faça backup do certificado ou da chave assimétrica, e de preferência para um local diferente do arquivo de backup que ele criptografa. 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 [AdventureWorks2025]
TO DISK = N'/var/opt/mssql/backups/AdventureWorks2025.bak'
WITH COMPRESSION,
    ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupEncryptCert),
    STATS = 10;
GO

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

Conteúdo relacionado

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