Configuration de la visibilité des métadonnées

  • Article

S’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

La visibilité des métadonnées est limitée aux é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 retourne une ligne si l'utilisateur bénéficie d'une autorisation telle que SELECT ou INSERT sur la table myTable.

SELECT name, object_id  
FROM sys.tables  
WHERE name = N'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

Métadonnées exposant des fonctions intégrées

vues de compatibilité ;

Procédures stockées sp_help moteur de base de données

Affichages des schémas d'information

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 des plans de maintenance de base de données

Tables système de réplication

Tables système SQL Server Agent

Tables système de sauvegardes

Réplication et sql Server Agent sp_help procédures stockées

Une accessibilité restreinte aux métadonnées implique les conséquences suivantes :

  • 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 comme OBJECTPROPERTYEX peuvent retourner une valeur NULL.

  • Les procédures stockées du moteur sp_help de base de données peuvent retourner uniquement un sous-ensemble de lignes, ou NULL.

  • Par conséquent, les applications qui supposent que l’accès aux métadonnées publiques s’interrompt.

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 retournée.

CREATE PROCEDURE assumes_caller_can_access_metadata  
BEGIN  
SELECT name, object_id   
FROM sys.objects   
WHERE name = N'myTable';  
END;  
GO

Pour permettre aux appelants d’afficher les métadonnées, vous pouvez accorder aux appelants l’autorisation VIEW DEFINITION ou commencer par SQL Server 2022 VIEW SECUIRITY DEFINITION ou VIEW PERFORMANCE DEFINITION dans une étendue appropriée : niveau objet, niveau base de données ou niveau 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 Database Permissions (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.

Note

L’exemple suivant utilise l’affichage catalogue sys.objects au lieu de l’affichage de compatibilité 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

Note

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).

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. La possibilité de telles attaques d’essai et d’erreur 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 succincts et plus 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 peuvent pas être violées :

  • Valeur stockée dans la provider_string colonne de sys.servers. Un utilisateur qui ne dispose pas de l’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 si l'une des conditions suivantes est remplie :

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

    • L’autorisation VIEW DEFINITION sur 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 voient une valeur NULL.

  • Colonnes de définitions qui se trouvent dans les affichages catalogue suivants :

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

  • Colonne ctext dans la vue de syscomments compatibilité.

  • Sortie de la sp_helptext procédure.

  • Colonnes suivantes des affichages des schémas d'information :

    • 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

  • Fonction OBJECT_DEFINITION()

  • Valeur stockée dans la colonne password_hash de sys.sql_logins. Un utilisateur qui n’a pas CONTROL SERVER ou qui commence par SQL Server 2022, l’autorisation VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION voit une NULL valeur dans cette colonne.

Note

Les définitions SQL des procédures et fonctions système intégrées sont visibles publiquement par le biais de la sys.system_sql_modules vue catalogue, de la sp_helptext procédure stockée et de la fonction OBJECT_DEFINITION().

Note

La procédure stockée système sp_helptext n’est pas prise en charge dans Azure Synapse Analytics. À la place, utilisez l’affichage catalogue d’objets sys.sql_modules.

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

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 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 consulter les métadonnées du schéma, ainsi que l’ensemble 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 (moteur de base de données).

Note

L’autorisation UNMASK n’influence pas la visibilité des métadonnées : l’octroi de l’autorisation UNMASK seule ne divulgue pas de métadonnées. L’autorisation UNMASK doit toujours être accompagnée d’une autorisation SELECT pour avoir un effet. Exemple : Si vous octroyez UNMASK sur l’étendue d’une base de données et SELECT sur une table individuelle, l’utilisateur peut uniquement voir les métadonnées de la table individuelle sur laquelle il dispose de l’autorisation SELECT, et d’aucune autre.

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, il 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, il 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. Un autre exemple consiste à accorder SELECT seulement sur une colonne individuelle d’une table donnée : cela permet au bénéficiaire de voir les métadonnées de la totalité de la table, notamment toutes les colonnes. L’une des façons de le voir est que l’autorisation VIEW DEFINITION ne fonctionne qu’au niveau de l’entité (la table, dans le cas présent) et n’est pas disponible pour les listes de sous-entités (comme les expressions de colonne ou de sécurité).

Le code suivant illustre ce comportement :

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

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 peut créer une table doit pouvoir accéder aux métadonnées du groupe de fichiers pour utiliser les clauses ON groupe_fichiers ou TEXTIMAGE_ON groupe_fichiers 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.

Voici la liste des affichages catalogue disponibles pour chaque rôle 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

Voir aussi

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