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

La fonction de sécurité RBAC (Role-based access control, contrôle d'accès basé sur les rôles) permet de contrôler l'accès utilisateur aux tâches qui incombent normalement au superutilisateur. 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 œuvre par le biais des privilèges. La gestion des droits des utilisateurs est mise en œuvre 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 9Utilisation du contrôle d'accès basé sur les rôles (tâches).

• Pour obtenir des informations de référence, reportez-vous au Chapitre 10Contrôle d'accès basé sur les rôles (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 œuvre 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 ordinaire 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 endossent 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 endosser 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 d'administrateur principal est l'équivalent du superutilisateur. Les profils de droits peuvent également être définis avec précision. Par exemple, le profil de droits de gestion cron gère les tâches at et cron. Lorsque vous créez des rôles, vous pouvez décider de créer des rôles aux capacités étendues et/ou des rôles aux capacités restreintes.

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 endossent 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 peu de rôles, trois rôles recommandés peuvent être configurés facilement. Les rôles sont basés sur des profils de droits du même nom :

• Administrateur principal : rôle puissant, équivalent de celui de l'utilisateur root ou du superutilisateur.

• Root : rôle puissant, équivalent de celui de 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é.

• 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 supports) donne accès au système de fichiers root entier. Par conséquent, bien que les profils de droits Sauvegarde des supports et Opérateur soient conçus pour les administrateurs débutants, les utilisateurs auxquels vous les affectez doivent être dignes de confiance.

  ---

Il n'est pas nécessaire de mettre en œuvre ces trois rôles. Les rôles sont fonction des besoins de sécurité d'une organisation. Les rôles peuvent être configurés 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 ordinaire 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

Éléments et concepts de base RBAC Oracle Solaris

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.

• 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 opérations effectuées par les utilisateurs standard peuvent nécessiter des attributs de sécurité. Outre les programmes setuid et setgid, les autorisations et les privilèges sont également des attributs de sécurité dans le modèle RBAC. Par exemple, un utilisateur avec l'autorisation solaris.device.allocate peut allouer un périphérique pour une utilisation exclusive. Un processus avec le privilège sys_time peut manipuler le temps système.

• 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 de capacités d'administration pouvant être affecté à un rôle ou un utilisateur. Un profil de droits peut se composer d'autorisations, de commandes avec des attributs de sécurité et d'autres profils de droits. Les profils de droits offre 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 les rôles, 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-1 Relations entre les éléments RBAC Oracle Solaris

Dans RBAC, les rôles sont affectés à des utilisateurs. Lorsqu'un utilisateur endosse un rôle, les capacités de ce rôle sont disponibles. Les rôles reçoivent leurs capacités des profils de droits. Les profils de droits peuvent contenir des autorisations, des privilèges affectés directement, des commandes privilégiées et d'autres profils de droits. Les commandes privilégiées s'exécutent avec des attributs de sécurité.

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

Figure 8-2 Exemple de relations entre éléments RBAC d'Oracle Solaris

Le rôle Sécurité réseau permet de gérer les liaisons réseau, IPsec et wifi. Ce rôle est assigné à l'utilisateur jdoe. Pour endosser le rôle, jdoe change de rôle, puis indique le mot de passe correspondant.

Le profil de droits Sécurité réseau a été affecté au rôle Sécurité réseau. Le profil de droits Sécurité réseau contient des profils supplémentaires qui sont évalués dans l'ordre Sécurité Wifi réseau, Sécurité Liaison réseau et Gestion IPsec réseau. Ces profils supplémentaires remplissent les tâches principales du rôle.

Le profil de droits 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 à l'utilisateur root uniquement. Si d'autres systèmes de sécurité sont en place, l'administrateur peut affecter les attributs conçus pour les utilisateurs root à d'autres comptes, mais il doit procéder avec prudence.

Par exemple, le profil de droits Restauration des supports 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 racine, son utilisation est une escalade possible de privilège. Des fichiers délibérément modifiés ou des supports de substitution peuvent être restaurés. Par défaut, seul l'utilisateur root a ce profil de droits.

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 d'accès est alors ajouté à un rôle et le rôle est assigné à un utilisateur. La Figure 8-2 présente un exemple.

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 :

• Délégation et nommage des autorisations

• Base de données auth_attr

• Commandes 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é d'exécution 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 pkgadd 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 le remplacer par un ID réel. Pour plus d'informations sur cette procédure, reportez-vous à la section Procédure de création ou de modification d'un profil de droits.

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. Au lieu de demander des capacités de superutilisateur pour utiliser une application ou une commande, vous pouvez isoler la commande avec des attributs de sécurité d'exécution 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 ifconfig, 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 Procédure de création ou de modification d'un profil de droits. Pour déterminer quelles commandes vérifient les privilèges dans un profil particulier, reportez-vous à la section Détermination des privilèges qui vous sont attribués.

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 :

• Suite d'outils de la console de gestion Solaris

• 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-24. Pour écrire un programme nécessitant des autorisations, reportez-vous à la rubrique About Authorizations du Developer’s Guide to Oracle Solaris Security.

Profils de droits RBAC

Un profil de droits est un ensemble de remplacements système pouvant être affecté à un rôle ou à un utilisateur. Un profil de droits peut se composer d'autorisations, de commandes avec des attributs de sécurité affectés et d'autres profils de droits. Les informations de profil de droits sont divisées entre les bases de données prof_attr et exec_attr. Le nom du profil de droits et les autorisations résident dans la base de données prof_attr. Le nom du profil de droits et les commandes avec les attributs de sécurité affectés résident dans la base de données exec_attr.

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

• Contenu des 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 personnel, 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 endosse 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 informations sur les rôles peuvent être ajoutées à la base de données audit_user. Pour obtenir des informations détaillées sur la configuration des rôles, reportez-vous aux sections suivantes :

• Procédure de planification de votre implémentation RBAC

• Procédure de création d'un rôle à partir de la ligne de commande

• Procédure de modification des propriétés d'un rôle

Un rôle peut être affecté à plusieurs utilisateurs. Tous les utilisateurs qui peuvent endosser le même rôle possèdent le même répertoire personnel de rôle, fonctionnent dans le même environnement et ont accès aux mêmes fichiers. Les utilisateurs peuvent endosser les rôles à partir de la ligne de commande à l'aide de la commande su ainsi que du nom et du mot de passe des rôles. Les utilisateurs peuvent également endosser un rôle dans l'outil de la console de gestion Solaris.

Un rôle ne peut pas se connecter directement. Un utilisateur se connecte, puis endosse un rôle. Après avoir endossé un rôle, l'utilisateur ne peut pas en endosser 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 endosser un autre.

Vous pouvez empêcher une connexion root anonyme en remplaçant l'utilisateur root par un rôle, comme illustré à la section Procédure de changement d'un utilisateur root en rôle. 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 endossés 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 Procédure d'audit des rôles.

Aucun rôle prédéfini n'est livré avec le logiciel Oracle Solaris. Cependant, les profils de droits livrés avec le logiciel sont conçus pour correspondre aux rôles. Par exemple, le profil de droits Administrateur principal peut permettre de créer le rôle Administrateur principal.

• Pour configurer le rôle Administrateur principal, reportez-vous à la section Utilisation des outils de gestion Solaris avec RBAC (liste des tâches) du Guide d’administration système : administration de base.

• Pour configurer d'autres rôles, reportez-vous à la section Procédure de création et d'attribution d'un rôle à l'aide de l'interface graphique.

• Pour créer des rôles sur la ligne de commande, reportez-vous à la section Gestion de RBAC (liste des tâches).

Shells de profil et RBAC

Les rôles peuvent exécuter des applications privilégiées à partir du lanceur de la console de gestion Solaris ou 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 shells de profil sont lancés lorsque cet utilisateur exécute la commande su pour endosser un rôle. Les shells de profil sont pfsh, pfcsh et pfksh. Ces shells correspondent au shell Bourne (sh), au shell C (csh) et au shell Korn (ksh), respectivement.

Les utilisateurs auxquels un profil de droits a été assigné directement 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 Procédure d'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 nommage, tel que NIS, NIS+ ou LDAP. Le champ d'application du service de noms pour un système est indiqué dans le fichier /etc/nsswitch.conf. 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 et les commandes privilégiées sont regroupées 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.

Étant 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.

Un profil de droits attribué directement à un utilisateur présente des problèmes d'utilisation plus que des problèmes de sécurité. Les commandes avec des attributs de sécurité dans le profil de droits ne peuvent être exécutées que dans un shell de profil. L'utilisateur ne doit pas oublier d'ouvrir un shell de profil, puis de saisir les commandes dans ce shell. Un rôle auquel est affecté un profil de droits obtient un shell de profil automatiquement. Par conséquent, les commandes sont exécutées avec succès dans le shell du rôle.