Безопасность выделенного пула SQL (ранее — Хранилище данных SQL) в Azure Synapse Analytics

• Общие сведения о безопасности для служб R SQL Server
• Проверка подлинности
• Шифрование (портал)
• Шифрование (T-SQL)

Эта статья поможет вам ознакомиться с основами защиты выделенного пула SQL (ранее — Хранилище данных SQL). В частности, эта статья поможет приступить к работе с ресурсами для ограничения доступа, защиты данных и мониторинга действий с помощью выделенного пула SQL (ранее — хранилища SQL DW).

Безопасность подключения

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

Правила брандмауэра используются как логическим сервером SQL, так и базой данных для отклонения попыток подключиться с IP-адресов, которые не были утверждены прямо. Чтобы разрешить подключение из своего приложения или с клиентского компьютера с общедоступным IP-адресом, сначала необходимо создать правило брандмауэра уровня сервера. Для этого воспользуйтесь порталом Azure, REST API или PowerShell.

В брандмауэре сервера рекомендуется максимально ограничить диапазоны разрешенных IP-адресов для уровня сервера. Для доступа к выделенному пулу SQL (ранее — Хранилище данных SQL) с локального компьютера, убедитесь, что брандмауэр в сети и локальный компьютер разрешают исходящие подключения через TCP-порт 1433.

Выделенный пул SQL (ранее — Хранилище данных SQL) использует правила брандмауэра для IP-адресов на уровне сервера. Правила брандмауэра для IP-адресов на уровне базы данных не поддерживаются. Дополнительные сведения см. в разделе База данных SQL Azure правила брандмауэра

Подключения к выделенному пулу SQL (ранее — Хранилище данных SQL) шифруются по умолчанию. Изменение параметров подключения для отключения шифрования игнорируется.

Проверка подлинности

В процессе аутентификации предлагается подтвердить личность пользователя при подключении к базе данных. Выделенный пул SQL (ранее — хранилище данных SQL) в настоящее время поддерживает проверку подлинности SQL Server с именем пользователя и паролем, а также идентификатором Microsoft Entra.

При создании сервера для базы данных вы указали имя пользователя и пароль для учетной записи "Администратор сервера". Используя эти учетные данные, можно выполнить проверку подлинности SQL Server для любой базы данных на этом сервере в качестве владельца базы данных (или dbo).

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

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

-- Connect to master database and create a login
CREATE LOGIN ApplicationLogin WITH PASSWORD = 'Str0ng_password';
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Затем подключитесь к выделенному пулу SQL (ранее — Хранилище данных SQL) с именем для входа администратора сервера и создайте пользователя базы данных для только что созданного имени для входа на сервер.

-- Connect to the database and create a database user
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Чтобы предоставить пользователю разрешение для выполнения дополнительных операций, таких как создание имен для входа или баз данных, назначьте ему роли Loginmanager и dbmanager в базе данных master.

Дополнительные сведения об этих дополнительных ролях и аутентификации в базе данных SQL см. в статье Проверка подлинности и авторизация в Базе данных SQL Azure: предоставление доступа. Дополнительные сведения о подключении с помощью идентификатора Microsoft Entra см. в Подключение использовании проверки подлинности Microsoft Entra.

Авторизация

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

EXEC sp_addrolemember 'db_datareader', 'ApplicationUser'; -- allows ApplicationUser to read data
EXEC sp_addrolemember 'db_datawriter', 'ApplicationUser'; -- allows ApplicationUser to write data

Учетной записи администратора сервера, которая используется для подключения, присвоена роль db_owner, обладатель которой может выполнять любые действия в базе данных. Сохраните эту учетную запись для развертывания обновлений схемы и выполнения других действий по управлению. Для подключения к базе данных из приложения с использованием наименьших привилегий, необходимых приложению, используйте учетную запись "ApplicationUser" с более ограниченными разрешениями.

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

• Детальная настройка разрешений позволяет указать операции, которые можно выполнять с отдельными столбцами, таблицами, представлениями, схемами, процедурами и другими объектами в базе данных. Используйте детализированные разрешения для обеспечения наивысшего уровня контроля и предоставления минимальных необходимых разрешений.
• Чтобы создать учетные записи пользователей приложения с более широкими правами или учетные записи управления с меньшим набором разрешений, можно использовать роли базы данных, отличные от db_datareader и db_datawriter. С помощью встроенных фиксированных ролей базы данных можно легко присваивать разрешения, однако это может привести к предоставлению лишних разрешений.
• Чтобы ограничить действия, выполняемые в базе данных, можно использовать хранимые процедуры.

В следующем примере предоставляется доступ для чтения к определяемой пользователем схеме.

--CREATE SCHEMA Test
GRANT SELECT ON SCHEMA::Test to ApplicationUser

Управление базами данных и серверами из портала Azure или использование API Azure Resource Manager регулируется назначением ролей учетной записи пользователя портала. Дополнительные сведения см. в разделе Назначение ролей Azure с помощью портала Azure.

Шифрование

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

В базе данных SQL ключ шифрования базы данных защищается встроенным сертификатом сервера. Для каждого сервера Azure используется уникальный встроенный сертификат. Майкрософт автоматически меняет эти сертификаты каждые 90 дней. Для этого используется алгоритм шифрования AES-256. Общее описание функции TDE см. в статье Прозрачное шифрование данных (TDE).

Базу данных можно зашифровать с помощью портала Azure или T-SQL.

Следующие шаги

Дополнительные сведения и примеры подключения к хранилищу с различными протоколами см. в разделе Подключение к выделенному пулу SQL (ранее — Хранилище данных SQL).