Рекомендации по защите автономных баз данных

  • Статья

Применимо к:Управляемому экземпляру SQL Server Azure

Содержащиеся базы данных имеют некоторые уникальные угрозы, которые следует понимать и устранять администраторами ядра СУБД SQL Server. Большинство угроз связаны с процессом проверки подлинности USER WITH PASSWORD , который перемещает границу проверки подлинности с уровня ядра СУБД на уровень базы данных.

Пользователи в автономной базе данных, имеющие разрешение ALTER ANY USER , такие как члены db_owner и db_accessadmin фиксированных ролей базы данных, могут предоставлять доступ к базе данных без знаний или разрешений или администратора SQL Server. Предоставление пользователям доступа к автономной базе данных увеличивает потенциальную область атаки для всего экземпляра SQL Server. Администраторы должны понимать это делегирования контроля доступа и должны быть очень осторожными при предоставлении пользователям в автономной базе данных разрешения ALTER ANY USER . Все владельцы базы данных обладают разрешением ALTER ANY USER . Администраторы SQL Server должны периодически проверять пользователей в автономной базе данных.

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

Владельцы и пользователи базы данных, имеющие разрешение ALTER ANY USER , могут создавать пользователей автономной базы данных. После подключения к автономной базе данных в экземпляре SQL Server пользователь автономной базы данных может получить доступ к другим базам данных в ядре СУБД, если другие базы данных включили гостевую учетную запись.

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

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

USE DB1;  
GO  
CREATE USER Carlo WITH PASSWORD = '<strong password>';   
-- Return the SID of the user  
SELECT SID FROM sys.database_principals WHERE name = 'Carlo';  
  
-- Change to the second database  
USE DB2;  
GO  
CREATE USER Carlo WITH PASSWORD = '<same password>', SID = <SID from DB1>;  
GO

Для выполнения межбазового запроса необходимо установить параметр TRUSTWORTHY в вызывающей базе данных. Например, если определенный выше пользователь (Carlo) находится в базе данных DB1 для выполнения запроса SELECT * FROM db2.dbo.Table1; , то параметр TRUSTWORTHY должен быть включен для базы данных DB1. Чтобы включить параметр TRUSTWORTHY , выполните следующий код:

ALTER DATABASE DB1 SET TRUSTWORTHY ON;

Создание пользователя с повторяющимся именем входа

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

  • Согласно рекомендациям, члены предопределенной роли сервера sysadmin должны всегда рассматривать соединение без использования параметра исходного каталога. Это вызывает подключение имени входа к базе данных master и предотвращает попытки владельца базы данных неправильно использовать попытку входа. Затем администратор может измениться на содержащуюся базу данных с помощью инструкции USE<database.> Можно также установить в качестве базы данных по умолчанию автономную базу данных, которая выполняет вход в базу данных master, а затем переносит вход на автономную базу данных.

  • Рекомендуется не создавать пользователей автономной базы данных с паролями, которые имеют то же имя, что и для входа SQL Server.

  • Если существует дублированное имя входа, выполните подключение к базе данных master без указания исходного каталога, а затем выполните команду USE , чтобы переключиться в автономную базу данных.

  • При наличии автономных баз данных пользователи баз данных, которые не содержатся, должны подключаться к ядру СУБД без использования первоначального каталога или указания имени базы данных, не содержащейся в качестве исходного каталога. Это позволяет избежать подключения к автономной базе данных, которая находится под менее прямым контролем администраторами ядра СУБД.

Увеличение доступа путем изменения состояния включения базы данных

Имена входа, которые имеют разрешение ALTER ANY DATABASE , такие как члены предопределенной роли сервера dbcreator и пользователи неавтономной базы данных, с разрешением CONTROL DATABASE , такие как члены предопределенной роли базы данных db_owner , могут изменять параметр включения базы данных. При изменении параметра включения базы данных с NONE на PARTIAL или FULLпользователю может быть предоставлен доступ путем создания пользователей автономной базы данных с паролями. Это может предоставить доступ без знаний или согласия администраторов SQL Server. Чтобы запретить содержать базы данных, задайте для ядраСУБД параметр проверки подлинности базы данных равным 0. Для предотвращения подключения пользователей автономной базы данных с паролями к выбранным автономным базам данных, используйте триггеры входа для отмены попыток входа пользователей автономной базы данных с паролями.

Присоединение автономной базы данных

При присоединении автономной базы данных администратор может предоставить нежелательным пользователям доступ к экземпляру ядра СУБД. Для предотвращения такого риска администратор может перевести базу данных в состояние "в сети" в режиме RESTRICTED USER , в результате чего пользователи автономной базы данных с паролями не смогут пройти проверку подлинности. Доступ к ядру СУБД сможет получить только субъекты, авторизованные через имена входа.

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

Политики паролей

Можно потребовать, чтобы пароли в базе данных были надежными, но защитить их надежными политиками паролей нельзя. По возможности используйте проверку подлинности Windows, чтобы использовать преимущества более сложных политик паролей, доступных в Windows.

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

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

Атака вне сети перебором по словарю

Хэши паролей для пользователей автономной базы данных с паролями хранятся в автономной базе данных. Любое лицо с доступом к базе данных может выполнить атаку перебором по словарю против пользователей автономной базы данных с паролями в системе без аудита. Чтобы устранить эту угрозу, ограничьте доступ к файлам базы данных или разрешите подключение к автономным базам данных только с использованием проверки подлинности Windows.

Экранирование автономной базы данных

Если база данных частично содержится, администраторы SQL Server должны периодически проверять возможности пользователей и модулей в содержащихся базах данных.

Отказ в обслуживании через параметр AUTO_CLOSE

Не настраивайте автономную базу данных на автоматическое закрытие. Если закрыть базу данных, ее открытие для проверки подлинности пользователя будет связано с потреблением дополнительных ресурсов, что может стать объектом атаки типа «отказ в обслуживании».

См. также

Автономные базы данных
Переход на частично автономную базу данных