Інженерний огляд
Що станеться з Genetec Security Center через п’ять років експлуатації
Оновлення прошивки камери — одна з найбуденніших операцій в експлуатації відеосистеми.
У частини виробників після оновлення камера може повернутися до заводських налаштувань, тому параметри, підібрані під конкретну сцену, доведеться відновити. Для деяких пристроїв оновлення виконується не через платформу керування системою безпеки Genetec Security Center, а за допомогою утиліти виробника обладнання.
У гетерогенній системі це нормальна частина експлуатації: різні пристрої мають власні цикли версій і власні процедури оновлення.
Питання
І вже на такій рутинній операції виникає питання, важливе для всього життєвого циклу: коли в системі щось змінюється, як далеко можуть розійтися наслідки?
Оновлення, яке не перетворюється на окремий проєкт
У системі з кількома сотнями камер складно тримати в голові, яка прошивка стоїть на якій моделі й які версії перевірені з поточною версією платформи. Тому оновлення нерідко відкладають або роблять без повної картини, а застаріла прошивка може залишати в мережі об’єкта вразливості, які виробник давно виправив.
Security Center знімає частину цього обліку з людей: він відстежує нові версії прошивок і їхню сумісність із вашою системою, повідомляє, коли така версія з’явилася для встановленої камери, і показує характер оновлення — зокрема, чи закриває воно виявлені вразливості. Цей механізм називається Firmware Vault; для частини виробників прошивку з нього можна ще й завантажити та розгорнути прямо з інтерфейсу платформи. Охоплення не суцільне: які саме зі встановлених моделей у нього потрапляють, видно зі звіту про обладнання.
Самі оновлення надходять ззовні через службу Genetec Update Service, яка може виходити в інтернет через вузол-посередник в окремому сегменті мережі (DMZ): тоді назовні дивиться один контрольований вузол, а не кожен сервер.
Для серверів і робочих станцій логіка та сама: оновлення не обов’язково означає «останню версію» — для конкретної машини версію можна вибрати й зафіксувати, а платформа перед встановленням перевірить її сумісність. Але після зміни інженер однаково перевіряє на живій системі, що все передбачене проєктом працює.
Кероване оновлення — не одна кнопка, а ситуація, коли до початку відомо, що зміниться, чим підтверджена сумісність і що перевіряти після.
Але так виглядають лише заплановані зміни. Частина змін накопичується поза планом, і саме з ними через кілька років виникає складніше питання.
Сервер, у якого є точка відліку
Через три роки сервер працює. Але чи відповідає його конфігурація тій, яку приймали разом з об’єктом? Хтось відкрив спільний доступ до файлів, щоб перенести архів, хтось вимкнув брандмауер на час пусконалагодження. Кожна дія мала причину, але зібрати з них повну картину через кілька років уже непросто.
Для цього в Genetec є Streamvault — готова апаратно-програмна платформа: сервери й робочі станції постачаються з операційною системою, Security Center і засобами керування конфігурацією самого пристрою. Захищена конфігурація тут — не разова настройка під час запуску, а стан, яким керують.
Ці налаштування задаються через вебпортал самого сервера. Якщо відповідні параметри Windows змінити вручну, вони діють до наступного застосування налаштувань через портал, після чого перезаписуються — еталоном лишається портал.
Сам еталон вибирають із кількох готових профілів захищеної конфігурації, і з заводу сервер приходить уже з одним із суворих. Типові послаблення, як-от віддалений робочий стіл, вимкнені за замовчуванням, а рішення про кожне з них оцінюють щодо обраного профілю: деякі можуть вивести сервер за його межі.
Через роки це дає головне: на питання «чи відповідає сервер тому, що приймали» є точка відліку — обраний профіль, а не реконструкція з пам’яті. Поточний стан машини порівнюють із заданим, замість відновлювати історію змін по слідах.
Компроміс
Суворіший профіль при цьому може обмежувати зручність роботи й продуктивність, тому його вибирають під реальні загрози об’єкта.
Коли на об’єкті з’являється система, якої не було в проєкті
Через кілька років змінюються не лише пристрої, а й сама задача. Службі безпеки потрібні дані від інженерних систем, яких у первинному технічному завданні не було: стан обладнання, живлення, сигнали виробничої автоматики. Звичне рішення — ще один пульт поруч із робочим місцем оператора: формально інтеграція є, але оператору доводиться самому зводити дві окремі картини.
Щоб ці дані потрапили в сам Security Center, існує плагін Industrial IoT: він під’єднується до інженерних систем через промислові протоколи. Важливо не те, які протоколи в переліку, а те, чим стає зовнішнє значення всередині платформи, — окремою точкою даних зі своїм станом і своїми правами.
Права потрібні тому, що з різними даними працюють по-різному: температуру в апаратній система лише зчитує, а задане значення параметра чи команду керованому обладнанню може й передавати — тому кожна точка даних має рівень доступу: лише читання або читання і запис. На BACnet, поширеному протоколі інженерних систем будівлі, його визначає сам тип об’єкта: виміряні значення тільки читаються, а виходи й керовані значення можна й записувати.
Сенс цього для життєвого циклу не в самому BACnet. Через кілька років до системи можна додати новий клас даних, не перебудовуючи операторське середовище навколо ще одного окремого пульта.
Межі при цьому задані архітектурно. На розподілених об’єктах кілька самостійних систем Security Center можна об’єднати для роботи з одного центру: центр бачить промислові дані віддалених систем, але записувати значення в їхні точки не може.
Так само з системами захисту життя людей: їхні об’єкти BACnet доступні лише на читання. Security Center показує їхній стан оператору в загальній картині, але не забирає функцію спеціалізованої системи, яка за ці процеси відповідає.
Буває й зворотна задача — передати події та стани Security Center у зовнішню систему диспетчеризації чи моніторингу. Для цього є інший плагін, Industrial Protocol Interface. Він лише віддає дані назовні, і робоче місце оператора йому не потрібне.
Що насправді означає «підтримує»
У специфікації інтеграція зазвичай виглядає одним рядком: «підтримує BACnet», «є інтеграція з системою X». Для проєкту цього мало. Рядок не каже, чи перевіряли саме таку комбінацію пристрою й версій, наскільки глибоко підтверджена сумісність і що доведеться перевіряти після наступного оновлення.
Для промислових інтеграцій рівень підтвердженої сумісності позначається двома статусами.
- Certified означає, що конкретний пристрій або тип пристроїв Genetec протестував і валідував.
- Supported by design — що пристрій має ті самі конструктивні характеристики, що й сертифікований, хоча окремо такої валідації не проходив.
Тут же видно різницю між протоколом і пристроєм: підтримка самих промислових протоколів має статус Supported by design, а Certified отримують конкретні протестовані пристрої — промислові контролери, пожежні панелі, датчики середовища й живлення. Для камер і контролерів доступу сумісність визначається власними переліками.
Для проєктувальника різниця практична: статус показує, на що вже можна спиратися, а що варто підтвердити для конкретного сценарію, — і це відомо до пусконалагодження. Якщо інтеграція критична або повторюватиметься на багатьох об’єктах, потрібну комбінацію версій відпрацьовують на стенді чи пілотному об’єкті й далі використовують як перевірену основу. Технічна підтримка теж прив’язана до цієї комбінації: вона передбачена, коли плагін встановлено з версіями Security Center і стороннього ПЗ, які мають статус Certified або Supported by design.
Для життєвого циклу тут важливий не сам факт підтримки протоколу, а те, наскільки передбачувано поводитиметься перевірена комбінація компонентів після наступної зміни.
Що видно в день запуску і що — через три роки
- У день здачі об’єкта камери пишуть, двері відчиняються, події доходять до оператора. Багато архітектурних відмінностей у цей момент ще просто не встигли проявитися.
- Вони проявляються пізніше. Через три-п’ять років сотні камер потребують оновлень, частину обладнання треба міняти, виходять нові версії платформи й плагінів, змінюються вимоги до кіберзахисту. До системи підключають інженерне обладнання, про яке під час проєктування ніхто не думав, а працюючу інтеграцію треба оновити, не зламавши решту. З’являються й вимоги, яких на момент проєктування не існувало.
Тут і стають у пригоді кероване оновлення прошивок, сервер із заданим базовим станом, можливість додати новий тип даних без ще одного пульта й зрозумілий обсяг перевірки кожної інтеграції.
Жоден із цих механізмів не позбавляє систему змін. Вони дають інше: можливість заздалегідь розуміти, які частини системи зачепить чергова зміна і що після неї доведеться перевірити.
