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

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

  • Статья

Область применения: SQL Server Управляемый экземпляр SQL 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

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

См. также

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