Partilhar via

Guias para as funcionalidades de segurança do SQL Server no Linux

Aplica-se a:SQL Server em Linux

Se é um utilizador de Linux que é novo no SQL Server, as seguintes tarefas guiam-no em algumas das tarefas de segurança. Estas não são exclusivas ou específicas do Linux, mas ajudam a ter uma ideia das áreas a investigar mais a fundo. Em cada exemplo, é fornecido um link para a documentação detalhada dessa área.

Os exemplos de código neste artigo usam o banco de dados de exemplo AdventureWorks2025 ou AdventureWorksDW2025, que pode ser descarregado da página inicial de Exemplos e Projetos da Comunidade do Microsoft SQL Server.

Crie um login e um utilizador de base de dados

Conceda a outros acesso ao SQL Server criando um login na master base de dados usando a instrução CREATE LOGIN . Por exemplo:

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

Atenção

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

Os logins podem ligar-se ao SQL Server e ter acesso (com permissões limitadas) à master base de dados. Para se ligar a uma base de dados de utilizadores, um login necessita de uma identidade correspondente ao nível da base de dados, chamada utilizador de base de dados. Os utilizadores são específicos para cada base de dados e devem ser criados separadamente em cada base de dados para lhes dar acesso. O exemplo seguinte leva-o para a AdventureWorks2025 base de dados e depois usa a instrução CREATE USER para criar um utilizador chamado Larry, associado ao login chamado Larry. Embora o login e o utilizador estejam relacionados (mapeados um para o outro), são objetos diferentes. O login é um princípio ao nível do servidor. O utilizador é um principal ao nível da base de dados.

USE AdventureWorks2022;
GO

CREATE USER Larry;
GO
  • Uma conta de administrador SQL Server pode ligar-se a qualquer base de dados e pode criar mais logins e utilizadores em qualquer base de dados.
  • Quando alguém cria uma base de dados, torna-se o proprietário da base de dados, que pode ligar-se a essa base de dados. Os proprietários de bases de dados podem criar mais utilizadores.

Mais tarde, pode autorizar outros logins a criar mais logins, concedendo-lhes essa ALTER ANY LOGIN permissão. Dentro de uma base de dados, pode autorizar outros utilizadores a criar mais utilizadores concedendo-lhes essa ALTER ANY USER permissão. Por exemplo:

GRANT ALTER ANY LOGIN TO Larry;
GO

USE AdventureWorks2022;
GO

GRANT ALTER ANY USER TO Jerry;
GO

Agora, o Larry de login pode criar mais logins, e o utilizador Jerry pode criar mais utilizadores.

Conceder acesso com o mínimo de privilégios

As primeiras pessoas a ligar-se a uma base de dados de utilizador são as contas de administrador e proprietário da base de dados. No entanto, estes utilizadores têm todas as permissões disponíveis na base de dados. Isto é mais permissões do que a maioria dos utilizadores deveria ter.

Quando está a começar, pode atribuir algumas categorias gerais de permissões usando as funções fixas incorporadas da base de dados. Por exemplo, a função de base de dados fixo db_datareader pode ler todas as tabelas da base de dados, mas não fazer alterações. Conceda a adesão a uma função fixa de base de dados utilizando a instrução ALTER ROLE . O exemplo seguinte adiciona o utilizador Jerry à função de base de dados fixa db_datareader.

USE AdventureWorks2022;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

Para uma lista dos papéis fixos na base de dados, veja Papéis ao nível da base de dados.

Mais tarde, quando estiver pronto para configurar um acesso mais preciso aos seus dados (altamente recomendado), crie os seus próprios papéis de base de dados definidos pelo utilizador usando a instrução CREATE ROLE . Depois atribui permissões granulares e específicas às tuas funções personalizadas.

Por exemplo, as seguintes instruções criam um papel de base de dados chamado Sales, concede ao Sales grupo a capacidade de ver, atualizar e eliminar linhas da Orders tabela, e depois adiciona o utilizador Jerry ao Sales papel.

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 mais informações sobre o sistema de permissões, consulte Começar com permissões do Motor de Base de Dados.

Configurar a segurança em nível de linha

A segurança ao nível das linhas permite-lhe restringir o acesso a linhas numa base de dados com base no utilizador a executar uma consulta. Esta funcionalidade é útil para cenários como garantir que os clientes só possam aceder aos seus próprios dados ou que os trabalhadores só possam aceder a dados pertinentes ao seu departamento.

Os passos seguintes acompanham a configuração de dois Utilizadores com acesso diferente ao nível da linha à Sales.SalesOrderHeader tabela.

Crie duas contas de utilizador para testar a segurança ao nível da linha:

USE AdventureWorks2022;
GO

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

Conceda acesso de leitura na Sales.SalesOrderHeader tabela a ambos os utilizadores:

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

Crie um novo esquema e uma função inline com valores de tabela. A função devolve 1 quando uma linha na SalesPersonID coluna corresponde ao ID de um SalesPerson login ou se o utilizador que executa a consulta for o utilizador Gestor.

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 adicionando a função como filtro e como predicado de bloqueio 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);

Realize o seguinte para consultar a tabela SalesOrderHeader como cada utilizador. Confirma que SalesPerson280 só vê as 95 linhas das suas próprias vendas e que Manager consegue ver todas as linhas da 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 utilizadores podem aceder a todas as linhas.

ALTER SECURITY POLICY SalesFilter
    WITH (STATE = OFF);

Ativar mascaramento dinâmico de dados

O mascaramento dinâmico de dados permite limitar a exposição de dados sensíveis aos utilizadores de uma aplicação, mascarando total ou parcialmente certas colunas.

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

USE AdventureWorks2022;
GO

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

Crie um novo utilizador TestUser com SELECT permissão na tabela, depois execute uma consulta como TestUser para 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 registo de:

ID de Endereço de Email Endereço de e-mail
1 ken0@adventure-works.com

em

ID de Endereço de Email Endereço de e-mail
1 kXXX@XXXX.com

Ativar encriptação de dados transparentes

Uma ameaça à tua base de dados é o risco de alguém roubar os ficheiros da base de dados do teu disco rígido. Isto pode acontecer com uma intrusão que aumente o acesso ao seu sistema, através das ações de um funcionário problemático, ou pelo roubo do computador que contém os ficheiros (como um portátil).

A encriptação de dados transparente (TDE) encripta os ficheiros de dados à medida que são armazenados no disco rígido. A master base de dados do motor de base de dados SQL Server tem a chave de encriptação, para que o motor de base de dados possa manipular os dados. Os ficheiros da base de dados não podem ser lidos sem acesso à chave. Administradores de alto nível podem gerir, fazer backup e recriar a chave, para que a base de dados possa ser movida, mas apenas por pessoas selecionadas. Quando o TDE é configurado, a tempdb base de dados também é automaticamente encriptada.

Como o Motor de Base de Dados pode ler os dados, o TDE não protege contra acessos não autorizados por administradores do computador que podem ler memória diretamente, ou aceder ao SQL Server através de uma conta de administrador.

Configurar TDE

  • Criar uma chave mestra
  • Criar ou obter um certificado protegido pela chave mestra
  • Crie uma chave de encriptação de base de dados e proteja-a pelo certificado
  • Defina a base de dados para usar encriptação

Configurar o TDE requer CONTROL permissão na master base de dados e CONTROL na base de dados do utilizador. Normalmente, um administrador configura TDE.

O exemplo seguinte ilustra a encriptação e desencriptação da AdventureWorks2025 base de dados usando um certificado instalado no servidor chamado MyServerCert.

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

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

ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION ON;

Para remover TDE, execute o seguinte comando:

ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION OFF;

As operações de criptografia e descriptografia são agendadas em threads em segundo plano pelo SQL Server. Pode consultar o estado destas operações usando as vistas de catálogo e as vistas de gestão dinâmica na lista que aparece mais adiante neste artigo.

Advertência

Os ficheiros de backup das bases de dados que têm o TDE ativado também são encriptados usando a chave de encriptação da base de dados. Como resultado, ao restaurar estas cópias de segurança, o certificado que protege a chave de encriptação da base de dados deve estar disponível. Isto significa que, para além de fazer backup da base de dados, certifique-se de manter cópias de segurança dos certificados do servidor para evitar perda de dados. A perda de dados resultará se o certificado deixar de estar disponível. Para obter mais informações, consulte Certificados do SQL Server e chaves assimétricas.

Para mais informações sobre TDE, consulte Encriptação de dados transparentes (TDE).

Configurar encriptação de backup

O SQL Server tem a capacidade de encriptar os dados enquanto cria uma cópia de segurança. Ao especificar o algoritmo de encriptação e o encriptador (um certificado ou chave assimétrica) ao criar uma cópia de segurança, pode criar um ficheiro de cópia de segurança encriptado.

Advertência

Faça sempre uma cópia de segurança do certificado ou da chave assimétrica, e de preferência para um local diferente do ficheiro de cópia de segurança que foi usado para encriptar. Sem o certificado ou a chave assimétrica, não pode restaurar o backup, tornando o ficheiro de backup inutilizável.

O exemplo seguinte cria um certificado e depois 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 mais informações, consulte Encriptação de backup.

Conteúdo relacionado

  • Last updated on