Грядет ли эра IP-турникетов?.
Как быстро летит время! К сожалению, я не смог найти достойную замену этой фразе для начала статьи. И действительно, еще вчера казавшийся таким смешным анекдот: «Алло, хозяина сейчас нет дома, с вами говорит его холодильник» – сейчас уже не более чем краткое описание очередного модного и дорогостоящего (пока что) сетевого девайса.
Очевидно, современному обществу всегда необходим некий фетиш для поклонения, причем не только для создания прибавочной стоимости определенной группой лиц, но и так вообще – чтобы не скучать.
Сегодня роль такового выполняют различные устройства с приставкой IP. И хотя на горизонте уже вполне четко проступают контуры «сменщика» нынешнего идола по имени «нано», на данный момент вряд ли что-то может сравниться на рынке безопасности с популярностью разнообразных сетевых систем. Вполне объяснимо, что производители и поставщики систем безопасности в своем абсолютно рациональном порыве ковать железо, пока горячо, стараются использовать бренд IP по максимуму. Ведь очевидно, что если к контроллеру СКУД приладить каким-либо образом порт Ethernet, то вполне можно назвать сей продукт IP-контроллером. Некоторые из коллег по цеху пошли дальше: оказывается, если спрятать IP-контроллер внутрь обыкновенного турникета, то получится IP-турникет. Начинание, на мой взгляд, вполне разумное, думаю, что не за горами очередные новинки в этом направлении. Ведь даже трудно представить, сколько еще есть замечательных мест, куда можно поместить IP-контроллер.
Если же говорить серьезно, то, на мой взгляд, происходит обыкновенная подмена понятий, так знакомая нам всем при выборе какого-то продукта потребления. Эмоции здесь ни к чему: вы ведь уже привыкли к переднеприводным внедорожникам в автосалонах и натуральному 100%-ному восстановленному соку в гипермаркетах. Просто каждый выработал для себя определенные критерии, что считать настоящим, а что – не очень. Вот и я хочу лишь изложить свой взгляд на критерии, по которым контроллеры СКУД и создаваемые на их основе системы можно отнести к сетевым.
Начнем с простого, я бы даже сказал, дилетантского взгляда на информационную сеть, как таковую. Какие ассоциации вызывает у обыкновенного человека словосочетание «компьютерная сеть»? Ну, это, конечно, компьютеры, соединенные тем самым «шнурком», который иногда зачем-то проверяет сисадмин, ползая под столом и спотыкаясь о ваши ноги. Правильно! Не берусь сказать, когда появился термин «сетевое» на рынке CCTV, но сетевым СКУД на нашем рынке уже, думаю, лет 10. Реклама этого продукта и по сей день зачастую выглядит примерно так: схематично изображенная компьютерная сеть с обозначенными АРМами операторов и администраторов, в которой также показаны некие «сетевые конверторы» для состыковки управляющих контроллеров СКУД с сетью через все тот же RS485, виртуальный COM-порт и т. д. Ну а далее обычно нарисован собственно головной или мастер-контроллер СКУД, объединяющий младшие или себе подобные контроллеры гордо раскинутыми в разные стороны шлейфами все того же RS-485, RS-422 или токовой петлей. Не сочтите за занудство, но что именно здесь является сетевым и почему для такой «сетевой» системы заказчику помимо прокладки сети Ethernet по своему объекту надо думать о размещении дополнительных километров различных витых пар в экране? Итак, в моем понимании настоящая сетевая система должна иметь связь между различными своими компонентами именно по сети. Безусловно, я не говорю о периферии: герконах, кнопках выхода, считывателях, замках и исполнительных устройствах (хотя кто знает,кто знает! – см. IP-турникет).
Теперь, что называется, перейдем от формы к содержанию. Если внимательно присмотреться к оставшейся после предыдущей «отсечки» продукции, именуемой «сетевые системы контроля доступа», то без труда можно заметить, что подавляющее большинство производителей для связи по сети между элементами своих СКУД используют все те же конверторы Ethernet в СОМ-порт или в RS-485. Другими словами, контроллеры и интерфейсные модули СКУД, обычно разработанные еще задолго до эры IP, общаются между собой, например, все по тому же RS-485, не зная о том, что на линии связи между ними теперь есть цепочка «посредников», преобразующая сигнал сначала из RS-485 в сетевой протокол, а потом обратно. Формально это действительно СКУД, работающая по сети. Но такой вариант обладает целым рядом функциональных ограничений, которые, на мой взгляд, при определенном масштабе системы размывают саму идею преимущества использования сетевого решения на объекте. Во-первых, само наличие цепочки таких конверторов для преобразования сигнала вкупе с прохождением информационных пакетов по сети, состоящей не из одной, а, к примеру, из нескольких подсетей со шлюзами, конверторами и т. д., может вызвать длительную задержку сигнала-отклика со стороны ведомого контроллера на запрос ведущего. И эта задержка вполне может быть воспринята ведущим контроллером как неисправность (напоминаю, контроллеры «не знают», что общаются через сеть). Во вторых, наверное, самые популярные (и вполне бюджетные) на рынке СКУД конверторы RS-485/Ethernet компании Lantronix поддерживают работу в сети по UDP-протоколу, предназначенному прежде всего для работы как раз в одноранговых сетях, где отсутствие гарантированной доставки сообщений и требование обязательной доступности определенных адресов в сети не является большой проблемой*. Помимо этого сами производители СКУД часто рекомендуют заводить таким образом по сети на один ведущий контроллер не более 4–8 ведомых, даже если в стандартном варианте, когда связь ведущего и ведомых осуществляется по RS-485, их может быть до 32 и более. Итак, для работы в таком режиме заказчику необходима выделенная подсеть для работы исключительно СКУД, причем с дополнительными ограничениями количества точек контроля системы. Но тогда возникает резонный вопрос: зачем жертвовать функционалом хорошей СКУД ради некой эфемерной инновации? Прокладывать кабельные соединения вам придется все равно только под нее, так не лучше ли использовать старый, добрый RS-485, где все надежно работает, а сам шлейф при желании можно удлинить с 1200 м повторителями сигнала более чем на 3 км?
Итак, в моем понимании на сетевом котроллере должен быть полноценно (программно и аппаратно) реализован порт Ethernet с сетевым протоколом TCP/IP и поддержкой системы динамического распределения адресов (DHCP), что позволяет избежать ошибок настройки, вызываемых необходимостью вводить значения для каждого сетевого устройства вручную. Кроме того, DHCP помогает предотвратить конфликты адресов, вызываемые использованием ранее назначенного IP-адреса при настройке нового компьютера в сети. По сути, это должен быть промышленный компьютер (вероятно, с ОС Linux), позволяющий в качестве контроллера сетевой СКУД воспользоваться всеми преимуществами полноценного обмена информации между модулями и сервером системы в рамках уже существующей на объекте заказчика сети. Более того, полноценная реализация всех возможностей работы по сети подразумевает создание СКУД с распределенным интеллектом. Другими словами, ПО таких контроллеров должно обеспечивать эффективное взаимодействие не только на уровне контроллер – сервер системы, но и в таких вариантах, как контроллер – контроллер (равный с равным или peer-to-peer), контроллер – внешняя система CCTV или ОПС, контроллер – система жизнеобеспечения или энергосбережения здания и т. д. Общая идея состоит в том, что после загрузки определенных сценариев работы в контроллеры СКУД они самостоятельно (без вмешательства управляющего сервера) могут при необходимости взаимодействовать как друг с другом для выполнения необходимого функционала доступа (самый простой пример – глобальный antipassback), так и включать по понятному для них протоколу внешние IP-камеры на запись, посылать команды в систему энергосбережения об отключении света в пустующих офисах и, в свою очередь, принимать по сети команды и информацию от других систем управления зданием (предприятием), функционирующих на объекте заказчика. Причем такой режим работы для контроллеров без активного взаимодействия с сервером системы должен являться не каким-то чрезвычайным, а, наоборот, стандартным.
Могу предложить простой тест на IP-интеллект. Нарисуйте структурную схему соединений всех компонентов вашей сетевой СКУД, после чего зачеркните на рисунке сервер системы и постарайтесь максимально честно ответить на единственный вопрос: что и как долго сейчас может делать ваша система? Количество оставшегося функционала и продолжительность его поддержки в таком режиме прямо пропорциональны моему пониманию правильно работающей сетевой системы контроля доступа с действительно распределенным интеллектом.
Отвечая на вечный контраргумент о незащищенности открытых сетей и их неприспособленности для использования системами безопасности, могу ответить одно: «Так защищайтесь, господа!» На контроллер на базе промышленного компьютера можно установить межсетевой экран (firewall), а обмен информацией по открытым сетям можно защитить реализацией VPN-соединения. Безусловно, эта задача не является простой, но в любом случае при грамотной реализации сетевого протокола в контролерах СКУД вам становятся доступны все имеющиеся на рынке IT-методы информационной защиты.
Еще один, на мой взгляд, непременный атрибут настоящей сетевой системы контроля доступа – это клиент-серверная технология построения. Причем та, в которой в качестве клиента выступает не специальное приложение, устанавливаемое отдельно, а web-браузер. Другими словами – web-клиент. В автономных СКУД с жестко ограниченным функционалом web-сервер встраивается непосредственно в сами контроллеры, а в случае распределенных сетевых систем устанавливается на выделенном сервере. Использование web-клиентов дает не только полную мобильность перемещений пользователям системы (работа с системой через любой мобильный телефон с web-браузером), но и позволяет максимально гибко настраивать интерфейс пользователя в соответствии с его задачами и полномочиями.
Кроме того, заказчик действительно может сэкономить на инсталляции и эксплуатации системы.
Нет проблем с обновлением ПО – оно происходит одновременно на всех машинах в сети, включая удаленные управления/филиалы. У пользователей нет затруднений, связанных с рассинхронизацией базы или некорректными записями в базу данных. Существенно снижаются требования к аппаратной части компьютеров, на которых будут разворачиваться рабочие места (можно использовать «тонких клиентов»). В разы снижается нагрузка на сеть, поскольку по сети передается только результат работы сервера, а не массив данных. Отсутствует зависимость от операционной системы – web-приложения являются межплатформенными сервисами. Легко решается задача доступа к внутренним ресурсам компьютера, все критически важные процессы блокируются стандартными средствами операционной системы (в настоящее время в ряде систем СКУД даже для запуска операторского места необходимы права администратора).
К вопросу о незащищенности доступа в систему через web-интерфейс от третьих лиц хочу напомнить, что все крупнейшие мировые банковские структуры достаточно давно предлагают клиентам доступ к управлению своими финансами через различные web-порталы. Соответственно, при должном подходе и эта задача решаема благодаря протоколу SSL.
Закончить свое повествование приходится тоже избитой фразой – идеальных систем нет. Системы, целиком и полностью отвечающие вышеописанным критериям на рынке безопасности, вы тоже вряд ли найдете, хотя действительно есть пара серьезных производителей СКУД, которые в большинстве параметров максимально точно удовлетворяют заданным требованиям.
Но каждый раз, когда вы в очередной раз услышите о «реальной» IP-системе доступа, не поленитесь наложить на полученную информацию мой «трафарет» – гарантирую, что будет интересно.
И отдельное пожелание производителям отечественных СКУД (зарубежные все равно не услышат). Ваша работа действительно заслуживает глубокого уважения, если в разгар экономического кризиса вы не потеряли своих клиентов и даже нашли время почитать очень достойное издание по безопасности. Просто, может быть, стоит немного аккуратней освещать в рекламных кампаниях разработанные вами IP-решения. Выиграют от этого, на мой взгляд, все стороны.
*Особенности работы СКУД по различным сетевым протоколам подробно освещены на страницах журнала ТЗ в статье г-на Стасенко в № 6 2008.
Замки NAPCO Trilogy для контроля доступа с сигнализацией
Как пандемия изменила потребности в контроле доступа
Новые ориентиры в биометрии контроля доступа
SmartBadge | переносной многорежимный трекер | Смарт-бейдж
HID обьявили лидером в отрасли биометрической аутентификации
