Résumé des modifications de la sécurité d'accès du code
Dans le .NET Framework version 4, la sécurité d'accès du code (CAS) a subi des modifications majeures, afin de simplifier le système de sécurité. Dans les versions précédents du .NET Framework, les droits d'une application managée étaient déterminés par les règles de la stratégie de sécurité, définies sur l'ensemble de l'ordinateur pour établir des paramètres d'exécution. À partir du .NET Framework 4 :
La stratégie de sécurité n'est plus en vigueur. Les autorisations sont toujours en vigueur. Seule la stratégie de sécurité a été supprimée.
Les droits d'accès pour les applications sont déterminés selon deux facteurs : leurs autorisations (le jeu d'autorisations généré par leur domaine d'application) et leur transparence. Toutes les applications de confiance partielle sont classées en tant qu'applications transparentes. Les applications transparentes n'ont pas à se préoccuper de la sécurité. La transparence a été utilisée pour la première fois pour Microsoft Silverlight. Elle est désormais étendue à tous les environnements hébergés.
Le niveau de confiance totale est accordé aux applications intranet de bureau et locales.
.gif "Remarque importante") Important |
|---|
La suppression de la stratégie de sécurité est le principal changement apporté à CAS.CAS lui-même n'a pas été supprimé. Seul l'utilisation de la stratégie (et certaines demandes d'autorisation) a été supprimée. |
Cette rubrique offre une brève présentation des changements CAS apportés au .NET Framework 4. Pour plus d'informations, consultez Modifications de sécurité dans le .NET Framework 4.
Sandboxing et modèle d'autorisations
La liste suivante décrit le modèle d'approbation pour les applications de bureau et les applications hébergées dans le .NET Framework 4. Pour plus d'informations, consultez Modifications de sécurité dans le .NET Framework 4.
Applications de bureau. Comme dans les versions antérieures du .NET Framework, un niveau de confiance totale est accordé aux applications managées qui résident sur le bureau (à moins qu'elles aient été téléchargées à partir du Web). Il en est de même pour les applications qui résident sur des partages du réseau intranet local. Vous ne pouvez plus utiliser la stratégie pour restreindre les autorisations d'une application en fonction de son dossier sur le disque dur local.
Applications hébergées. Un jeu d'autorisations limité est accordé aux applications qui s'exécutent dans un bac à sable (sandbox, comme les applications Silverlight, par exemple). Ces autorisations déterminent les ressources de l'ordinateur auxquelles ces applications peuvent accéder (par exemple, les fichiers qu'elles sont autorisées à utiliser). Les bacs à sable permettent d'identifier les différents niveaux de confiance des assemblys dans le bac à sable : niveau de confiance partielle et niveau de confiance totale. Un jeu d'autorisations spécifique est accordé aux assemblys de confiance partielle, tel que déterminé par le domaine d'application (System.AppDomain) qui a créé le bac à sable (sandbox). Une partie du code de confiance totale des bibliothèques de confiance totale peut être appelée par du code partiellement fiable. Ce code de confiance peut appeler des ressources protégées sur l'ordinateur. Toutefois, les types et les membres de confiance totale accessibles publiquement et en mesure d'appeler des ressources protégées doivent avoir subi un audit de sécurité. Ces membres sont classés comme étant critique sécurisé, comme décrit dans la section suivante. Ils peuvent être appelés par du code de confiance partielle (transparent) et peuvent, ensuite, appeler du code critique.
Transparence de sécurité
La transparence de sécurité sépare le code de sécurité sensible du code de sécurité non sensible. Elle a été introduite dans le .NET Framework version 2.0 pour simplifier les audits de sécurité. L'opération consiste à annoter du code devant exécuter des actions de sécurité sensibles comme étant critiques de sécurité. Ainsi, tout code n'étant pas critique de sécurité (autrement dit, le code transparent) n'exigeait pas de révision approfondie. Toutefois, dans les versions antérieures du .NET Framework, la transparence était uniquement utilisée par le code de Microsoft.
Dans le .NET Framework 4, ce modèle a été étendu et les règles ont été renforcées pour que la transparence de sécurité devienne un modèle de mise en conformité. Dans ce modèle amélioré, le code de sécurité sensible qui peut être appelé par les applications de confiance partielle est plus facilement identifiable. Cela réduit encore la surface d'exposition qui doit être auditée.
Le tableau suivant indique les catégories de transparence et les attributs associés pour annoter le code.
Catégorie de sécurité |
Attribut |
Description |
|---|---|---|
Transparent |
Code dont aucune opération n'est fondamentalement de sécurité sensible. |
|
Critical |
Code qui peut tout faire, mais qui ne peut pas être appelé à partir des applications de confiance partielle. |
|
Critique de sécurité |
Code qui peut tout faire et qui peut être appelé à partir des applications de confiance partielle. Il s'agit de la couche d'échange sécurisée. Elle est destinée à exécuter les vérifications de sécurité appropriées et la validation avant d'appeler le code critique. |
Le code transparent ne peut effectuer les opérations suivantes, quelles que soient les autorisations qui lui sont accordées :
Contenir du code non vérifiable.
Utiliser l'appel de code non managé.
Effectuer des opérations Assert.
Appeler du code critique.
Dériver de code critique.
Appeler le code protégé par LinkDemand (autrement dit, le code qui est considéré comme critique).
Si votre code essaie de violer ces règles, des exceptions sont levées (même si votre code dispose d'un niveau de confiance totale). Pour plus d'informations, consultez Modifications de sécurité dans le .NET Framework 4.
Notez que le niveau de confidentialité est défini dans le Common Language Runtime (CLR) comme des actions qui sont interdites pour du code transparent. Le modèle de transparence ne protège pas contre les violations de sécurité spécifiques au scénario, telles que le stockage des mots de passe dans les champs.
Fonctionnement du modèle de sécurité
Chaque AppDomain dispose d'un jeu d'autorisations associé, qui est défini par l'hôte dans un scénario hébergé. (Pour le code qui n'est pas hébergé, le jeu d'autorisations a un niveau de confiance totale.)
Le code de confiance partielle est toujours transparent. Par conséquent, il ne peut pas exécuter les actions interdites pour du code transparent (reportez-vous à transparence).
Par défaut, le code de confiance totale est critique, sauf s'il a été marqué comme étant transparent. Si une application de bureau est marquée comme étant transparente, elle ne peut pas appeler le code critique, bien qu'elle ait un niveau de confiance totale.
Les bibliothèques peuvent être exposées au code de confiance partielle par l'hôte et par le .NET Framework. Ces bibliothèques contiennent une combinaison de code transparent, critique et critique sécurisé.
Le code critique sécurisé doit demander les autorisations appropriées avant d'utiliser la fonctionnalité critique. Par exemple, la méthode File.Open exige FileIOPermission avant d'ouvrir un fichier.
Le code critique sécurisé doit également exécuter tous les autres contrôles et validations avant et après les appels à la fonctionnalité critique. Par exemple, les exceptions et les messages peuvent devoir être filtrés avant d'être passé au code partiellement fiable.
Le code critique doit déclarer les autorisations dont il a besoin lorsqu'il est appelé par le code partiellement fiable, car le code critique peut effectuer des opérations que le code partiellement fiable n'est pas autorisé à effectuer.