Preuve
.gif "Remarque importante") 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. |
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