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

В изолированных базах данных существуют некоторые уникальные угрозы, которые должны быть изучены и снижены администраторами СУБД SQL Server. Большинство угроз связаны с 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 пользователь контейнированной базы данных может получить доступ к другим базам данных в СУБД, если в других базах данных включена учетная запись гость.

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

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

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 параметр в вызывающей базе данных. Например, если пользователь (Карло), определенный выше, записан в 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<базы данных>. Можно также установить в качестве базы данных по умолчанию автономную базу данных, которая выполняет вход в базу данных master, а затем переносит вход на автономную базу данных.

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

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

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

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

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

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

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

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

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

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

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

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

Атака по словарю в офлайн-режиме

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

Выход из ограниченной базы данных

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

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

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

См. также

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