Ескертпе
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Жүйеге кіруді немесе каталогтарды өзгертуді байқап көруге болады.
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Каталогтарды өзгертуді байқап көруге болады.
Относится к:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Azure 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_helpSQL 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_modulessys.server_sql_modulessys.default_constraintssys.numbered_proceduressys.sql_modulessys.check_constraintssys.computed_columns
Столбец
ctextвsyscommentsпредставлении совместимости.Выходные данные
sp_helptextпроцедуры.Следующие столбцы в представлениях информационной схемы:
INFORMATION_SCHEMA.CHECK_CONSTRAINTS.CHECK_CLAUSEINFORMATION_SCHEMA.DOMAINS.DOMAIN_DEFAULTINFORMATION_SCHEMA.ROUTINES.ROUTINE_DEFINITIONINFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULTINFORMATION_SCHEMA.ROUTINE_COLUMNS.COLUMN_DEFAULTINFORMATION_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_unitssys.column_type_usagessys.configurationssys.data_spacessys.database_filessys.destination_data_spacessys.filegroupssys.messagessys.parameter_type_usagessys.partition_functionssys.partition_range_valuessys.partition_schemessys.partitionssys.schemassys.sql_dependenciessys.type_assembly_usages