Vue d'ensemble de l'administration de stratégie de sécurité

Article
08/10/2011

Important
Dans le .NET Framework version 4, le common language runtime (CLR) cesse de fournir des stratégies de sécurité pour les ordinateurs.Microsoft recommande l'utilisation des stratégies de restriction logicielles Windows à la place de la stratégie de sécurité CLR.Les informations contenues dans cette rubrique s'appliquent au .NET Framework versions 3.5 et antérieures ; elles ne s'appliquent pas aux versions 4 et ultérieures.Pour plus d'informations sur cette modification et d'autres modifications, consultez Modifications de sécurité dans le .NET Framework 4.

Dans le .NET Framework version 4, le common language runtime (CLR) cesse de fournir des stratégies de sécurité pour les ordinateurs.Microsoft recommande l'utilisation des stratégies de restriction logicielles Windows à la place de la stratégie de sécurité CLR.Les informations contenues dans cette rubrique s'appliquent au .NET Framework versions 3.5 et antérieures ; elles ne s'appliquent pas aux versions 4 et ultérieures.Pour plus d'informations sur cette modification et d'autres modifications, consultez Modifications de sécurité dans le .NET Framework 4.

Le système de sécurité .NET Framework est régi par un ensemble de règles configurable appelé stratégie de sécurité. Cette stratégie permet à l'utilisateur final ou à l'administrateur d'adapter les paramètres qui déterminent les ressources auxquelles le code peut accéder et de choisir en fin de compte le code qui est autorisé à s'exécuter.

Par exemple, supposons que vous soyez un administrateur au sein d'une entreprise et que vous ne fassiez pas confiance à un logiciel provenant d'une société particulière. Cette société produit peut-être un logiciel que les salariés trouvent divertissant, mais qui contribue à l'accroissement du trafic réseau ou rend les postes de travail instables. Vous pouvez définir une stratégie de sécurité de niveau entreprise qui restreint l'accès dont le logiciel doté d'un nom fort de chiffrement particulier (un identificateur unique d'un programme) dispose pour vos ressources informatiques. Vous pouvez également définir une stratégie qui empêche complètement le logiciel de cet éditeur de s'exécuter.

Cette rubrique contient une vue d'ensemble de l'administration de stratégie de sécurité. Pour plus d'informations, consultez Gestion de la stratégie de sécurité.

Preuve, groupes de codes et jeux d'autorisations

Le code destiné au Common Language Runtime est déployé dans des unités appelées assemblys. Au moment du chargement, le runtime examine chaque assembly pour y rechercher une preuve, à savoir des informations sur l'identification de l'assembly (par exemple, la signature numérique de l'auteur du code et l'emplacement d'origine du code). S'appuyant sur cette preuve, le gestionnaire de sécurité du Common Language Runtime mappe l'assembly à un groupe de codes en fonction de la stratégie de sécurité. Les groupes de codes sont définis de façon à rechercher la présence de formes spécifiques de preuves et à leur associer des jeux d'autorisations. Les assemblys appartenant à un groupe de codes reçoivent les autorisations définies par les jeux d'autorisations qui leur sont associés. Pour plus d'informations sur les preuves, les groupes de codes et les jeux d'autorisations, consultez Modèle de stratégie de sécurité.

Autorisations

Les autorisations sont de simples objets qui représentent le droit d'accéder à une ressource protégée. Les autorisations sont configurables et un objet d'autorisation unique peut prendre plusieurs formes. Par exemple, FileIOPermission représente le droit de créer, de lire, d'écrire et de modifier des fichiers ou d'y accéder sur le disque dur local. Pour avoir une signification, une autorisation doit contenir des informations spécifiques sur le type d'accès qu'elle représente. Vous pouvez configurer une autorisation FileIOPermission de manière à ce qu'elle représente un droit d'accès en lecture sur un fichier particulier, un droit d'accès en lecture et en écriture sur un fichier particulier ou un droit d'accès en lecture sur les fichiers d'un répertoire entier. Les droits qu'une autorisation représente et que les assemblys reçoivent sont entièrement configurables par l'administrateur de l'ordinateur. Si les applications peuvent créer et configurer des objets d'autorisation à l'instar de tout autre objet, seule la stratégie de sécurité peut accorder une autorisation à une application. Les administrateurs contrôlent en fin de compte l'octroi des autorisations. Pour obtenir une liste d'autorisations courantes, consultez Autorisations d'accès du code.

Niveaux de stratégie de sécurité

Il existe quatre niveaux de stratégie de sécurité définis par le modèle de sécurité, qui correspondent aux différents scénarios d'administration et d'hébergement. Le tableau suivant décrit chaque niveau. Le niveau de stratégie d'entreprise est le plus haut et le niveau de domaine d'application est le plus bas.

Niveau de stratégie	Description
Stratégie d'entreprise	Défini par les administrateurs d'entreprise qui déterminent la stratégie pour les domaines d'entreprise.
Stratégie de l'ordinateur	Défini par les administrateurs d'ordinateur qui déterminent la stratégie pour un ordinateur.
Stratégie de l'utilisateur	Défini par les utilisateurs qui déterminent la stratégie d'un compte d'ouverture de session unique.
Stratégie de domaine d'application	Défini par l'hôte du runtime (toute application qui héberge le Common Language Runtime) pour la détermination de la stratégie au moment du chargement. Ce niveau ne peut pas être administré.

Chaque niveau de stratégie se compose d'une hiérarchie de groupes de codes. Les administrateurs de chaque niveau de stratégie peuvent créer leurs propres groupes de codes et leur associer des jeux d'autorisations. Au moment du chargement, le système de sécurité d'accès du code examine tous les niveaux de stratégie et l'autorisation qui est ensuite accordée se situe à l'intersection de toutes les autorisations permises à chaque niveau. Les administrateurs d'un niveau de stratégie inférieur ne peuvent pas assouplir une décision de stratégie prise à un niveau supérieur, mais ils peuvent renforcer la stratégie autant qu'ils le souhaitent. La stratégie de sécurité par défaut correspond au niveau de stratégie de l'ordinateur.

Les paramètres de sécurité par défaut sont les suivants :

Les niveaux de l'utilisateur et d'entreprise sont illimités.
Le niveau de l'ordinateur contient les paramètres de stratégie spécifiques et des restrictions.
Les paramètres définis par les trois niveaux constituent des paramètres par défaut.

Notez que les niveaux illimités de l'utilisateur et d'entreprise ne se traduisent pas par l'octroi d'autorisations illimitées à un assembly. Dans la mesure où le niveau de l'ordinateur définit plusieurs restrictions et que les trois niveaux sont considérés comme formant un tout, l'autorisation accordée ensuite n'est pas une autorisation illimitée. Pour plus d'informations, consultez Modèle de stratégie de sécurité.

Mappage de groupes de codes à des jeux d'autorisations

Vous administrez la stratégie en mappant des groupes de codes à des jeux d'autorisations aux niveaux de stratégie dont vous êtes responsable.

Les groupes de codes contiennent une condition d'appartenance, une association de jeu d'autorisations et des attributs de groupe de codes. La preuve qu'un assembly présente au runtime est comparée à la condition d'appartenance que vous spécifiez pour un groupe de codes. Si un assembly fournit une preuve correspondant à la condition d'appartenance, l'accès au groupe de codes lui est ouvert. Les administrateurs identifient et classent dans les assemblys dans des groupes de codes en spécifiant des conditions d'appartenance, et en assignant des jeux d'autorisations à ces groupes de codes. Facultativement, les attributs de groupe de codes peuvent être utilisés pour spécifier qu'aucun niveau de stratégie en dessous du niveau en cours ou qu'aucun groupe de codes en dehors de celui en cours ne doit être pris en compte pour l'assignation d'une autorisation.

Les types de preuve intégrée suivants peuvent être utilisés en tant que conditions d'appartenance :

Le répertoire d'installation de l'application
Le hachage de chiffrement de l'assembly
La signature numérique de l'éditeur de l'assembly
Le site d'où provient l'assembly
Le nom fort de chiffrement de l'assembly
L'URL d'origine de l'assembly
La zone d'où provient l'assembly

Vous pouvez accroître ou réduire les autorisations accordées aux assemblys sur la base de toute combinaison de ces conditions d'appartenance. Dans la mesure où des conditions d'appartenance personnalisées peuvent être créées, la liste précédente ne répertorie pas toutes les possibilités. Pour plus d'informations, consultez Preuve.