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