Настройка видимости метаданных

Применимо к: SQL Server (все поддерживаемые версии) Azure SQL database Управляемый экземпляр SQL Azure Azure Synapse Analytics Analytics Platform System (PDW)

Видимость метаданных ограничивается защищаемыми объектами, которыми пользователь владеет или на которые пользователю предоставлено разрешение. Например, следующий запрос возвращает строку, если пользователю было предоставлено разрешение SELECT или INSERT на таблицу myTable.

SELECT name, object_id  
FROM sys.tables  
WHERE name = N'myTable';  
GO  

Однако если пользователь не имеет никаких разрешений на myTable, запрос возвращает пустой результирующий набор.

Область и влияние настроек видимости метаданных

Настройка видимости метаданных применяется только к следующим защищаемым объектам:

Представления каталога

Метаданные, предоставляющие встроенные функции

представлений совместимости;

Хранимые процедуры компонента Компонент Database Engine sp_help

Представления информационной схемы

Расширенные свойства

Настройка видимости метаданных не применяется к следующим защищаемым объектам:

Системные таблицы доставки журналов

Системные таблицы плана обслуживания базы данных

Системные таблицы репликации

SQL Server Системные таблицы агента

Системные таблицы резервных копий

Репликация и хранимые процедуры SQL Server sp_help агента

Ограниченная возможность доступа к метаданным означает следующее.

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

  • Запросы на системные представления смогут вернуть только подмножество строк или иногда пустой результирующий набор.

  • Встроенные функции, которые формируют метаданные, например OBJECTPROPERTYEX, могут возвращать NULL.

  • Хранимые процедуры sp_help из Компонент Database Engine могут в некоторых случаях возвращать только подмножество строк или значение NULL.

SQL модули, например хранимые процедуры и триггеры, выполняются в контексте безопасности участника и поэтому имеют ограниченный доступ к метаданным. Например, в следующем коде, когда хранимая процедура пытается получить доступ к метаданным для таблицы myTable , на который участник не имеет прав, возвращается пустой результирующий набор. В ранних версиях SQL Serverвозвращается строка.

CREATE PROCEDURE assumes_caller_can_access_metadata  
BEGIN  
SELECT name, object_id   
FROM sys.objects   
WHERE name = N'myTable';  
END;  
GO  

Чтобы позволить участникам просматривать метаданные, можно предоставить им разрешение VIEW DEFINITION в соответствующей области: на уровне объектов, базы данных или сервера. Таким образом, если в предыдущем примере участник имеет разрешение VIEW DEFINITION на таблицу myTable, хранимая процедура возвращает строку. Дополнительные сведения см. в статьях GRANT (Transact-SQL) и GRANT Database Permissions (Transact-SQL) (Transact-SQL).

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

Примечание

В следующем примере использования представление каталога sys.objects применяется вместо представления совместимости sys.sysobjects .

CREATE PROCEDURE does_not_assume_caller_can_access_metadata  
WITH EXECUTE AS OWNER  
AS  
BEGIN  
SELECT name, object_id  
FROM sys.objects   
WHERE name = N'myTable'   
END;  
GO  

Примечание

Можно использовать EXECUTE AS, чтобы временно переключиться на контекст безопасности участника. Дополнительные сведения см. в разделе EXECUTE AS (Transact-SQL).

Преимущества и ограничения настроек видимости метаданных

Настройка видимости метаданных может играть очень важную роль в общем плане безопасности. Однако иногда даже опытный пользователь может форсировать раскрытие некоторых метаданных. Рекомендуется развертывание разрешений метаданных как одной из многих глубоко эшелонированных защит.

Теоретически возможно принудительно вызвать выброс метаданных в сообщениях об ошибках, манипулируя порядком оценки предикатов в запросах. Возможность таких атак методом проб и ошибок относится не только к SQL Server. Это подразумевается ассоциативными и коммуникативными преобразованиями, разрешенными в реляционной алгебре. Можно снизить эту угрозу ограничением объема сведений, возвращаемых в сообщениях об ошибках. Также, чтобы ограничить видимость метаданных таким образом, можно запустить сервер с флагом трассировки 3625. Этот флаг трассировки ограничивает объем сведений, отображаемых в сообщениях об ошибках. В свою очередь, это помогает предотвратить форсированное раскрытие. Компромисс заключается в том, что сообщения об ошибках будут в сжатом виде и могут вызвать сложности при использовании для отладки. Дополнительные сведения см. в разделе "Параметры запуска службы ядра СУБД" и флаги трассировки (Transact-SQL).

Следующие метаданные не подвергаются форсированному раскрытию.

  • Значение, хранимое в столбце provider_string объекта sys.servers. Пользователь, не имеющий разрешения ALTER ANY LINKED SERVER, получит в этом столбце значение NULL.

  • Определение источника пользовательского объекта, например хранимой процедуры или триггера. Код источника видим только в том случае, когда выполняется одно из следующих условий.

    • Пользователь имеет для объекта разрешение VIEW DEFINITION.

    • Пользователю не отказано в разрешении VIEW DEFINITION для объекта, и он имеет для него разрешение CONTROL, ALTER или TAKE OWNERSHIP. Все прочие пользователи получат значение NULL.

  • Столбцы определений, найденные в следующих представлениях каталога:

    • sys.all_sql_modules
    • sys.server_sql_modules
    • sys.default_constraints
    • sys.numbered_procedures
    • sys.sql_modules
    • sys.check_constraints
    • sys.computed_columns
  • Столбец ctext в представлении совместимости syscomments .

  • Выходные данные процедуры sp_helptext .

  • Следующие столбцы в представлениях информационной схемы:

    • INFORMATION_SCHEMA.CHECK_CONSTRAINTS.CHECK_CLAUSE
    • INFORMATION_SCHEMA.DOMAINS.DOMAIN_DEFAULT
    • INFORMATION_SCHEMA.ROUTINES.ROUTINE_DEFINITION
    • INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT
    • INFORMATION_SCHEMA.ROUTINE_COLUMNS.COLUMN_DEFAULT
    • INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION
  • Функция OBJECT_DEFINITION().

  • Значение, хранимое в столбце password_hash объекта sys.sql_logins. Пользователь, не имеющий разрешения CONTROL SERVER, получит в этом столбце значение NULL.

Примечание

Определения SQL встроенных системных процедур и функций видимы для всех пользователей через представление каталога sys.system_sql_modules , хранимую процедуру sp_helptext и функцию OBJECT_DEFINITION().

Примечание

Azure Synapse Analytics не поддерживает системную хранимую процедуру sp_helptext. Вместо нее используйте представление каталога объектов sys.sql_modules.

Общие принципы видимости метаданных

Ниже представлены некоторые общие принципы, относящиеся к видимости метаданных.

  • Неявные разрешения предопределенных ролей.

  • Область разрешений.

  • Приоритет инструкции DENY

  • Видимость метаданных вспомогательных компонентов.

Предопределенные роли и неявные разрешения

Доступ предопределенных ролей к метаданным зависит от соответствующих неявных разрешений.

Область разрешений.

Разрешения на одну область дают возможность видеть метаданные в этой области и на всех включенных областях. Например, разрешение SELECT для схемы предполагает, что его получатель имеет разрешение SELECT для всех защищаемых объектов, содержащихся в этой схеме. Таким образом, когда пользователю предоставлено для схемы разрешение SELECT, он может просматривать ее метаданные, а также все находящиеся в ней таблицы, представления, функции, процедуры, очереди, синонимы, типы и коллекции схем XML. Дополнительные сведения об областях см. в разделе "Иерархия разрешений " (ядро СУБД)".

Примечание

Разрешение UNMASK не влияет на видимость метаданных. При предоставлении только UNMASK никакие метаданные не раскрываются. Разрешение UNMASK будет действовать только совместно с разрешением SELECT. Пример. Если предоставить разрешение UNMASK в области базы данных и разрешение SELECT для отдельной таблицы, то в результате пользователь сможет просматривать только метаданные конкретной таблицы, в которой ему разрешено выполнять SELECT, а метаданные других таблиц доступны не будут.

Приоритет инструкции DENY

DENY обычно имеет приоритет по отношению к другим разрешениям. Например, если пользователю базы данных предоставлено разрешениеEXECUTE для схемы, но отказано в разрешении EXECUTE для хранимой процедуры этой схемы, то он не сможет просматривать метаданные этой хранимой процедуры.

Кроме того, если пользователю отказано в разрешении EXECUTE для схемы, но предоставлено разрешение EXECUTE для хранимой процедуры в этой схеме, то он также не сможет просматривать метаданные для этой хранимой процедуры.

Вот другой пример. Если пользователю и предоставлено, и заблокировано разрешение EXECUTE для хранимой процедуры, что возможно в результате членства в различных ролях, то DENY будет иметь приоритет и пользователь не сможет просматривать метаданные хранимой процедуры.

Видимость метаданных вспомогательных компонентов.

Видимость вспомогательных компонентов, таких как индексы, проверочные ограничения и триггеры, определяется разрешениями на родительский объект. Эти вспомогательные компоненты не имеют предоставляемых разрешений. Например, если пользователю предоставлено какое-то разрешение на таблицу, он может просмотреть метаданные для столбцов таблицы, индексов, проверочных ограничений, триггеров и других подобных вспомогательных компонентов. Еще один пример — предоставление разрешения SELECT только для отдельного столбца заданной таблицы. Это позволит получателю просматривать метаданные всей таблицы, в том числе всех столбцов. Это можно рассматривать так, что разрешение VIEW DEFINITION действует только на уровне сущности (в нашем примере — таблицы) и недоступно для списков вложенных сущностей (например, столбцов или выражений безопасности).

Следующий код демонстрирует такое поведение:

CREATE TABLE t1
(
    c1 int,
    c2 varchar
 );
GO
CREATE USER testUser WITHOUT LOGIN;
GO

EXECUTE AS USER='testUser';
SELECT OBJECT_SCHEMA_NAME(object_id), OBJECT_NAME(object_id), name FROM sys.columns;
SELECT * FROM sys.tables
-- this returns no data, as the user has no permissions
REVERT;
GO

-- granting SELECT on only 1 column of the table:
GRANT SELECT ON t1(c1) TO testUser;
GO
EXECUTE AS USER='testUser';
SELECT OBJECT_SCHEMA_NAME(object_id), OBJECT_NAME(object_id), name FROM sys.columns;
SELECT * FROM sys.tables
-- this returns metadata for all columns of the table and thge table itself
REVERT;
GO

DROP TABLE t1
DROP USER testUser

Метаданные, доступные для всех пользователей базы данных

Некоторые метаданные должны быть доступны для всех пользователей в указанной базе данных. Например, файловые группы не имеют присвоенных разрешений; поэтому пользователю не может быть предоставлено разрешение на просмотр метаданных файловой группы. Однако любой пользователь, который может создать таблицу, должен иметь доступ к метаданным файловой группы, чтобы использовать предложения ON filegroup или TEXTIMAGE_ON filegroup инструкции CREATE TABLE.

Метаданные, возвращаемые функциями DB_ID() и DB_NAME(), видимы всем пользователям.

Это список представлений каталога, видимых для общей роли.

sys.partition_functions

sys.partition_schemes

sys.filegroups

sys.database_files

sys.partitions

sys.schemas

sys.sql_dependencies

sys.parameter_type_usages

sys.partition_range_values

sys.data_spaces

sys.destination_data_spaces

sys.allocation_units

sys.messages

sys.configurations

sys.type_assembly_usages

sys.column_type_usages

См. также:

Инструкция GRANT (Transact-SQL)
DENY (Transact-SQL)
REVOKE (Transact-SQL)
EXECUTE AS, предложение (Transact-SQL)
Представления каталога (Transact-SQL)
Представления совместимости (Transact-SQL)