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


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

Относится к:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure 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
  • Системные таблицы резервных копий
  • Хранимые процедуры репликации и агента sp_help SQL Server

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

  • Запросы на системные представления смогут вернуть только подмножество строк или иногда пустой результирующий набор.
  • Встроенные функции, такие как 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 DEFINITIONVIEW PERFORMANCE DEFINITION уровень базы данных или уровень сервера. Таким образом, в предыдущем примере, если вызывающий объект имеет VIEW DEFINITION разрешение на myTable, хранимая процедура возвращает строку. Дополнительные сведения см. в разделе GRANT и GRANT Database Permissions.

Также можно изменить хранимую процедуру таким образом, что она будет выполняться под учетными данными владельца. Если владелец процедуры и владелец таблицы один и тот же, применяются цепочки владения, и контекст безопасности владельца процедуры открывает доступ к метаданным таблицы 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_stringsys.servers. Пользователь, у которых нет ALTER ANY LINKED SERVER разрешений, видит NULL значение в этом столбце.

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

    • У пользователя есть VIEW DEFINITION разрешение на объект.

    • Пользователь не был отклонен VIEW DEFINITION разрешением на объект и имеет CONTROLALTERили 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_hashsys.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 имеет приоритет, а пользователь не может просматривать метаданные хранимой процедуры.

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

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