• Artículo

Configuración de visibilidad de los metadatos

En las versiones anteriores de SQL Server, los metadatos de todos los objetos de una base de datos se encontraban visibles para los miembros de la función public. Esto significa que cualquier usuario que hubiese iniciado una sesión en una instancia de SQL Server puede ver los metadatos de todos los objetos del servidor, incluso los de aquellos objetos sobre los que no tiene ningún derecho.

En SQL Server 2005 y versiones posteriores, la visibilidad de los metadatos se limita a los asegurables 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 = '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 sólo se aplica a los siguientes asegurables:

Vistas de catálogo

Database Engine (Motor de base de datos) Procedimientos almacenados sp_help

Funciones integradas que exponen metadatos

Vistas de esquema de información

Vistas de compatibilidad

Propiedades extendidas

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

Tablas de sistema de trasvase de registros

Tablas de sistema del Agente SQL Server

Tablas de sistema de planes de mantenimiento de bases de datos

Tablas de sistema de copia de seguridad

Tablas de sistema de replicación

Procedimientos almacenados sp_help del Agente SQL Server y de replicación

Una accesibilidad limitada a los metadatos significa lo siguiente:

  • Las aplicaciones que asuman un acceso public a los metadatos se interrumpirán.

  • Las consultas que se realicen en vistas del sistema puede que sólo 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 de Database Engine (Motor de base de datos) pueden devolver únicamente un subconjunto de filas, o NULL.

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, id 
FROM sysobjects 
WHERE name = 'myTable';
END;
GO

Para permitir que los autores de la llamada vean los metadatos, puede concederles un permiso VIEW 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 obtener más información, vea GRANT (Transact-SQL) y GRANT (permisos de base de datos de 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 utiliza 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, id
FROM sys.objects 
WHERE name = '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).

Para obtener más información acerca del encadenamiento de propiedad, vea Cadenas de propiedad.

Beneficios y límites de la configuración de visibilidad de los metadatos

La configuración de visibilidad de los metadatos puede desempeñar una función 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 conseguir una mayor restricción de la visibilidad de los metadatos, puede iniciar el servidor con la marca de traza 3625. Esta marca de traza limita la cantidad de información que aparece 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 Usar las opciones de inicio del servicio SQL Server y Marcadores de seguimiento (Transact-SQL).

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

  • El 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 sólo 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.sql_modules

    sys.server_sql_modules

    sys.check_constraints

    sys.default_constraints

    sys.computed_columns

    sys.numbered_procedures

  • La 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.COLUMNS.COLUMN_DEFAULT

    INFORMATION_SCHEMA.DOMAINS.DOMAIN_DEFAULT

    INFORMATION_SCHEMA.ROUTINE_COLUMNS.COLUMN_DEFAULT

    INFORMATION_SCHEMA.ROUTINES.ROUTINE_DEFINITION

    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 tenga un permiso CONTROL SERVER 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().

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 funciones fijas

  • Ámbito de los permisos

  • Prioridad de DENY

  • Visibilidad de los metadatos de subcomponentes

Funciones fijas y permisos implícitos

Los metadatos a los que pueden obtener acceso las funciones fijas 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 asegurables 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 los ámbitos, vea Jerarquía de permisos (motor de base de datos).

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 distintas funciones); 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.

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. Sin embargo, cualquier usuario que pueda crear una tabla deberá poder obtener acceso a los metadatos de un grupo de archivos para utilizar 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.

En la siguiente tabla se muestran las vistas de catálogo que se encuentran visibles para la función public.

sys.partition_functions

sys.partition_range_values

sys.partition_schemes

sys.data_spaces

sys.filegroups

sys.destination_data_spaces

sys.database_files

sys.allocation_units

sys.partitions

sys.messages

sys.schemas

sys.configurations

sys.sql_dependencies

sys.type_assembly_usages

sys.parameter_type_usages

sys.column_type_usages