Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.

Traduction

Source

Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Code transparent de sécurité, niveau 2

.NET Framework 4.5

Autres versions

.NET Framework 4

La transparence de niveau 2 a été introduite dans le .NET Framework 4. Les trois composants de ce modèle sont le code transparent, le code critique sécurisé et le code critique de sécurité.

Le code transparent, notamment le code qui s'exécute avec une confiance totale, peut uniquement appeler un autre code transparent ou un code critique sécurisé. Il peut uniquement exécuter les actions autorisées par le jeu d'autorisations (s'il en existe un) de confiance partielle du domaine. Le code transparent ne peut pas effectuer les opérations suivantes :
- Effectuer une Assert or élévation de privilège.
- Contenir du code non sécurisé or non vérifiable.
- Appeler directement du code critique.
- Appeler du code natif ou du code possédant l'attribut SuppressUnmanagedCodeSecurityAttribute.
- Appeler un membre qui est protégé par un LinkDemand.
- Hériter de types critiques.
De plus, les méthodes transparentes ne peuvent pas substituer de méthodes virtuelles critiques ou implémenter des méthodes d'interface critiques.
Le code critique sécurisé a un niveau de confiance totale mais peut être appelé par du code transparent. Il expose une surface limitée de code de confiance totale. Les vérifications d'exactitude et de sécurité ont lieu dans le code critique sécurisé.
Le code critique de sécurité peut appeler tout code et a un niveau de confiance totale, mais il ne peut pas être appelé par du code transparent.

Cette rubrique contient les sections suivantes :

Comportements et exemples d'utilisation
Modèles de substitution
Règles d'héritage
Règles et informations supplémentaires

Comportements et exemples d'utilisation

Pour spécifier des règles .NET Framework 4 (transparence de niveau 2), utilisez l'annotation suivante pour un assembly :

[assembly: SecurityRules(SecurityRuleSet.Level2)]

Pour verrouiller les règles .NET Framework 2.0 (transparence de niveau 1), utilisez l'annotation suivante :

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Si vous n'annotez pas d'assembly, les règles .NET Framework 4 sont utilisées par défaut. Toutefois, la meilleure pratique consiste à utiliser l'attribut SecurityRulesAttribute au lieu de dépendre de la valeur par défaut.

Annotation au niveau de l'assembly

Les règles suivantes s'appliquent à l'utilisation d'attributs au niveau de l'assembly :

Aucun attribut : si vous ne spécifiez pas d'attributs, le runtime interprète tout le code comme étant critique de sécurité, sauf si cet état entre en violation avec une règle d'héritage (par exemple, lors de la substitution ou de l'implémentation d'une méthode d'interface ou virtuelle transparente). Dans ces cas, les méthodes sont critiques sécurisées. Lorsque aucun attribut n'est spécifié, le Common Language Runtime détermine les règles de transparence à votre place.
SecurityTransparent : tout le code est transparent. L'assembly dans son ensemble ne fera rien de privilégié ou de non sécurisé.
SecurityCritical : tout le code présenté par les types de cet assembly est critique ; le reste du code est transparent. Ce scénario est similaire à la non-spécification d'attributs. Toutefois, le Common Language Runtime ne détermine pas automatiquement les règles de transparence. Par exemple, si vous substituez une méthode virtuelle ou abstraite ou implémentez une méthode d'interface, par défaut, cette méthode est transparente. Vous devez annoter explicitement la méthode comme SecurityCritical ou SecuritySafeCritical ; sinon, une exception TypeLoadException est levée au moment du chargement. Cette règle s'applique également lorsque la classe de base et la classe dérivée figurent toutes deux dans le même assembly.
AllowPartiallyTrustedCallers (niveau 2 uniquement) : tout le code est transparent par défaut. Toutefois, certains types et membres spécifiques peuvent avoir d'autres attributs.

Le tableau suivant compare le comportement de niveau d'assembly pour le niveau 2 avec le niveau 1.

Attribut d'assembly	Niveau 2	Niveau 1
Aucun attribut sur un assembly partiellement fiable	Les types et membres sont transparents par défaut, mais peuvent être critiques de sécurité ou critiques sécurisés.	Tous les types et membres sont transparents.
Pas d'attribut	Lorsque aucun attribut n'est spécifié, le Common Language Runtime détermine les règles de transparence à votre place. Tous les types et membres sont critiques de sécurité, sauf lorsque cet état entre en violation avec une règle d'héritage.	Sur un assembly d'un niveau de confiance totale (dans le Global Assembly Cache ou identifié en tant que fiable dans le AppDomain), tous les types sont transparents et tous les membres sont critiques sécurisés.
SecurityTransparent	Tous les types et membres sont transparents.	Tous les types et membres sont transparents.
SecurityCritical(SecurityCriticalScope.Everything)	Non applicable.	Tous les types et membres sont critique de sécurité.
SecurityCritical	Tout le code présenté par les types de cet assembly est critique ; le reste du code est transparent. Si vous substituez une méthode virtuelle ou abstraite ou implémentez une méthode d'interface, vous devez annoter explicitement la méthode comme SecurityCritical ou SecuritySafeCritical.	L'ensemble du code est transparent par défaut. Toutefois, certains types et membres spécifiques peuvent avoir d'autres attributs.

Annotation de type et de membre

Les attributs de sécurité appliqués à un type s'appliquent également aux membres présentés par le type. Toutefois, ils ne s'appliquent pas aux substitutions virtuelles ou abstraites de la classe de base ou des implémentations d'interface. Les règles suivantes s'appliquent à l'utilisation d'attributs au niveau des types et des membres :

SecurityCritical : le type ou le membre est critique et peut être appelé uniquement par du code de confiance totale. Les méthodes introduites dans un type critique de sécurité sont critiques.

Important
Les méthodes virtuelles et abstraites présentées dans des interfaces ou des classes de base, et substituées ou implémentées dans une classe critique de sécurité, sont transparentes par défaut. Elles doivent être identifiées comme SecuritySafeCritical ou SecurityCritical.

SecuritySafeCritical : le type ou le membre est critique sécurisé. Toutefois, le type ou le membre peut être appelé à partir de code transparent (partiellement approuvé) et a les mêmes capacité que tout autre code critique. Le code doit être audité dans le cadre de la sécurité.

Retour au début

Modèles de substitution

Le tableau suivant indique les substitutions de méthodes autorisées pour la transparence de niveau 2.

Membre d'interface/virtuel de base	Substitution/interface
Transparent	Transparent
Transparent	SafeCritical
SafeCritical	Transparent
SafeCritical	SafeCritical
Critical	Critical

Retour au début

Règles d'héritage

Dans cette section, l'ordre suivant est assigné au code Transparent, Critical et SafeCritical en fonction de l'accès et des fonctionnalités :

Transparent < SafeCritical < Critical

Règles pour les types : de gauche à droite, l'accès devient plus restrictif. Les types dérivés doivent être au moins aussi restrictifs que le type de base.
Règles pour les méthodes : les méthodes dérivées ne peuvent pas changer l'accessibilité depuis la méthode de base. Pour le comportement par défaut, toutes les méthodes dérivées qui ne sont pas annotées sont Transparent. Les dérivés des types critiques lèvent qu'une exception si la méthode substituée n'est pas annotée explicitement en tant que SecurityCritical.

Le tableau suivant indique les modèles d'héritage de type autorisés.

Classe de base	La classe dérivée peut être
Transparent	Transparent
Transparent	SafeCritical
Transparent	Critical
SafeCritical	SafeCritical
SafeCritical	Critical
Critical	Critical

Le tableau suivant indique les modèles d'héritage de type non autorisés.

Classe de base	La classe dérivée ne peut pas être
SafeCritical	Transparent
Critical	Transparent
Critical	SafeCritical

Le tableau suivant indique les modèles d'héritage de méthode autorisés.

Méthode de base	La méthode dérivée peut être
Transparent	Transparent
Transparent	SafeCritical
SafeCritical	Transparent
SafeCritical	SafeCritical
Critical	Critical

Le tableau suivant indique les modèles d'héritage de méthode non autorisés.

Méthode de base	La méthode dérivée ne peut pas être
Transparent	Critical
SafeCritical	Critical
Critical	Transparent
Critical	SafeCritical

Remarque
Ces règles d'héritage s'appliquent aux types et membres de niveau 2. Les types des assemblys de niveau 1 peuvent hériter des types et membres critiques de sécurité de niveau 2. Par conséquent, les types et membres de niveau 2 doivent disposer de demandes d'héritage séparées pour les héritiers de niveau 1.

Retour au début

Règles et informations supplémentaires

Prise en charge de LinkDemand

Le modèle de transparence de niveau 2 remplace le LinkDemand par l'attribut SecurityCriticalAttribute. Dans le code hérité (niveau 1), un LinkDemand est automatiquement traité comme un Demand.

Réflexion

L'appel d'une méthode critique ou la lecture d'un champ critique déclenche une demande de confiance totale (comme si vous appeliez une méthode ou un champ privé(e)). Par conséquent, le code de confiance totale peut appeler une méthode critique, tandis que le code de confiance partielle ne peut pas.

Les propriétés suivantes ont été ajoutées à l'espace de noms d' System.Reflection pour déterminer si le type, la méthode, ou le champ est SecurityCritical, SecuritySafeCritical, ou SecurityTransparent: IsSecurityCritical, IsSecuritySafeCritical, et IsSecurityTransparent. Utilisez ces propriétés pour déterminer la transparence à l'aide de la réflexion au lieu de rechercher la présence de l'attribut. Les règles de transparence sont complexes, et la recherche de l'attribut peut ne pas être suffisante.

Remarque
Une méthode d' SafeCritical retourne true pour IsSecurityCriticalet IsSecuritySafeCritical, car SafeCritical est en effet critique (il a les mêmes fonctionnalités que le code critique, mais il peut être appelé à partir de code transparent).

Les méthodes dynamiques héritent de la transparence des modules auxquels elles sont attachées. Elles n'héritent pas de la transparence du type (si elles sont attachées à un type).

Ignorer la vérification en cas de confiance totale

Vous pouvez ignorer la vérification pour les assemblys transparents d'un niveau de confiance totale en affectant à la propriété SkipVerificationInFullTrust la valeur true dans l'attribut SecurityRulesAttribute :

[assembly: SecurityRules(SecurityRuleSet.Level2, SkipVerificationInFullTrust = true)]

La propriété SkipVerificationInFullTrust a la valeur false par défaut. Elle doit donc avoir la valeur true pour ignorer la vérification. Ceci doit être fait à des fins d'optimisation uniquement. Vous devez vous assurer que le code transparent de l'assembly est vérifiable à l'aide de l'option transparent de l'outil PEVerify.

Retour au début

Voir aussi

Concepts

Code transparent de sécurité, niveau 1

Modifications de sécurité dans le .NET Framework

Cela vous a-t-il été utile ? Oui Non

Manque de précision

Pas suffisamment approfondi

Besoin d'exemples de code supplémentaires

La traduction a besoin d'être améliorée.

(1500 caractères restants)

Ajouts de la communauté

AJOUTER

Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,

Confidentialité