Сиротин Дмитрий Вячеславович, руководитель направления IP-систем безопасности ГК «Эликс»
На тему использования смартфонов в системах контроля доступа уже написано достаточно статей. В каждой из них раскрыты выгоды и достоинства новой технологии идентификации. Обозначены причины, по которым карты доступа должны быть заменены мобильными идентификаторами. И казалось, стоимость внедрения мобильного доступа соразмерна стоимости внедрения системы на картах доступа. У новой технологии нет преград: завтра или, в крайнем случае, послезавтра произойдет смена власти на рынке идентификации, и карты доступа уйдут в небытие, как раритеты, занимая место для сбора пыли в музеях. Однако…
Критерием проникновения технологии на рынок является вовлеченность конечного потребителя. В нашем случае конечным заказчиком выступает бизнес. На сегодняшний день бизнес отреагировал довольно сдержанно, обозначив ряд критериев, которым система должна соответствовать: возможность работать в замкнутой системе координат без выхода в Интернет как способ защиты информации, шифрование данных при передаче по каналам связи и возможность управления (выдача и отзыв мобильных идентификаторов) через корпоративные IТ-системы.
Вопрос шифрования данных передачи мобильных идентификаторов от смартфона к считывателю решен производителями на этапе выхода технологии на рынок, а соответствие другим обозначенным выше критериям бизнеса требует изменения логики работы и разработки отдельных серверных решений.
Причины, по которым заказчик готов платить за собственное серверное решение, встроенное или адаптивное для интеграции с возможностями управления и обслуживания через «шапку» корпоративной системы, понятны и лежат на поверхности. Это защита доступа и хранение корпоративной информации на собственных серверах, удобство управления системой и снижение издержек на обслуживание системы. Не менее интересная задача, которую обозначают перед интеграторами, – это брендирование мобильного приложения, которое ежедневно будут использовать для прохода в офис каждый сотрудник или гость компании.
Таким образом, если обобщить основные требования, с которыми сталкивается интегратор при внедрении мобильной идентификации в компанию, – это, как минимум, два разных продукта: отдельный сервер для безопасного выпуска идентификаторов с управлением через корпоративную IТ-систему заказчика и разработка или внедрение мобильного доступа в корпоративное мобильное приложение для идентификации по смартфону.
Перед тем, как приступить к оценке перспектив проникновения мобильной идентификации в системах управления доступом, следует разграничить задачу выпуска постоянных и гостевых пропусков. Так как, как правило, это разные бизнес-процессы, за которые отвечают разные люди.
На уровне карточных систем за постоянные пропуска отвечает отдел кадров, за гостевые – бюро пропусков. Если рассматривать мобильную идентификацию, за каждый процесс должен отвечать отдельный сервер – сервер для выпуска постоянных (не отзываемых) мобильных идентификаторов и сервер выдачи мобильных отзываемых идентификаторов для обслуживания большого количества авторизованных гостей. А это бизнес-центры, отели, гостиницы, жилищные комплексы, коттеджные поселки и другие, где требуется большое количество разовых пропусков.
То есть при выборе решения рекомендуется оценить целесообразность перехода той или иной группы пользователей СКУД на мобильные пропуска. При этом с технической стороны для реализации обоих вариантов необходимы следующие компоненты: специальное серверное приложение, HASP-ключ, в который будет загружен приобретенный заказчиком пул лицензий, мобильное приложение для идентификации пользователя, куда будут загружать мобильные метки (мобильные идентификаторы) и API, например, на базе JSON, для интеграции решения в любую бизнес-логику заказчика (рис. 1).
Рис. 1. Структура бизнес логики приложений заказчика
За выдачу лицензий (идентификаторов) отвечает серверное приложение. Существуют несколько вариантов выдачи идентификаторов. Самые распространенные: в формате QR-кодов, которые можно будет распространять любым доступным способом, и загрузка файла с лицензиями в настольный регистрирующий считыватель, который далее будет отвечать за выдачу идентификаторов пользователям системы.
В случае организации распределенной системы, решение по выдаче мобильных идентификаторов можно спроектировать таким образом, чтобы заказчик смог выпускать мобильные метки, привязанные к определенным объектам, которые будут загружаться в мобильное приложение. То есть мобильная метка будет являться своего рода контейнером, состоящей из связки «Метка объекта – идентификатор».
При этом в мобильном приложении одновременно может храниться несколько различных мобильных меток (связок «Метка объекта – идентификатор») и передача идентификатора считывателю будет происходить автоматически по признаку «Метка объекта». Однако, в таком случае, необходимо предварительно в каждый считыватель загружать соответствующий профиль через приложение настройки, используя NFC или BLE. Примеры используемых профилей приведены на рисунке 2.
Рис. 2. Профили считывателей для реализации связок «Метка объекта – имдентификатор
Процесс выдачи постоянных мобильных пропусков мало чем отличается от процесса выдачи карт, в случае организации выдачи гостевых (отзываемых) идентификаторов, администратор системы должен иметь возможность указывать «срок жизни» выпускаемого идентификатора, оперативно его отозвать, если мобильным идентификатором уже досрочно воспользовались, и выдать его следующему гостю.
Средство интеграции серверов выдачи мобильных лицензий с приложениями заказчика (API) в общем случае может предоставлять следующие возможности:
HASP на расширение пула меток, пула профилей считывателей и продления срока работы HASP.
Перейдем к вопросу мобильных приложений, которые пользователи будет использовать ежедневно. На рынке представлено несколько вариантов: использовать мобильное приложение разработчика системы, персонализировать мобильное приложение и встроить библиотеки мобильной идентификации в собственные приложения заказчика.
Резюме: с точки зрения процессов, для интегратора внедрение мобильной идентификации ничем не отличается от интеграции любой другой информационной или технической системы в корпоративную IТ-систему заказчика.
Информация и фото с https://algoritm.org/arch/arch.php?id=98&a=2384