Configuración de visibilidad de metadatos

Aplica a:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSistema de Plataforma de Analítica (PDW)Base de datos SQL en Microsoft Fabric

La visibilidad de los metadatos se limita a los elementos protegibles que son propiedad de un usuario o sobre los que el usuario tienen algún permiso.

Por ejemplo, la consulta siguiente devuelve una fila si el usuario concede un permiso como SELECT o INSERT en la tabla myTable.

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

Sin embargo, si el usuario no tiene permiso en myTable, la consulta devuelve un conjunto de resultados vacío.

Ámbito e impacto de la configuración de visibilidad de metadatos

La configuración de visibilidad de metadatos solo se aplica a los siguientes elementos protegibles:

• Vistas de catálogo
• Funciones integradas que exponen metadatos
• Vistas de compatibilidad
• Procedimientos almacenados del motor sp_help de base de datos
• Vistas de esquema de información
• Propiedades extendidas

La configuración de visibilidad de metadatos no se aplica a los siguientes elementos protegibles:

• Tablas de sistema de trasvase de registros
• Tablas de sistema de planes de mantenimiento de bases de datos
• Tablas de sistema de replicación
• Tablas del sistema del Agente SQL Server
• Tablas de sistema de copia de seguridad
• Procedimientos almacenados del Agente sp_help SQL Server y replicación

Una accesibilidad limitada a los metadatos significa lo siguiente:

• Las consultas que se realicen en vistas del sistema puede que solo devuelvan un subconjunto de filas o, en ocasiones, un conjunto de resultados vacío.
• Las funciones integradas que emiten metadatos, como OBJECTPROPERTYEX, pueden devolver NULL.
• Los procedimientos almacenados sp_help en el motor de base de datos pueden devolver únicamente un subconjunto de filas o NULL.
• Como resultado, las aplicaciones que asumen el acceso a metadatos públicos fallan.

Los módulos SQL, como procedimientos almacenados y desencadenadores, se ejecutan en el contexto de seguridad del autor de la llamada y, por tanto, tienen un acceso limitado a los metadatos. Por ejemplo, en el siguiente código, cuando el procedimiento almacenado intenta obtener acceso a los metadatos de la tabla myTable sobre la que el autor de la llamada no tienen ningún derecho, se devuelve un conjunto de resultados vacío. En versiones anteriores de SQL Server se devuelve una fila.

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

Para permitir que los llamantes vean los metadatos, puede otorgarles el permiso VIEW DEFINITION, o en SQL Server 2022 (16.x) y versiones posteriores, el permiso VIEW SECURITY DEFINITION o VIEW PERFORMANCE DEFINITION en el ámbito adecuado: a nivel de objeto, de base de datos o de servidor. Por lo tanto, en el ejemplo anterior, si el autor de la llamada tiene VIEW DEFINITION permiso en myTable, el procedimiento almacenado devuelve una fila. Para obtener más información, consulte GRANT y Permisos de base de datos GRANT.

También puede modificar el procedimiento almacenado para que se ejecute bajo las credenciales del propietario. Cuando el propietario del procedimiento y el propietario de la tabla son el mismo, se aplica el encadenamiento de propiedad, y el contexto de seguridad del propietario del procedimiento permite el acceso a los metadatos de myTable. En un escenario de este tipo, el siguiente código devuelve una fila de metadatos al autor de la llamada.

Nota:

En el siguiente ejemplo se usa la vista de catálogo sys.objects en lugar de la vista de compatibilidad 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

Nota:

Puede usar EXECUTE AS para cambiar temporalmente al contexto de seguridad del autor de la llamada. Para obtener más información, vea EXECUTE AS.

Ventajas y límites de la configuración de visibilidad de metadatos

La configuración de visibilidad de los metadatos puede desempeñar un rol importante en el plan de seguridad global. Sin embargo, hay casos en los que un usuario con conocimientos y determinación puede forzar la divulgación de algunos metadatos. Es recomendable implementar permisos sobre los metadatos como una de las distintas medidas de defensa más completa.

En teoría, es posible forzar la emisión de metadatos en mensajes de error mediante la manipulación del orden de evaluación de predicado en las consultas. La posibilidad de estos ataques de prueba y error no es específico de SQL Server. Está implícito en las transformaciones asociativas y conmutantes permitidas en el álgebra relacional. Puede mitigar este riesgo mediante la limitación de la información que se devuelve en los mensajes de error. Para restringir más la visibilidad de metadatos de esta manera, puede iniciar el servidor con la marca de seguimiento 3625. Esta marca de seguimiento limita la cantidad de información que se muestra en los mensajes de error. A su vez, ayuda a evitar divulgaciones forzadas. La desventaja es que los mensajes de error son tesos y pueden ser difíciles de usar para fines de depuración. Para obtener más información, consulte Opciones de inicio del servicio motor de base de datos y marcas de seguimiento.

Los metadatos siguientes no están sujetos a la divulgación forzada:

• Valor almacenado en la columna provider_string de sys.servers. Un usuario que no tiene ALTER ANY LINKED SERVER permiso ve un NULL valor en esta columna.

• La definición de origen de un objeto especificado por el usuario, como un procedimiento almacenado o desencadenador. El código fuente solo es visible cuando se cumple una de las condiciones siguientes:

  • El usuario tiene VIEW DEFINITION permiso sobre el objeto.

  • No se ha denegado al usuario el permiso VIEW DEFINITION en el objeto y tiene el permiso CONTROL, ALTER o TAKE OWNERSHIP en el objeto. Todos los demás usuarios ven NULL.

• Las columnas de definición de las siguientes vistas de catálogo:

  • sys.all_sql_modules
  • sys.server_sql_modules
  • sys.default_constraints
  • sys.numbered_procedures
  • sys.sql_modules
  • sys.check_constraints
  • sys.computed_columns

• Columna ctext de la vista de compatibilidad syscomments.

• El resultado del procedimiento sp_helptext.

• Las siguientes columnas de las vistas de esquema de información:

  • 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() función

• Valor almacenado en la columna password_hash de sys.sql_logins. Un usuario que no tiene CONTROL SERVER, o en SQL Server 2022 (16.x) y versiones posteriores, los permisos VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION ve un valor NULL en esta columna.

Las definiciones SQL de procedimientos y funciones del sistema integrados son visibles públicamente a través de la vista de sys.system_sql_modules catálogo, el sp_helptext procedimiento almacenado y la OBJECT_DEFINITION() función .

Nota:

El procedimiento sp_helptext almacenado del sistema no se admite en Azure Synapse Analytics. En su lugar, use la vista de catálogo del objeto sys.sql_modules.

Principios generales de visibilidad de metadatos

A continuación, se muestran algunos de los principios generales que hay que tener en cuenta de cara a la visibilidad de los metadatos:

• Permisos implícitos de roles fijos
• Ámbito de los permisos
• Precedencia de DENY
• Visibilidad de los metadatos de subcomponentes

Roles fijos y permisos implícitos

Los metadatos a los que pueden obtener acceso los roles fijos dependen de sus permisos implícitos correspondientes.

Ámbito de los permisos

Los permisos de un ámbito implican la posibilidad de ver los metadatos en dicho ámbito y en todos los ámbitos incluidos en el mismo. Por ejemplo, el SELECT permiso en un esquema implica que el receptor tiene SELECT permiso para todos los elementos protegibles contenidos en ese esquema. La concesión de SELECT permisos en un esquema permite a un usuario ver los metadatos del esquema y también todas las tablas, vistas, funciones, procedimientos, colas, sinónimos, tipos y colecciones de esquemas XML dentro de él. Para obtener más información sobre ámbitos, vea Jerarquía de permisos (motor de base de datos).

Nota:

El UNMASK permiso no influye en la visibilidad de los metadatos: la concesión UNMASK por sí sola no revela ningún metadato. UNMASK siempre debe ir acompañado de un SELECT permiso para tener cualquier efecto. Ejemplo: conceder UNMASK en el ámbito de la base de datos y conceder SELECT en una tabla individual tiene el resultado de que el usuario solo puede ver los metadatos de la tabla individual desde la que puede seleccionar, no en ninguna otra.

Prioridad de DENY

DENY Normalmente tiene prioridad sobre otros permisos. Por ejemplo, si a un usuario de base de datos se le concede EXECUTE permiso en un esquema, pero se le ha denegado EXECUTE permiso en un procedimiento almacenado en ese esquema, el usuario no puede ver los metadatos de ese procedimiento almacenado.

Además, si se deniega EXECUTE el permiso de un usuario en un esquema, pero se le ha concedido EXECUTE permiso en un procedimiento almacenado en ese esquema, el usuario no puede ver los metadatos de ese procedimiento almacenado.

Otro ejemplo sería si se han concedido y denegado EXECUTE permisos a un usuario en un procedimiento almacenado, lo cual es posible a través de las distintas afiliaciones a roles. DENY tiene prioridad, y el usuario no puede ver los metadatos del procedimiento almacenado.

Visibilidad de los metadatos de subcomponentes

La visibilidad de los subcomponentes, como índices, restricciones check y desencadenadores, se determinan mediante permisos en el elemento primario. Estos subcomponentes no tienen permisos concedidos. Por ejemplo, si a un usuario se le concede algún permiso sobre una tabla, el usuario podrá ver los metadatos de las tablas, columnas, índices, restricciones CHECK, desencadenadores y otros subcomponentes de este tipo. Otro ejemplo consiste en conceder SELECT solo una columna individual de una tabla determinada: esto permite al receptor ver los metadatos de toda la tabla, incluidas todas las columnas. Una manera de pensarlo es que el VIEW DEFINITION permiso solo funciona en el nivel de entidad (en este caso, la tabla) y no está disponible para listas de subentidades (como las expresiones de columna y de seguridad).

En el código siguiente se muestra este comportamiento:

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;

Metadatos accesibles para todos los usuarios de la base de datos

Algunos metadatos están disponibles para todos los usuarios de una base de datos específica. Por ejemplo, los grupos de archivos no tienen permisos conferibles; por lo tanto, no se puede conceder permiso a un usuario para ver los metadatos de un grupo de archivos. Sin embargo, cualquier usuario que pueda crear una tabla debe poder acceder a los metadatos de los grupos de archivos para utilizar las cláusulas ON <filegroup> o TEXTIMAGE_ON <filegroup> de la instrucción CREATE TABLE.

Los metadatos devueltos por las DB_ID() funciones y DB_NAME() son visibles para todos los usuarios.

Esta se una lista de las vistas de catálogo que se encuentran visibles para el rol public.

• 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

Contenido relacionado

• BECA (Transact-SQL)
• DENEGAR (Transact-SQL)
• REVOCAR (Transact-SQL)
• EXECUTE AS (cláusula de Transact-SQL)
• Vistas de catálogo del sistema (Transact-SQL)
• Vistas de compatibilidad del sistema (Transact-SQL)