Sécurisation 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 voudrez probablement utiliser les autorisations qui sont héritées d'un dossier parent. Il est nécessaire d'établir des paramètres de sécurité sur les ressources et les rapports uniquement si vous voulez masquer le rapport ou la ressource aux utilisateurs qui n'ont pas besoin de savoir que le rapport ou la ressource existe, ou pour augmenter le niveau d'accès d'un rapport ou d'un élément. Ces objectifs ne sont pas mutuellement exclusifs. 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 est possible que vous deviez 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 même si vous le déplacez dans un dossier à stratégie de sécurité 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'entité 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 sera exécuté lorsque l'utilisateur ouvrira 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écutera 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 à un petit nombre d'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 suspicieux.
Limitation des attaques par injection SQL dans un rapport paramétré
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 assurez-vous que l'utilisateur qui exécute le rapport dispose uniquement des autorisations nécessaires à l'affichage des données du rapport. Lorsque vous définissez un paramètre de type String, 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 le paramètre de rapport est lié à un paramètre de requête et vous n'utilisez pas une liste de valeurs disponibles, l'utilisateur d'un rapport peut taper la syntaxe SQL dans la zone de texte, ce qui peut exposer le rapport et votre serveur de rapports au risque d'une attaque par injection SQL. Si l'utilisateur dispose d'autorisations suffisantes pour exécuter la nouvelle instruction SQL, cela risque de générer 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 les valeurs de paramètre sont incluses dans le rapport, l'utilisateur d'un rapport peut taper la syntaxe de l'expression ou une URL dans la valeur de paramètre et rendre le rapport au format Excel ou HTML. Si un autre utilisateur affiche ensuite le rapport et clique sur le contenu du paramètre de rendu, celui-ci peut exécuter accidentellement le lien ou le script malveillant.
Pour réduire le risque d'exécution accidentelle de scripts malveillants, ouvrez les rapports uniquement à partir de sources approuvées.
[!REMARQUE]
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écification 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 Sécurisation des dossiers.
Voir aussi