Permissions Comparison

Что это и зачем

В IBM Engineering Lifecycle Management то, что пользователь может делать в проекте, зависит от ролей области проекта и разрешений каждой роли: кто может создавать или удалять артефакты, изменять модуль, утверждать проверку, создавать базовую линию или поставлять набор изменений. Области команд, временные шкалы и итерации могут ещё раз изменить эти разрешения для своей части проекта.

Обычно организации создают все проекты из одного шаблона процесса, а затем проекты постепенно расходятся. В одном проекте авторам разрешено удалять артефакты, в другом у области команды свои разрешения, в третьем есть роль, которой нет у остальных. Веб-клиент показывает разрешения только одной области проекта за раз, поэтому, чтобы найти такие различия, приходится открывать одни и те же экраны рядом и проходить роль за ролью. Permissions Comparison считывает их за вас и показывает только то, что отличается.

Какие проблемы решает

• Области проектов, созданные из одного шаблона, разрешения которых больше не совпадают, причём никто не знает, где именно.
• Проверки доступа, при которых каждую роль в каждой области проекта приходится проверять вручную.
• Области команд или итерации, которые незаметно дают роли больше или меньше разрешений, чем область проекта.
• Нет доказательств для аудитора, что задокументированные роли и разрешения совпадают с настроенными на сервере.

Почему это важно для стандартов и аудитов

Стандарты для регулируемой разработки и разработки, связанной с безопасностью, редко называют конкретный инструмент, но ожидают, что изменять контролируемые записи могут только уполномоченные лица и что вы можете показать, кому что разрешено. В области проекта ELM этот контроль обеспечивают разрешения ролей. Permissions Comparison позволяет проверить, что он одинаков во всех проектах и соответствует вашему задокументированному процессу.

• FDA 21 CFR Part 11 (электронные записи в медицинских изделиях и фармацевтике): § 11.10(d) требует "limiting system access to authorized individuals" (ограничения доступа к системе уполномоченными лицами), а § 11.10(g) требует проверки полномочий, чтобы только уполномоченные лица могли изменить запись или выполнить соответствующую операцию. Сравнение показывает для каждой области проекта, какая роль может выполнять какую операцию.
• ISO/IEC 27001:2022: меры приложения A 5.15 Access control, 5.18 Access rights, 5.3 Segregation of duties и 8.2 Privileged access rights. Права доступа нужно регулярно пересматривать, а конфликтующие обязанности разделять, например роль, которая пишет требование, и роль, которая его утверждает. Отчёт в Excel фиксирует, что и когда было проверено.
• ISO 26262, Automotive SPICE, DO-178C и IEC 62304: все четыре требуют управления конфигурацией и управления изменениями рабочих продуктов, таких как требования (ISO 26262 Part 8, SUP.8 и SUP.10 в Automotive SPICE, раздел 7 DO-178C, пункт 8 IEC 62304). В DOORS Next часть этого контроля состоит в том, какие роли могут изменять артефакты, создавать базовые линии и поставлять изменения. Проект, роли которого позволяют больше, чем описано в процессе, это типичное замечание аудита.

Асессор проверяет выборку проектов и ожидает в каждом один и тот же процесс. Сравните каждую область проекта с эталонным проектом до оценки, и вы первыми увидите различия.

Преимущества

• Все различия в одном списке: роли, их порядок и кратность, а также каждое разрешение, которое есть с одной стороны и отсутствует с другой, для области проекта, областей команд и при необходимости временных шкал и итераций.
• Один источник, много целей: эталонную область проекта можно сравнить с не более чем 25 другими областями того же приложения.
• Работает во всех приложениях ELM: DOORS Next, Workflow Management (EWM), Test Management (ETM) и Global Configuration, с ELM Mini Dashboard.
• Отчёт в Excel с полной матрицей разрешений, готовый для проверки доступа или аудиторского дела.
• Только чтение: виджет только считывает разрешения и никогда их не меняет.

Как пользоваться

1. В Settings выберите, сравнивать ли области команд (сначала включено) и временные шкалы и итерации (сначала выключено).
2. В разделе Compare выберите Application. From (источник): на дашборде DOORS Next сначала это открытый проект, а Change выбирает другую область проекта.
3. В To нажмите Add, отметьте до 25 областей проектов (помогают поиск, Select all и Show archived) и нажмите Apply.
4. Нажмите Compare. Блок результата показывает число различий по категориям или по целям, а также цели, которые не удалось прочитать, с кнопкой Retry.
5. В разделе Differences выберите цель, если их несколько, затем Roles или Permissions. Разрешения сгруппированы по роли и уровню, например Author / Team area: Business Recovery. Щёлкните строку, чтобы увидеть обе стороны.
6. Нажмите Export to Excel в блоке результата, чтобы сохранить всё сравнение.

Полезно знать

• Роли сопоставляются по идентификатору, затем по имени, поэтому роль с тем же именем и другим идентификатором считается той же ролью. Порядок ролей тоже сравнивается, потому что пользователь с несколькими ролями получает разрешение первой роли, которая его даёт.
• Виджет сравнивает роли и их разрешения, а не то, кому они назначены. Какие пользователи имеют какие роли, показывает User Audit.
• Область команды, временная шкала или итерация, где только одна сторона задаёт роли собственные разрешения, выводится одной строкой, а не длинным списком различий разрешений.
• Типичные моменты для запуска: перед аудитом или оценкой, после изменения шаблона процесса и при создании нового проекта из шаблона.
• Виджет не делает проект соответствующим требованиям. Он даёт факты, чтобы проверить, что разрешения соответствуют задокументированному процессу, и отчёт, который можно сохранить как доказательство.