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

Применимо к:SQL Server в Linux

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

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

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

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

Caution

Пароль должен соответствовать политике паролей по умолчанию SQL Server. По умолчанию пароль должен быть не короче восьми символов и содержать три вида символов из следующих: прописные буквы, строчные буквы, десятичные цифры, специальные символы. Пароли могут иметь длину до 128 символов. Рекомендуется использовать максимально длинные и сложные пароли.

Учетные записи для входа могут подключаться к SQL Server и получать доступ к базе данных master (с ограниченными разрешениями). Чтобы подключиться к базе данных пользователя, учётная запись входа должна иметь соответствующего пользователя на уровне базы данных, который называется пользователем базы данных. Пользователи специфичны для каждой базы данных, поэтому для предоставления доступа нужно создавать их отдельно.

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

USE AdventureWorks2025;
GO

CREATE USER Larry;
GO

Учетная запись администратора SQL Server может подключаться к любой базе данных и создавать дополнительные имена входа и пользователей в любой базе данных.
Когда вы создаёте базу данных, вы становитесь владельцем базы данных и можете подключиться к ней. Владельцы базы данных могут создавать дополнительных пользователей.

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

GRANT ALTER ANY LOGIN TO Larry;
GO

USE AdventureWorks2025;
GO

GRANT ALTER ANY USER TO Jerry;
GO

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

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

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

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

USE AdventureWorks2025;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

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

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

Например, следующие операторы создают роль базы данных с названием Sales, предоставляя Sales группе возможность читать, обновлять и удалять строки из Orders таблицы, а затем добавлять пользователя Jerry в эту Sales роль.

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;

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

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

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

Следующие шаги проходят через настройку двух пользователей с разным доступом к Sales.SalesOrderHeader таблице на уровне строк.

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

USE AdventureWorks2025;
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 столбце совпадает с ID входа SalesPerson или когда пользователь, выполняющий запрос, является пользователем 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')

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

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 AdventureWorks2025;
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	Адрес электронной почты
1	`ken0@adventure-works.com`

EmailAddressID	Адрес электронной почты
1	`kXXX@XXXX.com`

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

Злоумышленник может украсть файлы базы данных с вашего жёсткого диска. Это может произойти, если злоумышленник получает повышенный доступ к системе, если сотрудник забирает файлы или кто-то крадёт компьютер, в котором хранятся файлы.

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

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

Настройка TDE

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

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

Следующий пример иллюстрирует шифрование и расшифровку AdventureWorks2025 базы данных с установленным на сервере сертификатом.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 AdventureWorks2025;
GO

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

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION ON;

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

ALTER DATABASE AdventureWorks2025
    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 [AdventureWorks2025]
TO DISK = N'/var/opt/mssql/backups/AdventureWorks2025.bak'
WITH COMPRESSION,
    ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupEncryptCert),
    STATS = 10;
GO

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

Безопасность системы управления базами данных SQL Server и базы данных Azure SQL

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-08-14