these doctorat une architecture de securité

Chapitre 3. Étude d’intergiciels sécurisés pour le calcul distribué
système d’exploitation Microsoft Windows, l’authentification HTTP, Digest et Kerberos, ainsi que
Microsoft Passport.
La sécurité peut être basée sur les concepts des Rôles au lieu d’utiliser directement les identifiants
des utilisateurs. L’appartenance d’un utilisateur à un rôle est du ressort de l’administrateur
de l’un des quatre niveaux d’affinements des politiques de sécurité.
FIG. 3.12 – Sécurité utilisateur basée sur les rôles
tel-00239252, version 1 - 5 Feb 2008
Les permissions accordées à une action donnée correspondent à l’intersection des permissions
des quatre niveaux de sécurité (tableau 3.1).
Type Spécifié par S’applique à
Entreprise Administrateur Tous les codes
Machine Administrateur Tous les codes sur la machine
Utilisateur Administrateur et Utilisateur Tous les codes associés à l’utilisateur
Application Application Tous les codes chargés par l’application
TAB. 3.1 – Les divers niveaux de politiques de sécurité en .Net
Afin de gérer le comportement de sécurité d’une assembly, le programmeur peut avoir recours
à deux méthodes : la sécurité déclarative et la sécurité impérative.
La sécurité déclarative permet aux programmeurs de spécifier les critères de sécurité d’un
assembly directement dans les métadonnées du son code. Les demandes d’autorisation et toutes
les autres formes de sécurité déclarative sont spécifiées en tant qu’attributs personnalisés dans
le code.
Les annotations des classes, des propriétés et des méthodes sont utilisées pour définir de manière
plus précise les autorisations. La sécurité déclarative peut servir, par exemple, à vérifier
que l’appelant d’une classe spécifique porte la signature d’un éditeur connu ou possède un nom
fort particulier avant l’appel d’une méthode. Dans la mesure où les attributs déclaratifs font
partis des métadonnées de l’assembly, ses besoins en matière de sécurité deviennent plus facilement
identifiables. Des outils peuvent analyser les assemblies pour déterminer les méthodes
avec demandes d’autorisations et celles avec assertions d’autorisations.
Les vérifications déclaratives conviennent particulièrement lorsque l’action et l’autorisation
demandées sont déterminées au moment de la compilation. Si une méthode doit toujours vérifier
un accès en écriture dans un répertoire par exemple, une vérification d’autorisation déclarative
sera plus avantageuse. Si, par contre, l’emplacement de l’accès requis en écriture change, la
sécurité impérative devient la solution la mieux adaptée. L’exemple ci-après présente le code
C# responsable du contrôle d’accès, effectué de manière déclarative, à la méthode Method. Pour
qu’un utilisateur puisse avoir accès à cette méthode, il doit appartenir au rôle Responsable.
[PrincipalPermission(SecurityAction.Demand, Role="Responsable")]
void Method()
{
// la methode est executee seulement si l’utilisateur
// appartient au role "Responsable"
44