Permissions Comparison

Ce que c'est et pourquoi il existe

Dans IBM Engineering Lifecycle Management, ce qu'un utilisateur peut faire dans un projet dépend des rôles de la zone de projet et des permissions de chaque rôle : qui peut créer ou supprimer des artefacts, modifier un module, approuver une revue, créer une ligne de base ou livrer un ensemble de modifications. Les zones d'équipe, les chronologies et les itérations peuvent encore modifier ces permissions pour leur partie du projet.

Les organisations démarrent généralement chaque projet à partir du même modèle de processus, puis les projets divergent. Un projet permet aux auteurs de supprimer des artefacts, un autre donne à une zone d'équipe ses propres permissions, un troisième possède un rôle que les autres n'ont pas. Le client web n'affiche les permissions que d'une zone de projet à la fois : trouver ces différences oblige donc à ouvrir les mêmes écrans côte à côte, rôle par rôle. Permissions Comparison les lit pour vous et ne liste que ce qui diffère.

Problèmes résolus

• Des zones de projet créées à partir du même modèle dont les permissions ne correspondent plus, sans que personne ne sache où.
• Des revues d'accès qui imposent de vérifier à la main chaque rôle dans chaque zone de projet.
• Des zones d'équipe ou des itérations qui donnent discrètement à un rôle plus, ou moins, de permissions que la zone de projet.
• Aucune preuve à montrer à un auditeur que les rôles et permissions documentés sont bien ceux configurés sur le serveur.

Pourquoi c'est important pour les normes et les audits

Les normes de développement réglementé ou lié à la sécurité citent rarement un outil, mais elles exigent que seules les personnes autorisées puissent modifier les enregistrements contrôlés et que vous puissiez montrer qui peut faire quoi. Dans une zone de projet ELM, ce contrôle, ce sont les permissions des rôles. Permissions Comparison permet de vérifier qu'il est le même dans chaque projet et qu'il correspond à votre processus documenté.

• FDA 21 CFR Part 11 (enregistrements électroniques dans les dispositifs médicaux et l'industrie pharmaceutique) : le § 11.10(d) demande « limiting system access to authorized individuals » (limiter l'accès au système aux personnes autorisées), et le § 11.10(g) des contrôles d'autorité, afin que seules les personnes autorisées puissent modifier un enregistrement ou effectuer l'opération concernée. La comparaison montre, par zone de projet, quel rôle peut effectuer quelle opération.
• ISO/IEC 27001:2022 : les mesures de l'Annexe A 5.15 Access control, 5.18 Access rights, 5.3 Segregation of duties et 8.2 Privileged access rights. Les droits d'accès doivent être revus régulièrement et les tâches incompatibles séparées, par exemple le rôle qui rédige une exigence et le rôle qui l'approuve. Le rapport Excel garde la trace de ce qui a été revu et quand.
• ISO 26262, Automotive SPICE, DO-178C et IEC 62304 : les quatre exigent la gestion de configuration et la gestion des modifications des produits d'activité tels que les exigences (ISO 26262 Part 8, SUP.8 et SUP.10 dans Automotive SPICE, la section 7 de DO-178C, l'article 8 de l'IEC 62304). Dans DOORS Next, une partie de ce contrôle porte sur les rôles autorisés à modifier les artefacts, créer des lignes de base et livrer des modifications. Un projet dont les rôles autorisent plus que ce que décrit le processus est un constat d'audit classique.

Un évaluateur examine un échantillon de projets et attend le même processus dans chacun. Comparez chaque zone de projet avec votre projet de référence avant l'évaluation, et vous verrez les différences en premier.

Avantages

• Toutes les différences dans une seule liste : les rôles, leur ordre et leur cardinalité, et chaque permission autorisée d'un côté et pas de l'autre, pour la zone de projet, les zones d'équipe et, si vous le souhaitez, les chronologies et les itérations.
• Une source, plusieurs cibles : comparez une zone de projet de référence avec jusqu'à 25 autres de la même application.
• Fonctionne dans toutes les applications ELM : DOORS Next, Workflow Management (EWM), Test Management (ETM) et Global Configuration, depuis un ELM Mini Dashboard.
• Rapport Excel avec la matrice complète des permissions, prêt pour une revue des accès ou un dossier d'audit.
• Lecture seule : le widget lit et ne modifie jamais une permission.

Utilisation

1. Dans Settings, choisissez de comparer ou non les zones d'équipe (activé au départ) et les chronologies et itérations (désactivé au départ).
2. Sous Compare, choisissez l'Application. From est la source : sur un tableau de bord DOORS Next, elle part du projet ouvert, et Change choisit une autre zone de projet.
3. Sous To, cliquez sur Add, cochez jusqu'à 25 zones de projet (la recherche, Select all et Show archived vous aident) et cliquez sur Apply.
4. Cliquez sur Compare. Le bloc de résultat indique le nombre de différences, par catégorie ou par cible, et les cibles qui n'ont pas pu être lues, avec Retry.
5. Sous Differences, choisissez une cible s'il y en a plusieurs, puis Roles ou Permissions. Les permissions sont regroupées par rôle et par niveau, par exemple Author / Team area: Business Recovery. Cliquez sur une ligne pour voir les deux côtés.
6. Cliquez sur Export to Excel dans le bloc de résultat pour enregistrer la comparaison complète.

Bon à savoir

• Les rôles sont mis en correspondance par identifiant, puis par nom : un rôle de même nom avec un autre identifiant compte donc comme le même rôle. L'ordre des rôles est comparé, car un utilisateur qui a plusieurs rôles obtient la permission du premier rôle qui l'autorise.
• Le widget compare les rôles et leurs permissions, pas les personnes qui les détiennent. User Audit liste quels utilisateurs ont quels rôles.
• Une zone d'équipe, une chronologie ou une itération où un seul côté donne à un rôle ses propres permissions est signalée sur une seule ligne, et non comme une longue liste de différences de permissions.
• Moments typiques pour l'utiliser : avant un audit ou une évaluation, après une modification du modèle de processus et lors de la création d'un nouveau projet à partir d'un modèle.
• Le widget ne rend pas un projet conforme. Il vous donne les faits pour vérifier que les permissions correspondent à votre processus documenté, et un rapport à conserver comme preuve.