SoD, делегирование и deny-гранты

Безопасность доступа держится на трёх механизмах, каждый разобран ниже в своём разделе: разделение обязанностей (SoD), делегирование и deny-гранты.

Разделение обязанностей (SoD)

Разделение обязанностей (Separation of Duties) не позволяет одному человеку совмещать права, которые по регламенту должны быть у разных людей. Классические пары:

• тот, кто вводит данные (data.enter), не должен их верифицировать (data.sdv.verify);
• автор правок дизайна (studyversion.update) не должен сам их утверждать (studyversion.approve);
• тот, кто раздаёт доступ (access.grant), под контролем при совмещении с правкой данных.

Каждое SoD-правило — это данные (пара конфликтующих разрешений + политика), настраиваемые под регламент вашего спонсора. Есть две политики:

Политика	Что делает система
block	жёстко отклоняет выдачу: обойти запрет нельзя, нужно изменить область действия, роль или набор прав
warn	выполняет операцию, но предупреждает о конфликте; факт совмещения фиксируется в аудите

Когда сработает предупреждение SoD

Проверка идёт в момент выдачи гранта или назначения роли — по эффективным правам принципала, а не по составу одной роли. Поэтому конфликт ловится, даже если он складывается из двух по отдельности «чистых» ролей: иначе SoD обходился бы тривиально. При политике warn вы увидите «Создано, но есть SoD-предупреждения» с формулировкой конфликта; при block — «Комбинация запрещена политикой SoD (block)».

SoD на актах утверждения — политика, не константа

Правило «утверждает не автор» для актов утверждения (версия дизайна, словарь перевода) включается настройкой «Строгое разделение обязанностей при утверждении» (core.sod.strict_approvals) — на весь арендатор или на отдельное исследование (Администрирование → Настройки).

• По умолчанию — мягко: автор может утвердить собственную работу; система всегда помечает факт самоутверждения в аудите (self_approved) — след не зависит от политики.
• Строгий режим: утвердить дизайн или перевод может только другой человек. Если утвердить пытается автор, система прямо подсказывает — «Утвердить должен другой пользователь с правом studyversion.approve» — со ссылкой «Настроить доступ».

Строгий режим уместен, когда его требует регламент спонсора или ваша СМК; мягкий — для команд, где вторая пара рук не предусмотрена процессом. Пара на выдаче прав studyversion.update × studyversion.approve следует той же политике: в мягком режиме выдача проходит с предупреждением (иначе право утверждать нельзя было бы даже выдать автору). Остальные пары — прежде всего data.enter × data.sdv.verify — от настройки не зависят.

Малые организации: документированное исключение

В строгом режиме второй пары рук для утверждения может просто не быть — например, в исследовании, инициированном исследователем, или в CRO из одного-двух человек (если строгий режим не требуется вовсе, проще его не включать — см. политику выше). Руководства по целостности данных (PIC/S PI 041, MHRA GxP Data Integrity) допускают отступление от разделения обязанностей в таких случаях — но задокументированное и авторизованное, а не молчаливое.

В X7 Insight носитель такого отступления — обычный грант специального права:

• studyversion.self_approve — автор версии дизайна может утвердить её сам;
• translation.self_approve — переводчик может утвердить собственный перевод.

Правила выдачи жёсткие, и обойти их нельзя:

• выдать себе нельзя — исключение авторизует другой человек (в организации из одного человека — представитель спонсора, QA-консультант или администратор платформы): принцип «четырёх глаз» не отменяется, а смещается с акта утверждения на акт разрешения;
• срок обязателен (valid_to) — бессрочных исключений не бывает; по истечении дверь закрывается сама;
• причина обязательна — укажите ссылку на оценку риска в вашей СМК;
• в роль не кладётся — право персонально, выдаётся только прямым грантом.

Что происходит дальше: автор с действующим исключением утверждает свою версию, а система помечает факт самоутверждения в аудите (self_approved) — инспектор увидит его первым. Блокирующая пара studyversion.update × studyversion.approve при действующем исключении понижается до предупреждения: права выдаются, конфликт остаётся видимым.

Что не ослабляется никогда

Пара data.enter × data.sdv.verify исключений не имеет: верификация первичных данных (SDV) — это сверка с первоисточником вторым лицом. Человек, сверяющий собственный ввод, не выполняет SDV. Также в строгом режиме не ослабляется запрет утверждать версию с незафиксированным автором.

Делегирование (замещение коллеги)

Делегирование — это когда вы временно передаёте свои права замещающему (например, монитор уходит в отпуск и коллега подхватывает его центры). Делегирование подчиняется строгим правилам:

• передать можно только подмножество собственных эффективных прав (⊆ ваших прав) и только в подмножество вашей области действия;
• глубина — один уровень: тот, кому делегировали, не может делегировать дальше;
• срок делегирования не превышает срок ваших собственных прав;
• при отзыве или истечении ваших прав делегированное каскадно отзывается автоматически.

1. В зоне Администрирование → Доступ оформите замещающему временное назначение той же роли на тот же (или более узкий) scope.

2. Задайте даты «с — по» — замещение действует ровно в этом окне.

3. По окончании отпуска доступ прекращается сам (или отзывается вручную).

Личная подпись не делегируется

Делегирование передаёт разрешения, но не личную ответственность. Право подписывать можно передать, а вот саму электронную подпись всегда ставит конкретный человек с повторной аутентификацией. «Подписаться за коллегу» невозможно ни при каком делегировании.

Deny-гранты: запрет всегда побеждает

Deny-грант — это точечный запрет конкретного разрешения конкретному принципалу в конкретном scope. Его отличительное свойство: deny побеждает любой grant на пути. Даже если у человека есть широкая роль, дающая это право, точечный deny его перекроет.

Deny-гранты — хирургический инструмент для исключений: конфликт интересов, служебное расследование, временное ограничение. Пример: запретить одному координатору data.update на одном центре, не трогая его роль и не затрагивая остальные центры.

1. Откройте карточку человека в Администрирование → Пользователи и нажмите «Выдать право».

2. Укажите право и где оно действует, а в поле «Что делает» выберите «Запретить — запрет побеждает любое разрешение».

3. Подтвердите. Система предупредит: «Запрет побеждает любое разрешение на пути: это точечное исключение, которое не перекроет ни одна роль».

Как читается решение о доступе

Движок доступа детерминирован и объясним. По любому запросу он собирает все применимые гранты по префиксам областей (scope) и решает так: если есть хотя бы один deny → запрещено; иначе если есть хотя бы один grant → разрешено; иначе запрещено по умолчанию (default deny). Порядок выдачи не важен — результат всегда один и тот же.

Отлаживайте deny через «Проверить доступ»

Точечные deny легко забыть, и тогда «пропавший» доступ выглядит загадочно. Не гадайте: инструмент «Проверить доступ» (Администрирование → Пользователи) покажет итог по каждому разрешению и источник решения — включая победивший deny. См. Управление доступом.