Sécuriser des rapports et des 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 aux rapports et aux ressources en fonction des rôles
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 souhaitez probablement utiliser les autorisations qui sont héritées d'un dossier parent. La définition de la sécurité sur des ressources et des rapports individuels ne doit être nécessaire que dans quelques scénarios. Ces scénarios sont les suivants :
- 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
- Pour augmenter le niveau nécessaire à l’accès d’un rapport ou d’un élément.
Ces objectifs ne sont pas exclusifs l’un de l’autre. Vous pouvez limiter l'accès à un rapport à un plus petit nombre d'utilisateurs, et leur fournir (à tous ou à certains) des privilèges étendus pour gérer le rapport.
Il vous faudra possiblement 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 seules quelques personnes sont autorisées à accéder, le rapport continue à n'être accessible qu'à ces mêmes personnes. Ce résultat peut se produire même si vous le déplacez vers un dossier dont la stratégie de sécurité est relativement ouverte.
Limitation des attaques par injection HTML dans un document ou un rapport 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 est exécuté 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.
Lorsque vous accordez l'accès à des rapports et des ressources qui sont traités en tant que code HTML, vous devez garder en mémoire le fait que les rapports sont traités en confiance totale et qu'un script potentiellement malveillant peut être envoyé au client. En fonction des paramètres du navigateur, le client exécute le code HTML au niveau de confiance qui est 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. Dans la mesure où il existe un risque de publication de contenu malveillant, vous devez restreindre les utilisateurs pouvant publier du contenu à quelques utilisateurs de confiance.
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. Vous devez tenir compte du scénario suivant présentant une attaque potentielle par injection de script de convertisseur HTML :
Un rapport contient une zone de texte dont l'action du lien hypertexte est définie sur la valeur d'un paramètre qui pourrait éventuellement un texte malveillant.
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.
Un attaquant crée un lien vers la page web ou le serveur de rapports. Ce lien spécifie la valeur du paramètre dans le formulaire
javascript:<malicious script here>et envoie ce lien à quelqu’un d’autre dans une attaque par ruse.
Limitation des attaques par injection de script dans un lien hypertexte figurant 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 sélectionne le lien dans le rapport publié ou exporté, le script malveillant peut ensuite 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 issues des résultats de la requête et des expressions qui lient des données aux liens hypertexte ne créent pas de liens susceptibles d'être utilisés frauduleusement. Par exemple, ne fondez pas un 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.
Limitation des attaques par injection SQL dans un rapport paramétrable
Dans un 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 l’utilisateur qui exécute le rapport dispose uniquement des autorisations nécessaires à l’affichage des données du rapport. Quand vous définissez un paramètre de type Chaîne, la zone de texte qui apparaît vous permet d’entrer n’importe quelle valeur. Une liste de valeurs disponibles limite les valeurs susceptibles d'être entrées. Si vous liez le paramètre de rapport à un paramètre de requête et que vous n'utilisez pas une liste de valeurs disponibles, l'utilisateur d'un rapport peut taper la syntaxe SQL dans la zone de texte. Cette action peut potentiellement ouvrir le rapport et votre serveur à une attaque par injection de code SQL. Si l'utilisateur dispose d'autorisations suffisantes pour exécuter la nouvelle instruction SQL, cela risquerait de générer des résultats indésirables sur le serveur.
Un paramètre de rapport pourrait ne pas être lié à un paramètre de requête et les valeurs de paramètre sont incluses dans le rapport. Si c’est le cas, il est possible pour un utilisateur de rapport de taper une syntaxe d’expression ou une URL dans la valeur du paramètre et d’afficher le rapport dans Excel ou HTML. Si un autre utilisateur affiche ensuite le rapport et sélectionne le contenu du paramètre de rendu, l’utilisateur pourrait exécuter accidentellement le lien ou le script malveillant.
Pour réduire le risque d'exécution accidentelle de scripts malveillants, ouvrez les rapports rendus uniquement à partir de sources approuvées.
Notes
Les versions précédentes de la documentation contenaient un exemple de création d'une requête dynamique en tant qu'expression. Ce type de requête crée une vulnérabilité aux attaques par injection SQL ; il est par conséquent déconseillé.
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.