Partager via


Preuve

Remarque importanteImportant

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.

La preuve est l'information que le Common Language Runtime utilise pour prendre des décisions fondées sur la stratégie de sécurité. La preuve indique au runtime que le code possède une caractéristique particulière. Les formes de preuve habituelles incluent les signatures numériques et l'emplacement d'origine du code, mais la preuve peut aussi être conçue de manière personnalisée pour représenter d'autres informations significatives pour l'application. Les assemblys et les domaines d'applications reçoivent des autorisations sur base de la preuve.

Le tableau suivant indique les types de preuve habituels qu'un hôte peut présenter au runtime.

Preuve

Description

Répertoire d'application

Répertoire d'installation de l'application.

Hachage

Hachage de chiffrement tel que SHA1.

Éditeur

Signature d'éditeur de logiciel ; c'est-à-dire le signataire Authenticode du code.

Site

Site d'origine, tel que https://www.microsoft.com/france.

Nom fort

Nom fort d'un point de vue du chiffrement de l'assembly.

URL

URL d'origine.

Zone

Zone d'origine, telle que la zone Internet.

Outre les formes de preuve énumérées dans le tableau, une preuve définie par l'application ou par le système peut aussi être présentée au runtime. Les hôtes de domaine d'application de confiance peuvent présenter une preuve à propos d'un assembly ou d'un domaine d'application au runtime. Le runtime utilise cette information pour évaluer la stratégie d'entreprise, de l'ordinateur et de l'utilisateur (en plus d'une stratégie de domaine d'application pour les assemblys, si la définition de l'hôte du domaine d'application de confiance le prévoit) et retourner le jeu d'autorisations à octroyer à l'assembly ou au domaine d'application. Si l'hôte du domaine d'application de confiance n'a pas l'autorisation de fournir des preuves, l'assembly ou le domaine d'application reçoit les autorisations qui ont été octroyées à l'hôte.

Le runtime reçoit la preuve concernant les assemblys des hôtes de domaine d'application de confiance ou directement du programme de chargement. Certaines preuves, telles que l'origine du code, proviennent de l'hôte de domaine d'application de confiance car seul cet hôte connaît cette information. Les hôtes de domaine d'application de confiance peuvent substituer la preuve fournie par le programme de chargement et fournir leur propre preuve.

D'autres preuves, telles que la signature numérique d'un assembly, sont inhérentes au code lui-même et peuvent provenir du programme de chargement ou d'un hôte de domaine d'application de confiance. En règle générale, le runtime valide la signature numérique de chaque assembly lors du chargement du code. Si la signature numérique est valide, l'hôte du domaine d'application de confiance passe l'information comme preuve au mécanisme de la stratégie d'exécution. En outre, un assembly ou un hôte de domaine d'application de confiance peut fournir une preuve personnalisée comme une ressource faisant partie de l'assembly. Les administrateurs et les développeurs peuvent définir une preuve personnalisée et étendre la stratégie de sécurité à sa reconnaissance et à son utilisation.

Le mécanisme de stratégie du runtime utilise la preuve de l'hôte du domaine d'application de confiance et de l'assembly pour déterminer l'appartenance (membership) d'un fragment de code à un groupe de codes.

Voir aussi

Concepts

Hôtes de domaine d'application

Groupes de codes

Autres ressources

Gestion de la stratégie de sécurité