Fournir un élément de contrat et Processus de gestion des droits utilisateur la solution de substitution au modèle superutilisateur

Langue :

Dans les systèmes UNIX classiques, l'utilisateur root, également appelé superutilisateur, dispose de tous les pouvoirs. Les programmes exécutés comme root, et réciproquement pour la plupart des programmes, sont également tous les pouvoirs. setuid 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 root piraté peut avoir la mainmise sur le système.

L'affectation de droits aux utilisateurs, aux ressources et aux processus représente une alternative plus sûre au modèle tout ou rien des superutilisateurs. Les droits permettent d'appliquer des stratégies de sécurité à un niveau plus détaillé. Les droits respectent le principe de sécurité du moindre privilège. En d'autres termes, un utilisateur dispose ni plus ni moins des privilège exacts 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 droits qui dépassent ceux de l'utilisateur standard sont regroupées dans des profils de droits. Les utilisateurs qui doivent effectuer des tâches qui nécessitent une des droits de superutilisateur peuvent se voir attribuer un profil de droits.

Droits qui sont regroupées dans un profil peut être affecté directement à des utilisateurs. Elles peuvent également être affectés indirectement en créant des comptes spéciaux, appelés rôles. Un utilisateur peut alors endosser un rôle pour effectuer une tâche qui requiert certains privilèges d'administration. Oracle Solaris fournit un grand nombre de profils de droits prédéfinis. Vous créez les rôles et affectez les profils.

Le package ARMOR contient un jeu de rôles standardisés. L'installation de ce package par l'interface et en affectant les rôles aux utilisateurs, vous ne pouvez créer un système qui fournit la séparation des tâches à l'initialisation. Pour plus d'informations, reportez-vous à la section Authorization Rules Managed On RBAC (ARMOR), Modèle de gestion des droits de votre Sélectionné suivantes, et à l'Example 3–1.

Les profils de droits peuvent fournir large les droits d'administration. 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 des imprimantes et des 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, les rôles peuvent être assignés droits des droits d'administration ou Etroit large.

La figure suivante illustre la manière dont Oracle Solaris peut répartir des droits aux Utilisateurs de confiance en créant des rôles. Des droits d'accès par le superutilisateur peut également imputer assigner des profils de droits directement à aux utilisateurs de confiance.

Figure 1-1 Répartition des droits

image:Le graphique présente les clés qui représentent des droits. Les utilisateurs dans des rôles exécutant des fonctions différentes se voient attribuer des clés différentes.

Dans le modèle de droits indiqués ci-après , le superutilisateur crée trois 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.

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, ces derniers peuvent être configurés facilement. Example 3–1l' utilisation de rôles basés sur le ARMOR standard. En plus ou en remplacement des rôles ARMOR, vous pouvez créer vos propres rôles en fonction des profils de droits fournis par Oracle Solaris.

root : rôle puissant, équivalent à l'utilisateur root. Cependant, à l'instar de tous les rôles, le rôle root ne peut pas se connecter. Un utilisateur standard doit se connecter, puis prendre le rôle root qui lui est affecté. Ce rôle est configuré et affecté à l'utilisateur initial par défaut.
System Administrator : 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.
Operator : rôle d'administrateur junior permettant d'effectuer des opérations telles que la gestion d'imprimantes et de sauvegardes.

Remarque - Le profil de droits Media Backup permet d'accéder à la totalité du système de fichiers root. 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).

Notez que les rôles n'est pas nécessaire de mettre en oeuvre. 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. Vous pouvez également affecter des profils de droits directement de créer des rôles aux utilisateurs et pas du tout.

Le modèle superutilisateur et le modèle de droits peuvent coexister. Le tableau suivant résume les différents degrés (du superutilisateur à l'utilisateur standard limité) possibles dans le modèle de droits. 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, c'est - à - dire des droits des processus, reportez-vous au Table 1 -2 des privilèges. Table 1–2

Table 1-1 Droits du modèle modèle de superutilisateur par rapport

Capacités d'un utilisateur sur un système	Modèle superutilisateur	Modèle de droits
Peut devenir superutilisateur avec tous les privilèges correspondants	Peut	Peut
Peut se connecter en tant qu'utilisateur disposant des droits utilisateur complets	Peut	Peut
Peut devenir superutilisateur avec des droits limités	Ne peut pas	Peut
Peut se connecter en tant qu'utilisateur et disposer des privilèges superutilisateur sporadiquement	Peut, avec les programmes `setuid root` uniquement	Peut, avec les programmes `setuid root` et avec des droits
Peut se connecter en tant qu'utilisateur disposant des droits d'administration, mais sans les privilèges superutilisateur complets	Ne peut pas	Pouvez, si vous disposez de profils de droits, des rôles ou avec les autorisations et privilèges affectés directement
Peut se connecter en tant qu'utilisateur disposant de moins de droits qu'un utilisateur standard	Ne peut pas	La suppression de droits peut, par
Peut suivre les actions superutilisateur	Peut, par l'audit de la commande `su`	Peut, par l'audit des appels à `pfexec()` En outre, le nom de l'utilisateur qui a pris le rôle `root` se trouve dans la piste d'audit.