Інженерний огляд
Genetec Synergis і ClearID: керування життєвим циклом фізичного доступу
Два питання до будь-якої системи контролю доступу.
Хто сьогодні має доступ до цієї зони?
Відповідь займає кілька секунд: звіт вивантажується, список готовий.
Чому кожна з цих людей досі має цей доступ?
Тут відповіді зазвичай немає.
Не тому, що рішень не було. Хтось попросив, хтось погодив листом або усно, адміністратор виконав. У системі залишився результат — право доступу. Підстава залишилася в пошті, заявці, таблиці або в чиїйсь пам’яті.
Звідси незручна асиметрія: служба безпеки відповідає за наслідки доступу, але потребу в ньому визначають інші — керівники підрозділів, власники зон, менеджери проєктів. Слідів цих рішень система не зберігає, тому під час перевірки чи розслідування служба безпеки захищає чужі рішення, яких вона не бачила.
Три питання, які зливаються в одне
Управління фізичним доступом складається з трьох різних задач.
Хто ця людина.
Джерело — кадрова система або корпоративний каталог: там людина з’являється, змінює посаду й підрозділ, звідти вона зникає.
Чому їй дозволено заходити саме сюди.
Це рішення, у якого є автор, підстава і строк.
Хто це фізично виконує.
Контролери, зчитувачі, замки, правила доступу на дверях.
У більшості організацій перше й третє автоматизовані, а друге живе в листуванні. Саме там накопичується ризик — не в дверях, які спрацювали неправильно, а в правах, що колись були обґрунтованими і залишилися після зникнення підстави.
Зріла архітектура не змішує ці рівні, а коректно їх зв’язує.
Звідки система знає цю людину
Дублювати людину вручну в СКУД, якщо вона вже існує в кадровій системі, означає створити другу базу, яка розійдеться з першою після першого ж наказу.
Synergis Card Synchronization plugin імпортує власників карток, їхні групи та ідентифікатори доступу із зовнішньої системи-джерела у Security Center. Синхронізація односпрямована: власником даних залишається зовнішнє джерело, а Security Center використовує їх для задач фізичного доступу.
Але це закриває лише перший рівень. Синхронізація знає, хто ця людина. Вона не пояснює, чому саме їй дозволено цей доступ.
У кожного дозволу має бути автор, підстава і строк
Управлінська проблема не в тому, що права призначаються неправильно. Вона в тому, що рішення про них не існує як об’єкт: його не можна знайти, перевірити чи оскаржити через рік.
Genetec ClearID — рівень, що працює поверх Synergis і відповідає не за виконання доступу, а за рішення про нього. Запит фіксує, хто його подав, до якої зони, на який період і з якої причини; причина є обов’язковим полем — саме тому, що її читатимуть під час аудиту, а не під час видачі. Далі запит іде на погодження до тих, хто може оцінити потребу по суті, і склад погоджувачів налаштовується окремо для кожної зони.
Сама лише наявність маршруту погодження задачі не вирішує — узгоджувати заявки вміє й звичайна корпоративна система заявок. Питання в тому, наскільки рішення, ухвалене на рівні управління доступом, пов’язане із системою, яка фізично виконує доступ.
Тут зв’язок прямий. У сценарії запиту на доступ результат погодження не залишається записом у реєстрі: у Security Center оновлюється правило доступу, а після завершення строку надані ним права знімаються. Між рішенням і виконанням немає людини, яка може забути.
Частину рішень взагалі не потрібно ухвалювати вручну: доступ, що належить людині за підрозділом, посадою або типом зайнятості, надається за політиками автоматично і так само автоматично знімається, коли ці ознаки змінюються. Ручне погодження залишається на винятках — там, де воно щось означає.
Для служби безпеки це не втрата контролю, а зміна ролі. Вона перестає бути автором рішень, яких не може оцінити по суті, і стає власником процедури: хто має право погоджувати, для яких зон потрібен другий рівень, які строки допустимі. Рішення розподіляються. Контроль над процедурою — ні.
Права накопичуються швидше, ніж їх переглядають
Найпоказовіший випадок — підрядник. У класичній моделі це «видати картку на два тижні», а через два тижні хтось має згадати її вимкнути: строк існує в домовленості між людьми, а не у властивостях права. У ClearID для таких випадків використовуються шаблони, де дата завершення може бути обов’язковою, а максимальна тривалість — обмеженою політикою організації. Запитати доступ безстроково стає технічно неможливо.
Там, де право створюється вручну і не має вбудованого строку, накопичення надлишкових прав — не збій, а нормальний результат експлуатації. Кожна окрема заявка виглядає обґрунтованою; проблемою стає сума за три роки, і реальна зона доступу співробітника поступово перестає відповідати його поточній ролі.
Видати право недостатньо. Enterprise-модель має вміти довести, що право досі обґрунтоване.
У ClearID перегляд прав є запланованою процедурою, а не щорічним проєктом із розсилкою таблиць: він налаштовується окремо для зон, ролей і людей, а виконують його ті, хто знає предмет — власники зон, керівники ролей, безпосередні керівники. Історія зберігається повністю, завершений перегляд не редагується, а позаплановий можна запустити після інциденту, коли треба швидко підтвердити, хто саме мав доступ і на якій підставі.
Наслідок для управління: зрілість фізичного доступу стає вимірюваною. Не «стало безпечніше», а частка діючих прав із зафіксованою підставою; частка тимчасових прав із датою завершення; час між кадровою подією та фактичною зміною доступу; частка прав, підтверджених і відкликаних під час останнього перегляду. Перші два показники можна порахувати у власній системі вже цього тижня — зазвичай саме вони й стають найпереконливішим аргументом.
Чи означає це перебудову фізичного рівня
ClearID надбудовується не над будь-якою системою контролю доступу, а над Synergis — це власний рівень управління доступом платформи Security Center. Відкритість архітектури лежить рівнем нижче: Synergis працює з різними екосистемами сторонніх контролерів, зчитувачів і замків, тому перехід на керовану модель не обов’язково означає одночасну заміну польового обладнання — якщо конкретна сумісність це дозволяє.
Саме тут потрібна точність, а не обіцянка. Перелік підтримуваних брендів давно не є достатнім аргументом — він є в кожної серйозної платформи. Практичне питання інше: наскільки глибоко підтримується потрібний сценарій на конкретній моделі.
Показовий приклад: автономний режим роботи (degraded mode), у якому точка доступу продовжує ухвалювати рішення без зв’язку із сервером, доступний не на всьому обладнанні.
Критерій перевірки
«Підтримується виробник» і «підтримується цей сценарій на цій моделі» — різні твердження, і перевіряти треба друге.
Масштабується не кількість дверей
У розподіленій організації кожен майданчик зазвичай має власну систему доступу і власну історію рішень: політика формально єдина, практика на кожному об’єкті своя.
Масштабування СКУД рідко впирається в кількість дверей — додати сто точок доступу є зрозумілою інженерною роботою. Впирається воно в кількість рішень про доступ: разом із дверима масштабуються профілі людей, погодження, тимчасові права, винятки, строки й перегляди.
Архітектурно тут розділяються три задачі: поширення даних про людину між системами Security Center, для чого платформа має власні механізми — ролі Global Cardholder Synchronizer і Federation; управління самим процесом надання доступу, яке живе рівнем вище і працює над кількома системами одразу; і фізичне виконання, що залишається на місцях. Підміняти одну задачу іншою означає отримати або дублювання даних, або політику, що існує лише на папері.
Одна умова тут організаційна. Єдина політика працює тільки тоді, коли рішення справді ухвалюються в одному місці; якщо паралельно зберігається практика ручного призначення прав, система показуватиме порядок, якого немає.
Чим вимірюється зрілість
Швидкість, з якою система відчиняє двері, — базовий рівень. Для enterprise-архітектури він уже недостатній як критерій зрілості.
Зрілість визначається тим, чи здатна організація через рік пояснити: хто отримав доступ, чому, за чиїм рішенням, на який строк — і чому це право досі існує. І тим, чи пов’язане це пояснення із системою, яка фізично виконує рішення.
Рішення, відірвані від виконання, дають документацію замість контролю.
Виконання без керованих рішень дає порядок на дверях і хаос у підставах.
Обидва питання краще ставити на етапі проєктування архітектури, а не через три роки — коли в системі накопичилися права, походження яких уже ніхто не пам’ятає.
