Sécurité de l’accès au code dans Reporting Services
La sécurité d'accès du code est axée sur les concepts principaux suivants : preuve, groupes de codes et jeux d'autorisations nommés. Dans Reporting Services, le Gestionnaire de rapports, Concepteur de rapports et les composants report Server ont chacun un fichier de stratégie qui configure la sécurité d’accès au code pour les assemblys personnalisés. Ce fichier de stratégie configure également l’accès au code pour les données, la remise, le rendu et les extensions de sécurité. Les sections suivantes fournissent une vue d'ensemble de la sécurité d'accès du code. Pour plus d’informations sur les articles abordés dans cette section, consultez « Modèle de stratégie de sécurité » dans la documentation du Kit de développement logiciel (SDK) Microsoft .NET Framework.
Reporting Services utilise la sécurité d’accès au code car, bien que le serveur de rapports repose sur ASP.NET technologie, il existe une différence substantielle entre une application ASP.NET classique et le serveur de rapports. Une application ASP.NET classique n’exécute pas de code utilisateur. En revanche, Reporting Services se sert d’une architecture ouverte et extensible qui permet aux utilisateurs de programmer des fichiers de définition de rapport à l’aide de l’élément Code du langage RDL (Report Definition Language), et de développer des fonctionnalités spécialisées dans un assembly personnalisé à utiliser dans les rapports. En outre, les développeurs peuvent concevoir et déployer de puissantes extensions visant à améliorer les fonctionnalités du serveur de rapports. Cette puissance et cette flexibilité sont nécessaires pour fournir autant de protection et de sécurité que possible.
Les développeurs Reporting Services peuvent utiliser n’importe quel assembly du .NET Framework dans leurs rapports, et faire appel en mode natif à toutes les fonctionnalités des assemblys déployés dans le Global Assembly Cache. La seule chose que le serveur de rapports peut contrôler est l'autorisation accordée aux expressions de rapport et aux assemblys personnalisés chargés. Dans Reporting Services, les assemblys personnalisés reçoivent par défaut les autorisations Execute uniquement.
Preuve
Une preuve représente l'information que le Common Language Runtime (CLR) utilise pour définir une stratégie de sécurité relative aux assemblys de code. Une preuve indique au runtime que le code possède une caractéristique particulière. Les formes communes de preuve incluent les signatures numériques et l'emplacement d'un assembly. Une preuve peut également être personnalisée pour représenter d'autres informations ayant une importance pour l'application.
Les assemblys et les domaines d'applications reçoivent des autorisations sur la base de la preuve. Par exemple, l’emplacement d’un assembly auquel Reporting Services tente d’accéder est une forme commune de preuve pour les assemblys portant un nom faible. Cet exemple est appelé preuve d’URL. La preuve d’URL d’une extension de traitement des données personnalisée déployée sur un serveur de rapports peut être C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Samples.ReportingServices.FsiDataExtension.dll. Le nom fort ou la signature numérique d'un assembly est une autre forme commune de preuve. Dans ce cas, la preuve est représentée par les informations de clé publique d'un assembly.
Groupes de codes
Un groupe de codes est un regroupement logique de codes selon une condition particulière d'appartenance (membership). Tout code remplissant la condition d'appartenance est inclus dans le groupe. Les administrateurs configurent une stratégie de sécurité en gérant les groupes de codes et leurs jeux d'autorisations associés.
Une condition d'appartenance d'un groupe de codes est basée sur la preuve. Par exemple, une appartenance « URL » d'un groupe de codes est basée sur la preuve URL. Le Common Language Runtime (CLR) utilise des caractéristiques d'identification (par exemple la preuve d'URL) pour décrire le code et déterminer si une condition d'appartenance à un groupe a été remplie. Par exemple, si la condition d'appartenance d'un groupe de codes est « code dans l'assembly C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Samples.ReportingServices.FsiDataExtension.dll », le runtime examine la preuve pour déterminer si le code provient de cet emplacement. Un exemple d’entrée de configuration pour ce type de groupe de codes peut ressembler à l’exemple suivant :
<CodeGroup class="UnionCodeGroup"
version="1"
PermissionSetName="FullTrust"
Name="MyCodeGroup"
Description="Code group for my data processing extension">
<IMembershipCondition class="UrlMembershipCondition"
version="1"
Url="C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Samples.ReportingServices.FsiDataExtension.dll"
/>
</CodeGroup>
Contactez votre administrateur système ou votre expert en déploiement d’applications pour déterminer le type de sécurité d’accès du code et les groupes de codes requis par vos assemblys personnalisés ou extensions Reporting Services.
Jeux d’autorisations nommés
Un jeu d'autorisations nommé est un jeu d'autorisations que les administrateurs peuvent associer à un groupe de codes. La plupart des jeux d'autorisations nommés comprennent au moins une autorisation, un nom et une description pour le jeu d'autorisations. Les administrateurs peuvent utiliser des jeux d'autorisations nommés pour établir ou modifier la stratégie de sécurité des groupes de codes. Plusieurs groupes de codes peuvent être associés au même jeu d'autorisations nommé. Le CLR fournit des ensembles d’autorisations nommés intégrés tels que Nothing, Execution, Internet, LocalIntranet, Everything et FullTrust.
Remarque
Les extensions relatives aux données personnalisées, à la remise, au rendu et à la sécurité dans Reporting Services doivent s’exécuter sous le jeu d’autorisations FullTrust. Contactez votre administrateur système pour ajouter le groupe de codes et les conditions d’appartenance appropriés pour vos extensions Reporting Services.
Vous pouvez associer vos propres niveaux personnalisés d'autorisations pour les assemblys personnalisés que vous utilisez avec des rapports. Par exemple, si vous souhaitez permettre à un assembly d'accéder à un fichier spécifique, vous pouvez créer un jeu d'autorisations nommé disposant d'un accès d'E/S de fichier spécifique, puis assigner ce jeu d'autorisations à votre groupe de codes. Le jeu d'autorisations suivant accorde l'accès en lecture seule au fichier MyFile.xml :
<PermissionSet class="NamedPermissionSet"
version="1"
Name="MyNewFilePermissionSet"
Description="A special permission set that grants read access to my file.">
<IPermission class="FileIOPermission"
version="1"
Read="C:\MyFile.xml"/>
<IPermission class="SecurityPermission"
version="1"
Flags="Assertion, Execution"/>
</PermissionSet>
Un groupe de codes que vous accordez à ce jeu d’autorisations peut ressembler à l’exemple suivant :
<CodeGroup class="UnionCodeGroup"
version="1"
PermissionSetName="MyNewFilePermissionSet"
Name="MyNewCodeGroup"
Description="A special code group for my custom assembly.">
<IMembershipCondition class="UrlMembershipCondition"
version="1"
Url="C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\MyCustomAssembly.dll"/>
</CodeGroup>