Quelqu'un utilise vraiment la sécurité d'accès au code pour protéger ses assemblages et/ou ses méthodes?

Question

Il me semble que la plupart des développeurs ignorent complètement ces fonctionnalités. Les gens préfèrent gérer les exceptions de sécurité comme des exceptions génériques reposant sur des rôles et des droits Windows standard au lieu d'apprendre à utiliser les moyens CAS pour améliorer la sécurité - probablement parce que CAS est assez confus dans sa logique et son nom. Est-ce que quelqu'un peut suggérer des règles générales ou des bonnes pratiques pour utiliser CAS de manière optimale?

Answer 1

Oui et non. Malheureusement, vous avez raison: les développeurs utilisent rarement le CAS, et encore moins l'utilisent pleinement. Dans quelques situations, est-ce que je les vois en train de le faire (d'accord, ce n'est pas vraiment les programmeurs mais l'organisation qui les force ...)

En plus d'être utilisé pour permettre aux utilisateurs de limiter les assemblages téléchargés sur Internet (par exemple) - Bien que ce soit rarement déployé en dehors de Silverlight - j'ai vu deux utilisations principales de CAS.
D'abord, il y a les limites de la politique générale, généralement le moyen le plus facile de se familiariser avec CAS (surtout que VS peut automatiquement générer le fichier de politique pour vous). J'ai vu cela en usage (rarement) lorsqu'une entreprise sensible (par exemple des banques) a un développement personnalisé par un tiers d'un système qui doit être sécurisé. Cela peut leur profiter en ajoutant des limitations supplémentaires sur ce qu'ils ne savent pas que leurs programmeurs font.
Deuxièmement, il y a des demandes de liaison très spécifiques, dans la situation (encore rare) où vous avez un module fonctionnant avec des privilèges relativement élevés, et vous ne voulez que des assemblys spécifiques appelant dans votre module. Par exemple, la semaine dernière, j'avais un client avec un module qui écrivait dans ActiveDirectory, et je voulais limiter l'accès à cette fonction uniquement à partir d'un système spécifique.

Bien sûr, CAS est beaucoup plus grand que cela, mais ce sont vraiment les deux meilleurs endroits pour commencer. En règle générale, et c'est vrai pour tout, ne décidez pas de l'utiliser juste parce que c'est là, sauf si cela répond à un besoin que vous avez. La politique est la plus simple et a le plus de sens à mettre en place à l'avance.

Answer 2

Voir également this discussion.

Le problème est exacerbé car beaucoup de code (peut-être trop) fonctionne à pleine confiance. Et puis les seules vérifications qui sont effectuées sont des choses comme les contrôles PrincipalPermissionAttribute - la plupart des autres sont simplement ignorés. Donc, dans de nombreux cas, il n'y a pas beaucoup de points! À moins que vous chargiez dans des fichiers externes (non approuvés) [et que vous ayez besoin de CAS], cela n'ajoute pas beaucoup dans beaucoup de cas (et oui, il y a beaucoup d'exceptions).

CAS est beaucoup plus utile pour les clients s'exécutant dans le bac à sable (par exemple, téléchargé sur Internet). Sliverlight prend cela à l'extrême, avec des règles plus strictes (en particulier autour de la réflexion) que régulière .NET.