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 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, ouNULL
.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 desys.servers
. Un utilisateur qui ne dispose pas de l’autorisation ALTER ANY LINKED SERVER voit une valeurNULL
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 desyscomments
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 uneNULL
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)
Commentaires
https://aka.ms/ContentUserFeedback.
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir:Soumettre et afficher des commentaires pour