Code transparent de sécurité (security-transparent)
La sécurité implique trois composants interactifs : l'utilisation de bacs à sable (sandbox), les autorisations et la contrainte de mise en conformité. L'utilisation de bacs à sable fait référence à la création de domaines isolés où du code est traité comme du code d'un niveau de confiance totale et d'autre code est soumis aux autorisations du jeu d'autorisations du bac à sable (sandbox). Le code d'application qui s'exécute dans le jeu d'autorisations du bac à sable est considéré comme transparent. Autrement dit, il ne peut pas exécuter d'opérations susceptibles d'affecter la sécurité. Le jeu d'autorisations du bac à sable est déterminé par preuve. La preuve identifie les autorisations spécifiques requises par les bacs à sable et les genres de bacs à sable pouvant être créés. La contrainte de mise en conformité consiste à autoriser le code transparent à s'exécuter uniquement dans son jeu d'autorisations.
.gif "Remarque importante") Important |
|---|
La stratégie de sécurité était un élément clé des versions antérieures du .NET Framework.À partir du .NET Framework version 4, la stratégie de sécurité est obsolète.L'élimination de la stratégie de sécurité est distincte de la transparence de sécurité.Pour plus d'informations sur les effets de cette modification et obtenir de conseils d'atténuation, consultez Compatibilité de la stratégie de sécurité d'accès du code et migration. |
Cette rubrique décrit le modèle de transparence plus en détail. Elle contient les sections suivantes :
Objectif du modèle de transparence
Spécification du niveau de transparence
Contrainte de mise en conformité de transparence
Objectif du modèle de transparence
La transparence est un mécanisme de contrainte de mise en conformité qui distingue le code qui s'exécute dans le cadre de l'application du code qui s'exécute dans le cadre de l'infrastructure. La transparence établit un cloisonnement entre le code qui peut réaliser des actions privilégiées (code critique), notamment appeler le code natif, et le code qui ne le peut pas (code transparent). Le code transparent peut exécuter des commandes dans les limites de son jeu d'autorisations, mais il ne peut pas exécuter, dériver de ou contenir de code critique.
L'objectif principal de la contrainte de mise en conformité de transparence est de fournir un mécanisme simple et efficace pour isoler différents groupes de code en fonction de privilèges. Dans le contexte du modèle de bac à sable, ces groupes de privilèges ont un niveau de confiance totale (autrement dit, non restreint) ou de confiance partielle (autrement dit, limité au jeu d'autorisations accordé au bac à sable).
| Important |
|---|
Le modèle de transparence surpasse la sécurité d'accès du code.La transparence est mise en application par le compilateur juste-à-temps et reste en effet indépendamment du jeu d'autorisations d'un assembly, notamment la confiance totale. |
La transparence a été introduite dans le .NET Framework version 2.0 pour simplifier le modèle de sécurité et pour simplifier l'écriture et le déploiement de bibliothèques et d'applications sécurisées. Le code transparent est également utilisé dans Microsoft Silverlight, pour simplifier le développement d'applications de confiance partielle.
.gif "Remarque") Remarque |
|---|
Lorsque vous développez une application de confiance partielle, vous devez être informé des besoins d'autorisation de vos hôtes cibles.Vous pouvez développer une application qui utilise des ressources qui ne sont pas autorisées par certains hôtes.Cette application sera compilée sans erreur, mais échouera lorsqu'elle sera chargée dans l'environnement hébergé.Si vous avez développé votre application à l'aide de Visual Studio, vous pouvez activer le débogage avec une confiance partielle ou dans un jeu d'autorisations restreintes depuis l'environnement de développement.Pour plus d'informations, consultez Comment : déboguer une application ClickOnce avec des autorisations restreintes.La fonctionnalité Calculer les autorisations fournie pour les applications ClickOnce est également disponible pour toute application de confiance partielle. |
Retour au début
Spécification du niveau de transparence
L'attribut SecurityRulesAttribute au niveau de l'assembly sélectionne explicitement les règles SecurityRuleSet suivies par l'assembly. Les règles sont organisées sous un système de niveaux numérique, où les niveaux supérieurs signifient une contrainte de mise en conformité plus stricte des règles de sécurité.
Les niveaux sont déterminés comme suit :
Niveau 2 (Level2) – règles de transparence du .NET Framework 4.
Niveau 1 (Level1) – règles de transparence du .NET Framework 2.0.
La principale différence entre les deux niveaux de transparence est que le niveau 1 n'applique pas les règles de transparence pour les appels depuis l'extérieur de l'assembly et est destiné uniquement à la compatibilité.
| Important |
|---|
Vous devez spécifier la transparence de niveau 1 pour la compatibilité uniquement, c'est-à-dire, spécifier le niveau 1 uniquement pour le code développé avec le .NET Framework 3.5 ou version antérieure qui utilise l'attribut AllowPartiallyTrustedCallersAttribute ou n'utilise pas le modèle de transparence.Par exemple, utilisez la transparence de niveau 1 pour les assemblys .NET Framework 2.0 qui autorisent les appels d'appelants d'un niveau de confiance partiel.Pour le code développé pour le .NET Framework 4, utilisez toujours la transparence de niveau 2. |
Transparence de niveau 2
La transparence de niveau 2 a été introduite dans le .NET Framework version 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, indépendamment des autorisations dont il bénéficie (notamment la confiance totale), peut appeler uniquement un autre code transparent ou du code critique sécurisé. Si le code est d'un niveau de confiance partiel, il peut uniquement effectuer les actions autorisées par le jeu d'autorisations du domaine. Le code transparent ne peut pas effectuer les opérations suivantes :
Effectuer une opération Assert ou une élévation de privilèges.
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.
Transparence de niveau 1
Le modèle de transparence de niveau 1 a été introduit dans le .NET Framework version 2.0 pour permettre aux développeurs de réduire la quantité de code soumis à un audit de sécurité. Bien que la transparence de niveau 1 était publiquement disponible dans version 2.0, elle a été principalement utilisée uniquement dans Microsoft dans des objectifs d'audits de sécurité. Grâce aux annotations, les développeurs peuvent déclarer les types et les membres qui peuvent exécuter des élévations de sécurité et d'autres actions approuvées (critiques de sécurité) et ceux qui ne le peuvent pas (transparents de sécurité). Le code identifié en tant que transparent ne nécessite pas un niveau élevé d'audit de sécurité. La transparence de niveau 1 indique que la contrainte de mise en conformité de transparence est limitée à l'assembly. En d'autres termes, tous les types ou membres publics identifiés comme critiques de sécurité sont critiques de sécurité uniquement dans l'assembly. Si vous souhaitez appliquer la sécurité pour ces types et membres lorsqu'ils sont appelés depuis l'extérieur de l'assembly, vous devez utiliser des demandes de liaison pour bénéficier d'une confiance totale. Si vous ne le faites pas, les types et membres critiques de sécurité visibles publiquement sont traités comme s'ils étaient critiques sécurisés et peuvent être appelés par du code d'un niveau de confiance partiel à l'extérieur de l'assembly.
Le modèle de transparence de niveau 1 présente les limitations suivantes :
Les types et membres critiques de sécurité qui sont publics sont accessibles à partir de code transparent de sécurité.
Les annotations de transparence sont mises en application uniquement dans un assembly.
Les types et membres critiques de sécurité doivent utiliser des demandes de liaison pour mettre en application la sécurité des appels depuis l'extérieur de l'assembly.
Les règles d'héritage ne sont pas mises en application.
Il est possible que du code transparent ait des effets négatifs lorsqu'il est exécuté avec une confiance totale.
Retour au début
Contrainte de mise en conformité de transparence
Les règles de transparence ne sont pas mises en application tant que la transparence n'est pas calculée. À ce moment, une InvalidOperationException est levée si une règle de transparence est enfreinte. Le moment du calcul de la transparence dépend de plusieurs facteurs et ne peut pas être prédit. Elle est calculée aussi tard que possible. Dans le .NET Framework 4, le calcul de transparence au niveau de l'assembly se produit plus tôt qu'il ne le fait dans le .NET Framework 2.0. La seule garantie est que le calcul de transparence se produira avant d'être requis. Ceci ressemble à la façon dont le compilateur juste-à-temps (JIT) peut modifier le point lorsqu'une méthode est compilée et que des erreurs sont détectées dans cette méthode. Le calcul de transparence est invisible si votre code n'a pas d'erreurs de transparence.
Retour au début