Автор статьи
В одной из прошлых статей мы разбирали, зачем нужна матрица ролей и прав доступа и как её составлять (Матрица ролей и прав доступа: кому можно всё, а кому ничего). Когда мы дошли до роли администратора, за кадром остался вопрос, который на инспекциях всплывает едва ли не чаще самой матрицы: а кто, собственно, этим администратором может и должен быть?
Спросите в пяти разных лабораториях, и получите пять разных ответов. Где-то права администратора у ведущего химика, потому что он лучше всех знает хроматограф. Где-то у руководителя лаборатории, потому что «он же материально ответственное лицо». Где-то у инженера по обслуживанию лабораторного оборудования, у нескольких человек сразу, а в организациях позрелее администрирование забрал себе ИТ-департамент. Встречается и модель, где постоянного администратора на площадке нет вовсе: административные действия по заявке выполняет сервисный специалист поставщика или производителя, и каждое действие документируется.
Должность сама по себе ни один из этих вариантов не оправдывает и не отменяет. Вопрос надо ставить иначе: какие принципы мы соблюдаем или нарушаем, отдавая права именно этому человеку.
Чем администратор отличается от обычного пользователя
Обычный пользователь работает внутри контролируемой среды. Администратор эту среду меняет. В зависимости от конкретной системы он может создавать и удалять учётные записи, перекраивать роли и права, менять параметры системы и настройки оборудования, управлять аудиторским следом, а кое-где — редактировать или удалять сами данные и добираться до функций, о существовании которых рядовой пользователь не подозревает.
Четыре типовые модели и что с ними не так
Ведущий аналитик. Самый естественный кандидат с точки зрения лаборатории: знает прибор, знает софт, знает процесс. И самый проблемный с точки зрения целостности данных. Один и тот же человек оказывается пользователем системы и её администратором, то есть контролирует и контролируемого в одном лице. Эта конфигурация неоднократно становилась предметом замечаний FDA, причём годы идут, а картина не меняется.
Adamson Analytical Laboratories, август 2021 года: у лабораторного персонала админ-привилегии в софте газовых хроматографов, включая удаление последовательностей, правку методов и включение-выключение аудиторского следа. Сам след при этом не работал как минимум с апреля 2018 по февраль 2021 года.
Ava Inc., апрель 2026: общие логин и пароль к ВЭЖХ для испытаний на примеси, у аналитиков права администратора на изменение и удаление данных, а в корзине компьютера инспекторы обнаружили удалённые GC-последовательности, в том числе по проверке пригодности системы.
Четыре с половиной года между письмами, ошибка одна и та же.
Руководитель группы или лаборатории. Выглядит управленчески логично, но конфликт тот же, только этажом выше. Руководитель отвечает за результаты испытаний. За результаты — не за учётные записи. А техническая возможность менять среду, в которой формируются результаты, за которые ты же и отвечаешь, это ровно тот конфликт интересов, который руководства по целостности данных просят исключить.
Инженер. Занимается оборудованием, значит нужен расширенный доступ — логика понятная, и на практике этот вариант встречается постоянно. Только смотреть здесь надо не на слово «инженер», а на то, кому он подчиняется, кто ставит ему приоритеты и кто может поручить ему «поправить настройки».
Сотрудник ИТ. ИТ обычно лучше соответствует принципу независимости: он не пользователь системы и не заинтересован в конкретном результате анализа. Есть условие, о котором любят забывать. Администратор из ИТ должен хотя бы в общих чертах понимать, что за система перед ним, зачем нужен этот прибор, что произойдёт с данными и с лабораторией, если он поменяет настройку. Превращать айтишника в химика никто не требует. Достаточно, чтобы техническое администрирование не выполнялось вслепую, без понимания процесса, который человек фактически изменяет.
Что говорят регуляторы
Ни один документ не пишет «администратором должен быть специалист ИТ». Регуляторы формулируют принципы, а не штатное расписание.
Отправная точка сформулирована в самих правилах GMP, задолго до всех руководств по целостности данных. Правила надлежащей производственной практики ЕАЭС (Решение Совета ЕЭК № 77 от 03.11.2016), часть I, пункт 6.1 — та же норма стоит в главе 6 EU GMP:
У каждого производителя должно быть подразделение контроля качества, независимое от других подразделений и отделов.
Требование к доступу в компьютеризированные системы закреплено там же, в Приложении 11, разделе 12 «Защита»: доступ ограничивается кругом уполномоченных лиц, а создание, изменение и отмена прав доступа регистрируются.
Агентство по регулированию лекарственных средств и медицинских изделий Великобритании (MHRA) в GXP Data Integrity Guidance, раздел 6.16 «Computerised system user access / system administrator roles», требует ограничить административный доступ минимально возможным числом людей с учётом размера и характера организации — и прямо запрещает выдавать права администратора лицам, имеющим прямую заинтересованность в данных. Раздел 6.13 того же документа добавляет: пользователи не должны иметь возможность править или отключать аудиторский след, а если это делает администратор, запись о таком действии сохраняется.
FDA в руководстве Data Integrity and Compliance With Drug cGMP: Questions and Answers в вопросе 4 «How should access to CGMP computer systems be restricted?» говорит то же самое почти дословно: роль системного администратора, включая любые права на изменение файлов и настроек, следует назначать персоналу, независимому от ответственных за содержание записей. Там же есть оговорка, которая пригодится небольшим лабораториям: если независимое назначение невозможно, нужны документированные альтернативные меры контроля — например, проверка настроек и содержимого вторым лицом.
Руководство Системы сотрудничества по фармацевтическим инспекциям (PIC/S) PI 041-1 Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments разворачивает тему шире всех: раздел 9.5 о безопасности систем требует строгого разделения обязанностей, при котором администраторы независимы от пользователей лаборатории, ограничивает избыточные права рядовых пользователей и отдельно разбирает общие учётные записи.
ВОЗ в руководстве по целостности данных (TRS 1033, Annex 4, 2021) встраивает те же требования в общую систему управления данными (data governance): предусматриваются иерархия прав пользователей, ограничение доступа уполномоченными лицами, идентификация операторов и регистрация изменений прав доступа.
Для работающих по праву Китайской Народной Республики фундамент тот же. Государственное управление по контролю за фармацевтической продукцией КНР (NMPA) в Требованиях к управлению записями и данными о лекарственных средствах в статье 22 требует для электронных записей раздельных прав на выполнение операций и на системное администрирование: права пользователя, ответственного за бизнес-процесс, должны соответствовать его обязанностям и не должны включать права администратора системы — включая операционную систему, прикладные программы и базы данных.
И наконец свежий штрих. В проекте новой редакции Приложения 11 к GMP EU разделению обязанностей между администраторами и GMP-пользователями посвящён отдельный пункт в разделе про управление доступом.
То, что раньше приходилось выводить из общих принципов, скоро будет написано прямым текстом.
Сложим перечень в один вывод. Права администратора компьютеризированной системы контроля качества выдаются минимально возможному числу людей, независимых от тех, кто отвечает за содержание записей, то есть от сотрудников контроля качества, — и одновременно независимых от производства.
Скрытый риск: оргструктура, которая всё обнуляет
А теперь самая недооценённая часть. Допустим, компания всё сделала «правильно»: у аналитиков прав нет, у начальника лаборатории нет, администрирует ИТ. Матрица чистая, инспектор доволен. Смотрим на организационную схему.
Генеральному директору подчиняются два блока: качество и производство. В блоке качества — обеспечение качества, контроль качества, уполномоченные лица. В блоке производства — само производство, инженерная служба и… информационные технологии.
Формально требование выполнено: аналитик не администратор. Фактически человек с полным доступом к лабораторным системам сидит в подчинении у директора по производству. Того самого производства, чью продукцию лаборатория бракует.
Я называю это обходом принципа независимости через организационную структуру. Проверяется он одним вопросом, который я рекомендую задавать себе при любой оценке модели администрирования: если завтра между производством и лабораторией возникнет спор по результатам испытаний, на чьей стороне окажется человек с административными правами — исходя из того, кто подписывает ему премию?
PIC/S прямо указывает, что при оценке целостности данных необходимо учитывать организационные факторы, культуру, влияние иерархии и заинтересованность лиц в результате.
Должность в этой проверке ничего не решает. Решает положение человека в системе координат: кому подчиняется, кто определяет приоритеты, кто оценивает его работу, насколько он зависим от пользователей системы и их руководителей.
Когда система вообще не позволяет разделить роли
Отдельная и очень земная проблема. Не всякий софт лабораторного прибора дорос до ролевой модели. У старого или узкоспециализированного оборудования нередко одна учётная запись на всех, административные функции перемешаны с пользовательскими, аудиторского следа нет и не предвидится. Механически натянуть идеальную схему разделения ролей на такую систему физически не получится.
Принцип здесь такой: если техническое разделение ролей невозможно, контроль никуда не исчезает, он переезжает в организационную плоскость. Компенсирующие меры известны: физическое ограничение доступа к рабочей станции, узкий и поимённо определённый круг допущенных, журналирование административных действий, контроль изменений, независимая проверка настроек, периодический пересмотр доступа, надзор за действиями сервисного специалиста. Скучно, вручную, зато работает, и инспектор это понимает. Понимает он и обратное: когда меры существуют только на бумаге.
Для маленьких автономных систем PIC/S в PI 041-1 прямо допускает упрощённую модель всего из двух ролей, но с условием: аудиторский след должен фиксировать действия каждой роли так, чтобы конфликт интересов был виден.
Рассчитывать, что компенсирующие меры будут устраивать регуляторов вечно, не стоит. MHRA ещё в руководстве 2018 года зафиксировало ожидание, что компании смогут продемонстрировать движение к системам с индивидуальным входом и аудиторским следом, а альтернативные меры для устаревших систем должны быть доказанно эффективными. Так что закупку оборудования, отвечающего современным требованиям к управлению доступом, разумно закладывать в бюджет уже сейчас, не дожидаясь замечания.
Как в итоге принимать решение
Модель администрирования нельзя выбирать по должностной инструкции. Оценивать её нужно сразу на трёх уровнях.
- Технический: что конкретно может сделать администратор в этой системе — завести пользователя или переписать историю?
- Организационный: насколько администратор независим от тех, кто в системе работает, и от их руководителей, включая подчинённость на схеме оргструктуры?
- Регуляторный: выдерживает ли модель принципы разделения обязанностей, минимально необходимых прав и независимости контроля качества?
Одна и та же модель на разных системах даст разный риск: зависит от возможностей софта, критичности данных, наличия аудиторского следа, числа пользователей. Поэтому «инженер — плохо, ИТ — хорошо» не работает как правило. Работает вопрос: какие реальные возможности даёт административная роль и какие барьеры стоят между этими возможностями и соблазном ими воспользоваться.
Кто бы ни оказался администратором по должности, модель обязана обеспечивать независимость, разделение обязанностей и защиту данных, на которых держится решение о качестве продукта.
