Введение
QR-код как идентификатор доступа — один из самых удобных способов выдать пропуск без физической карты. Сотрудник или посетитель получает код на смартфон, подносит экран к считывателю и проходит через турникет или дверь. В экосистеме Parsec этот сценарий реализуется через технологию защищенных QR-кодов формата Parsec, где считыватель PNR-QX29 анализирует прочитанный код и передает данные в контроллер доступа.
Примечание
QR Parsec (существует два вида: простой и расширенный) — это технология, а не готовое решение под ключ. Parsec предоставляет криптографию, форматы данных, средства генерации и консультации по интеграционному сервису. А канал доставки пропуска пользователю (чат-бот, почта, мобильное приложение, личный кабинет на сайте) проектируется и реализуется силами интегратора или заказчика под собственную IT-инфраструктуру.
Статья раскрывает, где и как применять эту технологию в разных типах проектов, чем отличаются простой и расширенный форматы, какие есть способы генерации кодов и как выглядит типовой сценарий интеграции с мессенджером MAX через чат-бот, как пример того, что строит интегратор поверх технологии Parsec.
QR Parsec. Технология на базе готовой инфраструктуры СКУД
| Зона ответственности | Кто реализует |
|---|---|
| Формат и криптография QR Parsec | Parsec |
| Генерация QR (SOAP интеграционного сервиса ParsecNET3 / REST API ParsecNext / библиотека libqr) | Parsec предоставляет, интегратор встраивает. Важно: интеграционный сервис ParsecNET3 работает по SOAP, REST API относится к ParsecNext. |
| База субъектов, прав доступа, проходы | СКУД ParsecNET3 / ParsecNext |
| Считывание на периметре | Оборудование Parsec (PNR-QX29 + контроллер) |
| Канал доставки QR пользователю | Интегратор / заказчик |
| Бизнес-логика (заявки, одноразовый код (OTP), привязка аккаунтов) | Интегратор / заказчик |
| Консультации по интеграционному сервису | Parsec |
Parsec не поставляет готовый чат-бот, мобильное приложение или портал самообслуживания для выдачи QR. Это осознанная архитектурная модель: технология остается гибкой, а заказчик сам выбирает любой канал, который соответствует его процессам (корпоративный MAX, email для гостей, мобильное приложение для сотрудников или веб-кабинет для подрядчиков).
Два типа QR Parsec в ParsecNET3
Простой QR Parsec
Зашифрованный QR с идентификатором доступа внутри (аналог обычной proximity-карты, длина кода до 7 байт). Считыватель расшифровывает код, извлекает ID и передает его в контроллер. Дальше работает стандартная логика СКУД: код сверяется с внутренней базой контроллера аналогично работе с обычной картой.
Расширенный QR Parsec
Зашифрованный QR со структурированным набором полей:
- ID групп контроллеров доступа (то, куда разрешен доступ);
- код идентификатора длиной до 4 байт (может быть не привязан к субъекту в СКУД; если код совпадает с существующим в системе, Parsec подставит субъекта в событие прохода);
- дата и время начала и окончания действия доступа (используются для короткого срока действия, например, несколько минут);
- время начала и окончания интервала доступа в дни, не попадающие на начало и конец периода (дневное окно для промежуточных дней многодневного периода).
Параметры срока задаются в формате ISO 8601 (как в интеграционной библиотеке libqr и документации на расширенный QR). Главное преимущество: возможность регулярного перевыпуска QR с заданным интервалом и ограниченным сроком действия без потери данных о субъекте доступа в СКУД. Это снижает риск клонирования и передачи QR третьим лицам.
Ограничения ParsecNext
В ParsecNext на текущий момент реализован только простой QR Parsec. Расширенный формат и штатный перевыпуск QR с коротким сроком действия не поддерживаются.
| Параметр | ParsecNET3 | ParsecNext |
|---|---|---|
| Простой QR | Да | Да |
| Расширенный QR | Да | Нет |
| API интеграции | SOAP (интеграционный сервис) | REST API |
| Перевыпуск QR с коротким сроком действия | Штатно для расширенного QR | Нет (только простой QR без перевыпуска) |
Практический вывод: При проектировании на ParsecNext интегратор работает с REST API платформы. Это принципиально иной интерфейс по сравнению с SOAP-сервисом ParsecNET3. Сценарий «живого» QR с коротким TTL на ParsecNext потребует пересмотра архитектуры или гибридного решения на переходный период.
Требования к оборудованию
Для простого QR:
- Считыватель: PNR-QX29 (обязательно).
- Контроллер: Любой поддерживаемый контроллер Parsec.
Для расширенного QR (только ParsecNET3):
- Считыватель: PNR-QX29 (обязательно).
- Контроллер: NC-60K.M или NC-100K-IP.M (для связи со считывателем рекомендуется интерфейс OSDP).
- Обратите внимание: Именно эти контроллеры работают со структурой расширенного QR Parsec. Связка PNR-QX29 + NC-8000 для расширенного формата не подойдет.
Способы генерации QR-кодов
Оба типа QR в ParsecNET3 можно получить двумя путями. Интегратор выбирает способ и встраивает его в свою инфраструктуру доставки.
- Интеграционный сервис ParsecNET3 (SOAP)
Внешнее приложение отправляет SOAP-запрос на сервер интеграции СКУД и получает готовое значение QR для визуализации. Parsec консультирует по работе с этим сервисом, а клиентская часть реализуется на стороне интегратора.
Подходит для: централизованной архитектуры с постоянной связью с сервером ParsecNET3, единой точки контроля и умеренной нагрузки. - Интеграционная библиотека Parsec libqr
Библиотека встраивается во внешнее приложение интегратора и генерирует QR локально, без синхронного SOAP-запроса при каждом обращении.
Подходит для: высокой оперативности выпуска, автономных или распределенных сценариев, ботов и мобильных приложений с большим числом одновременных пользователей. - ParsecNext REST API
Взаимодействие со СКУД осуществляется через REST API платформы. Генерация QR-значения происходит через штатные механизмы ParsecNext или libqr, в зависимости от согласованной архитектуры.
Сравнение подходов
| Критерий | SOAP (ParsecNET3) | libqr | REST API (ParsecNext) |
|---|---|---|---|
| Платформа | ParsecNET3 | ParsecNET3 / ParsecNext | ParsecNext |
| Зависимость от сервера | Постоянная | Минимальная | По архитектуре |
| Скорость выпуска | Средняя | Высокая | Зависит от реализации |
| Кто реализует | Интегратор / Заказчик | Интегратор / Заказчик | Интегратор / Заказчик |
Применимость в разных типах проектов
Во всех сценариях Parsec обеспечивает технологию QR и СКУД, а канал доставки остается в зоне ответственности интегратора или заказчика.
| Тип объекта | Сценарий | Тип QR | Генерация | Доставка | Оборудование |
|---|---|---|---|---|---|
| Корпоративный офис и бизнес-центр | Сотрудники получают QR вместо или в дополнение к карте | Простой | SOAP (NET3) или REST API (ParsecNext) | Корпоративный бот MAX, приложение, email | PNR-QX29 + существующие NC |
| Объекты с повышенными требованиями к безопасности | Режимные зоны, риск передачи пропусков | Расширенный (только ParsecNET3) | libqr в защищенном промежуточном ПО интегратора | Приложение или бот с автообновлением QR | PNR-QX29 + NC-60K.M / NC-100K-IP.M |
| Пропускная система для посетителей | Предварительная регистрация, разовый визит | Простой | SOAP / REST API из модуля посетителей | Email, SMS (с WEB-ссылкой), бот MAX | PNR-QX29 + любой контроллер |
| Образовательные и спортивные объекты | Массовые потоки, мероприятия | Простой | libqr при массовой выдаче | Личный кабинет на сайте, мобильное приложение | PNR-QX29 + любой контроллер |
Рекомендации для проектов с миграцией на ParsecNext:
- Закладывать только простой QR;
- Проектировать интеграцию на REST API, а не переносить SOAP-клиент как есть;
- Не строить критичные процессы на расширенном формате.
Примерный сценарий интеграции: выдача QR через бота MAX
Ниже представлен пример типовой архитектуры, которую интегратор или заказчик реализует поверх технологии QR Parsec и СКУД ParsecNET3. MAX-бот — лишь один из возможных каналов доставки. Аналогичная схема применима для email, мобильного приложения или веб-кабинета.
Исходные условия (обязательные для сценария):
- Бот MAX: Зарегистрирован в платформе, получен
access_token. Для продуктовой среды настроена подписка на события (POST /subscriptions) на HTTPS-адрес сервера интегратора (порт 443, доверенный TLS). Базовый URL API:platform-api2.max.ru. Токен передается в заголовке Authorization. - Сервер интегратора: Принимает события бота, реализует бизнес-логику выдачи QR, аудит и обращение к СКУД или libqr. Длительный опрос событий (Long Polling) не рекомендуется.
- СКУД Parsec: В карточке субъекта заранее создано дополнительное поле (например, «Телефон») и заполнено номером. По этому полю сервер интегратора проверяет наличие субъекта и право выдать QR.
- Для проверки и данных о пропуске сервер интегратора обращается к интеграционному сервису Parsec (ParsecNET3, SOAP): ищет субъекта по дополнительному полю «Телефон», убеждается, что доступ разрешён, получает код идентификатора.
- Сервер интегратора формирует QR-код Parsec: либо запрашивает готовую строку у интеграционного сервиса (вариант А), либо генерирует её локально библиотекой libqr (вариант Б). Затем собирает из строки картинку QR.
- Картинка QR возвращается пользователю в чат бота MAX (через API MAX) вместе с короткой подсказкой: поднести экран к считывателю, при необходимости: до какого времени действует пропуск.
- Пользователь подходит к точке прохода и предъявляет QR на экране телефона считывателю PNR-QX29.
- Считыватель расшифровывает код и передаёт данные в контроллер доступа. Контроллер принимает решение о доступе (для простого QR: по базе идентификаторов; для расширенного: ещё и по сроку и зоне, зашитым в QR).
- При разрешении контроллер управляет исполнительной периферией: открывается дверь или турникет, пользователь проходит. Факт прохода фиксируется в СКУД. Если на шагах 3-5 проверка не пройдена (номер не найден, доступ запрещён, сработала политика ИБ), бот сообщает об отказе простым текстом и QR не выдаёт.

Рисунок. Архитектура выдачи QR Parsec через бота MAX.
Пользовательский сценарий (шаг за шагом)
Технические детали скрыты на стороне интегратора, пользователь их не видит:
- Пользователь открывает мессенджер MAX и находит бота пропуска.
- В чате с ботом нажимает кнопку авторизации (например, «Поделиться контактом»). MAX отправляет боту номер, привязанный к аккаунту.
- Бот передает номер на сервер интегратора, который сверяет телефон с данными в СКУД и применяет правила службы информационной безопасности (ИБ).
- Сервер интегратора обращается к SOAP-сервису Parsec, ищет субъекта по полю «Телефон», проверяет доступ и получает код идентификатора.
- Сервер интегратора формирует QR-код (запрашивает строку у сервиса Parsec или генерирует ее локально библиотекой libqr) и собирает картинку QR.
- Картинка возвращается пользователю в чат MAX вместе с короткой подсказкой.
- Пользователь предъявляет QR на экране телефона считывателю PNR-QX29.
- Считыватель расшифровывает код и передает данные в контроллер, который принимает решение о доступе.
- Турникет или дверь открывается, а факт прохода фиксируется в СКУД.
(Если на шагах 3–5 проверка не пройдена, бот сообщает об отказе простым текстом без выдачи QR).
Многоуровневая проверка права выдать QR (зона ИБ заказчика)
| Уровень | Суть проверки | Где реализуется |
|---|---|---|
| L1. Идентификация в MAX |
Получение номера через кнопку request_contact, проверка hash совпадения номера с аккаунтом.
|
Бот + сервер интегратора |
| L2. Наличие в СКУД | Поиск субъекта по доп. полю «Телефон». | Сервер интегратора → SOAP Parsec |
| L3. Право на QR | Есть активный идентификатор нужного типа, группа доступа или территория; статус не заблокирован. | Сервер интегратора → СКУД |
| L4. Политики ИБ | Время суток, подразделение, частота запросов, одноразовый код (OTP), белый список мессенджеров, запрет выдачи уволенным. | Сервер интегратора / регламент ИБ |
| L5. Аудит | Журнал: кто запросил, по какому телефону, какой ID выдан, успех/отказ. | Сервер интегратора + отчеты Parsec |
Примерный сценарий реализации кода
Шаг 0. Подготовка бота и подписки на события
POST https://platform-api2.max.ru/subscriptions
Authorization: {access_token}
Content-Type: application/json
{
"url": "https://integrator.example.com/webhook",
"update_types": ["bot_started", "message_created", "message_callback"],
"secret": "your_secret"
}
Шаг 1. Старт диалога и получение телефона
POST https://platform-api2.max.ru/messages?user_id={user_id}
Authorization: {access_token}
{
"text": "Для выдачи пропуска поделитесь контактом",
"attachments": [{
"type": "inline_keyboard",
"payload": {
"buttons": [[{ "type": "request_contact", "text": "Поделиться контактом" }]]
}
}]
}
Шаг 2. Поиск субъекта в СКУД (псевдокод)
// ParsecNET3, служба интеграции (SOAP)
Person[] persons = PersonSearch(sessionID, phoneFieldId, EQUALS, phoneFromMax, null);
if (persons == null || persons.Length == 0) {
/* отказ: субъект не найден */
}
// далее проверка статуса, идентификаторов, групп доступа
Шаг 3. Запрос пропуска пользователем.
Сотрудник нажимает кнопку/команду в боте («Получить QR»). Сервер интегратора повторно прогоняет цепочку проверок ИБ (на случай блокировки между регистрацией и запросом).
Шаг 4. Генерация QR через libqr (C-код)
// Простой QR (4 байта ID)
struct qr_context *ctx = qr_new_default_ctx();
uint8_t out[QR_DATA_STRUCT_LEN_ASCII + 1] = {0};
qr_GenId4(ctx, identifier_u32, out);
// Расширенный QR
qr_UserAccess_t access;
strncpy(access.DateTimeFrom, "2026-07-14T09:00:00", USER_ACCESS_DATETIME_LEN);
strncpy(access.DateTimeTo, "2026-07-14T18:00:00", USER_ACCESS_DATETIME_LEN);
strncpy(access.TimeStart, "00:00:00", USER_ACCES_TIME_LEN);
strncpy(access.TimeEnd, "00:00:00", USER_ACCES_TIME_LEN);
access.Area[0] = 42; access.Area[1] = 0; access.Area[2] = 0; access.Area[3] = 0;
qr_GenAccess(ctx, identifier_u32, &access, out);
qr_delete_ctx(ctx);
(Ключ AES libqr должен совпадать с ключом считывателей PNR-QX29 объекта и храниться в надежном хранилище секретов).
Безопасность (зона интегратора)
| Риск | Мера противодействия |
|---|---|
| Подмена пользователя в MAX |
Кнопка request_contact + проверка hash; при необходимости OTP или корпоративный каталог.
|
| Выдача чужому телефону |
Совпадение телефона MAX с полем субъекта; отказ при неоднозначном PersonSearch.
|
| Пересылка QR | Расширенный QR с коротким TTL + регенерация через libqr; расписания и зоны в СКУД. |
| Утечка ключей libqr / токена | Хранилище секретов; токен бота только на сервере интегратора; ротация. |
| Обход политик ИБ | Многоуровневая проверка до генерации; аудит отказов и выдач. |
Заключение
Итог для проектировщика: Parsec предоставляет технологию QR и данные СКУД, MAX выступает транспортом до пользователя, а сервер интегратора — это место, где сходятся телефон из MAX, дополнительное поле субъекта, политики ИБ и выбранный способ генерации.
При проектировании фиксируйте в техническом задании: платформу (ParsecNET3 или ParsecNext), тип QR, модели контроллеров, способ генерации, канал доставки и границы ответственности. Тогда интеграция будет предсказуемой, а ожидания заказчика совпадут с моделью «технология от Parsec, решение от интегратора».