Configuration de la visibilité des métadonnées

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 accorde 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 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 :

• Affichages catalogue
• Métadonnées exposant des fonctions intégrées
• vues de compatibilité ;
• Procédures stockées du moteur sp_help de base de données
• Affichages des schémas d'information
• Propriétés étendues

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

• 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
• Procédures stockées sql Server Agent sp_help et réplication

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 émettrices de métadonnées telles que OBJECTPROPERTYEX peuvent retourner NULL.
• Les procédures stockées du moteur de base de données sp_help peuvent ne renvoyer qu’un sous-ensemble de lignes, ou NULL.
• Par conséquent, les applications qui supposent des interruptions d’accès aux métadonnées publiques .

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, object_id
FROM sys.objects
WHERE name = N'myTable';
END;
GO

Pour permettre aux appelants d’afficher les métadonnées, vous pouvez accorder l’autorisation des appelants VIEW DEFINITION , ou dans SQL Server 2022 (16.x) et versions ultérieures, soit VIEW SECURITY DEFINITIONVIEW PERFORMANCE DEFINITION dans une étendue appropriée : au niveau de l’objet, au niveau de la base de données ou au niveau du serveur. Par conséquent, dans l’exemple précédent, si l’appelant a VIEW DEFINITION l’autorisation sur myTable, la procédure stockée retourne une ligne. Pour plus d’informations, consultez GRANT et GRANT Database Permissions.

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.

Remarque

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

Remarque

Vous pouvez utiliser EXECUTE AS pour basculer temporairement vers le contexte de sécurité de l’appelant. Pour plus d’informations, consultez EXECUTE AS.

Avantages et limites 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 de forcer 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 est implicite par les transformations associatifs et commutatives autorisées dans l’algèbre relationnelle. 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. Le compromis est que les messages d’erreur sont brefs et peuvent être difficiles à utiliser à des fins de débogage. Pour plus d’informations, consultez les options de démarrage du service de moteur de base de données et les indicateurs de trace.

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

• La valeur stockée dans la colonne provider_string de sys.servers. Un utilisateur qui n’a ALTER ANY LINKED SERVER pas d’autorisation voit une NULL valeur 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’une des conditions suivantes est remplie :

  • L'utilisateur a l'autorisation VIEW DEFINITION pour l'objet.

  • L'utilisateur n'a pas été refusé l'autorisation VIEW DEFINITION sur l'objet et a l'autorisation CONTROL, ALTER, ou TAKE OWNERSHIP sur l'objet. Tous les autres utilisateurs voient 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

• La colonne ctext dans l’affichage de compatibilité syscomments.

• La sortie de la procédure sp_helptext.

• 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

• OBJECT_DEFINITION() fonction

• La valeur stockée dans la colonne password_hash de sys.sql_logins. Un utilisateur qui n’a pas l'autorisation CONTROL SERVER, ou dans SQL Server 2022 (16.x) et versions ultérieures, l’autorisation VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION, voit la valeur NULL dans cette colonne.

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

Remarque

La procédure sp_helptext stockée système 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, SELECT l’autorisation sur un schéma implique que le bénéficiaire dispose SELECT d’une autorisation sur tous les éléments sécurisables contenus dans ce schéma. L’octroi d’autorisations SELECT sur un schéma permet donc à un utilisateur de voir les métadonnées du schéma, ainsi que toutes les tables, vues, fonctions, procédures, files d’attente, synonymes, types et collections de schémas XML. Pour plus d’informations sur les étendues, consultez Hiérarchie des autorisations (moteur de base de données).

Remarque

L’autorisation n’influence pas la UNMASK visibilité des métadonnées : l’octroi UNMASK seul ne révèle aucune métadonnées. UNMASK doit toujours être accompagné d’une SELECT autorisation pour avoir un effet quelconque. Exemple : l’octroi UNMASK sur l’étendue de la base de données et l’octroi SELECT sur une table individuelle a le résultat que l’utilisateur ne peut voir que les métadonnées de la table individuelle à partir de laquelle il peut sélectionner, et non d’autres.

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 EXECUTE l’autorisation sur un schéma mais qu’il a été refusé EXECUTE l’autorisation 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é EXECUTE l’autorisation sur un schéma, mais qu’il a reçu EXECUTE l’autorisation 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é EXECUTE l’autorisation sur une procédure stockée, ce qui est possible grâce à vos différents rôles, DENY a la priorité et l’utilisateur ne peut pas afficher les métadonnées de la procédure stockée.

Visibilité des métadonnées des sous-composants

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 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 uniquement une colonne individuelle d’une table donnée : cela permet au bénéficiaire d’afficher les métadonnées de la table entière, y compris toutes les colonnes. L’une des façons de le considérer est que l’autorisation VIEW DEFINITION fonctionne uniquement au niveau de l’entité (la table dans ce cas) et n’est pas disponible pour les listes de sous-entités (telles que les colonnes ou les expressions 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 the table itself
;

REVERT;
GO

DROP TABLE t1;
DROP USER testUser;

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

Certaines métadonnées doivent rester accessibles à tous les utilisateurs dans une base de données spécifique. Par exemple, les groupes de fichiers ne disposent 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 qui peut créer 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 retournées par les DB_ID() fonctions et DB_NAME() sont visibles par tous les utilisateurs.

Voici la liste des affichages catalogue disponibles pour chaque rôle public.

• sys.allocation_units
• sys.column_type_usages
• sys.configurations
• sys.data_spaces
• sys.database_files
• sys.destination_data_spaces
• sys.filegroups
• sys.messages
• sys.parameter_type_usages
• sys.partition_functions
• sys.partition_range_values
• sys.partition_schemes
• sys.partitions
• sys.schemas
• sys.sql_dependencies
• sys.type_assembly_usages

Contenu connexe

• SUBVENTION (Transact-SQL)
• REFUSER (Transact-SQL)
• RROGER (Transact-SQL)
• Clause EXECUTE AS (Transact-SQL)
• Vues de catalogue système (Transact-SQL)
• Vues de compatibilité système (Transact-SQL)