Instructions de codage sécurisé

La sécurité basée sur les preuves et la sécurité d'accès du code fournissent des mécanismes particulièrement puissants et explicites d'implémentation de la sécurité. La plupart du code d'application peut simplement utiliser l'infrastructure implémentée par le .NET Framework. Dans certains cas, une sécurité supplémentaire spécifique à l'application est nécessaire, générée soit par l'extension du système de sécurité, soit par l'utilisation de nouvelles méthodes ad hoc.

À l'aide des autorisations appliquées par le .NET Framework et d'autres vérifications dans votre code, vous devez dresser des barrières pour empêcher du code nuisible d'obtenir des informations que vous ne voulez pas partager ou d'effectuer d'autres actions indésirables. En outre, il vous faut trouver un compromis entre la sécurité et les possibilités d'utilisation dans tous les scénarios prévus qui utilisent du code de confiance.

Cette vue d'ensemble décrit les différents procédés utilisés pour concevoir du code afin qu'il fonctionne avec le système de sécurité.

Remarque
D'importantes modifications ont eu lieu au niveau du modèle de sécurité et de la terminologie .NET Framework dans le .NET Framework version 4. Pour plus d'informations sur ces modifications, consultez Modifications de sécurité dans le .NET Framework 4.

Code indépendant de la sécurité

Le code indépendant de la sécurité ne fait rien d'explicite avec le système de sécurité. Il s'exécute quelles que soient les autorisations qu'il reçoit. Bien que des applications qui ne parviennent pas à intercepter les exceptions de sécurité associées à des opérations protégées (comme l'utilisation de fichiers, la mise en réseau etc.) puissent engendrer une exception non gérée, le code indépendant de la sécurité tire néanmoins parti des technologies de la sécurité du .NET Framework.

Une bibliothèque indépendante de la sécurité possède des caractéristiques particulières que vous devez connaître. Supposons que votre bibliothèque fournisse des éléments d'API qui utilisent des fichiers ou appellent du code non managé ; si votre code ne possède pas l'autorisation correspondante, il ne s'exécutera pas comme décrit. Cependant, même si le code possède l'autorisation, n'importe quel code d'application qui l'appelle doit avoir la même autorisation afin de fonctionner. Si le code appelant ne possède pas la bonne autorisation, une SecurityException apparaît suite au parcours de pile de la sécurité d'accès du code.

Code d'application ne correspondant pas à un composant réutilisable

Si votre code fait partie d'une application qui ne sera pas appelée par un autre code, la sécurité est simple et un codage spécial n'est sans doute pas nécessaire. Cependant, n'oubliez pas que du code nuisible peut appeler votre code. Si la sécurité d'accès du code peut empêcher le code nuisible d'accéder à des ressources, ce type de code est toutefois capable de lire les valeurs de vos champs ou propriétés susceptibles de contenir des informations confidentielles.

De plus, si votre code accepte des entrées de l'utilisateur à partir d'Internet ou d'autres sources peu fiables, vous devez vous méfier des entrées malveillantes.

Implémentation de wrapper managé vers du code natif

Dans ce scénario, certaines fonctionnalités utiles sont généralement implémentées dans du code natif que vous voulez mettre à disposition du code managé. Les wrappers managés sont faciles à écrire à l'aide soit de l'appel de code non managé, soit de COM Interop. Toutefois, si vous le faites, les appelants de vos wrappers doivent avoir des droits de code non managé pour que l'opération réussisse. Dans le cadre de la stratégie par défaut, cela signifie que le code téléchargé depuis un intranet ou Internet ne fonctionnera pas avec les wrappers.

Au lieu d'accorder des droits de code non managé à toutes les applications qui utilisent ces wrappers, il est préférable d'accorder ces droits uniquement au code wrapper. Si les fonctionnalités sous-jacentes n'exposent aucune ressource et que l'implémentation est également sécurisée, le wrapper doit simplement déclarer ses droits, ce qui permet à n'importe quel code d'effectuer un appel via celui-ci. Lorsque des ressources sont concernées, le codage de sécurité doit être le même que le cas de code de bibliothèque décrit dans la section suivante. Comme le wrapper expose potentiellement les appelants à ces ressources, une vérification minutieuse de la sécurité du code natif est nécessaire, ce qui relève de la responsabilité du wrapper.

Code de bibliothèque exposant des ressources protégées

Il s'agit de l'approche la plus puissante et donc potentiellement risquée (si elle n'est pas exécutée correctement) pour le codage de sécurité : votre bibliothèque sert d'interface permettant à un autre code d'accéder à certaines ressources qui ne sont pas autrement disponibles, tout comme les classes du .NET Framework appliquent des autorisations pour les ressources qu'elles utilisent. Quel que soit l'emplacement où vous exposez une ressource, votre code doit en premier lieu demander l'autorisation appropriée à la ressource (c'est-à-dire effectuer une vérification de sécurité), puis généralement déclarer ses droits lui permettant d'effectuer l'opération proprement dite.

Rubriques connexes

Titre	Description
Comment : exécuter du code d'un niveau de confiance partiel dans un bac à sable (sandbox)	Explique comment exécuter une application d'un niveau de confiance partiel dans un environnement de sécurité restreint qui limite les autorisations d'accès au code accordées.
Demandes d'autorisation	Décrit comment interagir avec le système de sécurité du .NET Framework à l'aide des demandes de sécurité.
Sécurisation des données d'état	Décrit comment protéger les membres privés.
Sécurisation de l'accès à la méthode	Décrit comment empêcher l'appel de méthodes par du code d'un niveau de confiance partiel.
Sécurisation du code wrapper	Décrit les problèmes de sécurité pour le code qui englobe un autre code.
Sécurité et champs de tableau en lecture seule publics	Décrit les questions de sécurité applicables au code qui utilise des tableaux publics en lecture seule issus des bibliothèques .NET Framework.
Sécurisation de la gestion des exceptions	Décrit les problèmes de sécurité liés à la gestion des exceptions.
Sécurité et entrées d'utilisateur	Décrit les problèmes de sécurité pour des applications qui acceptent les entrées de l'utilisateur.
Considérations sur la sécurité et la communication à distance	Décrit les problèmes de sécurité pour les applications qui communiquent sur des domaines d'application.
Sécurité et sérialisation	Décrit les problèmes de sécurité lors de la sérialisation d'objets.
Sécurité et conditions de concurrence	Décrit comment éviter des conditions de concurrence critique dans votre code.
Sécurité et génération de code immédiate	Décrit les problèmes de sécurité pour les applications qui génèrent du code dynamique.
Autorisations dangereuses et administration de stratégie	Décrit des autorisations qui peuvent permettre le contournement potentiel de la sécurité.
Sécurité et problèmes d'installation	Décrit les aspects à prendre en compte pour le test et l'installation de votre application.
Sécurité des applications Web ASP.NET	Donne une description détaillée de la sécurité ASP.NET et explique comment l'utiliser dans votre code.
Sécurité d'accès du code	Donne une description détaillée de la sécurité d'accès du code de .NET Framework et explique comment l'utiliser dans votre code.
Sécurité basée sur les rôles	Donne une description détaillée de la sécurité basée sur les rôles de .NET Framework et explique comment l'utiliser dans votre code.