> Data > Un accès sécurisé aux données des rapports

Un accès sécurisé aux données des rapports

Data - Par Jan De Clerq - Publié le 24 juin 2010
email

Dans les secteurs de la santé et de la finance, où les applications de base de données traitent fréquemment des informations confidentielles, le recours à l’authentification et au cryptage pour sécuriser l’accès aux données est devenu une pratique courante.
En effet, pour les entreprises soumises à des réglementations spécifiques telles que la loi américaine sur la portabilité et la responsabilité d’assurance médicale HIPAA (Health Insurance Portability and Accountability Act), la sécurisation des données des systèmes de reporting constitue une nécessité absolue. En revanche, dans de nombreux autres secteurs, la sécurité des systèmes de reporting et des bases de données auxquelles ils accèdent reste une priorité secondaire sur les listes de tâches des concepteurs et administrateurs de systèmes, en raison de sa complexité apparente.

Pourtant, ce type de travail n’a nul besoin d’être difficile, en particulier si vous utilisez SQL Server Reporting Services (SSRS) comme système de reporting. Fourni avec Windows Server 2003 ou Windows 2000. Voyons comment configurer SSRS afin de sécuriser l’accès à vos données.


Contenu complémentaire :

Le groupe utilisateurs de SQL Server

Un accès sécurisé aux données des rapports

Pour comprendre le modèle de contrôle des accès de SSRS, il faut d’abord appréhender le concept de rôle du modèle RBAC. Un rôle est un ensemble d’opérations ou de tâches qu’un sous-ensemble particulier d’utilisateurs doit pouvoir effectuer. La combinaison exacte des tâches constitutives d’un rôle permet à un type spécifique d’utilisateur d’accomplir son travail (ni plus, ni moins) dans le contexte d’une application donnée.

Par exemple, SSRS inclut un rôle Navigateur (Browser) pour les utilisateurs qui ont simplement besoin de consulter des rapports et un rôle Editeur (Publisher) pour ceux qui doivent afficher, gérer et publier des rapports. Pour appliquer le modèle RBAC, vous liez les rôles aux ressources d’une application, puis vous mappez les rôles aux identités des utilisateurs. Pour commencer rapidement la définition du modèle RBAC de votre application de reporting, SSRS inclut un ensemble de rôles prédéfinis. Ceux-ci peuvent servir à sécuriser les ressources SSRS ou à définir des rôles personnalisés et à supprimer ceux prédéfinis.

SSRS inclut deux catégories de rôles prédéfinis :
• Les rôles au niveau élément définissent les attributions des utilisateurs et administrateurs de données au niveau des éléments SSRS tels que les dossiers de rapports et les rapports proprement dits.
• Les rôles au niveau système spécifient les tâches administratives que les utilisateurs système et administrateurs système peuvent accomplir sur un serveur SSRS.

Sous les rôles au niveau système, SSRS définit un rôle Utilisateur système restreint et un rôle Administrateur système élargi. Si vous attribuez à un administrateur système uniquement un rôle au niveau système, autrement dit sans rôle au niveau élément, et s’il n’est pas administrateur local, il pourra effectuer seulement des tâches d’administration du système SSRS et ne pourra pas accéder au contenu des rapports SSRS.

Ce point est extrêmement important : les rôles au niveau système ne fournissent aucun accès aux rapports, aux dossiers de rapports ou à la hiérarchie des dossiers de rapports SSRS. Les utilisateurs qui ont besoin d’un accès à ces ressources doivent avoir un rôle au niveau élément approprié. SSRS prédéfinit 16 tâches au niveau élément et 9 au niveau système.

Ensemble, ces 25 tâches englobent toutes les actions qu’un utilisateur ou un administrateur peut accomplir dans SSRS. Les tableaux Web 1 et 2 (Club Abonnés) présentent les affectations de tâches au niveau système et au niveau élément pour les rôles SSRS prédéfinis. A la différence des rôles SSRS, vous ne pouvez pas définir vos propres tâches ou supprimer des tâches prédéfinies.

Téléchargez cette ressource

Sécuriser votre système d’impression

Sécuriser votre système d’impression

Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.

Data - Par Jan De Clerq - Publié le 24 juin 2010