Конфигурация видимости метаданных

Относится к:SQL ServerБаза данных SQL AzureУправляемый экземпляр SQL AzureAzure Synapse AnalyticsСистема платформы аналитики (PDW)База данных SQL в Microsoft Fabric

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

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

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

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

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

Конфигурация видимости метаданных применяется только к следующим защищаемым компонентам:

  • Представления каталога
  • Метаданные, предоставляющие встроенные функции
  • Представления совместимости
  • Компонент ядро СУБД sp_help: хранимые процедуры
  • Представления информационной схемы
  • Расширенные свойства

Конфигурация видимости метаданных не применяется к следующим защищаемым компонентам:

  • Системные таблицы доставки журналов
  • Системные таблицы плана обслуживания базы данных
  • Системные таблицы репликации
  • системные таблицы агента SQL Server
  • Системные таблицы резервных копий
  • Репликация и агент SQL Server sp_help хранимые процедуры

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

  • Запросы на системные представления смогут вернуть только подмножество строк или иногда пустой результирующий набор.
  • Встроенные функции, возвращающие метаданные, такие как OBJECTPROPERTYEX, могут возвращать NULL.
  • Хранимые процедуры ядра СУБД sp_help могут возвращать только подмножество строк или 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 или, в SQL Server 2022 (16.x) и более поздних версиях, либо VIEW SECURITY DEFINITION, либо VIEW PERFORMANCE DEFINITION в соответствующей области: на уровне объекта, базы данных или сервера. Таким образом, в предыдущем примере, если вызывающий объект имеет VIEW DEFINITION разрешение на myTable, хранимая процедура возвращает строку. Дополнительные сведения см. в разделе GRANT " GRANT Разрешения базы данных".

Также можно изменить хранимую процедуру таким образом, что она будет выполняться под учетными данными владельца. Если владелец процедуры и владелец таблицы один и тот же, применяются цепочки владения, и контекст безопасности владельца процедуры открывает доступ к метаданным таблицы 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.

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

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

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

Следующие метаданные не подлежат принудительному раскрытию.

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

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

    • У пользователя есть 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 или, в SQL Server 2022 (16.x) и более поздних версиях, разрешения VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION, видит в этом столбце значение NULL.

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

Примечание.

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

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

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

  • Неявные разрешения фиксированных ролей
  • Область разрешений.
  • Приоритет DENY
  • Видимость метаданных вспомогательных компонентов.

Фиксированные роли и неявные разрешения

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

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

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

Примечание.

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

Приоритет DENY

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

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

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

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

Видимость подкомпонентов, таких как индексы, ограничения CHECK и триггеры, определяется разрешениями для родительского объекта. Эти подкомпоненты не имеют назначаемых разрешений. Например, если пользователю предоставлено какое-то разрешение на таблицу, он может просмотреть метаданные для столбцов таблицы, индексов, проверочных ограничений, триггеров и других подобных вспомогательных компонентов. Другим примером является предоставление 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 the table itself
;

REVERT;
GO

DROP TABLE t1;
DROP USER testUser;

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

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

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

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

  • sys.allocation_units
  • sys.column_type_usages
  • sys.configurations
  • sys.data_spaces
  • sys.database_files
  • sys.destination_data_spaces
  • sys.filegroups
  • sys.messages
  • sys.parameter_type_usages
  • sys.partition_functions
  • sys.partition_range_values
  • sys.partition_schemes
  • sys.partitions
  • sys.schemas
  • sys.sql_dependencies
  • sys.type_assembly_usages