Керування доступом користувачів (UAM) – ролі та дозволи

Ця тема є частиною SG Systems Global глосарій нормативних та операційних термінів.

Оновлено у жовтні 2025 р. • Контроль доступу, розподіл обов'язків та відповідність вимогам • ІТ/ОТ, забезпечення якості, виробництво, лабораторія

Керування доступом користувачів (UAM) – це управління та контроль того, хто, що, де та коли може робити в регульованих виробничих системах. На практиці UAM перетворює політику на дозволи на основі ролей , які обмежують дії в модулях MES , LIMS , ELN , WMS та QMS, забезпечують мінімальні привілеї та запобігають конфліктам шляхом розподілу обов'язків (SoD) . Оскільки такі рішення, як випуск партій та електронні підписи, мають юридичну силу згідно з 21 CFR Part 11 та EU Annex 11 , UAM лежить в основі цілісності даних і має бути демонстративно ефективним, перевіреним ( CSV ) та аудитованим за допомогою незмінних журналів аудиту.

«У GxP доступ – це рішення щодо якості: кожен дозвіл, який ви надаєте, стає ризиком, який ви повинні контролювати та доводити».

1) Що охоплює UAM, а що ні

Охоплює: ідентифікацію, автентифікацію (наприклад, SSO, MFA), авторизацію (ролі, набори дозволів), систему захисту даних (SoD), привілейований доступ, елементи керування у разі надзвичайних ситуацій/розбиття скла, облікові записи сервісів та токени API, елементи керування сеансами, робочі процеси затвердження , подвійну верифікацію та періодичні перевірки доступу. Він також включає життєвий цикл користувача (приєднався-перейшов-вийшов), контроль навчання/компетентності та докази того, що доступ відповідає обов'язкам, визначеним у системі якості.

Не охоплює: UAM не може компенсувати слабку розробку процесу або неконтрольовані документи. Вона не замінює процедурні перевірки в eBMR , а також не усуває потреби в огляді другою особою. UAM дозволяє та обмежує дії; вона сама по собі не підтверджує, що ці дії є науково обґрунтованими або відповідають вимогам.

2) Юридичні, системні та дані, що забезпечують цілісність даних

Рішення щодо доступу завершуються електронними записами, які повинні відповідати критеріям Частини 11 / Додатку 11 : унікальні ідентифікаційні дані, перевірені підписи, журнали аудиту з позначкою часу та перевірені засоби контролю безпеки у форматі CSV . Політики містяться в контрольованих стандартних операційних процедурах (СОП ) ( контроль документів ), а докази зберігаються відповідно до розділу «Зберігання записів» . UAM повинна відповідати стандартам менеджменту якості організації ( ISO 13485 , QMSR ) та ІТ-безпеки, а також періодично перевірятися внутрішнім аудитом.

3) Пакет доказів для UAM

Готовий до аудиту файл UAM містить: затверджений каталог ролей та матриці дозволів; правила та винятки SoD; зіставлення ролей з посадами та необхідними компетенціями в Матриці навчання ; записи JML (хто запитував, хто схвалив, коли надано/видалено); налаштування автентифікації (постачальник SSO, фактори MFA); політики сеансу; журнали володіння обліковим записом служби та ротації токенів; результати перевірки доступу та виправлення; а також посилання на пов'язані елементи керування змінами, відхиленнями та CAPA. Усі записи повинні бути пов'язаними, мати позначку часу та незмінними через журнали аудиту.

4) Від запиту до виконання — стандартний шлях

Доступ починається із задокументованого запиту, пов’язаного з роллю та профілем компетенції. Керівники та фахівці з контролю якості/ІТ затверджують його відповідно до стандартної операційної процедури (СОП); система автоматично надає доступ через групи каталогів або власні ролі. Перш ніж користувач зможе виконувати контрольовані дії (наприклад, звільнення, видалення, введення результатів), платформа перевіряє ефективність навчання та реєстрацію підписів. Під час використання дозволи обмежують дії на покроковому рівні в робочому процесі eBMR/LIMS, за потреби забезпечують подвійну перевірку та реєструють кожну дію під ідентифікатором користувача. Переведення активує повторну оцінку вимог до доступу (SoD) та дозволів; звільнення активує негайне скасування доступу та анулювання токенів. Періодичні перевірки доступу узгоджують реальність із політикою та усувають прогалини.

5) Інтерпретація ролей, дозволів та SoD

Уявіть собі роль як іменований набір дозволів, що виражає функцію роботи, а не особу. Хороші ролі невеликі, компонуємі та стабільні; дозволи – це явні дієслова (створити пакет, затвердити відхилення, підписати результат). SoD гарантує, що жодна окрема роль (або користувач) не може одночасно ініціювати та затверджувати одне й те саме рішення з високим ризиком (наприклад, створити та випустити пакет). Винятки повинні бути рідкісними, обмеженими в часі та реєструватися як прийняті ризики зі схваленням та переглядом керівництва. Узгодьте ролі з Планом контролю та реальними робочими процесами, щоб безпека не змушувала використовувати обхідні шляхи, які шкодять дотриманню вимог.

6) Життєвий цикл «Приєднатися–Перехід–Вихід» (JML)

Для тих, хто приєднується, надавати лише ті ролі, які обґрунтовані описом посади та пройденим навчанням; відкласти активацію електронного підпису до перевірки особи. Для осіб, що переходять на іншу позицію (підвищення, переведення), потрібні дельта-перевірки: спочатку видалити старий доступ, потім додати новий; повторно оцінити стан виконання вимог. Особи, що звільняються, повинні бути скасовані з дати набрання чинності з негайним анулюванням облікових даних у MES/LIMS/ELN/WMS та підключених сервісах; архівувати їхні записи відповідно до політики зберігання. Кожен крок JML реєструється, затверджується та підлягає аудиту.

7) Аутентифікація, електронні підписи та сесії

Використовуйте централізований єдиний вхід (SAML/OIDC) з багатофакторною автентифікацією (MFA) для інтерактивних користувачів; встановлюйте тайм-аути сеансу відповідно до ризику та середовища. Для дотримання Частини 11 електронні підписи мають бути унікальними для окремої особи та ніколи не поширюватися; запити на підпис повинні вимагати щонайменше повторного введення пароля та значення підпису (перевірка, затвердження, відповідальність). Вимкніть кешовані/спільні облікові дані на спільних робочих станціях; надавайте перевагу входам для окремих користувачів зі швидкою повторною автентифікацією (значок плюс PIN-код), щоб підтримувати атрибуцію без шкоди для продуктивності.

8) Реальність виробничих приміщень та лабораторій

Термінали на лініях та стендах часто обслуговують багатьох операторів. Уникайте спільних універсальних облікових записів — використовуйте особисті облікові записи зі швидким перемиканням, скануванням бейджів або режимами кіоску, які зберігають ідентичність на кожному кроці. Прив’яжіть використання пристрою до навчання на певному обладнанні; блокуйте критичні дії (наприклад, зважування за допустимим відхиленням, випуск випробувань), якщо термін навчання закінчився. Для інтегрованих приладів переконайтеся, що ідентифікація керуючого користувача вноситься до запису (жоден «системний» користувач не перезаписує) та що годинники/часові пояси узгоджені для цілісності даних.

9) Постачальники, сервіси та доступ до API

Постачальникам та автоматизації потрібен доступ, але не карт-бланш. По можливості призначайте іменовані облікові записи окремим особам; якщо облікових записів служб уникнути неможливо, обмежте область дії (мінімум привілеїв), ротуйте секрети, обмежуйте IP-адреси та реєструйте кожен виклик. Токени API повинні бути короткочасними та доступними для аудиту власником. Для віддаленої підтримки вимагайте доступу за часовими рамками та фіксуйте сеанси, де це можливо. Розглядайте весь доступ, який не здійснюється людиною, як зміни згідно з MOC.

10) Аварійні та склозахисні пристрої

Визначте мінімальний набір можливостей для екстрених ситуацій (наприклад, лінія зупинки, охорона продукту), що надаються через роль «розбити склянку». Доступ має активуватися лише за задокументованих надзвичайних ситуацій, автоматично припинятися та запускати сповіщення та перегляд дій після дій. Ніколи не використовуйте роль «розбити склянку» як зручний спосіб обійти SoD або навчальні ворота.

11) Контроль змін, перевірка та аудит

Зміни рольової моделі, матриці SoD, налаштування автентифікації та інтеграції каталогів – це елементи конфігурації, які мають бути пропорційно перевірені в рамках CSV та регулюватися MOC . Тестуйте негативні випадки (роль не може підписувати, SoD блокує схвалення), граничні умови та повноту журналу аудиту. Використовуйте внутрішні аудити для перевірки облікових записів-сиріт, спільних облікових даних та застарілих дозволів; обробляйте результати за допомогою CAPA.

12) Інтеграція з операційною системою та релізом

UAM має посилювати, а не уповільнювати виконання відповідно до вимог. Призначати дії з високим рівнем ризику (наприклад, випуск партії , випуск готової продукції , затвердження відхилень) відповідним ролям; вимагати подвійної перевірки для критичних кроків (перевірка ідентичності, затвердження етикеток). Прив'язувати дозвіл до навчання, щоб некваліфіковані користувачі не могли виконувати або підписувати. Забезпечити, щоб UAM охоплював підключені системи, щоб та сама особа не могла обійти блокування в MES, діючи в LIMS або WMS.

13) Метрики, що демонструють контроль

• Покриття МЗС: % інтерактивних облікових записів із застосованою багатофакторною автентифікацією.
• Час налаштування/відключення: медіана годин від затвердження до застосування змін (той, хто приєднується/звільняється).
• Порушення SoD, запобігнуті/вирішені: блоки в точці використання та час до усунення.
• Осиротілі та спільні облікові записи: кількість та вік; ціль нуль.
• Завершення перевірки доступу: своєчасність та кількість змін після перевірки.
• Гігієна токенів послуг: частота обертання, призначення власника, вік останнього використання.
• Повнота журналу аудиту: % критичних дій із пов’язаним користувачем/підписом.

Ці ключові показники ефективності (KPI) показують, що доступ є своєчасним, заснованим на ризиках та постійно перевіряється, а не встановленим за принципом «встановив і забув».

14) Поширені помилки та як їх уникнути

• Спільні логіни або загальний «оператор». Замініть на особисті облікові записи та швидко повторно авторизуйтеся на спільних станціях.
• Рольова повзучість. Періодично проводите рефакторинг та коригування розмірів ролей; оперативно скасовуйте гранти для тих, хто переходить/звільняється.
• SoD лише на папері. Впроваджуйте технічні блоки в момент дії, а не лише текст стандартних операційних процедур (СОП).
• Неконтрольовані облікові записи послуг. Призначення власників, мінімальні привілеї, ротацію, обмеження IP-адрес та моніторинг.
• Списки доступу до електронних таблиць. Зберігайте доступ до перевіреної платформи за допомогою журнали аудиту, а не офлайн-файли.
• Навчання не пов'язане з доступом. Забезпечити дотримання правил навчання через Матриця навчання щоб запобігти некваліфікованому виконанню.

15) Що належить до запису UAM

Зберігайте каталог ролей, матриці дозволів, правила SoD та результати тестування, квитки та схвалення JML, конфігурацію та перевірку каталогів/SSO, налаштування MFA та сеансів, реєстр облікових записів служби, періодичні перевірки та результати доступу, зіставлення навчання з ролями, журнали реєстрації електронних підписів, винятки та події break-glass, а також посилання на пов’язані MOC , відхилення , CAPA та архівні метадані — все це в розділі « Контроль документів».

16) Як це поєднується з V5 від SG Systems Global

Централізовані ролі та забезпечення виконання вимог до SoD. Платформа V5 стандартизує RBAC (керування базами даних) у модулях MES, LIMS, ELN, WMS та QMS з каталогом корпоративних ролей, ефективним датуванням та розділенням середовищ (DEV/TEST/PROD). Політики SoD (наприклад, «не можна одночасно записувати та затверджувати результати лабораторії», «не можна створювати та публікувати багато даних») застосовуються на рівні кроків, блокуючи дії та спонукаючи до відповідної маршрутизації через робочі процеси затвердження та подвійну верифікацію.

Ідентифікація, єдиний вхід та багатофакторна автентифікація (MFA). V5 інтегрується з постачальниками корпоративних ідентифікаційних даних (SAML/OIDC) для забезпечення єдиного входу та багатофакторної автентифікації (MFA), зберігаючи при цьому запити електронного підпису Частини 11/Додатку 11 та захоплення значення підпису. Режими кіоску та значка з PIN-кодом підтримують спільні термінали без шкоди для атрибуції користувача.

Доступ, обмежений навчанням. Ролі можуть вимагати компетенцій з Матриці навчання ; користувачам, які не пройшли поточного навчання, заборонено виконувати або підписувати контрольовані кроки до повторної кваліфікації. Статус навчання відображається контекстно на екранах eBMR, LIMS та QMS.

Керування сервісами/API. V5 керує обліковими записами сервісів та токенами API, вказуючи власників, області дії, терміни дії, обмеження IP-адрес та повну можливість аудиту. Токени можуть бути обмежені часом для підтримки постачальників та автоматично відкликані у разі виходу з сервісу.

Контроль життєвого циклу та перевірка. Конфігурації UAM контролюються версіями, керуються змінами в рамках MOC та підтримуються скриптами CSV , які тестують негативні/позитивні сценарії (наприклад, блокування SoD, запити на електронні підписи). Перевірки доступу, сканування облікових записів-сиріт та панелі інструментів SoD забезпечують видимість управління для відділу контролю якості та ІТ.

Готові до аудиту докази. Кожне надання доступу, скасування та використання привілеїв фіксується в незмінних журналах аудиту з урахуванням користувача, часу, обґрунтування та схвалення. Звіти підсумовують охоплення MFA, терміни JML, винятки SoD та відповідність електронного підпису для перевірок — без зшивання електронних таблиць.

Підсумок: V5 перетворює контроль доступу на першокласний, перевірений бізнес-процес — достатньо чіткий для регуляторів і достатньо швидкий для операторів.

17) FAQ

Q1. RBAC проти ABAC — чи потрібні нам атрибути?
RBAC (ролі) є базовим показником для ясності та валідації GxP. Атрибути (ділянка, зміна, обладнання) можуть уточнити доступ, якщо вони регулюються та валідуються; забезпечуйте пояснювальність та можливість перевірки рішень.

Q2. Чи потрібен SSO для Частини 11?
Не прямо, але SSO з MFA посилює гарантію ідентифікації. Незважаючи на це, електронні підписи мають бути унікальними, атрибутивними та перевіреними в момент підписання з відповідними підказками.

Q3. Як часто слід проводити перевірки доступу?
Принаймні раз на квартал для посад з високим рівнем ризику; узгоджуйте це з аудитами та організаційними змінами. Завжди переглядайте інформацію після злиттів, реорганізацій або основних оновлень рольових моделей.

Q4. Як ми обробляємо облікові записи служб?
Ставтеся до них як до елементів конфігурації: призначайте власників, обмежуйте область дії, ротуйте секрети, обмежуйте мережеві джерела, контролюйте використання та регулярно переглядайте. По можливості надавайте перевагу доступу іменованих користувачів.

Q5. Чи можуть оператори використовувати спільний логін на лінійному терміналі?
Ні. Використовуйте індивідуальні облікові записи зі швидкою повторною автентифікацією (значок + PIN-код, короткі сеанси), щоб зберегти атрибуцію та відповідати вимогам Частини 11/Додатку 11.

Q6. Що пов'язує доступ з компетентністю?
Команда Матриця навчанняЗіставте ролі з обов'язковими курсами/оцінюваннями; блокуйте контрольовані дії, доки навчання не стане актуальним та ефективним.

Пов'язане читання
• Системи та цілісність: 21 CFR ч. 11 | Додаток 11 | Аудиторський слід | цілісність даних | CSV
• Виконання та затвердження: еБМР | Робочий процес затвердження | Подвійна перевірка
• Управління та аудит: Документ контрольний | Внутрішня ревізія | MOC | КАПА
• Люди та можливості: Матриця навчання | ISO 13485 | QMSR