Sécuriser les rapports et les ressources

Vous pouvez définir la sécurité pour des rapports et des ressources individuels afin de contrôler le degré d'accès dont disposent les utilisateurs à ces éléments. Par défaut, seuls les utilisateurs qui sont membres du groupe intégré Administrateurs peuvent exécuter les rapports, afficher les ressources, modifier les propriétés et supprimer les éléments. Tous les autres utilisateurs possèdent des attributions de rôles créées pour eux qui autorisent l'accès à un rapport ou une ressource.

Accès en fonction du rôle aux rapports et aux ressources

Pour accorder l'accès aux rapports et aux ressources, vous pouvez autoriser les utilisateurs à hériter des attributions de rôles existantes d'un dossier parent ou à créer une nouvelle attribution de rôle sur l'élément proprement dit.

Dans la plupart des cas, vous souhaiterez probablement utiliser les autorisations héritées d’un dossier parent. La définition de la sécurité sur des rapports et des ressources individuels doit être nécessaire uniquement si vous souhaitez masquer le rapport ou la ressource des utilisateurs qui n’ont pas besoin de savoir que le rapport ou la ressource existe, ou pour augmenter le niveau d’accès pour un rapport ou un élément. Ces objectifs ne s’excluent pas mutuellement. Vous pouvez restreindre l’accès à un rapport à un plus petit ensemble d’utilisateurs et fournir à tous ou certains d’entre eux des privilèges supplémentaires pour gérer le rapport.

Vous devrez peut-être créer plusieurs attributions de rôles pour atteindre vos objectifs. Par exemple, supposons que vous ayez un rapport que vous vouliez rendre accessible à deux utilisateurs, Anne et Fernand, et au groupe des responsables des ressources humaines. Anne et Fernand doivent être en mesure de gérer le rapport, mais les membres responsables des ressources humaines ont uniquement besoin de l'exécuter. Pour répondre aux besoins de ces différents utilisateurs, vous devez créer trois attributions de rôles distinctes : une qui donne à Anne un rôle de gestionnaire de contenu du rapport, une qui donne à Fernand un rôle de gestionnaire de contenu du rapport et une qui permette au groupe des responsables des ressources humaines d'effectuer des tâches en affichage seul.

Une fois que vous avez défini la sécurité sur un rapport ou une ressource, ceux-ci conservent ces paramètres même si vous déplacez l'élément à un autre endroit. Par exemple, si vous déplacez un rapport auquel seuls quelques personnes sont autorisées à accéder, le rapport continue d’être disponible uniquement pour ces utilisateurs, même si vous le déplacez vers un dossier qui a une stratégie de sécurité relativement ouverte.

Atténuation des attaques par injection HTML dans un rapport ou un document publié

Dans Reporting Services, les rapports et les ressources sont traités sous l’identité de sécurité de l’utilisateur qui exécute le rapport. Si le rapport contient des expressions, un script, des éléments de rapports personnalisés ou des assemblys personnalisés, le code s'exécute sous les informations d'identification de l'utilisateur. Si une ressource est un document HTML qui contient un script, le script s’exécute lorsque l’utilisateur ouvre le document sur le serveur de rapports. La possibilité d'exécuter un script ou du code dans un rapport est une fonction puissante associée à un certain degré de risque. Si le code est malveillant, le serveur de rapports et l'utilisateur qui exécute le rapport sont vulnérables à une attaque.

Lors de l’octroi de l’accès aux rapports et aux ressources qui sont traitées au format HTML, il est important de se rappeler que les rapports sont traités en toute confiance et que le script potentiellement malveillant peut être envoyé au client. Selon les paramètres du navigateur, le client exécute le code HTML au niveau de confiance spécifié dans le navigateur.

Vous pouvez limiter le risque d'exécution de script malveillant en prenant les précautions suivantes :

• Soyez sélectif lorsque vous décidez quelles sont les personnes pouvant publier du contenu sur un serveur de rapports. Étant donné que le potentiel de publication de contenu malveillant existe, vous devez limiter les utilisateurs qui peuvent publier du contenu à un petit nombre d’utilisateurs approuvés.

• Tous les éditeurs doivent éviter de publier des rapports et des ressources provenant de sources inconnues ou non approuvées. Si nécessaire, ouvrez le fichier dans un éditeur de texte et vérifiez qu'il ne contient pas d'URL et de script suspects.

Paramètres de rapport et injection de script

Les paramètres de rapport apportent une grande souplesse au niveau de la création et de l'exécution générale du rapport. Toutefois, cette souplesse peut, dans certains cas, être utilisée par un intrus au cours d'attaques par ruse. Pour réduire le risque d'exécution accidentelle de scripts malveillants, ouvrez les rapports rendus seulement à partir de sources approuvées. Il est recommandé de prendre en compte le scénario suivant qui est une attaque potentielle par injection de script renderer HTML :

1. Un rapport contient une zone de texte avec l’action lien hypertexte définie sur la valeur d’un paramètre pouvant contenir du texte malveillant.

2. Le rapport est publié sur un serveur de rapports ou mis à disposition de telle façon que la valeur du paramètre de rapport est contrôlable par l'URL d'une page Web.

3. Un attaquant crée un lien vers la page web ou le serveur de rapports en spécifiant la valeur du paramètre sous la forme « javascript :<script malveillant ici> » et envoie ce lien à quelqu’un d’autre dans une attaque par appât.

Atténuation des attaques par injection de script dans un lien hypertexte dans un rapport ou un document publié

Les rapports peuvent contenir des liens hypertexte incorporés dans la valeur de la propriété Action sur un élément de rapport ou une partie d’un élément de rapport. Les liens hypertexte peuvent être liés aux données extraites d'une source de données externe au moment du traitement du rapport. Si un utilisateur mal intentionné modifie les données sous-jacentes, le lien hypertexte risque d'être utilisé pour écrire des exploits. Si un utilisateur clique sur le lien dans le rapport publié ou exporté, un script malveillant peut s’exécuter.

Pour limiter le risque d'insertion de liens dans un rapport qui, par inadvertance, exécuterait des scripts malveillants, n'associez des liens hypertexte qu'avec des données de sources fiables. Vérifiez que les données des résultats de la requête et les expressions qui lient des données aux liens hypertexte ne créent pas de liens pouvant être exploités. Par exemple, ne basez pas de lien hypertexte sur une expression qui concatène des données à partir de plusieurs champs de jeu de données. Si nécessaire, accédez au rapport et utilisez la commande « Afficher la source » pour rechercher la présence éventuelle d'URL et de scripts suspects.

Atténuation des attaques par injection SQL dans un rapport paramétrable

Dans tout rapport qui inclut un paramètre de type String, veillez à utiliser une liste de valeurs disponibles (également appelée liste de valeurs valides) et vérifiez que tout utilisateur exécutant le rapport dispose uniquement des autorisations nécessaires pour afficher les données dans le rapport. Lorsque vous définissez un paramètre de type String, l’utilisateur est présenté avec une zone de texte qui peut prendre n’importe quelle valeur. Une liste de valeurs disponibles limite les valeurs susceptibles d'être entrées. Si le paramètre de rapport est lié à un paramètre de requête et que vous n’utilisez pas de liste de valeurs disponibles, il est possible qu’un utilisateur de rapport tapez la syntaxe SQL dans la zone de texte, ouvrant potentiellement le rapport et votre serveur à une attaque par injection SQL. Si l’utilisateur dispose des autorisations suffisantes pour exécuter la nouvelle instruction SQL, il peut produire des résultats indésirables sur le serveur.

Si un paramètre de rapport n’est pas lié à un paramètre de requête et que les valeurs des paramètres sont incluses dans le rapport, il est possible qu’un utilisateur de rapport tapez une syntaxe d’expression ou une URL dans la valeur du paramètre et affiche le rapport dans Excel ou HTML. Si un autre utilisateur affiche ensuite le rapport et clique sur le contenu du paramètre rendu, l’utilisateur peut exécuter par inadvertance le script ou le lien malveillants.

Pour réduire le risque d'exécution accidentelle de scripts malveillants, ouvrez les rapports rendus uniquement à partir de sources approuvées.

Sécurisation des rapports confidentiels

Les rapports qui contiennent des informations confidentielles doivent être sécurisés au niveau de l'accès aux données, en exigeant des utilisateurs qu'ils s'identifient pour accéder à des données sensibles. Pour plus d’informations, consultez Spécifier des informations d’identification et de connexion pour les sources de données de rapport. Vous pouvez également sécuriser un dossier pour le rendre inaccessible aux utilisateurs non autorisés. Pour plus d’informations, consultez Dossiers sécurisés.

Voir aussi

(créer-et-gérer-les-attributions-de-rôles.md)
Configurer l’accès au Générateur de rapports
Octroi d'autorisations sur un serveur de rapports en mode natif
Éléments de source de données partagées sécurisés
Stocker des informations d’identification dans une source de données Reporting Services