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

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

  • Статья

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

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

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

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

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

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

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. Чтобы включить параметр TRUSTWORHTY, выполните следующий код:

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 команду для изменения автономной базы данных.

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

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

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

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

При присоединении автономной базы данных администратор может предоставить нежелательным пользователям доступ к экземпляру компонента Компонент Database Engine. Для предотвращения такого риска администратор может перевести базу данных в состояние «в сети» в режиме RESTRICTED_USER, в результате чего пользователи автономной базы данных с паролями не смогут пройти проверку подлинности. Доступ к компоненту Компонент Database Engineсмогут получить только участники, авторизованные через имена входа.

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

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

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

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

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

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

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

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

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

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

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

См. также:

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