Configuration de la visibilité des métadonnées

La visibilité des métadonnées est limitée aux éléments sécurisables qu’un utilisateur possède ou sur lequel l’utilisateur a reçu une autorisation. Par exemple, la requête suivante retourne une ligne si l’utilisateur a reçu une autorisation telle que SELECT ou INSERT sur la table myTable.

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

Toutefois, si l’utilisateur n’a aucune autorisation sur myTable, la requête retourne un jeu de résultats vide.

Étendue et impact de la configuration de la visibilité des métadonnées

La configuration de visibilité des métadonnées s’applique uniquement aux éléments sécurisables suivants.

La configuration de visibilité des métadonnées ne s’applique pas aux éléments sécurisables suivants.

L’accessibilité limitée des métadonnées signifie ce qui suit :

• Les applications qui présument l'accès aux métadonnées publiques échoueront.

• Les requêtes sur les vues système peuvent uniquement retourner un sous-ensemble de lignes, ou parfois un jeu de résultats vide.

• Les fonctions intégrées émettrices de métadonnées telles que OBJECTPROPERTYEX peuvent retourner NULL.

• Le moteur de base de données peut faire en sorte que la procédure stockée sp_help retourne uniquement un sous-ensemble de lignes ou NULL.

Les modules SQL, tels que les procédures stockées et les déclencheurs, s’exécutent sous le contexte de sécurité de l’appelant et, par conséquent, ont une accessibilité limitée des métadonnées. Par exemple, dans le code suivant, lorsque la procédure stockée tente d’accéder aux métadonnées de la table myTable sur laquelle l’appelant n’a aucun droit, un jeu de résultats vide est retourné. Dans les versions antérieures de SQL Server, une ligne est retournée.

CREATE PROCEDURE assumes_caller_can_access_metadata  
BEGIN  
SELECT name, id   
FROM sysobjects   
WHERE name = 'myTable';  
END;  
GO  

Pour permettre aux appelants d’afficher les métadonnées, vous pouvez accorder aux appelants l’autorisation VIEW DEFINITION dans une étendue appropriée : niveau objet, niveau base de données ou niveau serveur. Par conséquent, dans l’exemple précédent, si l’appelant dispose de l’autorisation VIEW DEFINITION sur myTable, la procédure stockée retourne une ligne. Pour plus d’informations, consultez GRANT (Transact-SQL) et GRANT Database Permissions (Transact-SQL).

Vous pouvez également modifier la procédure stockée afin qu’elle s’exécute sous les informations d’identification du propriétaire. Lorsque le propriétaire de la procédure et le propriétaire de la table sont le même propriétaire, le chaînage de propriétés s’applique et le contexte de sécurité du propriétaire de la procédure permet d’accéder aux métadonnées pour myTable. Dans ce scénario, le code suivant retourne une ligne de métadonnées à l’appelant.

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  

Avantages et limites de la configuration de visibilité des métadonnées

La configuration de la visibilité des métadonnées peut jouer un rôle important dans votre plan de sécurité global. Toutefois, il existe des cas dans lesquels un utilisateur qualifié et déterminé peut forcer la divulgation de certaines métadonnées. Nous vous recommandons de déployer des autorisations de métadonnées comme l’une des nombreuses défenses en profondeur.

Il est théoriquement possible de forcer l’émission de métadonnées dans les messages d’erreur en manipulant l’ordre d’évaluation du prédicat dans les requêtes. La possibilité de telles attaques d’essai et d’erreur n’est pas spécifique à SQL Server. Elle est implicite par les transformations associatifs et commutatives autorisées dans l’algèbre relationnelle. Vous pouvez atténuer ce risque en limitant les informations retournées dans les messages d’erreur. Pour restreindre davantage la visibilité des métadonnées de cette façon, vous pouvez démarrer le serveur avec l’indicateur de trace 3625. Cet indicateur de trace limite la quantité d’informations affichées dans les messages d’erreur. À son tour, cela permet d’empêcher les divulgations forcées. Le compromis est que les messages d’erreur seront brefs et peuvent être difficiles à utiliser à des fins de débogage. Pour plus d’informations, consultez Options de démarrage du service moteur de base de données et Indicateurs de trace (Transact-SQL).

Les métadonnées suivantes ne sont pas soumises à une divulgation forcée :

• Valeur stockée dans la colonne provider_string de sys.servers. Un utilisateur qui n’a pas d’autorisation ALTER ANY LINKED SERVER voit une valeur NULL dans cette colonne.

• Définition source d’un objet défini par l’utilisateur, tel qu’une procédure stockée ou un déclencheur. Le code source n’est visible que lorsque l’un des éléments suivants a la valeur true :

  • L’utilisateur dispose de l’autorisation VIEW DEFINITION sur l’objet.

  • L'utilisateur n'a pas été refusé le droit VIEW DEFINITION sur l'objet et dispose des droits CONTROL, ALTER ou TAKE OWNERSHIP sur l'objet. Tous les autres utilisateurs verront NULL.

• Les colonnes de définition que l'on trouve dans les vues de catalogue suivantes :

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

• La colonne ctext de la vue de compatibilité syscomments.

• Sortie de la procédure sp_helptext .

• Les colonnes suivantes dans les vues du schéma d'informations :

  INFORMATION_SCHEMA. CHECK_CONSTRAINTS. CHECK_CLAUSE	INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT
  INFORMATION_SCHEMA.DOMAINES.DOMAINE_PAR_DÉFAUT	INFORMATION_SCHEMA.ROUTINE_COLUMNS.COLUMN_DEFAULT
  INFORMATION_SCHEMA. ROUTINES. ROUTINE_DEFINITION	INFORMATION_SCHEMA. AFFICHAGE. VIEW_DEFINITION

• fonction OBJECT_DEFINITION()

• Valeur stockée dans la colonne password_hash de sys.sql_logins. Un utilisateur qui n’a pas d’autorisation CONTROL SERVER voit une valeur NULL dans cette colonne.

Principes généraux de la visibilité des métadonnées

Voici quelques principes généraux à prendre en compte concernant la visibilité des métadonnées :

• Permissions implicites des rôles fixes

• Étendue des autorisations

• Précedence de DENY

• Visibilité des métadonnées de sous-composant

Rôles fixes et autorisations implicites

Les métadonnées accessibles par des rôles fixes dépendent de leurs autorisations implicites correspondantes.

Étendue des autorisations

Les autorisations à une étendue impliquent la possibilité de voir les métadonnées à cette étendue et à toutes les étendues entourées. Par exemple, l’autorisation SELECT sur un schéma implique que le bénéficiaire dispose de l’autorisation SELECT sur tous les éléments sécurisables contenus dans ce schéma. L’octroi de l’autorisation SELECT sur un schéma permet donc à un utilisateur de voir les métadonnées du schéma et également toutes les tables, vues, fonctions, procédures, files d’attente, synonymes, types et collections de schémas XML au sein de celui-ci. Pour plus d’informations sur les étendues, consultez Hiérarchie des autorisations (moteur de base de données).

Priorité de DENY

DENY est généralement prioritaire sur d’autres autorisations. Par exemple, si un utilisateur de base de données reçoit l’autorisation EXECUTE sur un schéma, mais qu’il a refusé l’autorisation EXECUTE sur une procédure stockée dans ce schéma, l’utilisateur ne peut pas afficher les métadonnées de cette procédure stockée.

En outre, si un utilisateur a refusé l’autorisation EXECUTE sur un schéma, mais qu’il a reçu l’autorisation EXECUTE sur une procédure stockée dans ce schéma, l’utilisateur ne peut pas afficher les métadonnées de cette procédure stockée.

Pour un autre exemple, si un utilisateur a reçu et refusé l’autorisation EXECUTE sur une procédure stockée, ce qui est possible par le biais de vos différentes appartenances de rôle, DENY est prioritaire et l’utilisateur ne peut pas afficher les métadonnées de la procédure stockée.

Visibilité des métadonnées de sous-composant

La visibilité des sous-composants, tels que les index, les contraintes de vérification et les déclencheurs, est déterminée par les autorisations sur le parent. Ces sous-composants n’ont pas d’autorisations accordées. Par exemple, si un utilisateur a reçu une autorisation sur une table, l’utilisateur peut afficher les métadonnées des tables, des colonnes, des index, des contraintes de vérification, des déclencheurs et d’autres sous-composants de ce type.

Métadonnées accessibles à tous les utilisateurs de base de données

Certaines métadonnées doivent être accessibles à tous les utilisateurs d’une base de données spécifique. Par exemple, les groupes de fichiers n’ont pas d’autorisations pouvant être accordées ; par conséquent, un utilisateur ne peut pas être autorisé à afficher les métadonnées d’un groupe de fichiers. Toutefois, tout utilisateur pouvant créer une table doit être en mesure d'accéder aux métadonnées du groupe de fichiers pour utiliser les clauses ON groupe de fichiers ou TEXTIMAGE_ON groupe de fichiers de l'instruction CREATE TABLE.

Les métadonnées retournées par les fonctions DB_ID() et DB_NAME() sont visibles par tous les utilisateurs.

Le tableau suivant répertorie les vues de catalogue visibles par le rôle public .

Voir aussi

GRANT (Transact-SQL)
DENY (Transact-SQL)
REVOKE (Transact-SQL)
Clause EXECUTE AS (Transact-SQL)
Affichages catalogue (Transact-SQL)
Affichages de compatibilité (Transact-SQL)