Configuration de la visibilité des métadonnées
Dans les versions antérieures de SQL Server, les métadonnées de tous les objets d'une base de données sont visibles par tous les membres du rôle public. Autrement dit, tout utilisateur connecté à une instance de SQL Server peut voir les métadonnées de chaque objet du serveur, même celles des objets sur lesquels l'utilisateur n'a aucun droit.
Dans SQL Server 2005, les métadonnées ne sont visibles que pour les éléments sécurisables qu'un utilisateur détient ou pour lesquels des autorisations lui ont été accordées. Par exemple, la requête suivante renvoie une ligne si l'utilisateur bénéficie d'une autorisation comme SELECT ou INSERT sur la table myTable.
SELECT name, object_id
FROM sys.tables
WHERE name = 'myTable';
GO
Toutefois, si l'utilisateur ne dispose pas d'autorisation sur myTable, la requête renvoie un jeu de résultats vide.
Portée et impact de la configuration de la visibilité des métadonnées
La configuration de la visibilité des métadonnées ne s'applique qu'aux éléments sécurisables ci-dessous.
Affichages catalogue |
Moteur de base de données SQL Server 2005 Procédures stockées sp_help |
Métadonnées exposant des fonctions intégrées |
Affichages des schémas d'information |
Affichages compatibilité |
Propriétés étendues |
La configuration de la visibilité des métadonnées ne s'applique pas aux éléments sécurisables ci-dessous.
Tables système de copie des journaux de transaction |
Tables système de l'Agent SQL Server |
Tables système des plans de maintenance de base de données |
Tables système de sauvegardes |
Tables système de réplication |
Procédures stockées sp_help de la réplication et de l'Agent SQL Server |
Une accessibilité restreinte aux métadonnées implique les conséquences suivantes :
- Les applications qui sous-entendent un accès aux métadonnées public s'interrompront.
- Les requêtes portant sur les vues système risqueront de renvoyer simplement un sous-ensemble de lignes et même parfois un jeu de résultats vide.
- Les fonctions intégrées émettant des métadonnées telles que OBJECTPROPERTYEX peuvent renvoyer une valeur NULL.
- Les procédures stockées sp_help du moteur de base de données pourront renvoyer uniquement un sous-ensemble de lignes ou la valeur NULL.
Les modules SQL, tels que les procédures stockées et les déclencheurs, fonctionnent dans le contexte de sécurité de l'appelant et, par conséquent, auront un accès limité aux métadonnées. Dans le code suivant par exemple, lorsque la procédure stockée tente d'accéder aux métadonnées de la table myTable pour laquelle l'appelant n'a aucune autorisation, un jeu de résultats vide est renvoyé. Dans les versions antérieures de SQL Server, une ligne est renvoyée.
CREATE PROCEDURE assumes_caller_can_access_metadata
BEGIN
SELECT name, id
FROM sysobjects
WHERE name = 'myTable';
END;
GO
Si vous voulez autoriser les appelants à consulter les métadonnées, vous pouvez leur accorder l'autorisation VIEW DEFINITION avec une étendue appropriée : niveau de l'objet, niveau de la base de données ou niveau du serveur. Si, dans le cas de l'exemple précédent, l'appelant bénéficie d'une autorisation VIEW DEFINITION sur myTable, la procédure stockée renvoie une ligne. Pour plus d'informations, consultez GRANT (Transact-SQL) et GRANT – octroi d'autorisations de base de données (Transact-SQL).
Vous pouvez également modifier la procédure stockée pour qu'elle s'exécute avec les informations d'identification du propriétaire. Si le propriétaire de la procédure et celui de la table sont identiques, le chaînage des 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 de myTable. Dans ces circonstances, le code suivant renvoie une ligne de métadonnées à l'appelant.
.gif "ms187113.note(fr-fr,SQL.90).gif") Remarque : |
|---|
| L'exemple suivant utilise l'affichage catalogue sys.objects au lieu de l'affichage compatibilité 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
| Remarque : |
|---|
| Vous pouvez utiliser EXECUTE AS pour basculer temporairement dans le contexte de sécurité de l'appelant. Pour plus d'informations, consultez EXECUTE AS (Transact-SQL). |
Pour plus d'informations sur le chaînage des propriétés, consultez Chaînes de propriétés.
Avantages et inconvénients de la configuration de la 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. Sachez quand même qu'il existe des cas où un utilisateur expérimenté et déterminé peut enfreindre la confidentialité de certaines métadonnées. Nous vous recommandons de déployer des autorisations d'accès aux métadonnées comme d'autres mesures préventives efficaces.
Il est théoriquement possible d'imposer l'émission de métadonnées dans les messages d'erreur en manipulant l'ordre d'évaluation de prédicat dans les requêtes. L'éventualité d'attaques de type essai et erreur de cette sorte n'est pas spécifique à SQL Server. Elle provient implicitement des transformations associatives et commutatives autorisées en algèbre relationnel. Vous pouvez réduire ce risque en limitant les informations retournées dans les messages d'erreur. Pour restreindre encore la visibilité des métadonnées dans ce sens, 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 contribue à éviter les divulgations forcées. En échange, les messages d'erreur seront succints et plus difficiles à utiliser à des fins de débogage. Pour plus d'informations, consultez Utilisation des options de démarrage du service SQL Server et Indicateurs de trace (Transact-SQL).
Les métadonnées suivantes ne peuvent pas être violées :
Valeur stockée dans la colonne provider_string de sys.servers. Sans autorisation ALTER ANY LINKED SERVER, un utilisateur verra 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 si l'une des conditions suivantes est remplie :
- L'utilisateur dispose de l'autorisation VIEW DEFINITION pour l'objet.
- L'autorisation VIEW DEFINITION pour l'objet n'a pas été refusée à l'utilisateur et ce dernier bénéficie de l'autorisation CONTROL, ALTER ou TAKE OWNERSHIP sur l'objet. Tous les autres utilisateurs verront la valeur NULL.
Colonnes de définitions qui se trouvent dans les affichages catalogue suivants :
sys.all_sql_modules
sys.sql_modules
sys.server_sql_modules
sys.check_constraints
sys.default_constraints
sys.computed_columns
sys.numbered_procedures
Colonne ctext de l'affichage compatibilité syscomments
Sortie de la procédure stockée sp_helptext
Colonnes suivantes des affichages des schémas d'information :
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
Fonction OBJECT_DEFINITION()
Valeur stockée dans la colonne password_hash de sys.sql_logins. Un utilisateur qui ne possède pas l'autorisation CONTROL SERVER verra une valeur NULL dans cette colonne.
| Remarque : |
|---|
| Les définitions SQL des procédures et des fonctions système intégrées sont visibles par tous par l'intermédiaire de l'affichage catalogue sys.system_sql_modules, de la procédure stockée sp_helptext et de la fonction OBJECT_DEFINITION(). |
Principes généraux de la visibilité des métadonnées
Voici quelques points à prendre en compte en termes de visibilité des métadonnées :
- Autorisations implicites des rôles fixes
- Étendue des autorisations
- Priorité de DENY
- Visibilité des métadonnées des sous-composants
Rôles fixes et autorisations implicites
Dans SQL Server 2005, les métadonnées accessibles par les rôles fixes dépendent des autorisations implicites qui s'y rapportent.
Étendue des autorisations
Les autorisations délivrées à une étendue impliquent la possibilité de voir les métadonnées à ce niveau et à tous les niveaux inférieurs qui en dépendent. Par exemple, si une autorisation SELECT a été accordée à un utilisateur sur un schéma, le bénéficiaire possè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 consulter les métadonnées du schéma ainsi que des tables, vues, fonctions, procédures, files d'attente, synonymes, types et collections de schémas XML qu'il renferme. Pour plus d'informations sur les étendues, consultez Hiérarchie des autorisations.
Priorité de DENY
DENY a généralement la priorité sur toutes les autres autorisations. Par exemple, si un utilisateur de base de données dispose d'une autorisation EXECUTE sur un schéma, mais que l'autorisation EXECUTE lui a été refusée sur une procédure stockée de ce schéma, l'utilisateur ne peut pas voir les métadonnées de cette procédure stockée.
De plus, si un utilisateur se voit refuser l'autorisation EXECUTE pour un schéma alors qu'il dispose de l'autorisation EXECUTE pour une procédure stockée de ce schéma, l'utilisateur ne peut pas voir les métadonnées de cette procédure stockée.
Prenons un autre exemple. Si l'autorisation EXECUTE a été accordée, puis refusée à un utilisateur sur une procédure stockée, ce qui est possible par le biais de diverses appartenances aux rôles, DENY reste prioritaire et l'utilisateur ne peut pas voir les métadonnées de la procédure stockée.
Visibilité des métadonnées des sous-composants
La visibilité des sous-composants que sont les index, les contraintes de validation et les déclencheurs est déterminée par les autorisations accordées au parent. Ces sous-composants ne bénéficient pas d'autorisations transmissibles. Par exemple, si un utilisateur dispose d'une autorisation sur une table, il peut voir les métadonnées correspondant aux colonnes de la table, aux index, aux contraintes de validation, aux déclencheurs et à d'autres sous-composants de la sorte.
Métadonnées accessibles à tous les utilisateurs de la base de données
Certaines métadonnées doivent rester accessibles à tous les utilisateurs dans une base de données spécifique. Par exemple, dans la mesure où les groupes de fichiers ne peuvent pas recevoir d'autorisations, il est impossible d'octroyer à un utilisateur l'autorisation de consulter les métadonnées d'un groupe de fichiers. En revanche, tout utilisateur qui crée une table doit pouvoir accéder aux métadonnées du groupe de fichiers pour utiliser les clauses ON filegroup ou TEXTIMAGE_ON filegroup de l'instruction CREATE TABLE.
Les métadonnées renvoyées par les fonctions DB_ID() et DB_NAME() sont visibles par tous les utilisateurs.
Le tableau ci-dessous répertorie les affichages catalogue qui sont visibles par le rôle 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 |
Voir aussi
Tâches
Dépannage de la visibilité des métadonnées
Dépannage de la visibilité des métadonnées des vues partitionnées distribuées
Concepts
Autorisations des rôles de base de données fixes
Autorisation VIEW ANY DATABASE
Autorisation VIEW DEFINITION
Affichage des définitions d'objet
Autres ressources
GRANT (Transact-SQL)
DENY (Transact-SQL)
REVOKE (Transact-SQL)
Clause EXECUTE AS (Transact-SQL)
Affichages catalogue (Transact-SQL)
Vues de compatibilité (Transact-SQL)