Modèle de sécurité pour Windows Server AppFabric

Vous devez protéger vos applications .NET Framework gérées par Windows Server AppFabric de manière à ce que les utilisateurs soient autorisés à accéder uniquement aux services et aux données pour lesquels ils ont reçu une autorisation. Pour ce faire, vous devez identifier les utilisateurs, vérifier qu'ils sont bien ceux qu'ils prétendent être et déterminer s'ils ont reçu l'autorisation d'afficher les informations ou de réaliser la tâche demandée. L'échange de messages entre le client et le serveur doit avoir lieu via un canal sécurisé qui garantit l'intégrité du transfert d'informations privées. Les technologies Microsoft qui prennent en charge AppFabric offrent des services intégrés permettant aux entreprises de se connecter à vos applications, ainsi que de les utiliser, de manière sécurisée. Les administrateurs AppFabric ne doivent pas assurer la gestion de plusieurs jeux de bases de données de comptes d'utilisateurs, et tous les services associés à des centaines de serveurs intranet peuvent être gérés facilement à partir d'un outil graphique unique. L'intégration des produits et technologies de sécurité Microsoft qui prennent en charge AppFabric permet d'octroyer aux utilisateurs un accès à toutes les ressources nécessaires à l'exécution de leurs applications.

Éléments importants de la sécurité d'AppFabric

Son objectif principal du modèle de sécurité de AppFabric est de fournir à la majorité des utilisateurs de AppFabric un dispositif simple et efficace. Grâce à son intégration à Windows, à .NET Framework, à IIS et aux modèles de sécurité SQL Server, les utilisateurs peuvent tirer profit de l'ensemble des connaissances et du savoir-faire actuels en matière de sécurité pour utiliser le modèle de sécurité de AppFabric. Plus spécifiquement, les concepts de sécurité de Windows, de .NET Framework, d'IIS et de SQL Server permettent d'appliquer différents niveaux de sécurité aux applications WCF et WF gérées par le modèle. Étant donné que AppFabric n'apporte que des améliorations mineures à un schéma intégré de sécurité Microsoft qui a fait ses preuves, son modèle de sécurité semblera familier aux administrateurs ayant déjà assimilé les concepts de sécurité de Microsoft. Pour les clients de AppFabric, le coût total de possession sur le long terme s'en trouve donc diminué. Si vous êtes déjà familiarisé avec ces produits et technologies, vous pouvez facilement sécuriser votre application en suivant les instructions de la section Sécurité et protection.

AppFabric fait appel aux concepts de sécurité existants comme suit :

  • Sécurité Windows. AppFabric exploite la sécurité des groupes et du système de fichiers Windows. L'architecture de sécurité éprouvée de Windows est appliquée de manière cohérente sur tous les composants d'une application ; l'authentification est liée au contrôle de l'accès aux ressources AppFabric. Pour plus d'informations, consultez la section Sécurité Windows.

  • Sécurité .NET Framework. AppFabric exploite les services WCF et WF de la sécurité Windows Communication Foundation. Le service WCF est une plateforme de programmation distribuée basée sur les messages SOAP, et il est admis que la sécurisation des messages qui transitent entre les clients et les serveurs constitue un aspect essentiel de la protection des données. Aussi, le service WCF déploie une plateforme d'échange polyvalente et interopérable pour les messages sécurisés, laquelle exploite l'infrastructure de sécurité existante et les normes reconnues de sécurité des messages SOAP. Les concepts auxquels fait appel le service WCF vous sembleront familier, si vous avez déjà créé des applications sécurisées et distribuées exploitant des technologies actuelles telles que le protocole HTTPS, la sécurité intégrée de Windows, les noms d'utilisateurs et les mots de passe permettant d'identifier des utilisateurs. Pour plus d'informations, consultez la rubrique Sécurité .NET Framework et IIS.

  • Sécurité IIS. AppFabric fait appel à un sous-ensemble de fonctionnalités de sécurité IIS, car ses services sont hébergés dans le Service d’activation des processus Windows (WAS) et ses outils d'administration sont affichés dans le Gestionnaire des services Internet. IIS est étroitement intégré au système d'exploitation Windows afin d'optimiser les niveaux de sécurité des applications et des données : IIS s'intègre dans le modèle de sécurité et le système d'exploitation Windows NT, comme le système de fichiers et l'annuaire. AppFabric est basé sur le concept d'identifié de pool d'applications quand les services de flux de travail de AppFabric doivent accéder à la base de données de persistance en cours d'exécution. À l'instar des autres services Windows, IIS utilise les listes de contrôle d'accès (ACL) de Windows NT Server. Sachant qu'IIS exploite la base de données d'utilisateurs de Windows NT Server, les administrateurs AppFabric n'ont pas besoin de créer des comptes d'utilisateurs distincts sur chaque serveur Web, et les utilisateurs d'un intranet doivent se connecter une seule fois à leur réseau. Pour plus d'informations, consultez la rubrique Sécurité .NET Framework et IIS.

  • Sécurité SQL Server. AppFabric crée des rôles de base de données SQL Server pour contrôler l'accès à ses bases de données de persistance et de surveillance. AppFabric exploite l'authentification Windows intégrée en ce qui concerne l'accès à ses bases de données SQL Server. La sécurité intégrée fait appel à l'identité Windows actuelle qui a été établie lors du thread appelant qui permet d'accéder aux bases de données SQL Server. Vous pouvez ensuite mapper l'identité Windows aux autorisations et bases de données SQL Server de AppFabric. Pour plus d’informations, consultez la rubrique Sécurité SQL Server.

Rôles conceptuels de sécurité d'AppFabric

Comprendre le modèle de sécurité de AppFabric aide à se familiariser avec les attributs des trois rôles de sécurité associés. Ces rôles sont strictement conceptuels ; aucune entité du modèle de sécurité ne possède l'un de ces noms. Toutefois, ils se manifestent au travers des groupes physiques de sécurité Windows et des rôles de base de données SQL Server correctement mappés. Dans votre solution de sécurité, vous affectez à ces rôles les utilisateurs et les autorisations comme suit :

  • Observateurs de serveur d'applications. Ce rôle administratif offre une visibilité totale des données de surveillance et de persistance d'une application. Les observateurs de serveur d'applications peuvent :

    • énumérer les applications et les services ;

    • afficher la configuration de l'application et du service ;

    • afficher les données de surveillance ;

    • examiner les instances persistantes.

  • Administrateurs de serveur d'applications. Ce rôle administratif offre un contrôle total sur la configuration, la surveillance et la persistance d'une application. Les administrateurs de serveur d'applications peuvent exécuter toutes les tâches pouvant être réalisées par les observateurs de serveur d'applications, ainsi que les opérations suivantes :

    • interruption, reprise, arrêt, annulation et suppression des instances persistantes ;

    • création et suppression des sources et des collecteurs d'événements ;

    • affichage, purge et archivage des données de surveillance.

  • Utilisateurs de serveur d'applications. Ce rôle est utilisé par IIS au moment de l'exécution afin d'attribuer les identités de toutes les applications d'hébergement des pools d'applications. Les services inclus dans les applications reçoivent un accès partagé aux bases de données de persistance et aux services système.

En tant qu'utilisateur de AppFabric, vous devez savoir que ces trois rôles conceptuels sont ceux que vous utilisez lors de la création de votre solution de sécurité. Vous affectez les autorisations et les utilisateurs appropriés avec les groupes et comptes Windows NT, les pools d'applications IIS ainsi que les informations de connexion et les rôles de base de données correspondants, comme décrit dans la présente documentation. Pour plus d'informations ainsi que des conseils de sécurité essentiels sur l'utilisation des rôles de AppFabric, les autorisations de sécurité associées et la manière dont ils sont mappés vers les groupes de sécurité de Windows et les rôles de base de données SQL Server, consultez les rubriques Sécurité Windows, Sécurité .NET Framework et IIS et Sécurité SQL Server.

Étendue de la sécurité d'AppFabric

AppFabric utilise les comptes de sécurité Windows ainsi que les noms de connexion et les rôles de base de données SQL Server pour déterminer l'accès dont dispose un utilisateur ou une application aux ressources système, telles que les bases de données de persistance, les données de minuterie, les données de surveillance et les fichiers de configuration. L'accès à ces ressources se produit à la fois au niveau de l'application et au niveau de la gestion, qui constituent les deux zones d'étendue logique associées au modèle de sécurité de AppFabric. L'étendue de l'application couvre le processus d'exécution des services AppFabric hébergés en tant qu'applications IIS. L'étendue de la gestion concerne la gestion de AppFabric d'un point de vue administratif. Pour approfondir les trois rôles de sécurité de AppFabric, examinons leur utilisation sur les étendues de l'application et de la gestion.

Étendue de l'application

L'étendue de l'application définit l'exécution en cours des services .NET Framework configurés dans AppFabric et hébergés dans l'espace du processus WAS sous IIS. Cela ne concerne ni l'administration, ni les outils ; l'étendue en question est celle de la gestion. Les concepts de l'étendue de l'application s'appliquent au rôle de sécurité conceptuel Utilisateurs de serveur d'applications de AppFabric. Ce rôle mappe vers le groupe Windows IIS_IUSRS, qui constitue un groupe de sécurité Windows utilisé pour le compte de service IIS. Pour plus d'informations, consultez les rubriques Sécurité Windows, Sécurité .NET Framework et IIS et Sécurité SQL Server.

Chaque application est exécutée dans un pool d'applications. Il peut s'agir du pool d'applications par défaut, ou vous pouvez également créer et configurer votre propre pool d'applications. (La création et la configuration d'un pool d'applications est une fonction d'administrateur traitée dans la section « Étendue de la gestion » ci-dessous.) Vous pouvez utiliser un pool d'applications pour regrouper des applications et des services au sein d'un même espace de processus de travail, et partager ainsi les paramètres de configuration et autres entités de système d'exploitation. Étant donné que chaque processus de travail fonctionne en tant qu'instance distincte de l'exécutable parent W3WP.EXE, chaque processus prenant en charge un pool d'applications doit être considéré comme une instance autonome. Cela permet d'isoler les applications si vous hébergez une application dans son propre pool. L'isolation des applications empêche qu'une application Web qui aurait échoué n'affecte des applications exécutées dans d'autres pools d'applications.

L'isolation de la sécurité personnalisée constitue un autre avantage. Cela permet de s'assurer que l'entité de sécurité configurée du processus de travail hébergeant le pool d'applications (qui contient le service AppFabric.NET Framework), est utilisée lors de l'accès à des ressources situées en aval, telles que SQL Server. L'identité par défaut du pool d'applications est le compte Network_Service. Vous pouvez affecter votre propre identité de compte Windows lors de la configuration du pool d'applications dans IIS. Au moment de l'exécution, WAS transfère tout message entrant de la file d'attente du pool d'applications vers le processus de travail W3WP.EXE correspondant à l'aide des liaisons de l'application Web spécifiées dans la métabase IIS. C'est ainsi que AppFabric autorise l'activation des points de terminaison et des services WCF à l'aide de protocoles non-HTTP. IIS recherche tous les comptes Windows situés dans ses pools d'applications et les ajoute au groupe de sécurité Windows local BUILTIN\IIS_IUSRS. Si vous avez créé votre propre pool d'applications, IIS ajoute automatiquement l'identité de celui-ci au groupe Windows IIS_IUsers.

L'utilisation de plusieurs pools d'applications possédant des identités de sécurité distinctes permet d'isoler les applications en ce qui concerne l'accès des bases de données de persistance et de surveillance de AppFabric au moment de l'exécution. Par défaut, ces bases de données sont entièrement partagées avec toutes les identités AppFabric authentifiées qui sont utilisées par leurs pools d'applications hébergées. Si vous souhaitez obtenir un niveau de sécurité supérieur grâce à l'isolation, vous pouvez restreindre l'affectation des autorisations sur certaines ressources de base de données spécifiques, à certaines identités spécifiques utilisées par des pools d'applications IIS spécifiques. Vous pouvez également contrôler la sécurité au moment de l'exécution en créant vos propres bases de données dédiées à des applications spécifiques, et en vous assurant que seules les identités spécifiées se connectent à ces bases de données. Toutefois, vous pouvez isoler une application à partir de la base de données de surveillance et l'autoriser à accéder uniquement à la base de données de persistance.

L'étendue de l'application s'applique également aux services système installés et exploités par AppFabric :

  • Service de collecte d'événements. Ce service collecte des événements en provenance de AppFabric et des applications hébergées.

  • Service de gestion du flux de travail. Ce service traite les commandes de contrôle de flux de travail, active les instances de flux de travail via des minuteurs, et redémarre les services de flux de travail abandonnés.

Ces deux services sont exécutés sous le compte Autorité NT\Service local. Le compte Service local dispose de l'autorisation pour émettre des événements de suivi mais également pour manipuler les instances persistantes (arrêt, interruption et reprise).

L'augmentation des contrôles de sécurité réduit généralement les performances. Bien que l'isolation des applications augmente les capacités de sécurité, cette opération provoque une utilisation accrue de la mémoire et des ressources de processus du fait de l'exécution de plusieurs processus. Pour économiser les ressources, vous devrez peut-être isoler les applications à l'aide du modèle appDomain .NET Framework plutôt que d'utiliser plusieurs processus distincts. Deux applications ou plus peuvent cohabiter en toute sécurité avec le même processus sur des domaines appDomains distincts tout en respectant la mémoire virtuelle et les valeurs de données de chacune.

Étendue de la gestion

L'étendue de la gestion définit l'administration et les outils associés à la gestion administrative des applications. Cela ne concerne pas l'exécution réelle des services .NET Framework configurés dans AppFabric, qui relève de l'étendue de l'application. Les concepts de l'étendue de la gestion s'appliquent aux rôles conceptuels de sécurité Administrateurs de serveur d'applications et Observateurs de serveur d'applications AppFabric.

D'un point de vue administratif et d'un point de vue des services système, cette étendue concerne la gestion de AppFabric ainsi que ses technologies de prise en charge. Vous pouvez réaliser des opérations de gestion préalables à l'exécution d'une application : vous pouvez par exemple déployer et configurer une application .NET Framework dans AppFabric. Vous pouvez également effectuer des opérations de gestion pendant l'exécution, lorsque l'état d'un flux de travail a été rendu persistant et que la prochaine étape doit être traitée via l'interface utilisateur de AppFabric. Par exemple, un flux de travail interrompu a peut-être besoin d'être repris. L'autorisation de sécurité pour gérer la configuration et l'exécution des services .NET Framework configurés dans AppFabric est basée sur l'appartenance à des groupes de sécurité Windows spécifiques. L'étendue de la gestion s'applique également aux services service de collecte d'événements ; et Service de gestion du flux de travail, mais d'un point de vue de gestion et de contrôle plutôt que d'un point de vue de l'application.

Les rôles de sécurité conceptuels Administrateur de serveur d'applications et Observateurs de serveur d'applications mappent respectivement vers les groupes de sécurité de Windows NT AS_Administrators et AS_Observers. Le groupe AS_Administrators contient l'ID de service (SID) des services Service de gestion du flux de travail et service de collecte d'événements ;. Une fois les services enregistrés auprès du Gestionnaire de contrôle des services, leur SID ne change plus. Cela signifie que les services service de collecte d'événements ; et Service de gestion du flux de travail deviennent membres du groupe AS_Administrators, indépendamment de leur identité d'exécution. Généralement, cette identité est Autorité NT\Service local. Ainsi, le fait d'utiliser les SID au lieu des identités de service empêche tout autre service ou processus exécuté sous l'identité Autorité NT\Service local de devenir membre du groupe AS_Administrators. Pour plus d'informations sur les rôles de sécurité dans AppFabric et leur utilisation, consultez les rubriques Sécurité Windows, Sécurité .NET Framework et IIS et Sécurité SQL Server.

AppFabric sécurise l'étendue de la gestion lors de l'installation. Lorsque les cmdlets Windows PowerShell créent les bases de données de persistance et de surveillance lors de l'installation, les rôles de base de données SQL Server appropriés sont également créés sur la base des rôles de sécurité conceptuels AppFabric correspondants. Par exemple, les rôles créés dans SQL Server pour le groupe AS_Observers sont des rôles du type Lecteur (rôle MonitoringDbReader pour la base de données de surveillance et rôle System.Activities.DurableInstancing.InstanceStoreObservers pour la base de données de persistance). Les rôles de base de données SQL Server définis pour le compte de connexion AS_Administrators incluent tous les rôles de base de données associés au compte de connexion AS_Observers, ainsi que des rôles supplémentaires permettant de créer et de modifier les entités des bases de données d'un point de vue administratif.

Par défaut, le programme d'installation de AppFabric exécute certaines cmdlets AppFabric lors de son processus. AppFabric crée tous les comptes et groupes de sécurité Windows locaux nécessaires pour une installation de AppFabric composée d'un seul serveur. Si vous utilisez AppFabric sur plusieurs serveurs, vous devez créer manuellement les groupes de domaine Windows puis les affecter aux groupes de sécurité Windows adéquats afin que ce serveur puisse administrer l'installation de AppFabric à distance. En tant qu'administrateur, vous devez créer des groupes de domaine en tant que manifestations physiques des rôles de sécurité conceptuels Administrateurs de serveur d'applications et Observateurs de serveur d'applications (c'est-à-dire DOMAIN\MyAppFabricAdmins et DOMAIN\MyAppFabricObservers). Vous pouvez ensuite affecter ces comptes de domaine aux groupes LOCAL\AS_Administrators et LOCAL\AS_Observers sur tous les ordinateurs exécutant AppFabric dans le domaine.

Modèle de sécurité pour les scripts personnalisés Windows PowerShell et les cmdlets d'AppFabric

AppFabric ne fournit pas un nouveau modèle de sécurité pour les scripts personnalisés ou les nombreuses cmdlets Windows PowerShell contenus dans cette version de AppFabric. Tout comme d'autres aspects de son modèle de sécurité, AppFabric exploite les modèles de sécurité existants au sein de sa technologie de prise en charge. Dans ce cas, AppFabric utilise le modèle de sécurité de Windows PowerShell pour appliquer la sécurité aux scripts personnalisés et aux cmdlets AppFabric précompilées.

Lorsqu'un script Windows PowerShell de AppFabric est exécuté, il fonctionne en utilisant l'identité du processus d'hébergement. Cela signifie que l'entité de sécurité de l'utilisateur exécutant la cmdlet est transmise comme ID de processus. Il n'existe aucun moyen d'utiliser l'emprunt d'identité pour exécuter la cmdlet dans un contexte de sécurité différent de celui de l'utilisateur qui exécute le processus d'hébergement.

Bien que vous puissiez exécuter les commandes Windows PowerShell par défaut de manière interactive, l'exécution des scripts Windows PowerShell est désactivée par défaut pour des raisons de sécurité. Vous devez d'abord activer cette fonctionnalité via la stratégie de groupe d'exécution de script dans Windows PowerShell pour que les scripts puissent être exécutés.

Les scripts Windows PowerShell fournis avec AppFabric sont signés numériquement à l'aide d'un certificat acquis auprès d'une autorité de certification. Ceci permet de protéger l'intégrité du package. Grâce à l'utilisation d'algorithmes de chiffrement de clé publique et de hachage unidirectionnel, le processus de signature garantit que les modifications apportées à un package après qu'il a été signé par son auteur sont détectées et l'exécution du script bloquée. Vous pouvez également utiliser les signatures numériques pour vous assurer que l'entité signée provient bien de la personne tierce qui prétend l'avoir créée. Une alternative simple et moins coûteuse consiste à utiliser une autorité de certification locale et un serveur de certificats Microsoft afin de générer un certificat auto-signé. Vous pouvez ensuite améliorer la protection d'un certificat à l'aide du chiffrement de clé privée.

securitySécurité Remarque
La stratégie d'approbation minimale consiste à signer un package de script Windows PowerShell par l'intermédiaire d'une autorité de certification. Un package signé en local est approuvé sur un système local mais ne l'est pas sur des systèmes externes.

Gestion des identités fédérées et authentification unique (SSO)

Les systèmes d'authentification fédérée sont également connus sous l'appellation de systèmes à authentification unique via le Web. Ils fonctionnent au-delà des frontières de l'organisation et relient les processus utilisant des technologies, des stockages d'identités, des approches de sécurité et des modèles de programmation distincts. Grâce aux services ADFS (Active Directory Federation Services), les employés d'une entreprise peuvent utiliser leur compte Active Directory pour accéder à des serveurs hébergés par une autre entreprise. Ces services établissent une relation d'approbation entre les deux entreprises et permettent aux utilisateurs finaux d'utiliser un mode de connexion unique (SSO) et fluide. Les organisations peuvent ainsi partager des informations sur l'identité d'un utilisateur en toute sécurité.

Une application HTTP gérée par AppFabric est dans bien des cas une simple application IIS. Si vous devez intégrer une solution de gestion des identités fédérées et l'authentification SSO de Web dans votre application, vous pouvez utiliser les services ADFS comme vous les utiliseriez pour une application IIS. Ces services mappent le compte de connexion d'une application avec un compte de domaine, puis l'authentifient dans IIS à l'aide de ce compte de domaine.

Étant donné que .NET Framework 4 fait appel au service WCF et à son modèle de sécurité pour établir la communication entre ses services gérés et leurs clients, le modèle IIS traditionnel de prise en charge des applications HTTP s'étend dorénavant au-delà du protocole HTTP. Si vous utilisez le protocole HTTP sans l'authentification de transport, ou avec une application non-HTTP, utilisez l'interface graphique de programmation de votre service afin d'implémenter le traitement des revendications d'identité. Une application prenant en charge les revendications utilise les revendications figurant dans un jeton de sécurité ADFS pour prendre des décisions en matière d'authentification et autoriser des personnalisations d'application supplémentaires À l'instar des services ADFS, vous devez assimiler la manière dont fonctionne le traitement des revendications d'identité avec une application IIS afin d'intégrer le traitement des revendications dans votre application.

Dans cette section

Voir aussi

Autres ressources

WF Security Pack CTP

  2011-12-05