Поделиться через

Пошаговое руководство по функциям обеспечения безопасности в SQL Server на Linux

  • Статья

Область применения: SQL Server — Linux

Если вы являетесь пользователем Linux, который является новым для SQL Server, то в следующих задачах описаны некоторые задачи безопасности. Это не уникальные или характерные для Linux, но это помогает дать вам представление о областях для дальнейшего изучения. В каждом примере приводится ссылка на подробную документацию по соответствующей теме.

Примеры кода Transact-SQL в этой статье используют AdventureWorks2022 базу данных или AdventureWorksDW2022 пример базы данных, которую можно скачать с домашней страницы примеров и проектов сообщества Microsoft SQL Server.

Создание имени входа и пользователя базы данных

Предоставьте другим пользователям доступ к SQL Server, создав имя входа в master базу данных с помощью инструкции CREATE LOGIN . Рассмотрим пример.

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

Примечание.

Всегда используйте надежный пароль вместо звездочек в предыдущей команде.

Имена входа могут подключаться к SQL Server и иметь доступ (с ограниченными разрешениями) к master базе данных. Для подключения к пользовательской базе данных имя входа должно иметь соответствующее удостоверение на уровне базы данных, называемое пользователем базы данных. Пользователи относятся к конкретной базе данных, и их нужно создавать отдельно в каждой базе данных для предоставления им доступа. Следующий пример перемещает вас в AdventureWorks2022 базу данных, а затем использует инструкцию CREATE USER для создания пользователя с именем Larry, связанного с именем Larryвхода. Хотя имя входа и пользователь связаны (сопоставлены друг с другом), это разные объекты. Имя для входа является субъектом серверного уровня. Пользователь является субъектом уровня базы данных.

USE AdventureWorks2022;
GO
CREATE USER Larry;
GO
  • Учетная запись администратора SQL Server может подключаться к любой базе данных и создавать дополнительные имена входа и пользователей в любой базе данных.
  • Когда пользователь создает базу данных, он становится ее владельцем, который может подключаться к этой базе данных. Владельцы базы данных могут создавать дополнительных пользователей.

Позже вы можете авторизовать другие имена входа для создания дополнительных имен входа, предоставив им ALTER ANY LOGIN разрешение. Внутри базы данных вы можете авторизовать других пользователей, чтобы создать дополнительных пользователей, предоставив им разрешение ALTER ANY USER. Например:

GRANT ALTER ANY LOGIN TO Larry;
GO

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

Теперь имя входа Larry может создавать дополнительные имена входа, а пользователь Jerry может создавать больше пользователей.

Предоставление доступа с минимальными привилегиями

Первыми пользователями для подключения к пользовательской базе данных являются учетные записи администратора и владельца базы данных. Однако у этих пользователей есть все разрешения, доступные в базе данных. Это гораздо больше, чем нужно большинству пользователей.

Когда вы только начинаете работу, вы можете назначить некоторые общие категории разрешений с помощью встроенных предопределенных ролей базы данных. Например, роль фиксированной базы данных db_datareader может считывать все таблицы в базе данных, но не вносить никаких изменений. Предоставьте членство в предопределенной роли базы данных с помощью инструкции ALTER ROLE. В следующем примере добавьте пользователя Jerry в роль фиксированной базы данных db_datareader .

USE AdventureWorks2022;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

Список предопределенных ролей базы данных см. в разделе Роли уровня базы данных.

Позже, когда вы будете готовы настроить более точный доступ к данным (настоятельно рекомендуется), создайте собственные определяемые пользователем роли базы данных с помощью инструкции CREATE ROLE . Затем назначьте определенные детализированные разрешения пользовательским ролям.

Например, следующие инструкции создают роль базы данных Sales, предоставляют группе Sales возможность видеть, обновлять и удалять строки из таблицы Orders, а затем добавляют пользователя Jerry в роль 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;

Дополнительные сведения о системе разрешений см. в статье Приступая к работе с разрешениями ядра СУБД.

Настройка безопасности на уровне строк

Безопасность на уровне строк позволяет ограничить доступ к строкам в таблице базы данных в зависимости от характеристик пользователя, выполняющего запрос. Эта функция полезна в таких сценариях, как обеспечение доступа клиентов только к их собственным данным, а также предоставление работникам доступа только к тем данным, которые относятся к их отделу.

Ниже описано, как настроить двух пользователей с разным доступом на уровне строк к таблице Sales.SalesOrderHeader.

Создайте две учетные записи пользователей для тестирования безопасности на уровне строк.

USE AdventureWorks2022;
GO

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

Предоставьте обоим пользователям доступ на чтение к таблице Sales.SalesOrderHeader.

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

Создайте новую схему и встроенную функцию с табличным значением. Функция возвращает 1, если строка в столбце SalesPersonID соответствует идентификатору имени входа SalesPerson или если пользователь, выполняющий запрос, является пользователем Manager.

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');

Создайте политику безопасности, добавив функцию в качестве фильтра и предиката блокировки для таблицы.

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);

Выполните следующую процедуру, чтобы запросить таблицу SalesOrderHeader от имени каждого пользователя. Убедитесь, что SalesPerson280 видит только 95 строк из своих продаж, а Manager может видеть все строки в таблице.

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

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

Измените политику безопасности, чтобы отключить политику. Теперь оба пользователя могут получить доступ ко всем строкам.

ALTER SECURITY POLICY SalesFilter
WITH (STATE = OFF);

Включение динамического маскирования данных

Динамическое маскирование данных позволяет ограничить раскрытие конфиденциальных данных для пользователей приложения путем полной или частичной маскировки определенных столбцов.

Используйте инструкцию ALTER TABLE, чтобы добавить функцию маскирования в столбец EmailAddress таблицы Person.EmailAddress.

USE AdventureWorks2022;
GO

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

Создайте нового пользователя TestUser с разрешением SELECT для таблицы, а затем выполните запрос от имени TestUser для просмотра маскированных данных.

CREATE USER TestUser WITHOUT LOGIN;

GRANT SELECT ON Person.EmailAddress TO TestUser;

EXECUTE AS USER = 'TestUser';

SELECT EmailAddressID, EmailAddress
FROM Person.EmailAddress;

REVERT;

Убедитесь, что функция маскирования меняет адрес электронной почты первой записи с:

EmailAddressID EmailAddress
1 ken0@adventure-works.com

into

EmailAddressID EmailAddress
1 kXXX@XXXX.com

Включение прозрачного шифрования данных

Одной из угроз для базы данных является риск кражи файлов базы данных с жесткого диска. Это может произойти при атаке, предоставляющей повышенные права доступа к вашей системе, в результате действий сотрудника или кражи компьютера, содержащего файлы (например, ноутбука).

Прозрачное шифрование данных (TDE) шифрует файлы данных по мере их хранения на жестком диске. База master данных ядра СУБД SQL Server имеет ключ шифрования, чтобы ядро СУБД могли управлять данными. Файлы базы данных не могут быть прочитаны без доступа к ключу. Администраторы высокого уровня могут управлять этим ключом, выполнять его резервное копирование и повторно создавать его, чтобы базу данных можно было перемещать, но только отдельным пользователям. При настройке TDE база данных tempdb также автоматически шифруется.

Так как ядро СУБД может считывать данные, TDE не защищает от несанкционированного доступа администраторами компьютера, который может напрямую считывать память или получать доступ к SQL Server через учетную запись администратора.

Настройка TDE

  • Создайте главный ключ
  • Создайте или получите сертификат, защищенный главным ключом
  • Создайте ключ шифрования базы данных и защитите его с помощью сертификата
  • Задайте ведение шифрования базы данных

Для настройки TDE требуется CONTROL разрешение на master базу данных и CONTROL разрешение для пользовательской базы данных. Обычно TDE настраивает администратор.

В следующем примере демонстрируется шифрование и дешифрование базы данных AdventureWorks2022 с помощью сертификата с именем 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;

Чтобы удалить TDE, выполните следующую команду:

ALTER DATABASE AdventureWorks2022 SET ENCRYPTION OFF;

Операции шифрования и расшифровки планируются SQL Server в фоновых потоках. Состояние этих операций можно просмотреть с помощью представлений каталога и динамических административных представлений в списке, который отображается далее в этой статье.

Предупреждение

Файлы резервных копий баз данных, в которых включено TDE, также шифруются с помощью ключа шифрования базы данных. Поэтому для восстановления таких резервных копий необходимо иметь сертификат, защищающий ключ шифрования базы данных. Это означает, что помимо резервного копирования базы данных убедитесь, что вы сохраняете резервные копии сертификатов сервера, чтобы предотвратить потерю данных. Если сертификат станет недоступным, это приведет к потере данных. Дополнительные сведения см. в статье SQL Server Certificates and Asymmetric Keys.

Дополнительные сведения о TDE см. в статье Прозрачное шифрование данных (TDE).

Настройка шифрования резервных копий

SQL Server может шифровать данные при создании резервной копии. Указав алгоритм шифрования и шифратор (сертификат или асимметричный ключ) при создании резервной копии, можно создать зашифрованный файл резервной копии.

Предупреждение

Всегда резервное копирование сертификата или асимметричного ключа и предпочтительно в другое расположение, отличное от файла резервной копии, который использовался для шифрования. Без сертификата или асимметричного ключа невозможно восстановить резервную копию, отрисовка файла резервного копирования неиспользуемого.

Следующий пример создает сертификат, а затем создает резервную копию, защищенную этим сертификатом.

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

Дополнительные сведения см. в статье Шифрование резервной копии.

Связанный контент