Рекомендации по обеспечению безопасности автономных баз данных
С автономными базами данных связаны некоторые уникальные угрозы, о которых администраторы Компонент SQL Server Database Engine должны знать (и принимать меры по их устранению). Большая часть угроз связана с процессом проверки подлинности USER WITH PASSWORD, который перемещает границу проверки подлинности с уровня компонента Компонент Database Engine на уровень базы данных.
Угрозы, связанные с пользователями
Пользователям автономной базы данных, имеющим разрешение 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
Не настраивайте автономную базу данных на автоматическое закрытие. Если закрыть базу данных, ее открытие для проверки подлинности пользователя будет связано с потреблением дополнительных ресурсов, что может стать объектом атаки типа «отказ в обслуживании».