Comparaison entre les groupes définis dans le système d'exploitation et l'autorisation de liste de contrôle d'accès

Au lieu d'affecter des utilisateurs à plusieurs groupes définis dans le système d'exploitation, les listes de contrôle d'accès vous permettent d'affecter des éléments à plusieurs groupes, vous simplifiant l'administration des autorisations.

Groupes définis dans le système d'exploitation

Dans les versions 8.0 et antérieures de ClearCase, chaque élément VOB dispose de trois catégories de protection : propriétaire, groupe et autre. Pour chaque catégorie, l'administrateur peut définir ou effacer les bits de lecture et d'exécution. Par exemple, si vous disposez d'un fichier source qui doit être accessible en lecture au propriétaire et aux membres du groupe d'éléments, mais pas aux à tous les utilisateurs du réseau, vous vous devez définir propriétaire=lecture, groupe=lecture, autre=aucun. si vous disposez d'un fichier exécutable pour un outil de programmation, vous pouvez éventuellement définir les trois catégories sur lecture et exécution.

En pratique, si vous utilisez ce modèle, vous devez utiliser un groupe distinct pour chaque classe d'éléments qui partage la même protection. Si vous ne souhaitez pas autoriser tous les utilisateurs à lire les éléments présents dans votre VOB, alors définissez autre=aucun et contrôlez les accès à l'aide des catégories propriétaire et groupe.

L'utilité de l'élément propriétaire en termes de protection des éléments est relativement limitée. Seul le groupe dispose d'un contrôle effectif. Par défaut, le propriétaire d'un élément correspond au compte utilisateur qui a créé l'élément. Si vous disposez de plusieurs développeurs, alors les propriétaires des éléments vont changer sans cesse, ce qui n'est pas pratique pour le contrôle d'accès. Certains administrateurs configurent un déclencheur permettant de transférer la propriété au compte du propriétaire de la VOB après la création d'un élément mais ceci n'est pas pratique non plus pour le contrôle des accès, étant donné que la plupart des utilisateurs ne prennent que très rarement l'identité du propriétaire de la VOB.

Ce qui laisse le groupe de l'élément comme mécanisme de contrôle d'accès à chaque élément. L'administrateur doit définir un groupe distinct pour chaque classe d'élément nécessitant une protection. Par exemple, la classe d'éléments 1 est celle des développeurs du composant A ; la classe d'éléments 2 est celle des développeurs du composant B ; et la classe d'éléments 3 est celle regroupant tous les développeurs (code partagé). Si vous possédez 25 composants (de A à Y) et un composant partagé (Z), il vous faudra 26 groupes pour contrôler les accès. Vous protégez tous les éléments du composant A en le rendant accessible en lecture au groupe A uniquement. Même chose pour les composants B à Y. Chaque développeur d'un composant compris entre A et Y est un membre dudit groupe, et en plus membre du groupe Z. Le compte permettant de générer et d'intégrer tout le code doit être membre de tous les groupes de A à Z.

Les groupes utilisés par ClearCase sont définis par le système d'exploitation (Domaine Windows, UNIX NIS ou LDAP) et sont ajoutés aux données d'identification d'un utilisateur lorsqu'il se connecte à un hôte exécutant ClearCase. Malheureusement, du fait des limitations des protocoles de réseau utilisés dans le système d'exploitation et dans ClearCase, un utilisateur unique ne peut utiliser que 16 groupes (UNIX et Linux) ou 32 groupes (Windows) à la fois quand il utilise ClearCase. Dans l'exemple ci-dessus, le compte de génération/intégration doit utiliser 26 groupes pour effectuer la génération, soit en réalisant une alternance complexe entre étapes de génération et données d'identification selon les groupes à activer dans ClearCase, soit en compromettant l'implémentation de la sécurité de vos éléments et en utilisant moins de classes et de groupes d'élément. Aucune de ces options ne fait envie.

Listes de contrôle d'accès sur des éléments

Si vous activez les listes de contrôle d'accès pour protéger des éléments qui se trouvent dans une VOB à niveau de fonctionnalité 8 dans ClearCase 8.0.1, vous pouvez alors modifier la stratégie de contrôle d'accès afin d'éliminer les nombreux cas où vous accédez aux limites d'appartenance définies par groupe d'utilisateurs. Il peut être utile de penser aux listes de contrôle d'accès pour vous aider à placer les éléments dans plusieurs groupes au lieu de devoir placer des utilisateurs dans plusieurs groupes. Etant donné que le nombre de groupes autorisés dans la liste de contrôle d'accès effective d'un élément n'est pas soumis à la même limite basse que le nombre de groupes pour un compte utilisateur, ce mécanisme de sécurité active de nouveaux cas de protection à l'utilisation et simplifie les autres.

Grâce à ces listes de contrôle d'accès sur éléments vous pouvez accorder l'accès à plusieurs utilisateurs individuels, à plusieurs groupes et à quelques catégories incluant d'autres utilisateurs. Cette rubrique traite des listes de contrôle d'accès sur éléments en termes de listes de listes de contrôles d'accès effectives. Dans cette rubrique et dans celles associées se trouvent des exemples de combinaison de mappages de rôle et de règles afin de générer des listes de contrôle d'accès effectives.

Dans l'exemple ci-dessus, il y avait 25 composants classés de A à Y, chacun étant utilisé par une équipe différente et par une compte de génération ("générateurs"). Personne d'autre ne doit y a avoir accès. Grâce aux listes de contrôle d'accès effectives, vous pouvez protéger chaque élément d'un composant donné en en partageant une accordant les droits Modification au groupe A et aux générateurs.

Chaque autre composant compris entre B et Y doit disposer d'une liste de contrôle d'accès effective similaire. Le composant Z (le composant partagé) dispose également d'une liste de contrôle d'accès effective similaire. Avec cette configuration, chaque compte de membre d'équipe se trouve dans le groupe correspondant à son composant et dans le groupe Z (comme avant). Toutefois, le compte de génération ne doit se trouver que dans le groupe de "générateurs". Vous ne vous heurtez plus aux limites d'appartenance simultanées à des groupes pour le compte de génération.

De plus, vous n'avez plus besoin d'utiliser des stratégies complexes pendant la génération du système, ni même de compromettre la sécurité des composants A à Y. Vous obtenez également la possibilité d'ajouter des groupes supplémentaires et de rendre disponibles les éléments en lecture seule. Partons du principe que le composant Z est conservé par sa propre équipe mais que les équipes A à Y ne doivent qu'y faire référence, et que vous placez les développeurs ne travaillant pas sur le composant Z dans le groupe "tous les développeurs" au lieu du "groupe Z". Vous pouvez configurer la liste de contrôle d'accès du composant Z afin que le groupe Z dispose des droits Modification, que le groupe tous_développeurs dispose de droits Lecture et que les générateurs disposent des droits Modification.

Un développeur de l'équipe A pourra lire les éléments dans le composant Z, mais il ne pourra pas les modifier. (Sans les listes de contrôle d'accès, il aurait fallu effectuer un emprunt avant opération et disposer d'un déclencheur mkbranch afin de vérifier son droit de modifier l'élément, puis rejeter une opération si elle n'avait pas été autorisée.)

Vous pouvez également placer des comptes individuels dans les listes de contrôle d'accès des éléments. Ce processus peut être utile s'il existe quelques individus qui ont besoin d'un accès spécifique à un composant, si jamais l'intérêt de créer un groupe dans le système d'exploitation simplement pour ce but était limité. Ainsi, si le composant B doit être disponible en modification pour son équipe plus un autre utilisateur ("utilisateur_supplémentaire"), la liste de contrôle d'accès doit alors accorder des droits Modification au groupe B, à l'utilisateur supplémentaire et aux générateurs.

Si certains composants sont conservés par plusieurs équipes, vous pouvez éventuellement éliminer certains des groupes utilisés précédemment. Partons du principe que le composant E a été géré par tous les membres des équipes travaillant sur les composants C et D. Dans l'exemple de la version 8.0, il fallait un groupe E pour inclure tous les membres des groupes C et D. Désormais, vous pouvez configurer la liste de contrôle d'accès du composant E pour y indiquer ces deux groupes, puis ne plus utiliser le groupe E (autrement, le supprimer de la liste des groupes pour les comptes inclus dans les équipes C et D).

Règle A et mappages de rôle associés

La description énoncée plus haut traite de listes de contrôle d'accès effectives. Dans une VOB, la liste de contrôle d'accès effective est générée en associant un mappage de rôle à une règle. La base de données VOB calcule la liste de contrôle d'accès effective pour chaque mappage de rôle et la met en mémoire cache. Chaque élément est associé à un mappage de rôle. Pour implémenter les exemples ci-dessus, il vous faut un mappage de rôle distinct pour chaque classe d'éléments (composants A à Z). Vous pouvez lier tous ces mappages de rôle à une unique règle qui décrit votre modèle général de protection. Ci-dessous se trouvent un exemple de règle et un ensemble de mappages de rôle qui utilisent les listes de contrôle d'accès effectives montrées plus haut. (En pratique, vous souhaiterez probablement ajouter un administrateur ou un groupe d'administration pour qu'ils disposent d'un contrôle complet sur les éléments.)


Commentaires