• 03/30/2017
• 6 minutes à lire
• • g
  • D
  • m
  • Y

  .

  • s
  • +8

La sécurité implique trois pièces en interaction : le sandboxing, les permissions et l’application. Le sandboxing fait référence à la pratique consistant à créer des domaines isolés où une partie du code est traitée comme entièrement fiable et où d’autres codes sont limités aux permissions de l’ensemble de subventions pour le sandbox. Le code d’application qui s’exécute dans l’ensemble d’autorisations du bac à sable est considéré comme transparent, c’est-à-dire qu’il ne peut effectuer aucune opération susceptible d’affecter la sécurité. L’ensemble d’autorisations du bac à sable est déterminé par des preuves (classe de preuves). Les preuves identifient les autorisations spécifiques requises par les bacs à sable et les types de bacs à sable qui peuvent être créés. L’application fait référence à l’autorisation du code transparent à s’exécuter uniquement dans son ensemble d’octroi.

Objectif du modèle de transparence

La transparence est un mécanisme d’application qui sépare 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 trace une barrière entre le code qui peut faire des choses privilégiées (code critique), comme l’appel du code natif, et le code qui ne le peut pas (code transparent). Le code transparent peut exécuter des commandes dans les limites de l’ensemble de permissions dans lequel il fonctionne, mais ne peut pas exécuter, dériver ou contenir du code critique.

Le but premier de l’application de la transparence est de fournir un mécanisme simple et efficace pour isoler différents groupes de code en fonction des privilèges. Dans le contexte du modèle de sandboxing, ces groupes de privilèges sont soit entièrement de confiance (c’est-à-dire non restreints), soit partiellement de confiance (c’est-à-dire restreints à l’ensemble des autorisations accordées au sandbox).

La transparence a été introduite dans le .NET Framework version 2.0 pour simplifier le modèle de sécurité, et pour faciliter 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 partiellement de confiance.

Spécifier le niveau de transparence

L’attribut SecurityRulesAttribute au niveau de l’assemblage sélectionne explicitement les règles SecurityRuleSet que l’assemblage suivra. Les règles sont organisées selon un système de niveaux numériques, où des niveaux plus élevés signifient une application plus stricte des règles de sécurité.

Les niveaux sont les suivants :

• Niveau 2 (Level2) – les règles de transparence du .NET Framework 4.

• Niveau 1 (Level1) – les 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 provenant de l’extérieur de l’assemblage et est destiné uniquement à la compatibilité.

Transparence de niveau 2

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

• Le code transparent, quelles que soient les permissions qui lui sont accordées (y compris la confiance totale), ne peut appeler que d’autres codes transparents ou du code critique pour la sécurité. Si le code est partiellement de confiance, il ne peut effectuer que les actions autorisées par l’ensemble des permissions du domaine. Le code transparent ne peut pas faire ce qui suit :

  • Exécuter une opération Assert ou une élévation de privilège.

  • Contenir du code non sûr ou non vérifiable.

  • Appeler directement du code critique.

  • Appeler du code natif ou du code ayant l’attribut SuppressUnmanagedCodeSecurityAttribute.

  • Appeler un membre qui est protégé par un LinkDemand.

  • Hériter de types critiques.

    En outre, les méthodes transparentes ne peuvent pas surcharger les méthodes virtuelles critiques ou mettre en œuvre des méthodes d’interface critiques.

• Le code critique sécurisé est entièrement fiable mais peut être appelé par du code transparent. Il expose une surface limitée de code de confiance totale. Les vérifications de correction et de sécurité se produisent dans le code sûr-critique.

• Le code sûr-critique peut appeler n’importe quel code et est entièrement de confiance, 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 qui est soumise à un audit de sécurité. Bien que la transparence de niveau 1 ait été disponible publiquement dans la version 2.0, elle était principalement utilisée uniquement au sein de Microsoft à des fins d’audit de sécurité. Grâce aux annotations, les développeurs sont en mesure de déclarer quels types et membres peuvent effectuer des élévations de sécurité et d’autres actions de confiance (sécurité critique) et lesquels ne le peuvent pas (sécurité transparente). Le code qui est identifié comme transparent ne nécessite pas un haut degré d’audit de sécurité. Le niveau 1 de transparence indique que l’application de la transparence est limitée à l’intérieur de l’assemblage. En d’autres termes, tous les types ou membres publics qui sont identifiés comme critiques en termes de sécurité le sont uniquement au sein de l’assemblage. Si vous voulez renforcer la sécurité de ces types et membres lorsqu’ils sont appelés depuis l’extérieur de l’assemblage, vous devez utiliser les demandes de lien pour la confiance totale. Si vous ne le faites pas, les types et membres critiques pour la sécurité visibles publiquement sont traités comme critiques pour la sécurité et peuvent être appelés par du code partiellement approuvé en dehors de l’assemblage.

Le modèle de transparence de niveau 1 a les limitations suivantes :

• Les types et membres critiques pour la sécurité qui sont publics sont accessibles à partir de code transparent pour la sécurité.

• Les annotations de transparence ne sont appliquées qu’à l’intérieur d’un assemblage.

• Les types et les membres critiques pour la sécurité doivent utiliser les demandes de liens pour appliquer la sécurité pour les appels provenant de l’extérieur de l’assemblage.

• Les règles d’héritage ne sont pas appliquées.

• Le potentiel existe pour que le code transparent fasse des choses nuisibles lorsqu’il est exécuté en toute confiance.

Mise en application de la transparence

Les règles de transparence ne sont pas appliquées jusqu’à ce que la transparence soit calculée. À ce moment-là, une InvalidOperationException est lancée si une règle de transparence est violée. Le moment où la transparence est calculée dépend de multiples facteurs et ne peut être prédit. Elle est calculée aussi tard que possible. Dans le .NET Framework 4, le calcul de la transparence au niveau des assemblages intervient plus tôt que dans le .NET Framework 2.0. La seule garantie est que le calcul de transparence aura lieu au moment où il sera nécessaire. Cela ressemble à la façon dont le compilateur juste-à-temps (JIT) peut changer le moment où une méthode est compilée et où toute erreur dans cette méthode est détectée. Le calcul de transparence est invisible si votre code ne comporte aucune erreur de transparence.

Voir aussi

• Code transparent pour la sécurité, niveau 1
• Code transparent pour la sécurité, niveau 2

.