Contrôle d'accès basé sur les rôles (présentation)

La fonction de sécurité RBAC permet de contrôler l'accès des utilisateurs aux tâches qui incombent normalement au rôle root. En appliquant les attributs de sécurité aux processus et aux utilisateurs, RBAC peut répartir les capacités superutilisateur entre plusieurs administrateurs. La gestion des droits des processus est mise en oeuvre par le biais des privilèges. La gestion des droits des utilisateurs est mise en oeuvre par le biais de RBAC.

• Pour une description de la gestion des droits des processus, reportez-vous à la section Privilèges (présentation).

• Pour plus d'informations sur les tâches RBAC, reportez-vous au Chapitre 9, Utilisation du contrôle d'accès basé sur les rôles (tâches).

• Pour des informations de référence, reportez-vous au Chapitre 10, Attributs de sécurité dans Oracle Solaris (référence).

RBAC : la solution de substitution au modèle superutilisateur

Dans les systèmes UNIX classiques, l'utilisateur root, également appelé superutilisateur, dispose de tous les pouvoirs. Les programmes exécutés comme root ou setuid ont tous les pouvoirs. L'utilisateur root peut lire les fichiers et y écrire des données, exécuter tous les programmes et envoyer des signaux d'interruption aux processus. Concrètement, un superutilisateur peut changer le pare-feu d'un site, modifier la piste d'audit, consulter des informations confidentielles et arrêter l'ensemble du réseau. Un programme setuid piraté peut avoir la mainmise sur le système.

RBAC constitue la solution de substitution plus sécurisée au modèle du tout ou rien des superutilisateurs. Avec RBAC, vous pouvez appliquer des stratégies de sécurité à un niveau plus détaillé. RBAC met en oeuvre le principe de sécurité du moindre privilège. En d'autres termes, un utilisateur dispose des privilèges exacts en termes de quantité nécessaires à l'exécution d'un travail. Les utilisateurs standard ont suffisamment de privilèges pour utiliser leurs applications, vérifier l'état de leurs tâches, imprimer des fichiers, créer des fichiers, et ainsi de suite. Les capacités qui dépassent celles de l'utilisateur standard sont regroupées dans des profils de droits. Les utilisateurs devant effectuer des tâches pour lesquelles il est nécessaire de disposer de capacités de superutilisateur prennent un rôle incluant le profil de droits approprié.

RBAC regroupe les capacités de superutilisateur en profils de droits. Ces profils de droits sont affectés à des comptes utilisateur spéciaux, appelés rôles. Un utilisateur peut alors prendre un rôle pour effectuer une tâche qui requiert certaines capacités du superutilisateur. Des profils de droits prédéfinis sont fournis avec le logiciel Oracle Solaris. Vous créez les rôles et affectez les profils.

Les profils de droits peuvent fournir des capacités étendues. Par exemple, le profil de droits System Administrator (administrateur système) permet à un compte d'effectuer des tâches qui ne sont pas liées à la sécurité, telles que la gestion de l'imprimante et les tâches cron. Les profils de droits peuvent également être définis avec précision. Par exemple, le profil de droits Cron Management (gestion Cron) gère les tâches at et cron. Lorsque vous créez des rôles, des capacités restreintes et/ou étendues peuvent leur être attribuées.

La figure suivante montre comment RBAC permet de distribuer des droits aux parties de confiance.

Figure 8-1 Répartition des droits RBAC

Dans le modèle RBAC, le superutilisateur crée un ou plusieurs rôles. Les rôles sont basés sur des profils de droits. Le superutilisateur attribue ensuite les rôles aux utilisateurs autorisés à effectuer les tâches que ce rôle implique. Les utilisateurs se connectent avec leur nom d'utilisateur. Une fois connectés, les utilisateurs prennent les rôles qui autorisent l'utilisation des commandes d'administration et des outils d'interface graphique d'accès limité.

La flexibilité qui caractérise la configuration des rôles permet de définir une vaste gamme de stratégies de sécurité. Bien que Oracle Solaris soit livré avec quelques rôles, différents rôles peuvent être configurés facilement. Vous pouvez baser la plupart des rôles sur des profils de droits du même nom :

• root : rôle puissant, équivalant à l'utilisateur root. Cependant, le rôle root ne permet pas de se connecter. Un utilisateur standard doit se connecter, puis prendre le rôle root qui lui est affecté. Ce rôle est configuré par défaut.

• Administrateur système : rôle moins puissant impliquant des tâches d'administration, mais pas de sécurité. Ce rôle peut gérer des systèmes de fichiers, la messagerie électronique et l'installation de logiciels. Cependant, ce rôle ne permet pas de définir des mots de passe.

• Opérateur : rôle d'administrateur débutant, permettant d'effectuer des opérations telles que la gestion d'imprimantes et de sauvegardes.

  ---

  Remarque - Le profil de droits Media Backup (sauvegarde des médias) donne accès au système de fichiers root entier. Par conséquent, bien que les profils de droits Media Backup et Operator (opérateur) soient conçus pour les administrateurs débutants, les utilisateurs auxquels vous les affectez doivent être dignes de confiance.

  ---

Vous pouvez aussi être amené à configurer un ou plusieurs rôles de sécurité. Trois profils de droits et leurs profils supplémentaires prennent en charge la sécurité. Il s'agit des profils suivants : Information Security (sécurité des informations), User Security (sécurité des utilisateurs) et Zone Security (sécurité de la zone). Sécurité du réseau est un profil supplémentaire inclus dans le profil de droits Information Security (sécurité des informations).

Il n'est pas nécessaire de mettre en oeuvre ces rôles. Les rôles sont fonction des besoins de sécurité d'une organisation. Une stratégie consiste à configurer les rôles pour les administrateurs ayant un objectif précis dans des domaines tels que la sécurité, la mise en réseau ou l'administration d'un pare-feu. Une autre stratégie consiste à créer un seul rôle d'administrateur puissant conjointement avec un rôle d'utilisateur avancé. Le rôle d'utilisateur avancé est affecté aux utilisateurs autorisés à réparer des parties de leur propre système.

Le modèle superutilisateur et le modèle RBAC peuvent coexister. Le tableau suivant résume les différents degrés (du superutilisateur à l'utilisateur standard limité) possibles dans le modèle RBAC. Le tableau comprend les actions d'administration pouvant faire l'objet d'un suivi dans les deux modèles. Pour obtenir un récapitulatif de l'effet de chaque privilège sur un système, reportez-vous au Tableau 8-2.

Tableau 8-1 Modèle de superutilisateur par rapport au modèle RBAC avec privilèges

Eléments et concepts de base RBAC

Le modèle RBAC dans Oracle Solaris introduit les éléments suivants :

• Autorisation : autorisation permettant à un utilisateur ou rôle de réaliser une classe d'actions nécessitant des droits supplémentaires. Par exemple, la stratégie de sécurité lors de l'installation attribue aux utilisateurs standard l'autorisation solaris.device.cdrw. Cette autorisation offre aux utilisateurs les droits de lecture et d'écriture au niveau du périphérique de CD-ROM. Pour obtenir la liste des autorisations, reportez-vous au fichier /etc/security/auth_attr.

• Privilège : droit discret accordé à une commande, un utilisateur, un rôle ou un système. Les privilèges permettent la réussite d'un processus. Par exemple, le privilège proc_exec permet à un processus d'appeler execve(). Les utilisateurs standard disposent des privilèges de base. Pour connaître vos privilèges de base, exécutez la commande ppriv -vl basic. Pour obtenir d'autres options de commande, reportez-vous à la section Commandes d'administration pour la gestion des privilèges.

• Attribut de sécurité : attribut autorisant un processus à effectuer une opération. Dans un environnement UNIX standard, un attribut de sécurité permet à un processus d'effectuer une opération qui serait autrement interdite aux utilisateurs standard. Par exemple, les programmes setuid et setgid ont des attributs de sécurité. Dans le modèle RBAC, les autorisations et les privilèges sont des attributs de sécurité qui s'ajoutent aux programmes setuid et setgid. Ces attributs peuvent être affectés à un utilisateur. Par exemple, un utilisateur avec l'autorisation solaris.device.allocate peut allouer un périphérique pour une utilisation exclusive. Les privilèges peuvent être placés sur un processus. Par exemple, un processus avec le privilège file_flag_set peut définir des attributs de fichier immutable, no-unlink ou append-only.

• Application privilégiée : application ou commande pouvant ignorer les contrôles système en recherchant les attributs de sécurité. Dans un environnement UNIX standard et dans le modèle RBAC, les programmes qui utilisent setuid et setgid sont des applications privilégiées. Dans le modèle RBAC, les programmes ayant besoin de privilèges ou d'autorisations pour s'exécuter correctement sont également des applications privilégiées. Pour plus d'informations, reportez-vous à la section Applications privilégiées et RBAC.

• Profil de droits : ensemble d'attributs de sécurité pouvant être affecté à un rôle ou un utilisateur. Un profil de droits peut inclure des autorisations, des privilèges affectés directement, des commandes avec des attributs de sécurité et d'autres profils de droits. Les profils au sein d'un autre profil sont appelés des profils de droits supplémentaires. Les profils de droits offrent un moyen pratique de regrouper les attributs de sécurité.

• Rôle : identité spéciale permettant d'exécuter des applications privilégiées. L'identité spéciale peut être endossée par les utilisateurs assignés uniquement. Dans un système exécuté par des rôles, y compris le rôle root, le superutilisateur n'est pas nécessaire. Les capacités de superutilisateur sont distribuées aux différents rôles. Par exemple, dans un système à deux rôles, les tâches de sécurité sont traitées par un rôle de sécurité. Le deuxième rôle traite des tâches d'administration système qui ne sont pas liées à la sécurité. Les rôles peuvent être définis de manière plus précise. Par exemple, un système peut inclure des rôles d'administration distincts pour la gestion de la structure cryptographique, des imprimantes, du temps système, des systèmes de fichiers et de l'audit.

La figure suivante illustre la collaboration entre les éléments RBAC.

Figure 8-2 Relations entre les éléments RBAC

La figure suivante utilise le rôle Sécurité réseau et le profil de droits Network Security (sécurité réseau) pour illustrer les relations RBAC.

Figure 8-3 Exemple de relations entre éléments RBAC

Le rôle Network Security (sécurité réseau) permet de gérer les liaisons réseau, IPsec et wifi. Ce rôle est assigné à l'utilisateur jdoe. Pour prendre le rôle, jdoe change de rôle, puis indique le mot de passe correspondant. L'administrateur peut personnaliser le rôle pour qu'il accepte le mot de passe utilisateur plutôt que le mot de passe du rôle.

Dans la Figure 8-3, le profil de droits Network Security (sécurité réseau) est affecté au rôle correspondant. Le profil de droits Network Security (sécurité réseau) contient des profils supplémentaires qui sont évalués dans l'ordre Network Wifi Security (sécurité wifi réseau), Network Link Security (sécurité liaison réseau) et Network IPsec Management (gestion IPsec réseau). Ces profils supplémentaires remplissent les tâches principales du rôle.

Le profil de droits Network Security (sécurité réseau) comporte trois autorisations attribuées directement, aucun privilège affecté directement et deux commandes avec des attributs de sécurité. Les profils de droits supplémentaires ont des autorisations attribuées directement et deux d'entre eux ont des commandes avec des attributs de sécurité. Dans le rôle Sécurité réseau, jdoe possède toutes les autorisations attribuées dans ces profils et peut exécuter toutes les commandes avec les attributs de sécurité dans ces profils. jdoe peut administrer la sécurité du réseau.

Escalade des privilèges

Oracle Solaris offre aux administrateurs une grande flexibilité pour configurer la sécurité. Selon la configuration de l'installation, le logiciel n'autorise pas l'escalade des privilèges. L'escalade des privilèges se produit lorsqu'un utilisateur ou un processus obtient plus de droits d'administration qu'il n'était prévu de lui accorder. Dans ce sens, privilège signifie n'importe quel attribut de sécurité.

Le logiciel Oracle Solaris comprend les attributs de sécurité affectés au rôle root uniquement. Si d'autres systèmes de sécurité sont en place, l'administrateur peut affecter les attributs conçus pour le rôle root à d'autres comptes, mais il doit procéder avec prudence.

Le profil de droits et le jeu d'autorisations suivants peuvent escalader les privilèges d'un compte non root.

• Profil de droits Media Restore (restauration des médias) : ce profil existe, mais il ne fait partie d'aucun autre profil de droits. Dans la mesure où Media Restore permet d'accéder à l'ensemble du système de fichiers root, son utilisation est une escalade possible de privilège. Des fichiers délibérément modifiés ou des médias de substitution peuvent être restaurés. Par défaut, le rôle root inclut ce profil de droits.

• solaris.*.assign authorizations : ces autorisations existent, mais ne sont affectées à aucun profil de droits ou compte. Un compte avec une autorisation solaris.*.assign peut affecter des attributs de sécurité à d'autres auxquels le compte lui-même n'est pas affecté. Par exemple, un rôle avec l'autorisation solaris.profile.assign peut affecter des profils de droits à d'autres comptes auxquels le rôle lui-même n'est pas affecté. Par défaut, seul le rôle root dispose des autorisations solaris.*.assign.

  La meilleure pratique consiste à affecter les autorisations solaris.*.delegate et non les autorisations solaris.*.assign. Une autorisation solaris.*.delegate permet au délégant de n'attribuer à d'autres comptes que les attributs de sécurité qu'il possède. Par exemple, un rôle avec l'autorisation solaris.profile.delegate peut affecter à d'autres utilisateurs et rôles des profils de droits qui lui sont affectés.

Pour connaître les escalades ayant une incidence sur l'attribut de sécurité, reportez-vous à la section Prévention de l'escalade de privilèges.

Autorisations RBAC

Une autorisation est un droit discret pouvant être accordé à un rôle ou à un utilisateur. Les autorisations permettent d'appliquer des stratégies au niveau de l'application utilisateur.

Tandis que les autorisations peuvent être attribuées directement à un rôle ou à un utilisateur, il est recommandé d'inclure les autorisations dans un profil de droits. Le profil de droits est alors ajouté à un rôle et le rôle est assigné à un utilisateur. Pour en voir un exemple, reportez-vous à la Figure 8-3.

Les autorisations comportant les mots delegate ou assign permettent à l'utilisateur ou au rôle d'affecter des attributs de sécurité à d'autres.

Pour empêcher l'escalade des privilèges, il est recommandé de ne pas affecter d'autorisation assign à un compte.

• Une autorisation delegate permet au délégant de n'attribuer à d'autres utilisateurs que les attributs de sécurité qu'il possède. Par exemple, un rôle avec l'autorisation solaris.profile.delegate peut affecter à d'autres utilisateurs des profils de droits qui lui sont affectés.

• Une autorisation assign permet à l'assignataire d'affecter à d'autres utilisateurs des attributs de sécurité que le compte ne possède pas. Par exemple, un rôle avec l'autorisation solaris.profile.assign peut affecter à d'autres utilisateurs n'importe quel profil de droits.

Les autorisations solaris.*.assign sont fournies, mais ne sont pas incluses dans tous les profils. Par défaut, seul le rôle root possède les autorisations solaris.*.assign.

Les applications compatibles avec RBAC peuvent vérifier les autorisations de l'utilisateur avant de lui autoriser l'accès au niveau de l'application ou des opérations spécifiques au sein de l'application. Cette vérification remplace la vérification conventionnelle dans les applications UNIX pour UID=0. Pour plus d'informations sur les autorisations, reportez-vous aux sections suivantes :

• Autorisations

• Base de données auth_attr

• Commandes sélectionnées nécessitant des autorisations

Autorisations et privilèges

Les privilèges appliquent la stratégie de sécurité dans le noyau. La différence entre les autorisations et les privilèges réside dans le niveau auquel la stratégie de sécurité est appliquée. Sans le privilège adéquat, un processus peut se voir empêcher d'exécuter des opérations privilégiées par le noyau. Sans les autorisations adéquates, un utilisateur peut se voir empêcher d'utiliser une application privilégiée ou d'exécuter des opérations liées à la sécurité au sein d'une application privilégiée. Pour en savoir plus sur les privilèges, reportez-vous à la section Privilèges (présentation).

Applications privilégiées et RBAC

Les applications et les commandes pouvant ignorer les contrôles système sont considérées comme des applications privilégiées. Les attributs de sécurité tels que UID=0, les privilèges et les autorisations rendent une application privilégiée.

Applications vérifiant les UID et GID

Les applications privilégiées vérifiant l'ID utilisateur root ( UID=0) ou autres UID (ID utilisateur) ou GID (ID de groupe) existent depuis longtemps dans l'environnement UNIX. Le mécanisme de profil de droits vous permet d'isoler les commandes nécessitant un ID spécifique. Au lieu de modifier l'ID sur une commande accessible par tous, vous pouvez placer la commande avec les attributs de sécurité affectés dans un profil de droits. Un utilisateur ou un rôle avec ce profil de droits peut alors exécuter le programme sans avoir à devenir superutilisateur.

Les ID peuvent être spécifiés en tant qu'ID réels ou effectifs. On préférera une affectation d'ID effectifs à une affectation d'ID réels. Les ID effectifs correspondent à la fonction setuid dans les bits d'autorisation de fichier. Les ID effectifs permettent également d'identifier l'UID pour l'audit. Cependant, étant donné que certains programmes et scripts shell nécessitent un UID réel de root, il est également possible de définir des ID utilisateur réels. Par exemple, la commande reboot requiert un ID utilisateur réel plutôt qu'un ID utilisateur effectif. Si un ID effectif n'est pas suffisant pour exécuter une commande, vous devez affecter l'ID réel à la commande.

Applications vérifiant les privilèges

Les applications privilégiées peuvent vérifier l'utilisation des privilèges. Le mécanisme de profil de droits RBAC permet de spécifier les privilèges pour des commandes spécifiques qui requièrent des attributs de sécurité. Ensuite, vous pouvez isoler la commande avec des attributs de sécurité affectés dans un profil de droits. Un utilisateur ou un rôle doté de ce profil de droits peut ensuite exécuter la commande avec les privilèges nécessaires à la réussite de la commande.

Voici la liste des commandes vérifiant les privilèges :

• Commandes Kerberos, telles que kadmin, kprop et kdb5_util

• Commandes réseau, telles que ipadm, routeadm et snoop

• Commandes de fichier et de système de fichiers, telles que chmod, chgrp et monter

• Commandes qui contrôlent les processus, telles que kill, pcred et rcapadm

Pour ajouter des commandes avec des privilèges à un profil de droits, reportez-vous à la section Création d'un profil de droits et à la page de manuel profiles(1). Pour déterminer quelles commandes vérifient les privilèges dans un profil particulier, reportez-vous à la section Affichage de tous les attributs de sécurité définis.

Applications vérifiant les autorisations

Oracle Solaris fournit également des commandes qui vérifient les autorisations. Par définition, les utilisateurs root possèdent toutes les autorisations. Par conséquent, l'utilisateur root peut exécuter n'importe quelle application. Voici la liste des applications qui vérifient les autorisations :

• Commandes d'administration d'audit, telles que auditconfig et auditreduce

• Commandes d'administration d'imprimante, telles que lpadmin et Ipfilter

• Commandes de tâche par lot, telles que at, atq, batch et crontab

• Commandes orientées périphérique, telles que allocate, deallocate, list_devices et cdrw.

Pour tester un script ou un programme dans le cadre des autorisations, reportez-vous à l'Exemple 9-23. Pour écrire un programme nécessitant des autorisations, reportez-vous à la rubrique About Authorizations du manuel Developer’s Guide to Oracle Solaris 11 Security.

Profils de droits RBAC

Un profil de droits est un ensemble d'attributs de sécurité pouvant être affecté à un rôle ou un utilisateur pour effectuer des tâches requérant des droits d'administration. Un profil de droits peut se composer d'autorisations, de privilèges, de commandes auxquelles des attributs de sécurité ont été affectées et d'autres profils de droits. Les privilèges qui sont affectés dans un profil de droits sont en vigueur pour toutes les commandes. Les profils de droits contiennent également des entrées afin de réduire ou d'étendre le premier ensemble hérité, et de réduire l'ensemble limite de privilèges.

Pour plus d'informations sur les profils de droits, reportez-vous aux sections suivantes :

• Profils de droits

• Base de données prof_attr

• Base de données exec_attr

Rôles RBAC

Un rôle est un type spécial de compte utilisateur à partir duquel vous pouvez exécuter des applications privilégiées. Les rôles sont créés de la même manière que les comptes utilisateur. Les rôles ont un répertoire d'accueil, une affectation de groupe, un mot de passe, et ainsi de suite. Les profils de droits et les autorisations attribuent les capacités administratives des rôles. Les rôles ne peuvent pas hériter des capacités d'autres rôles ou d'autres utilisateurs. Les rôles discrets répartissent les capacités de superutilisateur et permettent ainsi des pratiques administratives plus sécurisées.

Lorsqu'un utilisateur prend un rôle, les attributs du rôle remplacent tous les attributs de l'utilisateur. Les informations sur les rôles sont stockées dans les bases de données passwd, shadow et user_attr. Les actions des rôles peuvent être auditées. Pour obtenir des informations détaillées sur la configuration des rôles, reportez-vous aux sections suivantes :

• Planification de votre implémentation RBAC

• Création d'un rôle

• Modification des attributs de sécurité d'un rôle

Un rôle peut être affecté à plusieurs utilisateurs. Tous les utilisateurs qui peuvent prendre le même rôle possèdent le même répertoire d'accueil de rôle, fonctionnent dans le même environnement et ont accès aux mêmes fichiers. Les utilisateurs peuvent prendre les rôles à partir de la ligne de commande à l'aide de la commande su et en fournissant le mot de passe et le nom du rôle. Par défaut, les utilisateurs peuvent s'authentifier pour un rôle en fournissant le mot de passe du rôle. L'administrateur peut configurer le système pour permettre à un utilisateur de s'authentifier en fournissant le mot de passe de l'utilisateur. Pour la procédure, reportez-vous à la section Octroi à un utilisateur de l'autorisation d'utiliser son propre mot de passe pour prendre un rôle.

Un rôle ne peut pas se connecter directement. Un utilisateur se connecte, puis prend un rôle. Après avoir pris un rôle, l'utilisateur ne peut pas en prendre un autre tant qu'il n'a pas quitté son rôle actuel. Après avoir quitté son rôle, l'utilisateur peut alors en prendre un autre.

Le fait que root soit un rôle dans Oracle Solaris empêche toute connexion root anonyme. Si la commande shell de profil, pfexec, est en cours d'audit, la piste d'audit contient l'UID réel de l'utilisateur de connexion, les rôles que l'utilisateur a pris et les actions que le rôle a effectuées. Pour auditer le système ou un utilisateur particulier pour les opérations de rôle, reportez-vous à la section Audit des rôles.

Les profils de droits livrés avec le logiciel sont conçus pour correspondre aux rôles. Par exemple, le profil de droits System Administrator (administrateur système) peut permettre de créer le rôle Administrateur système. Pour configurer un rôle, reportez-vous à la section Création d'un rôle.

Shells de profil et RBAC

Les utilisateurs et les rôles peuvent exécuter des applications privilégiées à partir d'un shell de profil. Un shell de profil est un shell spécial qui reconnaît les attributs de sécurité inclus dans un profil de droits. Les administrateurs peuvent affecter un shell de profil à un utilisateur spécifique en tant que shell de connexion, ou le shell de profil est démarré lorsqu'un utilisateur exécute la commande su pour prendre un rôle. Dans Oracle Solaris, chaque shell dispose d'un shell de profil homologue. Par exemple, les shells de profil correspondant aux bourne shell (sh), bash shell (bash) et korn shell (ksh), sont respectivement les shells pfsh, pfbash et pfksh. Pour obtenir une liste des shells de profil, reportez-vous à la page de manuel pfexec(1).

Les utilisateurs auxquels un profil de droits a été assigné directement et dont le shell de connexion n'est pas un shell de profil doivent appeler un shell de profil pour exécuter les commandes avec les attributs de sécurité. La section Considérations relatives à la sécurité lors de l'affectation directe d'attributs de sécurité contient les points en prendre en considération en matière d'utilisation et de sécurité.

Toutes les commandes exécutées dans le cadre d'un shell de profil peuvent faire l'objet d'un audit. Pour plus d'informations, reportez-vous à la section Audit des rôles.

Champ d'application du service de noms et RBAC

Le champ d'application du service de noms permet de mieux comprendre RBAC. Le champ d'application d'un rôle peut être limité à un hôte unique. Il peut également inclure tous les hôtes pris en charge par un service de noms, tel que LDAP. Le champ d'application du service de noms pour un système est indiqué dans le service de commutation de nom, svc:/system/name-service/switch. La recherche s'arrête à la première correspondance. Si, par exemple, un profil de droits existe dans deux champs d'application du service de noms, seules les entrées dans le premier champ d'application du service de noms sont utilisées. Si files est la première correspondance, le champ d'application de ce rôle est limité à l'hôte local.

Considérations relatives à la sécurité lors de l'affectation directe d'attributs de sécurité

En général, un utilisateur obtient ses capacités d'administration par le biais d'un rôle. Les autorisations, les privilèges et les commandes privilégiées sont regroupés dans un profil de droits. Le profil de droits est inclus dans un rôle et le rôle est assigné à un utilisateur.

L'affectation directe des profils de droits et des attributs de sécurité est également possible :

• Les profils de droits, privilèges et autorisations peuvent être attribués directement aux utilisateurs.

• Les privilèges et les autorisations peuvent être attribués directement aux utilisateurs et aux rôles.

Toutefois, l'affectation directe de privilèges ne constitue pas une pratique sécurisée. Les utilisateurs et les rôles auxquels un privilège est affecté directement peuvent remplacer la stratégie de sécurité partout où ce privilège est requis par le noyau. Une pratique plus sécurisée consiste à attribuer le privilège en tant qu'attribut de sécurité d'une commande dans un profil de droits. Ce privilège n'est alors disponible que pour cette commande par un utilisateur doté de ce profil de droits.

Etant donné que les autorisations agissent au niveau de l'utilisateur, l'affectation directe d'autorisations constitue un moindre risque que l'affectation directe de privilèges. Cependant, les autorisations peuvent permettent à un utilisateur d'effectuer des tâches hautement sécurisées, comme l'affectation d'indicateurs d'audit par exemple.

Considérations relatives à l'utilisation lors de l'affectation directe d'attributs de sécurité

L'affectation directe de profils de droits et les attributs de sécurité peuvent avoir une incidence sur l'utilisation :

• Les autorisations et privilèges affectés directement et les commandes et autorisations dans un profil de droits affecté directement, doivent être interprétés par un shell de profil pour être effectifs. Par défaut, un shell de profil n'est pas affecté aux utilisateurs.

  L'utilisateur ne doit pas oublier d'ouvrir un shell de profil, puis d'exécuter les commandes dans ce shell.

• L'affectation individuelle d'autorisations n'est pas évolutive. Les autorisations affectées directement ne suffisent peut-être pas pour réaliser une tâche. Une tâche peut requérir des commandes privilégiées.

  Les profils de droits sont conçus pour lier des autorisations et des commandes privilégiées. Ceux-ci sont également évolutifs.