Configuración de visibilidad de metadatos

La visibilidad de los metadatos se limita a elementos protegibles que un usuario posee o en el que se ha concedido algún permiso al usuario. Por ejemplo, la consulta siguiente devuelve una fila si al usuario se le ha concedido un permiso como SELECT o INSERT en la tabla myTable.

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

Sin embargo, si el usuario no tiene ningún 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.

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

La accesibilidad de metadatos limitada significa lo siguiente:

• Las aplicaciones que asumen acceso público a los metadatos fallarán.

• Las consultas en vistas del sistema solo pueden devolver un subconjunto de filas o, a veces, un conjunto de resultados vacío.

• Las funciones integradas que emiten metadatos, como OBJECTPROPERTYEX, pueden devolver NULL.

• El motor de bases de datos podría hacer que los procedimientos almacenados, como sp_help, devuelvan solo 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 lo tanto, tienen una accesibilidad de metadatos limitada. Por ejemplo, en el código siguiente, cuando el procedimiento almacenado intenta acceder a los metadatos de la tabla myTable en la que el autor de la llamada no tiene derechos, 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 llamadores vean los metadatos, puede concederles permisos de VIEW DEFINITION en un ámbito adecuado: nivel de objeto, nivel de base de datos o nivel de servidor. Por lo tanto, en el ejemplo anterior, si el autor de la llamada tiene el permiso VIEW DEFINITION en myTable, el procedimiento almacenado devuelve una fila. Para obtener 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 en las credenciales del propietario. Cuando el propietario del procedimiento y el propietario de la tabla son el mismo propietario, se aplica el encadenamiento de propiedad y el contexto de seguridad del propietario del procedimiento permite el acceso a los metadatos de myTable. En este escenario, el código siguiente devuelve una fila de metadatos al autor de la llamada.

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  

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

La configuración de visibilidad de metadatos puede desempeñar un papel importante en el plan de seguridad general. Sin embargo, hay casos en los que un usuario cualificado y determinado puede forzar la divulgación de algunos metadatos. Se recomienda implementar permisos de metadatos como una de muchas defensas en profundidad.

En teoría, es posible forzar la emisión de metadatos en los mensajes de error manipulando el 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 limitando la información devuelta en los mensajes de error. Para restringir aún más la visibilidad de los 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, esto ayuda a evitar divulgaciones forzadas. El inconveniente es que los mensajes de error serán 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 del motor de base de datos y indicadores de seguimiento (Transact-SQL).

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 tenga el permiso ALTER ANY LINKED SERVER verá un valor NULL en esta columna.

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

  • El usuario tiene el permiso "VIEW DEFINITION" en el objeto.

  • El usuario no ha sido denegado el permiso de VER DEFINICIÓN en el objeto y tiene los permisos de CONTROL, ALTER o TOMAR PROPIEDAD en el objeto. Todos los demás usuarios verán NULL.

• Las columnas de definición encontradas en 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

• Columna ctext de la vista de compatibilidad syscomments .

• Salida del procedimiento sp_helptext .

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

  INFORMATION_SCHEMA. CHECK_CONSTRAINTS. CHECK_CLAUSE	INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT
  INFORMATION_SCHEMA. DOMINIOS. DOMAIN_DEFAULT	INFORMATION_SCHEMA.ROUTINE_COLUMNS.COLUMN_DEFAULT
  INFORMATION_SCHEMA.RUTINAS.DEFINICIÓN_DE_RUTINA	INFORMATION_SCHEMA.VISTA.DEFINICIÓN_DE_VISTA

• función OBJECT_DEFINITION()

• Valor almacenado en la columna password_hash de sys.sql_logins. Un usuario que no tenga permiso CONTROL SERVER verá un valor NULL en esta columna.

Principios generales de visibilidad de metadatos

A continuación se muestran algunos principios generales que se deben tener en cuenta con respecto a la visibilidad de los metadatos:

• Permisos implícitos de roles fijos

• Ámbito de permisos

• Precedencia de DENY

• Visibilidad de metadatos de subcomponentes

Roles fijos y permisos implícitos

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

Ámbito de permisos

Los permisos en un ámbito implican la capacidad de ver metadatos en ese ámbito y en todos los ámbitos incluidos. Por ejemplo, el permiso de SELECT en un esquema implica que el beneficiario tiene el permiso de SELECT en todos los securables que contiene ese esquema. La concesión del permiso SELECT 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 los ámbitos, vea Jerarquía de permisos (motor de base de datos) .

Precedencia de DENY

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

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

Otro ejemplo, si se ha concedido y denegado el permiso EXECUTE a un usuario en un procedimiento almacenado, lo cual es posible debido a sus distintas pertenencias a roles, DENY tiene prioridad y el usuario no puede ver los metadatos del procedimiento almacenado.

Visibilidad de metadatos de subcomponentes

La visibilidad de los subcomponentes, como índices, restricciones de verificación y desencadenadores, viene determinada por los permisos en el elemento primario. Estos subcomponentes no tienen permisos concedidos. Por ejemplo, si a un usuario se le ha concedido algún permiso en una tabla, el usuario puede ver los metadatos de las tablas, columnas, índices, restricciones check, desencadenadores y otros subcomponentes de este tipo.

Metadatos accesibles para todos los usuarios de la base de datos

Algunos metadatos deben ser accesibles 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 del 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() son visibles para todos los usuarios.

En la tabla siguiente se enumeran las vistas de catálogo que son visibles para el rol público .

Véase 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)