Limitation des menaces et des risques de vulnérabilité (Reporting Services)
Cette rubrique décrit des techniques et des stratégies visant à réduire les menaces auxquelles est exposé un déploiement de Reporting Services.
Vue d'ensemble
Un serveur de rapports est un serveur sans état qui stocke du contenu et des données d'application en externe. L'une des plus grandes menaces auxquelles est exposée une installation de serveur de rapports est un accès non autorisé ou la falsification de la base de données et des fichiers de configuration du serveur de rapports. Moins manifeste mais tout aussi importante est la menace liée à la méthode de création des rapports et aux personnes habilitées à publier du contenu sur un serveur de rapports. Les définitions de rapport sont des assemblys qui s'exécutent en confiance totale sur un serveur. Elles peuvent contenir d'autres assemblys personnalisés qui s'exécutent également sur le serveur. Si le rapport ou un assembly personnalisé contient du code malveillant, ce code s'exécutera sur le serveur de rapports avec les informations d'identification de l'utilisateur qui a demandé le rapport. D'autres menaces subtiles peuvent se superposer du fait d'une conception de rapport qui expose involontairement des données sensibles. Par exemple, si un employé exécute un rapport qui utilise un ID employé comme paramètre, il ne doit pas être en mesure d'afficher des informations sur un autre employé en insérant un ID aléatoire dans une URL de rapport. Enfin, penchez-vous sur les pratiques de distribution de rapports au sein de votre organisation. Vous pouvez configurer un serveur de rapports de façon à réduire au maximum la possibilité de remettre des rapports à l'extérieur de l'organisation. Vous pouvez également recourir à des autorisations au niveau du système de fichiers ou du serveur de rapports de sorte que seuls les utilisateurs autorisés soient en mesure d'ouvrir un rapport.
Les sections suivantes de cette rubrique décrivent d'autres menaces et indiquent comment réduire les risques d'un exploit réel.
Limitation des risques d'attaque sur un serveur de rapports
Le tableau suivant décrit les menaces et les mesures de limitation des risques auxquels sont exposés les composants serveur et les paramètres de configuration.
Fonctionnalité ou opération |
Menace |
Limitation des risques |
|---|---|---|
Les paramètres de configuration sont stockés dans le fichier Web.config et dans les fichiers de configuration d'application sur le serveur de rapports. |
Un intrus peut accéder à l'ordinateur, localiser un fichier de configuration non chiffré ou non protégé et falsifier ce dernier. |
Définissez des autorisations au niveau du fichier. Par défaut, les autorisations sont accordées à des groupes de sécurité Reporting Services créés au moment de l'installation. |
Le service Web Report Server traite les requêtes à la demande envoyées via des connexions TCP/IP. |
Un intrus peut lancer une attaque par déni de service qui prend les formes suivantes : Plusieurs demandes non authentifiées sont dirigées vers un serveur cible. Des demandes incomplètes sont dirigées vers un serveur cible mais ne sont jamais finalisées. Les demandes sont excessivement volumineuses ; l'intrus lance une demande et envoie une charge utile importante au serveur. |
Le serveur de rapports abandonne toutes les demandes non authentifiées au bout de deux minutes, ce qui peut atténuer certains effets d'une attaque par déni de service. L'intervalle de deux minutes est fixe ; vous ne pouvez pas le raccourcir. Si l'attaque est basée sur des opérations de téléchargement en direction du serveur de rapports, vous pouvez diminuer la valeur de l'élément maxRequestLength dans le fichier Machine.config. Par défaut, ASP.NET définit une limite exprimée en mégaoctets (Mo) pour les éléments qui peuvent être téléchargés sur une application serveur. Notez que la diminution de la valeur de maxRequestLength doit être une mesure temporaire. Vous devez rétablir sa valeur précédente si le téléchargement de fichiers volumineux (tels que les modèles) est une pratique courante. Pour plus d'informations sur la définition de maxRequestLength dans une installation Reporting Services, consultez Limites de taille des captures instantanées et des rapports. |
Reporting Services prend en charge une architecture extensible qui permet de déployer des extensions tierces de traitement de données, de rendu et de remise. Vous pouvez également déployer des concepteurs de requêtes personnalisés. Les extensions doivent s'exécuter en mode Confiance totale. |
Un intrus peut introduire du code malveillant dans une extension personnalisée. |
Veillez à ne déployer que des extensions issues d'utilisateurs ou d'organisations dignes de confiance. |
Limitation des menaces liées aux définitions de rapport et aux modèles de rapport
Le tableau suivant décrit les menaces auxquelles sont exposés les définitions de rapport et les fichiers de modèle et présente des mesures destinées à limiter les risques.
Fonctionnalité ou opération |
Menace |
Limitation des risques |
|---|---|---|
Publication de rapports, de modèles et de sources de données partagées sur un serveur de rapports. Les rapports et les modèles se connectent à des sources de données externes et les interrogent. |
Interception de rapports, de modèles et de sources de données partagées lors d'une opération de publication. Interception des demandes en transit vers un ordinateur externe. |
Utilisez un canal sécurisé, chiffré, tel que SSL/TLS/IPSec, pour la connexion. Des technologies de chiffrement doivent être utilisées pour protéger un canal. Avant de procéder à l'envoi, informez les utilisateurs que le canal n'est pas sécurisé. |
Des jetons d'authentification ou des informations d'identification sont utilisés pour se connecter aux sources de données et ordinateurs distants. |
Interception des données d'authentification lors du traitement d'une demande. |
Utilisez un canal sécurisé, chiffré. Informez l'utilisateur que le canal n'est pas sécurisé, le cas échéant. Suivez le principe de l'autorisation minimale. La récupération des données utilisées dans un rapport nécessite des autorisations d'accès en lecture seule au niveau des sources de données. |
Les URL de rapport présentent des valeurs de paramètres dans la barre d'adresses de la fenêtre du navigateur. |
Si un rapport contient des données sensibles, n'ajoutez pas de valeurs de paramètres susceptibles d'être falsifiées dans l'URL. Par exemple, si un rapport paramétrable inclut un ID d'employé, un utilisateur peut insérer des ID d'employé aléatoires dans l'URL pour afficher les données relatives à d'autres utilisateurs. |
Avant de publier un rapport en vue de sa distribution finale, vérifiez que son URL ne contient pas de valeurs de paramètres susceptibles d'être remplacées par des valeurs aléatoires. Lorsque vous concevez vos rapports, souvenez-vous qu'aucune autorisation n'est associée à la définition des paramètres. Il existe deux façons de limiter les risques :
|
Les rapports et les modèles contiennent des informations de source de données et des requêtes. |
La divulgation d'informations sur une source de données ou sa structure met à la disposition de tout intrus des informations internes susceptibles d'être exploitées. |
Avant de permettre à un utilisateur de modifier un modèle de rapport, définissez la sécurité des éléments de rapport pour restreindre l'accès aux éléments de rapport que vous ne souhaitez pas révéler à l'utilisateur dans le Générateur de modèles. Définissez des autorisations d'accès aux fichiers. Ces autorisations portent sur les fichiers .rdl, .rds, .smdl, .ds, .dsv et .smgl. Par défaut, les fichiers stockés localement dans le dossier d'un utilisateur sont uniquement accessibles aux groupes et aux comptes d'utilisateurs définis sur l'ordinateur local si le système d'exploitation est Windows XP ou une version ultérieure. |
Les définitions de rapport et les sources de données partagées contiennent des chaînes de connexion aux sources de données. Il est possible d'inclure des informations d'identification dans une chaîne de connexion. |
Un intrus peut accéder aux informations d'identification de base de données stockées dans les chaînes de connexion à une base de données si les fichiers de rapport sont compromis. |
Stockez les informations d'identification hors de la chaîne de connexion. Vous pouvez utiliser l'option de stockage d'informations d'identification dans les pages de propriétés de la source de données pour chiffrer et stocker un compte et un mot de passe d'utilisateur. |
Les rapports et les modèles sont traités à la demande. Les rapports peuvent contenir ou faire référence à des assemblys personnalisés. Les rapports peuvent contenir des éléments de rapport personnalisés ou des contrôles tiers. Les contrôles d'éléments de rapport personnalisés requièrent le mode Confiance totale. |
Un intrus convainc un utilisateur d'exécuter un rapport exploitant du code Visual Basic incorporé ou des requêtes de base de données de façon à exécuter du code arbitraire avec les autorisations de l'utilisateur. L'exécution d'un rapport ou d'un modèle falsifié peut entraîner des dépassements de mémoire tampon, une panne de serveur, voire pire. |
Limitez le nombre d'utilisateurs autorisés à publier des rapports et des modèles. Assurez-vous que seuls les utilisateurs authentifiés sont autorisés à télécharger des fichiers. Assurez-vous que les utilisateurs qui créent des rapports savent comment créer des scripts capables de résister à des attaques par injection SQL, injection de script et injection HTML. Veillez à ne télécharger ou à ne publier que des rapports et des modèles émanant de personnes dignes de confiance. Veillez à n'installer ou à n'utiliser qu'un contrôle d'élément de rapport personnalisé émanant de personnes dignes de confiance. Examinez les fichiers avant de les télécharger pour vérifier que les références éventuelles aux assemblys personnalisés sont valides. Définissez des autorisations de fichiers au niveau des assemblys pour empêcher leur remplacement par des utilisateurs malveillants. |
L'affichage d'un rapport ou d'un modèle sous l'onglet Aperçu du Concepteur de rapports a pour effet de créer des données en mémoire cache qui sont extraites à l'aide des informations d'identification de l'auteur. |
Si d'autres utilisateurs affichent un aperçu d'un rapport sur l'ordinateur de son auteur, ils risquent d'être en mesure de voir des données du rapport qu'ils n'auraient autrement pas pu voir. |
Déployez les rapports sur un serveur ou à un emplacement de test une fois que vous les avez créés. |
Étapes générales de limitation des menaces et des risques de vulnérabilité
Mettez en œuvre les recommandations suivantes pour améliorer la sécurité globale de tout déploiement de serveur de rapports :
Désactivez les fonctionnalités non utilisées pour réduire la surface d'exposition aux attaques. Pour plus d'informations, consultez Procédure : activer ou désactiver les fonctionnalités Reporting Services.
Utilisez le protocole SSL pour les connexions au serveur de rapports. Pour plus d'informations, consultez Configuration d'un serveur de rapports pour des connexions SSL (Secure Sockets Layer).
Créez une arborescence de dossiers qui prend en charge des stratégies d'autorisation solides en plaçant les rapports sensibles ou confidentiels dans des dossiers situés aux extrémités de l'arborescence de dossiers, dans des dossiers accessibles à un groupe d'utilisateurs limité. Les rapports, les modèles, les sources de données partagées et les ressources que vous publiez sur un serveur de rapports sont sécurisés par le biais des attributions de rôles que vous créez au niveau des dossiers et d'éléments spécifiques du site du serveur de rapports. Comme l'arborescence de dossiers est entièrement définie par l'utilisateur, il vous appartient de créer une arborescence de dossiers qui regroupe les éléments associés à des autorisations d'accès utilisateur semblables. Pour plus d'informations, consultez Sécurisation des dossiers.
Sachez que les rapports à la demande sont des assemblys compilés qui s'exécutent en mode Confiance totale sur un serveur de rapports avec les informations d'identification de l'utilisateur qui ouvre le rapport. Les utilisateurs de rapports qui se connectent avec des informations d'identification d'administrateur local ou de domaine et qui ouvrent par la suite un rapport contenant du script malveillant exécuteront par inadvertance ce script avec les autorisations d'administrateur. Encouragez les utilisateurs à utiliser des comptes dotés de privilèges minimaux lors de la consultation de rapports. Pour plus d'informations, consultez Sécurité intégrée et autorisations élevées.
Il convient de comprendre la façon dont les données sont extraites et utilisées dans un rapport. Si un modèle contient des données sensibles, envisagez d'utiliser des modèles en tant que source de données. Vous pourrez ainsi appliquer des filtres de sécurité et une sécurité au niveau des éléments de modèle. Pour plus d'informations, consultez Didacticiel : Application de filtres de sécurité aux éléments de modèle de rapport.
Il importe de comprendre la façon dont les rapports sont distribués. Les fonctionnalités d'abonnement et de remise sont de puissantes techniques d'automatisation du traitement et de la distribution de rapports générés. Toutefois, pour éviter des accès non autorisés, vous avez tout intérêt à surveiller quels sont les utilisateurs qui possèdent des autorisations de partage au niveau des dossiers réseau et à évaluer les paramètres de configuration de la messagerie du serveur de rapports pour déterminer si vous devez limiter la distribution de courrier électronique. Pour plus d'informations, consultez Contrôle de la distribution des rapports.