Considérations relatives à sécurité de Notification Services

Article
12/15/2008

Notification Services implémente la sécurité en utilisant des rôle de base de données et des comptes d'utilisateur de base de données restreints. Cette rubrique décrit le modèle de sécurité de Notification Services et les méthodes recommandées pour améliorer la sécurité de vos applications Notification Services.

Modèle de sécurité de Notification Services

Notification Services possède un moteur qui exécute des fournisseurs d'événements hébergés, des générateurs et des distributeurs. Il peut également comporter des applications clientes qui envoient des événements ou gèrent des abonnements.

Les comptes de connexion utilisés par le moteur et les applications clientes font appel à l'authentification Windows ou à l'authentification SQL Server pour accéder à SQL Server ; ils accèdent aux bases de données en utilisant des comptes d'utilisateur de base de données, puis obtiennent les autorisations nécessaires sur les bases de données d'instance et d'application par le biais de leur appartenance aux rôles de base de données Notification Services.

L'illustration suivante montre les rôles de base de données qui fournissent les autorisations requises pour chaque composant de moteur, pour un fournisseur d'événements non hébergé et pour une interface de gestion d'abonnement.

Modèle de sécurité Notification Services

Des autorisations de base de données sont affectées aux rôles de base de données. Les utilisateurs de base de données pour des composants individuels obtiennent leurs autorisations requises par le biais de leur appartenance au rôle approprié :

Les comptes utilisés par les fournisseurs d'événements obtiennent des autorisations par le biais de leur appartenance au rôle de base de données NSEventProvider. L'hôte de fournisseurs d'événements exécute des fournisseurs d'événements hébergés. Les fournisseurs d'événements non hébergés sont des applications indépendantes.
Les comptes utilisés par les générateurs obtiennent des autorisations par le biais de leur appartenance au rôle de base de données NSGenerator.
Les comptes utilisés par les distributeurs obtiennent des autorisations par le biais de leur appartenance au rôle de base de données NSDistributor.
Les comptes utilisés par les interfaces de gestion d'abonnement obtiennent des autorisations par le biais de leur appartenance au rôle de base de données NSSubscriberAdmin.

Si un moteur exécute des fournisseurs d'événements hébergés, des générateurs et des distributeurs, son compte peut obtenir toutes les autorisations requises par le biais du rôle de base de données NSRunService.

Pour des informations sur l'implémentation de la sécurité pour Notification Services, consultez Sécurisation de Notification Services.

Comptes supplémentaires pour les actions de condition

Dans Microsoft SQL Server 2005, Notification Services présente une nouvelle fonctionnalité de règle d'abonnement. Les règles gérées par les événements et les règles planifiées peuvent maintenant utiliser des actions de condition qui permettent aux abonnés de définir des abonnements plus complexes en utilisant des clauses de requête définies par l'utilisateur.

Étant donné que les abonnements basés sur des actions de condition autorisent les clauses de requête définies par l'utilisateur, les données disponibles pour la requête ont dû être limitées. Vous devez pour cette raison définir un utilisateur de base de données sous lequel les actions de condition s'exécutent. L'utilisateur de base de données doit être autorisé à interroger uniquement les tables et les vues contenant des données d'entrée.

Le générateur active les règles qui contiennent les actions de condition. Toutefois, les requêtes d'action de condition sont aussi limitées par l'utilisateur de base de données spécifié. Vous spécifiez l'utilisateur de base de données lorsque vous définissez une application Notification Services.

Pour plus d'informations sur les actions de condition, consultez Définition des actions de condition.

Autorisations Windows

Outre les autorisations de base de données, certains composants nécessitent également des autorisations Windows supplémentaires :

Le compte utilisé pour exécuter le moteur de Notification Services doit appartenir au groupe Windows SQLServer2005NotificationServicesUser$ComputerName. Il est ainsi possible d'accéder aux fichiers binaires de Notification Services utilisés pour exécuter le service. Si le service Windows NS$instanceName est utilisé pour exécuter le moteur, Notification Services ajoute le compte de service au groupe SQLServer2005NotificationServicesUser$ComputerName lors de l'inscription de l'instance.
Tous les autres composants qui doivent accéder aux fichiers binaires de Notification Services peuvent aussi requérir l'appartenance au groupe SQLServer2005NotificationServicesUser$NomOrdinateur. Dans la mesure où les assemblys et les ressources de Notification Services se trouvent dans le GAC (Global Assembly Cache), il n'est pas nécessaire d'appartenir à ce groupe.
Les fournisseurs d'événements requièrent parfois des autorisations dans des dossiers et d'autres bases de données. Par exemple, un fournisseur d'événements FileSystemWatcher requiert l'accès en lecture dans un fichier XSD (XML Schema Definition) qui décrit le schéma d'événements, et des accès en lecture et en modification au dossier dans lequel des fichiers d'événements sont supprimés. Les fournisseurs d'événements SQL Server ont besoin d'accéder aux tables de base de données ou aux vues qui sont utilisées en tant que sources d'événements.
Les distributeurs ont besoin d'autorisations pour livrer des notifications au service de remise, tel qu'un serveur SMTP (Simple Mail Transfer Protocol), un SMS (Short Message Service), un serveur Web ou un système de fichiers. Les distributeurs qui utilisent le module de formatage de contenu de transformation XSL (XSLT) ont également besoin d'accéder aux fichiers XSLT.

Recommandations de sécurité

Les sections suivantes fournissent des recommandations pour sécuriser le moteur de Notification Services, les interfaces de gestion d'abonnement, les fournisseurs d'événements personnalisés, les protocoles de remise personnalisés et d'autres applications personnalisées.

Moteur de Notification Services

Lorsque vous déployez une instance de Notification Services, prenez en compte les recommandations de sécurité suivantes pour le moteur de Notification Services :

Configurez le moteur afin qu'il utilise l'authentification Windows pour accéder aux bases de données.
Exécutez le moteur sous un domaine à faibles privilèges ou un compte local. N'utilisez pas le compte Système local, Service local ou Service Réseau ni un compte du groupe Administrateurs.
Un protocole de remise peut toutefois nécessiter des privilèges supplémentaires pour le compte sous lequel le service s'exécute. Si, par exemple, vous envoyez des notifications en utilisant le service SMTP IIS (Internet Information Services) local, le compte sous lequel le moteur s'exécute doit être membre du groupe Administrateurs local. (Les privilèges d'administrateur ne sont pas obligatoires pour envoyer des notifications via un service SMTP sur un ordinateur distant).

Lorsque vous déployez une instance de Notification Services, assurez-vous que chaque moteur dispose uniquement des autorisations nécessaires.
Pour les déploiements mono-serveur, le moteur exécute tous les fournisseurs d'événements hébergés par l'instance, les générateurs et les distributeurs. Le compte utilisé par le moteur doit obtenir les autorisations de base de données nécessaires par le biais de l'appartenance au rôle de base de données NSRunService.
Pour les déploiements évolutifs, limitez les autorisations des moteurs individuels. Par exemple, si un moteur exécute uniquement les fournisseurs d'événements, restreignez les autorisations de base de données accordées au compte du moteur en transformant le compte en membre du rôle de base de données NSEventProvider et en n'accordant d'autorisation au compte à aucune autre base de données ni aucun autre serveur. N'utilisez pas le rôle NSRunService tant que le moteur n'exécute pas tous les composants de moteur.

Remarque :
Vous configurez ce que chaque moteur exécute en spécifiant le nom de système pour chaque fournisseur d'événements hébergé, générateur et distributeur lorsque vous définissez une application.

Si les composants de moteur de Notification Services et le moteur de base de données de SQL Server sont installés sur des serveurs distincts, assurez-vous que TCP/IP ou les canaux nommés sont activés pour le moteur de base de données. Pour contribuer à améliorer la sécurité du moteur de base de données, la plupart des protocoles réseau sont désactivés par défaut.
Assurez-vous que les comptes de connexion disposent de mots de passe renforcés. Pour plus d'informations sur les mots de passe renforcés, consultez la section « Création de mots de passe renforcés » dans la documentation Microsoft Windows.
Assurez-vous que tout le code exécuté par le moteur (fournisseurs d'événements personnalisés, modules de formatage de contenu et protocoles) provient d'une source fiable. Notification Services suppose que le code apparaissant dans la configuration de l'instance et la définition de l'application que vous utilisez pour créer et mette à jour l'instance de Notification Services provient d'une source fiable. Lors de la définition des applications, utilisez le nom d'assembly pleinement qualifié pour vous assurer que l'assembly correct est chargé.
Notification Services ne peut pas valider des champs d'en-tête de protocole. Par conséquent, si votre application utilise des informations d'abonné, de périphérique d'abonné ou d'abonnement dans un champ de protocole, validez l'entrée utilisateur ou utilisez des valeurs définies par l'application (et non des valeurs définies par l'utilisateur). Pour des exemples de données utilisateur malveillantes, consultez Injection SQL.
Protégez tous les dossiers contenant des fichiers de configuration ou des données d'application. Pour plus d'informations sur la protection des fichiers et des dossiers, consultez Sécurisation des fichiers et des dossiers.

Hébergement du moteur de Notification Services

Le moteur de Notification Services est généralement un service Windows NS$instanceName que vous créez lorsque vous inscrivez une instance de Notification Services NS. Toutefois, vous pouvez héberger le moteur dans votre propre application au lieu d'utiliser le service Windows.

Le moteur se connecte au moteur de base de données et exécute l'instance de Notification Services. Si vous hébergez le moteur de Notification Services, veillez à sécuriser vos fichiers sources et binaires.

Pour plus d'informations sur l'hébergement du moteur, consultez Hébergement du moteur de Notification Services.

Interfaces de gestion d'abonnement

Les interfaces de gestion d'abonnement permettent aux utilisateurs de s'abonner à une application de notification et de créer des abonnements. Les interfaces de gestion d'abonnement obtiennent les autorisations de base de données dans les bases de données d'instance et d'application par le biais de l'appartenance au rôle de base de données NSSubscriberAdmin.

Lorsque vous développez une interface de gestion d'abonnement, prenez en compte les recommandations de sécurité suivantes :

Avant d'ajouter, de supprimer ou de modifier des données d'abonnés et d'abonnement, vérifiez l'identité de l'abonné, puis faites correspondre cette identité à un ID d'abonné.
N'importe quel utilisateur ou application qui possède un compte avec l'appartenance au rôle de base de données NSSubscriberAdmin (ou des autorisations effectives supérieures) peut modifier des données d'abonnés et d'abonnement. N'accordez pas d'autorisations inutiles et ne protégez pas le nom d'utilisateur et le mot de passe utilisés par les interfaces de gestion d'abonnement.
Ne stockez pas d'informations sensibles en texte brut telles que les noms d'utilisateur et mots de passe utilisés pour les connexions de base de données de l'application. Utilisez l'interface DPAPI (Data Protection Application Programming Interface) pour chiffrer les informations sensibles, puis stockez ces informations dans le Registre.
Si votre application doit utiliser des informations sensibles pour l'identification des utilisateurs, telles que des numéros de sécurité sociale, vous pouvez fournir aux utilisateurs des ID utilisateur non sensibles, puis utiliser une table de recherche dans la base de données pour faire correspondre les informations sensibles.

Les interfaces de gestion d'abonnement sont souvent des applications Web. Pour des informations sur les options de sécurité des applications ASP.NET, consultez Déploiement d'une interface de gestion d'abonnement.

Fournisseurs d'événements personnalisés

Les fournisseurs d'événements envoient des données d'événements aux applications Notification Services. Vous pouvez développer des fournisseurs d'événements personnalisés, hébergés ou non, pour vos applications. Lorsque vous développez un fournisseur d'événements personnalisé, prenez en compte les recommandations de sécurité suivantes :

Assurez-vous que les fournisseurs d'événements utilisent le rôle de base de données NSEventProvider pour envoyer les événements.
Tout utilisateur ou application peut envoyer des événements s'il possède un nom de fournisseur d'événements valide et un compte appartenant au rôle de base de données NSEventProvider (ou un rôle disposant d'autorisations effectives supérieures) dans votre base de données d'application. N'accordez pas d'autorisations inutiles et protégez le nom d'utilisateur et le mot de passe utilisés par les fournisseurs d'événements non hébergés.
Ne stockez pas d'informations sensibles, telles que des noms d'utilisateur et des mots de passe en texte brut. Utilisez l'interface DPAPI pour chiffrer les informations sensibles, puis stockez ces informations dans le Registre.
Sécurisez tous les fichiers sources et binaires des composants personnalisés.

Les fournisseurs d'événements hébergés personnalisés envoient les événements dans le contexte de l'hôte du fournisseur d'événements ; il est inutile de fournir toutes les informations d'identification de sécurité dans le code de votre fournisseur d'événement hébergé pour envoyer les événements. La recommandation suivante s'applique spécifiquement aux fournisseurs d'événements hébergés :

Lors de la création de votre application, vous fournissez des informations sur le fournisseur d'événements hébergé personnalisé dans la définition de l'application. Notification Services approuve toutes les informations figurant dans la définition de l'application. Utilisez le nom d'assembly pleinement qualifié pour vous assurer que l'assembly correct est chargé.

Les fournisseurs d'événements non hébergés s'exécutent en dehors du contexte de votre application Notification Services. La recommandation suivante s'applique spécifiquement aux fournisseurs d'événements non hébergés :

Les fournisseurs d'événements non hébergés ne sont pas approuvés explicitement par Notification Services. Vous devez fournir des informations d'identification de sécurité dans le code de votre fournisseur d'événements non hébergé. Le compte spécifié doit être en mesure de se connecter à l'instance du moteur de base de données, et le compte d'utilisateur de base de données associé doit être membre du rôle de base de données NSEventProvider dans chaque base de données d'instance et d'application.

Protocoles de remise personnalisés

Les protocoles de remise personnalisés s'exécutent dans le contexte du moteur de Notification Services. Comme pour tous les composants personnalisés, sécurisez vos fichiers sources et binaires pour protéger toute les informations sensibles.

Objets NMO (Notification Services Management Objects)

Si vous utilisez des objets NMO (Notification Services Management Objects) pour configurer des instances de Notification Services, définir des applications ou développer des applications administratives, veillez à sécuriser les fichiers sources et binaires. Les fichiers contenant des bases de données d'instance et d'application peuvent contenir des informations sensibles, telles que des noms de serveur, des noms d'utilisateur et des mots de passe.

Pour plus d'informations sur les métadonnées d'instance et d'application et d'autres fichiers, consultez Sécurisation des fichiers et des dossiers.

Voir aussi