Автор статьи
В лаборатории контроля качества один и тот же прибор и одна и та же компьютеризированная система обслуживают людей с совершенно разными задачами. Аналитику нужно провести испытание. Ведущему аналитику — создать или изменить инструментальный метод. Руководителю — проверить результат и утвердить протокол. Системному администратору — управлять учётными записями и настройками. Если всем выдать одинаковые права, вопрос будет не в том, произойдёт ли ошибка, а в том, когда она произойдёт.
Поэтому доступ ограничивают.
В информационной безопасности существует принцип минимальных привилегий (англ. Principle of Least Privilege, PoLP), согласно которому пользователь должен иметь только те права, которые необходимы ему для выполнения своих обязанностей. Лишние права убирают по двум причинам: внешнее вмешательство и собственные ошибки, которые оборачиваются несанкционированными изменениями и потерей целостности данных.
Приложение 11 к Правилам GMP ЕАЭС в разделе 12 «Защита» требует ограничивать доступ к компьютеризированной системе кругом уполномоченных лиц и регистрировать создание, изменение и отмену прав доступа. В 21 CFR Part 11 аналогичное требование установлено в §11.10(d): доступ к системе должен быть ограничен уполномоченными лицами.
Оформляется это матрицей ролей и прав доступа (англ. Roles and Permissions Matrix). В простейшем виде это таблица: по строкам — функции системы, по столбцам — роли, на пересечении — наличие или отсутствие права. Матрица разрабатывается на этапе формирования спецификации требований пользователя, проверяется при квалификации системы и далее ведётся как контролируемый документ.
Ролевое управление доступом
Рутинный аналитик включает и выключает систему, запускает инструментальный метод, обрабатывает и просматривает результаты. Редактировать параметры метода, удалять данные и создавать пользователей ему не нужно.
Ведущий аналитик дополнительно создает, редактирует и верифицирует методы, работает с калибровками и просматривает аудиторский след. Права на удаление данных нет и у него. Исключение — очистка системы после переустановки программного обеспечения (см. примечание 1), но это отдельная процедура с обоснованием и, как правило, с участием ИТ.
Руководитель группы сам испытания не проводит, поэтому права рутинного и ведущего аналитика у него отключены (см. примечание 2). Его задача — просмотр данных, отчётов и истории изменений для проверки и утверждения протокола испытания. Редактировать результаты он не может. Иначе его подпись под протоколом ничего не подтверждает: подписывающий сохраняет техническую возможность изменить то, что сам только что утвердил.
Администратор системы создает и блокирует учётные записи, назначает права и конфигурирует систему. Ограничение здесь одно: администраторские права не выдаются тем, кто сам генерирует или утверждает данные в этой системе. Значит, у руководителя группы или лаборатории их быть не должно, хотя на практике выдают их чаще всего именно ему. Кому тогда выдавать административные права, что делать с внешним подрядчиком и как быть, если администратор в компании один на всё, — тема отдельной статьи, ссылка на неё появится здесь позже.
В реальности ролей может быть больше: отдельная для инженера по обслуживанию оборудования, ограниченная по времени роль для внешнего сервисного инженера, роль «только чтение» для подразделения QA. Сколько именно — зависит от системы качества и структуры лаборатории.
Универсального оптимального числа ролей не существует. Задача поиска минимального достаточного набора ролей — отдельное направление исследований в области управления доступом, и однозначного решения она не имеет (подробнее об этой проблеме можно прочитать здесь).
Оптимум лежит между двумя крайностями.
Слишком узкие роли приводят к так называемому «взрыву количества ролей» (англ. Role Explosion): под каждый частный случай заводится своя роль, роли начинают дублировать друг друга, их перестают удалять, и через пару лет матрицу невозможно ни прочитать, ни проверить. Для лаборатории это узнаваемо: методика поменялась, кому-то срочно понадобился доступ, завели роль под конкретный случай и она осталась навсегда.
Слишком широкие роли, наоборот, раздают лишние права и тем самым разрушают сам принцип PoLP: пользователь получает больше доступа, чем необходимо ему для выполнения своих обязанностей.
На практике полезно использовать как минимум два критерия:
- если две роли совпадают по набору прав более чем на 80%, стоит рассмотреть возможность их объединения (скорее всего, это одна роль);
- если назначение роли невозможно однозначно объяснить через обязанности пользователя или выполняемый им процесс, такую роль стоит пересмотреть (см. примечание 3).
Недостаточные права
Про избыточные права пишут много, про недостаточные — почти ничего, хотя ломают они систему не хуже. Если аналитик не может перезапустить обработку и каждый раз идёт за ведущим, через месяц пароль ведущего окажется на стикере под клавиатурой. Правила, которые мешают работать, не соблюдаются, а обходятся. Самый опасный вариантов такого обхода — «общественная учётная запись». Кто именно выполнил действие, установить уже нельзя, а действие, которое не приписать конкретному человеку, для целостности данных не существует.
Поэтому матрицу нельзя составить кабинетно. Пройдите с аналитиком одну смену от включения прибора до печати протокола и отметьте все места, где ему пришлось кого-то звать. Каждое такое место — точка, в которой недостаточные права перестают быть неудобством и становятся риском для целостности данных.
Что смотрит аудитор
Матрица ролей и прав доступа есть почти у всех. Расхождение матрицы с фактическими настройками — тоже почти у всех.
Аудитор просит выгрузить из системы список активных пользователей с назначенными правами, кладёт рядом утвержденную матрицу и документы по личному составу. Дальше находки типовые: уволенные сотрудники с активными учётными записями, переведённые в другое подразделение со старыми правами, общие записи вроде analyst или lab1, подрядчик с полным доступом, выданным на время пусконаладки год назад.
Отдельно проверяется периодический пересмотр прав: предусмотрен ли он процедурой, с какой периодичностью проводится, кто его выполняет и есть ли документальные свидетельства предыдущих пересмотров.
Второй слой — уровень операционной системы.
Матрица доступа для самой операционной системы часто вообще отсутствует. О ней либо забывают, потому что всё внимание сосредоточено на правах внутри лабораторной системы, либо намеренно не создают, оставляя скрытый обходной путь (бэкдор), который позволяет обойти ограничения прикладной системы.
Права внутри хроматографического программного обеспечения могут быть настроены безупречно, но если у всех пользователей есть локальные права администратора, файлы исходных данных можно переносить, переименовывать и удалять в обход приложения, а системное время — изменять вручную.
Поэтому проверять нужно в две стороны: что пользователь может сделать внутри приложения и что он может сделать с данными и самой системой за его пределами.
Чем это заканчивается
В письме-предупреждении FDA компании Ava Inc. от 14 апреля 2026 года описана лаборатория, где на ВЭЖХ системе для определения примесей заходили под общей учётной записью, а аналитики имели администраторские права на изменение и удаление данных. В корзине при этом лежали удалённые последовательности ГХ, включая проверку пригодности системы и испытания стабильности.
Компания объяснила это тем, что сотрудник нарушил процедуру и обучение. FDA объяснение не приняло. В ответ на письмо потребовало перечислить всех, у кого есть администраторские права, и описать, как будет обеспечено разделение персонала, проводящего испытания, и персонала с администраторскими правами. Эта формулировка про разделение переходит из письма в письмо почти дословно.
У Specialty Process Labs в письме от 3 мая 2022 года история короче. Единственной ролью в системе была «System/Administrator», удалять и изменять данные она позволяла без ограничений. В таком виде систему с марта по ноябрь 2021 года использовали для определения подлинности и количественного содержания субстанции тиреоидина.
Начните с малого
Выпишите функции своей системы, сопоставьте их с должностями и напротив каждой пары поставьте «нужно» / «не нужно». Если необходимость права нельзя обосновать, не выдавайте его «на всякий случай». Добавить право по обоснованной заявке быстрее, чем объяснять инспектору, почему у стажёра была возможность удалить проект.
При проверке матрицы достаточно начать с трёх простых вопросов:
Кому? Зачем? Почему именно эти права?
Примечание 1. Речь о ситуации, когда после переустановки программного обеспечения необходимо удалить остатки старой базы данных. Именно поэтому у ведущего аналитика в отдельных случаях всё же может появляться право на удаление, но применяться оно должно в рамках отдельной процедуры, с установленными условиями и контролем.
Примечание 2. Развести роли получается там, где хватает штата. В небольшой лаборатории руководитель нередко сам проводит испытания, и тогда конфликт интересов невозможно устранить только настройкой прав. В этом случае нужны компенсирующие меры: проверку результатов передают сотруднику другого подразделения, чаще всего подразделения обеспечения качества, а периодический просмотр аудиторского следа поручают сотруднику, который руководителю не подчиняется. И то и другое должно быть описано в процедуре, иначе это не мера контроля, а стечение обстоятельств.
Примечание 3. Каждая роль должна иметь понятное функциональное назначение: кто её получает, какие обязанности она обеспечивает и почему именно такой набор прав необходим.
