Настройка видимости метаданных
В ранних версиях SQL Server метаданные для всех объектов в базе данных были видны для членов общей роли. Это значит, что любой пользователь, зарегистрировавшейся на экземпляре SQL Server, мог просмотреть метаданные для каждого объекта на сервере, даже для тех, на которые пользователь не имеет прав.
В SQL Server 2005 и более поздних версиях видимость метаданных ограничивается защищаемыми объектами, которыми пользователь владеет или на которые пользователю были предоставлены разрешения. Например, следующий запрос возвращает строку, если пользователю было предоставлено разрешение SELECT или INSERT на таблицу myTable.
SELECT name, object_idFROM sys.tablesWHERE name = 'myTable';GO
Однако если пользователь не имеет никаких разрешений на myTable, запрос возвращает пустой результирующий набор.
Область и влияние настроек видимости метаданных
Настройка видимости метаданных применяется только к следующим защищаемым объектам:
Представления каталога |
Database Engine Хранимые процедуры sp_help |
Метаданные, предоставляющие встроенные функции |
Представления информационной схемы |
Представления совместимости |
Расширенные свойства |
Настройка видимости метаданных не применяется к следующим защищаемым объектам:
Системные таблицы доставки журналов |
Системные таблицы агента SQL Server |
Системные таблицы плана обслуживания базы данных |
Системные таблицы резервных копий |
Системные таблицы репликации |
Хранимые процедуры репликации и хранимую процедуру sp_help агента SQL Server |
Ограниченная возможность доступа к метаданным означает следующее.
Приложения, предполагающие общий доступ к метаданным, разорвутся.
Запросы на системные представления смогут вернуть только подмножество строк или иногда пустой результирующий набор.
Встроенные функции по формированию метаданных, например OBJECTPROPERTYEX, могут вернуть значение NULL.
Хранимые процедуры sp_help компонента Database Engine смогут вернуть только подмножество строк или значение NULL.
SQL модули, например хранимые процедуры и триггеры, выполняются в контексте безопасности участника и поэтому имеют ограниченный доступ к метаданным. Например, в следующем коде, когда хранимая процедура пытается получить доступ к метаданным для таблицы myTable, на который участник не имеет прав, возвращается пустой результирующий набор. В ранних версиях SQL Server возвращается строка.
CREATE PROCEDURE assumes_caller_can_access_metadataBEGINSELECT name, id FROM sysobjects WHERE name = 'myTable';END;GO
Чтобы позволить участникам просмотреть метаданные, можно предоставить им разрешение VIEW DEFINITION на соответствующую область: уровень объекта, уровень базы данных или уровень сервера. Таким образом, если в предыдущем примере участник имеет разрешение VIEW DEFINITION на таблицу myTable, хранимая процедура возвращает строку. Дополнительные сведения см. в разделах Инструкция GRANT (Transact-SQL) и GRANT, предоставление разрешений на базу данных (Transact-SQL).
Также можно изменить хранимую процедуру таким образом, что она будет выполняться под учетными данными владельца. Если владелец процедуры и владелец таблицы один и тот же, применяются цепочки владения, и контекст безопасности владельца процедуры открывает доступ к метаданным таблицы myTable. Под таким сценарием следующий код возвращает строку метаданных участнику.
.gif "Примечание") Примечание |
|---|
Следующий пример использует представление каталога sys.objects вместо представления совместимости sys.sysobjects. |
CREATE PROCEDURE does_not_assume_caller_can_access_metadataWITH EXECUTE AS OWNERASBEGINSELECT name, idFROM sys.objects WHERE name = 'myTable' END;GO
| Примечание |
|---|
Можно использовать EXECUTE AS, чтобы временно переключиться на контекст безопасности участника. Дополнительные сведения см. в разделе EXECUTE AS (Transact-SQL). |
Дополнительные сведения о цепочках владения см. в разделе Цепочки владения.
Преимущества и ограничения настроек видимости метаданных
Настройка видимости метаданных может играть очень важную роль в общем плане безопасности. Однако иногда даже опытный пользователь может форсировать раскрытие некоторых метаданных. Рекомендуется развертывание разрешений метаданных как одной из многих глубоко эшелонированных защит.
Теоретически возможно принудительно вызвать выброс метаданных в сообщениях об ошибках, манипулируя порядком оценки предикатов в запросах. Возможность таких атак методом проб и ошибок относится не только к SQL Server. Это подразумевается ассоциативными и коммуникативными преобразованиями, разрешенными в реляционной алгебре. Можно снизить эту угрозу ограничением объема сведений, возвращаемых в сообщениях об ошибках. Также, чтобы ограничить видимость метаданных таким образом, можно запустить сервер с флагом трассировки 3625. Этот флаг трассировки ограничивает объем сведений, отображаемых в сообщениях об ошибках. В свою очередь, это помогает предотвратить форсированное раскрытие. Компромисс заключается в том, что сообщения об ошибках будут в сжатом виде и могут вызвать сложности при использовании для отладки. Дополнительные сведения см. в разделах Использование параметров запуска службы SQL Server и Флаги трассировки (Transact-SQL).
Следующие метаданные не подвергаются форсированному раскрытию.
Значение, хранимое в столбце provider_stringsys.servers. Пользователь, не имеющий разрешения ALTER ANY LINKED SERVER, в данном столбце получит значение NULL.
Определение источника пользовательского объекта, например хранимой процедуры или триггера. Код источника видим только в том случае, когда выполняется одно из следующих условий.
Пользователь имеет разрешение VIEW DEFINITION на объект.
Пользователю не было запрещено получение разрешения VIEW DEFINITION на объект и он имеет разрешения CONTROL, ALTER или TAKE OWNERSHIP. Все остальные пользователи получат значение NULL.
Столбцы определений, найденные в следующих представлениях каталога:
sys.all_sql_modules
sys.sql_modules
sys.server_sql_modules
sys.check_constraints
sys.default_constraints
sys.computed_columns
sys.numbered_procedures
Столбец ctext в представлении совместимости syscomments.
Выход процедуры sp_helptext.
Следующие столбцы в представлениях информационной схемы:
INFORMATION_SCHEMA.CHECK_CONSTRAINTS.CHECK_CLAUSE
INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT
INFORMATION_SCHEMA.DOMAINS.DOMAIN_DEFAULT
INFORMATION_SCHEMA.ROUTINE_COLUMNS.COLUMN_DEFAULT
INFORMATION_SCHEMA.ROUTINES.ROUTINE_DEFINITION
INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION
Функция OBJECT_DEFINITION().
Значение, хранимое в столбце password_hash представления sys.sql_logins. Пользователь, не имеющий разрешения CONTROL SERVER, в данном столбце получит значение NULL.
| Примечание |
|---|
Определения SQL встроенных системных процедур и функций видимы для всех пользователей через представление каталога sys.system_sql_modules, хранимую процедуру sp_helptext и функцию OBJECT_DEFINITION(). |
Общие принципы видимости метаданных
Ниже представлены некоторые общие принципы, относящиеся к видимости метаданных.
Неявные разрешения предопределенных ролей.
Область разрешений.
Приоритет инструкции DENY.
Видимость метаданных вспомогательных компонентов.
Предопределенные роли и неявные разрешения
Доступ предопределенных ролей к метаданным зависит от соответствующих неявных разрешений.
Область разрешений
Разрешения на одну область дают возможность видеть метаданные в этой области и на всех включенных областях. Например, разрешение SELECT на схему предполагает, что получатель разрешения имеет разрешение SELECT на все защищаемые объекты, содержащиеся в этой схеме. Таким образом, предоставление разрешения SELECT на схему позволяет пользователю видеть метаданные схемы, а также все находящиеся в ней таблицы, представления, функции, процедуры, очереди, синонимы, типы и коллекции XML-схем. Дополнительные сведения об областях см. в разделе Иерархия разрешений (компонент Database Engine).
Приоритет инструкции DENY
Инструкция DENY обычно является приоритетной по отношению к другим разрешениям. Например, если пользователю базы данных на схему было предоставлено разрешение EXECUTE, но это разрешение было запрещено на хранимую процедуру схемы, он не сможет просмотреть метаданные для этой хранимой процедуры.
К тому же, если пользователю было запрещено разрешение EXECUTE на схему, но была предоставлена инструкция EXECUTE на хранимую процедуру данной схемы, он также не сможет просмотреть метаданные для этой хранимой процедуры.
Другой пример: если пользователю разрешение EXECUTE на хранимую процедуру было и предоставлено, и запрещено, что возможно благодаря членству в различных ролях, то преимущество имеет инструкция DENY, и пользователь не сможет просмотреть метаданные хранимой процедуры.
Видимость метаданных вспомогательных компонентов
Видимость вспомогательных компонентов, таких как индексы, проверочные ограничения и триггеры, определяется разрешениями на родительский объект. Эти вспомогательные компоненты не имеют предоставляемых разрешений. Например, если пользователю предоставлено какое-то разрешение на таблицу, он может просмотреть метаданные для столбцов таблицы, индексов, проверочных ограничений, триггеров и других подобных вспомогательных компонентов.
Метаданные, доступные для всех пользователей базы данных
Некоторые метаданные должны быть доступны для всех пользователей в указанной базе данных. Например, файловые группы не имеют присвоенных разрешений; поэтому пользователю не может быть предоставлено разрешение на просмотр метаданных файловой группы. Однако любой пользователь, который может создать таблицу, должен иметь доступ к метаданным файловой группы, чтобы использовать предложения ON filegroup или TEXTIMAGE_ON filegroup инструкции CREATE TABLE.
Метаданные, возвращаемые функциями DB_ID() и DB_NAME(), видимы всем пользователям.
В следующей таблице приведены представления каталога, видимые для общей роли.
sys.partition_functions |
sys.partition_range_values |
sys.partition_schemes |
sys.data_spaces |
sys.filegroups |
sys.destination_data_spaces |
sys.database_files |
sys.allocation_units |
sys.partitions |
sys.messages |
sys.schemas |
sys.configurations |
sys.sql_dependencies |
sys.type_assembly_usages |
sys.parameter_type_usages |
sys.column_type_usages |
См. также