Sécurité de l’accès au code dans Reporting Services

La sécurité de l’accès au code se concentre sur ces concepts fondamentaux : preuves, groupes de code et jeux d’autorisations nommés. Dans Reporting Services, le Gestionnaire de rapports, le 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 ainsi que 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é de l’accès au code. Pour plus d’informations sur les rubriques abordées 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 utilise une architecture ouverte et extensible qui permet aux utilisateurs de programmer sur les fichiers de définition de rapport à l’aide de l’élément Code du langage de définition de rapport 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 des extensions puissantes qui améliorent les fonctionnalités du serveur de rapports. Grâce à cette puissance et à cette flexibilité, la nécessité de fournir autant de protection et de sécurité que possible.

Les développeurs Reporting Services peuvent utiliser n’importe quel assembly .NET Framework dans leurs rapports et appeler 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 les autorisations données pour les expressions de rapport et les assemblys personnalisés chargés. Dans Reporting Services, les assemblys personnalisés reçoivent des autorisations d’exécution uniquement par défaut.

Preuve

La preuve est les informations que le Common Language Runtime (CLR) utilise pour déterminer une stratégie de sécurité pour les assemblys de code. La preuve indique au runtime que le code a une caractéristique particulière. Les formes courantes de preuve incluent les signatures numériques et l’emplacement d’un assembly. Les preuves peuvent également être personnalisées pour représenter d’autres informations significatives pour l’application.

Les assemblys et les domaines d’application reçoivent des autorisations basées sur des preuves. Par exemple, l’emplacement d’un assembly que Reporting Services tente d’accéder est une forme courante de preuve pour les assemblys nommés faibles. Il s’agit de la 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 courante de preuve. Dans ce cas, la preuve est les informations de clé publique d’un assembly.

Groupes de codes

Un groupe de codes est un regroupement logique de code qui a une condition spécifiée pour l’appartenance. Tout code qui répond à la condition d’appartenance est inclus dans le groupe. Les administrateurs configurent une stratégie de sécurité en gérant les groupes de code et leurs jeux d’autorisations associés.

Une condition d’appartenance pour un groupe de codes est basée sur des preuves. Par exemple, une appartenance URL pour un groupe de codes est basée sur la preuve d’URL. Le Common Language Runtime (CLR) utilise des caractéristiques d’identification telles que la preuve d’URL pour décrire le code et déterminer si la condition d’appartenance d’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 à ce qui suit :

<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>  

Vous devez collaborer avec votre administrateur système ou expert en déploiement d’applications pour déterminer le type de sécurité d’accès au code et les groupes de code dont vos assemblys personnalisés ou extensions Reporting Services ont besoin.

Jeux d’autorisations nommés

Un jeu d’autorisations nommé est un ensemble d’autorisations que les administrateurs peuvent associer à un groupe de codes. La plupart des jeux d’autorisations nommés se composent d’au moins une autorisation, d’un nom et d’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é pour les groupes de codes. Plusieurs groupes de codes peuvent être associés au même jeu d’autorisations nommé. Le CLR fournit des jeux d’autorisations nommés intégrés ; parmi ceux-ci sont Nothing, Execution, Internet, LocalIntranet, Everything, and FullTrust.

Vous pouvez associer vos propres niveaux d’autorisations personnalisés pour les assemblys personnalisés que vous utilisez avec des rapports. Par exemple, si vous souhaitez autoriser un assembly à accéder à un fichier spécifique, vous pouvez créer un jeu d’autorisations nommé avec un accès d’E/S de fichier spécifique, puis affecter le jeu d’autorisations à votre groupe de codes. Le jeu d’autorisations suivant accorde un 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 à ce qui suit :

<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>  

Voir aussi

Développement sécurisé (Reporting Services)