Utilisation de la stratégie de restriction logicielle dans COM+

L’utilisation correcte de la stratégie de restriction logicielle peut rendre votre entreprise plus agile, car elle fournit une infrastructure proactive pour prévenir les problèmes, plutôt qu’une infrastructure réactive qui s’appuie sur l’alternative coûteuse de la restauration d’un système après qu’un problème s’est produit. La stratégie de restriction logicielle a été introduite avec la publication de Microsoft Windows XP pour aider à protéger les systèmes contre du code inconnu et éventuellement dangereux. La stratégie de restriction fournit un mécanisme dans lequel seul le code approuvé dispose d’un accès illimité aux privilèges d’un utilisateur. Le code inconnu, qui peut contenir des virus ou du code en conflit avec les programmes actuellement installés, est autorisé à s’exécuter uniquement dans un environnement contraint (souvent appelé bac à sable) où il n’est pas autorisé à accéder à des privilèges utilisateur sensibles à la sécurité.

La stratégie de restriction logicielle dépend de l’attribution de niveaux de confiance au code qui peut s’exécuter sur un système. Actuellement, deux niveaux de confiance existent : Non restreint et Non autorisé. Le code qui a un niveau de confiance illimité dispose d’un accès illimité aux privilèges de l’utilisateur. Ce niveau de confiance doit donc être appliqué uniquement au code entièrement approuvé. Le code avec un niveau de confiance Non autorisé n’est pas autorisé à accéder à des privilèges utilisateur sensibles à la sécurité et peut s’exécuter uniquement dans un bac à sable qui permet d’empêcher le code non autorisé de charger le code non autorisé dans son espace d’adressage.

La configuration de la stratégie de restriction logicielle pour un système s’effectue par le biais de l’outil d’administration Stratégie de sécurité locale, tandis que la configuration de la stratégie de restriction des applications COM+ individuelles est effectuée par programmation ou par le biais de l’outil d’administration Services de composants. Si le niveau d’approbation de la stratégie de restriction n’est pas spécifié pour une application COM+, les paramètres à l’échelle du système sont utilisés pour déterminer le niveau de confiance de l’application. Les paramètres de stratégie de restriction COM+ doivent être soigneusement coordonnés avec les paramètres à l’échelle du système, car une application COM+ qui a un niveau de confiance non restreint peut charger uniquement les composants avec un niveau de confiance non restreint ; Une application COM+ non autorisée peut charger des composants avec n’importe quel niveau de confiance, mais ne peut pas accéder à tous les privilèges de l’utilisateur.

En plus des niveaux d’approbation de stratégie de restriction logicielle des applications COM+ individuelles, deux autres propriétés déterminent comment la stratégie de restriction est utilisée pour toutes les applications COM+. Si SRPRunningObjectChecks est activé, les tentatives de connexion aux objets en cours d’exécution sont vérifiées pour les niveaux de confiance appropriés. L’objet en cours d’exécution ne peut pas avoir un niveau de confiance moins strict que l’objet client. Par exemple, l’objet en cours d’exécution ne peut pas avoir un niveau de confiance non autorisé si l’objet client a un niveau de confiance non restreint.

La deuxième propriété détermine comment la stratégie de restriction logicielle gère les connexions activate-as-activator. Si SRPActivateAsActivatorChecks est activé, le niveau de confiance configuré pour l’objet serveur est comparé au niveau d’approbation de l’objet client et le niveau de confiance plus strict est utilisé pour exécuter l’objet serveur. Si SRPActivateAsActivatorChecks n’est pas activé, l’objet serveur s’exécute avec le niveau d’approbation de l’objet client, quel que soit le niveau de confiance avec lequel il a été configuré. Par défaut, SRPRunningObjectChecks et SRPActivateAsActivatorChecks sont activés.

Rubriques connexes

Authentification du client

Emprunt d’identité et délégation du client

Configuration de la stratégie de restriction logicielle

Sécurité des applications de bibliothèque

Sécurité des applications multiniveau

Sécurité des composants programmatiques

Administration de la sécurité basée sur les rôles