Compartir a través de

Configuración de visibilidad de los metadatos

  • Artículo

Se aplica a: SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

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 siguiente consulta devuelve una fila si se ha concedido al usuario un permiso como SELECT o INSERT sobre la tabla myTable.

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

Sin embargo, si el usuario no dispone de ningún permiso sobre myTable, la consulta devuelve un conjunto de resultados vacío.

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

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

Vistas de catálogo

Funciones integradas que exponen metadatos

Vistas de compatibilidad

Procedimientos almacenados sp_help en el motor de base de datos

Vistas de esquema de información

Propiedades extendidas

La configuración de visibilidad de los 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 sp_help de replicación y del Agente SQL Server

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 asuman un acceso public a los metadatos se interrumpirán.

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 autores de la llamada vean los metadatos, puede concederles un permiso VIEW DEFINITION o a partir de SQL Server 2022 VIEW SECUIRITY DEFINITION o VIEW PERFORMANCE DEFINITION en un ámbito adecuado: nivel de objeto, base de datos o servidor. Por lo tanto, en el ejemplo anterior, si el autor de la llamada dispone de permiso VIEW DEFINITION sobre myTable, el procedimiento almacenado devuelve una fila. Para más información, vea GRANT (Transact-SQL) y GRANT Database Permissions (Transact-SQL).

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 utilizar EXECUTE AS para cambiar temporalmente al contexto de seguridad del autor de la llamada. Para obtener más información, vea EXECUTE AS (Transact-SQL).

Beneficios y límites de la configuración de visibilidad de los 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.

Teóricamente, es posible forzar la emisión de metadatos en los mensajes de error mediante la manipulación del orden de evaluación de predicados en las consultas. La posibilidad de estos ataques de prueba y error no es específica de SQL Server. Es una implicación de las transformaciones asociativas y conmutativas que admite 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 contrapartida es que los mensajes de error se simplificarán y puede resultar difícil su uso para fines de depuración. Para obtener más información, vea Opciones de inicio del servicio de motor de base de datos y Marcas de seguimiento (Transact-SQL).

Los metadatos que se muestran a continuación no están sujetos a una divulgación forzada:

  • Valor almacenado en la columna provider_string de sys.servers. Un usuario que no disponga de permiso ALTER ANY LINKED SERVER verá un valor NULL 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 una de las siguientes afirmaciones es cierta:

    • El usuario dispone de permiso VIEW DEFINITION sobre el objeto.

    • No se ha denegado al usuario el permiso VIEW DEFINITION sobre el objeto y dispone de permiso CONTROL, ALTER o TAKE OWNERSHIP sobre el objeto. El resto de usuarios verán 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

  • La función OBJECT_DEFINITION()

  • El valor almacenado en la columna password_hash de sys.sql_logins. Un usuario que no tiene CONTROL SERVER o a partir de SQL Server 2022, el permiso VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION verá un valor NULL en esta columna.

Nota:

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

Nota:

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

Principios generales de visibilidad de los 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

  • Prioridad 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 permiso SELECT sobre un esquema implica que el receptor dispone del permiso SELECT sobre todos los elementos protegibles incluidos en dicho esquema. Por tanto, la concesión del permiso SELECT sobre un esquema permite al usuario ver los metadatos del esquema y todas las tablas, vistas, funciones, procedimientos, colas, sinónimos, tipos y colecciones de esquemas XML que estén incluidos en el mismo. Para obtener más información sobre ámbitos, vea Jerarquía de permisos (motor de base de datos).

Nota:

El permiso UNMASK no influye en la visibilidad de los metadatos, ya que si solo se concede UNMASK no se revelará ningún metadato. Para que tenga efecto, UNMASK tendrá que ir acompañado de un permiso SELECT. Por ejemplo, si se concede UNMASK en el ámbito de la base de datos y se concede SELECT en una tabla individual, el usuario solo podrá ver los metadatos de la tabla individual en la que puede realizar una selección, no de otras.

Prioridad de DENY

Normalmente, DENY tiene prioridad sobre otros permisos. Por ejemplo, si se concede a un usuario de la base de datos el permiso EXECUTE sobre un esquema, pero se le deniega el permiso EXECUTE sobre un procedimiento almacenado de dicho esquema, el usuario no podrá ver los metadatos de dicho procedimiento almacenado.

Además, si a un usuario se le deniega el permiso EXECUTE sobre un esquema pero se le concede el permiso EXECUTE sobre un procedimiento almacenado de dicho esquema, el usuario no podrá ver los metadatos de dicho procedimiento almacenado.

Otro ejemplo sería que a un usuario se le concediese y denegase a la vez el permiso EXECUTE sobre un procedimiento almacenado (esto es posible a través de la pertenencia a distintos roles); en este caso, DENY tendría prioridad y el usuario no podría ver los metadatos del procedimiento almacenado.

Visibilidad de los metadatos de subcomponentes

La visibilidad de subcomponentes, como índices, restricciones CHECK y desencadenadores, viene determinada por los permisos del elemento principal. Estos subcomponentes no disponen de permisos que puedan concederse. 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 es conceder SELECT solo en una columna individual de una tabla determinada: esto permitirá al receptor ver los metadatos de la tabla completa, incluidas todas las columnas. Se puede pensar en ello como que el permiso VIEW DEFINITION solo funciona a nivel de entidad (en este caso, la tabla) y que no está disponible para listas de subentradas (como expresiones de columna o 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 thge table itself
REVERT;
GO

DROP TABLE t1
DROP USER testUser

Metadatos a los que pueden obtener acceso 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 disponen de permisos que puedan concederse; por lo tanto, no se puede conceder permiso a un usuario para ver los metadatos de un grupo de archivos. Pero cualquier usuario que pueda crear una tabla deberá poder acceder a los metadatos de un grupo de archivos para usar las cláusulas ON filegroup o TEXTIMAGE_ON filegroup de la instrucción CREATE TABLE.

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

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

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

Consulte también

GRANT (Transact-SQL)
DENY (Transact-SQL)
REVOKE (Transact-SQL)
EXECUTE AS (cláusula de Transact-SQL)
Vistas de catálogo (Transact-SQL)
Vistas de compatibilidad (Transact-SQL)