Навчальні матеріали з автоматизації технологічних процесів та виробництв, розроблені спільнотою
Підсистема керування доступом передбачає наявність в SCADA/HMI користувачів (users), які розділені за правами доступу до об’єктів системи та їх адміністрування. Це потрібно:
для захисту від несанкціонованих дій;
надання користувачам інтерфейсу відповідно до їх ролей;
збереження записів у журналі дій конкретного користувача.
У стандарті ISA-101 описано тільки частину функцій та вимог до підсистеми. Враховуючи, що керування доступом має безпосереднє відношення до кібербезпеки, ці функції детально описані в стандартах IEC 62443, зокрема в частині 2-1. Далі розглянемо підсистему з точки зору цих двох стандартів, а також функції блокування, після чого зупинимося на їх реалізації в різних SCADA/HMI.
У стандарті ISA-101 вказано, що при розробленні ЛМІ необхідно визначитися з типами користувачів, які будуть ним користуватися, та вимогами до них. Кожен користувач або тип користувача відповідно до своєї окремої ролі може мати різні привілеї та рівні доступу до окремих дисплеїв, діагностичних можливостей та інших функцій ЛМІ. Ролі та обов’язки можуть відрізнятися залежно від галузі та від конкретного об’єкта. Прикладом таких типів користувачів можуть бути:
операційний персонал (оператори процесу): здійснюють моніторинг і виконують керування та експлуатацію установки чи інших засобів виробництва; сюди можуть входити як оператори центрального пункту керування, так і операційний персонал, що користується і віддаленим доступом, і доступом з портативних пристроїв;
персонал з технічного обслуговування (Maintenance-users): усувають несправності та/або виконують технічне обслуговування приладів, виконавчих механізмів, регулюючих органів, насосів, двигунів і т.п.;
інженери (Engineering-users): виконують модифікації, доповнення або видалення компонентів HMI або системи керування;
адміністратори: виконують оновлення системи керування, призначають правила безпеки іншим користувачам;
керівники, менеджери: здійснюють моніторинг функціонування установки чи інших засобів виробництва;
аналітики: здійснюють моніторинг системи для поліпшення роботи установки;
інші користувачі: використовують або взаємодіють із системою для інших цілей, наприклад, персонал з керування якістю.
Операційний персонал належить до так званих первинних користувачів (primary users), інші, що забезпечують обслуговування та моніторинг, – до вторинних користувачів (secondary users). Для кожного типу визначаються вимоги до користувачів та набір завдань, які вони виконують, з урахуванням:
дій користувача при нормальних та ненормальних умовах експлуатації;
потреби в довідковій системі для користувача (онлайн або офлайн);
вимог, що стосуються ролей користувача та привілеїв облікового запису;
термінології, що використовується користувачем, моделі об’єкта та/або процесу з точки зору користувача;
потреби функцій HMI для користувача.
Важливо зазначити, що задоволення потреб вторинних користувачів не повинно перешкоджати виконанню вимог користувачів первинних. У випадках, коли потреби занадто різноманітні, щоб бути ефективними на одному дисплеї або їх сукупності, слід створити окремі дисплеї для підтримки потреб вторинних користувачів.
Користувачі можуть доступатися як з локальних терміналів (локальні користувачі, local user), так і з консолі, що знаходиться за межами охоронного периметра виробничої площадки (віддалені користувачі, remote user). У проекті можуть бути передбачені більші обмеження доступу віддалених користувачів порівняно з локальними (див. також параграф 9.5.1).
Вимоги до ЛМІ можуть бути означені у вигляді окремого документа або як частина вимог до функцій системи керування чи застосування (наприклад, як це означено в ANSI/ISA-5.06.01-2007). Загальні вимоги до керування доступом на рівні АСКТП означено в стандарті IEC 62443-2-1, нижче розглянемо ці вимоги детальніше.
Згідно IEC 62443-2-1, керування доступом – це метод керування тим, хто чи що може отримати доступ до приміщень та систем та який саме тип доступу дозволений. Доступ облікового запису (access account) – це функція керування, що дає користувачеві змогу отримати доступ до певного набору даних або функцій певного устатковання. Облікові записи пов’язуються з ідентифікаторами користувачів (ідентифікаторами) та паролями. Ці ідентифікатори та паролі користувачів можуть бути пов’язані з окремою особою або групою осіб, такими як робоча група диспетчерської, що виконує той самий набір операційних завдань.
Є три ключові аспекти, пов’язані з керуванням доступом:
адміністрування облікових записів (account);
автентифікація;
авторизація.
Адміністрування передбачає керування обліковими записами щодо автентифікації та авторизації. Автентифікація забезпечує перевірку дійсності (автентичності) користувача, а авторизація надає йому певні права залежно від наданих йому ролей.
У рамках кожного з трьох аспектів керування доступом повинні бути встановлені правила, які підтверджують, що доступ користувача до систем і даних контролюються. Правила зазвичай повинні застосовуватися до ролей та груп користувачів. Вони повинні мати доступ до систем і даних, які необхідні тільки для задоволення означених цілей.
Існують правила, які застосовуються в адміністративному порядку, і ті, які застосовуються автоматично за допомогою використання технологій. Обидва види правил повинні розглядатися як частина загальної стратегії керування доступом. Наприклад, адміністративне правило організації може передбачати видалення облікового запису співробітника або підрядника після його виходу з організації. Прикладом застосування правила, що стосується технологій, є вимога підключення віддалених користувачів виключно через VPN.
Щоб забезпечити загальну структуру безпеки для системи, на додаток до правил існують фізичні процедури безпеки та кібербезпеки, які працюють разом. Процедури фізичної безпеки включають такі заходи, як замикання кімнат, де знаходиться устатковання інтерфейсу користувача. Детальніше про ці процедури описано в стандарті IEC 62443-2-1. Основні аспекти кіберзахисту наведені в розділі 9.5 посібника.
Адміністрування облікових записів – це метод, пов’язаний із наданням та відкликанням доступу до облікових записів та підтримкою дозволів і привілеїв, передбачених цими обліковими записами, для доступу до певних ресурсів та функцій у фізичних приміщеннях, мережі чи системі.
Адміністрування облікового запису в середовищі АСКТП виходить за рамки традиційного ІТ-ного означення доступу в операційній системі. У середовищі АСКТП облікові записи більше обмежуються набором дозволених функцій, які користувачі можуть виконувати, а не доступом до даних.
Доступ облікових записів до функцій може ґрунтуватися за функціональною або рольовою ознакою і може бути означеним для осіб, груп осіб, які діють як команда, або для пристроїв, що забезпечують функцію. У стандарті вказані такі рекомендації щодо адміністрування:
права доступу повинні встановлюватися відповідно до політик безпеки, що повинні бути попередньо розроблені для всієї системи;
правила доступу повинні бути донесені до всього персоналу;
права доступу можуть бути означені як для команди, так і індивідуально для користувача;
доступ надається, змінюється або припиняється за дорученням відповідальної за адміністрування особи, яка може відрізнятися від адміністратора IT та обізнана в процесах операційної діяльності;
повинен вестися облік усіх дій щодо доступу до облікового запису;
якщо облікові записи не потрібні (наприклад, при звільненні працівника), їх слід призупинити або видалити;
користувачам мать бути призначені мінімальні права і повноваження, необхідні для виконання тільки їх завдань;
облікові записи необхідно регулярно переглядати: чи використовується, роль і потреби все ще актуальні, користувач має тільки мінімально необхідні дозволи;
перед уведенням системи керування в дію паролі за замовченням повинні бути змінені, оскільки вони можуть бути легко визначені з доступних джерел;
відповідність облікових записів політиці адміністрування необхідно періодично перевіряти;
доступ повинен контролюватися відповідним методом аутентифікації: тобто ID користувача і паролем, персональними ідентифікаційними номерами (PIN) або токенами;
особисті дані користувача не повинні передаватися будь-кому, за винятком особливих ситуацій; один особливий випадок – у диспетчерській, де оператори працюють як одна робоча група або команда;
повинен бути механізм альтернативного процесу ідентифікації в разі втрати облікових даних або забутого пароля
Слід зазначити, що на практиці підсистема організації доступу в системах SCADA/HMI є відокремленою та незалежною від системи керуванням доступу самої операційної системи. Тим не менше, в багатьох сучасних SCADA/HMI продуктах є опція з інтеграції із системою керування доступом операційної системи, але зазвичай така інтеграція не використовується. Це може призводити до випадків, коли оператор працює під своїм “обмеженим” обліковим записом у SCADA/HMI, але в той самий час має права локального адміністратора в операційній системі. Інколи буває і навпаки – інженерний персонал отримує набір логінів та паролів від розробників проекту, включно із адміністраторським, але коли настає час вносити зміни до конфігурації проекту, виявляється, що ніхто не має даних облікового запису локального адміністратора ОС.
Крім того, однією з важливих функцій системи керування доступом у SCADA/HMI є обмеження доступу до функцій консолі операційної системи. Саме тому у SCADA/HMI продуктах різних вендорів наявні функції:
блокування виходу із повноекранного режиму на “робочий стіл”;
блокування системних комбінацій клавіш, наприклад CTRL+ALT+DEL;
блокування системних кнопок “Windows”;
інші блокування виходу в ОС;
обмеження доступу до функцій запуску прикладних програм зі SCADA.
З тією самою метою розробники інколи блокують доступ до деяких функцій та комбінацій клавіш у реєстрі або навіть прописують виконавчий файл SCADA/HMI системи замість shell. У кожного розробника свої методи боротьби з хитрощами операторів, але в будь-якому разі на ці питання слід звертати увагу при адмініструванні.
Серед системних комбінацій клавіш виділимо найбільш вживані, які є сенс блокувати:
Alt + Esc – переключення до наступного застосунку;
Alt + Tab – пряме переключення між відкритими застосунками;
Alt + Shift + Tab – зворотне переключення між відкритими застосунками;
Ctrl + Tab – переключається до наступного вікна всередині того самого застосунку, але може бути переназначено всередині застосунку;
Ctrl + Esc – виклик меню “Пуск”;
Alt + F4 – закриття застосунку;
Ctrl + F4 – закриття вікна всередині застосунку;
Ctrl + Shift + Esc – запуск диспетчера задач Windows;
Windows key – виклик меню “Пуск”;
Windows key + D – мінімізація/максимізація всіх вікон;
Windows key + E – відкриття провідника Windows;
Windows key + F – відкриття вікна пошуку;
Windows key + M – мінімізація всіх вікон представлених у панелі задач;
Windows key + P – переключення в режим презентації;
Windows key + R – запуск вінка виконання (запуску програми);
Ctrl+Alt+Del - вікно переривання;
Windows key + L – блокування робочого столу.
Автентифікація (authentication) – міра безпеки, розроблена для встановлення дійсності (автентичності) передачі, повідомлення чи джерела, або засоби перевірки дозволу особи на отримання конкретних категорій інформації. Автентифікація є обов’язковою умовою для надання доступу до ресурсів системи.
Необхідно враховувати, що на відміну від автентифікації в ІТ-системах, відсутність доступу до ресурсів у критичні моменти часу може призвести до небезпечних та аварійних ситуацій. З цих же причин у системах АСКТП необхідно дуже обережно ставитися до блокування облікових записів при невдалих входах у систему або періодах бездіяльності. З іншого боку, недостатньо сильна автентифікація може сприяти надаванню доступу зловмиснику для виконання небезпечних операцій.
Існує кілька типів стратегій автентифікації, і кожна має різний ступінь міцності. Сильні методи автентифікації - це ті, які є досить точними в правильній ідентифікації користувача, слабкі – ті, які легко анулювати, щоб забезпечити небажаний доступ до інформації. Прикладом слабкої автентифікації є ідентифікація за користувачем та паролем. Приклади сильної автентифікації:
використання двофакторної автентифікації, в якій потрібна фізична карта та пароль (PIN-код);
використання смарт-карт або біометричних даних;
автентифікація користувачів на основі їх місцезнаходження;
при підключенні модемів до промислових пристроїв керування використання функцій зворотного виклику для попередньо вказаного телефонного номера;
підключення домашніх комп’ютерів до пристроїв або мереж керування виробничою діяльністю з використанням VPN і двофакторної автентифікації з використанням токена і PIN-коду.
Враховуючи наявність ширших привілеїв у користувачів з правами адміністрування/конфігурування, вимоги до їх автентифікації більш жорсткі.
Фізичне розташування користувача може мати істотний вплив на ризик доступу до АСКТП. Наприклад, користувач, що підключається до системи зсередини будівлі (локальний користувач), в якій є охорона і система зчитування електронних посвідчень на вході, створює менший ризик, ніж користувач, що підключається з якоїсь іншої точки світу (віддалений користувач). Тому для користувачів, що мають доступ віддалено, означуються жорсткіші вимоги. У системах АСКТП великий акцент робиться на поєднання заходів фізичної та електронної автентифікації.
Окрім автентифікації самих користувачів, в АСКТП при зв’язку між собою різних підсистем також повинна використовуватися автентифікація. Це потрібно для неможливості підроблення повідомлень сторонніми особами та засобами.
Слід зазначити, що вимоги до автентифікації (відповідно до локальних політик безпеки) сильно залежать від особливостей системи керування та об’єкта. У IEC 62443-2-1 вказані такі рекомендації щодо автентифікації:
повинна бути розроблена стратегія автентифікації, в якій вказуються використовувані методи автентифікації;
перед використанням застосунків, у тому числі SCADA/HMI, користувачі повинні пройти автентифікацію; це може проводитися з використанням комбінації фізичних та електронних засобів;
усі спроби та результат доступу до критичних систем повинні бути записані в журнал;
вимоги до автентифікації повинні бути більш жорсткими (наприклад, тільки складні паролі); враховуючи що адміністрування не потребує швидкої реєстрації, можна використовувати складні способи автентифікації;
рекомендується надавати системному адміністраторові тільки локальний доступ;
для автентифікації локальних користувачів (що працюють у межах будівлі системи керування):
враховуючи можливість командної роботи та необхідність швидкого доступу до дій у критичних ситуаціях, необхідно передбачити обмеження фізичного доступу до SCADA/HMI (охоронні системи);
для швидкої автентифікації можуть використовуватися: для компонентів керування фізичні ручні замки; автоматичні замки (карта-пропуск); доступ до пунктів керування;
система повинна враховувати можливість доступу до критичних функцій користувачам навіть при частковій відмові інфраструктури; наприклад, при відмові комп’ютерної мережі повинні працювати локальні засоби керування;
не повинні блокуватися при невдалих спробах автентифікації (у критичних ситуаціях оператор може ввести неправильний пароль);
у багатьох випадках не бажано вимагати складних паролів, оскільки в критичних ситуаціях це може уповільнити процес реалізації керуючої дії оператора на процес;
у багатьох випадках не бажано вимагати часового обмеження на паролі;
для автентифікації віддалених користувачів (що мають доступ ззовні будівлі або області керування):
повинні застосовуватися особливі способи автентифікації;
повинні бути передбачені особливі політики (реакція на невдалу спробу входу в систему, період бездіяльності тощо);
рекомендується, щоб надавався доступ тільки з функціями моніторингу без можливості керування; однак у деяких випадках системи SCADA доступ до керування обов’язковий;
після певної кількості невдалих спроб реєстрації віддалених користувачів, система повинна відключати їх обліковий запис на деякий час (захист від злому паролю); однак у деяких випадках системи SCADA доступ до керування може бути критичним, так само як і для локального користувача;
після певного часу неактивності користувача система може вимагати повторної автентифікації;
Авторизація (уповноваження, authorization) – право або дозвіл, що надається системній сутності для доступу до системного ресурсу. Після успішної автентифікації користувача та ідентифікації пов’язаного з ним облікового запису йому надаються привілеї доступу до ресурсів. Надані пільги визначаються конфігурацією облікового запису, встановленого на етапі адміністрування в бізнес-процесі.
Деякі стандартні процедури авторизації, що застосовуються в ІТ, можуть бути невідповідними або неадекватними для АСКТП. Наприклад, доступ облікових записів у типовій ІТ-системі в основному базується на користувачі з обмеженою кількістю присвоєних ролей (тобто стандартним користувачем або системним адміністратором). Кожному користувачеві зазвичай присвоюється лише одна роль. Доступ облікових записів у типовій системі АСКТП в основному буде ґрунтуватися на більшій кількості ролей (наприклад, оператор, інженер, технолог, розробник, системний адміністратор тощо). Користувачам може бути назначено декілька ролей на основі певних функцій, які потрібно виконувати в певний час. Користувачеві, можливо, доведеться увійти до певного пристрою та окремо в застосунок, який матиме дозвіл на внесення змін до змінних керування. Або користувачеві, можливо, доведеться вийти із системи та повторно увійти, щоб виконати завдання системного адміністрування на тому самому пристрої.
Авторизація означує засоби керування, спрямовані на захист інформації та активів від навмисного та ненавмисного руйнування, зміни чи виявлення. Вона спеціально зосереджена на заходах, розроблених для забезпечення доступу автентифікованих агентів до необхідних інформаційних ресурсів. Як і при автентифікації, авторизація залежить від місця розташування користувача.
У IEC 62443-2-1 вміщені такі рекомендації щодо авторизації:
правила, що означують привілеї, якими уповноважені облікові записи для різного персоналу повинні бути означені в політиці безпеки авторизації;
дозвіл на доступ до засобів АСКТП може бути логічним (правила, що надають або забороняють доступ відомим користувачам на основі їх ролі), фізичним (замки, камери та інші елементи керування, що обмежують доступ до активної консолі ПК) або їх комбінацією;
для керування доступом до відповідної інформації або системи облікові записи повинні базуватися на основі ролі;
для віддаленого доступу необхідно передбачати різне розміщення процедур авторизації:
на рівні застосунку;
на рівні пристрою: для кожного пристрою можуть бути означені конкретні правила авторизації;
на рівні бар’єрного мережного пристрою АСКТП (брандмауер або маршрутизатор): після автентифікації залежно від ролі надається доступ до конкретних пристроїв у мережі АСКТП;
віддалений доступ дозволяти тільки за потреби;
рольові облікові записи повинні враховувати фізичне розміщення користувача: різний набір ролей для локального та віддаленого входу;
у критичних середовищах керування для обмеження доступу до АСКТП слід використовувати декілька методів авторизації.
Правила авторизації описують, яким чином назначаються ролі певним користувачам або групам користувачів і як налаштовуються привілеї для цих облікових записів. Здатність реалізувати бажану політику авторизації залежить від особливостей інструментальних засобів систем керування розрізнення функцій та даних, необхідних для різних робочих ролей. Таким чином, означення політики авторизації є ітераційною процедурою, в якій організація означує ідеальну політику, а потім визначає, наскільки повно це можна реалізувати, використовуючи можливості своїх систем та мережі. При закупівлі нової системи підтримка потрібної політики авторизації може бути елементом специфікації закупівель. Розроблюючи нову мережну конфігурацію, такі технології, як брандмауери для віддалених користувачів, можуть бути додані для створення додаткового рівня авторизації критичних пристроїв.
Взагалі до всіх інструментальних засобів SCADA/HMI характерні такі властивості підсистеми керування доступом:
для забезпечення авторизації необхідно виділяти рівні прав або привілеїв, що задаються для елементів, на які необхідно обмежити доступ;
для забезпечення авторизації необхідно виділяти групи (категорії) користувачів, які мають однакові права (ролі), що спрощує адміністрування, шляхом надання обліковому запису певних ролей;
для забезпечення адміністрування має бути можливість створювати та редагувати користувачів не тільки в середовищі розроблення, але й у середовищі виконання;
можливість інтегрування зі службами керування користувачами операційної системи (наприклад Windows Active Directory);
для автентифікації можливість входу користувача за допомогою різних засобів – як з використанням імені та паролю, так і інших (карт, біометричних сканерів і т.п.);
можливість користувача тимчасово входити в систему (тимчасово змінювати роль), тобто користувач з вищими правами може зареєструватися тільки на час виконання однієї дії;
можливість обмежувати вміст на основі місцезнаходження (користувач з віддаленого засобу ЛМІ може мати менше прав);
можливість примітки автентифікації, тобто вимога до користувача додати причину для керуючої дії;
можливість задавати час простою, після якого система автоматично виведе користувача із системи.
Окрім обмеження доступу до елементів за привілеями, інколи необхідно блокувати можливість зміни значення чи відправки команд при виконанні (або невиконанні) певних умов.
Наприклад, оператор не повинен мати можливість викликати команду запуску, якщо лінія при цьому не готова. Слід розуміти, що блокування запуску повинно відбуватися на рівні ПЛК або інколи навіть на рівні СПАЗ (системи протиаварійного захисту) чи релейних схем. На противагу до цього на рівні HMI вирішується питання відображення наявності блокування. Іншими словами, блокування ручного керування більше потрібне для того, щоб оператор розумів, що дана команда йому зараз недоступна за певних причин, або для неможливості переходу на невикористовуваний у даний момент дисплей. Ішим прикладом блокування є деактивація певних пунктів меню навігації, які наразі недоступні.
Візуально блокування може бути показане зміною кольору або додатковими символами.
Теоретичне заняття розробив Олександр Пупена.