1. Функциональные, технические и эксплуатационные характеристики:
- Какое количество карт планируется заносить в базу данных системы?
- Каково общее суммарное количество точек прохода планируется на объекте?
- Какое количество односторонних (считыватель+кнопка) и двусторонних (считыватель+считыватель) дверных точек прохода планируется из общего количества?
- Планируются ли точки прохода с турникетом? Если да, сколько из общего количества?
- Планируется ли организация бюро пропусков? Если да, какие идентификаторы для посетителей предполагается использовать (обычные карты, легкие карты на бумажной основе, QR-коды, штрих-коды, и т. п.) и какой алгоритм присвоения, выдачи и изъятия идентификатора у посетителя.
- Планируются ли точки прохода с турникетом и картоприёмником? (сбор разовых карт у посетителей при выходе из объекта) Если да, сколько из общего количества?
- Планируются ли автомобильные проездные точки? Если да, сколько из общего количества? Обязательно опишите логику проезда автомобиля.
- Планируются ли на объекте точки прохода с уличными считывателями? Если да, сколько из общего количества?
- Какой формат идентификаторов (карт) планируется?
- Какое количество рабочих мест операторов планируется?
- Какой функционал должен выполняться на рабочих станциях? (работа с разовыми пропусками, фотоверификация, печать данных на картах, построение отчётов учёта рабочего времени и т. д.)
- Какой интерфейс связи оборудования с сервером наиболее предпочтителен (RS-485 или Ethernet)?
- Какой форм-фактор контроллеров наиболее предпочтителен: в корпусе с источником питания или в исполнении под DIN-рейку?
- Необходима ли интеграция с видеоподсистемой (какой именно)? Или рассматриваются СВН, проинтегрированные с конкретной СКУД?
- Необходима ли интеграция с ОПС или ОС? (на уровне ПО или сухих контактов?)
- Объект локальный или территориально-распределенный? Если второе, то сколько площадок входят в состав объекта, где они находятся и каковы каналы связи между ними. Как планируется администрировать систему — централизованно или в каждом филиале будет ответственный администратор?
- Есть ли требования к внешнему вида считывателей — цвета, материалы, возможность кастомизации внешних панелей, скрытого монтажа? Опишите требования к световой и звуковой индикации.
- Есть ли на объекте оборудование от предыдущей СКУД, которое планируется сохранить в ходе модернизации новой системы? Если да, опишите оборудование — модели, характеристики и прочее.
2. Обеспечение защищенности программного обеспечения, несанкционированного доступа:
В этой части прописываются следующие моменты:
- СКУД должна обеспечивать защиту от несанкционированного доступа на уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего руководящего документа Гостехкомиссии России «Автоматизированные системы.
- Компоненты системы защиты от несанкционированного доступа должны обеспечивать: идентификацию пользователя; проверку полномочий пользователя при работе с системой; разграничение доступа пользователей на уровне задач и информационных массивов.
- Протоколы или отчёты аудита системы и приложений должны быть защищены от несанкционированного доступа как локально, так и в архиве.
- Уровень защищённости от несанкционированного доступа средств вычислительной техники, обрабатывающих конфиденциальную информацию, должен соответствовать требованиям к классу защищённости 6 согласно требованиям действующего руководящего документа Гостехкомиссии России «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации».
- Защищённая часть системы должна использовать «слепые» пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов).
- Защищённая часть системы должна автоматически блокировать учётные записи пользователей в случаях подбора идентификационных данных (при входе в интерфейс управления системой).
- Защищённая часть системы должна иметь механизмы смены пароля при первом входе в интерфейс управления системой.
- Защищённая часть системы должна использовать многоуровневую систему защиты. Защищённая часть системы должна быть отделена от незащищённой части системы межсетевым экраном.
- Защищённая часть системы должна использовать надёжную СУБД с возможностью шифрования данных, хранящихся в БД.
— надежности идентификации личности персонала:
- Надёжность идентификации личности сильно зависит от типа средств идентификации. Обязательно должны быть указаны конкретные требования к конкретному типу средств идентификации (анализ биометрических данных или чтение Proximity идентификаторов).
- Если мы говорим про чтение Proximity идентификаторов, то в требованиях обязательно должен быть указан их тип\стандарт и условия использования (погодные условия, место размещения, форм-фактор, защищённость от внешних механических и радиочастотных воздействий воздействий).
- Что качается анализа биометрических данных, то в требованиях обязательно должен быть указан их тип, условия использования и требования к точности идентификации.
— интеграции СКУД с видеонаблюдением, охранными системами:
- Подробное описание функционала при интеграции;
- Механизмы интеграции (стандарты передачи данных, протоколы обмена данными, взаимодействие на аппаратном уровне);
- Требования к нагрузкам и масштабам интеграции;
— масштабируемости:
Чаще всего вопросом масштабирования задаются крупные локальные или территориально распределённые проекты. У каждого из них возникают разные требования к масштабированию СКУД, но есть и общие, про которые мы напишем ниже.
- Каналы связи и мощности серверного оборудования должны быть готовы к дальнейшему наращиванию системы. Требования к серверному и сетевому оборудованию;
- Требования к нагрузочным характеристикам СКУД (т.е., должны быть указаны конкретные цифры потенциального роста количества сотрудников, точек прохода, охранных зон и так далее);
- Требование к политике лицензирования. Программное обеспечение должно иметь модульную архтектуру для возможности дальнейшего приобретения дополнительного функционала или увеличения количества оборудования, объёма БД и так далее.
- Требования к гибкости построения топологии. СКУД должна масштабироваться в завистимости от условий и специфики объекта (где-то должен быть применён интерфейс RS-485, а где-то Ethernet для подключения контроллеров к системе).
- Требования к кластеризации или применения многосерверной архитектуры. Некоторым проектам не требуется централизованное управление всеми объектами проекта, но при этом важно получать выборочные данные от них. При применении многосерверной архитектуры — сохраняется автономность каждого объекта территориально-распределённого проекта, но при этом обеспечивается обмен выборочными данными (сотрудниками, расписаниями доступа, уровнями доступа).
Если вам требуется помощь в проверке соответствия проекта на основе решений Parsec техническому заданию, или спецификациям оборудования, просто оставьте заявку:
